BizTalk Server Operation Security

BizTalk360 has a powerful operational governance and auditing capability to maintain the logs of the user activities in the system. This feature helps the BizTalk administrators to find out "Who did what" in the environment over a period of time. Consider a few example scenarios when the support user:

• Accidentally stops a host instance
• Terminated a suspended service instance
• Accidentally unenlisted an orchestration in the application

In these situations, if the user action is recorded and logged as an event, it will help the administrator to identify the root cause of the issue. Right now, in BizTalk Administration console, none of the activities are audited. This leaves organizations to run their support purely based on trust, which may not be ideal in some mission-critical situations like Healthcare, Financial services etc.

What artifacts can be audited in BizTalk360

BizTalk360's has the capability to audit the following areas:

• Application operations
• Service instance operations
• Host instance operations
• ESB Message Activities
• Business Rules Activities

BizTalk Application Artifacts Operations

BizTalk Server uses a publish/subscribe messaging engine architecture where all incoming messages are published to the MessageBox database and picked up by the send ports, orchestrations. The three main components of this architecture are:

• Receive locations/Receive Ports
• Orchestrations
• Send Ports

These components are isolated from one another and BizTalk Server offers the flexibility to control (start, stop, enable, disable etc.) each one of them individually. Let's assume we have an application PurchaseOrderProj that uses, say, MSMQ adapter configured on the receive port (ReceivePort) to receive the messages in BizTalk Server. Accidentally (or intentionally) if the support user disables the receive location, it will stop BizTalk Server from polling messages from MSMQ. This will result in serious consequences to the business. Therefore, it is critical for the organizations to collect the audit log of the activities that are done on application artifacts like send ports, receive locations and orchestrations.

BizTalk360 by default audits all the activities performed by the support person on the application receive location, orchestration, and send ports. Following are the list of events captured by BizTalk360 for auditing:

• Enable/disable of receive locations
• Start/Stop/Enlist/Unenlist of orchestrations
• Start/Stop/Enlist/Unenlist of send ports

Audit Service Instance Operations in the BizTalk Environment

It is a best practice to keep an eye on the status of the service instances in the BizTalk environment. Too many service instances (in any state like suspended, ready to run, etc.) and not clearing up periodically in the environment might highlight some potential problems. Example: Too many suspended service instances will bloat the MessageBox database and affect the overall performance of the system over a duration of time.

Therefore, it is the responsibility of the support person to take a decision whether to resume the suspended service instances or to terminate them. But there may be chances when the support person may accidentally terminate a service instance that must be resumed. This could cost the business a potential transaction. Therefore, it is important for the organization to set up auditing mechanisms to record the user actions to understand "Who did what" in the environment.By clicking on the eye icon user can able to view the service instance audit details.

Audit Host Instance Operations

A BizTalk Host is a logical set of zero or more BizTalk runtime processes, which you can configure to run items such as adapter handlers, receive locations (including pipelines), and orchestrations. A host instance is a physical process (NT Service) that is created in BizTalk Servers where the message processing, receiving and transmitting occurs.

BizTalk Server provides the capability for the users to control the state of the host instances (start, stop, enable, disable) through the BizTalk Server Administration Console. Any of these operations can have consequences on the business operations. For instance, if a tracking host instance (which is responsible for moving DTA and BAM tracking data from MessageBox database to DTA and BAMPrimaryImport databases) is accidentally stopped, the data transfer will not happen as expected. This will bloat up the MessageBox database size and result in performance issues.

On a different example, if a host instance responsible for receive or transmitting messages is kept in a disabled or stopped state, then BizTalk Server will not receive or transmit messages, which could be serious. So, it becomes more important to keep track of the health of BizTalk host instance by monitoring as well as keep an eye on who is performing any activities on the host instance.

Audit ESB Message activities

BizTalk360 has the capability to audit the message submit/resubmit activities in the ESB Portal. Whenever the logged in user tries to resubmit a message to a particular receive location and if the resubmit activity happens successfully, an audit record will be created under the "ESB Message Activities" section BizTalk Activities in Governance Audit module of BizTalk360 with the result as "202-Successfully submitted to ". Even if the submit operation does not happen as expected, an audit log would be created under ESB message activities with the result as "500-Failure submitting to ". The audit information gets logged with the action that was performed on the message, the message id, the result of the activity, date time stamp when the operation was performed, and details of the user who performed the action.

In addition to auditing the ESB message activities, BizTalk360 offers added functionality to users to be able to view the details of the message that was submitted. The user with access to the Governance Auditing module in BizTalk360 can simply click the value under 'Message ID' column to view the message details such as general message information, content properties, and context properties.

Audit Business Rules Activities

With the traditional BizTalk Rules Composer feature, the process is long and tedious when it comes to saving/publishing and deploying the business rules. The "Business Rules Composer" feature comes out-of-the-box with the product. With this feature, the business user no longer needs to contact IT to add/modify a rule and publish/deploy them. Any user who has access to Business Rules Composer can create new rules, save, publish and deploy policy directly to the production environment. So, it becomes important to track the changes made in the business rules and as well as keep an eye on who is performing any activities in the business rules composer.