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>
This commit is contained in:
devmrko
156
docs/02-architecture.md
Normal file
156
docs/02-architecture.md
Normal file
@@ -0,0 +1,156 @@
|
||||
# 02 · Architecture
|
||||
|
||||
## 한 줄 요약
|
||||
|
||||
> **원본 DB 는 그냥 데이터 창고**, **권한은 ADB 한 곳**, **VPD 가 SQL 에 WHERE 절을
|
||||
> 자동 주입**.
|
||||
|
||||
---
|
||||
|
||||
## 왜 이렇게 만들었나 — 쿼리마다 EXISTS 돌리지 않는다
|
||||
|
||||
가장 단순한 접근은 "VPD 정책 함수 안에서 매번 매핑 테이블에 EXISTS 쿼리를 던지는"
|
||||
방식입니다. 동작은 하지만 **모든 SELECT 마다 권한 lookup 이 한 번 더 일어나서**
|
||||
원격 DB Link 위의 조회를 두 배로 만듭니다.
|
||||
|
||||
이 PoC 는 그 대신 **"로그인 시 1회만 매핑 조회 → 결과를 세션 컨텍스트에 캐시"**
|
||||
패턴을 씁니다.
|
||||
|
||||
```
|
||||
[LOGON 1회] [SELECT N회]
|
||||
ctx_pkg.init vpd_region_filter
|
||||
│ │
|
||||
├─ app_user JOIN user_group ├─ SYS_CONTEXT 읽기 (메모리)
|
||||
│ JOIN permission JOIN db_source │ = 디스크/네트워크 I/O 0
|
||||
│ → 'APAC' 또는 'APAC,EMEA' 또는 '*' 또는 NULL
|
||||
│ ├─ NULL → '1=0' (fail closed)
|
||||
└─ SYS_CONTEXT('VPD_CTX', '<view>') 에 저장 ├─ '*' → NULL (필터 없음)
|
||||
└─ 그 외 → 'region IN (...)'
|
||||
← Oracle 이 WHERE 에 AND
|
||||
```
|
||||
|
||||
**즉 EXISTS subquery 가 아니라 IN-list predicate 입니다.** 정책 함수가 반환한
|
||||
predicate 문자열을 Oracle 이 SQL 에 자동으로 AND 붙여줍니다. 매핑 테이블은
|
||||
LOGON 시 한 번만 읽으므로 쿼리 부하 0.
|
||||
|
||||
캐시가 stale 해질 위험 — 권한 변경 후 즉시 반영 — 은 `ctx_pkg.init` 을 수동
|
||||
호출하거나 재로그인으로 해소합니다. 운영에선 권한 변경 빈도가 낮으니 합리적
|
||||
트레이드오프입니다.
|
||||
|
||||
---
|
||||
|
||||
## 데이터 흐름
|
||||
|
||||
```
|
||||
+---------------------+
|
||||
| vpduser_a / b | ← 사용자 로그인
|
||||
+----------+----------+
|
||||
|
|
||||
(1) LOGON 트리거
|
||||
|
|
||||
v
|
||||
+---------------------+
|
||||
| ctx_pkg.init | → vpd_ctx 컨텍스트에 권한 set
|
||||
+----------+----------+
|
||||
|
|
||||
(2) SELECT * FROM v_customers_pg
|
||||
|
|
||||
v
|
||||
+---------------------+
|
||||
| VPD 정책 함수 | → SYS_CONTEXT 읽고 WHERE 절 동적 생성
|
||||
| (region IN (...)) |
|
||||
+----------+----------+
|
||||
|
|
||||
(3) 뷰가 DB Link 로 원격 조회
|
||||
|
|
||||
+----------+----------+
|
||||
| RDS_POSTGRES_LINK | (DBMS_CLOUD_ADMIN heterogeneous)
|
||||
| OR |
|
||||
| RDS_LINK (MySQL) |
|
||||
+----------+----------+
|
||||
|
|
||||
v
|
||||
+---------------------+
|
||||
| 원격 customers | → 필터링된 행만 ADB 로 반환
|
||||
+---------------------+
|
||||
|
|
||||
(4) Data Redaction 으로 이메일 마스킹
|
||||
|
|
||||
v
|
||||
사용자 화면
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 권한 모델 (6 테이블)
|
||||
|
||||
| 테이블 | 의미 |
|
||||
|---|---|
|
||||
| `app_customer` | 도메인의 "고객사" 개념 (멀티 테넌트 hook) |
|
||||
| `app_user` | DB 유저 → 도메인 유저 매핑 (`db_username` 컬럼이 핵심) |
|
||||
| `app_group` | 그룹 (KR_ANALYSTS, GLOBAL_ADMINS, ...) |
|
||||
| `user_group` | user ↔ group N:N |
|
||||
| `db_source` | 원본 소스 식별자 (PG, MY) |
|
||||
| `permission` | (group, source, region) 행 — `region='*'` 이면 전체 허용 |
|
||||
|
||||
→ "이 유저는 어떤 region 을 볼 수 있는가?" 는 **`app_user → user_group → permission` JOIN**
|
||||
한 번이면 답이 나옵니다. 그게 정책 함수가 하는 일.
|
||||
|
||||
---
|
||||
|
||||
## 정책 함수 (`vpd_region_filter`)
|
||||
|
||||
`DBMS_RLS.ADD_POLICY` 가 뷰 호출 시마다 부르는 함수. 반환 문자열이 그대로
|
||||
**WHERE 절 뒤에 AND 로 붙습니다.**
|
||||
|
||||
핵심 로직:
|
||||
|
||||
1. `SYS_CONTEXT('VPD_CTX', 'ALLOWED_REGIONS_PG')` 를 읽음
|
||||
(값 예: `'APAC'` 또는 `'APAC,EMEA,AMER'` 또는 `NULL`)
|
||||
2. NULL/빈 값 → `RETURN '1=0'` (아무것도 안 보임 = fail closed)
|
||||
3. `'*'` 포함 → `RETURN NULL` (필터 없음 = 전체)
|
||||
4. 그 외 → `RETURN 'region IN (''APAC'',''EMEA'')'` 형식으로 in-list
|
||||
|
||||
→ 컨텍스트는 **Secure Application Context** (`USING ctx_pkg`) 라 다른 패키지에서
|
||||
설정 불가. `vpduser_a` 가 `DBMS_SESSION.SET_CONTEXT('VPD_CTX', ...)` 직접 호출 →
|
||||
ORA-01031.
|
||||
|
||||
---
|
||||
|
||||
## 왜 뷰를 한 단계 더 두나?
|
||||
|
||||
뷰가 없으면 정책을 **DB Link 위에 직접** 걸어야 하는데, VPD 는 원격 객체를
|
||||
직접 보호할 수 없습니다. 그래서:
|
||||
|
||||
* `v_customers_pg` 는 `SELECT ... FROM "public"."customers"@RDS_POSTGRES_LINK`
|
||||
하는 단순 통과 뷰
|
||||
* VPD 정책은 이 **로컬 뷰** 에 붙음
|
||||
* 엔드유저에게는 뷰만 GRANT, DB Link 는 **EXECUTE 권한 X / 직접 보지 못함**
|
||||
|
||||
---
|
||||
|
||||
## 신뢰 경계
|
||||
|
||||
| 누가 | 무엇을 할 수 있나 |
|
||||
|---|---|
|
||||
| `ADMIN` (ADB 관리자) | 전부 다. 정책 BYPASS. **운영에선 절대 일반 사용자에게 주지 말 것** |
|
||||
| `vpduser_a/b` | (a) 자기에게 GRANT 된 뷰 SELECT, (b) `ctx_pkg.init` 호출 |
|
||||
| `vpduser_a/b` 가 **못** 하는 것 | DBMS_RLS 변경, EXEMPT ACCESS POLICY, CREATE TABLE (스냅샷 방지), 매핑 테이블 직접 SELECT, DB Link 직접 SELECT |
|
||||
|
||||
→ 즉 엔드유저 입장에서 정책을 우회할 표면이 없습니다. `07_end_users.sql` 의
|
||||
주석에서 "what we are deliberately NOT granting" 섹션이 그 목록.
|
||||
|
||||
---
|
||||
|
||||
## 한계 / 운영 고려사항
|
||||
|
||||
* **DB Link 비밀번호** 는 `DBMS_CLOUD.CREATE_CREDENTIAL` 로 ADB 안에 저장되지만,
|
||||
ADMIN 은 평문에 가깝게 읽을 방법이 있습니다 (deferred admin 모델). 운영에선
|
||||
IAM/Vault 기반 credential 회전이 필요.
|
||||
* **LOGON 트리거 실패 = fail closed** (컨텍스트 비어있음 → `1=0`). 운영에선
|
||||
실패시 audit table 기록 추가 권장.
|
||||
* **성능**: 정책 함수는 statement-level 캐싱이 기본. 같은 세션에서 같은 statement
|
||||
를 반복 실행해도 한 번만 호출됨. 하지만 통합 뷰가 DB Link 위에 있어 **원격
|
||||
쿼리는 매번** 발생.
|
||||
* **Redaction 정책**은 row level filter 와 별개로 동작 — 마스킹 컬럼이 추가되면
|
||||
06a 에 추가 필요.
|
||||
Reference in New Issue
Block a user