Example: Column-Level Discretionary Access Control and Row-Level Security Audit Logging - Teradata Vantage

Teradata® VantageCloud Lake

Deployment
VantageCloud
Edition
Lake
Product
Teradata Vantage
Published
January 2023
ft:locale
en-US
ft:lastEdition
2024-12-11
dita:mapPath
phg1621910019905.ditamap
dita:ditavalPath
pny1626732985837.ditaval
dita:id
phg1621910019905

Suppose you want to audit any attempt by user TomSmith to insert a row into the emp_record table because such an attempt is a violation of the discretionary access control security policy at your site.

The request to do this auditing looks like this.

     BEGIN LOGGING DENIALS WITH TEXT 
     ON EACH INSERT BY TomSmith 
     ON emp_record;

Suppose you also want to know whenever a user attempts to insert a row that violates the row-level security policy for the target table, which is maintained by a row-level security constraint named group_membership.

You cannot run DENIALS logging for DELETE, INSERT, SELECT, or UPDATE FOR CONSTRAINT requests. Denials as a result of insufficient security credentials to run a DML request on an row-level security-protected table are not treated as an access denial.

If you attempt to run a DML request, but do not have the required row-level security privilege, that request is considered to be a DENIAL.

For example, if you attempt to insert a value into a constraint column, you do not have a default session constraint value, and you do not do not have the OVERRIDE INSERT CONSTRAINT privilege on the table, that attempt is considered a denial.

For example, Vantage generates an audit row if logging is enabled by the following request.

     BEGIN LOGGING DENIALS
     ON EACH OVERRIDE INSERT
     FOR CONSTRAINT group_membership
     ON TABLE securedb.emp_record;