# DDS 보호 연결 페이지 상세 리뷰

> **추적성** — Redmine: #581 · 하위 일감: 설계/UX/개발/QA
>
> **대상** — `/vpd-policies` (사용자 표면명: DDS 보호 연결)
>
> **목적** — 구현 전, 보호 객체 상태와 DDS 집행 경계를 운영자가 판단할 수 있는지 검토한다.

> **하위 실행 기준** — [#606 설계](606-security-design.md) · [#607 UX](607-ux.md) · [#608 개발](608-implementation.md) · [#609 QA](609-qa.md)

## 1. 이 페이지에서 사용자가 끝내야 하는 일

이 페이지의 1차 사용자는 보안 설계자와 권한 운영자다. 사용자는 다음 네 질문에 답을 얻고 화면을 떠나야 한다.

1. 어떤 보호 객체가 실제로 DDS에 의해 보호되고 있는가?
2. 그 객체에 토큰 기반 서비스 경로와 DDS END USER 직접 비교 경로 중 어느 집행 방식이 선언됐는가? 한 객체가 두 경로를 함께 가질 수 있는가?
3. 토큰 경로의 런타임 권한 기준과 직접 비교 경로의 마지막 게시 스냅샷은 각각 최신이며, 최근 검증까지 통과했는가?
4. 정상·미게시·드리프트·실패 중 어떤 조치를 해야 하는가?

현재 화면은 공통 권한, 보호 객체, 역할 규칙, 검증 사용자 설명을 모두 보여 주지만 위 질문에 직접 답하지 못한다.

## 2. 현재 화면에서 확인된 증거

| 관찰 | 사용자 영향 |
|---|---|
| URL은 `/vpd-policies`, 제목은 DDS 보호 연결 | DDS 제품 화면인데 VPD 구현 잔재가 드러나 신뢰를 떨어뜨린다. |
| 토큰 Context와 DDS END USER를 한 흐름으로 표현 | 두 identity model이 같은 의미로 읽힌다. |
| `dds_demo_both/none/pg/my` 4개 카드가 기본 표면에 있음 | 데모 비교 프로필이 제품 운영 계정처럼 보인다. |
| `연결 설정됨`이라는 상태 | DB 연결, 비밀번호 설정, Grant 적용, 검증 통과 중 무엇인지 모호하다. |
| 역할·규칙 표가 중심 | 실제 DATA GRANT의 존재, 최신성, 검증 결과를 알 수 없다. |
| 상태/차이/게시 이력이 없음 | 운영자가 다음 행동을 고를 수 없다. |

## 3. 반드시 분리할 두 경로와 게시 경계

| 구분 | 토큰 기반 서비스 경로 | DDS END USER 직접 비교 |
|---|---|---|
| 목적 | 제품의 권한 기반 지식 검색 | DDS 선언형 identity/Data Role 동작 검증 |
| identity | 기술 사용자 세션 + Bearer로 만든 애플리케이션 Context | DDS `END USER` |
| 집행 | 기술 사용자에 연결된 객체별 `DATA GRANT` predicate가 `CB_AGENT_CTX`와 공통 권한 테이블을 요청 시 평가 | `END USER → DATA ROLE → DATA GRANT` |
| 권한 변경 반영 | 토큰 해석 뒤 predicate가 공통 권한을 읽으므로, 공통 권한 변경은 다음 요청에 반영된다. 단, Grant/함수/객체 선언 자체는 별도 게시·관찰 대상이다. | 유효 권한을 사용자별 predicate로 컴파일한 뒤 별도 게시한다. 공통 권한 변경만으로 기존 Grant는 갱신되지 않는다. |
| 기본 노출 | 기본 화면 | 고급 검증 |
| 주 사용 빈도 | 일상 운영 | 정책/장애 조사 |

Bearer 값을 DB 변수나 사용자명으로 매핑하는 것만으로 순수 DDS END USER Context가 만들어지지는 않는다. 그래서 기본 서비스 경로와 직접 비교 경로는 같은 탭, 같은 카드, 같은 용어로 다루면 안 된다.

이 표는 **보호 객체가 둘 중 하나만 선택해야 한다**는 뜻이 아니다. 같은 VIEW에 토큰용 `DATA GRANT`와 직접 비교용 `DATA GRANT`가 함께 있을 수 있다. 상태·검증 이력·조치도 객체 단위만이 아니라 `보호 객체 × 집행 경로` 단위로 보관한다.

## 4. 보호 객체 상태 계약

`정상/드리프트/검증 실패`를 서로 배타적인 하나의 값으로 두면 운영 사실이 사라진다. 예를 들어 Grant가 드리프트이면서 마지막 검증도 실패할 수 있다. 따라서 서버는 아래 세 축을 독립적으로 반환하고, UI는 대표 상태와 근거 배지를 함께 보여 준다.

| 상태 축 | 값 | 판정 근거 | 대표 조치 |
|---|---|---|---|
| 관측 가능성 | `OBSERVED` / `PARTIAL` / `UNAVAILABLE` | DDS catalog·권한 원천·검증 이력 중 필요한 원천을 모두 읽었는지 | 원천 연결/권한 점검 |
| 선언 동기화 | `MATCHED` / `NOT_PUBLISHED` / `DRIFTED` / `UNKNOWN` | 기대 명세와 실제 객체·Role·컬럼 범위·비교 가능한 predicate 표현의 차이 | 미리보기·재게시·차이 조사 |
| 실행 검증 | `PASSED` / `FAILED` / `STALE` / `NOT_RUN` / `UNKNOWN` | 결정적 허용/거부/경계 시나리오가 현재 명세 이후에 통과했는지 | 검증 실행·접근 근거 조사 |

대표 상태는 다음 우선순위로 정한다. 다만 보조 축의 값을 숨기지 않는다.

1. `확인 불가` — 관측 가능성이 `UNAVAILABLE`이거나, 정상 판정에 필요한 비교 원천이 없다.
2. `조치 필요` — `NOT_PUBLISHED`, `DRIFTED`, 또는 `FAILED`가 하나 이상 있다. 원인을 배지로 병기한다.
3. `재검증 필요` — 선언은 `MATCHED`지만 검증이 `STALE` 또는 `NOT_RUN`이다.
4. `보호 확인` — `OBSERVED`, `MATCHED`, `PASSED`가 모두 충족되고, 검증 시각이 마지막 관련 변경보다 뒤다.

`PARTIAL` 관측은 상세에 부족한 비교 필드를 표시하되, `보호 확인`으로 승격할 수 없다. 역할·권한 규칙의 건수도 보조 지표일 뿐, 이 계약의 정상 판정 근거가 아니다.

## 5. 기대값·실제값·검증 증거 데이터 계약

| 데이터 | 최소 필드 | 권위 있는 원천 | 용도 |
|---|---|---|---|
| 기대 명세 | `protectionObjectId`, 집행 경로, Data Role/기술 사용자, 객체·컬럼 범위, predicate의 canonical hash, 공통 권한/함수/객체 버전, 작성 시각 | **승인된 게시 계획의 immutable snapshot**. 현재 권한 화면의 즉시 조회값이 아니다. | 실제와의 비교, 검증 대상 고정 |
| 실제 관측 | Grant 이름, 객체, grantee, 컬럼 범위, 비교 가능한 선언 fingerprint, catalog 조회 시각·권한 범위 | DDS catalog adapter. 현재 `DBA_DATA_GRANTS` 조회만으로 확인할 수 있는 필드와 별도 비교 원천을 명시한다. | 동기화·관측 가능성 판정 |
| 게시 이력 | 계획 ID, 명세 version/hash, 실행자, 사유·승인 참조, 전후 version, DB 결과, rollback 참조 | append-only 게시 감사 기록 | 변경 추적/복구 |
| 검증 증거 | fixture ID, 경로, 주체 유형, 명세 version/hash, query/control query, 허용·거부·경계 결과, 반환/제외 수, 시각, 안전한 실패 분류, correlation ID | 검증 실행 기록 | 실행 검증·최근성 판정 |

canonical hash는 비교에 의미 없는 공백·대소문자·정렬 차이로 드리프트가 발생하지 않게 정규화한 명세에서 계산한다. 다만 정규화 규칙의 변경도 schema version으로 기록한다. raw predicate를 모든 운영자에게 보여 주거나 browser에 저장해서는 안 된다.

`DBA_DATA_GRANTS`는 현재 SQL에서 Grant 이름·객체·grantee를 확인하는 용도로 쓰인다. 이 정보만으로 predicate 또는 컬럼 범위까지 동일하다고 판정할 수 없다. 해당 Database release에서 허용된 추가 catalog/DDL fingerprint 조회가 없으면 관측 상태는 `PARTIAL`이어야 하며, `MATCHED`나 `보호 확인`으로 표시하지 않는다.

상태 계산이 실패했을 때 0건이나 정상으로 폴백하면 안 된다. `UNAVAILABLE`은 연결 오류, dictionary 권한 부족, timeout을 구분한 안전한 오류 분류와 마지막 정상 관측 시각을 동반한다.

## 6. 제안 정보 구조

### 기본: 토큰 기반 서비스 경로

상단에는 전체 상태와 추천 행동 하나를 둔다. 예시는 `1개 보호 객체 반영 필요 → 변경 미리보기`다.

그 아래 객체 표는 **토큰 기반 서비스 경로**의 현재 보호 상태만 기본으로 보여 준다. 행을 열면 객체 상세에서 다른 집행 경로와 기술 근거를 볼 수 있다.

| 보호 객체 | 대표 상태 | 동기화/검증 근거 | 마지막 관측 | 마지막 검증 | 조치 |
|---|---|---|---|---|---|

대표 상태는 `보호 확인`, `조치 필요`, `재검증 필요`, `확인 불가` 중 하나이며, `드리프트`, `검증 실패`, `관측 일부` 같은 근거 배지를 병기한다. 기본 표면에는 기술 SQL, raw predicate, dictionary 원문, 비밀·원문 데이터를 두지 않는다.

객체가 0개면 보호 범위가 아직 정의되지 않았다는 빈 상태와 `보호 객체 등록` 경로를 보인다. 다수 객체에서는 대표 상태, 이름, 마지막 관측/검증, 집행 경로로 필터·정렬하고, 게시 중인 객체에는 stale 데이터를 정상으로 보이지 않게 `반영 중` 처리를 한다.

### 고급: DDS END USER 직접 비교

`dds_demo_*` 프로필은 이 영역에서만 보여 준다. 표준 명칭은 **직접 비교용 검증 프로필**이다. `연결 설정됨` 대신 아래를 분리한다.

- 자격증명 설정 여부
- 직접 연결 가능 여부
- Data Role 매핑 여부
- 마지막 직접 비교 결과

직접 비교 탭은 기본 화면과 URL을 분리하거나, 최소한 명시적인 `고급 검증` 진입과 탭 역할·선택 상태를 제공한다. 데모 프로필은 제품 계정처럼 보이지 않게 fixture 목적과 만료/비활성 상태를 함께 표시한다.

### 객체 상세과 조치 권한

| 정보 또는 조치 | 일반 보호 상태 조회자 | 진단 권한자 | 게시 권한자 |
|---|---|---|---|
| 대표 상태·안전한 사유·마지막 관측 | 가능 | 가능 | 가능 |
| 객체명·Role·안전한 diff 요약 | 정책상 허용된 범위만 | 가능 | 가능 |
| raw predicate·catalog 원문·진단 로그 상관관계 | 불가 | 승인된 별도 화면/로그 | 필요 시 별도 감사 |
| 미리보기 | 불가 또는 요약만 | 가능 | 가능 |
| 게시·회수 | 불가 | 불가 | 사유·영향 확인·승인/감사 후 가능 |

위 권한명은 제품에서 구현할 개념적 capability다. 기존 관리자 로그인 권한과 동일하다고 가정하지 않으며, 실제 role mapping은 권한 설계에서 별도로 결정한다.

## 7. 오류와 누설 방지

- 일반 운영 화면에는 권한이 없는 객체의 이름, 금지된 TAG, 원문, predicate 상세를 오류 원인으로 노출하지 않는다.
- 토큰 경로에서 Grant 정보가 부족하더라도 `권한을 확인할 수 없음`처럼 안전한 상태와 운영자 조치만 표시한다.
- 직접 비교 프로필의 비밀번호 누락은 서비스 경로의 보호 실패가 아니라 고급 검증 구성 문제로 분리한다.
- inventory 조회 실패는 반드시 조회 시각과 오류 범위를 표시하고, 정상 상태 배지로 덮지 않는다. browser에는 DB 오류 원문 대신 correlation ID와 안전한 조치만 표시한다.
- Bearer 원문, END USER 비밀번호, 원문 청크, 차단된 TAG, 전체 predicate는 화면·감사 메모·URL query string에 기록하지 않는다.
- 토큰 Context는 요청 단위로 설정·해제되고, connection pool을 도입할 경우 다음 요청에 Context가 잔류하지 않는 검증을 필수로 한다.

## 8. 검증 증거와 0건 해석

벡터 검색의 0건은 권한 차단, 관련 문서 부재, embedding 차이, 상위 N 제한 중 무엇 때문인지 알 수 없다. 따라서 `반환 0건`만으로 `검증 실패` 또는 `차단 성공`을 판정하면 안 된다.

각 집행 경로에는 다음처럼 결정적인 fixture를 둔다.

| fixture | 목적 | 검증 방식 |
|---|---|---|
| 허용 TAG 문서 | 올바른 주체가 최소 1건을 볼 수 있음 | fixture 문서 ID를 포함하는 control query 또는 객체 조회를 사용해 1건 이상 반환 확인 |
| 거부 TAG 문서 | 허용되지 않은 자료가 노출되지 않음 | 같은 조건에서 fixture ID가 결과에 없는지 확인 |
| 경계 TAG 문서 | 다중 TAG OR, DENY 우선, 역할 상속의 경계를 검증 | 기대 결과 집합을 fixture manifest와 비교 |
| 권한 없음 주체 | default deny가 예상대로 동작 | 객체 미노출/권한 오류를 제품이 정한 안전한 분류로 확인 |

검증 이력에는 검색 결과만이 아니라 fixture manifest version, 명세 version/hash, query/control query, 반환 수·제외 수, 주체 유형, 시각, 실행 경로를 저장한다. 검색 관련도 자체를 검증하는 시나리오와 권한 집행을 검증하는 시나리오는 분리한다.

## 9. URL·용어 이전 기준

사용자 표면에서 VPD 잔재를 없애려면 제목만 바꾸면 안 된다. DDS canonical route를 먼저 정하고 메뉴·공유 링크·breadcrumb·감사 표기에 같은 명칭을 쓴다. 기존 `/vpd-policies`는 호환 기간 동안 DDS canonical route로 redirect하되, redirect 기간·북마크 영향·운영 로그의 옛 경로 표기 방식을 릴리스 결정으로 남긴다.

## 10. 페르소나 최종 판정

| 페르소나 | 최종 요구 |
|---|---|
| UI/UX 전문가 | 설명을 줄이는 것만으로 부족하다. 객체 상태와 다음 행동을 최상단으로 올려야 한다. |
| 보안 설계자 | 두 identity model과 두 반영 방식을 분리하고, immutable 기대 명세·실제 관측·검증 증거를 비교해야 한다. |
| 운영 사용자 | 데모 계정이 아니라 객체×집행 경로별 보호 상태, 관측 신선도, 마지막 게시·검증, 즉시 실행할 조치를 원한다. |

## 11. 구현 착수 게이트와 완료 조건

다음 항목이 #606 설계와 #607 UX에서 승인되기 전에는 #608 화면 구현을 시작하지 않는다.

1. 상태 세 축·대표 상태 우선순위·`PARTIAL`의 승격 금지 규칙을 API contract와 fixture로 확정한다.
2. 토큰 경로와 직접 비교 경로 각각의 immutable 기대 명세, canonical hash, catalog adapter 범위, 게시/권한 변경의 최신성 규칙을 확정한다.
3. 실제 catalog가 비교하지 못하는 필드는 `PARTIAL`로 표기하는 방식을 확정한다.
4. 허용·거부·경계·권한 없음 fixture와 control query, 검증 증거 보존 기간을 확정한다.
5. 대표 상태/근거 배지/다객체·빈·반영 중/오류 상태와 권한별 상세 노출을 와이어프레임으로 확정한다.
6. DDS canonical route와 기존 `/vpd-policies`의 redirect·호환 방식을 릴리스 계획에 기록한다.

구현 완료 조건은 다음과 같다.

1. 기본 화면에는 `dds_demo_*` 카드가 없고, 토큰 기반 서비스 경로의 객체 상태와 추천 조치만 보인다.
2. 동일 객체의 토큰/직접 비교 상태는 분리해 추적할 수 있으며, 한 객체가 두 경로를 함께 지원해도 혼동되지 않는다.
3. 대표 상태는 관측·동기화·검증의 근거 배지와 마지막 관측 시각을 동반하며, 불완전 관측을 정상으로 표시하지 않는다.
4. 기대/실제 선언의 차이는 raw predicate를 불필요하게 노출하지 않고 사용자 영향과 함께 확인할 수 있다.
5. 0건 검색을 권한 차단으로 단정하지 않으며, fixture 기반 허용·거부·경계 검증이 자동화되어 있다.
6. 토큰·비밀번호·차단 TAG·원문·DB 오류 원문이 브라우저와 감사 메모에 누설되지 않는다.
7. 사용자 표면에서 VPD route/용어가 노출되지 않고, 기존 URL은 정의된 호환 정책에 따라 처리된다.
8. 상태 계산, catalog 오류, drift, 검증 freshness, Context 잔류, 기본/고급 탭 분리에 대한 unit·integration·UI 회귀 검증이 있다.
