vpd-permission-poc/docs/design/dds-protection-connection-review

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