Imperva Cyber Community

Keeping up with new audit requirements and database monitoring needs requires solutions for handling far higher agent deployments.

At its core, database activity monitoring (DAM) is a concept as simple as it is powerful. 

The DAM agent is registered to a database server and assigned to a specific gateway. It then monitors and analyzes database activity independently of the database management system.

This allows for improved database performance while complying with regulatory systems like the PCI DDS, The HIPAA Act, or Sarbanes-Oxley. It also protects sensitive databases from external attacks by providing privileged, database-independent monitoring access, enabling comprehensive audits without compromising computing resources.

But audit requirements are changing, and the needs of customer DAM deployments are becoming more complex. A single DAM deployment with a single agent is easy to support on most networks, but a complex deployment with more than 100 individual agents will quickly overwhelm that deployment.

This is where DAM Cluster deployments come in. By allowing multiple gateways to work together and support large numbers of agents, DAM Clusters allow for scalable, secure agent management even with large DAM deployment loads.

How the DAM Cluster Works

There are two types of DAM Cluster:

• Standard Clusters. In the standard arrangement, every single agent monitors a volume of server load sufficient for a single SecureSphere gateway to handle all of the agent traffic. There are more agents than gateways, and every gateway can have multiple agents assigned to it.

• Large Server Clusters. When a single agent produces so much traffic for the gateway that a single SecureSphere instance cannot perform, the best solution is to distribute the traffic-generating agent among multiple gateways. In this arrangement, gateways outnumber agents, and every gateway can have a maximum of one agent assigned to it. This arrangement allows organisations to scale up their DAM capabilities without necessarily upgrading their gateway model.

Registering an agent to a DAM Cluster is slightly different than the legacy procedure. Every agent is actually assigned to a cluster manager. The cluster manager then decides with gateway within the cluster will be assigned to the agent.

The cluster manager acts on information sent by each gateway in the cluster. It continuously manages the load of each gateway and ensures that agents are efficiently distributed.

At the same time, Imperva Administrators are able to manually move agents between gateways. Users can zoom in and configure individual gateways and individual agents as needed. The cluster-based framework reflects the performance of the system as a whole.

This way, if a user makes changes to an individual gateway or agent, the cluster deployment will immediately reflect the impact those changes have on the entire system. Gateways can now be placed, maintained, and reported on with or without time-consuming micromanagement for every single agent-gateway relationship.

Advantages to Using a DAM Cluster

DAM Clusters are designed to streamline the most time-consuming parts of database activity monitoring deployment and maintenance. Beyond the functional benefits of Imperva’s DAM Cluster framework, DAM Cluster users can capitalize on the following benefits:

• Automatic Agent Assignment. DAM Cluster administrators assign agents to clusters – not gateways. The cluster assigns each agent automatically from there. In a Standard Cluster, the agent is assigned to the single gateway with the least load. In a Large Serve Cluster, the agent is distributed between several gateways according to its load. A single script can register any number of agents to any single cluster in one go.

• Load-Oriented Agent Assignment. Clusters assign agents to gateways based on their load. This load is calculated based on how much traffic the agent is likely to send to the gateway – estimated by multiplying the number of cores on the protected system by 100. The cluster will automatically assign each agent to a gateway with enough capacity to carry that load. If there isn’t enough capacity, the agent remains unassigned until capacity is added or new gateways are introduced.

• Improved Gateway Capacity Management. Adding new gateways to a DAM Cluster is easy to do. Adding gateways to clusters will allow the cluster to quickly assign any unassigned agents to the new gateways, distributing their load evenly in the process.

• Load Balancing Capabilities. Users who aren’t happy with the automatic gateway load calculation can balance that calculation manually. Users can move agents from one gateway to another, manually change agent load estimates, and change individual gateway capacity.

• Simple Cluster Redundancy. Users can use a single redundant gateway to provide redundancy to other gateways in the cluster.

• Automatic Gateway Failure Recovery. DAM Clusters automatically backup agent data. If a gateway fails, the potential data loss is not significant, nor will users have to manually fill-in missing details.

Clusters vs. Gateways: Operational Differences

Because clusters and gateways are so closely related, it can be easy to confuse gateway architecture and cluster architecture. Gateways do not necessarily share their operational qualities and attributes with clusters.

For instance, every gateway inside a cluster must be in passive monitoring (sniffing) mode. At the same time, data interfaces are used for agent traffic. This differs from gateway architecture, which receives incoming traffic through a passive monitoring interface.

There are a variety of other operational differences that users will have to pay attention to. Every agent and gateway in a single cluster must share the same password. All gateways and agents in a single cluster must share connectivity in order to preserve proper cluster topology, which must fall into one of the following categories:

• One network interface controller for the management server, agents, and cluster.
• One network interface controller for the management server and the agents, and another network interface controller for the cluster.
• One network interface controller for the management server and the cluster, and another network interface controller for the agents (this connectivity scheme is the recommended option).

Learn More About Imperva DAM Cluster Administration With the Imperva Community