SECURITY LABEL Clause
The GRANT SECURITY LABEL statement grants a security label to a user or to a list of users.
Element | Description | Restrictions | Syntax |
---|---|---|---|
label | Name of an existing security label | Must exist as a label for the specified security policy | Identifier |
policy | The security policy of this label | Must already exist in the database | Identifier |
user | User to whom the label is to be granted | Must be the authorization identifier of a user | Owner name |
Only a user who holds the DBSECADM role can issue the GRANT SECURITY LABEL statement.
A security label is a database object that is always associated with a security policy. That policy defines the set of valid security components that make up the security label. The label stores a set of one or more values for each component of the security policy.
- A column of a database table, which a column security label can protect
- A row of a database table, which a row security label can protect
- A user, whose user security label (and any exemptions from rules of the security policy that have been granted to the user) are called the security credentials of the user.
When a user who holds a security label for a specific security policy attempts to access a row that is protected by a row security label of the same security policy, the database server compares the sets of values in the user security label and in the row security label to determine whether the user should be allowed access to the data. Similarly, LBAC takes into account the user security label and the column security label in determining whether the credentials of the user should allow access to the protected column.
The GRANT SECURITY LABEL statement is the mechanism by which DBSECADM associates a user with a security label. (Data values in a protected table are associated with a row security label or with a column security label by options to the CREATE TABLE or ALTER TABLE statements that only DBSECADM can execute, rather than by the GRANT SECURITY LABEL statement.)
The USER keyword that can follow the TO keyword is optional, and has no effect, but any authorization identifier specified in the GRANT SECURITY LABEL statement must be the identifier of an individual user, rather than of a role.