For example, auditing a specific user would have less impact than auditing all activities by all users. The actual impact is known to depend on three key factors. In fact, since it is the database system that is generating and writing audit records to storage, this extra processing interferes directly with core database processing such as query execution. While the diminished security of native loggings may be acceptable to some clients depending on their risk tolerance, the impact on performance requires careful consideration. In this case, the DAM solution is simply an after the fact consumer of the audit records.
Additionally, native logging approaches do not permit the DAM solution to do any kind of enforcement whether on the database access side or the database response side. This lack of SoD makes it harder to adhere to zero-trust security.
#Agent activity audit full#
Unlike agent-based approaches, native logging does not ensure SoD because the audit capability is still within the full control of the DBA. Figure 2 gives a high-level overview of the native logging approach in IBM Security Guardium.įigure 2: Native Logging approach in IBM Security Guardium Typically, the database system would store these logs in a set of files on the database server. Then, the DAM solution typically leverages a set of APIs to retrieve those audit records from the location where the database system has stored them. These audit records are then written to storage either synchronously or asynchronously depending on the audit policy enabled. This causes the audit processing component of the database system to start generating audit records for database activities. In native logging approaches, the DAM solution would first enable the native auditing capability of the database system. This property keeps the monitoring overhead on database performance to a minimum, typically in the low single digits. Similarly, a policy can be specified to have the agent redact sensitive data in a query result set that is destined to an unauthorized user.Īdditionally, an agent-based approach is not affected by the type of workload running on the database (e.g., OLTP, Warehousing) because it operates within the operating system and independently of the database system.
For example, a policy can be specified to have the agent block the DBA from retrieving data from a sensitive table. Additionally, an agent-based approach provides the opportunity to extend the SoD property to enforcement as well. This SoD is critical for adhering to zero-trust security because it does not rely on the database system and the DBA to monitor themselves. Figure 1 gives a high-level overview of the agent-based approach (labeled as STAP) in IBM Security Guardium.įigure 1: Agent-based approach in IBM Security GuardiumĪn agent-based approach ensures Separation of Duties (SoD) between the DAM administrator and the DBA. In other words, the agent-based approach enables database activity monitoring independently of the database system and the database administrator (DBA). As such, the agent is able to see all requests coming into the database as well as all responses going out of the database. This is typically a kernel module which extends the host operating system.
#Agent activity audit software#
In the agent-based approach, a software agent is deployed on the database server. The goal of this paper is to describe and contrast both approaches to help clients make well-informed decisions when adopting one approach or another. While native database auditing may be a reasonable alternative when deploying an agent is not feasible, adopting this approach otherwise requires careful considerations. Thus, DAM solutions turned to native database auditing as an alternative to acquire the data they need for compliance reporting, analytics and other capabilities. Unfortunately, this traditional approach did not carry over to cloud database services because clients do not have access to the underlying operating system in order to deploy such agents. Traditionally, DAM solutions have provided this visibility independently of the database system by deploying a software agent on the database server. The emergence of cloud database services has driven several Database Activity Monitoring (DAM) solutions to enable and consume native database auditing in order to provide visibility into user activities.
0 kommentar(er)
