데이터 접근 제어

행 접근과 컬럼 마스킹 운영 흐름

업무 사용자와 데이터 접근 기준을 관리하고, DB가 적용한 결과까지 확인합니다.

도움말: 메뉴와 권한 적용 구조 보기

왜 권한 테이블을 따로 관리하나요?

DB 연결은 공용 실행 계정 하나로 유지하되, 실제 업무 사용자는 CB_APP_USER와 역할·권한 테이블에서 찾습니다. 요청마다 토큰이 사용자를 식별하고 행 접근 정책이 그 사용자의 행 조건을 계산하며, 컬럼 원문/마스킹은 ASO/Data Redaction 정책이 별도로 판단합니다.

메뉴 안내

처음 설정할 때의 순서

권한을 먼저 만들고 보호 대상을 연결한 뒤, 실제 사용자 토큰으로 결과를 검증합니다. 권한은 토큰에 복사되지 않아 이후 변경도 다음 요청부터 반영됩니다.

데이터 접근 제어 설정과 검증 순서 사용자와 그룹, 역할, 행 접근 규칙, 컬럼 마스킹, 보호 대상을 차례로 설정하고 실제 조회 결과를 검증하는 흐름 1사용자·그룹업무 대상을 등록 2역할직접·그룹 역할 부여 3행 접근 규칙객체·행 조건 설정 4보호·연결정책·ORDS 대상 확인 5유효 권한·접근 검증토큰으로 실제 결과 확인 규칙 변경은 다음 요청의 행 조건 계산에 동적으로 반영됩니다.

요청마다 권한이 적용되는 흐름

행 접근 적용 흐름 Bearer Token 요청이 공용 실행 계정과 사용자 컨텍스트를 거쳐 권한 테이블에서 계산한 행 조건으로 보호 데이터를 조회하는 흐름 요청·토큰Bearer Token 공용 실행 계정CB_ORDS한 개의 DB 연결 사용자 컨텍스트CB_AGENT_CTX사용자별로 설정 행 조건 계산ALLOW · DENY · predicate 보호 데이터 조회허용된 행 반환 사용자 · 역할 · 권한 테이블요청 시 동적으로 조회

권한 데이터 모델

접근 제어 ERD 사용자와 그룹에서 역할을 얻고 역할에서 권한과 권한 규칙을 거쳐 보호 대상으로 연결되는 데이터 모델 CB_APP_USER업무 사용자 CB_USER_ROLE직접 역할 연결 CB_APP_ROLE역할 CB_PERMISSION객체 접근 CB_PERMISSION_RULE행 조건 매핑 보호 대상TABLE / VIEW CB_USER_GROUP그룹 소속 CB_GROUP사용자 그룹 CB_GROUP_ROLE그룹 역할 연결 CB_AGENT_BEARER_KEY토큰 → 사용자 식별

실행 SQL은 어디에서 확인하나요?

DB 감사 실행 증적은 FGA가 남긴 실제 실행 SQL과 VPD RLS 정보를 보여줍니다. 화면의 SQL 재현은 설정을 이해하기 위한 참고용이며, 실행 증적과 구분합니다.

데이터 처리 오류가 발생했습니다.
./run.sh backoffice-support
전체 그림

토큰은 사용자를 식별하고, DB 정책이 행과 컬럼을 나눠서 제어합니다

이 백오피스는 토큰 자체에 권한을 복사하지 않습니다. 요청 시점에 토큰으로 사용자를 찾고, 저장된 역할·규칙을 DB 세션 context와 VPD/ASO 정책에 반영합니다.

1. 사용자 식별
Bearer Token으로 CB_AGENT_CTX에 사용자·부서·이해관계자 정보를 설정합니다.
2. 행 접근(VPD)
행 접근 규칙이 대상 테이블의 WHERE predicate로 변환되어 볼 수 있는 행만 남깁니다.
3. 컬럼 마스킹(ASO)
허용된 행 안에서 민감 컬럼을 원문으로 줄지, 마스킹해서 줄지 결정합니다.
4. 접근 검증
토큰으로 실제 ORDS 조회를 실행하고, 결과 행·마스킹 컬럼·감사 증적을 확인합니다.
업무 흐름

바로 시작

  1. 사용자역할을 준비합니다.
  2. 행 접근 규칙에서 역할별 대상 객체와 행 조건을 저장합니다.
  3. 보호 상태에서 대상 테이블의 VPD 연결 상태를 확인합니다.
  4. 컬럼 마스킹에서 민감 컬럼의 ASO 정책을 연결합니다.
  5. 검증 세션을 발급하고 접근 검증에서 실제 결과를 확인합니다.
등록 대상 상세

현재 검증 가능한 데이터

행 접근 규칙과 ORDS 경로가 등록된 보호 객체입니다.

접근 검증
데이터 객체검증 경로상태
ADMIN.OBJECT path 사용 가능
아직 검증할 보호 객체가 없습니다. 행 접근 규칙에서 객체 접근을 먼저 등록하세요.