3 Commits

Author SHA1 Message Date
devmrko
1f4a9c7e64 Wire DDS variant into run.sh as optional subcommands
Adds dds / dds-setup / dds-tests / dds-teardown subcommands so the
26ai Deep Data Security variant can be run from the same one-click
entry point. Not part of `./run.sh all` since DDS requires 26ai
(23.26.2+) which not every ADB has.

- sql/adb/14_tests_dds_user.sql: shared verification script for all
  4 ddsuser_*; uses WHENEVER SQLERROR CONTINUE so the expected
  ORA-00942 (deny-by-hiding) doesn't abort the script. Includes
  bypass attempts against the underlying VPD views, raw DB Links,
  and the VPD permission tables.
- sql/adb/15_dds_cleanup.sql: idempotent teardown for DDS objects
  (data grants, end users, data roles, dds_db_role, DDS-only views).
- run.sh: do_dds_prereq / do_dds_setup / do_dds_tests /
  do_dds_teardown helpers; dispatch case extended.

Also fixes a pre-existing secrets-leak gap: both 07_end_users.sql
and 13_dds_variant.sql had SET DEFINE ON without SET VERIFY OFF,
which causes sqlplus to echo the substituted DDL (including the
IDENTIFIED BY <password> clause) on the `new 1:` line. Added
SET VERIFY OFF.

E2E re-verified on ADB 23.26.2.2.0: matrix identical to manual run
(MY=17 / PG=12 / BOTH=12+17 / NONE=ORA-00942 on both), no password
in logs, dds-teardown leaves no residue.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-05-26 15:53:15 +09:00
devmrko
b7ee325b67 Fix DDS variant E2E + expand DDS capability docs
Real run against ADB 23.26.2.2.0 surfaced two issues:

- END USERs can't be direct grantees of a regular ROLE (ORA-01917).
  Connection privilege must flow through a DATA ROLE — added
  connect_only_role for ddsuser_none so it can authenticate
  without holding any data grant (mirrors VPDUSER_NONE UX).
- DDS Data Grants on top of the shared v_customers_* views silently
  returned 0 rows because the VPD policy on those views evaluates
  1=0 for sessions whose LOGON trigger didn't load the VPD context
  (i.e. all ddsuser_*). Created dedicated DDS-only views
  (v_dds_customers_pg / v_dds_customers_my) so DDS Data Grants are
  the sole authority.

E2E matrix now passes (ddsuser_my MY=17, ddsuser_pg PG=12,
ddsuser_both 12/17, ddsuser_none ORA-00942 on both). Notably DDS
returns ORA-00942 where VPD returned 0 rows — stronger object
hiding.

Expanded docs/05-dds-variant.md with:
- §1.1 capability matrix (End User, Data Role, Data Grant, MAC,
  ORA_END_USER_CONTEXT, OAuth2 federation, End User Context Object,
  ORA_IS_COLUMN_AUTHORIZED, dictionary views)
- §1.2 VPD/RAS-vs-DDS comparison
- §1.3 best-fit scenarios (multi-tenant SaaS, agentic AI, HR/PHI,
  federated identity, compliance)
- §1.4 limitations
- §5 operation-level grant example (manager-only UPDATE salary)
- §8 actual E2E results table

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-05-26 15:44:05 +09:00
devmrko
9702349dbe Add optional Oracle 26ai Deep Data Security variant
Reimplements the same 4-user source-access matrix using Oracle AI
Database 26ai's Deep Data Security (DDS) — VPD's declarative SQL
successor. Coexists with the VPD demo (ddsuser_* / dds_* prefixes,
MAC intentionally not enabled on shared views).

- sql/adb/13_dds_variant.sql: CREATE END USER + CREATE DATA ROLE +
  CREATE DATA GRANT for the same 4-user matrix; row-filter and
  column-mask variants shown as commented examples.
- docs/05-dds-variant.md: prereqs (23.26.2+, COMPATIBLE>=20.0),
  VPD <-> DDS 1:1 mapping table, run + teardown snippets.
- .env.example: DDSUSER_*_PASSWORD block (3b).
- README.md: tree + "더 깊이" link.

Not wired into run.sh — kept manual since DDS requires 26ai.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-05-26 15:25:08 +09:00