# 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 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. | ## Before You Begin ```bash 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 ```sql @scenarios/04-view-bypass-mac/sql/99_reset.sql ``` ### Task 1.2 - Create Table And View ```sql @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. | ### Task 1.3 - Load Accounts ```sql @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 ```sql @scenarios/04-view-bypass-mac/sql/02_identities.sql ``` The script creates: ```sql CREATE END USER emma IDENTIFIED BY "Welcome1_DDS!"; CREATE END USER marvin IDENTIFIED BY "Welcome1_DDS!"; CREATE DATA ROLE account_owner_role; ``` ## Lab 2 - Demonstrate The View Bypass Risk ### Task 2.1 - Query The Legacy View ```sql SELECT account_id, account_name, owner_name, region, balance FROM dds_mac_accounts_view ORDER BY account_id; ``` Expected result before DDS: the view may expose accounts belonging to multiple owners. ## Lab 3 - Apply Oracle Deep Data Security ### Task 3.1 - Apply Data Grants ```sql @scenarios/04-view-bypass-mac/sql/03_data_grants.sql ``` The main grant is: ```sql 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`. ## Lab 4 - Validate Table And View Access ### Task 4.1 - Test Emma ```sql exit ``` ```bash sql 'emma/Welcome1_DDS!@ddslab_tunnel' ``` ```sql @scenarios/04-view-bypass-mac/sql/04_test_queries.sql ``` Expected result: Emma sees only her authorized account from both table and view paths. ### Task 4.2 - Test Marvin ```sql exit ``` ```bash sql 'marvin/Welcome1_DDS!@ddslab_tunnel' ``` ```sql @scenarios/04-view-bypass-mac/sql/04_test_queries.sql ``` Expected result: Marvin sees only his authorized account. ## Lab 5 - Clean Up ```sql exit ``` ```bash sql admin@ddslab_tunnel ``` ```sql @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 used to demonstrate alternate access paths. | | `END USER` | `emma`, `marvin`; 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.