4.3 KiB
Executable File
02 - Shared App Account
Objective
Show the risk of a technical application account used by many users and how the database should enforce authorization based on the end user.
What This Lab Shows
Before Oracle Deep Data Security, a technical account or connection pool can query orders from every seller and region. After data grants are applied, the database authorizes access based on the end-user persona, not only on the shared technical account.
Personas
alice: sales representative.bruno: LATAM manager.dds_app: technical application account.
Where To Run The Commands
Run SQL scripts from the repository root. On Linux/macOS/WSL:
cd <repo-root>
export TNS_ADMIN=<wallet-directory>
Connect as the lab administrator:
sql admin@ddslab_tunnel
SQLcl note: when running a script with @file.sql, press Enter once and wait for the output. Do not type / afterward, because / reruns the last command in the SQLcl buffer.
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.
On Windows PowerShell:
cd <repo-root>
sql admin@ddslab_tunnel
Step By Step - Before, Vulnerable Environment
-
Reset the scenario as
ADMIN:@scenarios/02-shared-app-account/sql/99_reset.sql -
Create the orders table, seed data, business personas, and the shared app account:
@scenarios/02-shared-app-account/sql/00_schema.sql @scenarios/02-shared-app-account/sql/01_seed_data.sql @scenarios/02-shared-app-account/sql/02_identities.sql -
Show the full raw data as
ADMIN:SELECT order_id, customer_name, region, seller, amount, margin FROM dds_orders ORDER BY order_id; -
Connect as the shared technical application account:
sql 'dds_app/AppPool#2026Lab!@ddslab_tunnel' -
Run the broad application query:
@scenarios/02-shared-app-account/sql/04_test_queries.sql
Expected result before protection: DDS_APP can see orders from all regions and the sensitive MARGIN column. This represents a common connection-pool problem where the database only sees the application account.
Step By Step - After, With Deep Data Security
-
Reconnect as
ADMINand apply the data grants:@scenarios/02-shared-app-account/sql/03_data_grants.sql -
Connect as
alice, a sales representative:sql 'alice/Welcome1_DDS!@ddslab_tunnel' -
Run Alice's normal business query, without the sensitive
MARGINcolumn:ALTER SESSION SET CURRENT_SCHEMA = ADMIN; SELECT order_id, customer_name, region, seller, amount FROM dds_orders ORDER BY order_id;This query represents the normal sales workflow. Alice needs customer, region, seller, and order amount to follow her pipeline, but she does not need commercial margin.
-
Try to access the sensitive margin column as Alice:
SELECT order_id, customer_name, region, seller, amount, margin FROM dds_orders ORDER BY order_id;This query represents an application bug, abused endpoint, prompt injection, or ad hoc SQL asking for a sensitive field outside Alice's business role.
-
Connect as
bruno, the LATAM manager, and run the manager query:sql 'bruno/Welcome1_DDS!@ddslab_tunnel'ALTER SESSION SET CURRENT_SCHEMA = ADMIN; SELECT order_id, customer_name, region, seller, amount, margin FROM dds_orders ORDER BY order_id;
Expected result after protection:
alicesees only her orders and does not get access toMARGIN.brunosees LATAM orders with manager visibility, includingMARGIN.- The technical account is no longer the only authorization boundary.
Optional Automated Execution
Windows:
powershell -ExecutionPolicy Bypass -File .\scripts\run-scenario.ps1 -Scenario 02-shared-app-account -ConnectString "<connect_string>"
Linux/macOS:
./scripts/run-scenario.sh 02-shared-app-account "<connect_string>"
Demo Details
See the complete walkthrough, evidence, and official references in RUNBOOK.md.
For a LiveLabs-style guided workshop, use WORKSHOP.md.