Oralcle (Amazon RDS)

Amazon RDS (Relational Database Service)

AWS 에서 제공하는 관리형(Relational) 데이터베이스 서비스로서, 

Amzon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, MSSQL 등을 지원한다.

특징으로는 자동 백업, 패치 관리, 모니터링 제공, 멀티 AZ(가용 영역) 배포로 고가용성을 지원하며 확장성(읽기 전용 리플리카, 자동 스케일링)을 지원한다.

사용자

• 공통 사용자 (Common User)
  • CDB(ROOT)와 모든 PDB에 동일한 ID와 암호로 존재하는 계정
  • 예 : C##ADMIN, SYS, SYSTEM 같은 계정
  • CDB 전체를 관리하는 역할을 가짐
• 로컬 사용자 (Local User)
  • 특정 PDB 안에서만 존재하는 계정
  • 다른 PDB 에는 전혀 영향을 주지 않음.
• RDS 특수 사용자 (rdsadmin)
  • Amazon RDS가 내부 관리용으로 사용하는 공통 계정
  • 사용자가 직접 로그인할 수 없음
  • RDS에서 제공하는 관리 패키지 실행 권한만 존재 (백업/복구, 로그 수집)
    
    

RDS에서 DB 생성 시 지정하는 master user는 PDB 내부의 로컬 계정으로 만들어 진다.

즉, AWS RDS는 루트(CDB) 관리 권한을 직접 주지 않으며, 기본적으로 PDB 레벨 로컬 사용자를 마스터로 지정한다.

사용자가 추가로 만드는 계정 역시 모두 해당 PDB의 로컬 계정으로만 존재

 

RDS의 마스터 사용자(=PDB 로컬 계정)로는 PDB 자체 관리 작업(Create/Alter/Plug 등)은 할 수 없다.

 

RDS 내부적으로 관리용 계정이 존재하고, 이를 통해 RDS 전용 패키지(백업/복구)를 실행할 수 있지만, 사용자가 직접 로그인 할 수 는 없다.

또한, RDS 에서 마스터 사용자 암호는 사용자가 직접 관리하거나, AWS Secrets Manager와 연동해서 자동으로 관리할 수 있다는 것을 의미한다.

정리

• RDS의 마스터 사용자 = 로컬 사용자 (PDB 전용)
• CDB 레벨 관리 권한은 AWS에서 차단 -> 직접 DPV 생성/제어 불가
• rdsadmin = 공통 사용자 (RDS 내부 관리용), 로그인 불가
• 암호는 직접 관리 or AWS Secret Manager로 관리 가능

RDS 정책상 멀티테넌트는 19.0.0.0.ru-2022-01.rur-2022.r1 이상 버전에서만 지원됨

 

CDB 루트(CDB$ROOT)에는 접속할 수 없으며, 항상 특정 PDB 앤드포인트로만 접속해야한다. 접속 시 DB 이름에 pdb_name을 지정해야함.

 

감사(Audit)제약에 따라 CDB$ROOT 레벨에서의 감사 설정이 불가하며, 대신 각 PDB별로 개별적으로 감사 활성화 필요

 

RDS for Oracle(CDB)는 CDB$ROOT로 접속 불가 → 항상 각 PDB(tenant database)로만 접속/점검해야 함. 따라서 보안점검 스크립트는 PDB 단위로 실행하는 것이 원칙

감사(Audit)도 CDB$ROOT에서 켤 수 없고 PDB별로 개별 활성화해야 하므로, 감사 정책/로그 점검 역시 각 PDB마다 수행해야함.

외부 접속 IP차단은 PDB 단위가 아니라, "DB 인스턴스(=CDB 전체)" 단위로 진행
멀티테넌트 RDS for Oralce 에서 모든 PDB가 동일한 엔드포인트와 리스너를 공유하기 떄문
따라서, 보안 그룹(SG)/서브넷 NACL 에서 허용 IP/CIDR을 제한해야함.

AWS는 인바운드 IP 허용/차단을 보안그룹으로 통제하라고 명시. 기본은 차단, 필요한 IP만 허용
즉, 콘솔/.CLI에서 인스턴스 네트워킹 관리

tcp.validnode_checkiong(sqlnet.ora 기반)은 RDS 표준 제품에서는 지원 목록에 존재하지 않음.

백업/업그레이드/유지보수 또한 인스턴스(CDB) 단위로 진행하며 pdb 레벨이 아닌 인스턴스 레벨에서만 지원되는 항목임.

계정/권한감사에 대해서는 각 dpb에 접속해서 개별 설정을 확인해야함

 

요약

RDS for Oracle에서는 CDB$ROOT로 접속이 불가하고 운영·점검용 SQL 세션은 항상 PDB로만 들어감.
따라서 DB 내부 보안점검 스크립트는 PDB별로 실행 하는 것이 원칙

다만 예외적으로, 인스턴스(=CDB 전체) 공통 항목은 DB 밖에서 AWS 콘솔/CLI로 관리·검증
예컨대 보안그룹(IP 허용/차단), 퍼블릭 접근, 백업보존/멀티AZ, 파라미터/옵션 그룹 같은 네트워킹·인프라 설정은 인스턴스 단위이며, 한 번의 설정이 모든 PDB에 공통 적용

또한 감사(Audit)는 RDS 특성상 CDB 루트에서 일괄 적용할 수 없고, 각 PDB에서 개별적으로 정책 생성·활성화 즉, 감사 점검도 PDB 단위


 CDB에서 `C##USER` 같은 공통 사용자가 테이블을 만들면,  
PDB에 접속했을 때도 해당 사용자 계정은 존재하지만, 다만 권한이 없으면 보이지 않음. 단, PDB_ADMIN 같은 로컬 관리자는 기본적으로 공통 사용자 테이블을 볼 권한이 없음
즉, PDB 세션에서는 `CDB$ROOT`의 테이블을 바로 볼 수 없고, 공통 사용자 계정으로 로그인했을 때만 확인할 수 있음.

또한 기본적으로 CDB$ROOT 세션에서는 PDB 내부 스키마(로컬 사용자)와 그 테이블은 보이지 않음.

 

• CDB$ROOT : 데이터베이스 전체를 관리하는 루트 컨테이너. 공통 사용자(C##)와 CDB 전역 객체만 관리
• PDB : 각각 독립된 데이터베이스처럼 동작하는 컨테이너. 로컬 사용자/스키마와 그 테이블은 자기 PDB 안에서만 유효

즉, CDB에만 접속하면 PDB안에서 생성된 로컬 계정의 테이블은 보이지 않으며, CDB 전역뷰 (CDB_TABLES, CDB_USERS 등) ; PDB별 객체를 간접적으로 확인 가능