IBM db2 Row and Access Control & Masking (Enforcing Governance where the data resides)

Db2 Row and Column Access Control (RCAC)
George Baklarz
IBM DTE Leader Hybrid Data Management

IBM Cloud2IBM Digital Technical Engagement
Please note
 IBM’s statements regarding its plans, directions, and intent are subject to change
or withdrawal without notice and at IBM’s sole discretion.
 Information regarding potential future products is intended to outline our general
product direction and it should not be relied on in making a purchasing decision.
 The information mentioned regarding potential future products is not a commitment,
promise, or legal obligation to deliver any material, code or functionality. Information about
potential future products may not be incorporated into any contract.
 The development, release, and timing of any future features or functionality described for
our products remains at our sole discretion.
 Performance is based on measurements and projections using standard IBM benchmarks in
a controlled environment. The actual throughput or performance that any user will
experience will vary depending upon many factors, including considerations such as the
amount of multiprogramming in the user’s job stream, the I/O configuration, the storage
configuration, and the workload processed. Therefore, no assurance can be given that an
individual user will achieve results similar to those stated here.

Agenda
Introduction to Row Column Access Control (RCAC)
Using RCAC in Db2
 Row permissions
 Column masks
RCAC Usage Examples

Why Use Row Column Access Control?
 Currently, data access is restricted via views or
application logic
 Users with direct access to databases can
bypass these layers
 Example: Users with DATAACCESS authority
can still view all data
 DB2 10 provides a new way to control data
access at
row/column level
 Set up rich security policies
 Prevents administrators with DATAACCESS
authority from accessing all data in a database
 No dependency on application logic
 Allows for data masking (column)
 Facilitates table level multi-tenancy
How can we ensure
that a social security
number column is
masked out for
unauthorized users?
How can we ensure
that managers only
see data for their
own employees?

What is Row Column Access Control?
 Additional layer of data security introduced in
DB2 10
 Complementary to table
level authorization
 Allows access only to subset of data useful for
job task
 Controls access to a table at the row, column, or
both
 Two sets of rules
 Permissions for rows
 Masks for columns

How is This Different from LBAC?
LBAC is a fixed label security model designed
for governments
 Hierarchical access scenarios
• Great for large companies with well defined data and user classifications
• Suited for such applications as those intelligence and defense communities
RCAC is a general purpose security model
 No data or user classification required
 Best suited for commercial customers

How is This Different from LBAC? (cont.)
Why is RCAC more suited for commercial customers?
 Simpler mechanism
• LBAC is powerful, but has a complex, lengthy implementation
 No requirement to classify data and users
• Can use existing roles and groups
 Provides column masking (LBAC does not)
 Transparent to the client application
 Pushes security from application to database, giving
performance advantages
 Robust data privacy for supporting multi-tenancy
 Very easy for use in compliance
Click for Demo, video / Hands on Lab:
ibm.com/demos/collection/db2-database

CREATE PERMISSION p_name ON table/view FOR ROWS
WHERE search condition ENFORCED FOR ALL ACCESS {disable/enable};
ALTER TABLE/VIEW table/view ACTIVATE ROW ACCESS CONTROL;
Determines if permission
will be ENABLED when
access control is
ACTIVATED for table
WHERE clause
Create Permission
 To create a permission governing access to rows
1) CREATE the permission with access rule defined by search condition
– Choose to enforce for all DML or simply select
2) ENABLE or DISABLE the permission
– If enabled, this access rule will be implemented when row access control is
ACTIVATed for the affected table
3) ALTER table to activate row access control
ACTIVATE the row
access control

Scenario: Create Permission
A simple scenario has the following permissions attached
 PAYROLL table
• Can only be accessed between the hours of 8:00 am and 5:00 pm
 Anyone with table privileges on the PAYROLL table only has those privileges
enabled within the table during the selected hours
1
2

CREATE PERMISSION payrollp
ON PAYROLL
FOR ROWS WHERE CURRENT TIME BETWEEN ‘8:00’ AND ’17:00’
ENFORCED FOR ALL ACCESS ENABLE;
ALTER TABLE payroll ACTIVATE ROW ACCESS CONTROL;
Scenario: Create Permission (cont.)
1
2

A more complex scenario using the same PAYROLL has the
following permissions attached
 PAYROLL table
• Can only be accessed between the hours of 8:00 am and 5:00 pm
• Can only be accessed using the PROC1 stored procedure from within the
HRPROCS schema
 The PAYROLL table can only be accessed through the HRPROCS.PROC1
stored procedure during the hours from 8:00 am to 5:00 pm
1
2

CREATE PERMISSION payroll-table-rules
ON PAYROLL
FOR ROWS WHERE CURRENT TIME BETWEEN ‘8:00’ AND ’17:00’
AND SYSIBM.ROUTINE_SPECIFIC_NAME = ‘PROC1’
AND SYSIBM.ROUTINE_SCHEMA = ‘HRPROCS’
AND SYSIBM.ROUTINE_TYPE = ‘P’
ALTER TABLE payroll ACTIVATE ROW ACCESS CONTROL;
1
2

CREATE MASK m_name on t_name FOR COLUMN c_name RETURN
case-expression {disable/enable}
ALTER TABLE/VIEW table/view ACTIVATE COLUMN ACCESS CONTROL;
Create Column Mask
 To create a mask for a column
1) CREATE the mask with visibility of column value determined by
case expression
2) ENABLE or DISABLE the permission, determining if this access rule will be
implemented when column access control is enabled for the affected table
3) ALTER table to ACTIVATE column access control
Result of case expression
is returned in substitute of
column value
Determines if mask will be
enabled when access control
is ACTIVATEd for table
ACTIVATE column
access control

Scenario: Create Column Mask
Scenario has the following permissions attached
 Salary column
• Accounting can see the actual SALARY column value
• Everyone else sees 0.00
 Employee number column
• Employees or Accounting can see their own full employee number
• Everyone else sees ‘EEEEEE’
1
2

CREATE MASK salary_mask ON payroll FOR
COLUMN salary RETURN
CASE
WHEN verify_role_for_user(SESSION_USER,
‘ACCOUNTING’) = 1
THEN salary
ELSE 0.00
END
ENABLE;
CREATE MASK empno_mask ON payroll FOR
COLUMN empno RETURN
CASE
‘EMPLOYEE’) = 1
THEN empno
‘ACCOUNTING’) = 1
THEN empno
ELSE
‘EEEEEE‘
END
ENABLE;
ALTER TABLE payroll ACTIVATE COLUMN ACCESS CONTROL;
Scenario: Create Column Mask (cont.)
1
2

CREATE VIEW patient_info_view AS
SELECT p.sin, p.name, c.choice
FROM patient p, patientchoice c
WHERE p.sin = c.sin
AND c.choice = ‘drug-research’
AND c.value = ‘opt-in’;
Using Views with RCAC-Protected Tables
Views can be created on RCAC-protected tables
 When querying the view, data is returned based on RCAC
rules defined on base table
SELECT * FROM patient_info_view;
SIN NAME CHOICE
XXX XXX 856 Sam drug-research
XXX XXX 789 Bob drug-research

CREATE MASK EXAMPLEHMO.ACCT_BALANCE_MASK ON PATIENT FOR
COLUMN ACCT_BALANCE RETURN
CASE WHEN VERIFY_ROLE_FOR_USER(SESSION_USER,'ACCOUNTING') = 1
THEN ACCBALDISPLAY(ACCT_BALANCE)
ELSE 0.00
END
ENABLE;
Using UDFs and Triggers with RCAC-Protected Tables
 UDFs must be defined as SECURED when referenced from within row and column
access control definitions
 UDFs invoked on columns protected with a column mask must be defined as SECURED.
For instance, the SELECT statement below will fail unless CALC is defined as a secure
UDF
 Triggers must be defined as SECURED if the subject table is protected with row or
column access control
ALTER FUNCTION ACCBALDISPLAY SECURED;
SELECT CALC(ACC_BALANCE) FROM PATIENT;
ALTER TRIGGER T_LOG_CHANGES SECURED;

CREATE [OR REPLACE] MASK m_name ON t_name FOR COLUMN
c_name RETURN case expression DISABLE/ENABLE
SQL Statements for Managing RCAC rules
SQL information for creating a row permission or column mask is
stored in the SYSCAT.CONTROLS catalog table
CREATE [OR REPLACE] PERMISSION p_name ON t_name FOR ROWS
WHERE search condition ENFORCED FOR ALL ACCESS
DISABLE/ENABLE
ALTER MASK/PERMISSION c_name/p_name DISABLE/ENABLE
DROP MASK/PERMISSION c_name/p_name
ALTER TABLE t_name ACTIVATE/DEACTIVATE ROW/COLUMN ACCESS
CONTROL

New Built-in Scalar Functions
 verify_role_for_user (user, role1, role2, …)
 The result is 1 if any of the roles associated with the user are in list of role1, role2, etc.
 Else 0
 verify_group_for_user (user, group1, group2, …)
 The result is 1 if any of the groups associated with the user are in list of group1, group2, etc.
 Else 0
 Note: This scalar function can also be used for LDAP roles
 verify_trusted_context_role_for_user (user, role1, role2, …)
 The result is 1 if when the role acquired through a trusted connection is in (or contains) any of
the roles in the list of role1, role2, …
 Else 0

Restrictions and Considerations
 You cannot create a mask on a column which
 Is an XML object
 Is a LOB column or a distinct type column that is based on a LOB
 Is a column referenced in an expression that defines a
generated column
 UDFs and TRIGGERs must be altered with SECURE keyword
 Compromise between security vs. integrity
 Automatic Data Movement
 No propagation of any existing row permissions or column masks takes place. Target table is automatically
protected with the default no access row permission to protect against direct access to that target table
• MQT, History Tables for Temporal tables, and detached table partitions for range-partitioned tables
 db2look can extract row permission and column mask definitions in order to mimic elsewhere
 EXPLAIN facility shows access plans with RCAC in place
 Can override with NORCAC option

RCAC Usage Examples – Users, Groups, and Roles
For the usage examples, there exist the following users and
departments (groups and roles)
Using groups and roles with RCAC

Scenario: Create Permission
Scenario has the following permissions attached
 CUSTOMERS and CUST_CRDT_CARD table
• CUSTOMERS contains name, customer number, address, gender, and other
personal information
• CUST_CRDT_CARD contains customer ID and credit card information
 SALES department
• Has all row access to both tables
 ACCOUNTING department
• Has all row access to the CUSTOMERS table
• Can only see rows in the CUST_CRDT_CARD table for customers that
belong to each ACCOUNTING employee’s customer group
 Nobody else sees any data

TABLE PERMISSIONS – CUSTOMERS
CREATE PERMISSION custa ON TOQUE.CUSTOMERS
FOR ROWS WHERE
(VERIFY_ROLE_FOR_USER(SESSION_USER,'SALES')=1)
OR
(VERIFY_GROUP_FOR_USER(SESSION_USER,'ACCOUNTING')=1)
ALTER TABLE TOQUE.CUSTOMERS ACTIVATE ROW ACCESS CONTROL;
TABLE PERMISSIONS – CUST_CRDT_CARD
CREATE PERMISSION crdta ON TOQUE.CUST_CRDT_CARD
FOR ROWS WHERE
(VERIFY_ROLE_FOR_USER(SESSION_USER,'SALES')=1)
OR
(VERIFY_GROUP_FOR_USER(SESSION_USER,'ACCOUNTING')=1 AND
VERIFY_ROLE_FOR_USER(SESSION_USER,CUST_GROUP)=1)
ALTER TABLE TOQUE.CUST_CRDT_CARD ACTIVATE ROW ACCESS CONTROL;

Query Example – Row Permissions Only
RCAC flexibility allows row permissions, column masks, or both to
be implemented on a table
An example query where only row permissions exist
SELECT B.CUST_FIRST_NAME AS FIRST_NAME, B.CUST_LAST_NAME AS LAST_NAME,
A.CUST_CC_NUMBER AS CC_NUMBER,A.CUST_CC_EXP_DATE AS EXP_DATE,
A.CUST_GROUP AS GROUP FROM TOQUE.CUST_CRDT_CARD A, TOQUE.CUSTOMERS B
WHERE A.CUST_CODE = B.CUST_CODE AND B.CUST_LAST_NAME LIKE 'T%';
A

Scenario: Create Masks
 Scenario has the following masks attached
 CUSTOMERS and CUST_CRDT_CARD table
• CUST_GROUP column can only be viewed by members of the SECURITY group
• All others see the CUST_GROUP with the masked value of ‘NONE’
 CUSTOMERS table has restrictions on personal information columns
• CUST_AGE
• CUST_EMAIL
• MARITAL_STATUS_CODE
 For the three restricted view columns, the following masks apply
• SALES can view the e-mail address only
• Age is masked as “21”
• Marital status is masked as NULL
• ACCOUNTING can view the actual values of all 3 columns

COLUMN MASKS – CUSTOMERS
CREATE MASK cust_group_mask ON TOQUE.CUSTOMERS
FOR COLUMN cust_group RETURN
CASE WHEN (VERIFY_ROLE_FOR_USER(SESSION_USER,'SECURITY')=1)
THEN cust_group
ELSE 'NONE'
END
ENABLE;
CREATE MASK cust_age_mask ON TOQUE.CUSTOMERS
FOR COLUMN cust_age RETURN
CASE WHEN (VERIFY_GROUP_FOR_USER(SESSION_USER,'ACCOUNTING')=1)
THEN cust_age
WHEN (VERIFY_ROLE_FOR_USER(SESSION_USER,'SALES')=1)
THEN 21
ELSE NULL
END
ENABLE;
Scenario: Create Masks (cont.)

COLUMN MASKS – CUSTOMERS (cont.)
CREATE MASK cust_email_mask ON TOQUE.CUSTOMERS
FOR COLUMN cust_email RETURN
THEN cust_email
WHEN (VERIFY_ROLE_FOR_USER(SESSION_USER,'SALES')=1)
THEN cust_email
ELSE NULL
END
ENABLE;
CREATE MASK marital_status_mask ON TOQUE.CUSTOMERS
FOR COLUMN marital_status_code RETURN
THEN marital_status_code
ELSE NULL
END
ENABLE;
ALTER TABLE TOQUE.CUSTOMERS ACTIVATE COLUMN ACCESS
CONTROL;

COLUMN MASKS – CUST_CRDT_CARD
CREATE MASK cust_cc_group_mask ON
TOQUE.CUST_CRDT_CARD
FOR COLUMN cust_group RETURN
CASE WHEN
(VERIFY_ROLE_FOR_USER(SESSION_USER,'SECURITY')=1
)
THEN cust_group
ELSE 'NONE'
END
ENABLE;
ALTER TABLE TOQUE.CUST_CRDT_CARD ACTIVATE COLUMN
ACCESS CONTROL;

Permission and Mask Summary for Examples
The following permission and mask rules apply to the CUSTOMERS
table
CUSTOMERS TABLE AGE MARITAL
STATUS
CUST_GROUP E-MAIL
DBA N - - - -
SALES Y N N N Y
ACCOUNTING Y Y Y N Y
A
B
C

Permission and Mask Summary for Examples (cont.)
The following permission and mask rules apply to the
CUST_CRDT_CARD table
CUST_CRDT_CARD TABLE CUST_GROUP
DBA N -
SALES Y N
ACCOUNTING N
A Y
B Y
C Y

Query Example – Permissions and Masks
An example query with both permissions and masks
A

Query Example – Permissions and Masks
An example query with both permissions and masks
C
Gunter query returned 359 rows, Moe query returned 384 rows

Query Example – Permissions and Masks (cont.)
Now we will look at a query involving multiple masks
SELECT CUST_FIRST_NAME AS FIRST_NAME, CUST_LAST_NAME AS LAST_NAME,
CUST_CITY AS CITY, CUST_AGE AS AGE, CUST_GROUP AS GROUP
FROM TOQUE.CUSTOMERS WHERE CUST_CITY LIKE 'P%';
Click for Demo, video / Hands on Lab: ibm.com/demos/collection/db2-database

Query Example – Permissions and Masks (cont.)
RCAC prevents privileged users from accessing sensitive data
SELECT CUST_FIRST_NAME AS FIRST_NAME, CUST_LAST_NAME AS LAST_NAME,
CUST_CITY AS CITY, CUST_AGE AS AGE, CUST_GROUP AS GROUP
FROM TOQUE.CUSTOMERS WHERE CUST_CITY LIKE 'P%';
Click for Demo, video / Hands on Lab: ibm.com/demos/collection/db2-database

RCAC – Useful Tips
Here are some useful tips to remember when implementing RCAC
for a database table
 Both database roles and operating system groups can be utilized within RCAC to
provide sub-categories of access
 When defining column masks, remember the following
• Literal masks must match the data type defined for the column
• NULL masks can only be used if the column allows NULL values
 Permissions and masks are defined at the database level
• Each permission and mask name must be unique within the database
• Each permission or mask applies to a single table

Summary

Summary of Row and Column Access Control
Allows access only to subset of data useful for job task
 Leverages existing groups and roles
Same output regardless of access method
 Data Studio, views, applications, etc.
Data-centric and transparent to client application
Ideal for
 Commercial applications
 Function-specific access control (vs. hierarchical)
 Use in compliance
SECADM is the sole manager of security policy
Two sets of rules
 Row access is restricted via permissions
 Column access is restricted via masks

Thank You !
Seem more on Db2 @
IBM.COM/Demos/collection/db2-database

IBM db2 Row and Access Control & Masking (Enforcing Governance where the data resides)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IBM db2 Row and Access Control & Masking (Enforcing Governance where the data resides)

Similar to IBM db2 Row and Access Control & Masking (Enforcing Governance where the data resides) (20)

Recently uploaded

Recently uploaded (20)

IBM db2 Row and Access Control & Masking (Enforcing Governance where the data resides)

Editor's Notes