Securing Xlang Schedules

Up to this point, most of the discussion has been about securing the infrastructures and servers.Therefore, it is time to take a closer look at how the specific BizTalk server parts can be made more secure. Moreover, the XLANG schedule is a good starting point.There are a number of security issues involved:

■ Development and deployment process

■ Version control and release engineering

■ File protection

Running an XLANG schedule in production involves a number of stages: development, testing, acceptance, and production (also referred to as deployment). In a well-designed development process, every stage has its own environment, without ties to each other.This means that files have to be transported from one environment to the other.You want to be sure that what is running in production is the same as was developed. The biggest challenge in protecting your XLANG schedules during all these phases is that the schedules are plain-text files. Additionally, you also are dealing with COM+ components that are developed and called from one or more XLANG schedules and COM+ components calling XLANG schedules. The best approach to transferring your BizTalk solution between phases is to let it be controlled by a release engineer, who should take care of version control, packaging the components and schedules into, for example, a .CAB file, and signing this .CAB file with a certificate. In this way, the chances of tampering with the files will be significantly reduced. More on packaging can be found in the sidebar Bringing the BizTalk Application to Production. In short, the development and deployment process should work as follows:

1. The development teams hand over the schedules, components, and database scripts to the release engineer.

2. The release engineer checks the versions of the different parts, installs them on the test environment, and rebuilds databases as needed. A test plan, preferably an extensive regression test plan, is executed where the working of the BizTalk application is tested.

3. If all problems and errors are resolved during the test phase, the release engineer packages the application, including an installation script, and signs the total package. Now he or she can hand it over to the acceptance testing team. Again, this will lead to some modifications and bug fixing.

4. The communication between the acceptance testing team and the development team(s) is conducted by the release engineer. It is his or her role to make sure that the right fixes are released.

5. If the acceptance team finally gives permission to proceed, then the release engineer finalizes the version, repackages and signs it, and hands it over to production.

6. The release engineer is, of course, also responsible for all the correct documentation that has to be shipped with the application.

Now let's focus on securing the development environment. Developers are granted far more access rights than end users are. In fact, most of the time they have administrator rights.This is not a problem, as long as the systems are properly secured.

Was this article helpful?

0 0

Post a comment