17.10 - Security Constraint UDF Body - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQL External Routine Programming

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Release Date
July 2021
Content Type
Programming Reference
Publication ID
B035-1147-171K
Language
English (United States)

INSERT, UPDATE, DELETE and SELECT UDFs take the current session security label and/or the target row security label input arguments and compare these security values to the security policy rules defined in the UDF to determine if the INSERT, UPDATE, DELETE or SELECT should be allowed.

The security constraint UDFs return a true or false result depending on whether or not the input values pass the security policy. INSERT and UPDATE UDFs also return the current session security label if the SQL request passes the security policy. For details about the valid return values of security constraint UDFs, see Return Values for INSERT or UPDATE UDFs and Return Values for SELECT or DELETE UDFs.

The following example security policy rules provide a guide for creating security constraint UDFs. The rules are based on the Bell-Lapadula Model that is commonly used for enforcement of access control in government and military applications.

No Read Up (for SELECT operations):
  • The session hierarchical level must be ≥ the row hierarchical level.

    Users cannot read data with a higher classification.

  • The session label must include all non-hierarchical compartments found in the row label.

    The user must be assigned to all compartments under which the row is classified.

No Write Down (INSERT/UPDATE operations)
  • The row hierarchical level must be ≥ the session hierarchical level.

    New or updated rows inherit the session level. This rule prevents an updating user from accidentally reclassifying the row to a higher level.

  • The row label must include all non-hierarchical compartments in the session label.

    New or updated rows inherit all session compartments. This rule prevents an updating user from accidentally adding excess compartmental classifications to a row.

The sample rules do not contain recommendations for a DELETE policy, but it is common to require that a row be declassified, that is, set to the lowest classification level or to NULL before it can be deleted.

For more information about security classification categories and labels, see Teradata Vantage™ - Advanced SQL Engine Security Administration, B035-1100.