Monitoring the Database Administrator’s activities

Monitoring the Database Administrator’s activities

Its agree, the DBA is the unrestricted owner of the database. An organization’s most critical information is entirely exposed and controlled by this technologists. This leaves both the DBA, and the entire organization, in a precarious position. On one hand, the DBAs are afraid they will be blamed for any information leak, while on the other hand, the organization is forced to trust a small group of professionals in its technology group.

How do you properly audit database Administrator’s activity?

An answer may be,

Not through database’s native auditing, which fails here because it is fully under the control of the DBAs, who can turn off auditing, clear the audit logs, manipulate an audit record, or even reconfigure auditing to filter their own malicious activity. An ideal audit system is intelligent enough to distinguish database administration accounts, filter out “noise” and irrelevant events, and succinctly illustrate its activities. As well, the system should write audited data to a secure location where even the DBA would not have direct control over the recorded activity.

Another way to mitigate risk is to audit and monitor DBA activities. It is necessary to limit the amount of work a DBA does on a production server.

Others approach can be,

• Provide segregation of duties

• Limit the DBA from disabling the auditing

• Limit the DBA from deleting audit records

• Limit the DBA from changing auditing configuration

Segregation of duties is the key to meaningful security and regulatory compliance. The auditing subsystem must retain integrity, and must not be manipulated by the users it is meant to monitor. The “observer” and the “observed” cannot be the same person.

Auditing level can have several shortcomings. Which can affect over all data base performance?

1. First, since auditing is based in the database, it can detract from the system’s performance. This is especially true when you attempt to record every access to certain data; the constant reading and writing of auditing can result in substantial disk I/O on the database server, creating a bottleneck that significantly slows down database performance.
2. Another disadvantage: space and increasing database size. And this is a costly matter for database.

3. There is no intelligence built into the auditing feature. It takes a significant amount of effort to turn on and off AUDIT for specific activity .This creates a technologist nightmare, as any changes must be configured in live server, wasting time and introducing risk of human error.

4. Oracle Database Auditing includes no logic to detect and highlight malicious activity, nor can this be configured. Database auditing is great at amassing a huge amount of data, but is useless in finding the evidence of malicious activity.