Clarify view bypass lab access paths

scenarios/04-view-bypass-mac/README.md

@@ -6,7 +6,7 @@ Show that views and alternate access paths must not bypass the policy on the bas
 
 ## What This Lab Shows
 
-Before Oracle Deep Data Security, a legacy view can expose rows that should be protected. After data grants and `USE DATA GRANTS ONLY` are applied, both the table and the view respect the same access boundary.
+Before Oracle Deep Data Security, a legacy view may apply the expected owner filter, but direct table access can bypass that application access path and expose rows that should be protected. After data grants and `USE DATA GRANTS ONLY` are applied, both the table and the view respect the same access boundary.
 
 ## Personas
 
@@ -68,7 +68,7 @@ sql "<connect_string>"
    ORDER BY account_id;
    ```
 
-Expected result before protection: both direct table access and the legacy view may show accounts owned by other users.
+Expected result before protection: the view shows only Emma's account, but direct table access can still show accounts owned by other users.
 
 ## Step By Step - After, With Deep Data Security
 
@@ -91,7 +91,7 @@ Expected result after protection:
 - The table returns only the authorized account.
 - The view returns the same authorized subset.
 - `emma` sees `Account Alpha`, `marvin` sees `Account Beta`, and `erik` sees `Account Gamma`.
-- The alternate access path no longer works as a bypass.
+- The direct table access path no longer works as a bypass.
 
 ## Optional Automated Execution
 

scenarios/04-view-bypass-mac/RUNBOOK.md

@@ -2,11 +2,11 @@
 
 ## Objective
 
-Show that views and alternate access paths can bypass poorly designed controls, and that `USE DATA GRANTS ONLY` enforces Mandatory Access Control on the protected object.
+Show that a view can contain the intended access rule while direct table access still bypasses that path, and that `USE DATA GRANTS ONLY` enforces Mandatory Access Control on the protected object.
 
 ## Security Value
 
-- Prevents bypass through legacy views.
+- Prevents bypass through direct table access, reports, BI tools, and other alternate paths.
 - Enforces a consistent policy across the base table and views.
 - Helps customers with many reports, synonyms, views, and BI tools.
 
@@ -31,7 +31,21 @@ Show that views and alternate access paths can bypass poorly designed controls,
    @scenarios/04-view-bypass-mac/sql/02_identities.sql
    ```
 
-3. Simulate a legacy view that returns all data:
+3. Connect as `emma` and query the base table directly:
+
+   ```bash
+   sql 'emma/Welcome1_DDS!@ddslab_tunnel'
+   ```
+
+   ```sql
+   ALTER SESSION SET CURRENT_SCHEMA = ADMIN;
+
+   SELECT account_id, account_name, owner_name, region, balance
+   FROM dds_mac_accounts
+   ORDER BY account_id;
+   ```
+
+4. Query the intended legacy view:
 
    ```sql
    SELECT account_id, account_name, owner_name, region, balance
@@ -41,8 +55,9 @@ Show that views and alternate access paths can bypass poorly designed controls,
 
 ## Expected Result Before
 
-- The view may expose accounts owned by other users.
-- The alternate access path does not honor the intended base table policy.
+- Direct table access may expose accounts owned by other users.
+- The view returns only the current user's account because it contains the intended owner filter.
+- The security rule depends on using the correct access path.
 
 ## After - Applying Deep Data Security
 
@@ -62,7 +77,7 @@ Show that views and alternate access paths can bypass poorly designed controls,
 
 - The base table returns only the account owned by the current end user.
 - The view returns the same restricted rows.
-- The broad view data grant cannot bypass the base table policy when MAC is enabled.
+- Direct table access no longer bypasses the owner policy when MAC is enabled.
 
 ## Demo Evidence
 
@@ -75,4 +90,3 @@ Show that views and alternate access paths can bypass poorly designed controls,
 - SET USE DATA GRANTS ONLY: https://docs.oracle.com/en/database/oracle/oracle-database/26/sqlrf/set-use-data-grants-only.html
 - Fine-Grained Data Authorization - Mandatory Access Control: https://docs.oracle.com/en/database/oracle/oracle-database/26/ddscg/fine-grained-data-authorization.html
 - Configure Data Grants: https://docs.oracle.com/en/database/oracle/oracle-database/26/ddscg/configure-data-grants.html
-

scenarios/04-view-bypass-mac/WORKSHOP.md

@@ -2,7 +2,7 @@
 
 ## 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.
+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
 
@@ -55,7 +55,7 @@ The script creates:
 | Object | Purpose |
 | --- | --- |
 | `DDS_MAC_ACCOUNTS` | Protected base account table. |
-| `DDS_MAC_ACCOUNTS_VIEW` | Legacy view over the base table. |
+| `DDS_MAC_ACCOUNTS_VIEW` | Legacy view over the base table with an owner filter. |
 
 ### Task 1.3 - Load Accounts
 
@@ -120,20 +120,20 @@ FROM dds_mac_accounts_view
 ORDER BY account_id;
 ```
 
-Expected result before DDS: the view also returns accounts owned by multiple users.
+Expected result before DDS: the view returns only `Account Alpha`, because the view contains the expected owner filter.
 
-This is the alternate access path. The important point is not that the view itself is bad; the risk is relying on a specific access path as the only security boundary.
+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, Emma can reach the same overexposed data through both paths:
+Before DDS, the result depends on which path Emma uses:
 
 ```text
 Direct table query -> all accounts
-Legacy view query  -> all accounts
+Legacy view query  -> only Account Alpha
 ```
 
-The business rule "Emma should only see Emma's account" is not being enforced at the protected data boundary yet.
+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
 
@@ -264,7 +264,7 @@ exit
 | Component | Purpose |
 | --- | --- |
 | `DDS_MAC_ACCOUNTS` | Protected base table. |
-| `DDS_MAC_ACCOUNTS_VIEW` | Legacy view used to demonstrate alternate access paths. |
+| `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`. |

scenarios/04-view-bypass-mac/evidence/expected-results.md

@@ -1,6 +1,13 @@
 # Expected Results
 
+## Before Oracle Deep Data Security
+
+- Direct table access can return accounts owned by other users.
+- The legacy view returns only the current user's account because it contains the intended owner filter.
+- The control depends on users and tools using the correct access path.
+
+## After Oracle Deep Data Security
+
 - The base table returns only the account owned by the current end user.
 - The view returns the same restricted rows.
-- The broad view data grant does not bypass the base table policy when MAC is enabled.
-
+- Direct table access no longer bypasses the base table policy when MAC is enabled.

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

@@ -23,6 +23,7 @@ BEGIN
     CREATE OR REPLACE VIEW dds_mac_accounts_view AS
     SELECT account_id, account_name, owner_name, region, balance
     FROM dds_mac_accounts
+    WHERE UPPER(owner_name) = ORA_END_USER_CONTEXT.username
   ]';
 END;
 /