Feature Introduction
PolarDB-X now supports a new tri-role authorization mode, enabling you to allocate the broad privileges of high-level accounts among three specialized roles: system administrator, security administrator, and audit administrator. This approach prevents the risks associated with concentrated power by spreading out permissions, thereby bolstering the security of your database.
Risks and Solutions
Risks
In traditional database maintenance, database administrators (DBAs) wield extensive and centralized powers, which can lead to business vulnerabilities in certain situations:
DBAs making errors in judgement that result in system security breaches.
DBAs engaging in unauthorized activities for various reasons.
DBAs, outsourced third-party personnel, or developers exceeding their access and reaching sensitive data.
Solutions
PolarDB-X's new tri-role authorization model reforms the standard operational structure, which previously allowed DBAs to operate with unchecked privileges. This model clearly delineates the duties among database administrators (DBAs), security administrators (DSAs), and audit administrators (DAAs). Specifically:
Database Administrators (DBAs): Are restricted to DDL (Data Definition Language) capabilities.
Security Administrators (DSAs): Are limited to managing roles or users and can assign permissions to other accounts.
Audit Administrators (DAAs): Are solely authorized to review audit logs.
Database System Account Permissions Comparison
The table below illustrates the differences in permissions between various database system accounts under the default and tri-role authorization modes.
Note
The default mode's high-level account equates to the system administrator account. For an in-depth understanding of high-level accounts, please see Account Types.
Toggling the tri-role authorization mode on or off affects only system accounts (high-level, system administrator, security administrator, and audit administrator accounts) and doesn't alter the permissions of standard accounts.
Within the tri-role authorization mode, even though all system accounts lack DML (Data Manipulation Language), DQL (Data Query Language), and DAL (Data Administration Language) permissions, the security administrator retains the ability to grant these permissions to regular accounts.
The checkmark (✔️) in the table signifies that permission is granted, while the cross (❌) denotes it is not.
Category | Explanation | Default Mode (High-Level Account) | Tri-Role Authorization Mode (System Administrator Account) | Tri-Role Authorization Mode (Security Administrator Account) | Tri-Role Authorization Mode (Audit Administrator Account) |
---|---|---|---|---|---|
DDL | ALTER TABLE CREATE TABLE CREATE VIEW CREATE INDEX CREATE CCL_RULE DROP VIEW DROP INDEX DROP TABLE * TRUNCATE TABLE | ✔️ | ✔️ | ❌ | ❌ |
DML | DELETE UPDATE * INSERT | ✔️ | ❌ | ❌ | ❌ |
DQL | SELECT EXPLAIN | ✔️ | ❌ | ❌ | ❌ |
DAL | SHOW CCL_RULE SHOW INDEX | ✔️ | ❌ | ❌ | ❌ |
Account or Role Related | Account Permission Management Role Permission Management | ✔️ | ❌ | ✔️ | ❌ |
View Audit Logs | Access audit log information from the following two tables: information_schema.polardbx_audit_log information_schema.polardbx_ddl_log |
✔️ | ❌ | ❌ | ✔️ |
Usage Limitations
The system accounts within the tri-role authorization mode—including system administrator, security administrator, and audit administrator accounts—are subject to these limitations:
The execution of GRANT ROLE or REVOKE ROLE commands on system accounts is not permitted.
The execution of GRANT PRIVILEGES or REVOKE PRIVILEGES commands on system accounts is not allowed.
System account passwords can only be changed by the corresponding account itself, meaning only the system administrator can modify the system administrator account's password, and not by any other account.
System accounts do not have the ability to use the SET DEFAULT ROLE command.