Files
vpd-permission-poc/sql/adb/07_end_users.sql
devmrko 68d53dc5a9 Initial commit — VPD Permission POC (clone-and-go)
ADB-centered row-level access control across heterogeneous DB sources
(AWS RDS Postgres + MySQL) using Oracle VPD + Data Redaction +
Secure Application Context, packaged as a one-click demo.

Mechanism:
- LOGON trigger calls ctx_pkg.init once per session to load the user's
  allowed regions from the permission mapping tables into a Secure App
  Context (VPD_CTX, USING ctx_pkg).
- VPD policy function vpd_region_filter reads SYS_CONTEXT and returns
  an IN-list predicate (or '1=0' for fail-closed, NULL for '*'),
  which Oracle injects into every SELECT on the protected views.
- Data Redaction reuses the same context to mask PII (email, full_name)
  when the allowed-regions value is not '*'.
- 5 documented bypass attempts (direct DB link SELECT, SET_CONTEXT
  spoof, DBMS_RLS drop, mapping table SELECT) all blocked by GRANT
  scoping + DEFINER rights on ctx_pkg.

One-click entrypoint:
- ./run.sh {prereq|source|adb|tests|audit|all|teardown}
- Source DDL (Postgres + MySQL customers + 12-row seed each) is
  applied via local psql/mysql; ADB-side setup via sqlplus with .env
  values injected as SQL*Plus DEFINE substitutions.

Verified E2E on ADB 26ai + AWS RDS PG + RDS MySQL (mysql_community
gateway) on 2026-05-26: VPDUSER_A sees only APAC rows (PG 2 / MySQL 6,
PII masked), VPDUSER_B sees all (PG 12 / MySQL 17, PII unmasked).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-05-26 14:03:32 +09:00

62 lines
2.5 KiB
SQL

-- ============================================================
-- 07_end_users.sql
-- Create the two end-user accounts with MINIMAL privileges.
-- Add a LOGON trigger that loads each user's context automatically.
-- Run as ADMIN.
--
-- DEFINE: &VPDUSER_A_PASSWORD, &VPDUSER_B_PASSWORD
-- ============================================================
SET ECHO OFF
SET FEEDBACK ON
SET DEFINE ON
PROMPT === Creating end-user accounts ===
-- Passwords come from .env (DEFINE) so they aren't hardcoded in source.
-- Production should use IAM / proxy auth / mTLS instead of static passwords.
CREATE USER vpduser_a IDENTIFIED BY "&VPDUSER_A_PASSWORD";
CREATE USER vpduser_b IDENTIFIED BY "&VPDUSER_B_PASSWORD";
-- ADB requires a tablespace quota even for read-only users in some setups; we
-- skip QUOTA since these users won't create objects.
GRANT CREATE SESSION TO vpduser_a;
GRANT CREATE SESSION TO vpduser_b;
PROMPT === Granting SELECT on the policy-protected views ONLY ===
GRANT SELECT ON v_customers_pg TO vpduser_a;
GRANT SELECT ON v_customers_my TO vpduser_a;
GRANT SELECT ON v_customers_pg TO vpduser_b;
GRANT SELECT ON v_customers_my TO vpduser_b;
-- Allow them to call ctx_pkg.init (the logon trigger needs this, and a manual
-- re-init is sometimes useful). The package is bound to vpd_ctx so calling it
-- is harmless: it only ever loads the caller's OWN permissions.
GRANT EXECUTE ON ctx_pkg TO vpduser_a;
GRANT EXECUTE ON ctx_pkg TO vpduser_b;
-- NOTE on what we are deliberately NOT granting:
-- * NO grant on app_user / permission / etc. -> users can't read who-can-see-what
-- * NO grant on the underlying @dblink tables -> can't bypass the view
-- * NO grant on DBMS_RLS -> can't alter/drop the policy
-- * NO EXEMPT ACCESS POLICY -> can't escape VPD
-- * NO CREATE TABLE / CREATE MATERIALIZED VIEW -> can't snapshot filtered data
-- * NO DBA / PDB_DBA / RESOURCE roles -> least privilege
PROMPT === Creating LOGON trigger that auto-loads context ===
CREATE OR REPLACE TRIGGER vpd_logon_trg
AFTER LOGON ON DATABASE
BEGIN
-- Only fire for our application end-users. ADMIN logons keep normal behavior.
IF SYS_CONTEXT('USERENV','SESSION_USER') IN ('VPDUSER_A','VPDUSER_B') THEN
admin.ctx_pkg.init;
END IF;
EXCEPTION
WHEN OTHERS THEN
-- Never block login on a context-loading error; fail closed (no perms loaded
-- means policy returns 1=0, i.e. no rows). Log if you have an audit table.
NULL;
END;
/
PROMPT === End-users ready ===
EXIT;