ALTER SECURITY POLICY statement
The ALTER SECURITY POLICY statement modifies a security policy.
Invocation
This statement can be embedded in an application program or issued interactively. It is an executable statement that can be dynamically prepared only if DYNAMICRULES run behavior is in effect for the package (SQLSTATE 42509).
Authorization
The privileges held by the authorization ID of the statement must include SECADM authority.
Syntax
Description
- security-policy-name
- Specifies the name of the security policy to be altered. The name must identify an existing security policy at the current server (SQLSTATE 42710).
- ADD SECURITY LABEL COMPONENT component-name
- Adds a security label component to the security policy. The same security component must not be specified more than once for the security policy (SQLSTATE 42713). The security policy cannot currently be in use by a table (SQLSTATE 42893).
- OVERRIDE NOT AUTHORIZED WRITE SECURITY LABEL or RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL
- Specifies the action taken when a user is not authorized to write
the explicitly specified security label that is provided in the INSERT
or UPDATE statement issued against a table that is protected with
this security policy. A user's security label and exemption credentials
determine the user's authorization to write an explicitly provided
security label.
- OVERRIDE NOT AUTHORIZED WRITE SECURITY LABEL
- Indicates that the value of the user's security label, rather than the explicitly specified security label, is used for write access during an insert or update operation.
- RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL
- Indicates that the insert or update operation will fail if the user is not authorized to write the explicitly specified security label that is provided in the INSERT or UPDATE statement (SQLSTATE 42519).
- USE GROUP AUTHORIZATION or IGNORE GROUP AUTHORIZATION
- Specifies whether or not security labels and exemptions
granted to groups, directly or indirectly, are considered for any
access attempt.
- USE GROUP AUTHORIZATION
- Indicates that any security labels or exemptions granted to groups, directly or indirectly, are considered.
- IGNORE GROUP AUTHORIZATION
- Indicates that any security labels or exemptions granted to groups are not considered.
- USE ROLE AUTHORIZATION or IGNORE ROLE AUTHORIZATION
- Specifies whether or not security labels and exemptions
granted to roles, directly or indirectly, are considered for any access
attempt.
- USE ROLE AUTHORIZATION
- Indicates that any security labels or exemptions granted to roles, directly or indirectly, are considered.
- IGNORE ROLE AUTHORIZATION
- Indicates that any security labels or exemptions granted to roles are not considered.
Rules
- If a user does not directly hold a security label for write access,
an error is returned in the following situations (SQLSTATE 42519):
- A value for the row security label column is not explicitly provided as part of the SQL statement
- The OVERRIDE NOT AUTHORIZED WRITE SECURITY LABEL option is in effect for the security policy, and the user is not allowed to write a data object with the provided security label
Notes
- New components are logically added at the end of the existing security label definition contained by the modified policy. Existing security labels defined for this security policy are modified to contain the new component as part of their definition with no element in their value for this component.
- Cache invalidation when changing NOT AUTHORIZED WRITE SECURITY LABEL: Changing the NOT AUTHORIZED WRITE SECURITY LABEL to a new value will cause the invalidation of any cached dynamic or static SQL statements that are dependent on any table that is protected by the security policy being altered.
- Because the session authorization ID is the focus authorization ID for label-based access control, security labels granted to groups or to roles that are accessible through groups are eligible for consideration for all types of SQL statements, including static SQL.
- If more than one security label or exemption is available to a
user with associated groups or roles at the time of a read or write
access attempt, those security labels and exemptions will be evaluated
for eligibility based on the following rules:
- If the security policy enables only role authorizations for consideration, all security labels and exemptions granted to roles of which the user authorization ID is a direct or indirect member will be considered. Security labels and exemptions granted to roles for which membership is only accessible through the groups associated with the user authorization ID will not be considered.
- If the security policy enables only group authorizations for consideration, all security labels and exemptions granted to groups associated with the user authorization ID will be considered. Security labels and exemptions granted to roles for which membership is only accessible through the groups associated with the user authorization ID will not be considered.
- If the security policy enables both group and role authorizations for consideration, any security labels and exemptions granted to roles accessible to the user indirectly through groups associated with the user authorization ID will be considered.
- Role authorizations that are accessible to the user only through PUBLIC will not be considered at any time.
- If more than one security label is eligible for consideration
during an access attempt, the values provided for each security label
are merged at the individual component level to form a security label
that reflects the combination of all available values at each component
piece of the security policy. This is the security label
value that will be used for the access attempt.The mechanisms for combining security labels vary by component type. The components of the resultant security label are as follows:
- Set components contain the union of all unique values encountered in the eligible security labels
- Array components contain the highest order element encountered in the eligible security labels
- Tree components contain the union of all unique values encountered in the eligible security labels
- If more than one exemption is eligible for consideration during an access attempt, all found exemptions are applied to the access attempt.
Examples
- Example 1: Alter a security policy named DATA_ACCESS to
add a new component named REGION.
ALTER SECURITY POLICY DATA_ACCESS ADD COMPONENT REGION
- Example 2: Alter a security policy named DATA_ACCESS to
allow access through security labels granted to roles.
ALTER SECURITY POLICY DATA_ACCESS USE ROLE AUTHORIZATIONS
- Example 3: Show the eligible security labels that
would be considered depending on the settings for group or role authorizations
in a security policy. The security policy SECUR_POL has an array component
and a set component, consisting of the following elements:
- Array = {TS, S, C, U}
- Set = {A, B, X, Y}
- Security label L1 = C:A
- Security label L2 = S:B
- Security label L3 = TS:X
- Security label L4 = U:Y
The following table shows the value of the combined security label for any access attempt by Paul, depending on the different settings of the security policy SECUR_POL.Table 1. Security labels considered as a function of security policy settings Roles Enabled Roles Disabled Groups Enabled L1, L2, L3, L4 L1, L3 Groups Disabled L1, L2 L1 Table 2. Combined security labels as a function of security policy settings Roles Enabled Roles Disabled Groups Enabled TS:(A, B, X, Y) TS:(A, X) Groups Disabled S:(A, B) C:A