# MCP·VPD·Data Redaction·DDS 공통 운영 가이드

## 1. 적용 범위와 책임

이 문서는 고객사와 데이터 도메인에 무관하게 사용하는 공통 운영 절차다. 고객별 테이블,
지표, 질문 예제, Select AI 프로파일은 각 고객사 브랜치 문서에서 관리한다.

| 구성요소 | 책임 | 운영자가 확인할 것 |
| --- | --- | --- |
| MCP | 허용 도구를 공개하고 요청·응답 계약을 제공 | `tools/list`, 입력 스키마, 인증 |
| Select AI | 읽기 전용 SQL 생성 및 실행 | 허용 객체, SQL 검증, timeout |
| VPD | 행 단위 접근 제어 | session context, policy, predicate |
| Data Redaction (ASO) | 민감 컬럼 값의 NULL/마스킹 | 대상 컬럼, policy, 예외 사용자 |
| DDS | 선언형 행·컬럼·작업 권한 | END USER, DATA ROLE, DATA GRANT |
| FGA | 실행 증적 감사 | 요청 식별자, SQL, RLS 정보 |

VPD와 Data Redaction은 서로 대체하지 않는다. VPD는 **어떤 행을 볼 수 있는지**,
Data Redaction은 허용된 행에서 **컬럼 값을 어떻게 표시할지**를 담당한다. DDS는
`DATA GRANT`로 행·컬럼 권한을 선언적으로 적용하는 별도 경로다.

## 2. 공통 실행 흐름

```text
사용자/Agent
  → MCP initialize · tools/list · tools/call
  → Bearer 또는 서비스 인증 검증
  → 허용된 도구와 입력 스키마 확인
  → DB session context 또는 DDS END USER context 설정
  → Select AI SHOWSQL 생성
  → SELECT/WITH 전용 검증과 read-only 실행
  → VPD 행 필터 + Data Redaction 또는 DDS 권한 적용
  → 결과·생성 SQL·감사 식별자 반환
```

MCP 또는 애플리케이션은 사용자 입력을 VPD predicate나 SQL 조각으로 조합하지 않는다.
권한 판단은 DB 정책·권한 테이블·DDS grant에서 수행한다.

## 3. 최초 구성 순서

1. `database/adb/`의 기본 스키마, 권한 테이블, 보호 View를 적용한다.
2. VPD context package·policy function을 compile하고 `DBA_POLICIES`에서 적용 대상을 확인한다.
3. 민감 컬럼에는 Data Redaction policy를 적용하고 권한별 조회 결과를 확인한다.
4. DDS를 사용할 경우 END USER, DATA ROLE, DATA GRANT를 별도 구성한다. 단순 Bearer 값 조회만으로 DDS END USER가 되지 않는다.
5. MCP endpoint와 공개 도구 목록을 설정한다. 광고한 모든 도구는 실제로 호출 가능해야 한다.
6. SELECT/WITH 이외 문장 차단, read-only transaction, query timeout, 반환 행 제한을 설정한다.
7. 사용자별 허용/거부, 마스킹, 감사 증적을 회귀 검증한다.

## 4. MCP 운영 절차

### 기동 전

- 환경변수·DB 연결·wallet·MCP endpoint를 점검한다.
- 도구 이름, 설명, 입력 스키마가 실제 구현과 일치하는지 확인한다.
- 실제 token, password, wallet, 대화 이력 DB는 Git에 넣지 않는다.

### 요청 처리

1. `initialize` 후 협상된 프로토콜 버전을 사용한다.
2. `tools/list` 결과 중 승인된 도구만 호출한다.
3. `tools/call` 입력을 서버에서 검증한다.
4. 생성 SQL과 실행 결과, 오류 사유를 분리해 반환한다.
5. 실패 시 임의 SQL 재시도 대신 도구 상세·SHOWPROMPT·DB audit을 확인한다.

## 5. VPD와 Data Redaction 점검

| 증상 | 우선 확인 |
| --- | --- |
| 권한 있는데 0행 | session context, VPD predicate, 권한 매핑 |
| `ORA-00942`/`ORA-01031` | DB object grant와 보호 View 노출 여부 |
| 컬럼이 NULL/마스킹됨 | Data Redaction policy와 예외 조건 |
| 다른 사용자 결과가 같음 | Bearer→업무 사용자 매핑, context clear |
| 요청 추적 불가 | `CLIENT_IDENTIFIER`, FGA/Unified Audit Trail |

VPD 정책 변경 전에는 대상 View·TABLE, 기존 policy, 함수 상태를 백업하고, 변경 후
허용 사용자·거부 사용자·마스킹 예외 사용자를 모두 조회한다. 롤백은 policy/function 및
권한 매핑을 직전 검증 상태로 되돌린 뒤 같은 회귀 시나리오로 확인한다.

## 6. DDS 사용 기준

- 사용자별 `END USER` context를 실제 DB 호출에 전달할 수 있으면 DDS를 고려한다.
- 서비스 계정의 client-credentials token은 서비스 인증용이며 업무 사용자 권한을 뜻하지 않는다.
- 권한이 자주 바뀌면 사용자별 grant 복제보다 공통 role과 런타임 권한 함수를 검토한다.
- VPD와 DDS를 같은 보호 객체에 함께 적용할 때는 정책 순서와 예상 결과를 별도 검증한다.

## 7. 검증과 증적

최소 검증 세트는 다음과 같다.

1. 인증 성공/실패와 `tools/list` 계약
2. 허용 사용자와 거부 사용자의 행 수 차이
3. 민감 컬럼의 Redaction 결과
4. 읽기 전용 SQL 차단 규칙과 timeout
5. FGA 또는 Unified Audit Trail의 SQL·RLS 정보·요청 식별자

상세 SQLcl 절차는 [VPD 배포·검증·롤백 런북](460-sqlcl-vpd-deploy-runbook.md)을,
설계 근거는 [ORDS·VPD·DDS 보안 설계](../06-agent-ords-vpd-dds-security-brief.md)를 따른다.