2013.03.22

글로벌 칼럼 | 간과해선 안 되는 5가지 클라우드 위험

Roger A. Grimes | InfoWorld
미국 전 국방장관 도널드 럼스펠드를 좋아하든 싫어하든, 그는 '모른다는 것을 모르는 것(Unknown unknown)'이라는 유명한 발언을 한 적이 있다. 
 
럼스펠드는 "알고 있는 것을 아는 것이 있다. 우리가 알고 있다는 것을 알고 있는 것들이 있다. 또 모른다는 것을 알고 있기도 하다. 즉 우리가 모르는 무언가가 있다는 것을 알고 있다는 말이다. 하지만 모른다는 것을 모르는 것도 있다. 우리가 알고 있지 못한 것을 알고 있지 못한 것이다"라고 한 발언은 조롱을 당했다. 
 
그러나 이는 정치가답지 않게 진실을 말한 것이며, 필자는 컴퓨터 보안 분야에 종사하는 사람들이라면 럼스펠드 발언의 의미를 금새 알아차렸을 것이라고 생각한다. 
 
보안에 대해 우리는 지속적으로 세 가지 종류의 위험에 직면하게 된다. '알고 있는 것을 아는 것(Known knowns)', '모르는 것을 아는 것(Known unknowns)', 그리고  '모르는 것을 모르는 것(Unknown unknowns)'이다.
 
그리고 퍼블릭 클라우드 컴퓨팅을 도입할 때 직면하는 가장 큰 장애물 가운데 하나는 모르는 것과 아는 것 등에서 비롯되는 부수적인 위험을 계산하는 것이다. 
 
필자는 지난 몇 년간 퍼블릭 클라우드 제공자이자 사용자로 이와 같은 문제들을 심사숙고한 바 있다. 이에 기업이 퍼블릭 클라우드 서비스 고객으로 직면하게 되는 다섯 가지 위험을 소개한다.
 
클라우드 위험 1: 공유해서 접속 및 사용
퍼블릭 클라우드의 핵심 특징 가운데 하나는 멀티테넌시(Multitenancy, 다중소유)다. 통상 서로 관계가 없는 여러 고객들이 동일한 컴퓨팅 자원, 즉 CPU와 스토리지, 메모리, 네임스페이스(Namespace), 실제 건물 공간을 공유한다는 의미다.
 
대부분에게 있어 멀티테넌시는 '모르는 것을 아는 것(Known unknown)'이다. 특정 기업의 비밀 데이터가 다른 입주자(Tenant)에게 새어나갈 위험이 있을 뿐 아니라, 자원 공유에 따른 부수적인 위험도 있다. 
 
멀티테넌시가 갖는 취약점에는 아주 걱정스러운 부분이 있다. 하나의 특정 취약점으로 인해 다른 입주자나 해커가 모든 사람들의 데이터를 볼 수 있고, 다른 고객의 ID를 도용할 위험이 있기 때문이다.
 
몇몇 취약점은 클라우드가 갖는 공유 속성에서 비롯된다. 예를 들어, 연구원들이 새로운 스토리지 공간으로 옮겨간 다른 입주자의 데이터를 복원할 수 있었던 사례가 있었다. 그리고 다른 입주자의 메모리와 IP 주소 공간을 엿볼 수 있었다. 일부는 할당된 IP 및 MAC 주소를 예측하는 것만으로 다른 입주자의 컴퓨팅 자원을 가져올 수 있었다.
 
모두에게 멀티테넌시 보안 문제는 중요해지고 있는 실정이다. 멀티테넌시에서 비롯되는 취약점에 대한 공격이 시작되고 있는 추세기 때문이다. 
 
서로 관련이 없는 수백 또는 수천의 웹사이트가 있는 웹 서버에 단일 웹사이트가 자리를 잡고 있는 사례를 좋은 전조로 제시할 수 있다. 기존 사례는 좋은 참고가 된다. 이 점에서 멀티테넌시는 장기적으로 큰 문제가 될 수 있다.
 
클라우드 위험 2: 가상화 취약점 공격
대형 클라우드 공급업체들은 모두 가상화를 많이 사용한다. 이런 가상화는 물리적 장치가 갖는 위험에 더해 가상화만의 위험을 갖는다. 
 
가상 서버 호스트와 게스트를 표적으로 한 취약점 공격(Exploit)을 예로 들 수 있다. '서버 호스트 공격', '게스트-게스트 공격', '호스트-게스트 공격', '게스트-호스트 공격' 등이 이런 가상화 취약성을 대표하는 네 가지 유형의 위험이다. 이들은 모두 '모르는 것'들이고, 대부분은 위험을 모델링할 때 이를 계산하지 않는다.
 
경영진에게 이런 가상화 위험 문제를 이야기하면 대부분 심드렁한 표정을 짓는다. 많은 이들이 위험이 과장됐다거나, 그런 취약점 공격은 들어보지도 못한 것으로 취급한다. 필자는 이렇게 말하는 사람들에게 이용하고 있는 가상화 소프트웨어 개발업체의 패치 항목을 점검해보라고 충고한다. 그리 바람직해 보이지는 않을 것이다.
 
더 나아가, 자사의 개발업체가 어떤 가상화 제품이나 관리 툴을 실행시키고 있는지 모르는 클라우드 고객들이 많다. 개발업체에게 다음 질문을 해 위험을 파악해보기 바란다. 
 
- 사용하고 있는 가상화 소프트웨어는? 
- 현재 버전은? 
- 가상화 포스트를 패칭하는 사람은? 
- 얼마나 자주 패칭을 하는가? 
- 각각의 가상화 호스트 및 게스트에 로그인할 수 있는 사람은?
 
클라우드 위험 3: 인증, 승인, 접속 관리
클라우드 개발업체가 사용하고 있는 인증(Authentication), 승인(Authorization), 접속 제어(Access Control) 메카니즘은 아주 중요하다. 그러나 이의 상당수는 프로세스에 따라 달라진다. 
 
- 얼마나 자주 계정을 점검해 사용하지 않는 것을 제거하는가? 
- 시스템과 데이터에 접속할 수 있는 특권 계정의 수는? 
- 특권 계정 사용자가 요구하는 인증 형태는? 
- 개발업체 또는 간접적으로는 다른 입주자와 공통 네임스페이스를 공유하고 있는가?
 
SSO(Single Sign On) 체험 구현을 위해 네임스페이스와 인증을 공유하면 생산성에 큰 도움이 되지만, 동시에 위험도 크게 증가한다. 데이터 보호 또한 큰 걱정거리가 된다. 데이터 암호화를 사용, 집행하고 있다고 가정하자. 그렇다면 다음과 같은 질문을 해보자. 
 
- 입주자들이 프라이빗 키를 공유하는가? 
- 자신의 데이터를 확인할 수 있는 클라우드 개발업체 직원과 직원의 수는? 
- 데이터가 실제 저장되어 있는 장소는? 
- 더 이상 필요없을 때 처리 방법은? 
 
필자는 얼마나 많은 클라우드 개발업체들이 이와 같은 질문에 자세히 대답을 해줄지 모르겠다. 그러나 '아는 것'과 '모르는 것'을 찾기 원한다면 이런 질문을 해야만 한다.
 
클라우드 위험 4: 가용성(Availability)
퍼블릭 클라우드 공급업체의 고객, 퍼블릭 클라우드 사용자라면 이중화(Redundancy)와 폴트 톨로런스(고장 허용 한계)는 자신의 관리 아래 있지 않다. 
 
그리고 대부분의 공급업체는 이에 대한 서비스 내역과 방법을 공개하지 않는다. 우리가 완벽하게 모르는 것이다. 클라우드 서비스들은 저마다 뛰어난 폴트 톨로런스와 유효성을 제공한다고 자랑한다. 그러나 몇 개월이 지나고 큰 문제를 확인할지 모른다. 몇 시간은 물론 심지어는 며칠간 서비스가 중단되거나 방해받을 수 있다.
 
더 큰 문제도 있다. 실제 고객들이 데이터를 잃어버린 몇몇 사례가 있는 것이다. 클라우드 공급업체 내부의 문제나 해킹 공격 때문에 발생한 사건이다. 
 
클라우드 개발업체들은 자신들이 3중으로 데이터를 백업해 보호한다고 주장하고 있다. 그러나 개발업체들이 데이터 백업을 보증하는 경우에도 영구적으로 데이터를 잃어버리곤 한다. 따라서 클라우드에 공유하고 있는 데이터를 항상 백업하는 것이 좋다. 최소한 데이터를 영구적으로 잃어버렸을 때의 피해 보상 금액을 법적으로 정해놔야 한다.
 
클라우드 위험 5: 소유권
많은 클라우드 고객들을 당혹하게 만드는 위험이다. 그러나 고객들이 데이터의 유일한 소유주가 아닌 경우가 많다. 대형 퍼블릭 클라우드 업체들을 포함한 많은 업체들이 계약서 조항으로 '보관하고 있는 데이터가 고객 소유가 아닌 공급자 소유'라고 규정하고 있다.
 
클라우드 개발업체들은 데이터를 소유하고 싶어한다. 무언가 잘못됐을 때 법적으로 더 보호를 받을 수 있기 때문이다. 또 고객 데이터를 검색, 발굴해 추가 수익 창출을 위한 기회로 삼는다. 
 
필자는 클라우드 개발업체들이 파산하고 나서 고객의 개인 데이터를 자사의 자산으로 매각한 몇몇 사례에 대한 글을 읽은 적이 있다. 놀랄 일이다. 따라서 이 부분을 확실히 확인해야 한다. 
 
- 누가 데이터를 소유하고 있는가? 
- 클라우드 제공업체가 데이터를 이용해 어떤 일을 할 수 있는가?
 
클라우드 가시성
알려진 클라우드 컴퓨팅 위험이라도, 이를 정확하게 계산하기란 아주 어렵다. 보안이나 가용성 하락 확률을 판단하기에는 사례도, 증거도 부족하다. 특히 특정 개발업체의 경우 이런 위험이 고객에게 상당한 피해를 초래할 가능성도 있다. 우리가 할 수 있는 최선은 럼스펠드의 말을 생각해보는 것이다. 
 
최소한 '모르는 것을 알기 위해' 관리해야 한다.
 
그러나 가장 먼저 할 일은 '모르는 것을 모르는 것'을 최소화하기 위해 노력을 기울여야 한다. 
우선 가능한 투명성을 확보해야 한다. 최소한 가장 최근의 성공적인 관련 감사 보고서 사본을 입수한다. 개발업체에게 기존 입주자의 데이터 손실 및 침해 사례를 요구한다. 또한 이를 보고하는 것과 관련된 정책을 파악한다. 
 
가능한 클라우드 개발업체의 책임 한계를 넓혀야 한다. 할 수 있는 한 가장 어려운 질문과 요청을 해 퍼블릭 클라우드 컴퓨팅이 갖는 위험을 완전히 이해해 나가야 한다.
 
필자가 퍼블릭 클라우드 컴퓨팅에 부정적인 견해를 갖고 있다고 생각할지 모르겠다. 그러나 실제로는 대단한 팬이다. 필자는 대부분의 퍼블릭 클라우드 개발업체들이 고객보다 더 잘 데이터를 보호할 수 있다고 믿는다. 그러나 우리는 클라우드 개발업체의 위험 경감 정책과 방법을 파악해 스스로의 방법과 비교해봐야 한다. editor@itworld.co.kr



2013.03.22

글로벌 칼럼 | 간과해선 안 되는 5가지 클라우드 위험

Roger A. Grimes | InfoWorld
미국 전 국방장관 도널드 럼스펠드를 좋아하든 싫어하든, 그는 '모른다는 것을 모르는 것(Unknown unknown)'이라는 유명한 발언을 한 적이 있다. 
 
럼스펠드는 "알고 있는 것을 아는 것이 있다. 우리가 알고 있다는 것을 알고 있는 것들이 있다. 또 모른다는 것을 알고 있기도 하다. 즉 우리가 모르는 무언가가 있다는 것을 알고 있다는 말이다. 하지만 모른다는 것을 모르는 것도 있다. 우리가 알고 있지 못한 것을 알고 있지 못한 것이다"라고 한 발언은 조롱을 당했다. 
 
그러나 이는 정치가답지 않게 진실을 말한 것이며, 필자는 컴퓨터 보안 분야에 종사하는 사람들이라면 럼스펠드 발언의 의미를 금새 알아차렸을 것이라고 생각한다. 
 
보안에 대해 우리는 지속적으로 세 가지 종류의 위험에 직면하게 된다. '알고 있는 것을 아는 것(Known knowns)', '모르는 것을 아는 것(Known unknowns)', 그리고  '모르는 것을 모르는 것(Unknown unknowns)'이다.
 
그리고 퍼블릭 클라우드 컴퓨팅을 도입할 때 직면하는 가장 큰 장애물 가운데 하나는 모르는 것과 아는 것 등에서 비롯되는 부수적인 위험을 계산하는 것이다. 
 
필자는 지난 몇 년간 퍼블릭 클라우드 제공자이자 사용자로 이와 같은 문제들을 심사숙고한 바 있다. 이에 기업이 퍼블릭 클라우드 서비스 고객으로 직면하게 되는 다섯 가지 위험을 소개한다.
 
클라우드 위험 1: 공유해서 접속 및 사용
퍼블릭 클라우드의 핵심 특징 가운데 하나는 멀티테넌시(Multitenancy, 다중소유)다. 통상 서로 관계가 없는 여러 고객들이 동일한 컴퓨팅 자원, 즉 CPU와 스토리지, 메모리, 네임스페이스(Namespace), 실제 건물 공간을 공유한다는 의미다.
 
대부분에게 있어 멀티테넌시는 '모르는 것을 아는 것(Known unknown)'이다. 특정 기업의 비밀 데이터가 다른 입주자(Tenant)에게 새어나갈 위험이 있을 뿐 아니라, 자원 공유에 따른 부수적인 위험도 있다. 
 
멀티테넌시가 갖는 취약점에는 아주 걱정스러운 부분이 있다. 하나의 특정 취약점으로 인해 다른 입주자나 해커가 모든 사람들의 데이터를 볼 수 있고, 다른 고객의 ID를 도용할 위험이 있기 때문이다.
 
몇몇 취약점은 클라우드가 갖는 공유 속성에서 비롯된다. 예를 들어, 연구원들이 새로운 스토리지 공간으로 옮겨간 다른 입주자의 데이터를 복원할 수 있었던 사례가 있었다. 그리고 다른 입주자의 메모리와 IP 주소 공간을 엿볼 수 있었다. 일부는 할당된 IP 및 MAC 주소를 예측하는 것만으로 다른 입주자의 컴퓨팅 자원을 가져올 수 있었다.
 
모두에게 멀티테넌시 보안 문제는 중요해지고 있는 실정이다. 멀티테넌시에서 비롯되는 취약점에 대한 공격이 시작되고 있는 추세기 때문이다. 
 
서로 관련이 없는 수백 또는 수천의 웹사이트가 있는 웹 서버에 단일 웹사이트가 자리를 잡고 있는 사례를 좋은 전조로 제시할 수 있다. 기존 사례는 좋은 참고가 된다. 이 점에서 멀티테넌시는 장기적으로 큰 문제가 될 수 있다.
 
클라우드 위험 2: 가상화 취약점 공격
대형 클라우드 공급업체들은 모두 가상화를 많이 사용한다. 이런 가상화는 물리적 장치가 갖는 위험에 더해 가상화만의 위험을 갖는다. 
 
가상 서버 호스트와 게스트를 표적으로 한 취약점 공격(Exploit)을 예로 들 수 있다. '서버 호스트 공격', '게스트-게스트 공격', '호스트-게스트 공격', '게스트-호스트 공격' 등이 이런 가상화 취약성을 대표하는 네 가지 유형의 위험이다. 이들은 모두 '모르는 것'들이고, 대부분은 위험을 모델링할 때 이를 계산하지 않는다.
 
경영진에게 이런 가상화 위험 문제를 이야기하면 대부분 심드렁한 표정을 짓는다. 많은 이들이 위험이 과장됐다거나, 그런 취약점 공격은 들어보지도 못한 것으로 취급한다. 필자는 이렇게 말하는 사람들에게 이용하고 있는 가상화 소프트웨어 개발업체의 패치 항목을 점검해보라고 충고한다. 그리 바람직해 보이지는 않을 것이다.
 
더 나아가, 자사의 개발업체가 어떤 가상화 제품이나 관리 툴을 실행시키고 있는지 모르는 클라우드 고객들이 많다. 개발업체에게 다음 질문을 해 위험을 파악해보기 바란다. 
 
- 사용하고 있는 가상화 소프트웨어는? 
- 현재 버전은? 
- 가상화 포스트를 패칭하는 사람은? 
- 얼마나 자주 패칭을 하는가? 
- 각각의 가상화 호스트 및 게스트에 로그인할 수 있는 사람은?
 
클라우드 위험 3: 인증, 승인, 접속 관리
클라우드 개발업체가 사용하고 있는 인증(Authentication), 승인(Authorization), 접속 제어(Access Control) 메카니즘은 아주 중요하다. 그러나 이의 상당수는 프로세스에 따라 달라진다. 
 
- 얼마나 자주 계정을 점검해 사용하지 않는 것을 제거하는가? 
- 시스템과 데이터에 접속할 수 있는 특권 계정의 수는? 
- 특권 계정 사용자가 요구하는 인증 형태는? 
- 개발업체 또는 간접적으로는 다른 입주자와 공통 네임스페이스를 공유하고 있는가?
 
SSO(Single Sign On) 체험 구현을 위해 네임스페이스와 인증을 공유하면 생산성에 큰 도움이 되지만, 동시에 위험도 크게 증가한다. 데이터 보호 또한 큰 걱정거리가 된다. 데이터 암호화를 사용, 집행하고 있다고 가정하자. 그렇다면 다음과 같은 질문을 해보자. 
 
- 입주자들이 프라이빗 키를 공유하는가? 
- 자신의 데이터를 확인할 수 있는 클라우드 개발업체 직원과 직원의 수는? 
- 데이터가 실제 저장되어 있는 장소는? 
- 더 이상 필요없을 때 처리 방법은? 
 
필자는 얼마나 많은 클라우드 개발업체들이 이와 같은 질문에 자세히 대답을 해줄지 모르겠다. 그러나 '아는 것'과 '모르는 것'을 찾기 원한다면 이런 질문을 해야만 한다.
 
클라우드 위험 4: 가용성(Availability)
퍼블릭 클라우드 공급업체의 고객, 퍼블릭 클라우드 사용자라면 이중화(Redundancy)와 폴트 톨로런스(고장 허용 한계)는 자신의 관리 아래 있지 않다. 
 
그리고 대부분의 공급업체는 이에 대한 서비스 내역과 방법을 공개하지 않는다. 우리가 완벽하게 모르는 것이다. 클라우드 서비스들은 저마다 뛰어난 폴트 톨로런스와 유효성을 제공한다고 자랑한다. 그러나 몇 개월이 지나고 큰 문제를 확인할지 모른다. 몇 시간은 물론 심지어는 며칠간 서비스가 중단되거나 방해받을 수 있다.
 
더 큰 문제도 있다. 실제 고객들이 데이터를 잃어버린 몇몇 사례가 있는 것이다. 클라우드 공급업체 내부의 문제나 해킹 공격 때문에 발생한 사건이다. 
 
클라우드 개발업체들은 자신들이 3중으로 데이터를 백업해 보호한다고 주장하고 있다. 그러나 개발업체들이 데이터 백업을 보증하는 경우에도 영구적으로 데이터를 잃어버리곤 한다. 따라서 클라우드에 공유하고 있는 데이터를 항상 백업하는 것이 좋다. 최소한 데이터를 영구적으로 잃어버렸을 때의 피해 보상 금액을 법적으로 정해놔야 한다.
 
클라우드 위험 5: 소유권
많은 클라우드 고객들을 당혹하게 만드는 위험이다. 그러나 고객들이 데이터의 유일한 소유주가 아닌 경우가 많다. 대형 퍼블릭 클라우드 업체들을 포함한 많은 업체들이 계약서 조항으로 '보관하고 있는 데이터가 고객 소유가 아닌 공급자 소유'라고 규정하고 있다.
 
클라우드 개발업체들은 데이터를 소유하고 싶어한다. 무언가 잘못됐을 때 법적으로 더 보호를 받을 수 있기 때문이다. 또 고객 데이터를 검색, 발굴해 추가 수익 창출을 위한 기회로 삼는다. 
 
필자는 클라우드 개발업체들이 파산하고 나서 고객의 개인 데이터를 자사의 자산으로 매각한 몇몇 사례에 대한 글을 읽은 적이 있다. 놀랄 일이다. 따라서 이 부분을 확실히 확인해야 한다. 
 
- 누가 데이터를 소유하고 있는가? 
- 클라우드 제공업체가 데이터를 이용해 어떤 일을 할 수 있는가?
 
클라우드 가시성
알려진 클라우드 컴퓨팅 위험이라도, 이를 정확하게 계산하기란 아주 어렵다. 보안이나 가용성 하락 확률을 판단하기에는 사례도, 증거도 부족하다. 특히 특정 개발업체의 경우 이런 위험이 고객에게 상당한 피해를 초래할 가능성도 있다. 우리가 할 수 있는 최선은 럼스펠드의 말을 생각해보는 것이다. 
 
최소한 '모르는 것을 알기 위해' 관리해야 한다.
 
그러나 가장 먼저 할 일은 '모르는 것을 모르는 것'을 최소화하기 위해 노력을 기울여야 한다. 
우선 가능한 투명성을 확보해야 한다. 최소한 가장 최근의 성공적인 관련 감사 보고서 사본을 입수한다. 개발업체에게 기존 입주자의 데이터 손실 및 침해 사례를 요구한다. 또한 이를 보고하는 것과 관련된 정책을 파악한다. 
 
가능한 클라우드 개발업체의 책임 한계를 넓혀야 한다. 할 수 있는 한 가장 어려운 질문과 요청을 해 퍼블릭 클라우드 컴퓨팅이 갖는 위험을 완전히 이해해 나가야 한다.
 
필자가 퍼블릭 클라우드 컴퓨팅에 부정적인 견해를 갖고 있다고 생각할지 모르겠다. 그러나 실제로는 대단한 팬이다. 필자는 대부분의 퍼블릭 클라우드 개발업체들이 고객보다 더 잘 데이터를 보호할 수 있다고 믿는다. 그러나 우리는 클라우드 개발업체의 위험 경감 정책과 방법을 파악해 스스로의 방법과 비교해봐야 한다. editor@itworld.co.kr

X