Before you use the always-confidential database feature for an ApsaraDB RDS for MySQL instance, you must configure a data protection rule. ApsaraDB RDS for MySQL allows you to use a configuration file to manage data protection rules. This topic describes how to configure a data protection rule by using SQL statements and how to use the related API operations.
The always-confidential database feature stores the data protection rule that you configured in the system tables of your RDS instance. Only the privileged account or authorized users can write data to the system tables in the RDS instance. The system tables are the mysql.encdb_sensitive_rules and mysql.encdb_auth_users tables.
Prerequisites
The RDS instance runs MySQL 5.7 and a minor engine version of 20231031 or later. The RDS instance runs MySQL 8.0 and a minor engine version of 20240430 or later.
NoteFor more information, see Update the minor engine version.
The always-confidential database feature is enabled. For more information, see Use the always-confidential database feature.
A privileged account is used to configure data protection rules.
Usage notes
After you configure and enable a data protection rule, the rule takes effect on all databases on an RDS instance, and you do not need to repeatedly configure the rule.
We recommend that you use separate database accounts to manage data protection rules and online applications. Do not grant management permissions on online applications unless necessary.
Exercise caution when you grant the read and write permissions on the mysql.encdb_sensitive_rules and mysql.encdb_auth_users tables. The modification of the tables may allow attackers to bypass always-confidential protection.
Operations in SQL UDFs
ADD: adds a rule.
SELECT encdb_rule_op('add',<rule object json string> or <rules list json string>);
Example 1: Add a rule named newrule.
SELECT encdb_rule_op('add','{"name":"newrule","enabled":true,"meta":{"databases":["test"],"tables":["test"],"columns":["a","b"]}}');
Example 2: Add rules named newrule1 and newrule2.
SELECT encdb_rule_op('add','[{"name":"newrule1","enabled":true,"meta":{"databases":["test"],"tables":["test"],"columns":["a","b"]}},{"name":"newrule2","enabled":true,"meta":{"databases":["test2"],"tables":["test2"],"columns":["a","b"]}}]');
UPDATE: updates a rule.
SELECT encdb_rule_op('update',<rule object json string> or <rules list json string>);
Example 1: Update the rule named newrule.
SELECT encdb_rule_op('update','{"name":"newrule","enabled":true,"meta":{"databases":["test"],"tables":["test"],"columns":["a","b"]}}');
Example 2: Update the rules named newrule1 and newrule2.
SELECT encdb_rule_op('update','[{"name":"newrule1","enabled":true,"meta":{"databases":["test"],"tables":["test"],"columns":["a","b"]}},{"name":"newrule2","enabled":true,"meta":{"databases":["test2"],"tables":["test2"],"columns":["a","b"]}}]');
NoteIf the rule that is specified by the
name
parameter exists, the rule is updated. If the rule that is specified by thename
parameter does not exist, the rule is created. In this case, theUPDATE
operation is equivalent to theADD
operation.DELETE: deletes a rule.
SELECT encdb_rule_op('delete',<rule name json string> or <rule name list json string>);
Example 1: Delete the rule named delrule.
SELECT encdb_rule_op('delete','"delrule"');
Example 2: Delete the rules named delrule1 and delrule1.
SELECT encdb_rule_op('delete','["delrule1","delrule2"]');
NoteThe value of the
params
parameter is in the JSON format. When you delete a rule, the rule name must be in the"xxx"
format instead of thexxx
format. For example, the value must be'"delrule"'
instead of'delrule'
.GRANT: grants or revokes permissions.
NoteYou must grant users the required permissions.
Grant or revoke permissions.
SELECT encdb_rule_op('grant',<users object json string>);
Example 1: Grant the appuser and test_user users the permissions to access limited resources.
SELECT encdb_rule_op('grant','{"restrictedAccess": ["appuser","test_user"]}');
Example 2: Revoke the permissions of the illegal user.
SELECT encdb_rule_op('grant','{"noneAccess": ["illegal"]}');
Example 3: Grant the appuser and test_user users the permissions to access limited resources and revoke the permissions of the illegal user.
SELECT encdb_rule_op('grant','{"restrictedAccess": ["appuser","test_user"], "noneAccess": ["illegal"]}');
NoteThe users that are mentioned in this section must exist in the RDS instance.
Grant users full access permissions for temporary use
For ease of use, the always-confidential database feature allows you to grant users the
fullAccess
permission to temporarily maintain plaintext data in an efficient manner. If you grant users the permission, the users can access the plaintext database data of your RDS instance.In this case, the configured data protection rule does not take effect on the users, and the users can directly query the plaintext database data in the RDS instance.
For security purposes, we recommend that you grant the permissions for a short period of time and grant the permissions only if necessary. Before you grant the fullAccess permission, you must understand your business requirements and take responsibilities for the related risks.
The value of the
expired
parameter must fall in the range of1970-01-02 00:00:01
to2038-01-18 03:14:07
.
Example: Grant the dba user the full access permissions for temporary use
SELECT encdb_rule_op('grant','{"fullAccess": ["dba"], "expired": "2023-08-21 14:21:30"}');