Oracle Database Data Access Security and audit Solution

This is a real customer demand implementation solution. The customer needs to monitor the time periods, users, applications, and access records of some key tables.

The database system is Oracle9.2.0.1. Its audit function can meet this requirement.

Based on the performance pressure of Audit on normal applications, You Need To Set Data Access Audit for a specific period of time.

Detailed monitoring information obtained from audit logs, which applications access tables, and when to access tables. Provides detailed report information.

1. auditing principles

The audit function of Oracle database is used to analyze and manage database access security.

Generally, audit is used as follows:

It can audit the current operations of specific users, tables, or specific rows, or affect specific content.

For example, the user who queries what table or even those records in the table.

Investigate suspicious operations.

For example, if a user is deleting data from some tables, the auditor can use the audit function to audit all database connections, successful or unsuccessful deletion operations.

Inform the unauthorized user of the owner who is operating or deleting the data. The invalid user has too many permissions that are not permitted and can check for permission settings.

Monitors and collects data on special database behaviors.

Checks the implementation of authorization and access control.

For example, you can create an expected audit policy. This audit policy ensures that no audit records are generated in other circumstances. However, if this policy generates an audit record, you can know that other security controls are not implemented correctly.

Audit is generally divided into Statement Audit, permission audit, Object audit, and fine-grained audit.

Among them, the first three categories are standard audits, which are available in all ORACLE database versions. The last one is fine-grained audit, which is available in Versions later than ORACLE9i and is enhanced in 10 Gb.

Statement Auditing can audit specific types of operation statements, or even a series of operations. For example, audit table can audit all DDL statements on the table.

Permission audit can audit the system permissions of related operations. For example, audit create table.

Object auditing can audit clear statements on precise objects, such as audit select on temployees.

Object auditing is more accurate. It can audit the only clear type of statements on an object and act on all users in the database.

Fine-grained audit can audit fine-grained data access and operations based on content. For example, a field value is greater than a value.

In ORACLE10g, we compared the similarities and differences between the two types of audits.

Standard audit must be enabled at the database level with the AUDIT_TRAIL parameter. This parameter is not dynamic. You must restart the database to make it take effect. In contrast, fine-grained audit does not require any parameter modification.

Once set on an object, the standard audit will remain there. To remove it, you must use the NOAUDIT command to delete the audit option. This may be inconvenient because dropping the audit option on a table also discards metadata. However, fine-grained audit can be temporarily disabled and enabled without any metadata loss.

Fine-grained audit can only process four types of statements: SELECT, INSERT, UPDATE, and DELETE. In contrast, regular auditing can process many other statements and permissions, and even session connection and disconnection.

Standard audit only creates one record (by session) per session or one record (by Access) per access object. This resource-consuming method is very important for controlling the space in the audit lead table. Fine-grained auditing does not save the same amount of resources; it runs once each access-making the evidence more powerful.

Through recording clues, standard auditing can be used to detect any interruption attempts. If the attempt fails, an error code will be generated. Fine-grained auditing cannot.

Standard audits can be performed on database tables or OS files. The latter is useful when auditors (not database administrators) are able to access clues. This option protects the integrity of audit trails. However, fine-grained audit logs are only written to the database table FGA_LOG $.

Standard audit can be set for default objects. This feature becomes extremely useful when a table is created at runtime: the default audit option allows audit without the intervention of the database administrator. This is not possible in fine-grained audit. You must create a policy on an existing table. The preceding situation can only happen after the table has been created.

In fine-grained audit, audit is more flexible-only when certain columns are accessed and a specific condition is true. This versatility is convenient when you need to control the growth of clues.

In fine-grained audit, the SQL assignment variable is captured by default. In general audit, you must set the initialization parameter audit_trail to db_extended to enable this function.

Differences in permissions: regular audit requires audit system or statement permissions; fine-grained audit only requires running permissions on the dbms_fga package.

Use the Object audit function as needed. If you want to audit records in a specific table, you can use fine-grained audit.

Here, the Object audit function is used to meet our project requirements.

1 2 Next Page