5.4 KiB
DDS Permission Console
dds-backoffice는 기존 VPD 데모와 코드·프로세스·포트·보호 객체를 분리한 Deep Data Security 전용 데모입니다.
- 기본 포트:
8083 - 기본 화면:
/(공통 권한 여정),/dds(DDS 직접 조회 검증) - 권한 반영:
/dds-provision(공통 권한을 DDS DATA GRANT로 미리보기·게시) - 기본 보호 객체:
ADMIN.V_DDS_CUSTOMERS_PG,ADMIN.V_DDS_CUSTOMERS_MY - 지식 검색 보호 객체:
ADMIN.CB_DDS_VECTOR_SEARCH_DOCUMENTS - DDS 전용 사용자:
dds_demo_my,dds_demo_pg,dds_demo_both,dds_demo_none - 조회 방식: 선택한 DDS
END USER자격으로 직접 Oracle JDBC 연결
두 데모의 관계
두 인스턴스는 프로세스·포트·실행 경계를 분리하지만, 화면에서 설명하는 관리 순서는 같습니다.
사용자·그룹·역할 → 데이터 권한 규칙 → DDS Grant 게시 → 보호 연결 → 실제 결과 확인
8083 DDS 화면의 /users, /groups, /roles, /permissions, /effective-matrix는 8082 VPD 화면과 같은 관리 기준을 보여줍니다. 다만 보호를 실행하는 DB 계층만 다릅니다. VPD 인스턴스는 공통 DB 계정과 Bearer 컨텍스트로 동적 predicate를 계산하고, DDS 인스턴스는 DDS END USER의 DATA ROLE/DATA GRANT로 직접 집행합니다.
/dds-provision은 이 차이를 연결하는 명시적 배포 단계입니다. 직접 역할과 활성 그룹에서 상속된 역할을 합쳐 사용자별 유효 권한을 계산하고, 애플리케이션 객체 매핑을 거쳐 CREATE OR REPLACE DATA GRANT SQL을 미리 보여줍니다. 그룹을 DDS 그룹으로 복사하지 않고, 그룹이 상속한 역할을 해당 DDS DATA ROLE의 최종 predicate로 합칩니다. 매핑되지 않은 객체는 경고로 남기고 게시하지 않습니다.
| 데모 | 사용자 식별 | 정책 표현 | 권한 변경 |
|---|---|---|---|
| VPD | 공통 계정 + Bearer/세션 컨텍스트 | 동적 predicate 함수 | 업무 권한 테이블 |
| DDS | DDS END USER 또는 보안 컨텍스트 |
DATA ROLE + DATA GRANT |
선언형 DDL/Grant |
따라서 두 인스턴스의 관리 흐름과 기대 결과는 맞출 수 있지만, Bearer 요청마다 권한을 계산하는 VPD 실행 모델을 DDS가 그대로 대체하는 것은 아닙니다. DDS로 Bearer 기반 호출을 운영하려면 지원 드라이버의 EndUserSecurityContext 전파가 별도로 필요합니다.
권한 변경 후에는 다음 순서로 확인합니다.
1. /permissions에서 사용자·그룹·역할·행/TAG·컬럼 기준을 저장
2. /dds-provision에서 사용자별 predicate와 제외 컬럼을 검토
3. 승인된 경우에만 DDS DATA GRANT 게시
4. /dds 또는 /vector-knowledge에서 END USER별 결과를 검증
이 앱의 조회 경계는 다음과 같습니다.
END USER → DATA ROLE → DATA GRANT → DDS 보호 VIEW → 조회 결과
ORDS Handler가 Bearer 값을 cb_dds_hr 같은 문자열로 매핑하는 것만으로는 DDS 보안 컨텍스트가 전달되지 않습니다. 따라서 이 비교 인스턴스는 DDS END USER 직접 logon을 검증합니다. Bearer/ORDS 전달이 필요하면 지원 드라이버의 EndUserSecurityContext를 별도 설계해야 합니다.
실행
먼저 DDS 데모 전용 로컬 데이터셋과 권한 객체를 적용합니다. 이 스크립트는 VPD VIEW나 외부 RDS DB Link를 사용하지 않습니다.
sqlplus "$ADB_USER/$ADB_PASSWORD@$ADB_TNS" @sql/adb/31_dds_standalone_demo_setup.sql
sqlplus "$ADB_USER/$ADB_PASSWORD@$ADB_TNS" @sql/adb/32_dds_vector_tag_setup.sql
32_dds_vector_tag_setup.sql은 공통 청크·태그 저장소를 읽는 DDS 전용 VIEW를 만들고, 동일한 CB_PERMISSION/CB_PERMISSION_RULE에 역할별 TAG 규칙을 등록합니다. SPRING_BOOT, ORDS, ORACLE_VPD, MCP처럼 한 역할에 여러 TAG가 있으면 /dds-provision이 OR 조건으로 합쳐 DDS DATA GRANT를 다시 만듭니다. 벡터 검색에 필요한 EMBEDDING은 DDS 엔진이 거리 계산에 사용하므로 Grant에서 제외하지 않고, 검색 응답에서는 애플리케이션이 반환하지 않습니다. 그 외 민감 컬럼은 애플리케이션 권한의 원문 허용 목록에 없으면 ALL COLUMNS EXCEPT로 제외됩니다. 검색 화면에서는 같은 문서를 청킹·임베딩한 뒤 선택한 END USER로 직접 조회하므로, DDS Grant가 없는 주체는 보호 VIEW 자체를 볼 수 없습니다.
그 다음 DDS 인스턴스를 실행합니다.
cd dds-backoffice
export DDS_BACKOFFICE_DB_URL="${BACKOFFICE_DB_URL}"
export DDSUSER_MY_PASSWORD='...'
export DDSUSER_PG_PASSWORD='...'
export DDSUSER_BOTH_PASSWORD='...'
export DDSUSER_NONE_PASSWORD='...'
mvn -DskipTests package
java -jar target/dds-permission-backoffice-0.1.0-SNAPSHOT.jar
관리자 로그인은 DDS_BACKOFFICE_ADMIN_USER / DDS_BACKOFFICE_ADMIN_PASSWORD를 사용합니다. DDS END USER 비밀번호는 서버 환경 변수로만 읽고 화면에 표시하거나 저장하지 않습니다.
VM 배포는 scripts/deploy-dds-backoffice-vm.sh를 사용합니다. 스크립트는 기존 /home/opc/apps/vpd-backoffice의 wallet과 환경값을 읽어 /home/opc/apps/dds-backoffice를 별도 프로세스로 기동합니다. 기본 바인딩은 127.0.0.1:8083이며, 인터넷 공개는 HTTPS reverse proxy와 NSG/firewall 승인을 별도로 거쳐야 합니다.