oracle-deep-data-security-lab/scenarios/03-pii-row-column-cell/WORKSHOP.md

Workshop - Protect PII By Row, Column, And Cell With Oracle Deep Data Security

About This Workshop

This workshop demonstrates fine-grained access to employee PII. Before DDS, broad access can expose records, SSNs, salaries, and phone numbers. After DDS, each persona receives only the rows and columns required for their role.

Workshop Goals

• Create employee data with PII and salary fields.
• Apply row, column, and update controls with Data Grants.
• Validate employee, manager, and HR access patterns.

Estimated Time

25 to 40 minutes.

Scenario Summary

Persona	Business Role	Expected Access After DDS
emma	Employee	Own record and ability to update phone.
marvin	Manager	Direct reports without SSN, can update salary.
victoria	HR	All employee records with sensitive fields.

Before You Begin

cd ~/DEEP-DATA-SECURITY/oracle-deep-data-security-lab
export TNS_ADMIN=~/DEEP-DATA-SECURITY/wallet-ddslab
sql admin@ddslab_tunnel

SQLcl note: after running @file.sql, do not type /.

Lab 1 - Prepare The Environment

Task 1.1 - Reset The Scenario

@scenarios/03-pii-row-column-cell/sql/99_reset.sql

Task 1.2 - Create The Employee Table

@scenarios/03-pii-row-column-cell/sql/00_schema.sql

Column	Purpose
EMPLOYEE_ID	Employee identifier.
EMAIL	Used as the end-user row filter.
MANAGER	Used for manager direct-report filtering.
SSN	Sensitive PII.
SALARY	Sensitive compensation data.
PHONE	Field employees can update for themselves.

Task 1.3 - Load Sample Employees

@scenarios/03-pii-row-column-cell/sql/01_seed_data.sql

Task 1.4 - Create Personas And Roles

@scenarios/03-pii-row-column-cell/sql/02_identities.sql

The script creates:

CREATE END USER emma IDENTIFIED BY "Welcome1_DDS!";
CREATE END USER marvin IDENTIFIED BY "Welcome1_DDS!";
CREATE END USER victoria IDENTIFIED BY "Welcome1_DDS!";

CREATE DATA ROLE employee_role;
CREATE DATA ROLE manager_role;
CREATE DATA ROLE hr_role;

Lab 2 - Demonstrate The Vulnerable View Of PII

Task 2.1 - Review The Raw Data

SELECT employee_id, first_name, last_name, email, manager, ssn, salary, phone
FROM dds_employees
ORDER BY employee_id;

Expected result before DDS: all records and sensitive fields are visible to an administrator or broad legacy access path.

Lab 3 - Apply Oracle Deep Data Security

Task 3.1 - Apply Data Grants

@scenarios/03-pii-row-column-cell/sql/03_data_grants.sql

The grants are:

Data Grant	What It Allows
employees_own_record	Employees can select their own record and update PHONE.
manager_direct_reports	Managers can select direct reports except SSN and update SALARY.
hr_all_employees	HR can select all employee data.

DDS is then enabled with SET USE DATA GRANTS ONLY ON dds_employees ENABLED.

Lab 4 - Validate Personas

Task 4.1 - Emma Employee Access

exit

sql 'emma/Welcome1_DDS!@ddslab_tunnel'

@scenarios/03-pii-row-column-cell/sql/04_test_queries.sql

Expected result: Emma sees her own authorized view.

Task 4.2 - Marvin Manager Access

exit

sql 'marvin/Welcome1_DDS!@ddslab_tunnel'

@scenarios/03-pii-row-column-cell/sql/04_test_queries.sql

Expected result: Marvin sees direct reports and not their SSN.

Task 4.3 - Victoria HR Access

exit

sql 'victoria/Welcome1_DDS!@ddslab_tunnel'

@scenarios/03-pii-row-column-cell/sql/04_test_queries.sql

Expected result: Victoria sees HR-authorized sensitive data.

Lab 5 - Clean Up

exit

sql admin@ddslab_tunnel

@scenarios/03-pii-row-column-cell/sql/99_reset.sql
exit

What You Built

Component	Purpose
DDS_EMPLOYEES	Employee table with PII, salary, and phone data.
END USER	emma, marvin, victoria; business personas.
DATA ROLE	employee_role, manager_role, hr_role; authorization profiles.
DATA GRANT	Controls row access, column visibility, and update permissions.
ORA_END_USER_CONTEXT.username	Resolves the active end-user identity at query time.

The trust chain is: end-user identity -> DATA ROLE -> DATA GRANT -> row, column, and update enforcement.

Product Manager Talking Points

• DDS supports row, column, and update controls in one model.
• The database enforces the boundary even when SQL asks for too much.
• PII protection is close to the data and independent of application-only filtering.