Security Considerations for Monitoring Server

Security considerations for Monitoring Server

Monitoring Server provides deployment and configuration options to allow you to tailor the application to help meet your company requirements for securing your business data. Being informed on what the options are and knowing how they function will help you choose the right option for your deployment.

Application Pool accounts

The Monitoring Server application pool runs under the identity of an account specified during the configuration wizard. The application pool the SharePoint site runs under should be setup with the same identity. However, our configuration wizard does not change the current setting and it is up to the user to change this setting as a manual step. We strongly recommend using a domain account as the Application Pool Identity. The domain account as a best practice should only be assigned to the IIS_WPG group on the machine Monitoring Server is installed on.

The wizard supports specifying a domain account which is the recommended deployment. In addition the wizard supports specifying a built-in account. These options include Local System, Local Service and Network Service. The configuration wizard will automatically assign the selected account access to our application database for metadata storage. Under the default deployment this account needs to be assigned permissions by you to each of the data sources you plan to use. Refer to “Data Source authentication” for details on what additional options exist.

Data Source authentication

Data sources registered on the Monitoring Server will often require authentication for data access. By default the Monitoring Server always uses the application pool identity for connecting to any data source. The only exception for the default case is data sources that allow you to specify a connection string containing credentials. During the wizard for creating an Analysis Services data sources you can specify a set of roles to secure the connection based on.

Authenticating to data sources as a single user might not provide enough control over access to your business data. Two options are available on the server to allow for better access control. The first option is use of the CustomData field on an Analysis Services connection string. Our application is able to specify the domain/username of the account which authenticated to our server as the CustomData of the connection string. It is possible to then configure Analysis Services security model to restrict access based on the string containing the username provided by our application. The second is Monitoring Servers support of Kerberos delegation by enabling the Bpm.ServerConnectionPerUser property in the web.config file. Delegation provides an impersonation token from the currently authenticated user to any registered data source. As a result each of your users needs access to the data source both in our own internal application security as well as on the service you are connecting with. The advantage to this is you can use the application security models which are available for each registered data source.

Analytic Reports and Data Source security

Support for navigation on Analysis Services reports provides users the ability to gain understanding of their business beyond what a static report might convey. The report level security for editors and readers acts as a way for users to share data that they may have found interesting to a specific set of people. Editor or reader permissions on an analytic report will not prevent users from seeing the data on the cube outside of what the original view allowed. Data source security is the only way to limit access to cube data. Once you have given a user access to a data source referencing a cube you should expect that they will be able to see all of the data in that cube unless you have restricted the permissions in Analysis Services. Given that by default our application connects as a single user for all data sources that is difficult unless you have employed some of the suggestions in the “Data Source authentication” topic mentioned above.

Data Source Connection Strings

Monitoring Server provides users with the ability to specify their own connection strings for many of the supported data source types. If you choose to specify a set of credentials as part of the connection string you need to be aware that these will not be encrypted and can be stored directly in the workspace of whoever has access to the data source. Supplying credentials as part of a connection string is NOT recommended.

SharePoint deployments

As mentioned in the Application Pools section we highly recommend that you set the application pool of your SharePoint deployment to match the Monitoring Servers web sites. The reason we recommend this is to insure that if you are using the default configuration that your reports and scorecards are executed under the same user context. If you chose to use the Bpm.ConnectionPerUser it is still recommended to simplify configuration of Kerberos. In either case one other important note is the SharePoint process is going to have access to the metadata repository for our application. Make sure that your SharePoint deployment restricts who can publish content that might be able to access that data.

IIS configuration

In addition to the configuration of the application pool identity and the web.config file securing the Monitoring Server requires that SSL has been enabled for all the relevant web sites. We do not recommend using anything other than Windows Integrated Authentication and using a non-default port if possible.