One of the key strengths of DSP is its ability to scan and monitor multiple databases running on multiple database management systems (DBMSs) across multiple platforms (Windows, Unix, etc.). The DSP tool aggregates information from multiple collectors to a secure central server. In some cases the central server/management console also collects information while in other cases it serves merely as a repository for data from collectors.
This creates three options for deployment, depending on organizational requirements:
- Single Server/Appliance: A single server, appliance, or software agent serves as both the sensor/collection point and management console. This mode is typically used for smaller deployments.
- Two-tier Architecture: This option consists of a central management server and remote collection points/sensors. The central server does no direct monitoring, but aggregates information from remote systems, manages policies, and generates alerts. It may also perform assessment functions directly. The remote collectors may use any of the collection techniques.
- Hierarchical Architecture: Collection points/sensors/scanners aggregate to business-level or geographically distributed management servers, which in turn report to an enterprise management server. Hierarchical deployments are best suited for large enterprises, which may have different business unit or geographic needs. They can also be configured to only pass certain kinds of data between the tiers to manage large volumes of information or maintain unit/geographic privacy, and to satisfy policy requirements.
This can be confusing because each server or appliance can manage multiple assessment scanners, network collectors, or agent-based collectors may also perform some monitoring directly. But a typical deployment includes a central management server (or cluster) handling all the management functions, with collectors spread out to handle activity monitoring on the databases.
Blocking architecture options
There are two different ways to block queries, depending on your deployment architecture and choice of collection agents.
- Agent-based Blocking: The software agent is able to directly block queries – the actual technique varies with the vendor’s agent implementation. Agents may block inbound queries, returned results, or both.
- Proxy-based Blocking: Instead of connecting directly to the database, all connections are to a local or network-based proxy (which can be a separate server/appliance or local software). The proxy analyzes queries before passing them to the database, and can block by policy.
We will go into more detail on blocking later in this series, but the important point is that if you want to block, you need to either deploy some sort of software agent or proxy the database connection. Next we will recap the core features of DAM and show the subtle additions to DSP.
Reader interactions
One Reply to “Understanding and Selecting DSP: Technical Architecture”
Regarding the notes on blocking architecture options: As a vendor, the two ways we deliver blocking capabilities are with agents and via transparent, inline bridging. With only one exception, we don’t see other vendors offering the proxy approach to blocking in the market. Some of the advantages of an inline bridge include real-time blocking, the option to “fail open” and minimal changes to data center infrastructure.