Multilevel security

Multilevel security is a security policy that allows you to classify objects and users based on a system of hierarchical security levels and a system of non-hierarchical security categories.

Multilevel security provides the capability to prevent unauthorized users from accessing information at a higher classification than their authorization, and prevents users from declassifying information.

Multilevel security offers the following advantages:

  • Multilevel security enforcement is mandatory and automatic.
  • Multilevel security can use methods that are difficult to express through traditional SQL views or queries.
  • Multilevel security does not rely on special views or database variables to provide row-level security control.
  • Multilevel security controls are consistent and integrated across the system, so that you can avoid defining users and authorizations more than once.
  • Multilevel security does not allow users to declassify information.

Using multilevel security, you can define security for Db2 objects and perform other checks, including row-level security checks. Row-level security checks allow you to control which users have authorization to view, modify, or perform other actions on specific rows of data.

Multilevel security and row access control are mutually exclusive. While you can activate column access control on a table that has a security label column and enforce it on a security label column, you cannot do the same with row access control. If a table has a security label column, you cannot enable it with row access control. The opposite is also true; if a table is activated with row access control, you cannot alter it to include a security label column.

Security labels

Multilevel security restricts access to an object or a row based on the security label of the object or row and the security label of the user.

For local connections, the security label of the user is the security label that the user specified during sign-on. This security label is associated with the Db2 primary authorization ID and accessed from the RACF® ACEE control block. If no security label is specified during sign-on, the security label is the user's default security label.

For normal TCP/IP connections, the security label of the user can be defined by the security zone. IP addresses are grouped into security zones on the Db2 server. For trusted TCP/IP connections, the security label of the user is the security label established under the trusted context.

For SNA connections, the default security label for the user is used instead of the security label that the user signed on with.

Security labels can be assigned to a user by establishing a trusted connection within a trusted context. The trusted context definition specifies the security label that is associated with a user on the trusted connection. You can define trusted contexts if you have the SYSADM authority.

Security labels are based on security levels and security categories.

You can use the COMCRIT subsystem parameter to require that all tables in the subsystem are defined with security for the Common Criteria environment.

When defining security labels, do not include national characters, such as @, #, and $. Use of these characters in security labels may cause CCSID conversion errors.

Security levels

Along with security categories, hierarchical security levels are used as a basis for mandatory access-checking decisions. When you define the security level of an object, you define the degree of sensitivity of that object. Security levels ensure that an object of a certain security level is protected from access by a user of a lower security level.

Security categories

Security categories are the non-hierarchical basis for mandatory access-checking decisions. When making security decisions, mandatory access control checks whether one set of security categories includes the security categories that are defined in a second set of security categories.

Users and objects in multilevel security

In multilevel security, a user is any entity that requires access to system resources; the entity can be a human user, a stored procedure, or a batch job. An object is any system resource to which access must be controlled; the resource can be a data set, a table, a table row, or a command.