Data Management (DMS) allows you to configure security rules on the Access apply tab of the Security Rules tab to validate applications for permissions, including permissions on database instances, databases, and tables.
Background information
DMS provides a domain-specific language (DSL) to describe security rules. You can specify risk levels based on your business requirements. Then, you can specify different approval processes for applications for permissions on objects at different risk levels. For example, you can configure security rules to validate applications for permissions on database instances in different ways. For more information about the basic syntax, see DSL syntax for security rules.
Prerequisites
You are a DMS administrator, a database administrator (DBA), or a security administrator.
Basic configuration items
On the Access apply tab, eight basic configuration items are provided:
- [Instance-permission application] default approval Template: By default, this approval template takes effect if you do not specify different approval processes for instance permission applications at different risk levels under the Validation for Instance Permission Application checkpoint. In the Change Configuration Item dialog box, you can click Switch Approval Template and change the approval process of the default approval template. For more information, see the "Modify the default approval template" section of the Data change topic.
- [DB-permission application] default approval Template: By default, this approval template takes effect if you do not specify different approval processes for database permission applications at different risk levels under the Database Permission Application Validation checkpoint.
- Table-permission request default approval Template: By default, this approval template takes effect if you do not specify different approval processes for table permission applications at different risk levels under the Table Permission Application Validation checkpoint.
- [Programmable object-permission application] default approval Template: By default, this approval template takes effect if you do not specify different approval processes for programmable object permission applications at different risk levels under the Programmable object verification checkpoint.
- [Field-permission application] default approval Template: By default, this approval template takes effect if you do not specify different approval processes for sensitive field permission applications at different risk levels under the Sensitive Field Application Validation checkpoint.
- Line-permission application default approval Template: By default, this approval template takes effect if you do not specify different approval processes for row permission applications at different risk levels under the Line permission application verification checkpoint.
- [Owner-application] default approval template (when the resource has no Owner): By default, this approval template takes effect if you do not specify different approval processes for data ownership applications at different risk levels under the Owner Application Validation checkpoint and the data involved in the application has no owner.
- [Owner-application] default approval template (when the resource has an Owner): By default, this approval template takes effect if you do not specify different approval processes for data ownership applications at different risk levels under the Owner Application Validation checkpoint and the data involved in the application has one or more owners.
Checkpoints
When you submit a ticket to apply for permissions, DMS checks whether the ticket conforms to rules that are specified under checkpoints. The ticket can be submitted only after DMS determines that the ticket conforms to all rules that are specified under checkpoints. On the Access apply tab, seven checkpoints are supported:
- Owner Application Validation: allows you to specify approval processes or constraints for Instances-OWNER, Table-OWNER, and Database-OWNER tickets.
- Validation for Instance Permission Application: allows you to specify approval processes or constraints for Instances-Performance and Instances-Login tickets.
- Database Permission Application Validation: allows you to specify approval processes or constraints for Database-Permission tickets.
- Table Permission Application Validation: allows you to specify approval processes or constraints for Table-Permission tickets.
- Programmable object verification: allows you to specify approval processes or constraints for Programmable Object tickets.
- Sensitive Field Application Validation: allows you to specify approval processes or constraints for Sensitive Column-Permission tickets.
- Line permission application verification: allows you to specify approval processes or constraints for Row-Permission tickets.
Factors and actions
-
A factor is a predefined variable in DMS. You can use factors to obtain the context to be validated by security rules. The context includes SQL statement categories and database names. A factor name consists of the prefix
@fac.
and the display name of the variable. Each tab of the Security Rules tab provides different factors for different checkpoints. The following table describes the factors that are provided for the checkpoints on the Access apply tab.Factor Description @fac.env_type The type of the environment. The value is the display name of the environment type, such as DEV
orPRODUCT
. For more information, see Change the environment type of an instance.@fac.schema_name The name of the database. @fac.perm_apply_duration The period of time during which the requested permissions are valid. Unit: hours. @fac.column_security_level The security level of the field. Valid values: - sensitive
- confidential
- inner
@fac.perm_type The types of the requested permissions. A list of strings is returned, such as ['CORRECT','EXPORT']. Valid values:- QUERY
- EXPORT
- CORRECT
- LOGIN
- PERF
The @fac.perm_type factor can be used together with the @fun.listEqualIgnoreOrder function to evaluate the types of the requested permissions in a ticket. For example, the @fun.listEqualIgnoreOrder(@fac.perm_type, ['QUERY']) function is used to evaluate whether only the query permissions are requested.
-
An action in a security rule is an operation that DMS performs when the IF condition in the rule is met. For example, DMS can forbid the submission of a ticket, select an approval process, approve a ticket, or reject a ticket. An action in a security rule shows the purpose of the security rule. An action name consists of the prefix
@act.
and the display name of the operation. Each tab of the Security Rules tab provides different actions for different checkpoints. The following table describes the actions that are provided for the checkpoints on the Access apply tab.Action Description @act.forbid_submit_order Forbids a ticket from being submitted. @act.do_not_approve Specifies the ID of an approval template. For more information, see Configure approval processes. @act.choose_approve_template @act.choose_approve_template_with_reason
Security rule templates
DMS provides you with a large number of predefined security rule templates. You can use the templates or modify the templates based on your business requirements. The following table describes the security rule templates that are provided on the Access apply tab.
Checkpoint | Template feature |
---|---|
Owner Application Validation | Specifies that applications for the ownership of data in the production environment are not allowed. |
Specifies that applications for the ownership of data are not allowed. | |
Specifies that no approval is required for applications for the ownership of data in the test environment. | |
Database Permission Application Validation | Specifies that applications for permissions on databases are not allowed. |
Specifies that applications for permissions on databases in the production environment are not allowed. | |
Specifies that no approval is required for applications for permissions on databases in the test environment. | |
Table Permission Application Validation | Specifies that applications for permissions on tables are not allowed. |
Specifies that applications for permissions on tables in the production environment are not allowed. | |
Specifies that no approval is required for applications for permissions on tables in the test environment. | |
Programmable object verification | Specifies that applications for permissions on programmable objects are not allowed. |
Specifies that applications for permissions on programmable objects in the production environment are not allowed. | |
Specifies that no approval is required for applications for permissions on programmable objects in the test environment. | |
Sensitive Field Application Validation | Specifies that applications for permissions on sensitive fields are not allowed. |
Specifies an approval process for applications for permissions on confidential fields. | |
Line permission application verification | Specifies that applications for permissions on rows are not allowed. |
Specifies that applications for permissions on rows in the production environment are not allowed. | |
Specifies an approval process for applications for permissions on rows. |