From eea7bf097467cb889e1e184f32a8a318f655237b Mon Sep 17 00:00:00 2001 From: devmrko Date: Tue, 30 Jun 2026 20:03:20 +0900 Subject: [PATCH] docs: detail DDS protection review #581 --- docs/design/dds-persona-ux-review/README.md | 11 ++ .../README.md | 111 ++++++++++++++++++ 2 files changed, 122 insertions(+) create mode 100644 docs/design/dds-protection-connection-review/README.md diff --git a/docs/design/dds-persona-ux-review/README.md b/docs/design/dds-persona-ux-review/README.md index 9783780..97fb8c8 100644 --- a/docs/design/dds-persona-ux-review/README.md +++ b/docs/design/dds-persona-ux-review/README.md @@ -18,6 +18,17 @@ | #584 | 보호 객체 상세 | 실제 접근 근거 탐색 | | #585 | 공통 메뉴·구조 바 | 점진적 공개·용어·접근성 | +### #581 구현 하위 일감 + +| 이슈 | 책임 | 검증 가능한 산출물 | +|---|---|---| +| #606 | 보안 설계 | Grant 기대값·실제 inventory·게시/검증 이력을 비교하는 상태 전이와 API 계약 | +| #607 | UX 설계 | 서비스 경로 기본 화면, 직접 비교 고급 탭, 상태·조치·오류 상태가 담긴 와이어프레임 | +| #608 | 개발 | 객체 상태 화면, 드리프트 판정, 직접 비교 분리와 안전한 오류 처리 | +| #609 | QA | 정상·미게시·드리프트·검증 실패·만료·inventory 오류 및 접근성 회귀 검증 | + +상세 기준은 [`dds-protection-connection-review`](../dds-protection-connection-review/README.md)에 기록한다. #581은 이 네 일감의 완료 조건을 묶는 설계 기준이며, 화면 구현 자체는 #608에서 시작한다. + ## 1. 검토 방식 같은 화면을 세 관점에서 검토했다. diff --git a/docs/design/dds-protection-connection-review/README.md b/docs/design/dds-protection-connection-review/README.md new file mode 100644 index 0000000..2f73f4a --- /dev/null +++ b/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 회귀 검증이 있다.