External S-TAP is a proxy-based monitoring option that runs on a Kubernetes or Docker container. The External S-TAP sits between the end user and the database service. All external access to the database service is routed through the External S-TAP to the collector where it determines if the data needs to be logged or not. This is the closest option to the traditional S-TAP because it also captures transactions as they occur on the network and can analyze the traffic as it is happening.
- The configuration does not rely on someone with elevated/privileged access who could modify the monitoring capability
- Analyzes traffic and enforces actions in real-time, like logging, ignoring, blocking, and redacting
- Does not have an impact on the database or server performance
- Cannot monitor local database activity because it sits external to the S-TAP
- Deployment complexity can be high, requiring additional components, including a load balancer and a Kubernetes/Docker cluster
- Can introduce network latency due to the interception and mirroring of the activity in transit
The next two options, Universal Connector and Event Streams can send database activity events to a Guardium Data Protection Collector or Guardium Insights. They both rely on native logging and send the events in batch jobs. Which one to use is largely based on what is available or preferred by your cloud team.
Universal Connectors are plugins, that run on Docker containers. Integration consists of three Logstash Plugins: Input, Filter, and Output. The Input Plugin is responsible for communicating with the data source to either pull or receive events. Once the event is received, the Filter Plugin parses the event and transforms the data into the desired format. The Output Plugin then sends the event to the sniffer, which handles the mapping and logging. Universal Connectors rely on native audit logging to capture the desired events and can be created by IBM, Business Partners such as Converge, and even customers.
- Open-source flexibility and availability allow for quicker delivery for systems not supported by traditional S-TAP agents
- Enabling native audit logging can have potential system or database performance impact
- Activity detail is limited by what is available through the native logging capabilities, which may lack the detail required for compliance
- Any user with system-level or elevated access can disable or change the logging configuration, reducing or removing visibility into database activity
Event Streams utilize native cloud platform options like AWS Kinesis and Azure Event Hubs to capture the events. The events are received via a pull mechanism through APIs. Due to the event formatting events (typically JSON), parsing of the event isn’t required. The events are directly ingested and mapped through the sniffer process.
- Does not require any additional components to be managed by the Guardium administrator
- Easy to enable and configure by simply providing connection details
- Same Cons as mentioned for the Universal Connector, plus:
- Potential cloud costs for storing or transferring (external) of the logs
- Limited availability and support
Traditional S-TAPs are almost always the best option for data monitoring as they are minimally impactful, offer advanced capabilities, and allow for the separation of duties. In scenarios where an agent-based solution isn’t available, please consider all of the factors when determining the best alternative monitoring option for your environment.
I hope this blog helps to demystify the agentless options and assists you in your monitoring journey. Should you have additional questions or require any assistance, please reach out to the Converge Guardium Services team to inquire how we can help.