Defining Your Security Policy
0 The most important role of a security policy is to raise security awareness within your organization.
0 Implementing risk analysis and risk management enables you to control the security measures to take directly related to your business goals.
0 Defining and implementing security audits is a way to keep your operational security measures on their defined levels.
0 Defining and implementing a contingency plan enables your company to act quickly when things go wrong.
0 The most underestimated part of the security policy is a test plan that guides you through how changes should be tested before being taken into production, thereby preventing unexpected disruptions.
0 Each employee performs at least one role in your organization, and each role has to have access to certain applications and data. By defining these roles and access levels and mapping them in user groups limits the employees from accessing data they are not authorized to see.
0 Develop a policy on how you should deal with security patches and security packs that come available from time to time.
The use of routers, firewalls, and proxies can enhance the security within your BizTalk infrastructure, if placed in the proper places and configured in a thorough and rigid way.
The server configurations that should be used for an BizTalk infrastructure is determined by a number of factors. First, what type of hardware components you are going to use. Second, to which extent does a server need to have fail-over capabilities at hardware and/or software level. Third, how is it accomplished that the Windows 2000 platform will adequately installed, configured and tuned to support its tasks.
To prevent people from eavesdropping on the communication between servers, you need to put network protection in place, which primarily means encrypting the communication with encryption protocols, such SSL and IPSec, that also take care of authentication of the parties involved.
The most obvious, but many times forgotten, aspect of physical security is equipment access, not only of servers and the computer room, but also the systems in the workspaces. People have a tendency to bolt the doors, but leave the windows open.
Securing XLANG Schedules
0 Securing XLANG schedules, drawings, and compiled schedules is about strict version control, and you can use release engineering to accomplish this.
0 The best way to physically protect your XLANG schedules is by strictly controlling the access, making full use of the access rights that the Windows 2000 file system (NTFS) incorporates.
0 The Windows 2000 functionality of Encryption File System (EFS) is a perfect way to keep the content away from prying eyes. Unfortunately, EFS is not a feasible solution in a BizTalk development and production
environment that needs to share XLANG schedules among users and XLANG schedule engines, since only the user that encrypts a file or folder can decrypt it.
0 Use different BizTalk user groups to distinguish the different roles within the BizTalk Server environment. These groups can later be mapped easily based on the role definitions for the BizTalk COM+ applications.
0 You can secure access to COM+ components using roles and mapping them to users in the Windows 2000 domain.
0 By setting authentication levels and impersonation levels per COM+ application, you can control the security environment in which the COM+ components run.
0 Security settings should be done at the COM+ application level;
however, by setting COM+ security at machine level you create a safety net in case you fail to set certain settings at the application level.
0 Create a separate service account for every COM+ application to control the access the application has to the server, and be able to audit their behavior in detail.
0 The security settings of the BizTalk Server COM+ application after installation are minimal.
0 The Message Managing database,Tracking database, and Shared Queue database all use SQL Server authentication. Only the XLANG Scheduler persistent database uses Windows authentication.
0 By default, BizTalk server uses the SQL Server system administrator account ("sa") to log in to the database, giving the COM+ applications that use these database unlimited access. By creating a separate SQL Server user account for each of these databases as the owner of the database, a more restricted access is achieved.
0 By creating database roles, which are in line with the roles you defined in the BizTalk COM+ applications, you can restrict access to database objects such as tables, views, or stored procedures, or even table columns (fields) in a database. Database users are members of one or more roles, giving them limited access to the database.
0 Different strategies enable you to prevent, or at least minimize, the loss of data in case of a database failure. This can be achieved by a well-designed backup/recovery strategy, or by creating and enabling database replication, through a Publish/Subscribe configuration.
0 Windows 2000 Kerberos V5 is a distributed security protocol that has its own way of delivering authentication, data integrity, and data privacy without using certificates.The CryptoAPI is used in generating session keys and encrypting data. The Kerberos Key Distribution Center runs on every domain controller and gives out tickets that enable users to access services on services, even if these services run in other domains or on different operating systems.
0 Windows 2000 Certificate Services allows you to become your own certificate authority (CA) for your domain, or BizTalk environment. Certificates issued to users can be managed from within the Active Directory.
0 Certificates are used in every authentication and encryption method within Windows 2000. Within BizTalk Server 2000, you can set certificates on inbound and outbound documents on BizTalk channels.
0 Certificate Services come with a Web site from which your trading partners can request a certificate, in case you decide to control the certificates that are used in the BizTalk Server environment.
0 CryptoAPI is the powerful interface that enables your BizTalk application to make use of the certificate service providers (CSPs) that are available on the Windows 2000 server.
0 A secure exchange of compound messages between a BizTalk server and a trading partner can be achieved by encoding them in MIME format and sending them by Secure MIME (S/MIME).
Was this article helpful?