ALTER SECURITY POLICY statement

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

>>-ALTER SECURITY POLICY--security-policy-name------------------>

   .------------------------------------------------------.   
   V                                                (1)   |   
>----+-ADD SECURITY LABEL COMPONENT--component-name-----+-+----><
     +-+-OVERRIDE NOT AUTHORIZED WRITE SECURITY LABEL-+-+     
     | '-RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL-' |     
     +-+-USE GROUP AUTHORIZATIONS----+------------------+     
     | '-IGNORE GROUP AUTHORIZATIONS-'                  |     
     '-+-USE ROLE AUTHORIZATIONS----+-------------------'     
       '-IGNORE ROLE AUTHORIZATIONS-'                         

1. Only the ADD SECURITY LABEL COMPONENT clause can be specified more than once.

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}
  The following security labels are defined for SECUR_POL:
  • Security label L1 = C:A
  • Security label L2 = S:B
  • Security label L3 = TS:X
  • Security label L4 = U:Y
  User Paul is a member of role R1 and group G1. Group G1 is a member of role R2. Security label L1 is granted to Paul. Security label L2 is granted to role R1. Security label L3 is granted to group G1. Security label L4 is granted to role R2. The following table shows what security labels would be considered for any access attempt by Paul, depending on the different possible 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

  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 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