oracle-deep-data-security-lab/scenarios/04-view-bypass-mac/WORKSHOP.md

Workshop - Prevent View Bypass With Oracle Deep Data Security

About This Workshop

This workshop demonstrates why access rules should be enforced on the protected data, not only in application SQL or views. Before DDS, a legacy view can apply the expected owner filter, but direct table access can bypass that path and expose accounts outside the user's ownership. After DDS, the base table and alternate access paths respect the same boundary.

Workshop Goals

• Create an account table and a legacy view.
• Show how a view can become an alternate access path.
• Apply DDS to enforce account ownership at the table boundary.
• Validate that table and view access return the same authorized subset.

Estimated Time

20 to 30 minutes.

Scenario Summary

Persona	Business Role	Expected Access After DDS
emma	Account owner	Only accounts owned by Emma.
marvin	Account owner	Only accounts owned by Marvin.
erik	Account owner	Only accounts owned by Erik.

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/04-view-bypass-mac/sql/99_reset.sql

Task 1.2 - Create Table And View

@scenarios/04-view-bypass-mac/sql/00_schema.sql

The script creates:

Object	Purpose
DDS_MAC_ACCOUNTS	Protected base account table.
DDS_MAC_ACCOUNTS_VIEW	Legacy view over the base table with an owner filter.

Task 1.3 - Load Accounts

@scenarios/04-view-bypass-mac/sql/01_seed_data.sql

Example accounts include owners emma, marvin, and erik.

Task 1.4 - Create Personas And Roles

@scenarios/04-view-bypass-mac/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 erik IDENTIFIED BY "Welcome1_DDS!";
CREATE DATA ROLE account_owner_role;

Lab 2 - Demonstrate The View Bypass Risk

Task 2.1 - Connect As Emma Before DDS

Exit the administrator session:

exit

Connect as Emma:

sql 'emma/Welcome1_DDS!@ddslab_tunnel'

Emma represents an account owner. Before DDS enforcement, she still has a broad legacy role, so this section demonstrates why view-based controls and object grants can be risky.

Task 2.2 - Query The Base Table Directly Before DDS

ALTER SESSION SET CURRENT_SCHEMA = ADMIN;

SELECT account_id, account_name, owner_name, region, balance
FROM dds_mac_accounts
ORDER BY account_id;

Expected result before DDS: Emma can see Account Alpha, Account Beta, and Account Gamma, even though only Account Alpha belongs to her.

This is the direct table access path.

Task 2.3 - Query The Legacy View Before DDS

SELECT account_id, account_name, owner_name, region, balance
FROM dds_mac_accounts_view
ORDER BY account_id;

Expected result before DDS: the view returns only Account Alpha, because the view contains the expected owner filter.

This is the intended application access path. The view is doing the right thing, but the direct table query above still bypassed the view-based control.

Customer Message

Before DDS, the result depends on which path Emma uses:

Direct table query -> all accounts
Legacy view query  -> only Account Alpha

The business rule "Emma should only see Emma's account" exists in the view, but it is not enforced at the protected data boundary yet.

Lab 3 - Apply Oracle Deep Data Security

Task 3.1 - Reconnect As ADMIN

exit

sql admin@ddslab_tunnel

Task 3.2 - Apply Data Grants

@scenarios/04-view-bypass-mac/sql/03_data_grants.sql

The main grant is:

CREATE OR REPLACE DATA GRANT mac_account_owner
  AS SELECT
  ON dds_mac_accounts
  WHERE owner_name = ORA_END_USER_CONTEXT.username
  TO account_owner_role;

This filters accounts to the authenticated owner. The script enables DDS on DDS_MAC_ACCOUNTS.

In this lab, the predicate compares the account owner with the active DDS end-user context:

WHERE UPPER(owner_name) = ORA_END_USER_CONTEXT.username

That means Emma, Marvin, and Erik can run the same SQL, but the database returns different rows for each persona.

Lab 4 - Validate Table And View Access

Task 4.1 - Test Emma After DDS

exit

sql 'emma/Welcome1_DDS!@ddslab_tunnel'

@scenarios/04-view-bypass-mac/sql/04_test_queries.sql

Expected result: Emma sees only Account Alpha from both table and view paths.

The same two access paths are tested again:

Direct table query -> only Account Alpha
Legacy view query  -> only Account Alpha

The SQL did not become smarter. The database security boundary became mandatory.

Task 4.2 - Quick Validation With Marvin

exit

sql 'marvin/Welcome1_DDS!@ddslab_tunnel'

@scenarios/04-view-bypass-mac/sql/04_test_queries.sql

Expected result: Marvin sees only Account Beta from both paths.

Task 4.3 - Quick Validation With Erik

exit

sql 'erik/Welcome1_DDS!@ddslab_tunnel'

@scenarios/04-view-bypass-mac/sql/04_test_queries.sql

Expected result: Erik sees only Account Gamma from both paths.

Customer Message

After DDS, the result is consistent regardless of the path:

Emma   -> Account Alpha only
Marvin -> Account Beta only
Erik   -> Account Gamma only

This shows the value of DDS versus relying only on view logic, application SQL, BI filters, or agent-generated SQL.

Lab 5 - Clean Up

exit

sql admin@ddslab_tunnel

@scenarios/04-view-bypass-mac/sql/99_reset.sql
exit

What You Built

Component	Purpose
DDS_MAC_ACCOUNTS	Protected base table.
DDS_MAC_ACCOUNTS_VIEW	Legacy view with the intended owner filter.
END USER	emma, marvin, erik; account owner personas.
DATA ROLE	account_owner_role; owner authorization profile.
DATA GRANT	Filters rows by owner_name = ORA_END_USER_CONTEXT.username.
SET USE DATA GRANTS ONLY	Enforces DDS on the base table.

The trust chain is: end-user identity -> account owner role -> owner data grant -> protected table access.

Product Manager Talking Points

• Views are useful, but they should not be the only security boundary.
• DDS protects the data regardless of the access path.
• This reduces bypass risk from direct SQL, legacy views, and reporting tools.