Oracle ( CDB, PDB )

CDB와 PDB의 구조적 차이

CDB (Container Database)

• 물리적으로 하나의 Oracle 인스턴스 (= 메모리, 프로세스, 백그라운드 공유)
• CDB$ROOT 라는 루트 컨테이너와 최소 1개 이상의 PDB 를 포함
• SYS, SYSTEM 같은 공통 사용(Common User) 계정이 존재
• 인스턴스 차원의 파라미터, 리스너, 기본 보안정책은 여기서 관리

CDB 에서는 로컬유저 생성시 에러를 발생시키며, 생성이 되지 않는다. 오로지 공통 사용자인 Common User 관리자 계정만 생성 가능 하며, 모든 PDB에서 동일한 정체성으로 간주된다.

또한 CDB에서 계정 생성시, 세션권한을 줘야 원격에서 접근이 가능하며 이는 $ORACLE_HOME/network/admin/listener.ora 파일 수정을 해줘야한다.

 

CDB 루트에서 만든 공통사용자(C##)은 모든 PDB에서 동일한 정체성으로 존재, 하지만 각 PDB에서 사용할 권한을 따로 보유해야하며, 객체는 자동공유되지 않음.
로컬 사용자(PDB 생성 스키마)는 해당 PDB에만 존재, 루트에서는 로컬 사용자를 생성할 수 없음.

1. 공통사용자가 유출될 경우 여러 PDB로 확장 접속 시도 가능성이 존재함.
2. 루트에서 CDB_* 뷰는 루트+ 모든 PDB의 메타데이터를 보여줄 수 있다. 
3. 루트와 PDB 이중으로 분리하지 않을 경우, 공통사용자의 활동 감사에 문제가 발생

 

• Oracle 소프트웨어 파일 권한
  • Oracle 설치 디렉터리는 보통 /opt/oracle/product/19c/dbhome_1
  • Oracle 계정/그룹만 접근 가능해야 한다. (chmod 750, chown oracle:oinstall)
• SUID/SGID 권한 점검
  • Oracle 실행 파일(oracle, dbsnmp, extjob)등은 불필요한 SUID 제거
  • 보안가이드: SUID/SGID는 최소화, `/u01/app/oracle` 등에서 `find . -perm -4000 -o -perm -2000` 로 확인
• 환경 변수 보호
  • `$ORACLE_HOME`, `$ORACLE_SID` 등은 `oracle` 계정 전용, 일반 사용자 노출 방지

audit_trail 같은 전역(파라미터)은 CDB에서 한 번에 적용된다.
oralce 같은 설치시 필ㅇ요 파일은 이후 불필요한 SUID 제거 및 실행권한 제거

정리

애플리케이션 스키마/계정은 **로컬 사용자**로, 공통사용자는 최소 권한의 운영 계정으로만 - 공통사용자에 대해 필요 PDB에만 `CREATE SESSION`을 부여하고, 가급적 `SET CONTAINER`는 부여하지 않음. - 루트=공통관리 행위(권한부여, SET CONTAINER, LOGON), PDB=업무 DML/DDL로 정책 이원화하고, 중앙 수집·보존기간·정리 프로세스 확립

공통사용자는 PDB마다 같은 ID로 _존재_하지만, 권한/객체 격리는 설정에 달려 있고, 그 설정을 잘못하면 다수 PDB로 위험이 전파된다.” → 그래서 ID/권한 스코프/가시성/감사/락다운 을 함께 설계해야 안전하다.

PDB (Pluggable Database)

• 논리적으로 독립된 데이터베이스
• 각자 스키마, 사용자(Local User), 객체를 가짐
• 마치 하나의 독립된 DB 처럼 어플리케이션이 붙음
• 같은 CDB 안에 여러 개의 PDB를 붙여서 멀티테넌트(Multi-Teanant) 운영 가능

일반적인 어플리케이션용 스키마는 PDB에서 관리자 권한이 핋요하지 않으며, 이러한 런타임 스키마는 DML/필요 시 제한적 DDL만 갖어야 하며, 최소 권한 원칙이 필요하다.

PDB_ADMIN 과 같은 로컬 관리자 계정은 필요하며, 해당 계정은 해당 PDB에서만 적용됨, 타 PDB나 CDB에는 영향이 없으며, 보안 격리, 운영 자율성, 감사 컴플라이언스 분리를 위해 사용됨.

반대로 CDB 에서 DBA/SYSDBA 권한을 가진 공통사용자(예: SYS, SYSTEM, C##… )’는 여러 PDB에 영향을 줄 수 있음.

오라클 보안점검시 CDB, PDB 별도 점검해야한다.

1. 보안 영역이 분리됨
    - CDB 보안설정이 양호해도, 특정 PDB 안에서 약한 비밀번호 정책, 불필요 권한, PUBLIC 권한 남발이 있으면 그대로 취약점이 된다.
        
2. 운영 방식 변화
    - Oracle 19c부터 Non-CDB 아키텍처는 Deprecated → 신규 설치는 PDB 구조 강제
    - 즉, 현업/실무 환경에서는 CDB + PDB 구조가 기본이다.
        
3. 사용자가 실제로 붙는 곳은 PDB
    - 애플리케이션, 사용자 계정, 테이블, 권한, 네트워크 접근 등은 전부 PDB에 집중
    - 따라서 계정 관리, 권한 점검, 프로파일/비밀번호 정책은 PDB 단위에서 반드시 확인해야 함
        
4. 보안 가이드 준수
    - ISMS-P, 주정통(주요정보통신기반시설 취약점 점검 기준), STIG 모두 최근엔 CDB/PDB 구조를 전제로 점검 항목을 제시
    - 예: `PASSWORD_VERIFY_FUNCTION`, `FAILED_LOGIN_ATTEMPTS`, `AUDIT_TRAIL` 등이 PDB 단위로 적용돼야 함
        

Oracle 12c ~ 19c 이상 환경에서는 기본적으로 CDB + PDB 구조로 이루어져 있다.

• 12c : PDB 구조 도입 (Non-CDB) 허용
• 18c/19c: Non-CDB 아키텍처 Deprecated (더 이상 신규 권장 x)
• 21c: Non-CDB 완전히 제거 -> PDB만 지원

따라서, 요즘 대부분의 서버라면 거의 다 PDB 기반으로 동작중이라고 볼 수 있다.

---

일반 사용자는 `사용자/비밀번호`로, `SYSDBA` 원격 접속은 **비밀번호 파일(orapwd)** 기반.

 

PDB의 영향력

일반적으로 멀티테넌트에서 권한의 범위가 컨테이너 단위로 구분되기에,  PDB 안의 ‘로컬 스키마’에 권한을 과도하게 줘도 CDB(루트)나 다른 PDB의 사전·객체에 직접적인 보안 영향은 없다.