5.3 KiB
Executable File
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 <repo-root>
export TNS_ADMIN=<wallet-directory>
sql admin@ddslab_tunnel
SQLcl note: after running @file.sql, do not type /.
Connection alias note: ddslab_tunnel is the TNS alias configured in the wallet tnsnames.ora for this lab. If your wallet uses another alias, replace ddslab_tunnel with your own service alias.
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.
Run Emma's self-service phone update:
@scenarios/03-pii-row-column-cell/sql/05_update_phone_test.sql
Expected result: Emma can update only her own PHONE value.
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.
Do not run 05_update_phone_test.sql as Marvin for the core demo. That script represents employee self-service phone updates, while Marvin's manager-specific update permission is for SALARY on direct reports.
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.
Do not run 05_update_phone_test.sql as Victoria for the core demo. HR has read access in this lab, but the employee self-service phone update is intentionally tied to the employee role.
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.