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

6
scenarios/04-view-bypass-mac/README.md
View File

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