We Put You in Control of Your Data – Database Segmentation

Cygna solutions are designed to put you in control of your data. This post discusses the new database segmentation functionality allowing Cygna Auditor data to be stored on more than one database server for unmatched scalability. Change auditing can generate a lot of data which can make it difficult to find, analyze and retain the events.  Cygna Auditor is designed to overcome these issues in several different ways.

One of the ways to reduce the volume of events is to simply not capture unwanted events in the first place with auditing exclusions.  This feature is described in detail in the Auditing Exclusions section of the Auditing Policies – Cygna Auditor for Active Directory blog article.

Another way is purging.  This allows organizations a more conservative approach to capture all events and then delete unwanted ones at a later point in time.  This minimizes database growth and the number of events being retained while providing a configurable window of time to review the audited activities.  This approach is described in the We Put You In Control Of Your Data – Purging blog article.

The database segmentation functionality gives clients control to manage the performance, residency, retention, and separation of audit data.  This is accomplished through multiple implementations that can connect to each others’ databases in a mesh fashion.  This works the same way as the PBMS database connector that allows Cygna Auditor implementations to view and report against PBMS audit data.  The database segmentation feature uses this same approach by allowing the configuration of database connectors to additional Cygna databases.  This enables the viewing, alerting, and reporting of audit data across multiple Cygna and PBMS databases.

Performance

There are numerous factors that effect database store and retrieval performance.  The available storage, compute, memory, and network resources of the database server where the audit data resides are primary factors of the overall performance.  As the working dataset grows you may reach the limits of one or more of these resources that could result in general slow operation and response time to queries.

Various approaches such as the ones outlined above can be used together to maintain a workable dataset or can also be used in combination with database segmentation.   For example, an organization could implement Cygna Auditor in each of its main datacenters.  This regional approach would put the servers and databases in proximity of the audit event data being collected.  This would also be beneficial if there are slow WAN links between regions.  Database connections can then be defined on each Cygna Auditor server for the implementations in the other datacenters.  This would allow for queries or reports to be defined that would be able to span the data from all implementations while minimizing the dataset on each database.  The upcoming archiving feature also leverages database segmentation capabilities by moving events from a live or production database to an archive one.  This will also allow you to manage the dataset size.  Most queries will likely occur against the live dataset while still allowing you to keep older events on less expensive database servers that are only required for occasional use.  See the following diagram for a regional example with archiving.

 

Residency

Residency can be another use case for database segmentation.  Organizations may have regulatory requirements for data from a particular jurisdiction to be stored in that same jurisdiction.  This would allow for compliance with the applicable laws and regulations while still providing access to the audit data for security and operational needs from other implementations in the environment.

Retention

Database segmentation can also be utilized along with archiving for retention of events.  Regulations or internal policies may dictate that certain information be maintained for an extended period.  Depending on the jurisdictions and verticals, this timeframe can vary.  Segmentation with archiving can be used to move audit data to a different database so the events can be retained as mandated.  Purging can then be used to remove these events once they are no longer required.

Separation

Some organizations may need or want to keep different types of audit data separate.  This could be based on their administrative model.  For example, there may be a group responsible for cloud systems and another for on premises.  Another example could be that the file system and AD teams want their data kept separate.  Other groups in the organization may need visibility into all the systems for overall operations or security.

 

The Cygna Auditor platform is designed to allow organizations to tailor their deployments based on their unique set of requirements.  We have clients of all sizes across many different verticals so there is no one size fits all approach.  The product will work out of the box with a single database but can be extended should the need arise.  Cygna Auditor is the only truly scalable solution that allows you to be in complete control of where and how your audit data is stored.