vpd-permission-poc/docs/design/dds-protection-connection-review/README.md

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

추적성 — Redmine: #581 · 하위 일감: 설계/UX/개발/QA

대상 — /vpd-policies (사용자 표면명: DDS 보호 연결)

목적 — 구현 전, 보호 객체 상태와 DDS 집행 경계를 운영자가 판단할 수 있는지 검토한다.

하위 실행 기준 — #606 설계 · #607 UX · #608 개발 · #609 QA

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 회귀 검증이 있다.