Security rules are defined, by using a domain-specific language (DSL), to control user operations on different types of databases in various aspects, such as syntax and the number of affected rows. You can use security rules to standardize database operations, R&D processes, and approval processes as needed. This topic describes how and when to use the security rules feature in Data Management Service (DMS).
- The target instance is managed in the Secure Collaboration mode. You can customize security rules only for instances in the Secure Collaboration control mode. All instances in this control mode can be associated with appropriate security rules as needed.
Security rules for instances in the Flexible Management and Stable Change control modes are defined by DMS and cannot be modified.
- Security rules are ready to use. For more information, see DSL syntax for security rules.
- Log on to the DMS console.
- In the top navigation bar, choose System Management > Instance. The Instance List tab appears.
- Select multiple target instances and click Batch edit.
You can select multiple instances of the same database type at a time.
- In the Edit instance information in batches dialog box that appears, select Control Mode and then select Security Collaboration from the drop-down list.
- From the Security Rules drop-down list, select the security rule set that you want to apply to this instance.
- Log on to the DMS console.
- In the left-side navigation pane, right-click the target instance, choose Control Mode > Security Collaboration, and then select the security rule set that you want to apply to the instance.
|To change data in databases, the staff in your enterprise may still be using email or other instant messaging (IM) services to advance approval processes. Consequently, they are in dire need of an online process-based management system.|| |
|You need to control the database R&D process to ensure schema consistency across multiple environments. For example, before a newly designed schema can be published to the production environment, it needs to be verified in the development environment, debugged in the debugging environment, and verified again in the staging environment.|
|You need to establish guidelines for schema design. For example, you need to make sure that each newly created table has a primary key and only nullable fields can be added to an existing table.|
|You want to forbid the execution of certain SQL statements, for example, high-risk statements for deleting data or tables.|
|You want to allow only certain SQL statements, for example, |
|You need to set different approval processes for certain operations on databases. For example, data writing requires no approval, updating 10,000 rows or less requires the approval of the corresponding business manager, and updating more than 10,000 rows requires the approval of both the corresponding business manager and the database administrator (DBA).|
|You need to set different approval processes for granting permissions. For example, permissions can be granted without approval in the test environment, but permissions need to be granted with the approval of the corresponding business manager in the production environment.|