클라우드 보안, 영향 및 정책

클라우드 보안은 클라우드를 보호하고 클라우드에 대한 접근을 보호하는 것에 관한 것입니다. 이 강의에서는 클라우드 컴퓨팅의 보안, 영향 및 정책을 살펴보겠습니다.

1. 책임 공유

다양한 클라우드 서비스 모델(IaaS, PaaS, SaaS)이 있습니다. 이러한 다양한 서비스 모델에는 책임 공유가 있습니다.

• IaaS 서비스 모델에서는 클라우드 공급자가 하위 계층의 보안을 책임집니다. 고객은 운영 체제와 그 위에서 실행되는 모든 것의 보안을 책임집니다.
• PaaS에서는 클라우드 공급자가 데이터와 애플리케이션을 제외한 모든 것에 대해 책임을 집니다.
• SaaS 솔루션에서는 클라우드 공급자가 모든 것에 책임을 집니다.

서비스 모델에 대한 클라우드 공급자의 제어가 높을수록, 클라우드 공급자는 더 많은 보안 책임을 지게 됩니다.

Cloud Security Alliance(CSA) 는 클라우드 보안 모범 사례를 홍보하는 조직입니다. 클라우드 컴퓨팅의 모든 도메인에 대한 모범 사례와 권장 사항을 다루는 보안 지침 문서를 제공합니다.

CSA는 책임 공유 모델에 대해 두 가지 권장 사항을 가지고 있습니다.

• 클라우드 공급자는 클라우드 사용자가 정보에 입각한 결정을 내릴 수 있도록 내부 보안 제어와 고객 보안 기능을 명확히 문서화해야 합니다. 공급자는 또한 이러한 제어를 적절히 설계하고 구현해야 합니다.
• 클라우드 사용자는 모든 클라우드 프로젝트에 대해 누가 어떤 제어를 어떻게 구현하고 있는지를 문서화하기 위한 책임 매트릭스를 구축해야 합니다. 이것은 또한 필요한 모든 컴플라이언스 표준과 일치해야 합니다.

CSA는 이러한 요구 사항을 충족하는 데 도움이 되는 두 가지 도구를 제공합니다.

• Consensus Assessments Initiative Questionnaire (CAIQ): 클라우드 공급자가 보안과 컴플라이언스 제어를 문서화하기 위한 템플릿입니다.
• Cloud Controls Matrix (CCM): 클라우드 보안 제어를 나열하고 여러 보안 및 컴플라이언스 표준에 매핑합니다. CCM을 사용해 보안 책임을 문서화할 수도 있습니다.

2. 컴플라이언스

규제 컴플라이언스는 조직이 비즈니스 프로세스와 관련된 사양, 정책, 표준 또는 법률을 준수해야 함을 의미합니다. 규제 컴플라이언스를 위반하면 종종 벌금을 포함한 법적 처벌이 발생합니다.

다음은 규제 컴플라이언스 법과 규정의 예입니다.

• Payment Card Industry Data Security Standard (PCI DSS): 신용 카드를 처리하는 조직을 위한 정보 보안 표준입니다.
• Health Insurance Portability and Accountability Act (HIPAA): 의료 정보를 보호하기 위한 데이터 보안 및 개인 정보 보호를 제공하는 미국 법률입니다.
• General Data Protection Regulation (GDPR): 유럽 연합 내 개인의 데이터 개인 정보 보호 및 보호에 관한 EU 법률입니다.

클라우드 특정 표준도 있습니다. 다음은 두 가지 ISO 표준입니다.

• ISO 27017: 클라우드 컴퓨팅의 보안 측면에 대한 지침을 제공하는 ISO 표준입니다.
• ISO 27018: 클라우드 컴퓨팅에서 개인 식별 정보(PII)를 보호하는 데 대한 지침을 제공하는 ISO 표준입니다.

3. 위협과 위험

클라우드 환경은 전통적인(온프레미스) IT 인프라가 직면한 것과 동일한 위협에 직면합니다. 클라우드는 소프트웨어에서 실행됩니다. 소프트웨어에는 취약점이 있습니다. 공격자는 이러한 취약점을 악용하려고 합니다.

전통적인 IT 인프라와 클라우드 컴퓨팅의 주요 차이점은 클라우드 공급자와 고객이 이러한 위협을 완화하는 책임을 공유한다는 것입니다. 고객은 누가 무엇에 대해 책임이 있는지 이해하고 클라우드 공급자가 그들의 책임을 충족한다고 신뢰해야 합니다.

클라우드 컴퓨팅에 고유한 몇 가지 위협을 논의해 봅시다.

3.1. 제한된 가시성과 제어

고객과 클라우드 공급자의 책임은 클라우드 서비스 모델에 따라 달라집니다. PaaS와 SaaS 서비스 모델에서는 클라우드 공급자가 대부분의 계층을 책임집니다. 이는 또한 고객이 백그라운드에서 무슨 일이 일어나고 있는지에 대한 가시성이 많지 않다는 것을 의미합니다.

클라우드 공급자가 네트워크 계층을 관리할 때, 고객은 자신의 통제 밖에 있는 애플리케이션을 모니터링하고 분석하고 싶을 수 있습니다.

3.2. 단순화된 무단 사용

Shadow IT는 사용자가 조직의 명시적 승인 없이 사용하는 리소스입니다. 이는 전통적인 IT 환경에서도 위험입니다. 예를 들어, Google Drive, OneDrive, USB 스틱 같은 물리적 장치를 사용하는 사용자입니다.

클라우드 공급자는 새 온디맨드 리소스를 쉽게 프로비저닝할 수 있게 합니다. IT 부서의 동의 없이 직원이 새 클라우드 리소스(특히 PaaS와 SaaS)를 프로비저닝하기 쉽습니다. IT 부서는 자신이 모르는 것을 보호할 수 없습니다. Shadow IT는 가시성과 제어를 줄입니다.

3.3. 관리 API

클라우드 서비스는 거의 모든 기능을 REST API로 노출합니다. 프로비저닝, 과금, 모니터링, 접근 제어가 모두 API를 통해 자동화됩니다. 편리한 만큼, 이 API의 자격 증명(액세스 키, 토큰)이 유출되면 공격자는 콘솔 로그인 없이도 전체 환경을 제어할 수 있습니다.

• API 키/시크릿을 코드 저장소(GitHub 등)에 커밋하는 사고는 가장 흔한 유출 경로입니다.
• 권한이 과도한 장기 토큰 대신, 짧은 수명의 역할 기반(assume-role) 토큰을 사용하고, 필요 이상으로 넓은 관리자 권한을 기본값으로 두지 않습니다.
• API 호출에 대한 로그와 이상 탐지(예: AWS CloudTrail, GCP Audit Logs)는 반드시 활성화해 두어야 합니다.

3.4. 테넌트 간 분리

Public Cloud는 기본적으로 멀티 테넌트 구조입니다. 같은 물리 서버, 같은 스토리지 하드웨어 위에 서로 다른 고객의 워크로드가 올라갑니다. 하이퍼바이저·컨테이너 런타임·스토리지 계층에서 테넌트 간 분리가 깨지면 “옆 테넌트의 데이터”까지 노출될 수 있습니다.

실제로는 공급자 수준에서 잘 관리되지만, 고객 입장에서도 다음을 확인해야 합니다.

• 같은 계정 내에서도 환경(개발/운영)을 별도 프로젝트·계정으로 분리
• 네트워크는 VPC/VNet 단위로 격리하고 서비스 엔드포인트/프라이빗 링크를 사용
• 암호화 키는 테넌트/고객별로 분리하고, 가능하면 고객 관리 키(CMK/BYOK) 사용

3.5. 불완전한 데이터 삭제

온프레미스에서는 디스크를 물리적으로 파쇄하면 끝이지만, 클라우드에서는 삭제 요청이 논리적 삭제에 그치기 쉽습니다. 데이터 블록이 다른 고객에게 재할당되기 전까지 실제로는 남아 있을 수 있고, 스냅샷/백업/복제본에 사본이 따로 보관되어 있는 경우가 많습니다.

• 중요한 데이터는 저장 시점부터 클라이언트 측 암호화 또는 고객 관리 키로 암호화하여, 키만 폐기해도 사실상 복호화가 불가능하도록 설계합니다(crypto-shredding).
• 공급자의 데이터 삭제 정책·보존 기간 을 계약서 수준에서 확인합니다.

3.6. 도난당한 자격 증명

클라우드 환경에서 “서버가 뚫리는” 사고보다, 계정 자격 증명이 탈취되는 사고가 훨씬 흔합니다. 한 번의 로그인만으로 전 세계 어디에서든 리소스를 만들고 지울 수 있기 때문에, 자격 증명은 사실상 인프라 전체의 마스터키입니다.

• 모든 관리자 계정에 MFA 를 강제합니다.
• 일상 작업용 사용자와 높은 권한 작업용 사용자를 분리하고, 권한은 필요 최소한으로 유지합니다(최소 권한 원칙).
• 루트/오너 계정은 일상 작업에 사용하지 않고 별도 금고에 잠가 둡니다.
• 이상 로그인(예: 새 지역, 새 디바이스, 비업무 시간 대량 API 호출)은 즉시 알림이 오도록 설정합니다.

3.7. 벤더 종속 (Vendor lock-in)

특정 클라우드 공급자의 전용 서비스(전용 데이터베이스, 서버리스 프레임워크, 독자 관리형 서비스)에 깊이 엮여들수록, 나중에 다른 공급자나 온프레미스로 이동할 때 비용과 위험이 기하급수적으로 커집니다. 벤더 종속 자체가 직접적인 “공격”은 아니지만, 공급자 장애·가격 인상·계약 변경 시 대응 카드가 없어지므로 리스크 관리 관점에서 중요한 위협입니다.

• 중요 데이터와 워크로드는 가능한 한 표준적인 형식(Kubernetes, Terraform, 표준 DB 엔진)으로 구성해 포터빌리티를 확보합니다.
• 멀티 클라우드까지는 아니더라도, 최소한 데이터 추출/백업 은 공급자 외부에서도 열 수 있는 형태로 유지합니다.

3.8. 증가된 복잡성

클라우드를 도입하면 인프라가 단순해질 것 같지만, 실제로는 온프레미스에 없던 구성 요소(IAM, VPC 피어링, 여러 리전 간 복제, 다양한 관리형 서비스 등)가 늘어나 전체 구성은 오히려 더 복잡해지는 경우가 많습니다. 구성 오류 하나가 그대로 보안 사고가 되는 구조입니다.

• 잘못된 S3/Blob 버킷 공개, 과도하게 열린 보안 그룹/방화벽 규칙 은 반복적으로 반복되는 사고 유형입니다.
• 인프라를 수동으로 만들지 말고 IaC(Terraform, CloudFormation 등)로 코드화·리뷰·감사 가 가능한 형태로 운영합니다.
• CSPM(Cloud Security Posture Management) 도구나 공급자 기본 보안 권고(예: AWS Trusted Advisor, GCP Security Command Center, Azure Defender) 를 주기적으로 확인합니다.

4. 보안

클라우드 환경에서 기본적으로 적용해야 할 보안 통제를 영역별로 정리하면 다음과 같습니다.

• ID 및 접근 관리(IAM): 계정별로 역할(Role)을 정의하고, 사용자·애플리케이션에는 역할을 통해 최소 권한만 부여합니다. 루트 계정은 잠가 두고 MFA를 강제합니다.
• 네트워크 보안: VPC/VNet으로 격리하고, 서비스별 보안 그룹(방화벽)은 “기본 거부 + 필요한 포트만 허용” 원칙을 적용합니다. 관리 접근은 요새 호스트(bastion)나 세션 매니저, VPN을 통해서만 허용합니다.
• 데이터 보안: 전송 구간은 TLS, 저장 구간은 공급자 암호화(SSE) 또는 고객 관리 키(CMK). 민감 데이터는 추가적인 클라이언트 측 암호화를 고려합니다.
• 로깅과 모니터링: 관리 API 호출 로그, 네트워크 흐름 로그, 애플리케이션 로그를 변경 불가능한 저장소로 중앙화합니다. 이상 탐지와 알림까지 연결되어야 의미가 있습니다.
• 구성 관리: 수동 콘솔 변경 최소화, IaC 기반 변경 파이프라인, CSPM을 통한 설정 편차 탐지.
• 백업과 복구: 백업은 원본과 물리적·계정적으로 분리된 위치에 두고, 복구 절차를 주기적으로 실제로 수행해 검증합니다.
• 사고 대응 계획: 자격 증명 유출, 공개된 스토리지 버킷, 관리자 계정 탈취 같은 클라우드 고유 시나리오에 대한 플레이북을 준비합니다.

5. 결론

• 클라우드 보안의 출발점은 책임 공유 모델을 이해하는 것입니다. IaaS → PaaS → SaaS로 갈수록 공급자가 책임지는 영역이 늘어나지만, 데이터와 접근 제어는 어떤 모델에서도 결국 고객의 책임 입니다.
• PCI DSS, HIPAA, GDPR 같은 규제 준수와 ISO 27017/27018 같은 클라우드 표준은 “해도 되면 좋은 것”이 아니라, 위반 시 법적·재정적 제재가 따르는 기본 요구 사항입니다.
• 클라우드 고유 위협은 기술 자체보다 운영 관행에서 주로 발생합니다. API 키 유출, 과도한 권한, 공개된 스토리지, 감시 없는 Shadow IT 등이 대표적입니다.
• 이러한 위협에 대한 대응은 IAM/MFA, 네트워크 분리, 암호화, 감사 로깅, IaC, CSPM 같은 기술적 통제와 함께, 정책·문서화·책임 매트릭스라는 운영적 통제가 함께 뒷받침되어야 효과를 발휘합니다.

출처: networklessons.com - Cloud Security, Implications, and Policy

태그: Cloud