[ISMS-P] 멀티 클라우드 환경 중견기업의 암호화 적용 (2.7.1 ~ 2.7.2)
데이터의 안전한 보관과 전송을 보장하는 최후의 방어선은 암호화(Encryption)입니다. 특히 멀티 클라우드 환경에서는 데이터가 물리적으로 회사의 손을 떠나 다양한 CSP(클라우드 서비스 제공자)의 스토리지 및 네트워크 회선을 지나기 때문에, 데이터의 저장(At-Rest)과 전송(In-Transit) 모든 단계에서 완벽한 암호화 체계를 구축하는 것이 법적 컴플라이언스와 ISMS-P 인증 통과의 핵심 요구사항입니다.
이번 글에서는 ISMS-P 인증기준 2.7 (암호화 적용)의 2개 세부 항목을 멀티 클라우드 중견기업 관점에서 살펴보고, 실제 심사에서 발견되는 결함 사례와 퀴즈를 정리해 보겠습니다.
1. 2.7.1 암호정책 적용
📌 인증기준 개요
조직의 비밀성 요건에 따라 개인정보 및 중요 정보의 저장·전송 시 적용할 암호화 대상, 안전한 암호화 알고리즘(AES-256, SHA-256 등), 강도 등을 정의한 암호 정책을 수립하고 준수해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 개인정보 저장 암호화 대상 준수: 개인정보 보호법에 의거, 주민등록번호, 여권번호, 운전면허번호, 외국인등록번호(고유식별정보), 비밀번호, 바이오정보, 신용카드번호, 계좌번호 등은 데이터베이스 및 스토리지(S3 등) 저장 시 반드시 안전한 알고리즘(AES-256 등)으로 암호화해야 합니다. 비밀번호는 단방향 해시(SHA-256 이상 + Salt 적용)를 필수적으로 사용해야 합니다.
- 클라우드 스토리지 기본 암호화: AWS S3, EBS, RDS 및 Azure Blob Storage 등의 기본 암호화 옵션을 상시 활성화하여, 디스크 물리적 유출 시 데이터 유출을 원천 방지해야 합니다.
- 전송 중 암호화 (SSL/TLS 강제): 퍼블릭 네트워크를 통과하는 모든 서비스 트래픽은 HTTPS(TLS 1.2/1.3 권장) 프로토콜을 통과하도록 로드밸런서(ALB 등) 및 CDN(CloudFront 등) 설정을 적용하고, 취약한 레거시 암호화 프로토콜(SSL v3, TLS 1.0, 1.1) 및 취약한 대칭키 알고리즘(RC4 등)은 차단해야 합니다.
📝 실전 시험 대비 (예상 시나리오)
[상황] 심사원이 A기업의 웹 서비스 및 데이터베이스 저장 암호화 구성을 점검 중이다.
- 심사원: “회원들의 로그인 비밀번호와 주민등록번호가 저장되는 데이터베이스 테이블 설정을 확인해 보고 싶습니다.”
- 담당자: “비밀번호는 안전하게 암호화하여 저장하고 있습니다. 주민등록번호는 저희 DB 인프라(AWS RDS) 자체에 디스크 암호화(KMS를 통한 AES-256 암호화)를 걸어두었기 때문에 파일 단위로 안전하게 숨겨져 있습니다.”
- 심사원: “그렇다면 DB 테이블 내부를 직접 조회(SELECT)했을 때 주민등록번호 컬럼의 데이터는 어떻게 보이나요? 평문(Plain text)으로 보이나요?”
- 담당자: “쿼리로 조회하면 평문(예: 950101-1234567)으로 출력됩니다. 하지만 디스크 가상 장치 레벨에서 암호화되어 있어 물리적으로 안전합니다.”
Q. 위 상황에 대해 내릴 수 있는 심사 소견으로 가장 알맞은 것은?
- 디스크 수준의 암호화(TDE 등)를 적용했으므로 추가 암호화는 불필요하여 적절함
- 2.7.2 암호키 관리 - KMS 암호키가 정기적으로 변경되지 않았음
- 2.7.1 암호정책 적용 - 개인정보 보호법상 고유식별정보(주민등록번호)는 디스크 레벨 암호화 외에도 데이터베이스 파일/컬럼 레벨에서 추가적인 암호화 조치를 취해, 인가되지 않은 DB 조회 시 평문 노출을 방지해야 하므로 결함임 (정답)
- 2.6.4 데이터베이스 접근 - 일반 상담원이 데이터베이스를 직접 조회함
해설: 국내 개인정보 보호법상 주민등록번호와 같은 고유식별정보는 데이터베이스 내 저장 시 컬럼 레벨 암호화(API 방식, Plug-in 방식 등) 또는 그에 준하는 애플리케이션 레벨의 확실한 암호화가 보장되어야 합니다. 단순히 클라우드 제공자의 ‘디스크 전체 암호화(Encryption at Rest)’ 기능만 적용하여 조회 시 평문이 그대로 쏟아져 나오는 상태는 2.7.1의 핵심 결함으로 판정됩니다.
2. 2.7.2 암호키 관리
📌 인증기준 개요
암호화에 사용되는 암호키는 생성, 분배, 저장, 사용, 폐기 등 전체 수명 주기(Life Cycle) 관리 절차를 수립하고, 비인가자의 접근을 차단하기 위한 키 관리 정책 및 권한 분리 대책을 이행해야 합니다.
☁️ 멀티 클라우드 환경에서의 핵심 고려사항
- 클라우드 KMS(Key Management Service) 활용: 대칭키/비대칭키 관리를 개발자가 임의의 소스 코드나 텍스트 파일(예:
appsettings.json등)에 하드코딩하지 않고, AWS KMS, Azure Key Vault, GCP Cloud KMS 등 CSP에서 제공하는 매니지드 키 관리 서비스를 사용해 숨겨두어야 합니다. - 암호키 자동 로테이션(Key Rotation): KMS에 등록되어 데이터를 실질적으로 암호화하는 마스터 키(CMK - Customer Managed Key)는 일정 주기(예: 매년 1회)로 자동 순환(로테이션)되도록 활성화 옵션을 설정해야 합니다.
- 키 권한 격리 (Key Policy): 암호키를 관리하는 사람(보안/인프라팀)과 암호키를 사용하는 주체(애플리케이션 IAM Role, DB 엔진 등)의 IAM 권한을 명확히 격리하여 보안 사고 시 키 권한의 남용을 차단해야 합니다.
📝 실전 시험 대비 (기출 복원 시나리오)
[상황] 심사원이 B기업의 AWS KMS 암호키 설정 내역을 점검하고 있다.
- 심사원: “고객 계좌정보 암호화에 사용되는 AWS KMS 마스터 키의 설정 옵션을 보여주세요.”
- 담당자: “여기 보시면 저희가 직접 생성한 고객 관리형 마스터 키(CMK)를 지정해서 계좌정보 암호화용 DB 볼륨에 매핑해 두었습니다.”
- 심사원: “그렇군요. 그런데 암호키의 ‘자동 로테이션(Key Rotation)’ 옵션이 비활성화(Disabled) 상태로 되어 있고, 3년 전에 생성한 이래 키가 한 번도 교체되거나 변경된 적이 없네요. 또한, 이 키에 대한 관리 권한 정책(Key Policy)에 모든 개발자 그룹(
*)이 포함되어 있습니다.” - 담당자: “로테이션을 돌리면 기존 데이터가 복호화되지 않을까 봐 변경하지 않았습니다. 개발 편의상 개발자들도 키 권한을 갖고 있습니다.”
Q. 위 상황에서 발생한 암호키 관리 컴플라이언스 결함 사항을 모두 고르시오.
- ① AWS KMS 대신 외부 오픈소스 솔루션만 강제 권장됨
- ② 암호키의 자동 로테이션 기능이 활성화되지 않고 장기간 키 교체 이력이 없음
- ③ 암호키 접근 정책(Key Policy)에 최소 권한 원칙을 적용하지 않고 모든 개발자 그룹에 개방함
- ④ 마스터 키의 길이가 128비트로 설정됨 (AES-128도 안전한 범위 내에 있음)
- 정답: ②, ③
해설:
- ②: 중요 데이터를 암호화하는 마스터 키는 주기적(최소 연 1회 이상)으로 변경(로테이션)되어야 합니다. 클라우드 KMS는 기존 키 버전을 보존하며 새 키를 돌려주기 때문에 복호화 실패 우려 없이 안전하게 자동 로테이션 옵션을 켜두어야 합니다. 이를 방치하는 것은 2.7.2 결함입니다.
- ③: 암호키는 매우 강력한 통제 수단이므로 IAM 정책상 키를 생성/수정/삭제할 수 있는 관리 권한을 개발자 전체에 과도하게 개방하는 것은 최소 권한 위배 및 우남용 차단 실패에 해당하므로 결함입니다.
🚀 AI를 활용한 암호화 적용 자동화 의견
멀티 클라우드 환경 전반에 산재해 있는 미암호화 파일과 크레덴셜 누출 위험은 AI를 적용하여 효과적으로 상시 점검할 수 있습니다.
1. LLM 및 컴퓨터 비전 기반 데이터 분류 및 자동 암호화 (Sensitive Data Discovery)
- 미암호화 개인정보 실시간 감시: AI 엔진(예: AWS Macie, Azure Purview 등에서 고도화된 모델)이 클라우드 스토리지(S3 등)에 업로드되는 대량의 텍스트, 이미지(신분증 스캔본 등), PDF 파일을 자연어 처리(NLP)와 OCR 기술로 분석합니다. 주민등록번호, 카드번호 등 개인정보 패턴이 탐지될 경우 자동으로 AES-256 암호화를 적용한 보안 버킷으로 격리시키고 보안 담당자에게 통보합니다. (2.7.1 대응)
2. 코드 및 인프라 정의 파일(IaC) 내 암호키 하드코딩 실전 탐지 (Secret Scanning)
- CI/CD 파이프라인 내 비밀 탐지: 개발자가 GitHub 등 소스 저장소에 코드를 푸시하거나 Terraform 코드를 실행할 때, AI 기반 정적 분석 도구(SAST)가 코드 내에 실수로 포함된 KMS 키 정보, API Token, 개인키(Private Key), 하드코딩된 패스워드 패턴을 딥러닝 기반 의미적 분석으로 오탐 없이 탐지하여 빌드 단에서 즉각 차단(Block)합니다. (2.7.2 대응)
💡 요약 및 결론
암호화는 규정 준수를 위한 형식이 아니라 실제 해킹 사고 발생 시 피해를 제로화하는 강력한 최후의 방패입니다.
| 항목 | 핵심 키워드 | 클라우드 환경 핵심 체크리스트 |
|---|---|---|
| 2.7.1 암호정책 적용 | 저장/전송 암호화, 알고리즘 | 주민번호/비밀번호 DB 컬럼 암호화 적용 여부, HTTPS/TLS 1.2+ 전송 강제 |
| 2.7.2 암호키 관리 | 키 수명주기, 로테이션 | KMS 마스터키 연 1회 로테이션 설정, IAM Key Policy 권한 분리 |
정당한 암호 알고리즘의 유효성을 정기 검토하고, 키의 소유권을 확실히 격리하여 보관하는 것만이 ISMS-P 암호화 영역의 핵심 컴플라이언스를 확보하는 확실한 왕도입니다.