[Special Report] '숫자'로 풀어보는 클라우드
2000년대 후반, 클라우드 컴퓨팅(Cloud Computing)이라는 이상적인 개념이 등장하면서 IT 업계에 엄청난 이슈를 몰고 왔다. 일부에서는 클라우드 컴퓨팅은 IT 혁명이 아니라 Life 혁명이라고 표현하기도 한다. 이 개념이 소개된 후부터 매년 세게적인 리서치 그룹에서 발표하는 연례 IT 동향 보고서의 단골 주제로 소개되고 있으며, 2014년에도 여전히 주목 받고 있는 주제이다. 클라우드 컴퓨팅은 IT 업계 종사자라면 누구나 아는 듯하지만, 제대로 알기는 쉽지 않은 개념이다. 이 글에서는 클라우드 컴퓨팅에 대한 이해를 돕기 위해 클라우드의 개념과 특징을 자세히 소개한다.
호텔과 단독주택, 어디가 더 좋을까?
어리석은 질문일 수 있겠다. 호텔이 좋을지 단독주택이 더 좋을지는 상황에 따라 다를테니까. 짧은 기간 머물러 있다면 호텔이 낫고 장기간 살아야 한다면 단독주택이 더 나을 수도 있을 것이다. 단독주택은 나만 사니 편하고 사생활도 보장되겠지만 전기값 물값 각종 관리비를 자기가 내야 하고 청소나 집 수리도 직접 해야 하고 혹시 강도가 침입할 경우에도 알아서 방어해야 한다.
호텔은 침대시트도 호텔직원이 매일 바꿔 주고 청소도 해 주고 전기든 물이든 비용이 얼마가 나오든 신경 쓰지 않고 편하게 살 수 있다. 단지 숙박료만 지불하면 된다. 호텔도 물론 단점이 있다. 아무리 좋아도 호텔을 ‘나의’ 집이라 부르기는 어렵다. 여러 사람이 거주하는 공간이고 기물들은 내 소유가 아니며 호텔 직원이 청소와 점검을 위해 방에 들어올 것이다.
이쯤 되면 두 곳의 비교는 각자의 취향으로 정리해야 겠지만 특별한 상황 하나만 더 가정해 보자. 만약 당신에게 수십 명의 손님이 갑자기 찾아와 며칠간 머물러 가는 상황이 종종 발생한다면 그때는 어디에 사는 것이 편할 것인가? (극단적인 예를 피하기 위해 단독주택은 5인 가족이 사는 방 4개짜리 40평쯤 되는 집으로 설정한다.) 그 경우의 답은 아무래도 호텔이 되지 않을까?
IT(Information Technology) 시스템에도 호텔같은 서비스가 있다. 비용만 지불하면 서버든 저장장치든 네트워크든 얼마든지 추가로 늘려서 쓸 수 있다. 소프트웨어 개발에 필요한 프레임워크를 빌려 쓸 수도 있고 아예 개발할 필요 없이 고품질의 소프트웨어를 바로 사용할 수도 있다. 사용자는 돈을 내고 서비스를 이용할 뿐 자신이 제공받는 서비스 시스템의 내부가 어떻게 구성된 것인지 어떻게 만들어진 것인지는 알지 못한다. 구름 속에 있는 듯 내막은 잘 알 수 없지만 아무튼 잘 작동하는 고품질의 컴퓨팅 서비스, 이 것을 일컬어 ‘Cloud'라고 한다.
클라우드가 호텔이라면 기업들이 자체적으로 운영하는 컴퓨팅 시스템은 단독주택으로 비유할 수 있다. 단독주택에 사는 가족들이 각자 방을 하나씩 쓰듯이 기업 IT시스템을 이루는 서비스들도 특정한 서버를 독점해서 사용하곤 한다. 웹서비스는 웹서버에서 구동되고 DB서비스는 독자적인 DB서버에서 운영하는 것이 일반적이다. 이런 단독주택형 IT시스템도 평상시에는 큰 문제 없이 돌아간다. 그런데 갑자기 트래픽이라는 손님이 대량으로 밀려오면 어떻게 될까? 쇼핑몰이라면 명절 대목 때 평소의 몇 배가 되는 트래픽이 폭주하고 보안업체라면 국가적인 보안사고가 났을 때 트래픽이 폭주한다. 손님이 많이 찾아왔으니 방을 늘리면 되겠지만 단독주택의 방을 갑자기 늘리는 건 어려운 일이다. 기업 IT시스템도 트래픽이 늘었다고 해서 하루 아침에 서버를 증설하기란 쉽지 않다. 더군다나 트래픽 폭주는 며칠만 감당하면 끝나 버릴 터. 그 며칠의 대응을 위해 평소의 몇 배가 되는 서버를 도입한다면 수지타산이 맞겠는가? 이런 상황에서 호텔과 같은 클라우드 서비스는 탁월한 해결책이 된다. 잠깐 찾아온 손님이 방을 필요한 만큼 빌리고 비용만 지불하면 될테니까.
기업 내 서비스를 목적으로 운영되던 과거의 IT시스템과 달리 현재의 IT환경은 매우 복잡해졌다. 서비스 종류도 다양하고 트래픽의 변화도 예측하기 힘든 경우가 많다. 편의성 측면에서 보면 직접 소유하고 관리하는 시스템이 좋지만, 복잡한 환경과 급격한 변화에 신속하고 유연하게 대응하는 측면에서는 클라우드 시스템이 단연 유리하다. 그런 까닭 때문인지 세계적인 IT 리서치 기관인 가트너(Gatner)의 연례 IT 동향 예측 보고서를 비롯해 각종 IT 동향 보고서에는 클라우드가 빠지지 않는 주제이다. 이제 클라우드를 특징짓는 주요 개념들을 좀더 자세히 알아보자.
클라우드를 이해하는 숫자 5,4,3
클라우드에 대한 표준으로 가장 널리 쓰이는 자료는 미국 기술표준협회 NIST(U.S. National Institue of Standards and Technology)의 NIST Working Definition of Cloud Computing(NIST 800-145)이다. NIST는 클라우드 컴퓨팅을 5개의 필수적인 특징, 4개의 전개 모델, 3개의 서비스 모델로 설명하고 있다.

▲ 클라우드 컴퓨팅에 대한 NIST의 정의 (출처 : 2011. 11. US NIST)
5 : 클라우드의 다섯가지 특징
2) 광대역 네트워크 접속(Broad Network Access)
3) 온디맨드 셀프 서비스(On-demand Self-service)
4) 탄력성(Rapid Elasticity)
5) 측정성(Measured Service)
클라우드의 가장 중요한 특징은 모든 컴퓨터 자원(Resource)이 다수의 사용자(Multi tenancy)와 ‘공유(Pooling)’된다는 것이다. 연산을 담당하는 CPU, 주기억장치인 메모리, 하드디스크와 같은 저장장치 등 모든 자원은 사용자의 필요에 따라 제공된다. 제공된 컴퓨터 리소스 또는 서비스는 네트워크를 통해서 어디서나 접근이 가능하고 사용할 수 있다(Broad Network Access).
어떤 컴퓨터 자원을 늘려서 써야 할 필요가 생기면 다른 사람의 힘을 빌릴 것 없이 직접 처리할 수 있다(On-Demand Self Service). 그렇기 때문에 빠르게 대응할 수 있고 필요가 없어지면 역시 빠르게 사용을 중지할 수 있다. 즉 신속하고 유연한 대응이 가능하다(Rapid Elasticity).
공동의 자원을 빠르고 편리하게 언제든지 어디서든 사용하기 위해서는 물론 대가가 있다. 사용하는 만큼 돈을 내야 한다. 따라서 클라우드 서비스는 사용량에 대한 측정을 기본으로 한다(Measured Service).
4 : 클라우드 전개(Deployment) 모델
1) 공개형 클라우드(Public Cloud)
2) 폐쇄형 클라우드(Private Cloud)
3) 커뮤니티 클라우드(Community Cloud)
4) 하이브리드 클라우드(Hybrid Cloud)
클라우드 서비스의 장점은 자원을 여러 사용자가 유연성 있게 할당받아 사용하는 것이지만 한편으론 그 점이 클라우드 서비스를 꺼리게 만드는 가장 큰 이유이기도 하다. 클라우드를 관리하는 사람도 우리 회사 직원이 아니고 서비스를 함께 이용하는 사람도 다른 회사 사람들이라면 그 시스템을 정말 믿을 수 있을 것인가? 혹시라도 클라우드를 함께 사용하는 사람들 중에 해커나 범죄집단이 없으리라고 어떻게 장담할 수 있는가? 그래서 클라우드 서비스의 기능적인 장점은 그대로 가져가되 다른 조직의 접근이라는 보안 문제를 배제하고자 하는 전개 방식이 폐쇄형 (Private) 클라우드이다. 이와 상대적으로, 돈을 받고 제공하는 공용자원이라는 일반적인 개념으로 운영되는 클라우드를 공개형(Public) 클라우드라고 부른다. 클라우드 시스템은 일단 구축하면 여러 가지 요구에 대응하는 유연성은 뛰어나지만 초기 구축 과정에서는 빅뱅 수준의 대규모 작업이 필요하다. 또 클라우드 시스템의 장점이 발휘되려면 적정 수준의 시스템 여유가 확보되어야 하는데 그 또한 단독으로 부담하기엔 만만치 않다. 그래서 비슷한 사업 성격을 띄고 있거나 특정한 틀로 묶일 수 있는 (계열사 관계와 같이) 조직이 함께 모여 운영하는 클라우드 전개 방식도 있다. 이를 '커뮤니티(Community)클라우드'라고 부른다. 마지막으로 기업의 필요에 따라 공개형, 폐쇄형, 커뮤니티 클라우드를 혼용해서 운영하는 경우를 '하이브리드(Hybrid) 클라우드'라고 한다.
3 : 클라우드의 서비스 제공(Delivery) 모델
2) Platform as a Service (PaaS)
3) Infrastructure as a Service (IaaS)
클라우드 서비스에도 계층이 있다. 가장 단순한 서비스는 핵심적인 인프라만 빌려 쓰는 서비스이다(Infrastructure as a Service). 서버와 네트워크 장비, 저장 장치, 이들을 운영하는 상면공간 등 하드웨어와 밀접한 자원들이 이런 서비스 대상에 해당된다. 소프트웨어 관련 요소는 이들 하드웨어 인프라를 추상화시키고 사용자 관점에서 편리하게 사용할 수 있도록 제공하는 API(Application Programming Interface) 정도 뿐이다. 이 모델은 건물로 치자면 전력과 수도 등 기본적인 공조 설비는 갖춰져 있지만 콘크리트 벽 그대로 내장 공사도 하지 않은 건물을 그대로 빌려 쓰는 것과 같다. 내장 공사를 하고 가구를 들여 놓고 어떤 용도로 사용할지는 임대한 사용자가 알아서 해야 한다. IT 관점에는 인터넷에 연결된, 아무 것도 설치되지 않은 서버를 그대로 두었다고 생각하면 될 것이다. 그 서버에 설치할 소프트웨어와 운영할 서비스에 대한 결정은 전적으로 사용자 책임이고 인프라 운영 이외의 모든 문제에 대해서도 사용자가 해결해야 한다. IaaS로 잘 알려진 예는 아마존의 EC2(Elastic Compute Cloud)나 S3(Simple Storage Service)가 있다.
IaaS가 가장 아랫단의 기본적인 서비스라면 가장 상위 단계인 SaaS(Software as a Service)는 사용자가 이용하는 애플리케이션까지 클라우드에서 제공해 주는 것이다. 흔한 예로는 구글의 지메일이나 아마존의 AWS(Amazon Web Service)를 생각해 볼 수 있다. 이런 서비스는 사용자가 직접 개발하거나 유지 보수할 필요 없이 만들어진 그대로 사용만 하면 된다. 당연히 관리에 대한 부담이나 보안을 비롯한 각종 문제에 대한 책임도 매우 적다. IaaS나 PaaS에 비해 사용자가 관여할 부분이 적은 만큼 보안 문제를 비롯한 각종 관리 부담 또한 적은 것이 장점이다.
IaaS와 SaaS의 중간에 낀 PaaS(Platform as a Service)는 하드웨어 인프라 외에 사용자가 애플리케이션을 개발하는데 필요한 솔루션까지 함께 제공해 주는 서비스를 뜻한다. 장난감으로 비유하자면 IaaS가 뛰어놀 수 있는 운동장만 제공하는 것이고, SaaS가 비행기나 자동차, 인형과 같이 완성품 장난감을 주는 것이라면 PaaS는 레고 블럭처럼 무언가 직접 만들어 볼 수 있는 장난감을 주는 셈이다. PaaS의 대표적인 예로 구글 App Engine을 보면 사용자는 DB API(Application Program Interface)와 Python/Java/php 등을 기반으로 한 개발 프레임워크를 제공받아 자기만의 애플리케이션을 만들 수 있고 완성된 프로그램은 구글 클라우드에서 운영할 수 있다. 영업솔루션으로 유명한 세일즈포스닷컴 역시 PaaS의 예로 자주 언급되는데 php, java, .net 기반의 개발도구는 물론 모바일 서비스를 구축하기 위한 SDK를 포함하여 세일즈닷컴에 연동되는 애플리케이션을 사용자가 개발할 수 있도록 지원하고 있다.
클라우드 도입을 위한 보안 요소 14가지
(참고: https://cloudsecurityalliance.org/research/ccm/)
도메인 1 : 클라우드 컴퓨팅 아키텍처 프레임워크
이 부분은 본 기고문 ‘2.클라우드를 이해하는 숫자 5,4,3’의 내용과 같다.
클라우드 서비스의 전개 모델과 제공 모델에 따라 사용자가 책임져야 할 보안영역이 다르고 보안을 적용하는 과정도 차이가 생기기 때문에 클라우드 컴퓨팅의 기본 구조와 차이점을 알려주고 있다.
도메인 2 : 거버넌스 및 전사 위험 관리
클라우드는 기본적으로 제공자와 사용자가 서로 다른 조직이라는 걸 전제하므로 보안에 관한 양자 간 합의사항이나 주요 위험에 대한 분석과 대응절차가 심도있게 논의되어야 한다. 거버넌스는 제공자측이나 사용자측 내부에서도 중요하고 제공자, 사용자 혹은 제3자와의 관계까지 고려해야만 한다.
도메인 3 : 법적 이슈 : 계약 및 전자적 증거 수집
클라우드 서비스는 적용 과정이나 운영 상 문제가 발생할 경우 데이터 시스템 운영주체와 사용자 간에 법적 이슈가 심각할 수 있다. 국내의 경우 인터넷서비스 업체가 고객 데이터를 동의 없이 외국의 클라우드 서비스 업체로 이관할 경우 법을 위반하게 된다. 데이터 유실 장애가 생길 경우 전자적 증거를 보관해야 하는 법 규정도 큰 이슈가 될 수 있다. 이 때문에 국내외의 각종 규제 사항을 사전에 검토하여 제공자와 사용자 간 법적 책임범위를 SLA에 반영할 필요가 있다.
도메인 4 : 컴플라이언스 및 감사 관리
도메인4는 사실상 도메인2(거버너스)와 도메인3(법적 이슈)를 묶는 역할을 한다. 법적 기준을 파악하는 일이 도메인3이라면 그에 대한 대응체계를 갖추는 것이 도메인2 (거버넌스)이고 실제로 행위가 이루어지는 과정이 컴플라이언스이기 때문이다.
제공자에게 요구되는 컴플라이언스를 모니터링하기 위해서는 적절한 감사 프로세스가 사전에 수립되어야 할 것이다.
도메인 5 : 정보 관리 및 데이터 보안
정보보안의 주요 목표는 시스템과 어플리케이션의 기초 데이터를 보호하는 것이다. 전통적인 IT인프라 보안과 마찬가지로 클라우드 보안 역시 정책과 통제 절차, 관련된 보안솔루션에 대해 기준을 수립하는 일이 핵심적이다. 이 도메인에서는 IaaS부터 SaaS에 이르는 각 서비스 모델의 구성요소와 그에 따른 보안 사항을 설명하고 있다. 특히 데이터 암호화와 통신 보안은 기존에도 중요한 문제였지만 네트워크에 전적으로 의존하는 클라우드 서비스에서는 더욱 심각하게 주의를 기울여야 함을 알 수 있다.
도메인 6 : 상호운용성 및 이식성
클라우드 서비스는 하드웨어로 이루어진 물리적 계층과 독립적으로 다양한 서비스가 운영된다. 이기종 환경에서 운영되던 고객의 서비스나 데이터가 이관될 가능성이 있고 반대로 클라우드 서비스가 종료되어 다른 업체로 기존의 데이터를 옮겨야 할 수도 있다. 이런 경우 클라우드 서비스 간 혹은 고객과 클라우드 서비스 간 데이터가 원활하게 운용되고 이식 가능한지 여부가 중요한 고려 사항이 된다.
도메인 7 : 전통적인 보안, 사업연속성, 재해복구
이 도메인은 전통적인 IT인프라 보안과 크게 다르지 않다. 클라우드 역시 물리적 환경을 갖추고 있고 재해에 대한 위험을 대응해야 하기 때문이다. 특기할 점은 클라우드 서비스의 경우 인적 자원을 물리 보안 관점에서 다룬다는 점인데 사용자가 물리적으로 클라우드 시스템에 접근할 기회가 거의 없기 때문에 제공자의 인적 자원을 통제하는 일이 중요한 문제가 된다는 것을 이해할 수 있다.
도메인 8 : 데이터센터 운영
IT인프라를 운영하기 위한 목적으로 특별히 설계된 건물을 데이터센터라고 한다. 이 도메인은 도메인5부터 도메인7의 보안 영역에서 다루는 요소 중 가장 기본이 되는 물리적 보안요소로서 건물과 시설물의 운영 문제를 다루고 있다.
도메인 9 : 사고 대응
사고대응은 정보보안의 관리에서 기본요소 중 하나이다. 대형 클라우드 서비스 업체들은 일반기업들이 직접 운영하는 것보다는 훨씬 더 높은 수준으로 보안대책을 갖추고 있긴 하지만 그렇다고 보안사고가 발생하지 않는 것은 아니다. 아마존을 비롯해 구글과 마이크로소프트 클라우드 서비스도 심각한 시스템장애와 해킹사고를 겪었다.
(참고:http://www.ciokorea.com/news/9447).
클라우드 제공업체 문제가 아니라 한 입주 고객에게 발생한 사고일지라도 다수의 사용자가 사용하는 클라우드 특성 상 사고 발생 시 대응 과정은 차이가 클 수 있다(포렌직 과정에서 타 사용자의 데이터 침해 가능성에 대한 문제 등).
도메인 10 : 어플리케이션 보안
클라우드는 서비스 제공 모델 별로 어플리케이션의 운용 책임이나 구현 수준이 다를 수 있기 때문에 CSA에서는 ‘소프트웨어 개발주기 보안’-SDLC(Secure Development Life Cycle)을 강조하고 있다. 일단 운영 과정에서 문제가 발생하면 파급이 크기 때문에 개발 과정의 코드리뷰와 보안검사를 비롯한 사전 테스트를 철저하게 거칠 것을 요구한다.
도메인 11 : 암호화 및 키 관리
도메인11은 도메인5에서 잠깐 언급했던 암호화 이슈를 심도 있게 다룬다. 적합한 암호화 사용법과 확장성 있는 키 관리 방안, 자원에 대한 접근 및 데이터를 보호하고 신원을 확인할 때 암호화 및 키관리가 필요한 이유 등을 상세하게 설명하고 있다.
도메인 12 : 신원 확인, 권한 부여, 접근 통제
클라우드와 관련해서 기억할 만한 개념어 중 하나는 Multi-Tenancy와 Provisioning이란 용어이다. Multi-Tenancy는 번역하자면 ‘다중고객’이라고 할 수 있는데 클라우드 서비스를 함께 이용하는 다수의 이용자들을 일컫는 말이다. 다수의 사용자란 특별할 게 없는 말같지만 클라우드는 하나의 시스템이라 할지라도 각각의 사용자는 자신만의 독립된 환경에서 사용한다고 느끼게끔 만들어야 하기 때문에 가상화와 맞물려 다중운영환경을 제공하는 고도화된 기술을 뜻하기도 한다. Provisioning은 준비된 자원(컴퓨팅 자원 및 사용자 계정 등)을 제공하는 것이다. 도메인12는 이러한 멀티테넌시 환경에서 핵심적인 신원 확인과 권한 관리, 접근 통제 등 보안이슈를 다루고 있다.
도메인 13 : 가상화
클라우드의 강점은 IT 인프라의 물리적 구성을 사용자가 알 필요 없이 다양한 소프트웨어 개발/운영이 가능하다는 점이다. 이런 장점이 가능하게 된 기술적 배경에는 ‘가상화’가 있다. 다수의 사용자가 각각 다른 어플리케이션과 운영소프트웨어를 구동하기 위해서 클라우드 서비스는 하이퍼바이저(hypervisor)라는 논리적 플랫폼을 가장 하위 레이어에 운영하게 된다(호텔로 치자면 건물의 기초라고 이해하면 되겠다). 그런데 만약 해커가 개별적인 사용자의 시스템이 아니라 공통 기반인 하이퍼바이저 자체를 공격해서 점유하면(호텔 기초를 무너뜨린다면?) 어떻게 될 것인가?
도메인 14 : 서비스로서의 보안 (Security as a Service)
CSA 가이드 버전 3.0에서 새로 추가된 도메인이 용어조차 생소한 SecaaS (Security as a Service) 이다. 개념은 단순하다. 소프트웨어나 인프라를 서비스로 제공하듯이 보안 역시 클라우드 서비스의 하나로서 제공할 수 있지 않느냐는 것이다. 한 예로 기업들이 기본적인 보안 솔루션으로 도입하는 백신을 보자. 클라우드의 멀티테넌시 환경에서 입주 업체마다 각자의 환경에 별개의 백신 프로그램을 운영하는 것보다는 하이퍼바이저 단에서 백신 기능을 운용하는 편이 전체 운영 효율면에서 낫지 않겠는가? 통합인증(SSO)나 취약성 점검, 계정 관리 등 보안 기능 역시 클라우드 서비스로 제공 못할 까닭이 없다. 향후 많은 기업들이 IT 서비스를 클라우드로 옮겨 간다고 예상한다면 운영에 필수적인 보안 역시 중요한 클라우드 서비스의 하나로 자리 잡을 것으로 보인다.
짧지 않은 분량으로 클라우드의 개념과 특징, 보안 도메인까지 살펴 보았다. ‘해 아래 새로운 것이 없다’는 성경 문구처럼 클라우드 역시 완전히 낯선 개념으로 불쑥 나타났다기 보다는 과거의 여러 기술들이 축적되어 클라우드라는 특징을 이루며 활성화 되고 있다고 보아야 할 것이다. 아무쪼록 독자분들이 클라우드 기술에 관심을 큰 갖고 그 장점을 적극 활용할 수 있기를 기대하며 안랩 또한 통합보안기업으로서 클라우드를 활용하여 더욱 편리한 보안서비스를 제공할 수 있도록 노력할 것을 약속드린다. @
- AhnLab관리컨설팅팀 이장우 이사