View and Manage Alert Policies
You can view and perform management tasks with alert policies.
Create and Manage Custom Alert Policies
Expand the capabilities of Data Safe Alerts by creating custom alert policies.
Related Topics
Create a Custom Alert Policy From the All Activity Audit Report
You can leverage the convenience of Audit reports to create custom alert policy. Apply the filters in the All Activity report to narrow down the conditions for alerting and create a new custom alert policy based on the filtered conditions.
To create a custom alert policy:
- Under Security center, click Activity auditing.
- Under Related resources, click Audit reports.
- Select the All activity report from the list.
- Use basic or advanced filtering to filter the all
activity report as desired for the alert policy.
Tip:
Don't create filters that only apply to specific target databases or times as this will cause errors when creating the policy.See the Alert condition supported fields table below for the list of valid fields.
See Basic Filtering in an Audit Report and Advanced Filtering in an Audit Report for more information.
- Click Create as alert rule to use the currently applied filters as the conditions for a custom alert.
- Select Create an alert policy.
- Fill in the following required fields:
Field Name Description Policy name Display name of the alert policy you're creating. Compartment The compartment where the alert policy will be created. Alert policies can be applied to target databases regardless of the compartment. You will associate the alert policy to the target database in a later step. See Associate and Apply Alert Policies to Target Databases for more information.
Severity Critical, High, Medium, or Low The designated severity level will be visible if an alert is generated.
Rule name Display name of the alert rule. A rule defines the logic that will cause the alert to trigger. An alert policy can have up to five custom rules. You can only create one rule in this workflow, but you can create more in a later step. See Add an Alert Rule to an Existing Alert Policy From Activity Auditing or Manage the Alert Rules of an Existing Alert Policy Manually for more information.
Rule expression SCIM query This will show the System for Cross-Domain Identity Management (SCIM) syntax for the filters you applied earlier and defines the logic for your custom alert. You can use Copy rule from an existing alert policy to copy the SCIM syntax from a single existing policy.
See Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM) for more information.
- Click Submit.
Table 5-1 Alert condition supported fields
Field | Description |
---|---|
Audit type
(auditType) |
The type of auditing:
STANDARD , FINE_GRAINED ,
XS , DATABASE_VAULT ,
LABEL_SECURITY , RMAN ,
DATAPUMP , DIRECT_PATH_API
|
Client host
(clientHostname) |
The host name of the client application that was the source of the event causing the alert. |
Client ID
(clientId) |
The client identifier in each Oracle session. |
Client IP
(clientIp) |
The IP address of the client application that was the source of the event causing the alert. |
Client program
(clientProgram) |
The application from which the audit event was generated. For example SQL Plus or SQL Developer. |
DB user
(dbUserName) |
The name of the database user whose actions were audited. |
Error code
(errorCode) |
Oracle Error code generated by the action. Zero indicates the action was successful. |
Error message
(errorMessage) |
The detailed message on why the error occurred. |
Event
(eventName) |
The name of the event executed by the
user on the target database. For example ALTER
SEQUENCE , CREATE TRIGGER , or
CREATE INDEX .
|
External user
(externalUserId) |
The user ID of the external user of the audit event. |
Location
(auditLocation) |
The location of the audit. Currently the value is audit table. |
Object(objectName) |
Name of the object on the database
affected by the action, for example, a table name, file name, or a
directory name. Must be in upper case, for example,
ALTER_TABLE .
|
Object owner
(objectOwner) |
The schema name of the object affected by the action. |
Object type
(objectType) |
Type of object in the source database
affected by the action. For example PL/SQL ,
SYNONYM , or PACKAGE
BODY .
|
Operation
(operation) |
The name of the action executed by the
user on the target database. For example ALTER ,
CREATE , or DROP .
|
Operation status
(operationStatus) |
Status of the event: Success or
Failure |
OS user
(osUserName) |
The name of the operating system user for the database session. |
Terminal
(osTerminal) |
The operating system terminal of the user session. |
Unified audit policies
(auditPolicies) |
List of audit policies that caused the current audit event. |
Create a Custom Alert Policy Manually
You can use System for Cross-Domain Identity Management (SCIM) syntax to create custom alert policies. Existing alert policies can be used as the basis for a custom alert policy and further customized using SCIM.
- Under Security center, click Alerts.
- Under Related resources, click Alert policies.
- Click Create alert policy.
- Fill in the following required
fields:
Field Name Description Policy name Display name of the alert policy you're creating. Compartment The compartment where the alert policy will be created. Alert policies can be applied to target databases regardless of the compartment. You will associate the alert policy to the target database in a later step. See Associate and Apply Alert Policies to Target Databases for more information.
Severity Critical, High, Medium, or Low The designated severity level will be visible if an alert is generated.
Rule name Display name of the alert rule. A rule defines the logic that will cause the alert to trigger. An alert policy can have up to five custom rules. You can only create one rule in this workflow, but you can create more in a later step. See Add an Alert Rule to an Existing Alert Policy From Activity Auditing or Manage the Alert Rules of an Existing Alert Policy Manually for more information.
Rule expression SCIM query Use System for Cross-Domain Identity Management (SCIM) syntax to create the logic that will cause the alert to trigger. You can use Copy rule from an existing alert policy to copy the SCIM syntax from a single existing policy.
Tip:
Don't create rules that only apply to specific target databases or times as this will cause errors.See the Alert condition supported fields table below for the list of valid fields.
See Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM) for more information.
- Click Submit.
Table 5-2 Alert condition supported fields
Field | Description |
---|---|
Audit type
(auditType) |
The type of auditing:
STANDARD , FINE_GRAINED ,
XS , DATABASE_VAULT ,
LABEL_SECURITY , RMAN ,
DATAPUMP , DIRECT_PATH_API
|
Client host
(clientHostname) |
The host name of the client application that was the source of the event causing the alert. |
Client ID
(clientId) |
The client identifier in each Oracle session. |
Client IP
(clientIp) |
The IP address of the client application that was the source of the event causing the alert. |
Client program
(clientProgram) |
The application from which the audit event was generated. For example SQL Plus or SQL Developer. |
DB user
(dbUserName) |
The name of the database user whose actions were audited. |
Error code
(errorCode) |
Oracle Error code generated by the action. Zero indicates the action was successful. |
Error message
(errorMessage) |
The detailed message on why the error occurred. |
Event
(eventName) |
The name of the event executed by the
user on the target database. For example ALTER
SEQUENCE , CREATE TRIGGER , or
CREATE INDEX .
|
External user
(externalUserId) |
The user ID of the external user of the audit event. |
Location
(auditLocation) |
The location of the audit. Currently the value is audit table. |
Object(objectName) |
Name of the object on the database
affected by the action, for example, a table name, file name, or a
directory name. Must be in upper case, for example,
ALTER_TABLE .
|
Object owner
(objectOwner) |
The schema name of the object affected by the action. |
Object type
(objectType) |
Type of object in the source database
affected by the action. For example PL/SQL ,
SYNONYM , or PACKAGE
BODY .
|
Operation
(operation) |
The name of the action executed by the
user on the target database. For example ALTER ,
CREATE , or DROP .
|
Operation status
(operationStatus) |
Status of the event: Success or
Failure |
OS user
(osUserName) |
The name of the operating system user for the database session. |
Terminal
(osTerminal) |
The operating system terminal of the user session. |
Unified audit policies
(auditPolicies) |
List of audit policies that caused the current audit event. |
Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM)
Use the following information to use SCIM to create custom alert policies.
Supported SCIM Operators
Rule expression creation uses System for Cross-Domain Identity Management (SCIM) syntax and supported operators include:
co
: matches resources with an attribute that contains a given stringeq
: matches resources with an attribute that is equal to a given value (not case sensitive)eq_cs
: matches resources with an attribute that is equal to a given value (case sensitive)ew
: matches resources with an attribute that ends with a given stringge
: matches resources with an attribute that is greater than or equal to a given valuegt
: matches resources with an attribute that is greater than a given valuein
: matches resources with an attribute that is equal to any of given values in listle
: matches resources with an attribute that is less than or equal to a given valuelt
: matches resources with an attribute that is less than a given valuene
: matches resources with an attribute that is not equal to a given valuenot_in
: matches resources with an attribute that is not equal to any of given values in listpr
: matches resources with an attribute if it has a given valuesw
: matches resources with an attribute that starts with a given string
Tips for Using SCIM
- Pressing the escape key while defining the rule expression will clear the whole query and close the create alert policy workflow.
- Pressing the space key will display the drop down with the list of available attributes or operators.
- Pressing the space key after entering a value
like
objectName (demo_obj)
will enclose the string with quotes:("demo_obj")
. - Pressing enter will close the drop down listing the operators and attribute names.
- If a value like SQL Firewall policy name has
spaces in it, typing space will enclose the first word within quotes,
"policy name"
. You will have to move the cursor back to the enclosed string and continue typing the rest of the string value.
For more information about SCIM, see the protocol documentation at https://www.rfceditor.org/rfc/rfc7644.
For more information about filtering in SCIM, see the filtering section of the protocol documentation at https://www.rfc-editor.org/rfc/rfc7644#section-3.4.2.2.
Add an Alert Rule to an Existing Alert Policy From Activity Auditing
After applying filters to the All activity report in Activity Auditing, you can add a rule to an existing custom alert policy based on the filters.
- Under Security center, click Activity auditing.
- Under Related resources, click Audit reports.
- Select the All activity report from the list.
- Use basic or advanced filtering to filter the all activity
report as desired for the alert policy.
Tip:
Don't create filters that only apply to specific target databases or times as this will cause errors when creating the rule.See the Alert condition supported fields table below for the list of valid fields.
See Basic Filtering in an Audit Report and Advanced Filtering in an Audit Report for more information.
- Click Create as alert rule to use the currently applied filters as the conditions for a custom alert.
- Select Create as alert rule to use
the currently applied filters as the conditions for an additional
rule of an existing alert policy.
An alert policy can have up to five alert rules. The policy will trigger if any of the rules are met.
- Fill in the following required fields:
Field Name Description Compartment Select the compartment where the alert policy you're adding the rule to is stored. Policy name Select the name of the alert policy. The list is populated based on the compartment that is selected. Rule name Display name of the alert rule. A rule defines the logic that will cause the alert to trigger. An alert policy can have up to five custom rules. You can only create one rule in this workflow, but you can create more in a later step. See Add an Alert Rule to an Existing Alert Policy From Activity Auditing or Manage the Alert Rules of an Existing Alert Policy Manually for more information.
Rule expression SCIM query This will show the System for Cross-Domain Identity Management (SCIM) syntax for the filters you applied earlier and defines the logic for your custom alert. You can use Copy rule from an existing alert policy to copy the SCIM syntax from a single existing policy.
See Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM) for more information.
- Click Submit.
Table 5-3 Alert condition supported fields
Field | Description |
---|---|
Audit type
(auditType) |
The type of auditing:
STANDARD , FINE_GRAINED ,
XS , DATABASE_VAULT ,
LABEL_SECURITY , RMAN ,
DATAPUMP , DIRECT_PATH_API
|
Client host
(clientHostname) |
The host name of the client application that was the source of the event causing the alert. |
Client ID
(clientId) |
The client identifier in each Oracle session. |
Client IP
(clientIp) |
The IP address of the client application that was the source of the event causing the alert. |
Client program
(clientProgram) |
The application from which the audit event was generated. For example SQL Plus or SQL Developer. |
DB user
(dbUserName) |
The name of the database user whose actions were audited. |
Error code
(errorCode) |
Oracle Error code generated by the action. Zero indicates the action was successful. |
Error message
(errorMessage) |
The detailed message on why the error occurred. |
Event
(eventName) |
The name of the event executed by the
user on the target database. For example ALTER
SEQUENCE , CREATE TRIGGER , or
CREATE INDEX .
|
External user
(externalUserId) |
The user ID of the external user of the audit event. |
Location
(auditLocation) |
The location of the audit. Currently the value is audit table. |
Object(objectName) |
Name of the object on the database
affected by the action, for example, a table name, file name, or a
directory name. Must be in upper case, for example,
ALTER_TABLE .
|
Object owner
(objectOwner) |
The schema name of the object affected by the action. |
Object type
(objectType) |
Type of object in the source database
affected by the action. For example PL/SQL ,
SYNONYM , or PACKAGE
BODY .
|
Operation
(operation) |
The name of the action executed by the
user on the target database. For example ALTER ,
CREATE , or DROP .
|
Operation status
(operationStatus) |
Status of the event: Success or
Failure |
OS user
(osUserName) |
The name of the operating system user for the database session. |
Terminal
(osTerminal) |
The operating system terminal of the user session. |
Unified audit policies
(auditPolicies) |
List of audit policies that caused the current audit event. |
Manage the Alert Rules of an Existing Alert Policy Manually
After creating a custom alert policy you can add up to four additional custom alert rules, up to five rules total, to an existing custom alert policy. An alert will be triggered if any of the alert rules are met.
- Under Security center, click Alerts.
- Under Related resources, click Alert policies.
- Click the Custom alert policies tab.
- Select the custom alert policy you'd like mange the alert rules for.
- You can perform the following tasks:
- Click Add rule to add a new rule. Enter
the required fields as described in Table 5-4.
An alert policy can have up to five alert rules. The policy will trigger if any of the rules are met
- Select an existing rule and then Edit rule to edit it. Enter the required fields as described in Table 5-4.
- Select an existing rule and then Delete rule to delete it.
- Click Add rule to add a new rule. Enter
the required fields as described in Table 5-4.
Table 5-4 Fields
Field | Description |
---|---|
Rule name | Display name of the alert rule. A rule defines the logic that will cause the alert to trigger.An alert policy can have up to five custom rules. |
Rule expression SCIM query | Use System for
Cross-Domain Identity Management (SCIM) syntax to create the
logic that will cause the alert to trigger.
You can use Copy rule from an existing alert policy to copy the SCIM syntax from a single existing policy. Tip: Don't create rules that only apply to specific target databases or times as this will cause errors.See the Alert condition supported fields table below for the list of valid fields. See Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM) for more information. |
Table 5-5 Alert condition supported fields
Field | Description |
---|---|
Audit type
(auditType) |
The type of auditing:
STANDARD , FINE_GRAINED ,
XS , DATABASE_VAULT ,
LABEL_SECURITY , RMAN ,
DATAPUMP , DIRECT_PATH_API
|
Client host
(clientHostname) |
The host name of the client application that was the source of the event causing the alert. |
Client ID
(clientId) |
The client identifier in each Oracle session. |
Client IP
(clientIp) |
The IP address of the client application that was the source of the event causing the alert. |
Client program
(clientProgram) |
The application from which the audit event was generated. For example SQL Plus or SQL Developer. |
DB user
(dbUserName) |
The name of the database user whose actions were audited. |
Error code
(errorCode) |
Oracle Error code generated by the action. Zero indicates the action was successful. |
Error message
(errorMessage) |
The detailed message on why the error occurred. |
Event
(eventName) |
The name of the event executed by the
user on the target database. For example ALTER
SEQUENCE , CREATE TRIGGER , or
CREATE INDEX .
|
External user
(externalUserId) |
The user ID of the external user of the audit event. |
Location
(auditLocation) |
The location of the audit. Currently the value is audit table. |
Object(objectName) |
Name of the object on the database
affected by the action, for example, a table name, file name, or a
directory name. Must be in upper case, for example,
ALTER_TABLE .
|
Object owner
(objectOwner) |
The schema name of the object affected by the action. |
Object type
(objectType) |
Type of object in the source database
affected by the action. For example PL/SQL ,
SYNONYM , or PACKAGE
BODY .
|
Operation
(operation) |
The name of the action executed by the
user on the target database. For example ALTER ,
CREATE , or DROP .
|
Operation status
(operationStatus) |
Status of the event: Success or
Failure |
OS user
(osUserName) |
The name of the operating system user for the database session. |
Terminal
(osTerminal) |
The operating system terminal of the user session. |
Unified audit policies
(auditPolicies) |
List of audit policies that caused the current audit event. |
Details for an Oracle Data Safe Alert Policy
Oracle Data Safe provides the following information for each Oracle predefined alert policy:
- Policy name
- Severity level of the alert policy; for example, CRITICAL
- Type of alert policy - Currently, all policies are based on auditing.
- Oracle Cloud Identifier (OCID) - You can view and copy this OCID.
- Target databases on which the alert policy is applied
- Rule expression - For example, the expression for the Profile Changes
alert policy is
((operation eq_cs "CREATE" OR operation eq_cs "ALTER" OR operation eq_cs "DROP") AND objectType eq_cs "PROFILE")
Associate and Apply Alert Policies to Target Databases
You can associate and enable alert policies on target databases from the Target-Policy Associations page (recommended) or the Alert Policy Details page. On the Target-Policy page, you can view all alert policies associated with and enabled on each target database. The Apply Policy action associates and enables alert policies in one step.
View Alert Policies Associated with a Target Database
You can view the alert policies associated with a target database from the Target-Policy Associations page. It's useful to apply filters on the page to quickly locate a target database.
Enable or Disable Alert Policies on a Target Database
You can quickly disable an alert policy on a target database from the Target-Policy Associations page.