oracle-deep-data-security-lab/scenarios/07-audit-evidence-data-safe/WORKSHOP.md

Workshop - Audit Evidence With Oracle Deep Data Security And Data Safe

About This Workshop

This workshop demonstrates how to combine Oracle Deep Data Security, Unified Audit, Data Redaction, and OCI Data Safe concepts to protect sensitive payment data and produce audit evidence.

Before controls, a payment operator can query payment tokens through broad access. After controls, DDS restricts access, Data Redaction protects token display for audit review, and Unified Audit records access to the sensitive table.

Workshop Goals

• Create sensitive payment data.
• Demonstrate broad access to CARD_TOKEN.
• Apply DDS data grants by persona.
• Enable Unified Audit policies.
• Apply Data Redaction to payment tokens.
• Query local audit evidence and position OCI Data Safe for reporting.

Estimated Time

35 to 50 minutes.

Scenario Summary

Persona	Business Role	Expected Access After Controls
payment_operator	Payment operations	Brazil operational payment fields without CARD_TOKEN.
auditor	Audit reviewer	Review data with token protected by redaction.
dds_audit_analyst	Technical account	Lab analysis account.

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/07-audit-evidence-data-safe/sql/99_reset.sql

Task 1.2 - Create The Payment Table

@scenarios/07-audit-evidence-data-safe/sql/00_schema.sql

Column	Purpose
PAYMENT_ID	Payment identifier.
CUSTOMER_NAME	Customer name.
COUNTRY	Used by the operator row filter.
PAYMENT_AMOUNT	Transaction amount.
CARD_TOKEN	Sensitive payment token.
RISK_FLAG	Risk indicator.

Task 1.3 - Load Sample Payments

@scenarios/07-audit-evidence-data-safe/sql/01_seed_data.sql

Task 1.4 - Create Personas And Baseline Access

@scenarios/07-audit-evidence-data-safe/sql/02_identities.sql

The script creates payment_operator, auditor, data roles, and audit_legacy_broad_access_role for the vulnerable before state.

Lab 2 - Demonstrate Broad Payment Access

Task 2.1 - Connect As Payment Operator

exit

sql 'payment_operator/Welcome1_DDS!@ddslab_tunnel'

Task 2.2 - Query Payment Tokens Before Controls

ALTER SESSION SET CURRENT_SCHEMA = ADMIN;

SELECT payment_id, customer_name, country, payment_amount, card_token, risk_flag
FROM dds_audit_payments
ORDER BY payment_id;

Expected result before controls: the operator can see all payments and CARD_TOKEN.

Lab 3 - Apply DDS, Audit, And Redaction

Task 3.1 - Apply Data Grants

exit

sql admin@ddslab_tunnel

@scenarios/07-audit-evidence-data-safe/sql/03_data_grants.sql

Data Grant	What It Allows
audit_payments_read_all	Auditor can review payment records.
audit_payments_operator	Operator sees Brazil operational fields without CARD_TOKEN.

Task 3.2 - Create Unified Audit Policies

@scenarios/07-audit-evidence-data-safe/sql/04_audit_policies.sql

The policies audit selects on DDS_AUDIT_PAYMENTS and security administration actions.

Task 3.3 - Apply Data Redaction

@scenarios/07-audit-evidence-data-safe/sql/06_redaction_policy.sql

This protects CARD_TOKEN in query output while keeping the original value stored in the database.

Lab 4 - Validate Protected Access And Evidence

Task 4.1 - Validate Payment Operator

exit

sql 'payment_operator/Welcome1_DDS!@ddslab_tunnel'

ALTER SESSION SET CURRENT_SCHEMA = ADMIN;

SELECT payment_id, customer_name, country, payment_amount, risk_flag
FROM dds_audit_payments
ORDER BY payment_id;

Expected result: only Brazil operational payment fields are visible.

Task 4.2 - Validate Auditor

exit

sql 'auditor/Welcome1_DDS!@ddslab_tunnel'

ALTER SESSION SET CURRENT_SCHEMA = ADMIN;

SELECT payment_id, customer_name, country, payment_amount, card_token, risk_flag
FROM dds_audit_payments
ORDER BY payment_id;

Expected result: auditor can review records, with CARD_TOKEN protected by redaction.

Task 4.3 - Query Unified Audit Trail

exit

sql admin@ddslab_tunnel

SELECT event_timestamp,
       dbusername,
       current_user,
       action_name,
       object_schema,
       object_name,
       unified_audit_policies,
       return_code,
       sql_text
FROM unified_audit_trail
WHERE object_schema = 'ADMIN'
  AND object_name = 'DDS_AUDIT_PAYMENTS'
ORDER BY event_timestamp DESC
FETCH FIRST 20 ROWS ONLY;

Expected result: local audit evidence shows access to the sensitive payment table.

Lab 5 - Data Safe Review

In the OCI Console, open Data Safe and review:

Security Center > Data Safe
Target Databases
Activity Auditing
Reports or Events

OCI Data Safe can collect and present the audit trail as dashboards and evidence reports.

Lab 6 - Clean Up

@scenarios/07-audit-evidence-data-safe/sql/99_reset.sql
exit

What You Built

Component	Purpose
DDS_AUDIT_PAYMENTS	Sensitive payment table.
END USER	payment_operator, auditor; business personas.
DATA ROLE	payment_operator_role, audit_read_role; authorization profiles.
DATA GRANT	Restricts rows and columns by persona.
Unified Audit policy	Records access to sensitive payment data.
Data Redaction policy	Protects CARD_TOKEN in query output.
OCI Data Safe	Presents audit activity and evidence for review.

The trust chain is: end-user persona -> DATA ROLE -> DATA GRANT enforcement -> audit evidence -> Data Safe reporting.

Product Manager Talking Points

• DDS prevents overexposure.
• Data Redaction reduces sensitive display risk.
• Unified Audit and Data Safe support governance, compliance, and investigation.