# 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 에 추가 필요.