or on combinations of factor that can include user name, application, and time and so on. Security policies can trigger auditing when specified elements in an Oracle database are accessed or altered, including the contents within a specified object.
Auditing is typically used for the following:
- Enabling the future accountability for current actions taken in a particular schema, table, or row, or affecting specific content.
- Deter users or any other person from inappropriate actions based on that accountability.
- Investigate suspicious activity. For example, if some user is deleting data from tables, then the security administrator might decide to audit all connections to the database and all successful and unsuccessful deletions of rows from all tables in the database.
- Notify an auditor that an unauthorized user is manipulating or deleting data and that the user has more privileges than expected which can lead to reassessing user authorizations.
- Monitor and gather data about specific database activities. For example, the database administrator can gather statistics about which tables are being updated, how many logical I/Os are performed, or how many concurrent users connect at peak times.
- Detect problems with authorized or access control implementation. For example, you can create audit policies that you expect will never generate an audit record because the data is protected in other ways. However, if these policies do generate audit records then you will know the other security controls are not properly implemented.
Oracle database audit allows options to be focused or broad, enabling you to audit the following:
- Successful statement executions unsuccessful statement executions or even both.
- Statement executions once each user session or once every time the statement is executed
- Activities of all users or of a specific use
Oracle has various auditing mechanisms they include the following:
Statement Auditing: This is the selective auditing of SQL statements with respect to only the type of statement, not the specific schema objects on which it operates. Statement auditing options are typically broad, auditing the use of several types of related actions for each option. For example, AUDIT TABLE tracks several DDL statements regardless of the table on which they are issued. You can set statement auditing to audit selected users or every user in the database.
Privilege Auditing: The selective auditing of the use of powerful system privileges to perform corresponding actions such as AUDIT CREATE TABLE. Privilege auditing is more focused than statement auditing because it audits only the use of the target privilege. You can set privilege auditing to audit a selected user or every user in the database.
Schema Object Auditing: Enables you to audit specific statements on a particular schema object, such as AUDIT SELECTED ON employees. Schema object auditing is much focused, auditing only a single specified type of statement (such as selected) on a specified schema object. Schema object auditing
- Database Activity Monitoring
- Factors That Would Limit Your Deployment of Data Audit
- Database Audit Appliances