docs: detail DDS protection review #581

docs/design/dds-protection-connection-review/README.md

@@ -0,0 +1,111 @@
+# DDS 보호 연결 페이지 상세 리뷰
+
+> **추적성** — Redmine: #581 · 하위 일감: 설계/UX/개발/QA
+>
+> **대상** — `/vpd-policies` (사용자 표면명: DDS 보호 연결)
+>
+> **목적** — 구현 전, 보호 객체 상태와 DDS 집행 경계를 운영자가 판단할 수 있는지 검토한다.
+
+## 1. 이 페이지에서 사용자가 끝내야 하는 일
+
+이 페이지의 1차 사용자는 보안 설계자와 권한 운영자다. 사용자는 다음 네 질문에 답을 얻고 화면을 떠나야 한다.
+
+1. 어떤 보호 객체가 실제로 DDS에 의해 보호되고 있는가?
+2. 그 객체는 토큰 기반 서비스 경로인지, DDS END USER 직접 비교 경로인지?
+3. 공통 권한의 변경이 DATA GRANT에 반영됐고 최근 검증까지 통과했는가?
+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가 공통 권한 테이블 평가 | `END USER → DATA ROLE → DATA GRANT` |
+| 기본 노출 | 기본 화면 | 고급 검증 |
+| 주 사용 빈도 | 일상 운영 | 정책/장애 조사 |
+
+Bearer 값을 DB 변수나 사용자명으로 매핑하는 것만으로 순수 DDS END USER Context가 만들어지지는 않는다. 그래서 기본 서비스 경로와 직접 비교 경로는 같은 탭, 같은 카드, 같은 용어로 다루면 안 된다.
+
+## 4. 보호 객체 상태 모델
+
+| 상태 | 판정 근거 | 화면 문구 | 조치 |
+|---|---|---|---|
+| 정상 | 기대 Grant 정의와 실제 inventory가 일치하고 최근 검증 통과 | 보호 중 | 검색 검증 또는 상세 보기 |
+| 미게시 | 기대 Grant는 있으나 실제 inventory에 없음 | 권한 변경 반영 필요 | 변경 미리보기 |
+| 드리프트 | 객체/Role/predicate/컬럼 범위 중 하나가 기대와 다름 | DDS 선언 차이 발견 | 차이 확인 후 재게시 |
+| 검증 실패 | Grant는 있으나 허용·차단 시나리오가 실패 | 보호 결과 확인 필요 | 접근 근거 조사 |
+| 검증 만료 | 마지막 검증이 권한 또는 Grant 변경보다 이전 | 재검증 필요 | 검색 검증 |
+| 메타데이터 오류 | inventory 또는 권한 원천 조회 불가 | 상태를 확인할 수 없음 | DB/권한 연결 점검 |
+
+역할 수와 권한 규칙 수는 상태를 보조하는 지표일 뿐, 정상 판정 근거가 아니다.
+
+## 5. 필요한 데이터 계약
+
+| 데이터 | 최소 필드 | 원천 | 용도 |
+|---|---|---|---|
+| 기대 Grant 정의 | 보호 객체, Data Role, predicate hash, 제외 컬럼, 권한 기준 버전 | 권한 게시 계획/객체 매핑 | 실제와의 비교 |
+| 실제 Grant inventory | Grant 이름, 객체, Data Role, predicate, 컬럼 범위, 조회 시각 | `DBA_DATA_GRANTS`, 관련 dictionary | 정상/드리프트 판정 |
+| 게시 이력 | 계획 ID, 실행자, 사유, 전후 버전, DB 결과 | 게시 감사 기록 | 변경 추적/복구 |
+| 검증 이력 | 시나리오, 경로, 시각, 결과, 안전한 실패 분류 | 검증 기록 | 최근성/실패 판정 |
+
+상태 계산이 실패했을 때 0건이나 정상으로 폴백하면 안 된다. 메타데이터 오류는 독립 상태다.
+
+## 6. 제안 정보 구조
+
+### 기본: 토큰 기반 서비스 경로
+
+상단에는 전체 상태와 추천 행동 하나를 둔다. 예시는 `1개 보호 객체 반영 필요 → 변경 미리보기`다.
+
+그 아래 객체 표는 다음 열을 사용한다.
+
+| 보호 객체 | 업무 권한 대상 | DATA GRANT 상태 | 마지막 게시 | 마지막 검증 | 조치 |
+|---|---|---|---|---|---|
+
+기술 SQL, predicate 전체 텍스트, dictionary 원문은 객체 상세에서만 펼친다.
+
+### 고급: DDS END USER 직접 비교
+
+`dds_demo_*` 프로필은 이 영역에서만 보여 준다. 표준 명칭은 **직접 비교용 검증 프로필**이다. `연결 설정됨` 대신 아래를 분리한다.
+
+- 자격증명 설정 여부
+- 직접 연결 가능 여부
+- Data Role 매핑 여부
+- 마지막 직접 비교 결과
+
+## 7. 오류와 누설 방지
+
+- 일반 운영 화면에는 권한이 없는 객체의 이름, 금지된 TAG, 원문, predicate 상세를 오류 원인으로 노출하지 않는다.
+- 토큰 경로에서 Grant 정보가 부족하더라도 `권한을 확인할 수 없음`처럼 안전한 상태와 운영자 조치만 표시한다.
+- 직접 비교 프로필의 비밀번호 누락은 서비스 경로의 보호 실패가 아니라 고급 검증 구성 문제로 분리한다.
+- inventory 조회 실패는 반드시 조회 시각과 오류 범위를 표시하고, 정상 상태 배지로 덮지 않는다.
+
+## 8. 페르소나 최종 판정
+
+| 페르소나 | 최종 요구 |
+|---|---|
+| UI/UX 전문가 | 설명을 줄이는 것만으로 부족하다. 객체 상태와 다음 행동을 최상단으로 올려야 한다. |
+| 보안 설계자 | 두 identity model을 분리하고 기대/실제/검증의 세 원천을 비교해야 한다. |
+| 운영 사용자 | 데모 계정이 아니라 객체별 보호 상태, 마지막 게시·검증, 즉시 실행할 조치를 원한다. |
+
+## 9. 완료 조건
+
+1. 기본 화면에는 `dds_demo_*` 카드가 없다.
+2. 각 보호 객체는 정상·미게시·드리프트·검증 실패·검증 만료·메타데이터 오류 중 하나로 표시된다.
+3. 토큰 기반 서비스 경로와 DDS END USER 직접 비교가 탭/배지/도움말로 분리된다.
+4. 기대 Grant와 실제 Grant의 차이를 사용자 영향과 함께 확인할 수 있다.
+5. 사용자 표면에서 VPD route/용어가 노출되지 않는다.
+6. 상태 계산, 드리프트, 오류, 탭 분리에 대한 unit·integration·UI 회귀 검증이 있다.