Informix Database Security Audit

The Informix dynamic server provides two levels of access privileges to ensure the security of the database. Database privileges Control access to the database and the right to create tables and cable indexes on the database. The privileges of the table specify what actions the user can perform on a particular table.

Informix Dynamic servers support table-level modifications, insert and delete security, while enhancing column-level updates and query security. The detach privilege statement is used to grant the user the appropriate privileges to access the base level, or to reclaim privileges. Because INFORMX security is at the user level, there is no need for a separate database login.

Stored procedures provide additional security by establishing their own, as distinct from the permissions of the database. The owner of the stored procedure grants the user permission to execute the stored procedure, allowing the user to perform all SQL operations in the stored procedure, but restricting other database access. Database administrators can improve the security of a system by using stored procedures to limit the user's actions to perform certain databases.

Security audits

The security audit capabilities provided by the Informix Dynamic server provide tracking and operational records for each database object used to operate. This function conforms to the C2 level security requirements model proposed by the National Computer Security Center of the United States.

With the help of Informix dynamic servers, you can selectively monitor the activities of users in the system. The interface for security audits is either command-line-driven or parameter-controlled, which allows you to specify the monitoring of specific activities for a particular user.

Security audits can create event records that users are active in the database to check for unusual or suspicious database activity.

The events that can be logged are:

A successful or failed operation. You can record only successful operations, or record only failed operations, or both.

The connection to the online system. You can record the connection to the online system, including who built the connection, and at what point

System and database management events. Any administrative events such as adding dbspaces and chunks, archiving, empowering, recycling permissions, or the current transaction log can be audited.

Database and table operations. Select,insert,update, or DELETE statements can be audited, but the operations of one table are not allowed to be audited.

How the Audit works

The administrator first creates the audit masks (the audit mask), and a audit masks is like a filter that checks whether the user's activity should be audited. The audit masks is stored in the Sysaudit table of the Sysmaster database.

If the database operation is performed and the operation is within the scope of the audit, online automatically inserts a record in the audit log. The audit log is a UNIX file that holds audit records. This file may become very large, mainly looking at the number of operations included in the audit masks and the type of operation.

A separate user mask (user mask) can be available for each of the database users. In addition, the administrator can set a default mask so that users who do not have user mask can use this default mask.