Deploying Auditing Components in an Audit Installation

The multi-tiered architecture of the auditing infrastructure is referred to collectively as a DirectAudit installation. The DirectAudit installation represents a logical object similar to an Active Directory forest or site. It encompasses all of the auditing components you deploy—agents, collectors, audit stores, management database, and consoles—regardless of how they are distributed on your network. The installation also defines the scope of audit data available. All queries and reports are against the audit data contained within the installation boundary.

The most common deployment scenario is to have a single audit installation for an entire organization so that all audit data and management of the audit data is centralized. Within a single installation, you can have components wherever they are needed, as long as you have the appropriate network connections that allow them to communicate with each other. The audit data for the entire installation is available to users who have permission to query and view it using a console. For most organizations, having a single installation is a scalable solution that allows a “separation of duties” security model through the use of audit roles. If you establish a single installation, there will be one Master Auditor role for the entire organization, and that Master Auditor can control the audit data that other users and groups can see or respond to by defining roles that limit access rights and privileges.

However, if you have different lines of business with different audit policies—in different geographic locations, or with different administrative groups—you can configure them as separate audit installations. For example, if you have offices in North America and Hong Kong managed by two different IT teams—IT-US and IT-HK—you might want to create two DirectAudit installations to maintain your existing separation of duties for the ITUS and IT-HK teams.

Planning Where to Install Auditing Components

Before you install Centrify Audit & Monitoring Service, you should develop a basic deployment plan for how you will distribute and manage the components that make up an installation. For example, you should decide how many collectors and audit stores to create and where to put them. You should also consider the network connections required and how many computers you plan to audit. For example, you can have multiple agents using the same set of collectors, but you should keep the collectors within one hop of the agents they serve and within one hop of the audit stores to which they transfer data.

By planning where to install components initially, you can determine the number of collectors you should have for load balancing or redundancy. After the initial deployment, you can add collectors and audit stores whenever and wherever they are needed.

Using Multiple Databases in an Audit Store

Each audit store uses Microsoft SQL Server to provide database services to the audit installation. When you install the first audit store, you configure the database instance you want to use and that database becomes the active database for storing incoming audit data. A single audit store, however, can have several databases attached to it. Attached databases store historical information and respond to queries from the management database. You can use the Audit Manager console to control the databases that are attached to the audit store and to designate which database is active. Only one database can be active in an audit store at any given time.

Although the audit store can use multiple databases, the presentation of session data is not affected. If a session spans two or more databases that are attached to the audit store, the Audit Analyzer console presents the data as a single, unbroken session. For example, if you change the active database during a session, some of the session data is stored in the attached database that is no longer active and some of it stored in the newly activated database, but the session data plays back as a single session to the auditor.

Using Multiple Consoles in an Installation

A single installation always has a single audit management database. In most cases, however, you use more than one console to request data from the audit management database. The two most important consoles in an installation are the Audit Manager console and the Audit Analyzer console.

• As the audit installation owner, you use the Audit Manager console to configure and manage the auditing components in your installation. In most organizations, there is only one Audit Manager console installed.
• Auditors use the Audit Analyzer console to search, retrieve, and play back sessions. The auditor can use predefined queries to find sessions or define new queries. Auditors can also choose whether to share their queries with other auditors or keep them private. In most organizations, there are multiple Audit Analyzer consoles installed.

In addition to the Audit Manager and Audit Analyzer consoles, you can use the Agent Control Panel and the Collector Control Panel to configure and manage agents and collectors.

The following figure shows the architecture of a medium-size installation.