View and Manage Alert Policies

Create and Manage Custom Alert Policies

Expand the capabilities of Data Safe Alerts by creating custom alert policies.

Related Topics

Throttled Alerts

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 Data Safe - Database Security, select Activity auditing.
Under Activity auditing, select 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.
Under the Actions menu, select 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 Create.

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.

To create a custom alert policy:

Under Data Safe - Database Security, select Alerts.
Under Alerts, select 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 Create.

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 string
eq: 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 string
ge: matches resources with an attribute that is greater than or equal to a given value
gt: matches resources with an attribute that is greater than a given value
in: matches resources with an attribute that is equal to any of given values in list
le: matches resources with an attribute that is less than or equal to a given value
lt: matches resources with an attribute that is less than a given value
ne: matches resources with an attribute that is not equal to a given value
not_in : matches resources with an attribute that is not equal to any of given values in list
pr: matches resources with an attribute if it has a given value
sw: matches resources with an attribute that starts with a given string

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 Data Safe - Database Security, select Activity auditing.
Under Activity auditing, select 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.
Under the Actions menu, select 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 Create.

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 Data Safe - Database Security, select Alerts.
Under Alerts, select 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:
- In the Alert rules tab, 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
- In the Alert rules tab, on the row for an existing rule click ... and then Edit to edit it. Enter the required fields as described in Table 5-4.
- In the Alert rules tab, on the row for an existing rule click ... and then Delete to delete it.

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.

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")

View the List of Available Alert Policies

Under Data Safe - Database Security, select Alerts.
Under Alerts, select Alert policies.
The list of alert policies is displayed. For each policy, you can view its severity level and description.

View Details for an Alert Policy

Under Data Safe - Database Security, select Alerts.
Under Alerts, select Alert policies.
Select either the Oracle predefined alert policies or Custom alert policies tab.
Click the name of the alert policy for which you want to view more information.
The Alert Policy Details page is displayed.
On the Details tab, view the details for the alert policy.
On the Alert rules tab, view the alert rules associated with the policy.
You will also see:
- Rule key: This is a unique identifier that is automatically generated by Data Safe when a rule is created. It is unique across all rules and policies and can be used in filters in other areas of Data Safe.
- Alerts: This shows the number of alerts that this rule has triggered.

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.

Under Data Safe - Database Security, select Alerts.
Under Alerts, select Target policy associations. The Target-Policy Associations page is displayed.
Click Apply policy. The Apply and enable alert policy to target databases panel is displayed.
Select the target databases for which you want to apply the alert policies.

Note:
Currently, you can apply alert policies to a maximum of ten target databases at one time.
- If needed, click Change Compartment and select the compartment that contains your target databases. One at a time from the drop-down list, select target databases. To select target databases in a different compartment, click Add Row. In the new row, click Change Compartment and select a different compartment. One at a time from the drop-down list, select target databases.
Select the alert policies.
Click Apply policy.
The alert policies are applied while the panel is open.
Wait until the message Apply "Profile Changes" on <target database names> is displayed and has the status Done.
Click Close.
Refresh the Target-Policy Associations page to view the new associations.
The target databases have the alert policies enabled by default.

View Target Databases on Which an Alert Policy is Applied

Under Data Safe - Database Security, select Alerts.
Under Alerts, select Alert policies.
Select an alert policy from the list. The Alert Policy Details page is displayed.
Next to Policy applied on target databases, click View List to view the list of target databases on which the alert policy is applied.
The Target-Policy Associations page is displayed. The Policy Name filter is automatically set to the alert policy name. If the alert policy isn't applied to any target databases, the message No items to display is displayed.

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.

Under Data Safe - Database Security, select Alerts.
Under Alerts, select Target policy associations.
You will see a table of target-policy associations. There is a row for each association. For example, if your target database is associated with two alert policies, there are two rows in the table.
Under the Actions menu, use Add filter to filter by a particular target database to determine which policies are applied to it.

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.

Under Data Safe - Database Security, select Alerts.
Under Alerts, select Target policy associations.
The Target-Policy Associations page is displayed.
Use filters to narrow down the targets and/or policies.
In the table, select the check box for the rows that pertain to the target database and alert policy(ies) that you want to enable or disable.
From the Actions menu, select Enable policy or Disable policy.
An Enable policy or Disable policy dialog box prompts you to confirm.
Click Yes.

Move a Target-Policy Association

You can move a target-policy association resource to a different compartment.

Under Data Safe - Database Security, select Alerts.
Under Alerts, select Target policy associations.
Use filters to narrow down the table of target-policy associations.
In the table, locate the row that contains the target-policy association that you want to move, and then click the name of your target database.
The Target-policy associations details page is displayed.
Under the Actions menu, select Move resource.
The Move resource dialog box is displayed.
Select a compartment, and then click Move resource.
The target-policy association is immediately moved to the selected compartment.

Delete a Target-Policy Association

Under Data Safe - Database Security, select Alerts.
Under Alerts, select Target policy associations.
The Target-Policy Associations page is displayed.
Use filters to narrow down the table of target-policy associations.
On the right in the row that pertains to your alert policy and target database, click the target database name.
The Target-Policy Associations Details page is displayed.
Under the Actions menu, select Delete.
The target-policy association is deleted.