rodrigo.pace/oracle-deep-data-security-lab
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify view bypass lab access paths
Some checks failed
Repo Quality / structure (push) Has been cancelled
Details

Browse Source
This commit is contained in:
Rodrigo
2026-05-18 12:29:10 -03:00
parent 1d11986e94
commit 033d5e9456
5 changed files with 42 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
scenarios/04-view-bypass-mac/WORKSHOP.md
View File

@@ -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`. |