해당 포스트는 “마이크로소프트웨어 389호“에 제가 기고한 글입니다.


 클라우드 보안을 정복하는 기술
(Security really matters on Public Cloud)

Joon Park(Cloud Engineer) @ IBM Korea
‘클라우드 컴퓨팅(Cloud Computing)’은 이제 더 이상IT기업 혹은 IT 관련 업계 종사자들 만의 화두가 아니다. 우리가 사용하는 IT 서비스의 대부분은 클라우드를 통해 서비스가 되고 있다. 이미 클라우드는 우리 생활 깊숙이 매우 큰 자리를 차지하고 있다는 것이다.
이러한 클라우드, 특히 퍼블릭 클라우드(Public Cloud)를 도입할 때 가장 신경을 쓰고 주의 깊게 검토해야 하는 항목이 바로 ‘보안(Security)’이다.
이 글에서는 퍼블릭 클라우드 환경에서 보안의 중요성, 전산 센터(On-Premise IDC) 환경과의 차이점, 퍼블릭 클라우드 환경의 보안 모범사례(Best Practices)’에 대해 알아보도록 하겠다.
포브스(Forbes)에서 조사한 ‘2017 State Of Cloud Adoption And Security 에 따르면 기업의 데이터를 퍼블릭 클라우드 환경에 보관하는 것에 대해 단지 23%의 기업만 완벽하게 신뢰한다고 응답했다.

<그림1> To What extent do you trust the following to keep your org’s sensitive data secure?
위와 같은 통계는 해외의 사례지만, 우리나라의 경우도 절대로 23% 이상이 나오지 않을 것이라고 클라우드 경험자들 대부분 매우 격하게 공감할 것이다. 국내 대부분 기업들이 퍼블릭 클라우드 도입 검토 시 가장 고려하는 요소 중에 하나가 바로 보안이기 때문이다.
자 그럼, 기존에 운영하던 전산 센터(On-premise IDC) 환경과 퍼블릭 클라우드(Off-Premise)환경에 대해 보안 측면에서 차이점과 고려 사항을 알아보자.
 .
1-1. 퍼블릭 클라우드에서는 전산 센터(IDC)와 동급 수준의 보안정책(환경)을 기대하지 말자.
 .
클라우드를 도입(혹은 예정인)하려는 대다수의 고객들이 오해하고 있는 부분은 클라우드 도입 시에도 기존에 운영하던 전산 센터(On-Premise IDC) 환경과 동일한 보안 수준을 유지할 수 있을 것이라는 기대감이다.
기존 전산 센터(IDC) 환경에서는 고객이 데이터 센터(Data Center) 레벨’, 서버, 스토리지, 네트워크장비와 같은 기계장치(Hardware) 레벨그리고 가상화를 위한 하이퍼바이저(Hypervisor)레벨’, 그리고 마지막으로 가상 서버(Virtual Server) 레벨에 대해 직접 관리 및 수정할 수 있는 통제 권한을 갖고 있다. 그래서 전산 센터 환경에서는 자신의 업무환경 혹은 서비스 워크로드의 보안 중요도에 맞춰 물리적인 보안 장비(Security Appliance), 혹은 보안 정책을 각각의 레벨에 적용(관리)할 수 있다.
일반적인 퍼블릭 클라우드(IaaS)의 경우 데이터 센터, 기계장치, 하이퍼바이저 레벨에 대해서는 고객이 접근 혹은 수정할 수 있는 통제 권한이 철저히 배제된다. 해당 레벨에 문제나 보안 이슈가 발생해도 클라우드 서비스 제공업체(Cloud Service Provider)에서 해결해 줄 때까지 기다릴 수밖에 없다.
결국 일반적인 퍼블릭 클라우드 사용자의 경우에는 클라우드 업체에서 제공하는 보안관련 기능(Built-in 혹은 3rd-Party)만 사용할 수 있으며, 전산 센터(IDC) 환경에서 적용했던 물리적인 보안장비(Appliance)나 클라우드 업체에서 제공할 수 없는 보안 기능 및 제품들은 퍼블릭 클라우드 환경에서는 적용할 수 없다. 전산 센터 환경에서 물리적인 레벨에 적용했던 보안정책을 퍼블릭 클라우드 환경으로 동일하게 옮겨올 수 없는 것이다
 .
1-2. 퍼블릭 클라우드의 책임 분담 모델(Shared Responsibility Model)’에 대한 이해 
 .
<그림2>처럼 퍼블릭 클라우드(Off-Premise)환경은 클라우드 고객(Customers)과 클라우드 업체(CSP, Cloud Service Provider)로 통제권을 갖고 있는 계층이 분리돼 있으며, 해당 계층의 보안 설정 및 정책을 각각 관리 해야 되는 책임 분담 모델(Shared Responsibility Model)’을 갖고 있다.
<그림3>에서 보듯이 클라우드 업체(CSP)는 클라우드 데이터 센터에 물리적 보안(출입통제, 물리적 기계장치 접근 등)과 논리적 보안(하이퍼바이저 레벨, 자원의 논리적인 분리 등)에 관한 보안을 책임진다. 퍼블릭 클라우드(IaaS) 사용 고객은 운영체제(OS)의 패치 관리, 접근제어 정책(방화벽 룰 설정 등), 인증 및 계정정보 관리, 어플리케이션 및 데이터 암호화 등에 대해 책임을 갖고 있다. 클라우드 업체와 클라우드 사용자는 이러한 책임 분담 모델환경 아래, 각자가 관리해야 하는 계층에 대한 책임을 인지하고 운영해야 한다. 보안 이슈가 생길 경우에도 해당 계층에 책임을 갖고 있는 소유자가 책임을 진다.
물론 앞의 책임 분담 모델은 퍼블릭 클라우드의 서비스 모델 중에서도 IaaS(Infrastructure as a Service)에 경우에 해당한다. PaaS(Platform as a Service) 혹은 SaaS(Software as a Service) 같은 상위 서비스 모델로 올라갈수록 클라우드 업체(CSP)가 보안에 대해 고객 보다 많은 범위를 책임지며, 고객이 직접 보안을 위해 환경설정 및 수정할 수 있는 범위가 작아진다.
 .
1-3. 공유 자원(Shared Resources)과 전용 자원(Dedicated Resource)의 차이점 
 .
<그림4>에서 보듯이 물리적으로 하나의 리소스를 여러 명의 클라우드 고객이 나눠서 사용하는 환경을 공유 자원(Shared Resources)이라고 한다. ‘고객A’가 데이터를 저장을 하면  ‘고객B’ 뿐만 아니라 고객C’와도 물리적으로 동일한 디스크에 저장한다.
물론 클라우드 업체(CSP)는 이러한 디스크 리소스를 물리적으로만 공유(Physically Shared)하고, 논리적으로는 분리(Logically Isolated)시켜서 보안 이슈가 없도록 클라우드 서비스를 제공하고 있다.
특정 고객은 서비스(워크로드)의 특징(전자상거래 등) 혹은 보안 컴플라이언스(, PCI-DSS, Payment Card Industry Data Secure Stored)의 이유로 인해 위와 같은 논리적 데이터 분리가 아닌 물리적 분리(Physically Isolated)를 요구하는 사례도 존재한다. 이러한 경우 물리적 분리를 할 수 있도록 전용 자원(Dedicated Resources)을 제공하는 클라우드 업체도 존재한다. IBM Cloud Bare-Metal Server, Private Virtual Server, Dedicated Storage Server, Dedicated Security Appliance 등이 그 예다.
위에서는 데이터를 저장하는 스토리지(Disk)자원을 주로 살펴보았으나, 퍼블릭 클라우드에서는 서버, 네트워크, 가상화를 위한 하이퍼바이저 등 다양한 컴퓨팅 리소스들도 공유 자원(Shared Resources) 방식을 적용하는 것이 매우 일반적이다.
클라우드 컴퓨팅을 적용할 때에 고려해야 할 보안 관련 사항을 알아봤다. 클라우드 환경의 보안정책은 제약(Constraint)’을 동반한다. 고객이 고려할 수 있는 수준의 보안 레벨과 정책 수립, 고객에게 책임이 있는 계층(Layer) 관리, 공유 자원(Shared Resources)과 전용 자원(Dedicated Resources)에 대한 이해와 구분을 고려해 퍼블릭 클라우드 컴퓨팅 환경을 꾸릴 수 있어야 한다.
 .
 .
2. 퍼블릭 클라우드(Public Cloud)환경에서의 보안 모범사례(Best Practices)
 .
지금까지 언급 했던 퍼블릭 클라우드(IaaS)환경의 보안 관련 사항을 토대로, ‘보안 모범사례를 소개한다.
 .
2-1. 퍼블릭 클라우드(IaaS)Self Managed Service(직접 관리) 해야 한다. ‘보안도 예외가 아니다.
 .
 – 클라우드 포털 접속은 2차인증(MFA, Multi Factor Authentication)을 사용
  – 데이터 백업은 고객의 몫,  클라우드 업체에서 제공하는 백업 기능을 적용
  – 기본적인 보안정책은 클라우드 환경에서도 준수(인증정보에 대한 관리 등)
  – 관리를 위한 서버 접속은 VPN(가상사설네트워크)을 통해 접속하자
클라우드 서비스를 처음 접하는 사람들이 오해하는 것 중 첫번째는 퍼블릭 클라우드 서비스에 가입을 하고 서버를 생성하면 모든(A to Z) 보안설정(방화벽 등)을 클라우드 업체(CSP)에서 적용해줄 것이라 굳게(?) 믿고 있다는 것이다.
퍼블릭 클라우드 환경은 고객이 직접 관리하는 ‘Self Managed’가 원칙이다. 그래서 고객은 클라우드 업체(CSP)에서 제공하는 다양한 보안 기능에 대해 직접 설정하고 적용해야 될 의무(Shared Responsibility)를 갖는다.
퍼블릭 클라우드 가입시 생성된 마스터 계정(Master Account)”으로 클라우드 포털(Portal)에 접속하면, 해당 클라우드 계정에 있는 모든 컴퓨팅 자원(서버, 네트워크, 데이터 스토리지 등)에 대한 생성 및 삭제 권한을 갖는다.
2014 6코드스페이스라는 업체는 사용하고 있던 클라우드 포털 계정의 인증정보를 해킹당했다. 해당 계정이 보유하고 있던 모든 자원(서버, 데이터 등)을 해커가 삭제해, 사업을 폐쇄했던 이야기는 아직도 퍼블릭 클라우드 사용자에게 화자되고 있다.
우리는 코드스페이스의 사례로 클라우드 포털 접속(특히, 마스터 계정)은 패스워드 인증 방식 외에 추가로 ‘2차 인증방법인 OTP(One Time Password)를 사용해 패스워드 해킹에 대비해야 한다는 교훈을 얻을 수 있다. IBM 클라우드는 모바일 어플리케이션(Software OTP) 형태의 ‘Google Authentication’ 연동을 기본적(Built-in)으로 지원한다.
<그림5> 클라우드 포털 접속시 2차 인증을 위한 OTP(One Time Password) 적용
 .
2-2. 퍼블릭 클라우드 초심자들이 실수하는 것 중에 하나인 데이터 백업(Backup)”이다.
 .
퍼블릭 클라우드 환경에서 고객이 실수로 데이터를 삭제한 경우 클라우드 업체(CSP)에 언제든지 연락하면 해당 데이터를 복구시켜줄 수 있다고 강력하게(??) 믿는 클라우드 초심자들을 자주 접한다.
클라우드 업체는 고객이 사용할 수 있는 백업 서비스를 제공하고 있다. 최초 언급한 대로 ‘Self Managed’ 원칙에 따라 고객은 해당 서비스(기능)를 스스로(Self)로 자신의 클라우드 자원으로 적용해야 한다. 가상 서버에 대해 이미지 템플릿(서버에 저장된 데이터를 포함)으로 만들 수 있는 기능, 사용하는 스토리지 데이터를 스냅샷 형태로 만들고 유사시 특정 시점으로 복원할 수 있는 기능, 스토리지 자원을 Block 레벨 혹은 DBMS의 테이블 레벨까지 백업을 지원하는 기능 등이 있다. ‘고객이 직접 클라우드 포털에서 선택한 후 적용(물론 유료다)해야만 백업이 시작된다.
이러한 백업 옵션을 본인의 컴퓨팅 자원에 적용하지 않은 채, 실수로 데이터가 유실 되었으니 복구해 달라는 일이 벌어지지 않게 사전에 백업에 대한 준비를 해야한다.
참고로, 클라우드 업체(CSP)는 고객이 데이터를 제거하는 즉시 해당 데이터가 복구될 수 없도록 클라우드 스토리지에서 영구적으로 삭제(Delete with wiping)해야 보안정책(Compliance)에 위배 되지 않는다. 만일 클라우드 업체가 해당 데이터를 복원할 수 있다면 고객 데이터를 동의 없이 열람할 수 있는 가능성이 열리기 때문에 클라우드업체(CSP)는 별도의 백업을 갖고 있을 수가 없다.

 .
2-3. 기존(On-Premise IDC)의 기본 보안정책을 퍼블릭 클라우드 환경에서도 유지하는 것
 .
퍼블릭 클라우드 환경의 리눅스 운영체제 서버(Server)에 접속하는 방법은 ‘Password 인증 방식‘SSH Key 교환방식이 있다. SSH Key 교환방식이 익숙하지 않은 클라우드 사용자는 Password 인증 방식을 사용한다. 심지어 어떤 고객은 Password를 외우기 쉬운 ‘1234567890’으로 변경하는 고객도 있다. 만약 인터넷에 노출돼 있는 서버(Public IP TCP 22번포트가 Any로 외부 오픈된)라면, 해당 서버는 고양이 앞에 놓인 생선처럼 해커에게 매우 좋은 먹잇감이 된다.
위와 같은 패스워드 취약점이 존재하는 서버는 무차별 대입 공격(Brute Force Attack)’ 으로  패스워드가 탈취 당하면 P2P서비스 업로드나 DDoS 공격 용도의 서버로 악용되어, 해당 서버의 실제 주인이 어마어마한 트래픽 비용을 지불하게 만들 수 있다.
Password 인증 방식보다 SSH Key 교환 방식 적용, ‘Root’ 권한 사용자의 SSH 접속 제한, 원격관리를 위한 서비스(TCP 22, TCP 3389) 포트 변경을 적용하거나, 아예 관리용 접속(SSH, RDP)VPN(Virtual Private Network)을 통하여 서버의 공인IP(Public IP)가 아닌 사설IP(Private IP)로 접속(Access)하는 것이 퍼블릭 클라우드 환경에서 서버 접속에 대한 보안성을 높이는 방법이다.
IBM 클라우드 는 무상으로 SSL VPN 서비스를 제공한다. 윈도우즈(Windows) 혹은 맥OS(MAC OS) 사용자들이 손쉽게 접속할 수 있는 ‘SSL VPN 클라이언트와 웹브라우저용 랜딩 페이지(https://www.softlayer.com/ko/VPN-ACCESS )가 있다.
 .
2-4. 최소 권한의 원칙(Least Privileges)은 클라우드 환경에서도 예외가 아니다.
.
  – 클라우드 포털의 마스터 계정은 사용하지 않고, 담당자 업무에 맞춰 하위 계정(Child Account) 생성
  – 방화벽 적용으로 서버의 서비스 포트만 남기고(Allow) 나머지 모든 포트는 차단(All Deny)
  인터넷 접속(공인 네트워크)이 필요 없는 서버는 경우 공인 네트워크(Public Network)에서 분리
보안정책 중에는 최소 권한의 원칙(Least Privileges)’ 직무 분리의 원칙(Separation of Duty)’이 있다. 이러한 원칙은 퍼블릭 클라우드(IaaS)환경에서도 동일하게 적용된다.
최소 권한의 원칙이란 허가 받은 일을 수행하기 위한 최소한의 권한 부여(정보 등급 분류, 접근통제 리스트)’이며, 직무 분리의 원칙이란 업무의 발생부터 승인, 수정, 확인, 완료가 처음부터 한 사람에 의해 처리 못하게 함을 의미한다.
이 원칙을 퍼블릭 클라우드 환경에 적용하면 다음과 같다. A라는 회사에서 퍼블릭 클라우드에 가입을 하면 마스터 계정(Master Account)이 생성된다. A회사 총괄 담당자는 마스터 계정에 종속된 하위 계정(Child Account)을 만들어 빌링 담당자, 개발 담당자, 인프라 담당자, 모니터링 담당자에게 각각 하위 계정(Child Account)을 만들어 주면 직무 분리의 원칙을 준수한 것이다. 각 하위 계정에 맞게 권한을 할당하면 최소 권한의 원칙을 준수한 것이다.
예를 들면, 빌링 담당자의 하위 계정에는 클라우드 컴퓨팅 자원(서버, 네트워크, 스토리지 자원) 배포나 접근 권한을 줄 필요가 없다. 빌링 관련 권한만 최소로 부여(Grant)하면 된다.
<그림7> 역할 기반 접근 제어(RBAC, Role Base Access Control)
<그림7>은 각 사용자의 역할(Role)에 맞게 하위 계정(Child Account)를 생성해 사용자별로 권한을 부여하는 접근 제어(Access Control) 방식을 설명하고 있다.
퍼블릭 클라우드 환경에서 접근 제어 방식은 클라우드 포털의 계정(Account) 레벨뿐만 아니라 클라우드 서버 및 네트워크 레벨에서도 동일하다. 서버 생성 후, 필요한 서비스 포트만 남기고(Allow) 나머지 모든 포트는 닫는(All Deny) 방화벽 정책을 적용한다. <그림8>처럼 웹 서버(Web Server)에서 웹 서비스(Web Service) 80포트(HTTP)를 제외한 모든 포트는 닫는 것이 서버 및 네트워크 레벨의 접근 제어 방식이다.
추가로, 네트워크 레벨의 접근 제어를 살펴보자. <그림9>는 전통적인 전산 센터(IDC) 환경의 네트워크 분리 방안이다. 먼저 외부망(Internet)과 내부망을 분리해 접근을 제어하는 외부 방화벽(External Firewall)이 있다.  외부망(Internet)과 연동이 필요한 서버(웹 서버, 메일 서버, DNS서버)는 외부망과 내부망 중간인 DMZ 구간에 둔다. 외부망(Internet) 접근이 필요 없는 서버(DB서버, Application서버)DMZ 구간과 내부 방화벽(Internal Firewall)보다 더 안쪽인 내부망(Private Zone)에서 운영한다.
자 그럼, 클라우드 환경에서 네트워크 분리를 통한 보안성 강화예제는 어떨까? <그림10>IBM 클라우드의 네트워크 토폴리지(Topology)의 예시다.
외부망(Public Network)과 내부망(Private Network)은 방화벽을 통해 분리된다. 대외 서비스는 DMZ를 구성하면 된다. 물론 외부에 노출이 필요없는 서버(WAS, DB)는 내부 네트워크(Private Zone)로 분리해 전산 센터(IDC)환경과 유사한 방식으로 네트워크 레벨에서 분리할 수 있다.
 .
2-5. 하이브리드 클라우드 환경을 구성해 퍼블릭 클라우드 보안의 한계를 극복
.
  – 국내법 혹은 보안규정으로 클라우드 적용 불가 데이터는 전산 센터(On-Premise IDC)에 보관
  – 빠른 확장(High Scalability)이 필요한 자원은 퍼블릭 클라우드(Off-Premise)에 적용
국내에서 퍼블릭 클라우드 적용이 더딘 이유 중 하나는 규제(Regulation)때문이다금융기관이나 공공기관은 클라우드를 적용하려면 물리적 분리 뿐만 아니라, 해당 서버의 독립된 케이지(Cage) 구성까지 요구하는 경우가 있다.
퍼블릭 클라우드 특성상 이러한 규제를 수용하는 것은 불가능하다. 그때 고려할 수 있는 방법이 바로 하이브리드 클라우드(Hybrid Cloud)”이다.
미국표준기술연구소(NIST)에서는 프라이빗 클라우드(Private Cloud, 사업자가 자신의 조직을 위해 운영하는 클라우드)와 퍼블릭 클라우드(사업자가 불특정 다수를 위해 운영하는 클라우드)를 동시에 사용하는 것을 하이브리드 클라우드라고 일컫는다.
<그림11> 규제(Regulation) 극복을 위한 IBM 의 하이브리드 클라우드 레퍼런스 아키텍처
<그림11>과 같이 고객의 전산 센터(On-Premise)와 퍼블릭 클라우드(Off-Premise)를 연동해 하이브리드 형태로 구성하면, 앞에서 언급한 규제(Regulation)를 극복할 수 있다.
실제로 IBM 클라우드  고객 중에는 국내 유명 전자상거래(E-Commerce)서비스 사업자가 있다. 해당 고객은 자사의 전산 센터(On-Premise)에는 민감한 정보(개인정보, 카드정보 등)를 저장한다. IBM 클라우드 에는 해당 전자상거래 서비스의 전시(Display) 영역 데이터만 저장해 금융정보에 대한 규제(Regulation)를 위배하지 않고 퍼블릭 클라우드 서비스를 적용하고 있는하이브리드 클라우드(Hybrid Cloud)’의 좋은 사례다.
상기 고객은 전자상거래 서비스 특성상 고객 유입이 매우 높은 시즌(졸업, 입학, 이벤트, 연말 등)에는 전시 영역의 컴퓨팅 리소스가 많이 필요하다. 퍼블릭 클라우드의 특징인 높은 확장성(Scalability)과 특정 기간 사용 후 해지(Terminate) 가능한 종량제(Pay-As-You-Go)를 적용했다. 퍼블릭 클라우드의 장점을 매우 잘 활용한 사례다.
지금까지 퍼블릭 클라우드 환경의 보안에서 고려해야 할 사항부터 모범 사례까지 살펴보았다. 기업에서 퍼블릭 클라우드를 적용할 때, 반드시 앞에서 언급했던 내용들을 검토해야 하며, 자사의 서비스(워크로드)를 클라우드에 적용 시 보안 이슈를 얼마나 최소화할 수 있을지, 클라우드 환경에서 보안 정책을 어떻게 수립해야 할지 계획 시 도움이 되기를 바란다.
마지막으로 본문에서 아직 다루지 못한 내용(클라우드 업체의 보안인증, 클라우드 환경에서의 거버넌스 컨트롤, ‘On-Premise 전산 센터‘Off-Premise 퍼블릭 클라우드 환경의 계정 통합 방안, 클라우드 환경의 보안관제 및 침해사고 대응방안 등)클라우드 서비스 제공업체(Cloud Service Provider)’에서 배포하는 문서나 별도 서비스를 통해 더 많은 정보를 얻을 수가 있다.
<참고자료>
1. <클라우드 컴퓨팅의 한계를 극복하는 방법>, 박형준,  IBM DeveloperWorks,  
6. <User 생성 후 Two-Factor 인증 방법>, SoftLayer 서비스 설명 6, IBM Korea, Slideshare,
7. <SoftLayer Storage Overview>, Michael Fork, IBM InterConnect 2015, 
10. <Public DMZ network architecture>, AviD , INFORMATION SECURITY, .
11. <ASSURANCE IN THE CLOUD>, DRS. W.S. CHUNG RE, Compact_,

 

토론 참가

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.