클라우드 환경에서 ISMS-P 요구사항 충족하는 방법
2023년 개인정보보호위원회가 공개한 과징금 부과 현황에 따르면, 제재를 받은 기업 중 상당수가 클라우드 기반 인프라를 운영하면서 접근통제·암호화·로그 관리 항목에서 결함을 지적받았습니다. ISMS-P 인증기준 101개 항목은 온프레미스를 전제로 설계된 것처럼 보이지만, 실제 심사에서는 클라우드 구성 자체가 증거로 제출됩니다. 콘솔 캡처 한 장이 결함의 근거가 되기도 합니다.
클라우드가 ISMS-P 심사에서 어려운 진짜 이유
온프레미스 환경에서는 물리적 장비와 네트워크 장비가 통제 대상임이 직관적으로 명확합니다. 반면 클라우드는 책임 공유 모델(Shared Responsibility Model) 구조상, 어디까지가 클라우드 사업자의 책임이고 어디서부터가 고객사 책임인지 경계가 모호합니다.
ISMS-P 인증기준 2.10.1(보안시스템 운영) 항목은 침입탐지·방화벽 등 보안시스템의 운영 현황을 요구합니다. AWS Security Group이나 Azure NSG로 방화벽을 대체할 경우, 심사원이 이를 동등한 통제수단으로 인정받으려면 해당 설정의 정책 문서화와 변경이력 로그가 모두 갖춰져야 합니다. 콘솔 화면만으로는 부족합니다.
또 다른 쟁점은 2.6.4(데이터베이스 접근) 입니다. RDS나 Cloud SQL처럼 관리형 DB를 사용할 때 DBA 전용 계정 분리, 쿼리 로그 보존 여부가 점검됩니다. 기본 설정으로 운영하면 쿼리 로그가 비활성화 상태인 경우가 많아, 심사 직전에 급하게 활성화하다 "사후 조치"로 감점받는 사례가 반복됩니다.
세 가지 핵심 통제 영역과 실무 쟁점
1. 접근통제 — IAM 설계가 증거가 됩니다
ISMS-P 인증기준 2.5.1(사용자 계정 관리) 과 2.5.2(사용자 인증) 은 클라우드 IAM 구성으로 직접 심사됩니다. 심사원은 실제 IAM 정책 JSON이나 역할 바인딩 목록을 요청합니다.
실무에서 자주 발생하는 문제는 두 가지입니다.
- 과도한 와일드카드 권한:
"Action": "*"또는"Resource": "*"형태의 정책이 운영 계정에 붙어 있으면 최소권한 원칙 위반으로 즉시 결함 처리됩니다. - 공용 액세스 키 미삭제: 퇴직자 또는 프로젝트 종료 후에도 삭제되지 않은 IAM 액세스 키가 존재하면 2.5.6(접근권한 검토) 결함으로 연결됩니다.
권고 조치는 단순합니다. IAM Access Analyzer 또는 동등 도구로 분기 1회 이상 미사용 권한을 식별하고, 그 결과를 문서로 보존하면 됩니다.
2. 암호화 — 설정이 아닌 정책이 필요합니다
개인정보 보호법 제29조와 ISMS-P 2.7.1(암호정책 적용) 은 개인정보가 포함된 데이터의 저장 및 전송 구간 암호화를 요구합니다. 클라우드 환경에서는 S3 버킷 암호화, EBS 볼륨 암호화, TLS 인증서 설정이 해당 증거로 제출됩니다.
그런데 암호화가 "켜져 있는 것"만으로는 부족합니다. 키 관리 정책이 문서화되어야 하며, KMS 키 교체 주기와 접근 권한이 별도로 관리되어야 합니다. 암호화는 되어 있지만 키에 접근 가능한 계정이 10개 이상인 경우, 암호화의 실효성 자체가 결함 근거가 됩니다.
3. 로그 관리 — 보존 기간과 무결성이 핵심입니다
ISMS-P 2.9.4(로그 및 접속기록 관리) 는 개인정보 취급 시스템에 대한 접속 로그를 최소 1년 이상 보존하도록 요구합니다. 개인정보 보호법 시행령 제30조의2는 개인정보처리시스템의 접속 기록 보존 기간을 명시하고 있습니다.
클라우드에서는 CloudTrail, Azure Monitor, Cloud Audit Logs가 이 역할을 담당하지만, 기본 보존 기간이 90일인 서비스도 있어 별도 S3·스토리지 아카이빙 설정이 필요합니다. 로그 무결성 검증을 위한 해시값 검증 기능(예: CloudTrail Log File Validation) 활성화도 심사에서 확인됩니다.
개발팀이 놓치기 쉬운 구조적 맹점
많은 개발팀이 IaC(Infrastructure as Code) 도구로 인프라를 코드로 관리합니다. Terraform, CloudFormation 코드가 곧 인프라 변경 이력이 될 수 있다는 점에서 ISMS-P 2.9.7(정보시스템 변경관리) 증거로 활용 가능합니다. 단, 코드 리포지터리에 IAM 시크릿이나 DB 패스워드가 하드코딩된 경우, 해당 리포지터리 자체가 결함의 진원지가 됩니다. AWS Secrets Manager나 Vault를 통한 시크릿 분리가 선행되어야 합니다.
또한 멀티 클라우드 또는 하이브리드 환경을 운영하는 경우, 각 클라우드별로 로그 포맷과 보존 위치가 달라 통합 증거 제출이 어렵다는 점도 반복적으로 지적되는 구조적 문제입니다.
실무적 시사점
ISMS-P 심사를 앞두고 클라우드 환경을 정비할 때, 설정 변경보다 증거 체계 수립이 먼저입니다. 심사원이 요구하는 것은 "안전한 시스템"이 아니라 "안전하게 관리됐다는 기록"입니다. IAM 정책 문서, 키 관리 대장, 로그 아카이브 구성도, 변경 이력 — 이 네 가지가 클라우드 ISMS-P 심사의 실질적인 준비물입니다.
클라우드 인프라 전반의 보안 설정을 ISMS-P 인증기준 항목과 매핑하고, 증거를 자동으로 수집·관리하는 체계가 필요하다면 ComplixShield의 클라우드 연동 기능을 통해 심층 분석을 받아보시기 바랍니다.