국내 보안 인증 제도와 Amazon RDS — 활용 적합성 분석

1. 국내 심사 기준과 가장 잘 맞는 저장소

앞서 다룬 Amazon S3 편과 Amazon DynamoDB 편에서 국내 인증 심사와 금융권 점검이 관계형 데이터베이스를 전제로 설계되어 있다는 점을 지적했습니다. Amazon RDS는 그 전제에 가장 부합하는 서비스입니다.

• 데이터베이스 계정이 존재합니다. 계정 관리, 비밀번호 정책, 권한 분리 통제를 심사 기준의 표현 그대로 적용할 수 있습니다.
• 엔진 수준 감사 기능이 제공됩니다. 질의 단위 감사 로그를 확보할 수 있어 접속기록 요건 대응이 용이합니다.
• 네트워크 경로에 프록시를 배치할 수 있습니다. 데이터베이스 접근통제 제품을 인라인으로 구성하는 방식이 가능합니다.
• 스키마가 고정되어 있습니다. 개인정보 항목의 소재와 컬럼 단위 암호화 범위를 문서화하기 쉽습니다.

다만 관리형 서비스이므로 운영체제 접근이 불가하다는 점에서 발생하는 제약이 존재합니다. 에이전트 설치형 보안 제품을 사용할 수 없고, 데이터베이스 서버 파일 권한을 점검 대상으로 삼는 항목은 AWS 책임 영역으로 대체 설명해야 합니다. 이 글은 그 경계를 정리합니다.

2. 제도별 적용 가능성 요약

3. 통제 영역별 RDS 구성 구조

그림 1. 국내 보안 인증 요구사항의 통제 영역과 Amazon RDS 대응 구조

4. 암호화 — 생성 시점에 결정되는 설정

RDS에서 가장 주의해야 할 사항은 스토리지 암호화를 인스턴스 생성 이후에 활성화할 수 없다는 점입니다. 미암호화 상태로 운영 중인 인스턴스를 암호화 상태로 전환하려면 스냅샷을 생성하고, 해당 스냅샷을 암호화 옵션과 함께 복사한 뒤 복원하는 절차가 필요합니다. 서비스 중단이 발생하므로 마이그레이션 계획 단계에서 반영해야 합니다.

미암호화 인스턴스를 암호화 인스턴스로 전환하는 절차

aws rds create-db-snapshot \
  --db-instance-identifier legacy-db \
  --db-snapshot-identifier legacy-db-snap

aws rds copy-db-snapshot \
  --source-db-snapshot-identifier legacy-db-snap \
  --target-db-snapshot-identifier legacy-db-snap-enc \
  --kms-key-id alias/rds-compliance-cmk

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier prod-db \
  --db-snapshot-identifier legacy-db-snap-enc \
  --db-subnet-group-name private-db-subnet-group \
  --no-publicly-accessible

5. 계정 및 접근 통제

데이터베이스 계정이 존재하므로 심사 기준의 계정 관리 항목을 직접 적용할 수 있습니다. 다만 관리형 서비스 특성상 마스터 사용자에게 완전한 관리자 권한이 부여되지 않으며, 일부 시스템 권한은 AWS가 보유합니다. 이는 권한 최소화 측면에서 유리하게 설명할 수 있는 요소입니다.

2.5인증 및 권한 관리

6. 감사 로그 — 기본 보존 기간이 짧습니다

RDS는 엔진 수준의 감사 기능을 제공하므로 질의 단위 접속기록을 확보할 수 있습니다. 그러나 인스턴스에 저장되는 로그 파일은 보존 기간이 짧아 순환 삭제됩니다. 법령이 요구하는 1년 또는 2년 보관을 충족하려면 CloudWatch Logs로 내보내고 로그 그룹의 보존 기간을 명시적으로 설정해야 합니다. CloudTrail은 인스턴스 생성·변경과 같은 관리 이벤트만 기록하며, 데이터베이스 내부 질의는 기록하지 않습니다.

감사 로그 구성 시 다음 사항을 함께 결정해야 합니다.

• 기록 범위 — 전체 질의를 기록하면 성능 영향과 비용이 큽니다. 개인정보 테이블에 대한 접근과 권한 변경을 우선 대상으로 지정합니다.
• 보존 기간 — 로그 그룹 보존 기간을 적용 법령 기준 이상으로 설정하고, 장기 보관이 필요하면 S3로 아카이브합니다.
• 처리 목적 기록 — 접속기록에는 처리 목적과 대상 정보주체가 요구됩니다. 엔진 감사 로그는 질의문을 남기지만 목적을 설명하지 않으므로 애플리케이션 감사 로그가 함께 필요합니다.
• 로그의 개인정보 포함 — 질의문에 조건 값이 포함되므로 감사 로그 자체가 개인정보 파일이 될 수 있습니다. 로그 저장소에도 동일한 수준의 암호화와 접근 통제를 적용해야 합니다.

7. 보존과 파기 — 행 삭제로 끝나지 않습니다

개인정보는 보유 기간이 경과하면 복구·재생되지 않도록 파기해야 합니다. 관계형 데이터베이스에서 행을 삭제하더라도 다음 위치에 데이터가 남을 수 있습니다.

• 자동 백업 — 설정된 보존 기간 동안 삭제 이전 시점으로 복원할 수 있습니다.
• 수동 스냅샷 — 보존 기간이 자동으로 만료되지 않으므로 수년간 남아 있는 사례가 많습니다. 파기 절차에서 가장 빈번하게 누락되는 대상입니다.
• 바이너리 로그 및 트랜잭션 로그 — 복제 용도로 보존 시간이 설정된 경우 변경 이력에 값이 남습니다.
• 읽기 전용 복제본 — 복제 지연 구간과 복제본 자체의 백업을 확인해야 합니다.
• 테이블 내부 여유 공간 — 삭제된 행의 물리적 영역이 즉시 회수되지 않습니다. 필요한 경우 테이블 재구성 작업을 수행합니다.

따라서 파기 절차는 다음 순서로 설계합니다.

1. 보유 기간 경과 데이터를 식별하고 행 삭제 또는 비식별 처리를 수행합니다.
2. 자동 백업 보존 기간을 보유 기간과 정합하게 설정하여, 만료 시점에 복원 가능성이 소멸되도록 합니다.
3. 수동 스냅샷 목록을 전수 점검하고, 보존 근거가 없는 스냅샷을 삭제합니다. 다른 계정에 공유된 스냅샷이 있는지 함께 확인합니다.
4. 복제본과 로그 보존 설정을 확인하고 동일한 규칙을 적용합니다.
5. 인스턴스 자체를 폐기하는 경우 최종 스냅샷 생성 여부를 결정하고, 암호화에 사용한 고객 관리형 키를 삭제하여 암호학적 파기를 완결합니다.
6. 파기 수행 결과를 기록으로 남깁니다.

8. 취약점 점검 항목의 대체 설명

국내 데이터베이스 취약점 점검 항목에는 운영체제 수준의 확인이 필요한 항목이 포함되어 있습니다. 관리형 서비스에서는 해당 접근이 불가하므로, 점검 불가 사유와 대체 통제를 함께 기술해야 합니다.

9. 데이터 소재 및 가용성

금융 부문의 국내 소재 요건과 개인정보 국외 이전 규정을 고려하여 다음 항목을 점검합니다. 다중 가용영역 구성은 리전 내에서 이루어지므로 소재 요건과 충돌하지 않으며, 오히려 가용성 통제 항목의 증적으로 활용할 수 있습니다.

• 서울 리전 외 인스턴스와 스냅샷이 존재하지 않는지 조직 전체 계정을 대상으로 점검합니다.
• 국외 리전 읽기 전용 복제본과 교차 리전 자동 백업 복제 설정이 없는지 확인합니다.
• 글로벌 데이터베이스 구성 여부를 확인하고, 재해 복구 요건을 국내 가용영역 구성과 백업 기반 복구로 대체할 수 있는지 검토합니다.
• 서비스 제어 정책으로 허용 리전을 제한하여 구조적으로 차단합니다.
• 다중 가용영역 배치, 자동 장애 조치, 복구 시험 기록을 가용성 통제 증적으로 정리합니다.

10. 제도별 통합 매핑 표

11. 심사 대비 점검 항목

암호화

• 모든 인스턴스와 스냅샷에 스토리지 암호화가 적용되어 있는지 확인
• 고객 관리형 키를 사용하고 자동 교체가 활성화되어 있는지 확인
• 파라미터 그룹에서 SSL/TLS 강제 설정이 적용되어 있는지 확인
• 서버 인증서 만료일이 자산 목록에 등록되고 교체 계획이 수립되어 있는지 확인
• 고유식별정보 등 의무 대상 항목에 컬럼 단위 암호화를 적용했는지 확인
• KCMVP 적용 대상 정보에 대해 검증 모듈 기반 암호화 절차를 수립했는지 확인

계정 및 접근 통제

• 퍼블릭 액세스가 비활성화되고 프라이빗 서브넷 그룹에 배치되어 있는지 확인
• 보안 그룹 인바운드에 넓은 범위의 소스가 허용되어 있지 않은지 확인
• 애플리케이션 계정과 사람이 사용하는 계정이 분리되어 있는지 확인
• 마스터 계정이 일상 운영에 사용되지 않는지 확인
• Secrets Manager 자동 교체 또는 IAM 인증이 적용되어 있는지 확인
• 불필요한 기본 계정과 샘플 스키마가 삭제되었는지 확인
• 분기별 권한 검토 기록이 보관되어 있는지 확인

감사 로그

• 엔진 감사 기능이 활성화되어 있는지 확인
• 감사 로그가 CloudWatch Logs로 내보내지고 있는지 확인
• 로그 그룹 보존 기간이 적용 법령 요구 기간(1년 또는 2년) 이상인지 확인
• 권한 변경과 접속 실패 기록이 감사 대상에 포함되어 있는지 확인
• 처리 목적과 담당자를 포함한 애플리케이션 감사 로그가 존재하는지 확인
• 감사 로그 저장소에 암호화와 접근 통제가 적용되어 있는지 확인
• 월 1회 이상 로그 점검 기록이 남아 있는지 확인

보존 및 파기

• 자동 백업 보존 기간이 보유 기간 정책과 정합한지 확인
• 보존 근거가 없는 수동 스냅샷이 남아 있지 않은지 전수 점검
• 다른 계정에 공유된 스냅샷이 존재하지 않는지 확인
• 바이너리 로그 및 복제본의 보존 설정을 확인
• 삭제 방지 설정과 최종 스냅샷 정책이 파기 절차와 모순되지 않는지 확인
• 파기 수행 기록이 별도로 관리되는지 확인
• 불변 보존 요건 대상 기록에 백업 볼트 잠금을 적용했는지 확인

데이터 소재 및 가용성

• 서울 리전 외 인스턴스와 스냅샷이 존재하지 않음을 확인
• 국외 리전 복제본과 교차 리전 백업 복제가 없음을 확인
• 다중 가용영역 구성과 장애 조치 시험 기록을 확인
• 공공 대상 시스템의 경우 CSAP 인증 범위 내 데이터베이스를 사용하고 있는지 확인

12. 결론

Amazon RDS는 국내 보안 인증 제도의 기술적 요건에 가장 자연스럽게 대응되는 저장소입니다. 데이터베이스 계정과 엔진 감사 기능이 존재하므로 심사 기준의 표현을 그대로 적용할 수 있고, 접근통제 제품을 인라인으로 배치하는 구성도 가능합니다. 다음 네 가지는 설계 단계에서 확정해야 합니다.

1. 암호화는 생성 시점에 결정됩니다. 사후 전환은 스냅샷 복원과 서비스 중단을 수반하므로 마이그레이션 계획에 반영해야 합니다.
2. 감사 로그는 내보내지 않으면 남지 않습니다. 감사 활성화, 로그 내보내기, 보존 기간 설정을 하나의 묶음으로 구성해야 합니다.
3. 수동 스냅샷이 파기의 사각지대입니다. 보존 기간이 자동으로 만료되지 않으므로 전수 점검 절차가 필요합니다.
4. 운영체제 수준 점검 항목은 대체 설명이 필요합니다. 점검 불가 사유와 AWS 책임 범위를 통제 대응표로 정리해 두어야 합니다.

공공 부문은 CSAP 인증 범위, KCMVP 적용 대상 정보는 검증 암호모듈 사용이라는 제도적 제약이 선행하므로, 저장소 선택은 아키텍처 초기 단계의 의사 결정 사항이 됩니다.

세 편에 걸쳐 살펴본 결론은 동일합니다. 국내 인증 제도는 서비스의 기능 보유 여부가 아니라 조직의 설정과 운영 기록을 심사합니다. 파라미터 그룹과 백업 정책을 코드로 관리하고, AWS Config 및 Security Hub의 준수 현황을 정기적으로 보관하시기 바랍니다. 제이씨클라우드는 ISMS-P 및 금융권 요건에 대응하는 데이터베이스 설계와 컴플라이언스 자동 점검 체계 구축을 지원하고 있습니다.

참고 자료

• 정보보호 및 개인정보보호 관리체계 인증 등에 관한 고시 — 과학기술정보통신부·개인정보보호위원회
• 개인정보의 안전성 확보조치 기준 — 개인정보보호위원회
• 클라우드컴퓨팅서비스 보안인증에 관한 고시 — 과학기술정보통신부
• 전자금융감독규정 및 금융분야 클라우드컴퓨팅서비스 이용 가이드 — 금융위원회·금융보안원
• 암호모듈 검증제도(KCMVP) 안내 — 국가정보원 국가사이버안보센터
• 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세 가이드 — 한국인터넷진흥원
• Amazon RDS 사용자 안내서 — 저장 시 암호화, SSL 연결, 데이터베이스 로그, 백업 및 복원 항목

시리즈 글: Amazon S3 편 · Amazon DynamoDB 편 · ISMS-P 대응 인프라 구성 · 컴플라이언스별 패스워드 정책 비교