oracle-deep-data-security-lab/scenarios/02-shared-app-account/README.md

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 ~/DEEP-DATA-SECURITY/oracle-deep-data-security-lab
export TNS_ADMIN=~/DEEP-DATA-SECURITY/wallet-ddslab

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.

On Windows PowerShell:

cd C:\Users\rodrigo\Documents\Codex\oracle-deep-data-security-lab
sql admin@ddslab_tunnel

Step By Step - Before, Vulnerable Environment

1. Reset the scenario as ADMIN:

   @scenarios/02-shared-app-account/sql/99_reset.sql
   

2. 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
   

3. Show the full raw data as ADMIN:

   SELECT order_id, customer_name, region, seller, amount, margin
   FROM dds_orders
   ORDER BY order_id;
   

4. Connect as the shared technical application account:

   sql 'dds_app/AppPool#2026Lab!@ddslab_tunnel'
   

5. 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

1. Reconnect as ADMIN and apply the data grants:

   @scenarios/02-shared-app-account/sql/03_data_grants.sql
   

2. Connect as alice, a sales representative:

   sql 'alice/Welcome1_DDS!@ddslab_tunnel'
   

3. Run Alice's normal business query, without the sensitive MARGIN column:

   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.

4. 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.

5. 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:

• alice sees only her orders and does not get access to MARGIN.
• bruno sees LATAM orders with manager visibility, including MARGIN.
• 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.