CSA(Cloud Security Alliance)는 “클라우드 컴퓨팅 내에서 보안 보증을 제공하는 모범 사례사용을 촉진하고 기타 모든 형태의 컴퓨팅을 보호할 수 있도록 클라우드 컴퓨팅 사용에 대한 교육을 제공”하는 비영리 조직이다. 국내에는 클라우드 컴퓨팅 환경으로 변모 중인 국내 IT 산업 환경에 대비하여, 안전한 미래 사업 환경을 조성하고, 수익을 창출하기 위하여 (사)한국클라우드보안협회가 2008년 말에 설립되었다.

 

CSA에서 ‘17년에 발간한 ’For Critical Areas of Focus In Cloud Computing v4.0’에 대해서 간략하게 알아보며, 발간물을 통해 클라우드 컴퓨팅에 대한 기본 정의에 대해 알아본다.

 

이 도메인은 Cloud Security Alliance의 지침에 대한 개념적 프레임워크를 제공한다. 클라우드 컴퓨팅에 대한 정의, 기본 용어에 대한 설명, 전체적인 논리적 아키텍처 프레임워크를 설명한다.

 

해당 도메인은 아래의 4가지 항목을 포함하고 있다.

 

▶ 클라우드 컴퓨팅 정의

▶ 클라우드 논리 모델

▶ 클라우드 개념, 아키텍처 및 참조 모델

▶ 클라우드 보안 및 규정 준수 범위, 책임 및 모델

 

CSA는 완전히 새로운 분류체계나 참조 모델을 만들려고 하는 것은 아니며, 목표는 기존 모델(NIST Special Publication 800-145, ISO/IEC 17788 및 ISO/IEC 17789)을 보안과 관련이 높은 항목들에 대해 초점을 맞춘 것이다.

 

1.1 클라우드 컴퓨팅 정의

 

클라우드 컴퓨팅은 컴퓨팅 리소스의 공유 풀을 관리하기 위한 새로운 운영 모델이자 기술 셋이다.

 

NIST에서는 다음과 같이 정의하였다.

▶ 클라우드 컴퓨팅은 구성 가능한 컴퓨팅 리소스(예: 네트워크, 서버, 스토리지, 애플리케이션 및 서비스)의 공유 풀에 대한 유비쿼터스의 편리한 온-디맨드(On-demand: 공급중심이 아닌 수요 중심에서 결정하는 시스템이나 전략등을 총칭함) 네트워크 액세스가 가능한 모델이다.

 

ISO/IEC에서는 매우 간단하게 정의를 하였다.

▶ 셀프서비스 프로비저닝 및 온 디멘드(On-demand) 관리를 통해 공유 가능한 물리적 또는 가상 리소스의 확장이 가능하고 탄력적 풀에 대한 네트워크 액세스를 가능하게 하는 패러다임

 

더 간단히 클라우드를 설명하는 방법은 프로세서와 메모리와 같은 리소스 집합을 가져와서 큰 풀에 넣는 것이다. 소비자는 8개의 CPU와 16GB의 메모리와 같은 풀에서 필요한 것을 요청하고, 클라우드는 이러한 리소스를 클라이언트에 할당 한 다음 네트워크를 통해 연결하여 사용하는 것이다. 클라이언트가 완료되면 다른 사람이 사용할 수 있도록 리소스를 다시 해제할 수 있다.

 

클라이언트 사용자는 리소스를 요청하고 사용하는 사람 또는 조직이고, 클라우드 공급자는 리소스를 제공하는 사람 또는 조직이다. 또한, 때때로 클라우드 사용자 및 서비스를 지칭하기 위해 클라이언트 및 소비자라는 용어를 사용하기도 한다. NIST 500-292는 “클라우드 행위자”라는 용어를 사용하며, ISO/IEC 17788은 클라우드 서비스 고객, 클라우드 서비스 파트너 및 클라우드 서비스 공급자라는 용어를 사용한다.

 

1.2 모델 정의

 

CSA는 클라우드 컴퓨팅 모델을 정의하기 위한 표준으로 NIST 모델을 사용한다. 또한 추가로 ISO/IEC 모델을 참조한다.

NIST는 5가지 필수 특성, 3가지 클라우드 서비스 모델 및 4가지 클라우드 배포 모델을 설명하여 클라우드 컴퓨팅을 정의한다.

 

사진 삭제

클라우드 컴퓨팅 모델

 

 

1.2.1 필수 특성(Essential Characteristics)

 

필수 특성은 클라우드를 만드는 특성이다. 위 그림에서 Essential Characteristics 범주의 특성에 포함이 된다면 클라우드 컴퓨팅으로 간주한다. 하지만 특성 중 하나라도 포함되지 않는다면 클라우드의 특성이 아닐 확률이 높다.

 

▶ 리소스 풀링(Resource Pooling)은 가장 기본적인 특성이다. 공급자는 리소스를 추상화하고 Pool로 수집할 수 있으며, 일부는 다른 소비자에게 할당 할 수 있다.

▶ 소비자는 주문형 셀프서비스(On-Demand Self-Service)를 사용하여 Pool에서 리소스를 프로비저닝 한다. 관리자와 상의할 필요 없이 리소스를 직접 관리한다.

▶ 광범위한 네트워크 액세스는(Borad Network Access) 직접적인 물리적 액세스 없이 네트워크를 통해 모든 리소스를 사용할 수 있어야만 한다. 하지만 네트워크는 서비스의 일부에서 제외된다.

▶ 빠른 탄력성(Rapid Elasticity) 덕분에 소비자는 풀에서 사용하는 리소스를 확장하거나 축소할 수 있다.(프로비저닝 및 디프로비저닝) 이를 통해 리소스 소비와 수요를 보다 밀접하게 일치시킬 수 있다.(수요가 증가하면 가상서버를 추가하고 수요 감소 시에는 드랍시킴)

▶ 측정된 서비스(Measured Service)는 제공되는 항목을 측정하여 소비자가 할당 된 항목만 사용하고 필요한 경우 요금을 부과하도록 한다. 이것으로 인해 유틸리티 컴퓨팅이라는 용어가 나오게 되었다.

▶ ISO/IEC 17788에는 6가지 주요 특성이 나열되어 있다. 그 중 5개는 NIST 특성과 같다. 유일한 추가는 리소스 풀링과는 다른 멀티테넌시이다.

 

1.2.2 서비스 모델(Service Models)

 

NIST는 클라우드 서비스의 다양한 기본 범주를 설명하는 3가지 서비스 모델의 정의한다.

 

▶ SaaS(Software as a Service)는 공급자가 관리하고 호스팅하는 완전한 애플리케이션이다. 소비자는 웹 브라우저, 모바일 앱 또는 경량 클라이언 앱을 통해 액세스 한다.

▶ PaaS(Platform as a Service)는 데이터베이스, 애플리케이션 플랫폼(ex. Python, PHP 또는 기타 코드 실행 장소) 파일 저장 및 공동 작업 또는 독점 애플리케이션 처리(예: 기계학습, 빅데이터 처리 또는 SaaS 애플리케이션 기능에 대한 직접적인 API(응용 프로그래밍 인터페이스) 액세스)와 같은 플랫폼을 추상화하고 제공한다.

▶ IaaS(Infrastructure as a Service)는 컴퓨팅, 네트워크 또는 스토리지와 같은 기본 컴퓨팅 인프라의 리소스 풀에 대한 액세스를 제공한다.

 

해당 계층은 때때로 “SPI”라고 불린다. ISO/IEC는 SPI 계층(애플리케이션, 인프라 및 플랫폼 기능 유형)에 밀접하게 맵핑되는 클라우드 기능 유형으로 복잡한 정의를 사용한다. 그런 다음 Compute as a Service, Data Storage as a Service와 같이 보다 세분화된 클라우드 서비스 범주로 확장된 다음 IaaS, PaaS, SaaS를 포함하게 된다.

 

1.2.3 배포 모델

 

NIST와 ISO/IEC는 모두 동일한 4개의 클라우드 배포 모델을 사용한다.

 

▶ Public Cloud: 클라우드 인프라는 일반 대중이나 대규모 산업 그룹이 사용할 수 있으며, 클라우드 서비스를 판매하는 조직을 소유한다.

▶ Private Cloud: 클라우드 인프라는 단일 조직을 위해서만 운영된다. 조직 또는 제삼자가 관리할 수 있고, 온 프레미스(On-premise: 소프트웨어 등 솔루션을 클라우드 같이 원격 환경ㅇ이 아닌 자체적으로 보유한 서버에 직접 설치에 운영하는 방식) 또는 오프 프레미스(Off-Premises: 온프레미스와 반대로 클라우드 방식의 서비스를 의미)에 위치할 수 있다.

▶ Community Cloud: 클라우드 인프라는 여러 조직에서 공유하며, 보안 요구사항, 정책 또는 규정 준수 고려사항 등을 공유한 특정 커뮤니티를 지원한다. 조직 또는 제삼자가 관리할 수 있으며, 온 프레미스 또는 오프 프레미스에 위치할 수 있다.

▶ Hybrid Cloud: 클라우드 인프라는 고유한 엔티티로 유지되지만 데이터 및 애플리케이션 이식성을 가능하게 하는 표준화 또는 독점 기술(ex. 클라우드 간 로드 밸런싱을 위한 클라우드 버스팅)에 의해 결합하는 둘 이상의 클라우드(사설, 커뮤니티 또는 공용)로 구성된다. 하이브리드는 일반적으로 클라우드 제공업체에 직접 연결된 비 클라우드 에이터 센터를 설명하는데 사용된다.

사진 삭제

클라우드 배포 모델 및 인프라(자료: IssA M Khali et al. 2014.02)

 

1.3 참조 및 아키텍처 모델

 

최근에는 클라우드 서비스를 구축하기 위해 끊임없이 진화하는 기술 기법이 광범위하여 처음부터 단일 참조 모델이나 아키텍처 모델을 쓸모없게 만들고 있다. 해당 부분의 목적은 보안 전문가들이 정보를 제공하는 데 도움이 되는 몇 가지 기본사항과 새로운 모델을 이해하기 위한 기준을 제공하는 것이다.

 

사진 삭제

사진 설명을 입력하세요.

 

1.3.1 IaaS(Infrastructure as a Service)

 

물리적 시설 및 인프라 하드웨어는 IaaS의 기반을 형성한다. 클라우드 컴퓨팅을 통해 이러한 리소스를 추상화하고 풀링하지만 가장 기본적인 수준에서는 구축할 물리적 하드웨어, 네트워크 및 스토리지가 필요하다. 이러한 리소스는 추상화 및 오케스트레이션을 사용하여 풀링된다. 추상화는 가상화를 통해 리소스를 물리적 제약에서 해제하여 풀링을 가능하게 하고, 핵심 연결 및 전달 도구(오케스트레이션: 컴퓨터 시스템과 어플리케이션 서비스의 자동화된 설정, 관리, 조정을 의미)가 이러한 추상화된 리소스를 함께 연결하고 풀을 생성하여 자동으로 고객에게 제공한다.

 

이 모든 것은 응용 프로그래밍 인터페이스를 사용하여 촉진된다. API는 일반적으로 클라우드 내의 구성 요소에 대한 기본 통신 방법이며, 일부(또는 완전히 다른 집합)는 클라우드 사용자에게 노출되어 리소스 및 구성을 관리한다. 요즘 대부분의 클라우드 API는 HTTP 프로토콜을 통해 실행되는 REST(Representational State Transfer)를 사용하므로 인터넷 서비스에 매우 적합하다.

 

대부분의 경우 이러한 API는 원격으로 액세스 할 수 있으며, 웹 기반 사용자 인터페이스로 랩핑된다. 소비자가 가상머신(인스턴스) 시작 또는 가상 네트워크 구성과 같은 클라우드 리소스를 관리 및 구성하는데 사용하기 때문에 이 조합은 클라우드 관리영역이다. 보안 관점에서 볼 때 물리적 인프라 보호와의 가장 큰 차이점(물리적 액세스를 제어 수단으로 사용할 수 없기 때문에)이자 클라우드 보안 프로그램을 설계 할 때 최우선 순위이다. 공격자가 관리영역에 침입하면 잠재적으로 전체 클라우드 배포에 대한 완전한 원격 액세스 권한을 갖게 된다.

 

따라서, IaaS는 시설, 하드웨어, 추상화 계층, 추상화 된 리소스를 함께 연결하는 오케스트레이션(핵심 연결 및 전달) 계층과 리소스를 원격으로 관리하고 소비자에게 제공하는 API로 구성된다.

 

사진 삭제

컴퓨팅 IaaS 플랫폼의 단순화 된 아키텍처

 

위의 그림은 오케스트레이션을 위한 컴퓨팅 및 스토리지 컨트롤러, 추상화를 위한 하이퍼 바이저, 컴퓨팅과 스토리지 풀 간의 관계를 보여주는 간단한 다이어그램이다. 하지만 네트워크 관리자와 같은 많은 구성 요소가 생략되어 있다.

 

일련의 물리적 서버는 각각 하이퍼 바이저(가상화 용)와 서버를 연결하고 컴퓨팅 컨트롤러에 연결하는 관리/오케스트레이션 소프트웨어의 두 가지 구성 요소를 실행한다. 고객이 특정 크기의 인스턴스(가상서버)를 요청하면 클라우드 컨트롤러가 용량이 있는 서버를 결정하고 요청된 크기의 인스턴스를 할당한다. 그런 다음 컨트롤러는 스토리지 컨트롤러에서 스토리지를 요청하여 가상 하드디스크 드라이브를 생성하여 스토리지 풀에서 스토리지를 할당하고 이를 네트워크(스토리지 트래픽 전용 네트워크)를 통해 적절한 호스트 서버 및 인스턴스에 연결한다. 가상 네트워크 인터페이스 및 주소를 포함한 네트워킹도 필요한 가상 네트워크에 할당되고 연결된다. 그런 다음 컨트롤러는 서버 이미지의 사본을 가상 머신으로 전송하고 부팅한 다음 구성을 완료한다. 이렇게 하면 가상 네트워킹 및 스토리지가 모두 올바르게 구성된 가상머신(VM)에서 실행되는 인스턴스가 생성된다. 이 전체 프로세스가 완료되면 메타 데이터 및 연결 정보가 클라우드 컨트롤러에 의해 중개되고 소비자가 사용할 수 있으며, 소비자는 이제 인스턴스에 연결하고 로그인 할 수 있다.

 

1.3.2 PaaS(Platform as a Service)

 

모든 서비스 모델 중에서 PaaS는 광범위한 PaaS 오퍼링과 PaaS 서비스를 구축하는 다양한 방법으로 특성화하기 가장 어렵다. PaaS는 애플리케이션 개발 프레임 워크, 미들웨어 기능 및 데이터베이스, 메시징 및 대기열과 같은 기능과의 추가 통합계층을 추가한다. 이러한 서비스를 통해 개발자는 스택에서 지원하는 프로그래밍 언어 및 도구를 사용하여 플랫폼에서 애플리케이션을 빌드 할 수 있다.

 

현실 세계에서 자주 볼 수 있는 모델 옵션 중 하나는 IaaS 위에 플랫폼을 구축하는 것이다. 통합 및 미들웨어 계층은 IaaS에 구축 된 다음 함께 풀링되고 조정되며 PaaS로 API를 사용하여 고객에게 노출된다. 예를 들어 Database as a Service는 IaaS에서 실행되는 인스턴스에 수정 된 데이터베이스 관리 시스템 소프트웨어를 배포하여 구축할 수 있다. 고객은 API(및 웹 콘솔)를 통해 데이터베이스를 관리하고 일반 데이터베이스 네트워크 프로토콜을 통해 API를 액세스 한다.

 

사진 삭제

IaaS 아키텍처 기반 PaaS 애플리케이션 플랫폼 아키텍처

 

 

PaaS는 반드시 IaaS 기반에 구축될 필요는 없다. PaaS가 맞춤 독립형 아키텍처가 될 수 있지만 정의하기 어려운 이유는 소비자 접근과 플랫폼 관리가 근본적으로 인프라 기반이기 때문이다.

 

1.3.3 SaaS(Software as a Service)

 

SaaS 서비스는 대규모 소프트웨어 플랫폼의 모든 아키텍처 복잡성을 가진 완전한 다중 테넌트 애플리케이션이다.

 

대부분의 최신 클라우드 애플리케이션(SaaS 또는 기타)은 IaaS와 PaaS의 조합을 사용하며, 때로는 다른 클라우드 제공 업체 간에 사용되기도 한다. 또한 많은 사람들이 일부 기능에 대해 공용 API를 제공하는 경향도 있다. 다양한 클라이언트, 특히 웹 브라우저 및 모바일 애플리케이션을 지원하기 위해 이런 기능들이 필요로 한다. 따라서 모든 SaaS에는 애플리케이션/로직 레이어 및 데이터 스토리지가 있으며, API가 맨 위에 존재한다.

 

 

사진 삭제

SaaS 플랫폼 구성도

 

1.4 로직 모델

 

높은 수준에서 클라우드와 기존 컴퓨팅 모두 기능에 따라 다른 계층을 식별하는데 도움이 되는 논리적 모델을 준수한다. 이는 서로 다른 컴퓨팅 모델 자체의 차이점을 설명하는데 유용하다.

 

▶ 인프라(Infrastructure): 컴퓨팅 시스템의 핵심 구성 요소 – 컴퓨팅, 네트워크 및 스토리지

▶ 메타구조(Metastructure): 인프라 계층과 다른 계층 간의 인터페이스를 제공하는 프로토콜 및 메커니즘. 기술을 연결하고 관리 및 구성을 가능하게 하는 접착제 역할

▶ 정보구조(Infostructure):　데이터 및 정보, 데이터베이스, 파일 저장소 등의 콘텐츠

▶ 애플리케이션 구조(Applistructure): 클라우드에 배포된 애플리케이션과 이를 구축하는데 사용되는 기본 애플리케이션 서비스(메시지 대기열, 인공지능 분석 또는 알림 서비스와 같은 PaaS 기능)

 

클라우드와 기존 컴퓨팅의 주요 차이점은 메타 구조이다. 클라우드 메타 구조에는 네트워크를 지원하고 원격으로 액세스 할 수 있는 관리영역 구성 요소가 포함되어 있다. 또 다른 차이점은 클라우드에서는 각 레이어에 이중화하는 경향이 있다는 것이다. 예를 들어 인프라에는 클라우드 생성에 사용되는 인프라뿐만 아니라 클라우드 사용자가 사용하고 관리하는 가상 인프라가 모두 포함된다는 점이다. 공공 클라우드에서는 제공자가 물리적 인프라를 관리하는 반면, 소비자가 가상 인프라의 일부를 관리하지만 사설 클라우드에서는 동일한 조직이 두 가지 모두 관리가 가능해야 한다.

 

1.5 클라우드 보안 범위, 책임과 모델

 

1.5.1 클라우드 보안과 규정 준수 범위 및 책임

 

클라우드 보안 및 규정 준수에는 보안 팀이 클라우드 영역 내에 담당하는 모든 부분이 포함된다. 전통적인 보안 영역은 그대로 유지되지만 위험, 역할 및 책임의 특성은 종종 변화하기도 한다.

 

보안과 규정 준수의 전체 범위는 변하지 않지만, 주어진 클라우드 운영자가 책임져야 할 부분은 거의 확실하다. 이것은 일반적으로 공동 책임 모델이라고 한다. 특정 클라우드 제공업체 및 기능/제품, 서비스 모델 및 배포 모델에 따라 달라지는 책임 매트릭스로 생각하면 된다.

 

사진 삭제

아키텍처 스택에 따른 보안 책임

 

행위자가 아키텍처 스택에 대해 규제 수준에 따라 보안 책임 범주가 다르게 된다. 가장 중요한 보안 고려 사항은 주어진 클라우드 프로젝트에서 누가 무엇을 책임지고 있는지 정확하게 판단하고 있어야 하는 것이다. 특히 클라우드 업체가 제공하는 클라우드의 기능과 작동 방식을 정확히 알고 있어야 하는 것이다.

 

▶ 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 서비스가 어떤 규정 준수, 요구사항 또는 표준에 대해 평가되었는지 명확하게 명시되어야 한다. 클라우드 사용자는 규정 준수 및 거버넌스 의무와 일치하는 서버리스 서비스만 사용해야 하며, 공격 측면이나 네트워크 공격 경로를 제거하는 아키텍처를 사용하여 애플리케이션 스택에 서버리스 구성 요소를 삽입하는 것을 고려해야 한다. 또한, 클라우드 사용자는 서버 및 네트워크 로그보다는 애플리케이션 코드 스캔 및 로깅 더 많이 신경을 써야 한다. 또한, 서버리스 배포를 위해 사고 대응 프로세스를 주기적으로 업데이트 해야 한다. 클라우드 공급자는 서버리스 플랫폼 수준 이하의 보안을 담당하고 있지만 클라우드 사용자는 제품을 올바르게 구성하고 사용할 책임을 지고 있다.