\r\n

클라우드(Cloud)는 IT분야의 가장 뜨거운 주제 중의 하나다. 서비스 이용자에 따라 사설 클라우드(Private Cloud)와 공용 클라우드(Public Cloud)로 분류된다. 사설 클라우드는 개별 기업이 자체적으로 구축하여 사용하는 방식이며 공용 클라우드는 일반 사용자에게 서비스할 목적으로 외부에 공개되어 대규모로 이루어지는 서비스로 공용 클라우드는 데이터와 인프라에 대한 통제권이 서비스 사업자에게 있다는 점에서 보안적으로 고려해야 할 요소가 많다.

\r\n

\r\n

대부분의 클라우드 애플리케이션은 사용자 아이디와 패스워드에 기반을 둔 인증을 하고 있는데 이는 공개된 네트워크상에서 매우 취약한 부분이다. 패스워드의 취약성 보완을 위해 매우 어려운 비밀번호 체계를 강제하거나 주기적인 변경 정책을 적용할 수 있다.

\r\n

\r\n

하지만 ‘hmy1stuBBedmyt0e’와 같이 안전하지만 너무 복잡한 비밀번호를 몇 개나 기억할 수 있을까. 그리고 3개월 단위로 패스워드를 변경해야 한다면 어떻게 될까. 이런 이유 때문에 실제 상황에서는 동일한 패스워드를 여러 사이트에서 재사용하거나, 한 개의 패스워드에서 유추가 가능한 패스워드를 사용하고 있는 실정이다.

\r\n

\r\n

클라우드 서비스에서의 사용자 인증 가이드 라인

\r\n

클라우드와 사용자 인증은 어떤 관계가 있는지 살펴보면 클라우드 서비스를 사용한다는 것은 서비스 그 자체뿐만 아니라 계정과 데이터에 대한 접근 통제권을 클라우드 서비스 공급업자에게 위임한다는 것을 의미한다.

\r\n

\r\n

마치 개인금고에 보관하던 귀중품을 은행의 대여금고에 보관하는 것과 유사하다. 대여금고 속에 있는 개인금고는 소유자 본인에 의해 통제되기도 하지만, 실제로는 은행에 의해 통제된다고 보는 것이 더 정확할 것이다.

\r\n

\r\n

물론, 은행의 신뢰성에 바탕을 두고 있기는 하지만 일반적으로 이름, 계좌번호, 패스워드만 알면 대여금고내의 개인 보관함에 접근할 수 있을 것이다. 이러한 문제를 해결하기 위해서는 우선, 서비스 공급업체로부터 인증권한을 분리시켜야 한다. 즉, 인증에 관련된 데이터는 기업이 자체적으로 보관하고 관리해야 한다. 또한, 외부 클라우드 서비스와 내부 서비스 대한 인증 시스템을 단일화해야 한다.

\r\n

\r\n

둘째로 클라우드 서비스 접근통제권을 기업이 가지고 있어야 한다. 인증과 권한 관리를 서비스 제공업체에게 맡기지 말아야 한다는 것이다.

\r\n

\r\n

셋째로 클라우드 서비스에 대한 인증은 투팩터 인증이 최소한의 표준이 되도록 하는 것이 필요하다. 투팩터 인증이란 자신이 ‘알고 있는 것’과 ‘지니고 있는 무엇’을 결합한 형태의 인증을 의미한다. 이인증 방식을 사용하게 되면 네트워크에 접속하는 사용자가 실제 본인임을 더욱 신뢰할 수 있게 된다. 강력한 인증 솔루션은 기업에 새로운 보안 계층 하나를 더 추가하는 효과를 가져온다.

\r\n

\r\n

넷째로 투팩터 인증은 모든 사용자에게 적용이 가능하도록 운영이 편리하고 사용이 간편해야 한다. 전통적으로 투팩터 인증은 사용자에게 물리적인 토큰디바이스를 나눠주는 방식이었다. 이 방식은 초기 투자비용과 유지관리비가 너무 많이 든다는 것이 단점으로 지적되어 왔다. 하지만 토큰을 사용하지 않는 경제적인 인증방식도 보편화 되고 있어 전 직원으로 확대 적용하는 것이 가능해졌다. 투팩터 인증이 전 직원에게 확대 적용 되면 유저아이디/패스워드가 노출되었다 하더라도 이로 인해 전체 네트워크가 위험에 빠지는 불행한 상황으로 연결되지는 않는다.

\r\n

\r\n

연합 아이덴터티(Federated Identity)에 의한 SSO 인증

\r\n

클라우드 서비스에서의 보편적인 인증방식은 사용자가 본인 확인정보(Credentials)를 전송하고 로그인을 요청하면 서비스공급자의 백엔드 시스템에 저장되어 있는 사용자 정보와 비교작업을 거쳐 인증이 이루어진다.

\r\n

\r\n

아래 그림 1에서 보는 것처럼 기존 방식에서는 서비스 이용 기업은 서비스제공업자의 시스템에 접속하여 이용자아이디와 패스워드를 생성하고 삭제하는 권한을 갖는다. 그렇지만 사용자에 대한 인증과 접근통제는 서비스 제공업체의 시스템을 통해 이루어지고, 이용자의 크레덴셜(Credential)이 저장되는 장소와 관리책임은 서비스 제공업체에게 있다.

\r\n

\r\n

그러나 연합 아이덴터티 방식(Federated Identity Approach)에서는 사용자 인증과 권한관리 역할을 서비스 이용기업이 갖게 된다. 이 방식이 전혀 새로운 것이라고 할 수는 없지만, 서비스 공급업체들에 의해 표준으로 정착되어 가고 있다. 이 방식은 또한 서비스 이용기업이 기존에 운영하고 있던 자체 인증시스템을 클라우드 시스템과 연동하여 단일 인증체계로 운영하는 것이 가능함을 뜻한다.

\r\n

\r\n

즉, 연합(Federation)방식 하에서의 인증 체계는 “나의 data에 접근하려는 자가 있으면 그들을 나한테로 보내라. 그러면 내가 그들을 검증하고 판단하겠다”는 원칙에서 출발한다. 따라서 사용자 크레덴셜(Credential)은 서비스 제공업체의 시스템에 저장되지 않고 서비스 사용기업 내에 있는 인증시스템에서 관리된다.

\r\n

\r\n

사용자가 로그인을 시도하면 클라우스 서비스시스템은 사용자 인증 프로세스를 서비스 이용 기업으로 리다이렉션하고, 서비스 이용기업 내에 구축되어 있는 인증 시스템이 사용자를 검증하고 그 결과를 되돌려 주어 로그인을 허용한다.이 연합방식의 가장 큰 특징은 Data에 대한 접근권한이 클라우드서비스 이용기업에 있고, 사용자에 대한 신분확인과 권한관리를 이용기업이 직접 한다는 것이다.

\r\n

\r\n

이 방식을 사용하면 여러 공용 클라우드 서비스뿐만 아니라 사설 클라우드 서비스에 대한 인증체계도 하나로 통합할 수 있다. 따라서 서비스별 또는, 시스템별로 아이디를 따로 가져갈 필요가 없고 한 번의 인증절차로 여러 서비스에 로그인이 가능한 SSO를 구축하는 것이 매우 용이해진다.

\r\n

\r\n

클라우드서비스 통합인증 체계 구축

\r\n

대표적인 클라우드 서비스 구글앱스에 연합 아이덴터티를 적용하는 과정을 통해 고객이 자체적으로 보유한 인증서비스와 외부의 클라우스서비스를 연동하는 과정을 살펴보겠다.

\r\n

\r\n

구글앱스는 대표적인 SaaS 방식의 공용 클라우드 서비스로 SAML기반의 SSO 서비스를 제공한다. SAML(Security Assertion Markup Language)은 서비스 도메인간의 SSO을 가능하게 하는 XML 표준이다. 이 SAML을 이용하면 클라우드서비스 공급업체가 외부의 서비스이용기업이나 온라인 인증업체가 보유한 인증 시스템과 연합 아이덴터티 방식으로 연동할 수 있다.

\r\n

\r\n

이 연합 아이덴터티 방식으로 연동이 이루어지면 구글앱스 서비스를 받고 있는 고객은 사내에 이미 구축되어 사용 중인 인증 시스템을 통해 직접 인증을 할 수 있다.

\r\n

\r\n

그림 2에서 PINSafe 인증서버는 Swivel Secure사의 투팩터 인증 솔루션이다. 이 솔루션은 토큰디바이스를 사용하지 않는 인증 솔루션으로 보안성과 편리성을 동시에 충족시킬 수 있는 특징을 가지고 있다.

\r\n

\r\n

Pinsafe 솔루션은 XML기반의 자체 API를 보유하고 있으며, PINSafe idP는 PINSafe의 외부 애플리케이션으로 작동하고, PINSafe서버에 대해 Agent-XML 방식으로 인증을 요청한다. 또한, PINSafe idP는 SAML 규약에 따라 구글앱스와 같은 클라우드 시스템과 연동한다.

\r\n

\r\n

지금까지 살펴본 것처럼 보다 안전한 클라우드 서비스 이용을 위해서는 사용자 인증과 접근통제 권한을 서비스 이용기업의 통제 하에 두는 것이 무엇보다 중요하다. 이를 위해 사용자 크레덴셜관리는 기업 내부 인증 시스템에서 담당하고 내부 인증 시스템과 외부의 클라우드서비스를 연동하여 구성하는 것이 필요하다.

\r\n

\r\n

이 연동구성은 SAML을 근간으로 한 연합 아이덴터티(Federated Identity) 접근방식이 표준으로 자리 잡는 추세이므로 이에 대한 검토가 필요하다. 특히, 클라우드서비스에서의 사용자 인증은 패스워드 방식의 취약점을 보완하기 위해 투팩터 인증이 최소한의 표준이 되도록 할 필요가 있다.

\r\n

\r\n

구글앱스 인증과정

\r\n

▶ 먼저 사용자는 인터넷 브라우저를 이용하여 구글 애플리케이션에 접속을 시도한다.

\r\n

\r\n

▶ 구글은 SAML형식으로 인증요청을 작성하여 사용자 브라우저로 리다이렉션한다.

\r\n

\r\n

▶ 사용자 브라우저로 리다이렉션된 인증요청은 서비스 이용기업의 PINSafe 인증 시스템으로 전달된다.

\r\n

\r\n

▶ PINSafe 인증 시스템은 사용자 브라우저에 아이디/비밀번호 및 일회용 패스워드를 입력하는 창을 제공하고, 사용자에게 일회용 패스워드 생성에 필요한 난수를 발송한다. 난수 제공의 방식은 SMS, 이메일, 브라우저팝업, SW 방식등 다양한 형태를 제공한다.

\r\n

▶ 사용자는 인증 시스템이 제공한 난수와 자신이 기억하고 있는 개인 식별번호(PIN)을 이용하여 일회용 패스워드를 추출하여 입력한다.

\r\n

\r\n

▶ PINSafe 인증시스템은 사용자가 입력한 크레덴셜과 저장되어 있는 값을 비교하여 본인 여부를 판단하고 그 결과를 브라우저를 통해 구글앱스로 전송한다.

\r\n

\r\n

▶ 인증이 성공하면 구글앱스는 사용자에게 요청한 서비스 화면을 제공한다.

\r\n

\r\n

김 영 한 | 어레이 네트웍스 대표이사(young-kim@arraynetwork.net)

\r\n

\r\n

<글 : 시큐리티월드 편집팀>

\r\n

\r\n

[월간 시큐리티월드 통권 제188호(sw@infothe.com)]

\r\n

\r\n

<저작권자 : 시큐리티월드(www.securityworldmag.co.kr) 무단전재-재배포금지>

\r\n

\r\n