행위자가 아키텍처 스택에 대해 규제 수준에 따라 보안 책임 범주가 다르게 된다. 가장 중요한 보안 고려 사항은 주어진 클라우드 프로젝트에서 누가 무엇을 책임지고 있는지 정확하게 판단하고 있어야 하는 것이다. 특히 클라우드 업체가 제공하는 클라우드의 기능과 작동 방식을 정확히 알고 있어야 하는 것이다.
▶ SaaS(Software as a Service): 클라우드 사용자는 애플리케이션 사용에 액세스 및 관리만 할 수 있고, 애플리케이션 작동 방식을 변경할 수는 없기 때문에 클라우드 제공업체에서 대부분의 보안을 담당한다. 예를 들어 SaaS 공급자는 경계 보안, 로깅/모니터링/감사 및 애플리케이션 보안을 담당하는 반면 소비자는 권한 부여 및 권한만 관리한다.
▶ PaaS(Platform as a Service): 클라우드 공급자는 플랫폼의 보안을 책임지고, 소비자는 제공된 보안 기능을 구성하는 방법을 포함하여 플랫폼에서 구현하는 모든 것에 대한 책임을 진다. 따라서 책임이 균등하게 분할된다. 예를 들어 Database as a Service를 사용하는 경우 공급자는 기본 보안, 패치 및 핵심 구성을 관리하고 클라우드 사용자는 사용할 데이터베이스의 보안 기능, 계정 관리 또는 인증 방법을 포함한 다른 모든 것을 책임진다.
▶ IaaS(Infrastructure as a Service): PaaS와 마찬가지로 제공업체는 기본 보안을 담당하고 클라우드 사용자는 인프라에 구축된 모든 것을 담당한다. PaaS와 달리 IaaS는 클라이언트에게 더 많은 책임을 부여한다. 예를 들어 IaaS 공급자는 공격에 대한 경계를 모니터링해야 할 수 있으며, 소비자는 서비스에 사용할 수 있는 도구를 기반으로 가상 네트워크 보안을 정의/구현하는 방법에 대해 전적으로 책임을 진다.
CSA는 이러한 요구사항을 충족하는 데 도움이 되는 두 가지 도구를 제공한다
▶ CAIQ(Consensus Assessments Initiative Questionnaire): 클라우드 공급자가 보안 및 규정 준수 규제를 문서화하기 위한 표준 템플릿
▶ CCM(The Cloud Controls Matrix): 클라우드 고객이 클라우드 제공업체에 대한 전반적인 보안 위험을 평가하는데 도움을 주기 위한 기본 보안원칙을 제공하도록 설계된 가이드라인. CCM을 사용하여 보안 책임을 문서화할 수도 있음
1.5.2 클라우드 보안 모델
클라우드 보안 모델은 보안 의사결정을 안내하는데 도움이 되는 도구이다. “모델”이라는 용어는 다소 불규칙적으로 사용될 수 있으므로, 다음과 같이 유형을 구분한다.
▶ 개념적 모델 또는 프레임워크에는 CSA 논리 모델과 같은 클라우드 보안 개념 및 원칙을 설명하는 데 사용되는 시각화 및 설명을 포함한다.
▶ 규제 모델 또는 프레임워크는 특정 클라우드 보안 규제 또는 규제 범위(예: CSA CCM)를 분류하고 설명한다.
▶ 참조 아키텍처는 일반적으로 일반화된 클라우드 보안을 구현하기 위한 템플릿(예: IaaS 보안 참조 아키텍처)이다. 해당 아키텍처는 매우 추상적일 수 있고, 개념에 가까울 수 있으며, 상세하게 설명될 수 있다. 또한 특정한 통제나 기능에 해당 될 수 있다.
▶ 디자인 패턴은 특정 문제에 대한 재사용이 가능한 해결책이다. 예로는 IaaS 로그 관리가 있다. 참조 아키텍처와 마찬가지로 특정 클라우드 플랫폼의 일반적인 구현 패턴에 이르기까지 다소 추상적이거나 구체적일 수 있다.
이러한 모델 사이의 경계는 모델 개발자의 목표에 따라 종종 겹치기도 한다. “모델”이라는 제목 아래에 이 모든 것을 하나의 그룹으로 두는 것조차 정확하지 않을 수 있지만 용어가 서로 다른 소스에서 서로 바뀌어 사용되는 것을 볼 수 있으므로 그룹화하는 것이 좋다.
CSA는 다음 모델을 검토하고 권고하였다.
▶ The CSA Enterprise Architecture
▶ The CSA Cloud Controls Matrix
▶ The NIST draft Cloud Computing Security Reference Architecture (NIST Special Publication 500-299), which includes conceptual models, reference architectures, and a controls framework.
▶ ISO/IEC FDIS 27017 Information technology – Security techniques – Code of practice for information security controls based on ISO/IEC 27002 for cloud services.
2 거버넌스 및 엔터프라이즈 위험 관리(Governance and Enterprise Risk Management)
거버넌스 및 위험 관리는 매우 광범위한 주제이다. 해당 지침은 클라우드 컴퓨팅에서 어떻게 변화하는지에 중점을 둔다. 보안 전문가에게 클라우드 컴퓨팅은 거버넌스 및 위험 관리의 4가지 영역에 영향을 준다.
첫 번째: 거버넌스는 조직 운영방식을 구성하는 정책, 프로세스 및 내부 관리사항 등을 포함한다. 구조 및 정책에서 리더십 및 기타 관리 메커니즘에 이르기까지 다양한 사항들이 있다.
거버넌스에 대한 자세한 내용은 아래의 내용을 참조한다.
▶ ISO/IEC 38500:2015 - Information Technology - Governance of IT for the organization
▶ ISACA - COBIT - A Business Framework for the Governance and Management of Enterprise IT
▶ ISO/IEC 27014:2013 - Information Technology - Security techniques - Governance of information security
두 번째: 엔터프라이즈 위험 관리에는 조직의 거버넌스 및 위험 허용 범위에 맞춰 조직의 전반적인 위험 관리가 포함된다. 엔터프라이즈 위험 관리에는 기술과 관련된 영역뿐만 아니라 모든 위험 영역이 포함된다.
위험 관리에 대한 자세한 내용은 아래의 내용을 참조한다.
▶ ISO 31000:2009 - Risk management – Principles and guidelines
▶ ISO/IEC 31010:2009 - Risk management – Risk assessment techniques
▶ [NIST Special Publication 800-37 Revision 1](updated June 5, 2014) (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf)
세 번째: 정보 위험 관리에는 정보 기술을 포함한 정보 위험 관리에 관한 것이다. 조직은 금융에서 물리적까지 모든 종류의 위험에 직면하고 있으며, 정보는 조직이 관리해야 할 여러 자산 중 하나에 불과하다.
네 번째: 정보 보안은 정보에 대한 위험을 관리하는 도구와 실천사항들이다. 정보 보안은 위험 정보의 관리가 전부가 아니다. 정책, 계약, 보험 및 기타 메커니즘의 역할도 한다. 그러나 정보 보안의 주된 역할은 전자정보와 이를 액세스 하는데 사용하는 시스템을 보호하기 위한 프로세스 및 규제를 제공하는 것이다.
위험 관리는 선택한 클라우드 구축 및 서비스 모델을 기반으로 보안 및 위험 관리에 대한 공유 및 책임 등을 파악해야 한다. 관련 업계 모범사례, 글로벌 표준 및 CSA CCM, COBIT 5, NIST RMF, ISO/IEC 27017, HIPAA, PCI DSS, EU GDPR 등과 같은 규정에 따라 클라우드 거버넌스 프레임워크 및 모델을 개발해야 한다.
3 법적 문제, 계약 및 전자적 증거 수집(Legal Issues, Contracts and Electronic Discovery)
해당 파트는 데이터를 클라우드로 이동함으로써 제기 된 몇 가지 법적 문제를 다루고 있다. 클라우드 서비스 제공업체와 계약 소송에서 전자적 검색 요청을 처리한다. 하지만 해당 개요는 잠재적인 모든 법적 상황들을 다룰 수는 없다. 특정 문제를 해결하기 위해서는 운영하려는 담당자 및 고객이 거주하는 지역의 법률 고문과 상의해야 한다. 또한 법률 및 규정은 자주 변경되므로 해당 파트에 포함된 정보의 관련성을 확인해야 한다.
해당 파트는 주로 퍼블릭 클라우드 컴퓨팅 및 타사 호스팅 개인 클라우드의 법적 의미에 대한 내용을 담고 있다. 해당 파트는 데이터 거버넌스 및 감사/준수사항에 대한 몇 가지 측면이 포함되어 있지만 이러한 주제는 다음 2.4와 2.5에서 자세히 다루게 되어 있다.
해당 파트가 다루는 영역은 다음과 같다.
▶ 법적인 문제
▶ 클라우드 서비스 계약
▶ 클라우드에 저장된 전자 문서에 대한 제 3자 액세스
4 규정 준수 및 감사 관리(Compliance and Audit Management)
조직들은 기존 데이터센터에서 클라우드로 마이그레이션하면서 새로운 과제에 직면해 있다. 여러 국가에 걸쳐 다수의 규제 준수를 제공, 측정 및 전달하는 것은 이러한 과제 중 가장 큰 문제 중 하나이다. 고객과 공급자는 기존 준수사항 및 감사 표준, 프로세스, 사례들에 대한 차이들을 이해하고 평가할 필요가 있으며, 클라우드 컴퓨팅의 분산 및 가상화 특성은 정보와 프로세스의 물리적 인스턴스화를 기반으로 접근방식에 대한 조정이 필요하다.
공급자와 고객 외에도 규제 기관과 감사 인원도 클라우드 컴퓨팅의 새로운 세계에 적응하고 있다. 가상화 환경이나 클라우드 구현을 고려하는 기존 규정은 거의 없었다. 클라우드 사용자는 감사인에게 조직이 규정을 준수하고 있음을 보여주어야 한다. 클라우드 컴퓨팅과 규제 환경의 상호 작용을 이해하는 것은 모든 클라우드 전략의 핵심 구성 요소이다. 클라우드 고객, 감사자 및 공급자는 다음 사항을 고려해야 한다.
▶ 특정 클라우드 서비스 또는 제공업체 사용에 대한 규제적 영향(해당하는 경우 국경을 초월한 문제 또는 여러 주제의 문제에 특히 주의를 기울임)
▶ 간접 제공자(즉, 클라우드 공급자의 클라우드 공급자)를 포함하여 공급자와 고객 간의 규정 준수 책임을 할당.
▶ 문서 및 증거 생산, 프로세스 준수를 포함하여 적시에 입증할 수 있는 공급자 기능
특히 주의해야 할 몇 가지 추가 클라우드 관련 문제는 다음과 같다.
▶ 공급자 감사 및 인증의 역할과 인증이 고객 감사 범위에 미치는 영향
▶ 감사 및 평가 범위 내에 있는 클라우드 공급자의 기능 및 서비스 이해
▶ 시간 경과에 따른 규정 준수 및 감사 관리
▶ 클라우드 컴퓨팅 기술에 대한 경험이 부족할 수 있는 규제 기관 및 감사자와의 협력
▶ 감사 및 규정 준수 경험이 부족할 수 있는 공급자와의 협력
5 정보 거버넌스(Information governance)
정보 보안의 주요 목표는 시스템 및 애플리케이션을 구동하는 기본 데이터를 보호하는 것이다. 기업이 클라우드 컴퓨팅으로 전환함에 따라 기존의 데이터 보안 방법은 클라우드 기반 아키텍처의 어려움을 겪고 있다. 탄력성, 다중 테넌시, 새로운 물리적, 논리적 아키텍처, 추상화 된 제어에는 새로운 데이터 보안 전략이 필요로 한다. 많은 클라우드 배포에서 사용자는 불과 몇 년 전까지만 해도 상상할 수 없었던 방식으로 외부 또는 공용 환경으로 데이터를 전송한다.
클라우드 컴퓨팅 시대에 정보를 관리하는 것은 모든 조직에 영향을 미치며 새로운 기술 보호뿐만 아니라 기본적인 거버넌스에 대한 새로운 접근방식을 요구하는 어려운 과제이다. 클라우드 컴퓨팅은 정보 거버넌스의 모든 영역에 적어도 어느 정도 영향을 미치지만 특히 제삼자와 작업하고 관할 구역을 관리하는데 있어 복잡성이 증가하기 때문에 규정 준수, 개인정보 보호 및 기업 정책에 특히 영향을 미친다.
정보 및 데이터 거버넌스 요구사항에 영향을 미치는 데이터를 클라우드에 저장하는 데에는 여러 가지 요구사항이 있다.
▶ 멀티 테넌시(Multitenancy): 멀티 테넌시는 복잡한 보안 의미를 제공한다. 데이터가 퍼블릭 클라우드에 저장되면 신뢰할 수 없는 다른 테넌시와 공유인프라(Shared IT)에 저장된다. 사설 클라우드 환경에서도 서로 다른 사업부에서 공유되는 인프라에 저장 및 관리되므로 거버넌스 요구사항이 다를 가능성이 높다.
▶ 보안 책임 공유(Shared Security Responsibility): 환경 공유가 증가하면 보안 공유에 대한 책임도 커진다. 데이터는 다른 팀이나 조직에 의해 소유되고 관리될 가능성이 높다. 따라서 데이터 관리자와 데이터 소유권 간의 차이를 인식하는 것이 중요하다.
☞ 이름에서 알 수 있듯이 소유권은 누가 데이터를 소유하는지에 관한 것이다. 항상 완벽하고 명확한 것은 없으며, 고객이 데이터를 제공하는 경우, 법률, 계약 및 정책에 따라 데이터를 합법적으로 소유할 수 있다. 공용 클라우드 공급자에서 데이터를 호스팅하는 경우 데이터를 소유해야 하지만, 이는 계약에 따라 달라질 수 있다.
☞ 관리자는 데이터를 관리하는 사람을 말하며, 개인정보를 제공하고 이를 소유할 권리가 없는 경우 단지 관리자일 뿐이다. 즉, 승인된 방식으로만 사용할 수 있다. 퍼블릭 클라우드 공급자를 사용하는 경우 자신이 구현하고 관리하는 규제에 따라 관리 책임이 있을 수 있으며, 공급자를 이용한다고 해서 책임이 사라지지는 않는다. 소유자와 관리자 간의 경계와 역할은 공공 클라우드의 경우 클라우드의 인프라 영향을 받는다.
클라우드로의 전환을 계획하기 전에 정보에 대한 거버넌스 요구사항을 결정해야 한다. 여기에는 법적 및 규제 요구사항, 계약 의무 및 기타 기업 정책이 포함되어 있다. 제 3자가 데이터를 처리 할 수 있도록 회사 정책 및 표준을 업데이트 해야 할 수 있다. 또한, 정보 거버넌스 정책 및 관행이 클라우드로 확장되는지 확인해야 하며, 이는 계약 및 보안 규제를 통해 수행된다. 필요한 경우 데이터 보안 수명 주기를 사용하여 데이터 처리 및 규제를 모델링 해야한다. 기존 정보 아키텍처를 해제하고 이동하는 대신 클라우드로 마이그레이션하여 기존 인프라에서 자주 사용되는 분리된 접근방식을 재구성해야 한다.
6 관리 기준면과 비즈니스의 연속성(Management Plane and business Continuity)
관리영역은 기존 인프라와 클라우드 컴퓨팅 간의 가장 중요한 보안 차이점이다. 이것은 모든 메타 구조가 아니라 메타 구조와 연결하고 많은 클라우드를 구성하기 위한 인터페이스를 의미한다.
▶ 관리영역(메타구조) 보안
▶ API 게이트웨이 및 웹 콘솔에 대한 강력한 경계 보안이 있는지 확인한다.
▶ 강력한 인증과 MFA를 사용한다.
▶ 기본 계정 소유자/루트 계정 자격 증명을 엄격하게 제어하고, 이중 권한을 고려하여 액세스한다.
▶ 제공업체에 여러 계정으로 구축하면 계정 세분화와 Blast radius 제한에 도움이 될 것이다.(IaaS 및 PaaS 사용)
▶ 루트/기본 계정 소유자 자격 증명 대신 별도의 슈퍼관리자(최고관리자) 및 일상적인 관리자 계정을 사용한다.
▶ 메타 구조 액세스를 위한 최소 권한의 계정들을 일관되게 설정한다.
▶ 클라우드 공급자와 개발 및 테스트 계정을 분리한다.
▶ 가능할 때마다 MFA 사용을 시행한다.
7 인프라 보안(Infrastructure Security)
인프라 보안은 클라우드에서 안전하게 운영하기 위한 기본 베이스이다. 해당 파트에서는 워크로드 및 하이브리드 클라우드가 포함된 컴퓨팅 및 네트워킹 보안을 다룬다. 스토리지 보안도 인프라의 핵심이지만 ‘2.11 데이터 보안 및 암호화’에서 자세히 다룰 예정이다. 또한 사설 클라우드 컴퓨팅의 기본사항도 다루고 있으며, 기존 표준과 지침들이 적용되어있는 데이터센터 보안에 대한 모든 구성 요소를 포함하지는 않는다.
인프라 보안은 물리적 시설에서 소비자의 인프라 요소 구성 및 구현에 이르기까지 가장 낮은 보안 계층을 포함하고 있다. 클라우드 제공업체 및 사설 클라우드 배포에서 참조해야 하는 데이터센터 보안에 대한 지식과 산업 표준은 이미 있지만 CSA 지침들은 인프라 보안의 클라우드 관련 측면에 초점을 맞추고 있다. 해당 파트에서는 기본 인프라에 대한 클라우드 고려 사항과 가상 네트워크 및 워크로드에 대한 보안이라는 2가지 측면에 대한 설명이 포함되어 있다.
해당 파트에서 제공업체 또는 플랫폼의 인프라 보안에 대해 다음과 같이 추천한다.
▶ 공유 보안 모델에서 공급자(또는 사설 클라우드 플랫폼을 유지 관리하는 사람)는 클라우드의 기본 물리적, 추상화 및 오케스트레이션 계층을 보호해야 한다.
▶ 규정 준수에 대한 인증 및 증명을 검토한다.
▶ 공급업체가 클라우드 인프라의 모범사례나 규정을 따르고 있는지 확인하기 위해 정기적으로 산업 표준 및 산업별 규정 준수항목 등을 확인한다.
▶ 네트워크는 가능한 SDN을 선호한다.
▶ 여러 가상 네트워크 및 클라우드 계정/세그먼트에 SDN 기능을 사용하여 네트워크를 분리한다.
▶ 별도의 계정과 가상 네트워크는 기존 데이터센터에 비해 Blast radius를 제한한다.
▶ 네트워크 단위가 아니 워크로드 단위로 클라우드 방화벽을 적용한다.
▶ 가능한 경우 클라우드 방화벽(보안 그룹) 정책을 사용하여 동일한 가상 서브넷에 있는 워크로드 간의 트래픽을 제한한다.
▶ 탄력성을 제한하거나 성능 저하를 유발하는 가상 어플라이언스에 대한 종속성을 최소화 한다.
▶ 가능할 때마다 변경 불가능한 워크로드를 활용하고, 장기간 실행되는 워크로드에 대해 보안 제어 기능을 유지하되 클라우드를 인식하는 툴을 사용하며, 외부에 로그를 저장한다.
▶ 취약성 평가 및 해킹 테스트에 대한 클라우드 제한 사항을 이해하고 준수한다.
8 가상화 및 컨테이너(Virtualization and Containers)
가상화는 단순히 가상 머신을 생성하는 도구가 아닌 클라우드 컴퓨팅을 가능하게 하는 핵심 기술이다. 운영 가상머신에서 JVM(Java Virtual Machine)과 같은 실행환경은 물론 스토리지, 네트워킹 등 컴퓨팅 전반에 걸쳐 가상화가 가능하다.
클라우드 컴퓨팅은 기본적으로 리소스 풀링을 기반으로 하며, 고정 인프라를 이러한 풀링된 리소스로 변환하는데 사용되는 기술이다. 가상화는 리소스 풀에 필요한 추상화를 제공하며, 리소스 풀은 조직화 되어 관리하게 된다.
가상화가 보안에 미치는 영향을 이해하는 것은 클라우드 보안을 적절하게 설계하고 구현하는데 필수적이다. 리소스 풀에서 프로비저닝 된 가상 자산은 물리적 자산과 비슷해 보일 수 있지만 이러한 모양과 느낌은 실제로 보는 것보다 더 잘 이해하고 관리하는데 도움이 되는 도구일 뿐이다. 또한 운영체제와 같은 기존 기술을 활용할 수 있는 유일한 방법이다.
클라우드 공급자는 가상화에 사용되는 기본 물리적 인프라를 보호해야 하고, 테넌트 간의 보안 확보에 집중하여야 한다. 또한 클라우드 사용자가 자산을 적절하게 보호할 수 있도록 가상화 계층에서 충분한 보안 기능을 제공해야 하고, 물리적 인프라와 가상 플랫폼을 공격이나 내부 손상으로부터 보호해야 한다. 또한 기본 보안 구성만으로도 모든 고객 관리 가상화 기능이 구현되어야 한다.
클라우드 사용자는 클라우드 제공업체가 제공하는 기능과 보안 허점을 이해해야 하며, 클라우드 제공업체의 지침 및 기타 업계 모범사례에 따라 가상화 서비스를 적절하게 구성해야 한다.
9 사고 대응(Incident Response)
사고대응(IR: Incident Response)은 정보 보안 요소에서 중요한 부분이다. 예방적 보안으로는 중요한 데이터가 손상될 가능성을 완전히 제거할 수 없다는 것은 이미 입증 되었다. 대부분의 조직은 공격을 조사하는 방법을 통제하기 위한 일종의 IR 계획을 세우고 있으며, 클라우드 포렌식 데이터에 대한 액세스와 거버넌스에서 뚜렷한 차이를 나타내므로 조직은 IR 프로세스가 어떻게 변경되는지 신중하게 고려해야 한다.
해당 파트는 클라우드 컴퓨팅의 고유한 특성으로 발생하는 IR에 대해 분석한다. 보안 전문가는 IR 라이프 사이클의 준비 단계에서 대응 계획을 개발하고 다른 활동을 수행할 때 해당 파트를 참조할 수 있다. 이 파트는 National Institute of Standards and Technology Computer Security Incident Handling Guid(NIST 800-61rev2 08/2012)에 설명된 대로 일반적으로 허용되는 사고대응 수명 주기에 따라 구성된다. 사고 대응을 위한 다른 국제 표준 프레임 워크로 ISO/IEC 27035와 사고 대응 및 사이버 위기 협력을 위한 ENISA 전략이 있다.
SLA 및 고객이 하는 일 대비 제공업체가 하는 일에 대한 기대 설정은 클라우드 기반 리소스에 대한 사고 대응의 가장 중요한 측면이다. 각자의 역할과 책임을 명확하게 전달하고 사고에 대한 대응 연습하는 것이 중요하다. 클라우드 고객은 사고 발생 시 활용할 수 있는 공급자와의 비상 연락망을 가지고 있어야 한다. 또한 클라우드 고객은 클라우드 기반 리소스에 대한 지속적인 서비스 모니터링을 함으로서 기존 데이터센터보다 빠르게 잠재적인 문제들을 감지해야 한다.
클라우드 서비스 공급자의 SLA는 엔터프라이즈 사고 대응 계획을 효과적으로 실행하는데 필요한 지원을 보장해야 한다. 이는 감지, 분석, 봉쇄, 근절 및 복구와 같은 각각의 사고처리 프로세스 단계들이 포함되어 있다.
테스트는 적어도 1년에 한 번 또는 애플리케이션 아키텍처에 중대한 변경이 있을 때마다 수행되어야 한다. 고객들은 가능한 그들의 시험 절차들을 공급업체 및 다른 파트너들의 시험 절차와 통합 수행하여야 한다.
10 애플리케이션 보안(Application Security)
애플리케이션 보안은 초기 설계 및 위협 모델링에서 프로덕션 애플리케이션 유지 관리 및 보호에 이르기까지 매우 복잡하고 방대한 지식 체계를 포괄하고 있다. 또한, 애플리케이션 개발 관행이 계속해서 발전하고 새로운 프로세스, 패턴 및 기술을 수용함에 따라 애플리케이션 보안은 매우 빠른 속도로 진화하고 있다. 클라우드 컴퓨팅은 이러한 발전의 가장 큰 원동력 중 하나이며, 이러한 발전이 가능한 한 안전하게 계속되도록 보장하기 위해 애플리케이션 보안 상태를 지속적으로 발전 시켜야 한다.
해당 파트는 클라우드 컴퓨팅 환경, 특히 PaaS 및 IaaS에서 애플리케이션을 안전하게 구축하고 배포하려는 소프트웨어 개발 및 IT 팀을 대상으로 한다. (해당 파트는 보안 SaaS 애플리케이션을 뒷받침하는데도 사용된다.)
클라우드 컴퓨팅은 대부분 애플리케이션에 보안 측면에서 이점을 제공하지만 대부분의 클라우드 기술 영역과 마찬가지로 클라우드에서 작동하도록 설계되지 않은 기존 프로세스 및 기술에 상응하도록 변경이 필요하다.
클라우드에 설치되는 애플리케이션은 정식 SDLC(Software Development Life Cycle: 소프트웨어 개발 생명 주기)가 없더라도 지속해서 배포할 수 있도록 하고, 배포 파이프라인에 보안을 자동화 하는 것을 고려해보아야 한다. 또한 위협 모델링, SAST(Static Application Security Testing: 소스파일을 검사하고 근본적인 원인을 식별) 및 DAST(Dynamic Application Security Testing: 실행중인 웹 애플리케이션 또는 서비스를 대상으로 제어된 공격을 시뮬레이션하여 실행중인 환경에서의 취약성을 식별)(퍼징 포함) 모두 통합되어야 한다. 테스트는 클라우드 환경에서 작동하도록 구성하되 저장된 API 자격 증명과 같이 클라우드 플랫폼에 특정한 문제를 테스트하도록 구성되어야 한다.
11 데이터 보안 및 암호화(Data Security and Encryption)
데이터 보안은 정보 및 데이터 거버넌스를 위한 주요 시행 도구이다. 클라우드 보안의 모든 영역과 마찬가지로 모든 것을 동등하게 보호하는 것은 적절하지 않으므로 클라우드의 사용은 리스크에 기반해야 한다. 해당 파트는 클라우드 관련 여부에 관계없이 전반적인 데이터 보안에 해당한다. 하지만 많은 조직은 중요 데이터의 전부는 아니지만 많은 데이터양을 제삼자에게 공급하거나 내부 데이터를 공유 리소스 풀에 혼합하는데 익숙하지는 않다. 따라서 이러한 사항은 안전하고 비용적으로 효율적인 위험 기반 접근방식을 고수하는 대신 ‘클라우드의 모든 것’에 대한 포괄적인 보안 정책을 설정해야 한다.
예를 들어 SaaS의 모든 것을 암호화하는 것은 해당 공급자를 전혀 신뢰하지 않는 것으로 처음부터 공급업체를 사용해서는 안된다는 것을 의미할 수 있다. 하지만 모든 것을 암호화 하는 것이 만병통치약이 아니듯 기기 자체의 보안을 보장하지 않고 데이터 트래픽을 암호화 하는 등 잘못된 보안 의식을 초래할 수 있다.
어떤 관점에서의 정보 보안은 데이터에 대한 보안이지만, 해당 파트는 데이터 자체의 보안과 관련된 정책에 초점을 맞추고 있으며, 그 중 암호화가 가장 중요한 것 중에 하나로 나타내고 있다.
클라우드 제공업체 데이터 보안을 무시하지 말아야 하며, 대부분의 경우 직접 구축하는 것보다 클라우드 제공업체의 보안이 더 안전하고 비용도 저렴하다. 액세스 제어를 결정하기 위한 자격 매트릭스를 만들어야 하며, CASB(Cloud Access Security Broker: 클라우드 접근 보안 중계)를 고려하여 SaaS로 유입되는 데이터를 모니터링 하여야 한다. 일부 PaaS 및 IaaS에는 여전히 도움이 될 수 있지만, 이러한 유형의 대규모 마이그레이션에 대해서는 기존 정책 및 데이터 저장소 보안에 더 많이 의존하고 있다. 데이터, 비즈니스 및 요구사항에 대한 위협 모델에 따라 적절한 암호화 옵션을 사용해야 하며 공급자 관리 암호화 및 저장 옵션을 사용할 것인지 고려해야 한다. 가능한 경우는 고객 키(Customer-managed key)를 사용하는 것이 좋다.
NIST SP-800-57과 ANSI X9.69 및 X9.73은 좋은 보안을 설정하고 암호화 및 키 관리 기술과 프로세스를 올바르게 사용하는데 도움이 되는 표준이다.
12 ID, 사용 권한 및 액세스 관리(Identity, Entitlement, and Access Management)
ID, 사용 권한 및 액세스 관리(IAM)는 클라우드 컴퓨팅의 영향을 많이 받는다. 공공이나 개인 클라우드 모두에서 보안을 손상시키지 않고 IAM을 관리해야 한다. 이 파트에서는 클라우드의 ID 관리에서 변경해야 하는 사항에 중점을 두고 있다. 몇 가지 기본 개념을 검토하는 동안 클라우드가 ID 관리를 변경하는 방법과 이에 대해 수행할 작업에 중점을 둔다.
사설 클라우드에서의 주요 차이점은 공급자와 사용자 간의 관계이다. IAM은 둘 중 하나에 의해서만 관리 될 수 없으므로 신뢰 관계, 책임 지정 및 이를 가능하게 하는 기술적 메커니즘이 필요하다. 클라우드는 앞으로도 빠르게 변화하고 더욱 광범위한 네트워크 통신에 의존하여 핵심 인프라를 관리할 것이다.
본 파트는 주로 조직과 클라우드 제공업체 간 또는 제공업체와 서비스 간의 IAM에 대해 중점적으로 다룬다. IaaS에서 실행되는 엔터프라이즈 애플리케이션을 위한 내부 IAM과 같은 클라우드 애플리케이션 내 모든 면의 IAM에 대해서는 설명하지 않는다.
조직은 클라우드 서비스를 통해 ID와 권한을 관리하기 위한 포괄적이고 공식화 된 계획 및 프로세스 등을 개발해야 한다. 외부 클라우드 공급자에게 연결 할 때 가능한 경우 페더레이션을 사용하여 기존 ID 관리를 확장해야 한다. 또한 내부 ID에 연결되지 않은 클라우드 공급자의 ID를 최소화 해야 한다.
클라우드 사용자는 모든 외부 클라우드 계정에 대해 MFA를 선호하고 연합 인증을 사용할 때 MFA 상태를 속성으로 보내야 한다. 또한 권한이 잇는 ID는 항상 MFA를 사용해야 한다.
메타 구조나 관리 플레인에 대한 액세스를 강조하여 각 클라우드 공급자 및 프로젝트에 대한 권한 매트릭스를 만들어야 한다. 클라우드 컴퓨팅의 경우 RBAC보다 ABAC를 선호한다. 도한 클라우드 제공업체는 개방형 표준을 사용하여 내부 ID와 페더레이션을 모두 제공해야 한다고 이야기 하고 있다.3
13 서비스로서의 보안(Security as a Service)
해당 파트에서는 클라우드 플랫폼 및 배포 보안에 중점을 두지만 클라우드에서 제공되는 보안 서비스를 다루기 위한 내용을 포함하고 있다. 일반적으로 SaaS 또는 PaaS인 서비스는 클라우드 배포를 보호하기 위해 반드시 사용되어야 하는 것은 아니다. 기본적으로 온 프레미스 인프라를 방어하는데 도움이 된다는 의미이다.
SaaS 제공업체는 보안 기능을 클라우드 서비스로 제공한다. 여기에는 전용 SECaaS 공급자는 물론 일반 클라우드 컴퓨팅 공급자의 패키지 보안 기능이 포함된다. 서비스로서의 보안은 매우 광범위하지만 아래와 같은 기준을 충족해야 한다.
SECaaS에는 클라우드 서비스로 제공되는 보안 제품 또는 서비스가 포함되어야 한다.
SECaaS로 간주하려면 서비스가 2.1에 정의된 클라우드 컴퓨팅의 필수 NIST 특성을 충족해야 한다.
해당 파트에서는 SECaaS의 일부를 강조하고 있지만 다루지 않은 예외 서비스가 존재하며, 더욱 많은 서비스가 지속적으로 시장에 출시되기 때문에 해당 부분은 지속적으로 업데이트 할 필요가 있다.
SECaaS 공급자와 협조하기 전에 데이터 처리 및 가용성, 조사 및 규정 준수에 대한 보안 요구사항을 이해해야 한다. PII(Personally Identifiable Information: 개인식별정보)와 같은 규제 데이터 처리에는 특히 주의해야 한다. 데이터 보존 요구사항을 이해하고 종속 상황을 만들지 않는 데이터 피드를 지원할 수 있는 공급자를 선택해야 한다. SECaaS 서비스가 지원되는 클라우드 플랫폼, 워크 스테이션 및 모바일 운영체제 등과 호환이 되는지 확인해야 한다.
14 관련 기술(Related Technologies)
해당 파트는 클라우드 컴퓨팅을 직접 보호하기 위한 배경 정보와 모범사례를 제공하는데 초점을 맞추었다. 클라우드의 모든 잠재적인 부분까지 다루는 것은 본 문서의 범위를 많이 벗어난다. CSA는 클라우드와 관련된 핵심 기술에 대한 배경 및 환경 개선 사항을 포함하는 것이 중요하다고 생각한다. 컨테이너 및 소프트웨어 정의, 네트워크와 같은 부분은 각 매우 밀접하게 얽혀있어 다양한 지침들의 영역에서 다루고 있다.
해당 파트에서는 Bigdata, Internet of Things(IoT), Mobile, Serverless Computing 등에 대해 다루고 있다.
빅데이터 보안 기능 도구와 겹치는 경우에도 가능하면 클라우드 공급자가 제공하는 보안을 활용하는 것이 좋다. 이를 통해 클라우드 메타 구조 및 특정 애플리케이션 스택 내에서 적절한 보호를 받을 수 있다. 데이터 수집 및 데이터 스토리지 플레인 모두에 대해 기본, 중간 및 백업 스토리지에 암호화를 사용하고, 자격 매트릭스에 빅데이터 도구와 클라우드 플랫폼 ID 및 액세스 관리도 포함된다. 빅데이터 보안은 CSA에서 제공하는 사항을 포함하여 추가 빅데이터 보안 모범사례를 따르도록 한다.
IoT에서는 장치를 패치하고 업그레이드 할 수 있는지 확인해야 한다. 클라우드 애플리케이션 또는 인프라를 손상시킬 수 있는 장치에 정적 인증서를 저장하면 안된다. 일반적으로 페더레이션 된 ID 표준을 사용하여 클라우드 측 애플리케이션에 대한 보안 장치 등록 및 인증을 위한 모범사례들을 따라야 한다. CSA Internet of Things Working Group에서 발행한 자세한 추가 지침들을 따르도록 한다.
클라우드 인프라에 직접 연결되는 애플리케이션을 설계할 때 모바일 장치를 올바르게 인증하고 승인하는 방법에 대한 클라우드 제공업체의 지침을 따라야 한다. 모바일 장치 애플리케이션을 클라우드 호스팅 애플리케이션에 연결하기 위해 일반적으로 페더레이션 ID인 산업 표준을 사용한다. 모바일에서는 인터넷을 통해 암호화되지 않은 키 또는 자격 증명을 전송하면 안된다. 또한 적대적인 공격자가 인증되고 암호화되지 않은 액세스 권한을 갖는다는 가정하에 모든 API를 테스트 해야 한다. CSA Mobile Working Group에서 발행한 보다 자세한 권장 사항을 따르도록 한다.
클라우드 제공업체는 어떤 PaaS 서비스가 어떤 규정 준수, 요구사항 또는 표준에 대해 평가되었는지 명확하게 명시되어야 한다. 클라우드 사용자는 규정 준수 및 거버넌스 의무와 일치하는 서버리스 서비스만 사용해야 하며, 공격 측면이나 네트워크 공격 경로를 제거하는 아키텍처를 사용하여 애플리케이션 스택에 서버리스 구성 요소를 삽입하는 것을 고려해야 한다. 또한, 클라우드 사용자는 서버 및 네트워크 로그보다는 애플리케이션 코드 스캔 및 로깅 더 많이 신경을 써야 한다. 또한, 서버리스 배포를 위해 사고 대응 프로세스를 주기적으로 업데이트 해야 한다. 클라우드 공급자는 서버리스 플랫폼 수준 이하의 보안을 담당하고 있지만 클라우드 사용자는 제품을 올바르게 구성하고 사용할 책임을 지고 있다.
