보안 / 클라우드

대기업용 클라우드 공급업체를 위한 보안

Gregory Machler | CIO 2010.12.02

10억 달러 이상의 매출이 있는 기업이 IT 인프라의 일부를 클라우드 공급업체에게 아웃소싱 할지를 고려하고 있다고 하자. 클라우드에 배치하기 전에 보안에 관련된 어떤 문제들을 짚고 넘어가야 할까?

 

만약 연 매출 10억 달러가 넘는 기업의 CIO나 CSO라면, 자신이 책임지고 있는 IT 인프라를 기꺼이 클라우드에 배치하기 위해서는 어떤 보안 문제를 짚어보아야 할까?

 

다음과 같은 문제에 대해 살펴보자.

 

- 클라우드에는 어떤 것이 배치되는가?

- 민감한 데이터는 어떻게 보호해야 할까?

- 암호화 업그레이드는 어떻게 처리할 것인가?

- 민감한 데이터에 대한 액세스 제한은 어떻게 할 것인가?

- 그리고 핵심 시스템의 메타데이터는 어떻게 추적할 것인가?

 

각 기업마다 클라우드 컴퓨팅 공급업체 소유의 클라우드에 다양한 파이어월 세그먼트(Segment)와 그에 해당하는 네트워크 장비를 보유하고 있다고 가정하자. 각 세그먼트에는 그 세그먼트가 지원하고 있는 다양한 애플리케이션이 존재한다.

 

다른 기업들도 같은 클라우드에 존재할 수 있으므로, 파이어월 세그먼트와 네트워크 구성요소, 동일한 데이터베이스, 가상 운영체제, 그리고 가상 스토리지를 함께 공유하고 있을 수도 있다.

 

첫 번째, 클라우드 공급업체가 가지고 있는 실질적인 보안 제약사항 몇 가지에 대해서 살펴보자.

 

기업들의 현 IT 애플리케이션에는 표준이 없으므로 어떤 기업의 모든 인프라를 클라우드에 설치하기는 어려울 것이다. 예를 들면, 필자가 작업한 어떤 클라이언트는 웹 서비스와 통합된 메인프레임 솔루션을 가지고 있었다. 그 웹 서비스는 POS(Point of Sale) 시스템과 인터페이스 되어 TCP/IP를 통해 고유 포트를 사용하여 메인프레임과 통신했다.

 

이 솔루션용으로 모든 POS 솔루션, 웹 서비스, 그리고 TCP/IP 통신을 클라우드에 둘 수도 있었다. 하지만, 메인프레임의 애플리케이션, 고유의 스토리지 인프라, 그리고 암호화 기법은 클라우드에 두기 어려웠다. 메인프레임 애플리케이션을 포팅(Porting)할 수도 있었지만, ROI(Return on Investment) 검토를 수행하지도 않고 그렇게 하는 것이 현명하다고 할 수는 없다.

 

두 번째 우려는 민감한 데이터에 대한 액세스이다. 민감한 데이터는 클라우드에 어떻게 저장할 것인가? SAN(Storage Area Network) 서브시스템은 데이터를 스토리지 어레이의 여러 드라이브에 스트라이핑(Striping)한다. 암호화된 데이터를 전체 디스크 어레이에 스트라이핑하는 것이 좋을까?

 

필자의 고민은 데이터베이스, 파일 시스템, 혹은 디스크나 SSD(Solid State Drive)의 오류가 동일한 서브시스템에서 (가상화된) 데이터를 공유하고 있는 다른 애플리케이션으로 확산되는 것이다. 그래서 데이터베이스, 파일 시스템 혹은 디스크 상의 암호화된 데이터를 격리할 수 있는 방법이 필요한 것이다. 데이터의 구분이 오류 발생 시 그 확산을 억제해 줄 것이다.

 

세 번째로, 저장된 데이터용 암호화 알고리즘을 어떻게 갱신할 것인가? 프로세서 속도가 빨라짐에 따라 데이터를 해킹하기도 더 쉬워지기 때문에, 여러 데이터베이스와 파일 시스템 안에 저장된 암호화된 데이터를 업데이트할 필요가 있다.

 

그래서 그런 데이터는 기존 암호화 알고리즘으로 복호화한 다음에 새 알고리즘으로 다시 암호화해야 한다. 새로운 알고리즘으로 인해, 새로 암호화된 데이터가 데이터베이스나 파일 시스템에서 더 많은 공간을 차지할 수도 있다. 이 또한 감시할 필요가 있다.

 

그 다음, 클라우드 공급업체 내부에 있는 애플리케이션 데이터에 대한 매우 정교한 액세스 제어가 필요하다. 필자가 원하는 것은 데이터베이스, 파일 시스템 및 기기 일부에 대해서 클라우드 클라이언트 중 특정 개인만이 데이터에 액세스할 수 있는 LADP(Lightweight Directory Access Protocol) 디렉토리나 액티브 디렉터리(Active Directory) 인터페이스이다.

 

각각의 개인이 액세스할 수 있는 여러 가지 애플리케이션 데이터베이스, 파일 시스템, 혹은 디스크나 SSD의 일부분을 정의하고 있으며, 클라우드 클라이언트/세그먼트/애플리케이션/사용자 별로 구분되어 모두 포함되어 있는 한 개의 클라우드 공급업체 디렉터리가 필요하다. 이렇게 봉쇄된 액세스는 비공인 사용자와 관리자가 부적절하게 데이터에 액세스하는 것을 막아준다.

 

마지막으로, 세그먼트와 해당 세그먼트의 애플리케이션 메타데이터를 보관할 장소가 필요하다. 그 이유는 기업이 소유하고 있는 세그먼트와 애플리케이션을 클라우드에 넣거나 빼내기 위해서이다.

 

클라우드 클라이언트의 메타데이터 보관을 위해서는 LDAP 디렉토리나 AD 사용을 권장한다. 클라우드 클라이언트는 자원을 추출하고 경쟁적인 측면에서 특정 애플리케이션을 보강하기 위해서 이런 유연성을 활용할 수 있다. 클라우드 클라이언트는 클라우드 공급업체에 만족하지 못할 경우, 세그먼트와 애플리케이션을 제거할 수도 있다.

 

이런 디렉토리 메타데이터 계층구조는 해당 네트워크 세그먼트에 대한 가상 파이어월, 스위치, 라우터, 그리고 로드밸런싱 장비에서 세그먼트 정의를 갖고 있을 것이다. 주(Parent) 세그먼트의 부(Child) 세그먼트들은 해당 세그먼트가 지원하는 각 애플리케이션에 대한 메타데이터가 될 것이다.

 

요약하면, 클라우드 컴퓨팅은 공통 표준을 사용하는 기업 애플리케이션과 인프라만을 아웃소싱할 수 있다. 저장된 민감한 데이터는 공통적인 암호화 기법, 프로토콜을 사용할 필요가 있으며, 애플리케이션의 암호화된 데이터의 울타리가 되어 줄 보호 경계도 필요하다.

 

암호화 기법에는 데이터베이스 및 파일 시스템의 데이터에 대한 업그레이드 경로를 가질 필요가 있다. 민감한 데이터는 데이터베이스에서 애플리케이션의 데이터에 대한 액세스 대상을 제한하기 위해서 클라이언트/시스템/애플리케이션/사용자 계층구조에 따라 정의된 클로벌 클라우드 공급업체 LDAP나 AD가 주도하는 액세스도 필요로 한다.

 

마지막으로, 디렉토리에는 클라우드 내에서 애플리케이션의 쉬운 추가와 제거를 가능케 해주는 클라우드 컴퓨팅 메타데이터 계층구조도 포함되어 있어야 한다.

 

*Gregory Machler는 독립 IT 아키텍트이자 마케팅 컨설턴트로, 마케팅과 엔지니어링을 넘나드는 IT와 제품 솔루션에 초점을 맞추고 있다.  editor@idg.co.kr

 Tags 보안 클라우드
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2023 International Data Group. All rights reserved.