SaaS, PaaS, IaaS : 클라우드 모델에 따른 보안 체크리스트

클라우드 컴퓨팅에서 보안은 어떻게 지켜야 할까? 이 글에서 우리는 클라우드 컴퓨팅에 존재하는 5가지 주요 보안 이슈에 대한 답을 알아보면서, 보안을 철저히 할 수 있는 해결책을 살펴보겠다.

각종 기업과 조직들은 비용을 아끼고 효율성을 높이기 위해 클라우드 컴퓨팅에 눈독을 들이고 있다. 하지만 클라우드 컴퓨팅의 좋은 점들이 많아도, 많은 기관들은 관계된 보안 문제들로 도입을 머뭇거리고 있다. 한 조직의 애플리케이션을 다른 회사들과 함께 같은 기기와 데이터베이스를 공유한다는 점에서, CSO는 이런 리소스를 모두 통제할 수 없다는 사실을 알아야 하며, 결과적으로 클라우드 자체의 보안에 신경 써야 한다. 하지만 결코 클라우드 컴퓨팅이 근본적으로 보안이 약한 것이 아니다. 그저 보안이 된 방법으로 접근하고 관리를 하면 된다.

클라우드 모델이 다 똑같지는 않다

클라우드 컴퓨팅이라는 용어가 광범위하게 사용되고 있지만, 모든 클라우드 모델들이 다 똑같지는 않다는 사실을 알아두자. 따라서 모든 모델에 하나의 방법을 사용하면 안 된다. 클라우드 모델은 크게 SaaS(Software as a Service), PaaS(Platform as a service), IaaS(Integration as a Service)로 나눌 수 있다. 조직에서는 이런 세 가지 모델 사이의 차이점과 유사점을 고려하여 클라우드 보안을 적용해야 한다.

SaaS : 이 모델에서는 애플리케이션 사용을 관리하는 것에 초점을 맞추고 있다. 예를 들어 보안 정책에 따라 판매 직원은 단지 판매 CRM 프로그램에서 특정 정보만 다운받을 수 있도록 할 수 있다. 그리고 특정 지역이나 회사의 근무 시간에만 다운로드를 허용할 수도 있다. 보안 담당자들은 사용자의 애플리케이션 접근을 통제하는 것에 집중해야 한다.

PaaS : 이 모델에서는 데이터 보호가 주된 관심사다. 특히 STaaS(storage as a service)의 경우 중요하다. PaaS와 관련해 중요한 요소는 클라우드가 중단될 가능성에 대비한 계획을 세우는 것이다. 보안 담당자들은 이런 불시의 사고에도 안정적일 수 있도록 데이터 배분을 균형 있게 해야 한다. 제3자의 플랫폼에 저장할 때 암호화를 하는 방법과 지역에 따른 데이터 접근을 통제하는 방법도 관심 가져야 할 주요 요소들이다.

IaaS : 이 모델에서는 가상 머신(virtual machine) 관리에 집중해야 한다. CSO는 부적절한 접근과 잠재적인 지출을 막기 위해, 가상머신을 생성하고 지우는 방법을 조직이 통제할 수 있도록 보안 프레임워크를 잘 설계해야 한다.

아래의 체크리스트들은 CSO(최고보안담당자)들이 고려해야 하는 사항들을 모든 클라우드 모델에 대해 설명하고 있다. 몇 개의 이슈들은 클라우드 보안 연합(Cloud Security Alliance)에서 내놓은 자료를 보충설명하고 있다.

PaaS에 관심 있는 CSO에게

미션 #1. 개인 정보는 클라우드로 보내기 전에 보호하기

이미 현재 많은 법과 정책에 의해서 개인적인 데이터를 외부 시스템으로 보내는 것이 금지되어 있다. 클라우드 서비스 공급자 역시 외부 시스템 중 하나이기에, 조직에서는 이 경우에도 같은 규칙을 적용해야 한다. 조직들이 이를 걱정하고 있음은 분명하다. 클라우드 서비스 공급자들은 만약 개인적인 데이터가 그들의 시스템으로 보내졌다면, 자동적으로 암호화되고, 편집되거나 제거되게 하라고 조언한다. 그러면 다음과 같은 질문이 떠오른다. “어떻게 개인 정보를 클라우드 서비스 공급자에게 보내지기 전에 자동적으로 암호화하고, 제거하거나 삭제할 수 있을까?” 특히 암호화 과정은 CPU에 상당한 부담을 주기에 프로세스를 느리게 만든다는 것은 잘 알려져 있다.

이를 해결하기 위해서는 클라우드 서비스와의 연결을 중개하는 쪽에서 외부에 공개되기를 원치 않는 조직 내의 어떤 정보라도 자동적으로 암호화해야 한다. 예를 들어 주민등록번호, 주소, 또는 의료상의 환자 기록 등 직원과 고객의 개인적이고 민감한 사항들이 해당된다. CSO는 클라우드 서비스 공급자에게 보내지는 메시지에서 개인적인 데이터를 찾아내어 전송 되기 이전에 보호를 제공해야 한다. 또한 이를 암호화해서 오직 그 조직만이 나중에 암호를 풀 수 있도록 해야 한다. 정책에 따라 원래 데이터에서 그런 정보들을 편집하거나 삭제할 수도 있지만, 클라우드 서비스 제공자 측에서 다시 데이터 전송을 요구할 경우 재삽입 될 수 있다.

SaaS에 관심 있는 CSO에게

미션 #2. 조직을 클라우드에 그대로 복제하지 않기

클라우드 서비스를 이용하는 거대한 조직들은 딜레마에 빠졌다. 만약 수천 명의 직원들이 클라우드 서비스를 사용하기 위해서는, 클라우드 플랫폼에다가 마찬가지로 수천 개의 계정을 만들어야 하는 것일까? 기본적인 시스템과 클라우드 사이에 SSO(single sign-on, 싱글 사인온)을 적용하면 이런 걱정은 해결된다.

사용자들이 여러 개의 비밀번호를 사용하면 보안 위험성이 높으며 IT 헬프데스크 리소스를 낭비하게 만든다. 어떠한 큰 조직이라도 클라우드 컴퓨팅을 도입하여 애플리케이션 또는 SaaS를 이용하려고 한다면, 다중 비밀번호에 따른 위험과 비용은 늘 따라다닌다. 예를 들어 회사 내 1만 명의 직원이 있을 경우, 클라우드 서비스를 이용할 때 IT부서에서 1만 명 모두에게 각자 암호를 사용하도록 설정하는 것은 굉장히 비용이 많이 든다. 그리고 사용자들이 SaaS 서비스를 위한 암호를 잊어버려 새로 생성하게 된다면, 관리해야 될 암호가 점점 더 늘어난다.

조직에서 SSO를 적용하면, 사용자들은 각자의 컴퓨터와 모든 클라우드 서비스를 하나의 비밀번호로 접속할 수 있게 된다. 게다가 보안 문제도 방지할 수 있기에 상당한 비용 절감이 이루어진다. SSO로 한번에 로그인 한다면 비밀번호를 잃을 가능성이 줄어들기에, IT 헬프데스크에 필요한 비용이 줄어든다. 또한 비밀번호 권한을 설정하기 편리해진다. 만약 새로운 사용자가 가입하거나 탈퇴할 때, 하나의 비밀번호를 관리하는 것이 쉬울까 다중 비밀번호를 다루는 것이 쉬울까? 요약하자면 SSO를 사용하지 않을 경우, 보안 위험성이 높아지며 IT 헬프데스크에 소모되는 비용도 증가한다. 그리고 사용자들이 회사를 떠난 뒤 남겨진, 악용될 가능성이 열려있는 계정들에 대한 위험도 증가한다.

#######

PaaS에 관심 있는 CSO에게

미션 #3: 감사추적(Audit Trail)을 계속하기

클라우드 서비스는 이용에 따른 비용 청구 방식이기에, 재정 담당 부서에서는 서비스 이용 기록을 계속 감시하길 원할 것이다. 클라우드 서비스 공급자들은 이런 정보를 스스로 제공하고 있지만, 분쟁이 일어날 경우 독자적인 감사추적 결과가 굉장히 중요하다. 감사추적은 조직 내 직원들이 특정 클라우드 서비스를 어떻게 사용하고 있는지, 합법적인지 아닌지 중요한 정보를 제공해준다. 클라우드를 이용하는 조직에서는 클라우드 서비스 비용을 독자적으로 감사추적 하기 위해 CSB(Cloud Service Broker, 클라우드 서비스 브로커) 솔루션을 이용할 수 있다. 자신들만의 클라우드 서비스 이용 기록을 가지게 된다면, CSO는 비용 문제나 직원들의 이용 정보를 확실히 이야기할 수 있다. 어떤 서비스가 사용되었는지 조직에서 계속적으로 체크할 수 있도록 보고서를 제공하는 툴이 CSB에 포함되어야 한다. 물론 조직이 클라우드 사용 기록을 원하는 이유는 여러 가지가 있으며, 논쟁이 되고 있는 통제에 대한 이슈도 포함되어 있다.

IaaS에 관심 있는 CSO에게

미션 #4. 통제: 악의적인 클라우드 사용과 남아도는 클라우드 공급을 막자

조직에서 못된 직원들이 서비스를 다른 용도로 사용하는 것을 막기를 원할 때, 클라우드 컴퓨팅에서 통제가 일어난다. 예를 들어 기업에서는 판매 사원들이 특정한 서비스만 사용할 수 있으며, 다른 것에는 접속할 수 없도록 설정하길 원할 것이다. 또 다른 예로 직원들이 얼마나 많은 가상 머신을 삭제할 수 있는지, 그리고 더 이상 필요가 없어진 가상 머신이 삭제되도록 조직에서 설정하길 원할 것이다. 이를테면 “악의적인” 클라우드 사용도 발견할 수 있어야 하며, 클라우드 서비스를 사용하기 위한 계정을 가진 직원들을 적절한 통제범위 내에 있도록 해야 한다.

클라우드 서비스 공급자가 그 서비스를 모니터링할 수 있는 다양한 방법을 제공하긴 하지만, 조직들은 클라우드 서비스 통제 프레임워크를 만드는 것을 고려해봐야 한다. HR서비스(HR services), ERP, CRM 등 여러 SaaS 공급자들을 이용하고 있을 경우 이런 독자적인 통제가 특히 필요하다. 그러나 이 경우 CSO와 CTO(최고기술경영자)는 클라우드 공급자 각각은 정보에 접근하는 서로 다른 방식을 가지고 있다는 사실을 알아야 한다. 각각은 또한 서로 다른 보안 모델을 지니고 있다.

어떤 것은 REST를, 어떤 것은 SOAP 등을 이용한다. 보안을 위해 인증서를 이용하는 쪽도 있고, 다음 단계에서 알아볼 API 키를 이용하는 쪽도 있다. 단순히 기본적인 HTTP 인증을 사용하기도 한다. 문제는 클라우드 서비스 제공자들은 모두 서로 다르게 제공하려고 한다는 사실이다. 여러 클라우드 공급자들을 이용하기 위해서는, 그들이 각각 다른 수준의 기술을 사용한다는 것을 조직에서 깨달아야 한다.

역시나 클라우드 브로커가 해결책이다. 이를 통해 서로 다른 연결을 차단하고 그들간의 차이점을 완화시킬 수 있다. 이 말은 조직들이 여러 서비스를 함께 사용해도 된다는 뜻이다. STaaS와 같이 상대적으로 상품화된 것이 있을 때 서로 호환시킬 수 있다. 이는 한 클라우드 공급자가 망하거나 신뢰를 할 수 없게 되는 문제도 해결할 수 있는데, 조직에서 그 사용량을 다른 공급자들에게 배분하면 된다는 뜻이다. 사실 조직들이 서로 다른 인터페이스를 이해하거나 조정하려고 너무 기술적인 문제에 매달릴 필요가 없다. 클라우드 사용이 비용 절감을 가져오도록 수준이 높아져야 한다.

SaaS, PaaS, IaaS 어느 것이든 관심 있는 CSO에게

미션 #5. API 키 보호하기

많은 클라우드 서비스는 간단한 REST 웹서비스 인터페이스를 통해 접속한다. 이는 프로그래머들이 사용하는 훨씬 무거운 C++이나 자바(Java) API와 개념적으로 비슷해서 보통 “API”라고 부르는데, 웹페이지에서 또는 모바일 폰에서 통제하기 훨씬 쉽기 때문에 그 유용성이 계속 증가하고 있다. “API 키”는 이런 서비스에 접속할 때 사용된다. 비밀번호 사용법과 비슷한 점이 많다. 이것은 조직이 클라우드 공급자에게 접속할 수 있도록 해준다. 조직이 SaaS를 이용하고 있다면, 주로 API 키에 의해 제공될 것이다. 이런 키의 보안은 정말 중요하다.

구글 앱스(Google Apps)의 예를 살펴보자. 조직이 구글 앱스에 SSO를 사용하고 싶다면, 즉 이메일을 사용하기 위해 한번 더 로그인할 필요가 없도록 하려면, 이런 접속은 API 키를 통해 이루어지게 된다. 만약 이런 키가 유출된다면 공격자들은 조직 내 모든 사람의 이메일에 접속할 수 있게 된다. API 키의 유출은 언제든 일어날 수 있는 사고다. API 키는 파일 시스템에 저장할 경우 암호화 하거나, HSM(Hardware Security Module)에 저장해서 보호해야 한다.

결론: 스스로 구성이냐, 완성품 이용이냐? 

이런 미션을 도전하려고 보안 프레임워크를 설치할 때, CSO는 살 것인지 만들 것인지 선택해야 한다. 열정적인 개발자가 오픈소스 요소들을 모아 클라우드 서비스 브로커와 같은 기능을 맨손으로 제작할 수도 있다. 이런 방법으로 특정 클라우드 서비스 공급자로 라우팅 하는 등 브로커의 런타임 구성요소를 만들 수 있다. 하지만 감사추적과 보고와 같은 솔루션 속 다른 기능들은 없을 것이다. 완제품 클라우드 서비스 브로커는 기본적으로 다양한 기능을 제공할 것이며, 최소한 WS-시큐리티(WS-Security)와 비슷한 정도의 지원을 해야 된다.

클라우드 보안 연합이 보안 가이드 백서에서 밝혔듯이 “클라우드 컴퓨팅은 당신의 현재 환경에 비해 보안 수준이 별반 차이가 없다. 새로운 기술에는 새로운 위험과 새로운 기회가 뒤따른다. 어떤 경우 클라우드 이용이 낡은 애플리케이션과 인프라구조를 변화시켜 일반적인 보안 수준 이상이 되기도 한다. 마찬가지로 어떤 경우 새로운 인프라구조로 민감한 데이터와 애플리케이션을 이동시키는 것이 감당할 수 있는 위험 수위를 넘어설 수 있다.” 필자는 이 글이 여행을 준비하는 독자들에게 충분한 가이드가 되었으면 한다. editor@idg.co.kr