부칙 A. 클라우드 환경 적용
본문은 온프레미스를 전제로 작성됐다. 관리형 데이터베이스에서는 통제 지점이 달라지지만 요구사항 자체는 그대로다. 조문을 고치지 않고, 같은 요구를 클라우드에서 무엇으로 충족하는지 여기에 매핑한다.
요구사항 문장은 클라우드 서비스 제공자와 무관하게 쓴다. 서비스 이름이 필요한 자리에는 괄호로 예시를 붙인다. 이 부칙의 서비스 동작 서술은 Amazon RDS 및 AWS KMS 공식 문서로 확인한 것이다. 다른 관리형 데이터베이스를 쓴다면 같은 항목을 해당 제공자의 현행 문서로 대조한다.
WARNING — 제공자 이름만 바꿔 읽으면 어긋나는 구간이 있다
책임 공유 모델의 서술 방식이 제공자마다 다르다. Azure 는 온프레미스, IaaS, PaaS, SaaS 를 4열 매트릭스로 구분하고 PaaS 에서 애플리케이션과 네트워크 통제를 Shared 로 명시한다. 그리고 데이터, 엔드포인트, 계정, 접근 관리 네 가지는 항상 고객이 유지하는 책임으로 규정한다. Google Cloud 는 책임 공유 모델이 고객이 더 나은 보안 결과에 이르도록 돕는 데까지는 미치지 못한다고 보고 shared fate 를 따로 제시한다. 그러면서 오설정이 침해의 주요 원인이고 사고 대응 경계가 자주 간과된다고 지적한다. 한 제공자의 표를 이름만 치환해 다른 제공자에 옮기면 빈칸이 생긴다.
A-1. 책임 공유 모델
관리형 데이터베이스를 쓰면 일부 통제가 제공자로 넘어간다. 넘어간 것과 남은 것을 구분하지 못하는 것이 감사에서 가장 먼저 걸린다.
| 영역 | 제공자 단독 | 공동 | 우리 단독 |
|---|---|---|---|
| 물리·환경 보안 | 시설·하드웨어·매체 폐기 | — | — |
| 구성 관리 | 기반 인프라 구성 | 서비스 구성 표준과 준수 확인 | 파라미터 그룹·옵션 그룹 설정 |
| 패치 관리 | 엔진·OS 패치 제공 | 적용 시기와 유예 판단 | 유지관리 윈도우 설정, 적용 기록 |
| 인지 및 교육 | 제공자 인력 교육 | 서비스 사용 교육 자료 | 개인정보취급자 교육과 기록 |
| DB 엔진 마이너 버전 | 패치 제공과 적용 실행 | 자동 업그레이드 여부 결정 | 설정값과 변경 이력 기록 |
| DB 엔진 메이저 버전 | — | — | 계획·검증·실행 전부 |
| 네트워크 격리 | 격리 수단 제공 | — | VPC·서브넷·보안그룹 설계와 검증 |
| 계정·권한 | — | — | 발급·회수·점검 전부 |
| 저장 암호화 | 키 관리 서비스 제공 | — | 생성 시점 활성화 결정과 키 정책 |
| 백업·복구 | 백업·복제 메커니즘 동작 | — | 주기·보관기간 설정과 복구 훈련 |
| 감사 로그 | 로그 생성·전달 수단 제공 | — | 활성화, 수집, 보관, 점검 |
위 표에 공동 칼럼을 둔 근거가 있다. AWS 는 통제를 상속(inherited), 공동(shared), 고객 특정(customer specific) 세 가지로 구분하고 패치 관리, 구성 관리, 인지 및 교육을 공동 통제로 분류한다. 제공자와 우리 둘로만 나눈 표에서는 이 공동 통제에서 우리가 맡는 몫이 어느 칸에도 앉지 못한다.
백업 행의 구분선은 Amazon RDS 문서에 근거가 있다. RDS 문서는 백업 생성이나 주 인스턴스와 리드 레플리카 사이의 데이터 복제처럼 RDS 가 관리하는 프로세스라면 고객이 보안 접근을 구성하지 않아도 된다고 명시한다. 즉 메커니즘의 동작은 제공자, 정책(주기·보관 기간·복구 검증)은 이용자다.
IMPORTANT — 물리 보안 항목이 심사에서 빠지는 통로는 따로 있다
관리형 데이터베이스를 쓰면 물리·환경 통제는 제공자에게 상속된다. 그러나 ISMS-P 인증심사에서 물리 보안 항목(2.4.1~2.4.7)이 생략되는 통로는 ISMS-P 고시 제20조의 요건을 충족할 때만 열린다 — ① 국제인정협력기구 가입 인정기관이 인정한 인증기관이 발급한 ISO/IEC 27001 인증 또는 ② 「정보통신기반 보호법」 제9조에 따른 주요정보통신기반시설 취약점 분석·평가다. 신청한 인증 범위 안에 그 인증이나 조치의 범위가 들어 있어야 하고, 심사 시점에 유효하게 유지되고 있어야 한다.
생략 범위는 같은 고시 별표 5 로 정해져 있다 — 2.1.1~2.1.3, 2.2.1~2.2.6, 2.3.1~2.3.4, 2.4.1~2.4.7, 2.12.1~2.12.2. 제공자의 규정 준수 보고서는 이 통로의 근거가 아니다. 보고서는 제공자가 통제를 수행했다는 자료이고, 생략 요건은 우리 쪽 인증 또는 평가의 보유 여부로 판단된다.
IMPORTANT — “제공자가 한다”는 증빙이 아니다
관리형 서비스라도 설정을 켰다는 기록과 그 설정이 유지되고 있다는 점검 기록은 우리가 남겨야 한다. 위 표의 공동 칸이 정확히 그 자리다. 기본값에 의존하고 있다면 그 사실 자체를 판단 근거와 함께 문서로 남긴다.
A-2. 조문별 대응
| 조문 | 온프레미스 전제 | 클라우드에서 |
|---|---|---|
| 제2조 도입 | 장비 반입, 물리 접근 차단 | IaC 로 생성하고, 퍼블릭 액세스 비활성과 프라이빗 서브넷 배치를 코드로 강제한다. PR 리뷰가 승인 기록이 된다 |
| 제3조 계정 신청 | ‘DB계정 사용 신청서’ | 티켓 또는 IaC PR 이 신청서를 대체한다. 승인 이력이 곧 증빙이다 |
| 제3조 권한 내역 3년 보관 | 대장과 결재 문서 보관 | 티켓·PR 이력을 3년 이상 조회 가능한 상태로 보존한다. 저장소 정리 정책이 이 기간을 지우지 않는지 확인한다 |
| 제3조 1인 1계정 | 개인별 DB 계정 발급 | IAM 데이터베이스 인증으로 개인 주체에 매핑한다. 공용 DB 계정 대신 단기 토큰을 쓴다 |
| 제4조 접근제어시스템 | DB 접근제어 어플라이언스 | 배스천 대신 세션 관리 서비스(SSM Session Manager 등)를 쓰고, 세션 로그가 접속기록의 일부가 된다 |
| 제4조 망 분리 | 물리·VLAN 분리 | VPC 분리, 프라이빗 서브넷, 보안그룹 최소 개방. 퍼블릭 액세스 비활성이 1순위 |
| 제4조 안전한 인증수단 | 보안토큰, OTP 기기 | 관리 콘솔과 세션 관리 서비스에 다중 인증을 적용하고, DB 접속은 단기 자격증명으로 발급한다 |
| 제5·6조 암호화 | DB 암호화 솔루션 도입 | 저장 시 암호화를 인스턴스 생성 시점에 고객 관리 키로 켠다. 생성 뒤에는 켤 수 없고 키도 바꿀 수 없다 |
| 제7조 키 관리 | 시건장치 문서함, 관리 대장 | 키 관리 서비스를 쓴다. 대장은 API 감사 로그(CloudTrail 등)가 대체하되 키 소유자·용도·교체 절차는 별도 문서로 남긴다 |
| 제8조 접속기록 | 서버 로컬 로그 | 엔진 감사 기능을 활성화해 로그 서비스나 객체 스토리지로 내보낸다. 제어 평면 조작은 별도 감사 로그로 수집한다 |
| 제8조 보관 기간 | 로그 서버 보존 정책 | 로그 그룹 보존 기간과 객체 스토리지 수명 주기 규칙이 보관 기간의 실체다. 제8조 제3항이 요구하는 기간보다 짧게 설정돼 있지 않은지 확인한다 |
| 제8조 위·변조 방지 | 로그 서버 분리 | 객체 스토리지 버전 관리와 객체 잠금(Object Lock)으로 보관 기간 동안 삭제·변경을 막는다 |
| 제8조 시간 동기화 | NTP 서버 지정 | 제공자의 시각 원천을 사용하고, 로그 수집·분석 구간의 시간대 표기를 하나로 통일한다 |
| 제8조 패치 관리 | 수동 패치 작업 | 유지관리 윈도우와 자동 마이너 버전 업그레이드 설정이 정책의 실체다. 설정값과 변경 이력을 기록한다 |
| 제9조 백업 | 테이프, 소산 보관 | 자동 백업과 특정 시점 복구(PITR), 스냅샷 리전 간 복사가 소산 보관을 대체한다 |
| 제10조 파기 | 장비 반출, 디스크 파기 | 인스턴스 삭제만으로 끝나지 않는다 → A-4 |
| 제11조 수탁자 | 상주 인력 출입 통제 | 위탁 인력에게도 개인별 주체를 발급하고, 세션 및 쿼리 기록을 분리해 남긴다 |
| 제12조 출력·다운로드 | 출력물 통제 | 결과 내보내기 경로를 열거한다 — 콘솔 쿼리 편집기, 객체 스토리지 내보내기, 스냅샷 복원, 리드 레플리카 조회 |
| 제13조 침해사고 | 사내 대응 조직 | 제공자 지원 창구와 통지 경로를 절차에 포함하고, 증거 보존 대상에 제어 평면 감사 로그를 넣는다 |
WARNING — 저장 암호화는 생성 시점에만 켤 수 있고, 키는 바꿀 수 없다
Amazon RDS 는 DB 인스턴스를 만들 때만 암호화를 켤 수 있고 만든 뒤에는 켤 수 없다. 반대로 상속은 자동이며 강제다. 암호화된 인스턴스의 스냅샷, 리드 레플리카, 로그, 자동 백업은 모두 암호화되고, 동일 리전 리드 레플리카는 같은 KMS 키를 써야 한다. 그러므로 점검 항목은 “상속되는지”가 아니라 “생성 시점에 켰는지” 다. 미암호화 백업을 암호화된 인스턴스로 복원하는 것도 되지 않는다.
또한 암호화된 DB 인스턴스를 만든 뒤에는 그 인스턴스가 사용하는 KMS 키를 바꿀 수 없다. 키를 교체하려면 수동 스냅샷을 만들어 다른 키로 복사한 뒤 복원해야 한다. 제7조 제1항 제1호의 유효기간과 제6항의 대체 절차를 관리형 데이터베이스에 적용할 때는 이 복사·복원 절차를 교체 방법으로 명시한다.
A-3. 온프레미스에는 없던 통제 항목
이 지침서 제1조부터 제14조까지에 직접 대응하는 조문이 없는 항목이다. 외부 기준에는 대응 항목이 있다 — ISMS-P 인증기준에는 2.10.2 클라우드 보안 항목이 별도로 있다. 아래 위험은 2.10.2 의 이행 내역으로 관리한다.
- 퍼블릭 노출 — 설정 한 번으로 DB 가 인터넷에 열린다. 퍼블릭 액세스와
0.0.0.0/0보안그룹 규칙은 상시 탐지·차단 대상으로 둔다. - 제어 평면 권한 — DB 에 로그인하지 않아도 스냅샷을 만들어 다른 계정으로 공유하면 데이터가 통째로 나간다. 스냅샷 생성·공유·복원 권한을 DB 접근 권한과 같은 수준으로 통제한다.
- 스냅샷 공유와 키 정책 — 스냅샷을 퍼블릭으로 공유하지 못하도록 조직 정책으로 차단한다. AWS 관리형 키로 암호화한 스냅샷은 애초에 공유할 수 없다. 교차 계정으로 공유하려면 KMS 키를 함께 공유해야 하고, 리전 간 복사에는 대상 리전의 키를 지정해야 한다. 즉 키 정책이 그대로 스냅샷 공유 통제가 된다.
- 설정 드리프트 — 콘솔에서 손으로 바꾼 설정이 IaC 와 어긋난다. 주기적으로 드리프트를 탐지하고 기록한다.
- 태깅 — 소유 부서, 데이터 등급, 개인정보 포함 여부를 태그로 남긴다. 제2조 제2항 제4호의 자산 목록과 사고 시 영향 범위 산정의 기초다.
- 미사용 자원 — 끄지 않은 개발 인스턴스와 오래된 스냅샷은 비용 문제이자 관리되지 않는 데이터 사본이다. 정기 점검 대상에 넣는다.
- 사고 대응 책임 경계 — Google Cloud 는 사고 관리 책임이 자주 간과되고 정의하기 쉽지 않다고 지적한다. 탐지, 통지, 조사 협조, 증거 제공의 주체를 제13조 제4항에 따라 문서로 정한다.
- 클라우드 계정 자체의 루트·조직 권한 — 데이터베이스 통제를 우회하는 최상위 경로다. 루트 자격증명 사용 금지, 조직 수준 정책 변경 권한의 분리, 해당 권한 사용 기록의 상시 점검을 별도 통제로 둔다.
- 키 비활성화·삭제로 인한 가용성 사고 — 키를 비활성화만 해도 인스턴스가 멈춘다. 이 절 끝의 경고를 본다.
WARNING — KMS 키를 비활성화만 해도 인스턴스가 멈춘다
백업이 켜진 DB 인스턴스의 KMS 키를 비활성화하거나 접근할 수 없게 만들면, 탐지 후 2시간 뒤 인스턴스가
inaccessible-encryption-credentials-recoverable상태로 7일간 정지된다. 7일 안에 키를 복구하지 않으면inaccessible-encryption-credentials종료 상태가 되어 백업에서 복원하는 것만 남는다.그러므로 키 정책 변경과 키 비활성화는 삭제와 동일한 승인 대상으로 두고, 어떤 자원이 그 키를 참조하는지 목록을 유지한다. 이 항목은 파기 절차가 아니라 가용성 통제로 관리한다.
A-4. 파기 (제10조 확장)
인스턴스를 지워도 데이터는 남는다. 아래를 모두 확인해야 파기가 끝난다.
- 자동 백업 — 보존 기간이 남은 자동 백업
- 수동 스냅샷 — 인스턴스를 지워도 삭제되지 않는다. 삭제 시 최종 스냅샷을 만들면 최종 스냅샷과 이전에 만든 수동 스냅샷이 함께 남는다
- 보존을 선택한 자동 백업 — 삭제 시점의 보존 기간만큼 유지된다. 삭제는 별도 작업이며, 삭제될 때까지 과금된다
- 리전 간 복제된 자동 백업 — 다른 리전으로 복제된 자동 백업은 “자동 백업 미보존”을 선택해도 유지된다
- 동일 리전 리드 레플리카 — 인스턴스를 삭제하면 각 리드 레플리카가 독립 DB 인스턴스로 자동 승격되어 살아남는다. 확인할 항목이 아니라 자동으로 생존하는 사본이다
- 다른 계정으로 공유한 스냅샷
- 로그 서비스에 남은 DB 로그
- 개발·스테이징으로 복원한 사본
- 키 관리 서비스 키 — 다른 자원이 참조하지 않는지 확인한 후 삭제를 예약한다
삭제 방지(deletion protection)는 콘솔로 만든 인스턴스에서 기본값이 켜짐이다. 삭제 전에 해제해야 하므로 해제 절차 자체를 승인 대상으로 둔다.
WARNING — 삭제 요청 시점과 파기 완료 시점은 다르다
Amazon RDS 는 의도하지 않게 삭제한 인스턴스에 대해 삭제 요청 후 최대 6일간 AWS Support 를 통한 복구 가능성이 있다고 안내한다. KMS 고객 관리 키는 삭제를 예약하면 7일에서 30일(기본 30일) 의 대기 기간이 있고, 실제 삭제는 예약 시점보다 최대 24시간 늦을 수 있다. 대기 기간 중에는 삭제를 취소할 수 있고 그 키로 암호화 작업은 할 수 없다.
그래서 제10조 제4항 제3호가 파기 요청 시점과 파기 완료 시점을 나누어 적게 한다. 두 시점을 하나로 적으면 기록과 실제 상태가 어긋난다.
IMPORTANT — 키 파기 경로가 아예 없을 수 있다
AWS 관리형 키와 AWS 소유 키는 삭제할 수 없다. 기본 키로 암호화했다면 키를 파기하는 경로 자체가 없으므로, 제10조 제1항의 방법을 키 삭제로 대체하려는 설계는 성립하지 않는다. CloudHSM 키 스토어를 사용하는 경우 AWS KMS 는 클러스터 백업의 키 머티리얼을 삭제하지 않으므로, 백업에서 복원한 클러스터가 삭제된 키 머티리얼을 담고 있을 수 있다. 영구 파기에는 해당 클러스터 백업 전부를 삭제해야 한다.
그리고 고시 제13조는 암호 키의 파기를 개인정보 파기 방법으로 규정하지 않는다. 키 삭제를 제10조 제1항 제3호 또는 제3항의 이행으로 주장하려면, 그 논리와 기술적 근거를 문서로 세우고 심사에서 방어할 수 있어야 한다. 키 삭제 절차 자체는 위 체크리스트의 마지막 항목으로 남겨 둔다.
A-5. 백업·복구 (제9조 확장)
제9조 제3항의 백업자료 검증은 클라우드에서 복구 훈련으로 구체화한다. 스냅샷이 있다는 사실은 복구할 수 있다는 증거가 아니다.
- 복구 목표를 숫자로 정한다 — RPO(얼마나 잃어도 되는가), RTO(얼마나 빨리 살려야 하는가)
- 정기적으로 실제로 복원해 본다. 복원 소요 시간을 기록하고 RTO 와 대조한다
- 특정 시점 복구(PITR) 보존 기간이 요구 RPO 를 충족하는지 확인한다
- 이중화는 백업이 아니다. 잘못된
UPDATE나DROP같은 논리적 오류는 Multi-AZ 로 막지 못한다 - 랜섬웨어와 계정 탈취를 상정해 백업을 별도 계정에 격리한다
- 암호화된 인스턴스를 복원할 때 필요한 KMS 키가 대상 계정·리전에서 사용 가능한지 미리 확인한다
복구 훈련을 하면 다음을 기록한다.
- 훈련 일시와 대상 데이터베이스
- 복원 방식 — 특정 시점 복구(PITR) 또는 스냅샷 복원
- 데이터 정합성 확인 방법과 그 결과
- 복원 소요 시간과 RTO 대조 결과
- 발견 사항
- 후속 조치 항목과 담당자
이 목록을 그대로 채우면 ISMS-P 인증기준 2.12.2 재해 복구 시험 및 개선에 제출할 기록이 된다. 훈련 주기는 제9조에서 정한 자체 기준을 따른다.
A-6. 국가·공공기관 대상 서비스
국가·공공기관에 서비스를 제공하는 경우 별도의 클라우드 보안 검증 체계가 적용된다. 검증 체계와 평가 기준은 바뀌는 중이므로 이 지침서에 기준 내용을 옮겨 적지 않는다. 해당 서비스를 착수하는 시점에 현행 기준을 확인하고, 적용 범위와 이행 계획을 별도 문서로 정한다.