Try OpenEdge Now
skip to main content
Programming Interfaces
Data Management : Auditing : Developing auditing tools : Custom audit configuration tools : Accessing the audit policy tables
 
Accessing the audit policy tables
You can write your own tools to perform same functions supported by the Audit Policy Maintenance tool. To do so, you must:
*Write the ABL code to query and update audit policy tables in a given audit-enabled database.
*Use methods of the AUDIT-POLICY system handle to manage the effect of any changes to existing auditing policy settings.
The following tables store the basic audit policy settings for an audit-enabled database:
*_aud-event — Defines the supported audit events. Each OpenEdge-defined event has a unique event ID (_Event-id field value) with a value less than 32000. All application-defined events must also have a unique event ID with a value of 32000 or greater.
*_aud-audit-policy — Provides a mechanism to define named audit policies configured according to different policy requirements.
*_aud-event-policy — Defines policy settings for audit events of a specific named audit policy, and specifies such information as if the audit event is enabled and the level of audit detail to be recorded.
*_aud-field-policy — Optionally, defines any field-level policy settings for a specific named audit policy. Fields without settings inherit any settings for the table, if any, and are disabled from auditing otherwise.
*_aud-file-policy — Optionally, defines any table-level policy settings for a specific named audit policy. Tables without settings are disabled from auditing.
In addition to these principle audit policy tables, the following tables provide information about auditing and security features of a given OpenEdge RDBMS. You do not typically change these tables for Audit Policy Maintenance activities, but they might be useful for reference purposes:
*_db — Provides standard metaschema information in an OpenEdge RDBMS, including a global unique identifier (GUID) that is used to uniquely identify the database in audit data aggregated from multiple databases.
*_db-option — Provides an extensible means to define criteria for handling various database management options, including auditing and security. OpenEdge provides such options for managing auditing and general database security identities and permissions.
*_db-detail — Stores auditing-specific information about a database, including the message authentication code (MAC) key used to secure and seal audit data, depending on the audit data security level (an audit policy setting).
For more information on these tables, see the sections on audit policies and data in OpenEdge Getting Started: Core Business Services - Security and Auditing.
In order to allow audit policy changes to occur without taking an audit-enabled database off line, ABL provides a mechanism to inform the database server that audit policy changes have occurred so it can refresh its audit policy settings. You can do this using the REFRESH-AUDIT-POLICY( ) method on the AUDIT-POLICY system handle. By invoking this method for a specified database, the OpenEdge RDBMS can immediately use the latest changes to audit policies in order to process and record audit events.