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

From the repository root, connect as ADMIN:
```
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.
Reset the scenario:
```
@scenarios/02-shared-app-account/sql/99_reset.sql
```
Presenter note: this makes the demo repeatable and removes previous Data Grants or roles.

Create the table, data, and identities:

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

Show all rows and columns as ADMIN:
```
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.
Exit and connect as the shared technical application account:
```
exit
```
```
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.
Simulate an application or API using DDS_APP to query all orders:
```
@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

Exit and reconnect as ADMIN:
```
exit
```
```
sql admin@ddslab_tunnel
```
Apply data grants by business role:
```
@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.
Test Alice, the sales representative, with a normal business query:
```
exit
```
```
sql 'alice/Welcome1_DDS!@ddslab_tunnel'
```
```
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.
Try to force Alice to see MARGIN:
```
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.

Test Bruno, the LATAM manager:

exit

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;

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

5.2 KiB Executable File Raw Blame History