| Oracle® Label Security Administrator's Guide 10g Release 1 (10.1) Part Number B1 0774-01 |
|
|
View PDF |
The Oracle9i audit facility lets you hold database users accountable for the operations they perform. It ca n track specific database objects, operations, users, and privileges. Oracle Label Security supplements this by tracking use of its o wn administrative operations and policy privileges. It provides the SA_AUDIT_ADMIN package to set and change the policy auditing opti ons.
This chapter explains how to use Oracle Label Security auditing. It contains these top ics:
Oracle Label Security auditing supplements standard Oracle9i auditing by tracking use of its own administrative operations, and use of the policy privileges. You can use either the SA_AUDIT_ADMIN package o r Oracle Policy Manager to set and change the auditing options for an Oracle Label Security policy.
When you create a new policy, a label column for that policy is added to the database audit trail. The label column is creat ed regardless of whether auditing is enabled or disabled, and independent of whether database auditing or operating system auditing i s used. Whenever a record is written to the audit table, each policy provides a label for that record to indicate the session label. The administrator can create audit views to display these labels. Note that in the audit table, the label does not control access to the row; instead, it simply records the sensitivity of the row.
The auditing options that y ou specify apply only to subsequent sessions, not to the current session. You can specify audit options even if auditing is disabled; no overhead is created simply by making these specifications. When you do enable Oracle Label Security auditing, the options come in to effect, and overhead is created beyond that created by standard Oracle9i auditing.
< /a>Note that Oracle Label Security does not provide labels for audit data written to the operating system audit trial . All Oracle Label Security audit records are written directly to the database audit trail, even if operating system auditing is enab led. If auditing is disabled, then no Oracle Label Security audit records are generated.
For Oracle Label Security to generate audit records, y ou must first enable systemwide auditing by setting the Oracle9i AUDIT_TRAIL initialization parameter in the database's parameter file. The parameter can be set to one of the following values:
After you have edited the parameter file, restart the database instance to enable or disable d atabase auditing as specified.
Set the AUDIT_TRAIL parameter before you set audit options. If you do not set this parameter, you are still able to set audit options. However, audit records are not written to the database unt il the parameter is set and the database instance is restarted.
| See Also:
For information about enabling and disabl ing systemwide auditing, setting audit options, and managing the audit trail, see Oracle Database Administrator's Guide For informat ion about editing initialization parameters, see Oracle Database Reference For details about systemwide AUDIT and NOAUDIT functionin g, see Oracle Database SQL Reference |
After you have enabled systemwide auditing, you can use SA_AUDIT_ADMIN procedures to enable or disable Oracle Label Security audi ting. To use Oracle Label Security auditing, you must have the policy_type role.
Use the AUDIT procedure to enable policy-specific auditing.
Syntax:
P ROCEDURE AUDIT ( policy_name IN VARCHAR2, users IN VARCHAR2 DEFAU LT NULL, option IN VARCHAR2 DEFAULT NULL, type IN VARCHAR2 DEFAULT NULL, success IN VARCHAR2 DEFAULT NULL);
| Parameter | Description | Default Behavior | < /thead>
|---|---|---|
|
policy_name |
Required. Specifies the name of an exis ting policy. Auditing of each policy is independent of all others.) |
None |
|
users |
Optional. A comma-delimited list of use r names to audit. If not specified, all users are audited. |
All us ers |
|
option |
Optional. A comma-delimited list of option s to be audited. See Table 11-2. If not specified, all default options (that is, options not including privileges) are audited. Audit options for privileged operations should be set explic itly by specifying the PRIVILEGES option, which sets audit options for all privileges. |
All options |
|
type |
Optional. BY ACCESS or BY SESSION. If not specified, audit records are written by session. |
BY SESSION |
|
success |
Optional. SUCCESSFUL or NOT SUCCESSFUL. If not specified, audit is written for both. |
SUCCESSFUL and NOT SUCCESSFUL |
If the admini strator does not specify any audit options, then all options except the privilege-related ones are audited. Auditing of privileges mu st be specified explicitly. For example, if the administrator enters
SA_AUDIT_ADMIN.AUDIT ( 'HR');
then default auditing options are set for the HR policy. W hen the administrator enables auditing, it will be performed on all users by session, whether successful or not.
When you set auditing parameters and options, the new values apply only to subsequent sessions, not to the curr ent session.
Consider also a case in which one AUDIT call (with no users specified) enables auditing for APPLY operations for all users, and then a second call enables auditing of REMOVE operations for a specific user. For e xample:
SA_AUDIT_ADMIN.AUDIT ('HR', NULL, 'APPLY'); SA_AUDIT_ADMIN.AU DIT ('HR', 'SCOTT', 'REMOVE');
In this case, SCOTT is audited for both APPLY and REMOVE operations.
To disable policy-specific auditing, use the SA_AUDIT_ADMIN.NOAUDIT procedure.
Syntax:
PROCEDURE NOAUDIT ( policy_name IN VARCHAR2, users IN VARCHAR2 DEFAULT NULL, option IN VARCHAR2 DEFAULT NULL);
| Parameter< /font> | Description | < font face="Arial, Helvetica, sans-serif">Default Behavior |
|---|---|---|
|
policy_name |
Required. Specifies the name of an existing policy. |
None |
|
users |
Op tional. A comma-delimited list of user names to audit. If not specified, auditing is disabled for all users. |
All users |
|
option |
Optional. A comma-delimited list of options to be disabled. See Table 11-2. If not speci fied, all default options are disabled. Privileges must be disabled explicitly. |
All options |
You can disable auditing for all enabl ed options, or only for a subset of enabled options. All auditing for the specified options is disabled for all specified users (or a ll users, if the users parameter is NULL). For example, the following statement disables auditing of the APPL Y and REMOVE operations for users John, Mary, and Scott:
SA_AUDIT_ADMIN.NOAUDIT ('HR', 'JOH N, MARY, SCOTT', 'APPLY, REMOVE');
Consider also a case in which one AUDIT call enables auditing for a specific user, and a second call (with no user specified) enables auditing for all users. For e xample:
SA_AUDIT_ADMIN.AUDIT ('HR', 'SCOTT'); SA_AUDIT_ADMIN.AUDIT (' HR');
In this case, a subsequent call to NOAUDIT with no users sp ecified (such as the following)
SA_AUDIT_ADMIN.NOAUDIT ('HR');
does not reverse the auditing that was set for SCOTT explicitly in the first call. Auditing t hus continues to be performed on SCOTT. In this way, even if NOAUDIT is set for all users, Oracle Label Security still audits any use rs for whom auditing was explicitly set.
Auditing of privileged operations must be specifie d explicitly. If you execute NOAUDIT with no options, Oracle Label Security will nonetheless continue to audit privileged operations. For example, if auditing is enabled and you enter
SA_AUDIT_ADMIN.NOAUDIT ('HR');
then auditing will continue to be performed on the privileged operations ( such as WRITEDOWN).
NOAUDIT parameters and options that you set apply only to subsequent se ssions, not to current sessions.
If you try to enable an audit option that has already been set, or if you try to disable an audit option that has not been set, Oracle Label Security processes the statement without indicatin g an error. An attempt to specify an invalid option results in an error message.
< h3 class="H2">Examining Audit Options with the DBA_SA_AUDIT_OPTIONS ViewThis section describes the view that displays the Oracle Label Securit y auditing options and privileges.
The DBA_SA_AUDIT_OPTIONS view contains the following col umns:
POLICY_NAME
NOT NULL
VARCHAR2(30)
USER_NAME
td>NOT NULL
VARCHAR2(30)
APY
VARCHAR2(3 )
REM
VARCHAR2(3)
SET_
VARCHAR2(3)
PRV
VARCHAR2(30
Output is similar to the following:
| POLICY_NAME | USER_NAME | APY | REM th> | |
PRV |
|---|---|---|---|---|---|
|
HR |
SCOTT |
-/- |
-/- |
-/- |
A/A |
|
HR |
LBACSYS |
S/S p> |
S/S |
S/S |
-/- |
| See Also:
Cha pter 11 of the Oracle Database Security Guide |
This section de scribes procedures available to manage policy label auditing:
Use the AUDIT_LABEL procedure to recor d policy labels during auditing. It causes the user's session label to be stored in the audit table.
Syntax:
PROCEDURE AUDIT_LABEL ( < /a> policy_name IN VARCHAR2);
| Parameter | Description | Default |
|---|---|---|
|
policy_name |
Required. Specifies the name of an existing policy. |
None |
Use the NOAUDIT_LABEL procedure to disable auditing of policy labels.
Syntax:
PROCEDURE NOAUDIT_LABEL (
policy_name IN VARCHAR2);
| Parameter | Description | Default |
|---|---|---|
|
policy_name |
Required. Specifies the name of an existing policy. |
None |
Use the AUDIT_LABEL_ENABLED function to show whether lab els are being recorded in audit records for the policy.
Syntax:
FUNCTION AUDIT_LABEL_ENABLED (policy_name IN VARCHAR2)
RETURN
boolean;
This section contains these topics:
The CREATE_VIEW procedure creates an audit trail view named DBA_policyname_AUDIT_TRAIL, which contains the specified policy's label column as well as all the entries in the audit trail written on behalf of this policy. If the view name exceeds the database limit of 30 characters, the user can optionally specify a shorter view name.
Syntax:
PROCEDURE CREAT
E_VIEW (
policy_name IN VARCHAR2);
view_name IN VARCHAR2 DEFAULT N
ULL);
where policy_name specifies the nam e of an existing policy
The D ROP_VIEW procedure drops the audit trail view for the specified policy.
Syntax:
PROCEDURE DROP_VIEW (
policy_name IN VARC
HAR2);
view_name IN VARCHAR2 DEFAULT NULL);
where policy_name specifies the name of a policy. View_name is an opti onal parameter that can have a maximum of 14 characters.
This section contains th ese topics:
Before setting a ny audit options, you must devise an auditing strategy that monitors events of interest, without recording extraneous events. You sho uld periodically review this strategy, because applications, user base, configurations, and other external factors can change.
The Oracle Label Security options, and those provided by the Oracle9i aud it facility, might not directly address all of your specific or application-dependent auditing requirements. However, through use of database triggers, you can audit specific events and record specific information that you cannot audit and record using the more gene ric audit facility.
| See Also:
For more information about using triggers for auditing, see Oracle Database Concepts |
Consider auditing any operations that require Oracle Label Sec urity privileges. Because these privileges perform sensitive operations, and because their abuse could jeopardize security, you shoul d closely monitor their dissemination and use.