Offcanvas

보안 / 애플리케이션 / 클라우드

클라우드 공급업체가 지켜야 할 보안 2부 : 접근 제어

2011.02.09 David Taber  |  CIO

지난 기사에서 ID와 인증, 암호화, ILP/DLP, 감사 추적 같은 클라우드 컴퓨팅 서비스 업체의 7가지 기본 보안 사항에 대해 살펴봤다. 이번에는 접근 제어에 대해 자세히 알아보겠다.

 

이용하고 있는 클라우드 애플리케이션이 무슨 일을 하느냐에 따라, 접근 제어에는 몇 단계의 수준이 있다. 가장 단순한 단계는 파일 수준의 접근 제어이다. 운영체제가 시스템에 들어 있는 모든 파일을 대상으로 사용자/그룹/세계별로, 즉 ACL(Access Control List)을 수행하는 것이다. 운영체제는 원격 프로세스가 자격을 승인받고 나면, 사용자의 역할이나 프로파일에 따라 C/R/U/D 권한을 적용한다.

 

또 대부분의 운영체제는 프로세스와 시스템 객체에서 접근 제어를 실행한다. 클라우드 시스템에서 이와 같은 개괄적인(course-grained) 접근 관리는 기초적이고 상당히 정형적인 방식이다. 따라서 새로운 내용이 많지 않다.

 

DBMS 또한 이와 유사하게 클라우드 전반에 걸쳐 보안을 실행한다는 점에서 상당히 정형적이라 할 수 있다. 모든 DBMS 보안 시스템은 테이블 수준의 접근 제어 실행을, 그리고 대부분은 칼럼 수준의 제한 실행을 제공한다. 또 DBMS는 트랜잭션 수준에서 경합을 관리하고 충돌을 방지하게 위해 조처를 취한다. 클라우드는 사실 여기에서 많은 변화를 초래하지 않기 때문에 이 수준에서는 문제가 많지 않다.

 

복잡다단해지는 애플리케이션 수준의 접근 제어

하지만 애플리케이션 수준으로 가면 한층 흥미로워진다. 클라우드 애플리케이션 업체들이 접근 제어 메커니즘과 관련, 구축단계부터 많은 공을 들여야만 하기 때문이다. 멀티테넌시(multi-tenancy)와 관련된 업무 중 일부가 이뤄지는 수준이다.

 

하지만 접근 제어 수행 모델은 클라우드 애플리케이션 종류에 따라, 그리고 업체에 따라 달라지는 경향이 있다. 예를 들어 데이터 접근과 공유의 세부 방식은 회계 시스템, 전자상거래 엔진, ERP 시스템, CRM 시스템과 비교해 소셜 네트워크에서 완전히 달라진다. 이는 클라우드 전반에 걸쳐 통합을 시도할 때, 접근 제어와 관련 해결해야 하는 과제가 되는 부분이기도 하다.

 

더 자세한 설명을 위해, 세일즈포스닷컴의 사례를 살펴보겠다. 다만 절대적인 표준으로 받아들이지는 말기 바란다. 이 사례는 클라우드 간 교차 통합이라는 공통의 목표를 갖고 있고, 필자 개인적으로 최선의 보안 모델로 이해하고 있을 뿐이다.

 

세일즈포스닷컴은 믿을 수 없을 정도로 간단한 몇 개의 필터를 통해 접근 제어를 정의하고 실행하고 있다. 필터는 다음과 같이 사용자 계정의 그룹과 클래스에 각기 적용된다.

 

- 프로파일이 사용자 클래스가 테이블과 객체, 기능성 영역을 인지할 수 있는지 규정한다.

- 프로파일이 사용자 클래스가 테이블 칼럼(객체 속성)을 인지할 수 있는지 규정한다.

- 역할이 사용자 클레스가 레코드(열 또는 인스턴스)를 인지할 수 있는지 규정한다.

- 레코드 형식은 어떤 프로파일이 레코드 내부의 개별 셀을 인지할 수 있는지, 여타의 기능이나 객체 클래스를 대상으로 접근을 제한할 수 있는지 규정한다.

 

이들 필터에는 수퍼유저(superuser)의 접근 범위를 지정하거나 확대해주는 일종의 제어자(modifier)가 있다. 그러나 이와 같은 필터링 메커니즘 모두는 아주 양호한 접근 제어 수준을 대부분의 사용자에게 적용할 수 있다. 경우에 따라서는 지나칠 정도이다. 로킹과 필터링은 맥락이나 상황에 종속적일 수 있다. 그리고 필수적인 기업의 요구에 방해가 되기도 한다. 따라서 시스템 제공기업은 데이터 공유에 있어 개인이나 그룹 수준에서 예외를 허락하는 수단을 제공한다.

 

세일즈포스는 싱글 인스턴스(single instance) 환경에서 이런 방법들을 모두 이용하고 있다. 또 인스턴스를 연결하는 메커니즘을 보유하고 있기도 하다. 기업이 세일즈포스의 분리 인스턴스("org")에서 협력업체들과 개별 레코드를 공유하도록 하기 위해서다.

 

무궁무진한 보안

현재 사용하고 있는 클라우드 애플리케이션이 이런 보안 모델을 사용하고 있는가? 이는 핵심이 되는 부분이다. 분명히 이와 동등한 개념이 있을 수 있다. 하지만 모든 클라우드 애플리케이션 업체마다 구체적인 사항은 달라질 것이다. 클라우드를 통합할 때, 객체와 컨텍스트(context) 또는 트랜잭션과 관련, 애플리케이션의 보안 모델을 가장 깔끔하게 실행하는데 목표를 둔다. 그리고 이는 개발자 입장에서는 큰 도전이 될 수 있다.

 

기업에서 가장 꺼리는 것은 애플리케이션 외부에서 모든 보안장치를 에뮬레이트(emulate) 하려는 시도다. 개발자들이 모델을 정확히 이해하고 있다 할지라도, 잘못될 수 있는 부분이 무궁무진하다. 지속적으로 이뤄지게 되는 보안 모델의 관리와 설정, 그리고 코딩 모두에 있어서 그렇다.

 

클라우드 애플리케이션을 통합할 때, 외부 애플리케이션은 광범위한 사용자들에 대한, 또는 이들을 대표해 레코드에 접근할 수 있어야 한다. 예를 들어, 전자상거래 시스템은 영업 활동과 관련, CRM 시스템에서 기회를 생성하고 마무리할 수 있어야 한다. 외부 클라우드 전자상거래 시스템은 영업 담당자의 역할을 체현할 필요가 없다. 그러나 거래를 성사시키기 위해 CRM이 가장 높은 단계의 영업 관리자로서의 역할을 체현하도록 해야 한다. 이 경우 해결책은 전자상거래 통합 지점이 관련 영업 대표에 상응하는 자격을 갖도록 하는 것이다.

 

이런 사례가 성공을 거둘 수 있는 이유는 외부 시스템이 CRM 시스템의 내부적 요청에 의한 트리거(trigger) 없이, 본질적인 한 가지 일을 하기 때문이다. 그렇다면 외부 시스템이 기밀에 해당하는 서비스나 사용자별로 접근을 엄격하게 제어해야 하는 서비스(예, 급여 기록 또는 커미션 확인)를 제공하고 있다면 어떨까?

 

이 경우, 사용자가 브라우저를 통해 직접적으로 외부 클라우드 서비스를 요청할 수 있도록 해서는 안 된다. (예, 자바스크립트 및 JSON을 매개체로 트리거하거나, 스크린 매시업을 통해 제출하는 방식). 대신 사용자의 고유 시스템용 기간 시스템이 제공하는 데이터 메커니즘을 통해 이를 제어하는 형태가 되어야 한다.

 

보안 모델이 느슨한 클라우드는 해당 클라우드의 API 콜아웃(call-out)을 이용하는 엄격한 보안모델의 제어를 바탕으로 접근이 이뤄져야 한다. 이런 사례에 있어서, 커미션 관련 데이터를 확인하기 위해 이뤄진 사용자의 요청은 CRM 클라우드에서 커미션 클라우드로 호출된다. 그리고 적절한 수준의 접근 제어를 적용할 수 있는 CRM 테이블을 통해 결과가 제시된다.

 

본질적으로, 클라우드 간 대화를 계층별로, 그리고 독립적으로 접근 제어 전략을 고려하고 해결해야만 한다. 물론 그렇다 하더라도, 시험 가능성과 유지관리, 신뢰성 때문에, 기업은 이와 같은 보안 메커니즘을 가능한 많이 재활용했으면 하고 바라게 될 것이다.

 

과도한 다양성...표준화 시급

클라우드 전반에 걸쳐 접근 제어 모델과 실행 메커니즘이 다르다. 그리고 이런 이유에서 일률적인 접근 및 감사 수준을 제공하는 일은 계속해서 과제가 되고 있는 것으로 보인다. 불행히도 필자는 이런 문제를 해결해줄 여타의 표준화 기구를 보지 못했다. 오히려, 이런 상황이 관행화되어 가고 있다는 우려를 지울 수 없다. ciokr@idg.co.kr

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

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

Copyright © 2024 International Data Group. All rights reserved.