Label-based security (LabelSecurity) is a mandatory access control (MAC) policy for MaxCompute projects. LabelSecurity supports column-level access control.

DAC and MAC

Discretionary access control (DAC) allows object owners to manage their objects and determine whether to grant all or some access permissions on the objects to other users. When DAC is used, a user can flexibly grant permissions to others based on business requirements.

MAC is a system-controlled access control policy that constrains the ability of a subject to perform a specific operation on objects.

In MaxCompute, MAC is independent of DAC.

Data sensitivity levels

LabelSecurity uses labels to classify both data and users who want to access data into different levels.

In government agencies and financial institutions, the following four data sensitivity labels are used to classify data: 0 (unclassified), 1 (confidential), 2 (sensitive), and 3 (highly sensitive).

MaxCompute also uses this classification method. Project owners must define standards to classify data into sensitivity levels and users into data access levels. The default sensitivity level of all data is 0, and the default access level of all users is 0.

LabelSecurity provides the following features related to access control on sensitive data:
  • Supports access control on specific columns.
  • Allows project administrators to configure labels for specific columns in a table. A table can be composed of columns with different sensitivity levels.
  • Allows project administrators to configure labels for views. A view can have a different sensitivity level than the base table it corresponds to. By default, a newly created view has a sensitivity level of 0.

Default security policies

By default, the following security policies apply to all the data and users for which labels are configured:
  • No-ReadUp: A user is not allowed to read data whose sensitivity level is higher than the data access level of the user unless the user is explicitly authorized.
  • Trusted-User: A user is allowed to write data of all sensitivity levels. By default, the sensitivity level of new data is 0 (unclassified).
Note
  • In some traditional MAC systems, some other complex security policies can be used to prevent data from being distributed by unauthorized users within a project. For example, the No-WriteDown policy prohibits a user from writing data whose sensitivity level is lower than or equal to the data access level of the user. By default, MaxCompute does not support No-WriteDown because this policy incurs high costs for project administrators to manage data sensitivity levels. However, a project administrator can set the ObjectCreatorHasGrantPermission parameter to false to achieve an effect similar to No-WriteDown.
  • To prevent data from being transmitted across projects, a project administrator can set the projectProtection parameter to true. This way, users can access only data within their projects. This prevents data from being transmitted across projects. For more information, see Project data protection.

By default, LabelSecurity is disabled in a project. Only the project owner can enable this security mechanism. After LabelSecurity is enabled, the preceding default security policies are enforced. To access a data table, a user must be granted the SELECT permission and be assigned the appropriate data access level to read sensitive data in the table.

LabelSecurity-related operations

  • Enable LabelSecurity. The default value of LabelSecurity is false. Only project owners are allowed to perform this operation.
    Set LabelSecurity=true|false; 
  • Configure data access labels for users.
    Only project owners and the Admin role are allowed to perform this operation. number can be set to an integer that ranges from 0 to 9.
    SET LABEL <number> TO [USER|ROLE] <name>;
    Example:
    -- Add an Alibaba Cloud account whose username is yunma. The default data access level of this user is 0.
    ADD USER aliyun$yunma@aliyun.com;
    -- Add RAM user Allen that belongs to Alibaba Cloud account yunma@aliyun.com. 
    ADD USER ram$yunma@aliyun.com:Allen;
    -- Set the data access level of user yunma to 3 so that this user can access data with a sensitivity level of 3 or lower. 
    SET LABEL 3 TO USER aliyun$yunma@aliyun.com; 
    -- Set the data access level of RAM user Allen to 1 so that this RAM user can access data with a sensitivity level of 1 or lower.
    SET LABEL 1 TO USER ram$yunma@aliyun.com:Allen; 
  • Configure sensitivity labels for data.

    Only project owners and the Admin role are allowed to perform this operation. number can be set to an integer that ranges from 0 to 9.

    SET LABEL <number> TO TABLE tablename(column_list);
    Example:
    -- Set the sensitivity level of table t1 to 1.
    SET LABEL 1 TO TABLE t1; 
    -- Set the sensitivity levels of the mobile and addr columns of table t1 to 2.
    SET LABEL 2 TO TABLE t1(mobile, addr); 
    -- Set the sensitivity level of table t1 to 3. After you run the following command, the sensitivity levels of the mobile and addr columns are still 2.
    SET LABEL 3 TO TABLE t1; 
    Note Labels explicitly configured for columns in a table overwrite the labels configured for the table regardless of the sequence in which the labels are configured and the specified sensitivity levels.
  • Explicitly authorize a user to access data whose sensitivity level is higher than the data access level of the user.
    • Authorize a user to access data whose sensitivity level is higher than the data access level of the user. If WITH EXP <days> is not specified, the default validity period of the authorization is 180 days.
      GRANT LABEL <number> ON TABLE <tablename>[(column_list)] TO [USER|ROLE] <name> [WITH EXP <days>];
    • Revoke an authorization.
      REVOKE LABEL ON TABLE <tablename>[(column_list)] FROM [USER|ROLE] <name>;
    • Clear expired authorizations.
      CLEAR EXPIRED GRANTS;
    Example:
    -- Explicitly authorize RAM user Allen to access data with a sensitivity level of 2 or lower in table t1. The validity period of the authorization is one day.
    GRANT LABEL 2 ON TABLE t1 TO USER ram$yunma@aliyun.com:Allen WITH EXP 1; 
    -- Explicitly authorize RAM user Allen to access data with a sensitivity level of 3 or lower in the col1 and col2 columns of table t1. The validity period of the authorization is one day.
    GRANT LABEL 3 ON TABLE t1(col1, col2) TO USER ram$yunma@aliyun.com:Allen WITH EXP 1; 
    -- Revoke the authorizations to RAM user Allen on sensitive data in table t1.
    REVOKE LABEL ON TABLE t1 FROM USER ram$yunma@aliyun.com:Allen; 
    Note After you revoke a table-level authorization, all column-level authorizations for the same user are also revoked.
  • Query sensitive datasets that a specified user can access.
    SHOW LABEL [<level>] GRANTS [FOR USER <username>]; 
    where:
    • FOR USER <username>: specifies a user. If this parameter is not specified, the system queries the sensitive datasets that the current user can access.
    • <level>: specifies a sensitivity level. If this parameter is not specified, the system queries all the sensitive datasets that the user can access. If this parameter is specified, the system queries only the sensitive datasets of the specified sensitivity level.
  • Query users who are authorized to access a specific sensitive data table.
    SHOW LABEL [<level>] GRANTS ON TABLE <tablename>;
  • Query all the column-level authorizations for a specific user on a specific table.
    SHOW LABEL [<level>] GRANTS ON TABLE <tablename> FOR USER <username>;
  • Query the sensitivity levels of all columns in a specific table.
    DESCRIBE <tablename>;
  • Set the sensitivity level of the sensitive data that a package installer can access in a package. Only a package creator is allowed to run this command.
    ALLOW PROJECT <prjName> TO INSTALL PACKAGE <pkgName> [USING LABEL <number>]; 
    where:
    • [USING LABEL <number>]: specifies a sensitivity level. If it is not specified, level 0 is used. That is, the package installer can access only non-sensitive data in the package.
    • For cross-project data access, the sensitivity level specified in this command applies to all users who belong to the same project as the package installer.

Examples for the use of LabelSecurity

  • Authorize users who are not assigned the Admin role in a project to access sensitive columns in a specific table.

    The user_profile table in a project contains sensitive data. This table contains a total number of 100 columns, in which the id_card, credit_card, mobile, user_addr, and birthday columns contain sensitive data. All users have been authorized to perform SELECT operations on the table. The project owner can run the following commands to allow only the user who is assigned the Admin role to access the sensitive data.

    After the commands are successfully run, other users cannot access the sensitive data. To access the sensitive data, they must be authorized by the project owner or the user who is assigned the Admin role.
    -- Enable LabelSecurity.
    set LabelSecurity=true; 
    -- Set the sensitivity levels of the specified columns to 2.
    set label 2 to table user_profile(mobile, user_addr, birthday); 
    -- Set the sensitivity levels of the specified columns to 3.
    set label 3 to table user_profile(id_card, credit_card); 
    Project member Alice submits an application to access the mobile column in table user_profile. The requested validity period is one week. The project administrator can run the following command to authorize Alice to access the data:
    GRANT LABEL 2 ON TABLE user_profile TO USER ALIYUN$alice@aliyun.com WITH EXP 7;
    Note The mobile, user_addr, and birthday columns all have a sensitivity level of 2. After the preceding command is successfully run, Alice can access all the three columns. Excessive authorizations occur in this example. We recommend that project administrators appropriately set sensitivity levels of data columns to avoid excessive authorizations.
  • Prohibit a user who has been authorized to access sensitive data in a table from copying and disseminating the sensitive data within the project.

    In the preceding example, Alice is authorized to access sensitive data with a sensitivity level of 2. The project administrator worries that Alice may copy sensitive data from table user_profile to table user_profile_copy, which is created by Alice. If Alice copies the data to table user_profile_copy and authorizes other users in the project to access this table, the sensitive data may be disseminated within the project. The project administrator must prevent this from happening.

    By default, LabelSecurity allows for WriteDown based on the considerations of the usability and management costs of security policies. Users can write data to the columns with a sensitivity level lower than or equal to their data access level. This issue cannot be resolved. However, the project administrator can run the following commands to allow users to access only data created by themselves and prohibit them from authorizing other users to access the data:
    -- Allow an object creator to perform operations on objects created by themselves.
    SET ObjectCreatorHasAccessPermission=true; 
    -- Prohibit the object creator from authorizing other users to perform operations on the objects.
    SET ObjectCreatorHasGrantPermission=false;