|
|
|
|
연합 ID관리 |
| “ID가 이동한다”… 규정 준수·보안 강화 |
 |
2007년 05월 01일 00:00:00 |
데이터넷
|
 |
|
|
‘SSO·단순화된 사용자 경험’이 원동력 … ‘불완전한 표준’ 유의해야
연합(federation)은 다중 도메인에서 권한부여 기관(authority)을 유지하기 쉽게 해준다. 하지만 이에 필수인 보안 표준들은 고르지 못한 속도로 성숙하고 있다. 이번호에서는 연합 ID 관리로 얻을 수 있는 이득과, 여기에 따르는 위험을 따져본다.
ID관리(Identity management)와 SSO(Single Sign-On) 이니셔티브는 패스워드 노동으로 힘들어하는 엔드유저에게 사랑받을 뿐만 아니라, 하나의 트랜잭션 흐름 전체에서 ID를 유지함으로써 규정준수에 도움을 주고 보안을 강화할 수 있게 해준다.
연합 부문에서의 최근의 발전들, 즉 ID와 권한부여를 포터블하게 만들어 주는 협정, 표준, 기술 덕분에 다중 도메인으로 인증을 적용시키는 데는 하드 트렉 하나도 채 들지 않는다. 하지만 계약을 하기 이전에 필수 보안 표준들은 서로 다른 속도로 성숙하고 있으며, 특히 웹 서비스 부문에서 더욱 그러하다는 사실을 알고 있어야 한다.
게다가 브라우저 기반의 애플리케이션이 계속 인기가 높아져 가고, 웹 서비스 기반 SOA가 전략적 애플리케이션 모델로 부상하는 이때에, 조직의 모든 애플리케이션 유형에 SSO를 적용시킨다는 게 얼마나 현실성이 있는지 고려해 봐야 한다. 필수 표준이 불완전하고, 기존의 표준이 보편적으로 적용되고 있지 못하고, 레거시 애플리케이션이 포함돼야 할 때에는 어떠한 새로운 전략이든 채택을 하는 게 극도로 복잡한 인프라에 소용이 된다.
연합이 시작되는 곳
몇 개의 수직 업계에서 연합에 대한 수요가 늘어가는 것이 목격되고 있으며, 이런 업계에서는 여러 기업들이 불과 일이년 전만 하더라도 한 두 개가 보통이었던 파트너 조직을 50개 이상 연합하고 있다. 그리고 이러한 얼리 어댑터(early adopter)의 전부는 아니더라도 상당수가 전용 메커니즘을 표준 기반 제품으로 대체하려 하고 있다.
나아가 통신 업계 바깥에서도 수천 만 사용자를 지원하는 연합이 등장하고 있는데, 예전에는 이런 규모의 수직 배치는 통신 업계가 유일했다. 연합 프로젝트에 대해 공개적으로 자랑하고 있는 회사들로는 아메리칸익스프레스, 보잉, 하버드대학, HP, 필립스 및 썬마이크로시스템즈 등이 있다.
정부에서도 또한 최근 몇 년 동안 연합에 막대한 투자를 하고 있다. E-오쎈티케이션(E-Authentication) 이니셔티브(미국의 E-거버먼트 중에서 연합 부분)는 아직 많은 사람들이 바라는 만큼 성공을 거두지 못하고 있지만, 하나의 전략적 목표로 연합을 만들고 있다.
연합은 또한 덴마크, 핀란드, 네덜란드, 노르웨이, 영국 및 기타 유럽 국가에서도 e-정부 활동을 위한 핵심 기술이기도 하다. 유럽 전화회사 컨소시엄인 피델리티 프로젝트(Fidelity Project)에서는 리버티 얼라이언스(Liberty Alliance) 활동을 기반으로 연합 ID관리 시스템을 계획하고 있다.
커뮤니티 연합도 또한 자동차 업계를 넘어 이동하고 있다. 물론 자동차 제조업체들은 96개 국가에서 3만 개에 달하는 공급망 업체들과 25만 명 이상의 사용자를 자랑하는 가장 성숙한 커뮤니티 연합을 운영하고 있다. 코비신트(Covisint)에서 운영하고 있는 자동차 연합 허브는 비즈니스 협정 및 SLA 관리, 400개가 넘는 애플리케이션 공유, 애플리케이션들간 SSO, 적절한 타깃으로 액세스 요청 라우팅, 그리고 커뮤니티에서의 액세스 프로비저닝 등과 같은 수많은 혜택을 제공하고 있다.
써드파티 중개업자로 하여금 트러스트 협정(trust agreement) 중개, 메시지 라우팅 및 프로토콜이나 주장 번역 문제를 해결하는 등의 복잡한 일을 처리하게 방식이 좋다는 사실을 깨닫고 있는 업계도 있다. 예를 들어 2006년 7월 버튼 그룹 카탈리스트 컨퍼런스(Burton Group Catalyst Conference)에서는 에너지 업계에서 그 프로그램을 논의했는데, 이것은 현재 소수의 참가자들과 함께 파일로트 단계에 들어갔으며 올 하반기 생산 배치가 이뤄질 계획이다.
연합은 또한 2006년 RSA 보안 컨퍼런스 기조연설에서 빌 게이트의 든든한 지지를 받은 개념이기도 하다. 게이츠는 이 자리에서 트러스트 생태계가 성공하기 위해서는 이것이 “전체적으로 연합돼야(totally federated)한다”고 강조했다. 그는 또 연합은 다중 ID 시스템이 상호 운용될 수 있는 ID 메타시스템에서 핵심 컴포넌트라고 덧붙였다.
이는 연합이 마이크로소프트의 제품 계획에서 큰 자리를 차지하고 있기 때문에 당연한 일이기도 하다. 지난 해 도입된 ADFS(Active Directory Federation Services)는 WS-피더레이션을 기반으로 하며, 마이크로소프트는 롱혼 서버가 출시될 즈음에 WS-트러스트를 지원하는 모듈을 발표할 계획이라고 발표했다.
두 표준 이야기
분명히 연합이 지지자들이 기대하는 만큼 퍼져 나가려면 표준화가 필수다. 그리고 사실 ID 연합용의 표준과 사양은 비교적 성숙한 상태인 데 반해 불행히도 웹 서비스 보안 표준 개발은 완전히 얘기가 다르다.
지난 2002년 IBM, 마이크로소프트 및 그 파트너들은 보통 WS-*라고 부르는 웹 서비스 보안에 대한 비전을 소개했다. 여기에는 웹 서비스를 안전하고, 조합 가능하며, 상호운용이 되는 것으로 만들기 위한 수많은 프로토콜과 사양이 포함됐다. 2004년 4월에 발표된 최초의 WSS(Web Services Security) 버전은 메시지 보안과 ID 토큰의 기본에 대해 다뤘다.
하지만 WS--트러스트, WS-시큐리티폴리시 및 WS-시큐어컨버세이션(WS-Trust/SecurityPolicy/Secure Conversation)의 핵심 컨포넌트들이 새로운 오아시스 WS-SX(OASIS Web Services Securie Exchange) 기술 위원회로 제출된 것은 2005년 10월이 돼서였다. WS-SX의 1.0 버전은 올해 중순에나 출시될 전망이다.
하지만 연합 커뮤니티에서는 정반대의 문제를 갖고 있었다. 즉 SSO, 계정 연결 및 기타 브라우저 기반 애플리케이션 문제를 해결해주기 위해 수많은 표준과 사양들이 쏟아져 나온 것이다. 이 업계는 SAML(Security Assertion Markup Language) 1.0, SAML 1.1, 리버티 ID-FF 및 쉽볼렛(Shibboleth) 같은 대안들을 시험해 본 후 SAML 2.0과 FS-피더레이션을 중심으로 통합을 시켰다.
SAML 2.0을 기다리며 배치를 미뤄온 기업들은 이제 이동을 시작했으며, 이 표준의 최신 버전은 상용 제품에서 보다 널리 사용 가능해지고 있다. <그림: 연합 제품 시장 구분>은 브라우저 연합 툴 시장이 어떻게 나눠져 있는지를 보여주고 있다. 대부분의 업체들이 기존의 웹 액세스 관리 제품에 연합 기술을 추가하거나, 스탠드얼론 연합 제품을 만들고 있다.
이중 전략을 채택하면서 두 가지 부문의 제품을 모두 제공하는 곳은 몇 되지 않는다. 그리고 XML 보안 어플라이언스와 같이, 브라우저나 웹 서비스 표준 영역을 지원하는 또다른 제품 범주들도 많다는 사실을 명심해야 한다.
결론적으로 말하자면, 웹 서비스와 브라우저 애플리케이션을 통합하기는 아직 쉽지 않다. IT 그룹은 움직이는 표준의 바다를 항해할 준비를 해야 하며, 히긴스(Higgins)와 카드스페이스(CardSpace) 같은 새로운 프레임워크들에 뒤처져서도 안 된다.
협업 조직의 사용자가 파트너 사이트에 있는 애플리케이션에 액세스를 해야 할 경우, 연합은 보안 도메인들에서 SSO를 지원함으로써 관리적 부담 줄이고 공유 가능한 인프라 서비스를 제공한다. 하지만 연합 표준은 일부 ID관리의 책임을 파트너들간에 전가시키기도 한다는 사실을 명심해야 한다. 거듭 강조하지만 책임과 의무를 확립하는 비즈니스 협정이 무엇보다 중요하며, 이것은 연합에 대한 신뢰와 확신을 확립하는 기반이라고 할 수 있다.
연합이 좋은 이유
연합을 이행해야 하는 많은 이유가 있지만, 다중 보안 도메인을 내비게이팅할 때 SSO를 통해 사용자 이름과 암호 조합을 줄일 수 있다는 게 가장 자주 언급된다. 파트너 사이트로 액세스하기 앞서 사용자를 등록하는 것도 연합을 통해 치료될 수 있는 또 하나의 번거로운 프로세스다. 기업들은 사용자가 처음 파트너 사이트에 액세스하기 이전에 필요한 속성을 프리로딩(preloading)함으로써 등록 단계를 우회하게 해줄 수 있다.
비용 절감효과도 또한 연합을 이끄는 큰 힘이 된다. 다중 조합과 애플리케이션을 수용할 수 있는 표준화되고 재활용이 가능한 인프라가 전용의 하나를 위한 다중 시스템보다 언제나 나은 법이기 때문이다. 앞서도 언급한 것처럼 우리는 연합 서비스를 이용해 50개 이상의 엔티티와 접속하는 기업을 본 적도 있다.
연합은 완전히 별개의 프라이버시 보존 기능들을 이행할 수 있는 프레임워크를 제공하며, 이는 특히 리버티 얼라이언스에서 개발하고 현재 SAML 2.0에 포함된 연합 사양들에서 더욱 두드러진다. 연합은 조직들간에 공유되는 개인적인 정보의 양을 제한함으로써 프라이버시 법률이나 규정을 위반하지 않도록 하는 데 사용될 수 있다. 게다가 사용자들에게는 파트너 사이트와의 특정 상호작동을 위한 ID 속성을 공유하는 데 대에 얼마간의 제어권이 주어질 수 있다.
뒤떨어진 보안
물론 어디에나 함정은 있다. 웹 서비스는 비록 기업이 상호운용이 가능한 서비스 기반의 애플리케이션을 어떤 플랫폼에서 어떤 언어로든 만들 수 있게 해주지만, 웹 서비스 프레임워크의 원래 정의에는 빌트인 보안 모델은 포함돼 있지 않았다. 초기 이행자들은 서비스 종단지점간 커뮤니케이션을 보호하기 위해 SSL을 사용함으로써 보충을 할 수 있었지만, SSL은 보다 선진적인 웹 서비스 시나리오에 요구되는 정밀성과 유연성을 제공하지 않는다.
SSL이 부적절할 경우 이행자가 해야 할 일은? WS-시큐리티, 즉 WSS가 얼마간의 위안이 될 수 있다. 오아시스 WSS 기술위원회는 SOAP(Simple Object Access Protocol) 메시지와, SOAP 메시지 보안을 위한 핵심 사양과, 사용자나 서비스 ID정보를 통합시키기 위한 몇 가지 익스텐션을 규정 및 표준화했다.
예를 들어 WSS 프로파일은 SAML 토큰을 웹 서비스 요청에 어떻게 통합시키는지를 규정한다. 이것은 서비스 계정을 중개자로 사용하는 대신, 요청자의 ID가 트랜잭션 플로 전체에서 계속 사용될 수 있게 해준다.
WSS 프로파일의 이러한 특성은 애플리케이션 환경의 감사 능력을 강화시키면서 동시에 사용자를 위한 SSO를 보존할 수 있다.
WSS 보안 제품들
ID관리 정보를 웹 서비스 요청 안에 보관하는 데 WSS가 필요하다고 한다면 과연 어떤 제품으로 이것이 가능해질 수 있을까? 불행히도 미성숙한 표준과 시장의 분할로 이 질문에 속시원히 할 수 있는 대답은 없다. 너무도 많은 제품들이 WSS 프로파일이나 다른 연합 프로토콜의 일부, 혹은 대부분을 지원한다. 이 시장이 어떻게 분할돼 있는지를 나타내기 위해, 버튼 그룹에서는 업체들을 다음과 같은 6가지 범주로 분류했다.
>> 웹 서비스 플랫폼에는 BEA 웹로직(WebLogic), IBM 웹스피어(WebSphere), 오라클 애플리케이션 서버(Oracle Application Server), SAP 넷위버(NetWeaver) 등이 포함된다.
>> WSS 라이브러리는 웹 서버 플래솜과 통합이 되는 API나 툴키트를 제공하며, 아파치디지털(ApacheDigital), RSA시큐리티(현재 EMC 소속), 썬마이크로시스템즈 및 베리사인(VeriSign) 등에서 내놓고 있다.
>> 웹 서비스 관리 제품은 웹 서비스 환경에 배치되어 정책 시행 지점의 역할을 한다. 이 부문의 업체들로는 액셔널(Actional), 앰버포인트(AmberPoint), HP, 오라클 및 SOA 소프트웨어가 있다.
>> XML 보안 게이트웨이는 보통 어플라이언스로서 패키징되며, WSS 지원을 포함한 다양한 보안 특성을 갖고 있다. 이 부문의 업체들로는 시스코시스템즈, 포럼시스템즈, IBM, 인텔, 레이어세븐테크놀로지스, 리액티비티(Reactivity) 및 보델(Vordel) 등이 있다.
>> XML VPN은 웹 서비스 클라이언트에 통합, 혹은 임베딩될 수 있으며, 레이어세븐과 SOA 소프트웨어에서 내놓고 있다.
>> 웹 서비스 SSO와 연합; CA, 인트러스트(Entrust) 및 IBM 같은 일부 웹 액세스 관리 업체들은 WSS를 지원하도록 각자 제품을 확장시켰다.
웹 서비스 보안 시장에서는 이미 상당한 양의 통합이 이뤄지고 있으며, 웹 서비스 배치가 늘어나고 수요가 상승하면서 향후 2년 내에 더 많은 인수 합병이 있을 것으로 예상된다. 그리고 WS-SX가 여기에 뛰어들 준비를 갖춤으로써 혼란의 양상은 더욱 심화될 것 같다.
오아시스 WS-SX
WS-트러스트(Web Services Trust) 사양은 WSS를 기반으로 하며, 신용 관계를 평가하고 중개하기 위한 메커니즘과, 보안 토큰의 발급, 갱신 및 검증 방안을 규정함으로써 ID관리를 더욱 발전시켰다. 하지만 연합과, SSO 및 웹 서비스 메시지 보안에 관한 WSS는 브라우저나 웹 서비스 애플리케이션에게 있어 보안 표준의 전체 스펙트럼을 지원하지 못한다.
퍼즐의 또 다른 조각은 오아시스 WS-SX 기술위원회다. WS-SX는 2005년 결성됐으며, 버전 1.0이 올 하반기 발표될 예정이다. WS-SX 작업에는 세 가지 사양이 포함돼 있다.
우선 WS-트러스트는 WSS를 기반으로 보안 토큰을 발급, 갱신 및 검증하는 방식뿐만 아니라, 신용 관계를 평가 및 차단하는 메커니즘을 규정한다. WSS와 마찬가지로 WS-트러스트는 X.509 공중 키 인증, SAML 어서션(assertion), 권한 표기 언어 라이선스, 커버로스 공유-비밀 티켓, XCBF(XML Common Biometric Format) 객체, 심지어 암호 요약 등과 같은 기존의 기술을 이용할 수 있게 해준다.
WS-트러스트는 IT에서 다양한 보안 메커니즘을 이행할 수 있게 이용 가능한 확장성 있는 프레임워크와 유연한 신택스를 규정한다. WS-트러스트는 WSS를 기반으로 하기 때문에 STS(Security Token Service)를 만드는 데 대한 사양을 규정함으로써, 신임(credentiaing)을 통해 트러스트를 중개할 수 있는 능력을 지원한다.
STS는 트러스트 도메인 안에서, 그리고 이들에 걸쳐 사용될 수 있으며 이질적인 이행들을 지원하는데, 그 이유는 이것이 다양한 토큰을 발급할 수 있으며 이런 토큰은 서로 다른 도메인에서 트러스트 관계를 중개하는 데 사용되기 때문이다. 이러한 유연성은 토큰 서비스가 직접 트러스트, 직접 중개 트러스트, 호은 간접 중개 트러스트가 존재하는 상황을 지원할 수 있게 해준다. 하지만 WS-트러스트는 그 이름과 걸맞지 않게 트러스트 관계 자체를 수립하고 해지할 수 있는 서비스와 프로토콜은 제공하지 않는다.
WS-시큐어컨버세이션(WS-SecureConversation)은 메시지 부결성, 기밀성 및 인증에 대한 증명서를 사용함으로써 공유 보안 컨텍스트를 만들어 낸다. 공유 보안 커뮤니케이션은 메시지가 상호교환되는 수명 동안 수립이 된다.
마지막으로 WS-시큐리티폴리시(WS-SecurityPolicy)는 정책 어서션을 위한 프레임워크다. 이것은 WSS가 정한 포맷에 대해 조건과 규제를 부과하며, 상호 교환되는 메시지가 정책에 부합되는지 검토될 수 있게 해준다.
WS-SX는 아직 공식적으로 표현화되지는 않았지만, 일부 업체들은 현재 제품에서 일부, 특히 WS-트러스트를 이행하고 있는데, 이러한 업체들로는 IBM, 메모리엑스퍼츠(Memory Experts), 그리고 핑아이덴티티(Point Identity)가 포함된다. 크레덱스(CredEx), 히긴스, 프로젝트탱고(Project Tango) 등의 오픈 소스 프로젝트들도 또한 WS-트러스트를 지원하고 있거나 지원할 계획이다.
균형 잡기에 주력해야
연합 ID관리가 작동하도록 하는 데는 민감한 균형잡기 작업이 필요하며, 이는 특히 브라우저 연합에서부터 WS-SX 같은 여러 가지 표준과 기술들이 진화하고 있기 때문에 더욱 그러하다. 다행히도 SAML 같은 표준이나 WS-피더레이션 같은 사양을 기반으로 하는 연합 ID관리는 기존 파트너들간의 전용 인증 시스템을 대체할 만큼 충분히 성숙하며, 덕분에 삶은 조금 더 편안해진다.
우리들 가운데 낙관주의자들은 긍정의 힘이 들어맞는 것을 목격하게 될 것이다. 브라우저 연합 표준은 SOA 개념에 뿌리를 둔 마찬가지로 느슨하게 결합된 모델을 따르기 때문에, 연합 이행은 브라우저와 웹 서비스 하이브리드 상황을 연결할 수 있으며, WS-SX용 버전 1.0 표준을 마무리하기 위해 표준 개발쪽에서 진척이 이뤄지고 있다. 따라서 우승의 문턱에서 결코 눈을 돌려서는 안 된다. 경쟁에서 뒤쳐지지 않기 위해 IT는 시장 상황을 계속해서 평가하고, 페이스에 맞춰 아키텍처 목표를 조종해 나가야 한다.
FYI
ASP 수가 늘어나면서 연합의 기회도 함께 늘어나고 있다. 하지만 대부분의 애플리케이션 서비스 사업자는 오늘날의 기술을 지원하지 않는다. 대신 아웃소싱 서비스 사용자는 전형적으로 외부 애플리케이션으로의 액세스를 위해 완전히 다른 사용자 이름-암호 조합을 입력하도록 요구받는다. 그런 다음 기업에서는 접속에서 SSO를 지원하기 위한 전용 메커니즘을 이행한다. 하지만 이런 상황은 이제 달라질 것이다. 버튼 그룹에 따르면, 보다 쉽고 비용 효과적으로 엔터프라이즈 고객과 접속할 수 있게 해주는, 표준 기반의 공유되고 재활용 가능한 인프라의 가치를 인식하는 ASP가 늘어나고 있기 때문이다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
