The last step in securing an installation is to secure the data collected and stored through encryption. The following summarizes how data is secured as it moves from component to component:
- Between an audited computer and the spooler that stores the data locally when no collectors are available, audit data is not encrypted. Only the local Administrator account can access the data by default.
- Between the audited computer’s data collection service (
wdad) and the collector, data is secured using Generic Security Services Application Program Interface (GSSAPI) with Kerberos encryption.
- Between the collector and the audit store database, data can be secured using Secure Socket Layer (SSL) connections and ARC4 (Windows 2003) or AES (Windows 2008) encryption if the database is configured to use SSL connections.
- Between the audit store and management databases, data can be secured using Secure Socket Layer (SSL) connections and ARC4 (Windows 2003) or AES (Windows 2008) encryption if the database is configured to use SSL connections.
- Between the management database and the Audit Manager console, data can be secured using Secure Socket Layer (SSL) connections and ARC4 (Windows 2003) or AES (Windows 2008) encryption if the database is configured to use SSL connections.
The following illustration summarizes the flow of data and how network traffic is secured from one component to the next.
Enabling Secure Socket Layer (SSL) communication
Although the database connections can be secured using SSL, you must configure SSL support for Microsoft SQL Server as part of SQL Server administration. You must also have valid certificates installed on clients and the database server. If you are not the database administrator, you should contact the database administrator to determine whether encryption has been enabled and appropriate certificates have been installed. For more information about enabling SSL encryption for SQL Server and installing the required certificates, see the following Microsoft support article:
Enabling encryption for Microsoft SQL Server Express
To enable encryption for each audit store and management database:
- Log on to the computer hosting an audit store or management database with an account that has database administrator authority.
- Open SQL Server Configuration Manager.
- Select the SQL Server Network Configuration node, right-click Protocols for DBINSTANCE, then select Properties.
- On the Flags tab, select Yes for the Force Encryption option, then click OK to save the setting.
Using a service account for Microsoft SQL Server
When you install Microsoft SQL Server, you specify whether to use Windows authentication or a mix of Windows and SQL Server authentication. You also specify the accounts that the database services should use. By default, system accounts are used. If SQL Server uses a domain user account instead of a system account, you should ensure that the account has permission to update the SQL Server computer object in Active Directory. If the account has permission to update the computer where SQL Server is running, SQL Server can publish its service principal name (SPN) automatically. Getting the correct service principal name is important because Windows authentication relies on the SPN to find services and DirectManage Audit uses Windows authentication for console-to-audit management database connections. If the SPN is not found, the connection between the console and audit management database fails.
The audit management database-to-audit store connection and the collector-to-audit store connection can use either Windows authentication or SQL Server authentication. If SQL Server authentication is used, it does not matter whether the SQL Server instance uses a system account or a service account. If you have configured SQL Server to use Windows authentication only, be sure that the Windows account is allowed to connect to the audit management database and to the audit store database.