Security Constraint UDF Body - Analytics Database - Teradata Vantage

SQL External Routine Programming

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
VMware
Product
Analytics Database
Teradata Vantage
Release Number
17.20
Published
June 2022
Language
English (United States)
Last Update
2023-07-11
dita:mapPath
iiv1628111441820.ditamap
dita:ditavalPath
qkf1628213546010.ditaval
dita:id
B035-1147
lifecycle
latest
Product Category
Teradata Vantage™

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 row level security, see Teradata Vantage™ - Analytics Database Security Administration, B035-1100.