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

# Runbook - 02 Shared App Account

## Objective

Show that a shared technical application account should not be the real data authorization boundary.

## Security Value

- Reduces the risk of overprivileged connection pools.
- Lets the database evaluate the end user, not only the technical account.
- Helps protect web applications, APIs, BI tools, and agents that use shared accounts.

## Prerequisites

- Oracle AI Database compatible with Oracle Deep Data Security.
- SQLcl or SQL*Plus.
- Understanding of which end-user identity the application will propagate.

## Before - Vulnerable Environment

1. From the repository root, connect as `ADMIN`:

   ```bash
   cd ~/DEEP-DATA-SECURITY/oracle-deep-data-security-lab
   export TNS_ADMIN=~/DEEP-DATA-SECURITY/wallet-ddslab
   sql admin@ddslab_tunnel
   ```

   Presenter note: `ADMIN` prepares the lab objects. The risk will be shown later using the shared application account.

   SQLcl note: after running a script with `@file.sql`, do not type `/`. The slash reruns the last command in the SQLcl buffer and can make a successful command look like an error.

2. Reset the scenario:

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

   Presenter note: this makes the demo repeatable and removes previous Data Grants or roles.

3. Create the table, data, and identities:

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

   Presenter note: `DDS_APP` represents the application connection pool; `alice` and `bruno` represent real business users.

4. Show all rows and columns as `ADMIN`:

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

   Presenter note: `MARGIN` is commercially sensitive and should not be visible to every seller.

5. Exit and connect as the shared technical application account:

   ```sql
   exit
   ```

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

   Presenter note: this simulates a web app, API, BI tool, or AI service where many users arrive through the same database account.

6. Simulate an application or API using `DDS_APP` to query all orders:

   ```sql
   @scenarios/02-shared-app-account/sql/04_test_queries.sql
   ```

   Presenter note: before DDS, the database sees `DDS_APP` and the broad SQL returns too much data.

## Expected Result Before

- The shared account can see orders from every seller and region.
- Fields such as `MARGIN` may be exposed if the application generates incorrect SQL.
- A bug, prompt injection, or abused endpoint may query more data than the user should see.

## After - Applying Deep Data Security

1. Exit and reconnect as `ADMIN`:

   ```sql
   exit
   ```

   ```bash
   sql admin@ddslab_tunnel
   ```

2. Apply data grants by business role:

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

   Presenter note: `seller_role` is limited to the seller's own rows and excludes `MARGIN`; `latam_manager_role` can see LATAM orders with full manager fields.

3. Test Alice, the sales representative, with a normal business query:

   ```sql
   exit
   ```

   ```bash
   sql 'alice/Welcome1_DDS!@ddslab_tunnel'
   ```

   ```sql
   ALTER SESSION SET CURRENT_SCHEMA = ADMIN;

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

   Presenter note: this is Alice's legitimate workflow. She needs customer, region, seller, and amount to manage her pipeline, but she does not need commercial margin.

4. Try to force Alice to see `MARGIN`:

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

   Presenter note: this simulates an application bug, abused API endpoint, prompt injection, or AI-generated SQL asking for a sensitive column outside Alice's business role.

5. Test Bruno, the LATAM manager:

   ```sql
   exit
   ```

   ```bash
   sql 'bruno/Welcome1_DDS!@ddslab_tunnel'
   ```

   ```sql
   ALTER SESSION SET CURRENT_SCHEMA = ADMIN;

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

   Presenter note: Bruno has manager visibility, so he can see LATAM orders and the margin needed for his role.

## Expected Result After

- `alice` sees only her orders and does not see `margin`.
- `bruno` sees LATAM orders with full manager visibility.
- The technical account is no longer the only security boundary.

## Demo Evidence

- Before/after comparison of the same SQL.
- Explanation of data roles.
- Simple flow: end user -> app -> database -> data grants.

## Official References

- Oracle Deep Data Security Guide: https://docs.oracle.com/en/database/oracle/oracle-database/26/ddscg/index.html
- Fine-Grained Data Authorization: https://docs.oracle.com/en/database/oracle/oracle-database/26/ddscg/fine-grained-data-authorization.html
- Create Data Grants: https://docs.oracle.com/en/database/oracle/oracle-database/26/ddscg/create-data-grants.html
- End-User Security Contexts: https://docs.oracle.com/en/database/oracle/oracle-database/26/refrn/DBA_END_USER_SECURITY_CONTEXTS.html