All Products
Search
Document Center

Security rule

Last Updated: Dec 11, 2019
  • The security rule management module involves the following three core concepts:
    • Approval node, approval process, and security rule

Approval node

  • The system provides the following default dynamic nodes, which cannot be deleted or edited:

    • Admin: the system administrator. If the system has multiple administrators, any of them can participate in an approval process.
    • DBA: the database administrator of an instance, which is the administrator or DBA who registers the instance by default or can be assigned to another DBA role in the system.
    • Owner: the data owner of a database. The data owner of a database or table can be configured by the DBA when the DBA registers an instance and collects the data dictionary. In addition, the original data owner of a database or table can configure another user as the new data owner. A user can also request to become the data owner of a database or table.
  • The system also supports custom approval nodes, which can be deleted and edited as required.

    • You can customize approval nodes and their approvers apart from the default nodes of the system. Common custom nodes are as follows:
      • Test engineer
      • Data security engineer
      • R&D TL
      • Architect
      • ....
    • Note: You can even specify a specific business stakeholder, such as a tester or R&D TL of a specific business, as an approval node.

Approval process

  • The system provides the following default dynamic approval processes, which cannot be deleted or edited:
    • Admin only: A ticket only needs to be approved by the administrator.
    • DBA only: A ticket only needs to be approved by the DBA.
    • Owner only: A ticket only needs to be approved by the data owner.
    • Owner-->DBA: A ticket needs to be approved by the data owner and DBA in turn.
    • Owner-->DBA-->Admin: A ticket needs to be approved by the data owner, DBA, and administrator in turn.
  • The system also supports custom approval processes, which can be deleted and edited as required.
    • You can combine dynamic nodes of the system with manually customized approval nodes to customize an approval process. Common custom approval processes are as follows:
      • Owner-->Data security engineer: A ticket needs to be approved by the data owner and data security engineer in turn.
      • Owner-->Test engineer: A ticket needs to be approved by the data owner and test engineer in turn.
      • ...
    • Note: You can use any combination of various approval nodes to form an approval process for a specific business based on your business needs.

Security rule

  • By default, the system provides three levels of security rules: high, medium, and low. The rules can be refined to a specific operation of a specific module. For more information, see the help documentation. This section lists the control capabilities supported by specific modules. The default security rules cannot be deleted or edited.
    • You can control the following items related to the SQLConsole:
      • Whether to allow running DML statements (You can set a threshold for the number of affected rows. If the threshold is exceeded, DML statements cannot be run.)
      • Whether to allow running DDL statements (You can set a threshold for the table size. If the threshold is exceeded, DDL statements cannot be run.)
      • Whether to allow running high-risk DDL statements (such as deleting tables or fields)
      • Whether to allow running other SQL statements
    • You can control the following items related to data changes:
      • Whether to allow running DML statements (You can set a threshold for the number of affected rows. If the threshold is exceeded, DML statements cannot be run.)
        • If so, you can specify whether an approval process is required and what approval process is required.
      • Whether to allow running DDL statements (You can set a threshold for the table size. If the threshold is exceeded, DDL statements cannot be run.)
        • If so, you can specify whether an approval process is required and what approval process is required.
      • Whether to allow running high-risk DDL statements (such as deleting tables or fields)
        • If so, you can specify whether an approval process is required and what approval process is required.
      • Whether to allow running other SQL statements
        • If so, you can specify whether an approval process is required and what approval process is required.
    • You can control the following items related to data export:
      • Whether an approval is required for exporting data
        • If so, you can set a threshold for the number of rows exported each time.
          • Based on different thresholds, you can specify whether an approval process is required and what approval process is required.
        • When the data to be exported involves sensitive data, you can customize an approval process and set it as the most rigorous process that remains effective regardless of how many rows are exported.
    • You can control the following items related to permission application:
      • Application for permissions on databases, tables, or columns
        • Whether an approval process is required and what approval process is required:
          • Permissions on databases or tables
          • Permissions on sensitive columns
          • Permissions on confidential columns
      • Application for assuming the data owner role
        • Whether an approval process is required and what approval process is required:
          • Approval process when a data owner already exists
          • Approval process when no data owner exists
    • You can control the following items related to sensitivity levels (upgrading from a low level to a high level takes effect immediately):
      • Whether an approval process is required and what approval process is required:
        • Degrade from confidential to sensitive
        • Degrade from confidential to internal
        • Degrade from sensitive to internal
  • The system also supports custom security rules, which can be deleted and edited as required.
    • You can use a combination of multiple approval processes to configure security rules that meet the requirements of a specific business. In this way, you can implement flexible management and operation audit from the business dimension.
    • Note: An instance is associated with a security rule. With security rules, you can achieve flexible and on-demand business management. Depending on your business needs, you can even strictly control the test environment but loosely control the production environment of the back-end system.