 |
|
난이도 : 중급 Mark O'Neill, CTO, Vordel
원문 게재일 : 2009 년 6 월 16 일
번역 게재일 : 2009 년 9 월 22 일 하이브리드 클라우드 애플리케이션 개발에 대해 다루는 세 편의 기사로 구성된 시리즈의
마지막 기사인 이 기사에서는 클라우드 컴퓨팅의 통제와 보안에 대해 설명합니다. Part 2에서 작성한
HybridCloud 애플리케이션 예제를 바탕으로 Amazon SQS(Simple Queue Service)의 사용과 관련된
액세스 제어 정책을 추가하는 방법을 살펴봅니다. HybridCloud 애플리케이션에서 클라우드 서비스에
대한 인증을 받는 방법과 로그 감사 추적을 Amazon S3(Simple Storage Service)에 추가하는 방법에
대해 자세히 설명합니다. 마지막으로 Google Apps에서 OAuth를 사용하는 방법과 Force.com 클라우드
서비스에서 내장 테스트를 통해 우발적인 DoS(Denial-of-Service) 공격을 방지하는 방법에 대해 설명합니다.
소개
클라우드 통제는 클라우드 서비스와 관련된 정책을 적용하는 작업이다. 먼저 반대의 경우를
살펴보면 클라우드 통제의 가치를 확인하는 데 도움이 될 것이다. 즉, 조직에서 적절한 어떠한
감시도 없이 완전 무료로 클라우드 서비스를 사용하게 되면 매우 혼란스러운 상황이 발생한다. 이러한
혼란을 피하려면 클라우드 서비스 사용과 관련된 정책을 적절하게 적용하여 개인 정보가 클라우드에
유출되는 것을 막고 클라우드 서비스의 과도한 사용을 제어해야 한다. 과도하게 사용된 부분에
대해서는 비용이 청구되어야 한다. 통제와 보안이 적절히 적용되어 있다면 클라우드 컴퓨팅을 안심하고
사용할 수 있다.
SOA 통제로부터 얻은 교훈
통제(Governance)는 SOA의 채택과 함께 등장한 용어이다. SOA에서는 통제를 디자인 타임 통제(웹
서비스에 대한 정책 정의)와 런타임 통제(실시간 트래픽에 정책을 실제로 적용)로 구분한다.
|
자주 사용하는 약어
- API: Application programming interface
- DSA: Digital Signature Algorithm
- IP: Internet protocol
- IT: Information technology
- REST: Representational State Transfer
- SOA: Service Oriented Architecture
- SSL: Secure Sockets Layer
- URI: Universal Resource Identifier
- WSDL: Web Services Description Language
- XML: Extensible Markup Language
|
|
SOA의 서비스와 같은 클라우드 플랫폼은 주로 웹 서비스 API를 사용하여 액세스하기 때문에 SOA
통제와 동일한 머리글을 사용하는 경우가 대부분이다. 적어도 SOA 통제의 기본 원칙을 재사용할 수 있다.
SOA 통제에서는 일반적으로 레지스트리를 이용한다. 이는 사용자가 SOA의 서비스와 더불어 서비스에
적용된 정책도 볼 수 있는 중앙 위치이며 표준 WS-Policy와 호환 WS-Attachment 스펙을 통해 SOA의 서비스에
정책을 할당할 수 있다. 실제로 서비스에는 해당 정책에 대한 "포인터"가 있다. 레지스트리는 이러한
서비스와 정책의 관계를 관리한다.
SOA 통제 제품에서 제공하는 또 하나의 중요한 기능은 서비스의 수명 관리이다. 이는 서비스의
변경 사항을 제어 및 추적하는 기능과 서비스를 변경할 수 있는 사용자를 제어하는 기능을 의미한다. 이
기능을 사용하게 되면 조직에서 서비스를 작성한 사용자, 변경한 사용자 및 변경된 시기를 파악할 수 있다.
SOA 통제만 있으면 클라우드 통제와 관련된 문제가 모두 해결된 것일까? 결코 그렇지 않다. 일반적으로
클라우드 서비스에서는 SOAP가 아닌 메시지를 사용하여 통신하고 서비스는 WSDL에 정의되어 있지 않다.
그리고 이들 두 표준은 일반 SOA 통제에서 사용되는 표준이다. 이는 곧 서비스를 SOA 통제 레지스트리로 바로
가져올 수 없다는 것을 의미한다. 클라우드 컴퓨팅에 사용되는 웹 서비스에서는 SOAP와 WSDL을 무시하는
대신 비교적 다루기가 쉬워서 개발자가 많이 사용하고 있는 경량 REST 스타일 서비스를 활용한다.
가상 시스템은 SOA와 차별되는 클라우드 컴퓨팅의 새로운 특징이다. 클라우드 컴퓨팅에서는 웹 서비스뿐만
아니라 가상 시스템도 활용한다. Amazon EC2(Elastic Compute Cloud) 환경은 단순히 서비스를 모아 놓은 환경이
아닌 일종의 가상화된 호스팅 환경으로 볼 수 있다. 따라서 Amazon EC2에 대한 통제는 가상 시스템에 대한 통제의
예라고도 할 수 있다. 특히, 가상 시스템을 전개하면 어지러운 환경을 쉽게 정리할 수 있기 때문에 조직에서는
문서화되지 않은 방식으로 조금씩 다른 여러 가상 시스템을 사용하고 있다. 하지만 많은 VMware 또는 Citrix Xen
사용자가 알고 있는 것처럼 개인 사용자라고 하더라도 가상 시스템을 추적하기가 어려울 수 있다. 또한 조직의
경우에는 그 어려움이 배가될 것이라고 충분히 짐작할 수 있다. 게다가 가상 시스템이 써드파티 클라우드 서비스에서
호스팅된다면 더욱 심각한 문제가 될 것이다.
하지만 VM(Virtual Machine) 통제에도 SOA 통제의 "수명 통제" 기능과 비슷한 기능이
있다. Amazon EC2 클라우드 환경에서 VM은 AMI(Amazon Machine Image)의 인스턴스이다. 특정
AMI를 전개할 수 있는 사용자를 제어하는 규칙을 적용하는 기능이 중요하다. 구체적으로 말하자면
VM을 재부팅할 수 있는 사용자, 기존 VM 환경에 용량을 추가할 수 있는 사용자, 기존 가상 시스템
인스턴스를 삭제할 수 있는 사용자를 제어하는 기능이 중요하다.
마지막 기능 즉, Amazon AMI 인스턴스를 삭제하는 기능은 이러한 인스턴스에 대한 사용 비용을
조직에서 지불해야 하기 때문에 특히 중요한 기능이다. 가격은 사용량(이미지가 실행 중 상태에
있는 시간)과 데이터 트래픽을 기준으로 결정된다. 클라우드 통제 시스템이 제대로 갖추어져 있지
않다면 AMI 시스템 인스턴스가 불필요하게 많이 실행되면서 많은 비용 낭비가 발생할 수 있다. 하지만
이와는 반대로 클라우드 통제 솔루션이 제대로 갖추어져 있지 않다면 유용한 AMI 인스턴스가 실수로
삭제되는 문제가 발생할 수 있다. SOA 통제가 통제 프레임워크가 제대로 갖추어져 있는 조직에서 불필요한
서비스가 많이 실행되는 문제를 해결하는 것과 마찬가지로 AMI 인스턴스의 수명 관리도 불필요한 인스턴스로
인한 문제를 해결한다.
제품이 아닌 프로세스
SOA 통제는 제품이 아니라 프로세스라는 말을 자주 듣는다. 클라우드 통제에도 이 규칙이
적용된다. 통제 규칙을 적용하기 위해서는 개발자가 제공되는 통제 프레임워크를 잘 알고
있어야 한다. 예를 들어, SOA 통제 레지스트리가 전개된 경우 개발자는 웹 서비스(특히, 웹
서비스의 WSDL 정의)를 이 레지스트리에 등록해야 한다는 것을 알고 있어야 한다. 이처럼
등록하지 않으면 해당 웹 서비스를 추적할 수 없다. SOA 통제에서와 마찬가지로 클라우드 통제에서도
개발자가 클라우드 서비스의 사용을 조직에 등록하도록 요청하지 않으면 비슷한 상황이 발생한다.
SOA 통제 환경에는 레지스트리에서 제공하는 디자인 타임 통제와 더불어 레지스트리에 구성된
규칙을 적용하는 런타임 통제도 있다. 서비스에 대한 이 통제는 일반적으로 임베디드 에이전트나
XML 게이트웨이와 같은 네트워크 매개체에서 적용된다.
클라우드 컴퓨팅 환경에는 레지스트리 및 런타임 적용 지점(예: 에이전트 또는 XML 게이트웨이)과
같은 SOA 통제 업계의 주요 도구가 없다. 이는 클라우드 컴퓨팅 서비스의 사용자가 모든 서비스와
관련 정책을 볼 수 있는 중앙 지점이 없다는 것을 뜻한다. 연결의 클라우드 컴퓨팅측에서는 정책이
적용되지만(클라우드 서비스 공급자에 의해) 클라이언트측에서는 적용되지 않는다. 이는 클라우드
컴퓨팅의 통제에서 해결해야 하는 주요 과제이다.
미숙한 클라우드
많은 부분에서 클라우드 컴퓨팅은 웹 서비스의 초기 시절과 비슷하다. 각 개발자는 이 새 기술을
프로젝트에 사용하기로 결정한 후 개인 차원에서 이 기술을 사용한다. 회사 IT 관리 팀에서는 이러한
사실을 인지하고 못하고 있다가 뒤늦게 파악하고서 통제를 전반적으로 추가하게 된다. 하지만 이 시점에서
대부분의 조직은 클라우드 컴퓨팅과 관련하여 통제 전 단계에 있는 경우가 많다. 초기 프로토타입 과정에서
개인 Amazon 계정과 신용 카드를 사용하기는 하지만 AMI 이미지를 프로젝트에 활용하는 작업은 개발자에게
익숙하지 않은 작업이다.
클라이언트측 통제, 실제로 없을까?
일반적으로 클라우드 서비스 공급자는 서비스 중단 시간 정보를 클라이언트에게 미리 알려주지
않아도 된다. 또한 예기치 않은 이유로 서비스가 중단되더라도 클라우드 서비스 공급자에게는 해당
사실을 클라우드 서비스의 사용자에게 알려줄 의무가 없다. 따라서 클라우드 서비스의 응답 시간과
사용 가능성을 모니터링할 수 있는 클라이언트측 구성 요소가 필요하다. 이 클라이언트측 구성 요소(예:
XML 게이트웨이)는 클라우드 플랫폼에 대한 연결을 모니터링한다. 연결 속도가 느리면 XML 게이트웨이에서
경고를 발생시키거나 캐시에 저장된 응답을 사용하는 등의 대응 조치를 취한다. 이처럼 캐시를 사용하면
클라우드 서비스 중단으로 인한 영향을 줄일 수 있다.
또한 클라이언트에 있는 XML 게이트웨이에서 클라우드 경계 데이터를 검색하여 개인 정보나 회사의
주요 데이터가 유출되는지 검사할 수 있다. 클라우드 공급자에게 보내기 전에 데이터를 암호화하거나
선택적으로 암호화할 수 있다. 예를 들어, XML 게이트웨이에서는 클라우드 컴퓨팅 공급자에게 전송되는
데이터가 식별되지 않도록 하여 개인 정보가 데이터와 관련되지 않도록 할 수 있다.
Vordel XML Gateway Cloud Edition과 같은 XML 게이트웨이에서는 클라우드 플랫폼에 전송되는 트래픽을
필터링할 뿐만 아니라 클라우드 서비스에 대한 액세스에 정책을 적용하기도 한다. 이러한 기능을 통해 XML
게이트웨이에서는 클라우드 서비스에 대한 클라이언트측 진입로를 제공한다.
HybridCloud 애플리케이션에 제어 적용하기
이 시리즈의 Part 2에서 Amazon Web Services를 사용하는 HybridCloud 애플리케이션을 작성하기
시작했다. 이제 클라우드 통제 및 보안을 추가하기 위해 이 애플리케이션이 Amazon Web Services에서
인증을 받는 방법과 서비스 사용에 정책을 적용하는 방법에 대해 살펴본다.
Amazon에서 사용되는 키
HybridCloud 애플리케이션에서는 Amazon SQS 클라우드 서비스를 이용한다. 모든 AWS(Amazon
Web Services)와 마찬가지로 SQS를 이용하려면 Access Key ID 및 연결된 보안 키가 있어야
한다. 이전 기사에서 살펴본 HybridCloud Java™ 코드에서는 Amazon 키를 사용하기 위해
Amazon SQS 클라우드를 사용하고 있는 애플리케이션에 이들 키를 하드 코딩했다. 그렇다면 이러한
키는 어떤 키일까? 이제 자세히 살펴보자.
|
RSA의 의미
RSA 비대칭 암호화 알고리즘의 이름에서 "RSA"는 이 알고리즘에 대한 글을 처음으로 쓴 "Rivest,
Shamir, Adleman"을 의미한다.
|
|
PKI(Public Key Infrastructure)에 익숙하다면 디지털 서명 및 암호화를 위한 RSA 또는 DSA
알고리즘에 사용되는 키처럼 이러한 두 키를 비대칭 키 쌍으로 연결되는 공용 및 개인용 키라고
생각할 수도 있을 것이다. 하지만 이들 키는 기존의 공용 및 개인용 키가 아니다. Access Key ID는
AWS 서비스에 액세스하는 당사자를 식별하는 ID로 사용된다. 이 ID는 개념적으로 사용자 이름과
비슷하며 암호화되지 않은 요청으로 보낼 수 있다. 실제로 Amazon S3 클라우드 서비스를 온라인
스토리지로 사용할 경우 Access Key ID가 URL에 포함된다. 사용자가 Access Key ID "12456789"를
할당한 경우 Amazon S3에 저장된 사용자의 파일 버켓에 있는 파일을 검색할 때 https://s3.amazonaws.com/123456789- bucketname/filekey
형식의 URL이 사용된다.
| |
Amazon S3의 정의에 따르면 버켓은 파일을 저장하기 위한 스토리지 컨테이너이다. S3에서
필요한 공간을 정의하려면 버켓을 작성한 다음 Amazon 시스템 내에서 고유한 이름을 버켓에 지정해야
한다.
|
|
Access Key ID가 URL에 표시된다는 것은 파일에 액세스하기 위한 Amazon S3 버켓에 대한 요청을
라우팅하는 네트워크 인프라의 로그에도 Access Key ID가 저장된다는 것을 의미한다. 따라서 라우터나
프록시에서도 Access Key ID에 액세스하게 된다. 이처럼 Access Key ID는 매우 쉽게 검색되기 때문에
인증에 사용하기에 적합하지 않다. 실제로 Access Key ID는 식별을 위한 것이지 인증을 위한 것이 아니다.
Secret Access Key는 인증을 위한 키이다. 하지만 클라이언트가 이 키를 AWS 서비스에 보내지는
않는다. 대신 이 키는 Secret Access Key를 소유하고 있다는 증거를 제공하기 위해 사용되는 디지털
서명의 형식을 작성하는 데 사용된다. 이 소유 증명은 SSL 핸드셰이크 프로토콜에서 키를 직접 보내지
않고 암호화를 사용하여 클라이언트가 개인용 키를 실제로 소유하고 있다는 것을 입증하는 방법과
비슷하다. 클라이언트가 키를 사용할 수 있다는 사실이 키가 해당 클라이언트의 제어 하에 있다는
증거가 되는 것이다.
PKI 공용 및 개인용 키 쌍의 경우에는 쌍을 이루는 두 키 간에 수학적 관계가 있다. 개인용 키를
사용하여 암호화된 데이터는 해당 공용 키를 사용하여 해독할 수 있다. 이는 PKI 기반 디지털 서명의
기본 원칙이다. 키 소유자만 서명을 작성할 수 있는 반면 공용 키(일반적으로 X.509 인증서에서 가져옴)에
액세스할 수 있는 누구나 서명의 유효성을 검증할 수 있다.
Amazon Web Services의 Secret Access Key에는 이러한 특성이 없다. 대신 이 키는 Amazon.com과
클라우드 서비스 등의 AWS 리소스를 사용하는 개발자가 공유하고 있는 비밀이라고 생각할 수 있다. 다른
사용자와 이 키를 공유해서는 안된다. 왜냐하면 이 키를 사용하여 Amazon 클라우드 서비스에 액세스할 수
있기 때문이다. 클라우드 서비스에 대한 사용 비용이 개발자에게 청구되므로 Secret Access Key를 다른
사용자가 알게 되면 절대 안된다. 그렇지 않은 경우 매우 많은 비용이 청구될 수도 있다. 제 3자가 Secret
Access Key에 액세스했다는 의심이 들 경우에는 새 Secret Access Key를 온라인으로 생성할 수 있다.
HybridCloud 애플리케이션에서는 키가 애플리케이션 자체에 하드 코딩되어 있다. 하지만 Java 보호
프로그램(obfuscator)을 사용하지 않을 경우에는 공격자가 애플리케이션을 리버스 엔지니어링하여 키를
찾아낼 수 있다. 따라서 Java 보호 프로그램(obfuscator)을 사용하는 것이 좋다(참고자료
참조).
HybridCloud 애플리케이션에 대한 정책
이 시리즈의 Part 2에서 작성한 HybridCloud 애플리케이션에서는 X선 데이터를 Amazon SQS에
보낸다. X선 이미지는 분명 개인 의료 데이터이므로 클라이언트측에서 개인 데이터로 식별된 이후에
Amazon SQS 서비스로 전송되어야 한다. 데이터가 Amazon SQS에 도달하고 나서야 식별된다면 적절한
시점을 놓치게 된다. 이것이 바로 로컬 게이트웨이를 사용하여 클라우드 컴퓨팅 리소스에 연결해야
하는 또 다른 이유이다.
HybridCloud 애플리케이션의 보안과 관련하여 또 하나 고려할 사항은 신뢰할 수 있는 클라이언트만
서비스에 액세스할 수 있도록 Amazon SQS 서비스에 대한 액세스를 잠그는 것이다. 이 작업에는 Amazon
SQS 정책이 사용된다. Amazon SQS 정책은 JSON(JavaScript Object Notation) 형식으로 정의된다.
이제 HybridCloud 애플리케이션에 적용할 수 있는 여러 가지 Amazon SQS 정책을 살펴보자. (애플리케이션에 대한 세부 사항과 소스 코드는 이 시리즈의 Part 2에서 볼 수 있다.)
먼저 이 정책에서는 Amazon Web Services 계정 번호가 1234567890인 개발자만
리소스 URI /987654321/queue1을 사용하는 개발자 소유의 큐에 액세스할 수 있다고
규정하고 있다(Listing 1 참조).
Listing 1. Amazon SQS 정책 살펴보기
{
"Version": "2008-10-17",
"Id": 12345678901234567890
"Statement":
{
"Sid":"Queue1_SendMessage",
"Effect": "Allow",
"Principal": {
"AWS": "1234567890"
},
"Action": "SQS:SendMessage",
"Resource": "/987654321/queue1"
}
}
|
이제 이 정책을 자세히 살펴보자. 먼저 버전 정보를 볼 수 있다. 현재까지 이 필드에 사용할
수 있는 유일한 값은 2008-10-17이다. 다음으로 규칙의 ID를 볼 수
있다. 이 ID는 전체 Amazon Web Services 내에서 고유해야 한다. "Statement"는
실제 정책이다. Statement의 내부를 보면 Resource가 Amazon SQS 큐라는 것을 알 수 있다. 그리고
여기에서는 특정 "Principal"(이 경우에는 특정 AWS 사용자)이 특정
큐에 액세스할 수 있을 뿐만 아니라 해당 Principal만 큐에 액세스할 수 있다고 지정하고 있다.
날짜, 시간 및 소스 IP 주소를 기반으로 SQS 큐에 대한 액세스를 제어하는 정책도 설정할 수 있다(Listing 2 참조).
Listing 2. SQS 큐에 대한 액세스를 제어하는 정책 설정하기
"Condition" : [{
"DateGreaterThan" : {
"AWS:CurrentTime" : "2009-04-10T09:00:00Z"
}
"DateLessThan": {
"AWS:CurrentTime" : "2009-04-10T17:30:00Z"
}
"IpAddress" : {
"AWS:SourceIp" : ["4.3.2.1/24"]
}
}]
|
코드로 작성된 이 정책에서는 2009년 4월 10일 오전 9:00부터 오후 5:30 사이에 특정 IP 주소 범위에 해당하는 클라이언트만 큐에 액세스할 수 있도록 지정하고 있다.
AddPermission 및 RemovePermission 함수를
사용하여 각 큐에 대한 특정 액세스 권한을 설정 및 제거할 수 있다.
Amazon SQS에 대한 정책은 당연히 클라우드 서비스 공급자측에서 작동한다. 하지만 클라우드
공급자에게 전송되는 데이터를 전송 전에 암호화 또는 검색하려면 클라이언트측 XML 게이트웨이
장비를 사용하는 것이 이상적이다.
지금까지 HybridCloud 애플리케이션에서 Amazon SQS 서비스에 대한 액세스를 잠그는 방법에
대해 살펴보았다. 이제 Amazon, Google 및 Salesforce에서 제공하는 클라우드 보안 솔루션에 대해
간략히 살펴보자.
Amazon S3
Amazon S3(Simple Storage Service)는 온라인 스토리지에 사용되는 클라우드 서비스로 사진
고유 사이트 SmugMug(참고자료의 링크 참조)와 같은 웹 사이트에서
백 엔드 스토리지 기능으로 사용된다. 물론 회사 기밀 데이터를 저장할 때도 사용할 수 있다. Amazon
S3에 저장하는 데이터는 상황에 따라 매우 중요한 데이터일 수도 있다. 기밀 데이터라면 Amazon
SQS 서비스에 보내기 전에 XML 게이트웨이를 사용하여 데이터를 암호화하는 것이 좋다. 또한 Amazon
SQS에서 데이터에 액세스한 방법에 대한 정보도 추적한다. 이러한 기밀 문제 외에도 사용량에
따라 비용이 지불되기 때문에 단순히 S3 사용량을 추적할 수도 있다. 누구나 청구서 금액이 엄청난
액수라면 이러한 사용 금액을 전체적으로 확인하려고 할 것이다. 이러한
모든 이유 때문에 Amazon S3 서비스에 대한 로깅을 사용하는 것이 중요하다.
Cloudberry Explorer 애플리케이션을 사용하여 S3 인스턴스에 대한 로깅을 설정하면(참고자료
참조) Amazon S3 버켓에 대한 로깅을 쉽게 사용할 수 있다. Cloudberry Explorer는 Amazon S3에 대한
GUI 프론트 엔드를 효과적으로 제공한다. Cloudberry Explorer에서 버켓을 선택하고 도구 모음의
Logging 단추를 클릭한 다음 Use logging 선택란을 선택한다. 그런 다음 드롭다운
목록에서 로그 파일을 저장할 버켓을 선택한다. 이 시리즈의 예제에서는 cloudberry.log를
사용한다. 로그는 실제로 Amazon 클라우드 서비스에 기록된다. 로그 파일은 동일한 지역에 있는
버켓에 기록해야 한다. 즉, 미국 지역의 애플리케이션은 미국 지역의 로그에 기록해야 한다. 로그
파일은 Amazon S3 스토리지를 사용하기 때문에 월간 비용이 추가로 청구된다. 하지만 이 비용은
Amazon S3 스토리지 서비스에 액세스한 사용자에 대한 감사 추적 정보를 유지하기 위해 지불하는
것으로 글자 그대로 소액에 불과하다.
Google Apps
Google에서는 클라이언트측 Java 애플리케이션을 Google Apps 클라우드 서비스에 연결할
수 있도록 Google SDC(Secure Data Connector)라는 도구를 제공한다. 이 도구는 로컬 네트워크와
Google Apps 사이에 암호화된 링크를 제공하며 Google에서 호스팅하는 Google Apps 애플리케이션에서
로컬 네트워크에 연결할 때 주로 사용된다. 이 도구는 Google Apps에서만 이 연결을 통해 연결할
수 있는 환경을 제공하기 위해 제작되었다. 또한 이 도구는 Google Apps 가젯에서 액세스할 수 있는
내부 시스템을 제한하는 필터를 제공한다. 이 필터는 방화벽 규칙과 같은 기능을 수행하지만 애플리케이션
레벨에서 적용된다는 점이 다르다. 액세스할 수 있는 애플리케이션을 제어하는 것뿐만 아니라 사용자
레벨 제어도 추가할 수 있다. 이 기능을 사용하면 Google Apps 서비스에 액세스하는 사용자와 해당 서비스를
제어할 수 있다.
Google Apps SDS의 ID 프레임워크에서는 OAuth를 사용한다. 예를 들어, 호스팅되는 Google Apps
서비스가 OAuth를 사용하여 해당 서비스 자체 및 그 사용자를 로컬 애플리케이션에 대해 식별할 수
있다. 아직까지는 OAuth가 널리 사용되고 있지 않지만 Amazon에서 OAuth를 지원하고 있기 때문에
상황이 바뀔 수도 있다.
Force.com: 보호 및 테스트
이 시리즈의 Part 1에서 보았듯이 SalesForce의 Force.com 클라우드 서비스에서는 Apex라는
프로그래밍 언어를 사용한다. Force.com에서는 클라우드 플랫폼에서 호스팅되는 Apex 코드에 "assert"
함수를 의무적으로 포함시켜 코드가 필요한 동작을 수행하도록 한다. 이러한 요구사항은 개발자의 Apex
클래스 중 최소 75%에 적용되며 가능하다면 모든 클래스에 적용되는 것이 이상적이다. 이는 전체 시스템에서
발생할 수 있는 우발적인 DoS(Denial-of-Service) 공격을 방지하기 위한 조치이다. 예를 들어, 무한
루프 상태가 되거나 리소스를 과도하게 사용할 수 있는 코드는 이러한 예측하지 못한 상태가 발생할 가능성을
감지하는 테스트 코드로 랩핑해야 한다. 또한 Force.com에서는 추가된 보호 기능인 거버너(governor)라고
하는 제한 기능을 통해 스택 깊이, 문자열 크기 등과 같은 측정 기준에 규칙을 적용한다.
다른 클라우드 공급자의 경우에는 Force.com과 비슷한 테스트 조건이 없지만 Force.com을 클라우드 플랫폼으로
사용하지 않는다고 하더라도 Force.com에서 제시하는 권장 사항을 따르는 것이 좋다. 그렇게 하면 DoS 공격을 차단할
수 있을 뿐만 아니라 클라우드 공급자가 발행한 예기치 않은 요금 청구서로 인해 놀라는 일도 없을 것이다.
요약
Cloud Security Alliance와 같은 여러 단체에서 클라우드 보안을 강화하기 위한 노력을 경주하고
있으며 현재까지는 서비스 공급자 수준에서 Amazon, Google 및 Force.com이 앞서 가고 있는 형국이다. 하지만
이 상태가 고착될지는 아무도 알 수 없다. Federal Trade Commission에서는 알려진 데이터 관리 문제로 인해
발생할 수 있는 클라우드 컴퓨팅 관련 위험을 조사해 달라는 요청을 받고 있다. 클라우드 통제 및 보안에 대한
인식이 높아지고 있으므로 앞으로 더욱 향상된 클라우드 통제 및 보안 오퍼링이 등장할 것으로 기대한다.
참고자료 교육
- 클라우드에
연결하기, Part 1: 애플리케이션에서 클라우드 활용하기: 하이브리드 모델 활용하기(Mark O'Neill, developerWorks, 2009년 4월):
JMS 큐를 사용하는 전형적인 기업 애플리케이션의 예를 통해 주요 클라우드 컴퓨팅 공급자(Amazon, Google, Force.com 및 Microsoft
Azure)의 오퍼링을 살펴본다.
- 클라우드에 연결하기,
Part 2: 하이브리드 클라우드 모델 실현하기: JMS 큐 데이터를 Amazon SQS 큐로 가져오기(Mark
O'Neill, developerWorks, 2009년 4월): 기업용 Java 애플리케이션을 클라우드 컴퓨팅 플랫폼에
연결한 후 이 애플리케이션에서 XML, SOAP 및 REST API를 통해 클라우드를 활용하는 방법에 대해
설명한다.
- Leveraging
Amazon Web Services for enterprise application integration: XML messaging with Amazon SQS(Brian Stewart, developerWorks, 2009년 6월): Amazon
Web Services와 XML을 결합하여 엔터프라이즈 애플리케이션을 통합한다. 특정 기술에 의존하지 않으면서도 다중 플랫폼을 지원하는 유연하고 확장 가능한 샘플
애플리케이션을 빌드한다. C# 및 Java 언어로 된 코드 샘플이 포함되어 있다.
- Cloud Security Alliance: 클라우드
컴퓨팅 내에서 보안을 보장할 수 있는 방법을 보여 주는 베스트 프랙티스의 사용을 촉진하기 위해 결성된 이 비영리 단체를 살펴보자.
- S3를 통해 간편하게 스토리지 만들기:
Amazon S3(Simple Storage Service)로 시작하는 클라우드 컴퓨팅(Andrew Glover, developerWorks, 2009년 4월): 오픈 소스 JetS3t
라이브러리를 통해 Amazon의 S3 클라우드 서비스를 활용하여 데이터를 저장 및 검색하는 방법에 대해 설명한다.
- Amazon Web Services: Amazon Web Services와 클라우드 컴퓨팅에 대한 추가 정보를 볼 수 있다.
- Amazon Web Services를
사용한 클라우드 컴퓨팅(Prabhakar Chaganti, developerWorks, 2008년 7월): Amazon Web Services의 사용 방법에 대한 단계별
지침에 따라 웹 스케일 시스템을 빌드하는 방법을 살펴본다.
- Private
Clouds Take Shape: Information Week 기사를 통해 이 기사에서 설명한 하이브리드 클라우드에 대한 추가 정보를 볼 수 있다.
- Vordel XML Gateway, Cloud Edition:
JMS 큐에 대한 커넥터와 클라우드 서비스에 대한 사전 작성된 커넥터가 포함된 이 게이트웨이에 대한 정보를 볼 수 있다.
- developerWorks Cloud Computing
Resource Center: Amazon EC2 플랫폼에서 사용할 수 있는 IBM 제품을 찾아보자.
- Open source Java obfuscators:
이 Java 클래스 파일 축소 및 보호 프로그램(shrinker and obfuscator)을 사용하여 더 작고 리버스 엔지니어링하기 어려운 jar 파일을 만들어 보자.
- Google App Engine Blog:
개발 팀에서 제공하는 유용한 정보를 볼 수 있다.
- 최적의
클라우드 컴퓨팅 플랫폼 찾기(Brett McLaughlin, developerWorks, 2009년 3월): 특정 애플리케이션 요구 사항에 가장 적합한
클라우드 컴퓨팅 플랫폼을 결정하는 데 필요한 정보를 볼 수 있다.
- Connecting
Apple's iPhone to Google's cloud computing offerings(Noah Gift 및 Jonathan Saggau, developerWorks, 2009년 1월):
모바일 장치에서 액세스할 수 있는 클라우드를 만드는 방법에 대한 설명을 볼 수 있다.
- Data
integration with Salesforce CRM using IBM InfoSphere Information Server(Jon Deng 및 Jeff J. Li, developerWorks, 2008년 7월):
Salesforce에서 데이터를 애플리케이션에 액세스할 수 있게 만드는 방법을 볼 수 있다.
- IBM XML 인증: XML 및 관련 기술에 대한 IBM 인증 개발자가 되는 방법을 찾아볼 수 있다.
- XML Technical library: developerWorks XML 영역에서 다양한 기술 관련 기사와 팁, 튜토리얼, 표준 및 IBM Redbook을 볼 수 있다.
- developerWorks technical events and webcasts: 이들 세션에 참가하여 최신 기술에 대한 정보를 얻을 수 있다.
- developerWorks
팟캐스트: 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
제품 및 기술 얻기
토론
필자소개 | | | Mark O'Neill은 XML 네트워킹 회사인 Vordel의 CTO이다. 그가 집필한 "Web Services Security"와 "Hardening
Network Security" 모두 McGraw-Hill/Osborne Media에서 출판되었다. Vordel의 제품 개발 로드맵에 대한 감독 업무를
맡고 있으며 전세계에 있는 Global 2000 회사 및 정부에게 XML, 웹 서비스 및 SOA 기술의 전략 및 전술적 채택에 대한
조언을 제공하고 있다. Trinity College Dublin에서 수학 및 심리학을 전공하고 Oxford University에서 신경망
프로그래밍 자격 과정을 마쳤으며 매사추세츠의 보스톤에 살고 있다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
