지난 한 달 동안 회사의 헬프데스크에서는 패스워드 재설정을 위해 몇 통의 전화를 받아야 했는가? 특별한 경우가 아니라면 그 통화의 20~50%는 패스워드 재설정 때문에 하게 된다(각 통화 건당 평균 25달러). 특정 자원으로 새로운 권한이 필요한 사용자와, 최고의 고객과 파트너들에게 맞춤화된 액세스를 제공하고자 하는 조직의 욕망을 더하면, IAM(Identity and Access Management)의 시간 소모적이고 비용이 많이 드는 프로세스와 직면해야 할 상황에 놓이게 된다.

몇 년 전까지만 해도 계정 및 웹 액세스 제어의 문제를 해결하고 그 혜택을 실감하기 위해서는 여러 업체의 제품들을 구입해야 했다. 하지만 이제 시대는 통합을 요구하고 있으며, 업체들은 두 가지 기술을 하나의 패키지에 담아 내고 있다.
그리고 새로운 전문 용어로 FIM(Federated Identity Management)이라는 것이 있는데, 이것은 조직들이 계정을 관리하고, 외부 구성원들에게 보안의 제어되는 액세스를 제공할 수 있게 해준다. FIM은 아직 초기 단계로 표준이 만들어지고 있는 중이다. 제 1세대 FIM 기술이 여러 IAM 패키지에 통합돼 있긴 하지만 성숙하기까지는 아직 더 기다려야 할 것 같다.
이런 부분들이 함께 얼마나 잘 돌아가는지를 보기 위해 우리는 10개 업체들을 리얼월드 랩으로 초대해 제품을 보내도록 했다. 우리가 찾는 패키지는 정교한 역할 기반 웹 인증 및 권한부여, 싱글사인온, 디렉토리 저장소 통합 및 포괄적인 로깅/감사 기능을 제공하는 것들이었다. 게다가 제품이 계정관리 컴포넌트를 갖고 있거나 혹은 계정관리를 제공하는 다른 제품들과 함께 작동하기를 바랬다. 제품들의 평가는 성능과 가용성, 관리 및 구성의 편이, 가격, 보안 아키텍처, 그리고 다양한 웹 서버 및 디렉토리 저장소와의 통합을 기반으로 이루어졌다.
우리의 필요조건을 충족시킨 제품들을 가진 업체들 가운데, 엔티그리티 솔루션즈(Entigrity Solutions), HP (Hewlett-Packard), 네티그리티(Netegrity), 노벨 및 RSA 시큐리티가 테스트 과정을 통과하게 됐다. 오픈네트웍스(Open Networks)와 오블릭스(Oblix)는 초청을 수락하긴 했지만, 상세한 테스트 계획을 읽고 난 후 포기했다. 오블릭스는 자원 부족을 이유로 들었으며, 오픈네트웍스는 이번 리뷰가 자사의 전략과 맞지 않는다고 말했다. 인트러스트(Entrust)는 참가할 만한 자원이 없다고 말했으며, 썬은 최근 웨이브셋(WaveSet)을 인수했으며, 수준 높은 리뷰에 참가시키기 이전에 이 회사의 제품을 IAM에 통합시키는 데 시간이 더 필요한 것 같다고 정중히 거절했다. 반면 IBM은 간단히 초대를 거절했다.

복잡한 이행 과정
IAM 이행에는 소프트웨어를 구매하고 이것을 설치하는 데 며칠을 비워놓는 것 외에 더 많은 일이 포함된다. 여기에는 막대한 계획 작업이 필요하며, 아마도 컨설턴트가 필요할 것이다. 수집해야 하는 자원 및 계정 저장소 정보들을 얼마간 1부에서 소개한 바 있다. 테스트한 모든 제품들은 수천 명의 동시 사용자들용으로 잘 확장되었으며, 모두가 대다수의 기업용 필요를 충족시켜 줄 것이다. 따라서 주요 변수는 제품의 사양과 사용 편이가 되었다.
모든 제품은 사용자당으로 가격이 책정돼 있으며, 대부분이 최소 1천명의 사용자를 필요로 한다. 사용자당 가격은 20~50달러 범위지만, 숨겨진 비용도 생각해야 한다. 모든 업체들은 컨설팅 서비스를 추천하고 있기 때문이다. 글로벌 IAM 컨설턴트는 우리에게 IAM 이행에 보통 6개월이 걸리며, 규모가 큰 조직에서는 1년 이상이 걸릴 수도 있다고 말했다.
역 프록시 모드(reverse-proxy mode)만을 제공하는 노벨은 예외로 하고, 다른 모든 업체들은 에이전트와 프록시 방안을 둘 다 제공하고 있다. 에이전트를 이행하기 위해서는 보통 IAM 인프라의 일부가 될 각각의 웹 서버에 ISAPI/NSAPI 필터를 설치한다. 장기적으로 볼 때는 에이전트 방안에 별도의 유지보수 작업이 필요하게 되겠지만, 이것은 보다 정밀한 제어를 제공할 것이다. 반면 역 프록시는 클라이언트와 웹 서버 가운데 놓이며, 어떠한 서버 변경도 필요로 하지 않는다. 오래된 버전이나 지원되지 않는 플랫폼과 같이, 그 웹 서버용으로 업체에서 웹 에이전트를 제공하지 않는 곳에서는 이것이 좋은 선택이 될 수 있다.
네트워크 구성상의 변경이 필요하다는 것 외에도, 중복/부하조절 아키텍처를 사용하지 않을 경우 역 프록시에서는 성능이 문제가 될 수 있는데, 그 이유는 모든 트래픽이 많은 서버에 분산되는 게 아니라 프록시를 통해 라우팅되기 때문이다.

참가 제품들
HP는 2003년 발티모어 테크놀로지스(Baltimore Tch nologies)의 실렉트 액세스(Select Access) 계정관리 제품을 확보한 이래 IAM 시장의 주 사업자로 부상했다. 실렉트 액세스는 이번 리뷰에서 근소한 차로 2위를 차지한 노벨을 젖히고 에디터즈 초이스를 수상했다. 이 제품은 따라올 자가 없는 막강한 사양과 관리 인터페이스를 제공한다. 대부분의 제품들에서 우리는 작업을 구성하고 이행하느라 며칠을 보냈으며, 실렉트 액세스의 경우 이것은 신속하고 간편했다.
노벨의 패키지는 포괄적인고 강력하긴 했지만, 다중 노벨 제품들이 필요했으며 노벨 제품을 쓰지 않는 곳에서는 큰 도전이 될 것이다. 노벨 IAM 설치를 유지보수하는 데는 몇 명의 관리자가 필요하기 때문이다. 반면 RSA의 클리어트러스트(ClearTrust)는 사용이 간편하며 손대기 좋아하는 프로그래머가 있는 조직에는 잘 맞을 것이다. 하지만 클리어트러스트에는 기업 IAM 스위트에 있는 대부분의 핵심 기능들이 있음에도 불구하고 다중 계정 저장소에 대한 아웃 오브 더 박스 지원이 없는데, 이것은 특히 클리어트러스트가 값이 비싼 편에 속하기 때문에 조직에서는 실망이 될 것이다.
엔티그리티의 어슈어액세스(AssureAccess)는 그리 인상적이지 못했다. 이 제품은 최신 OS나 웹서비스를 지원하지 않으며, 경쟁 제품에 있는 많은 기능들이 빠져 있었는데, 특히 패스워드 재설정과 같이 비용을 절감해 주는 사용자 셀프서비스 기능들이 아쉬웠다.

HP
오픈뷰 실렉트 액세스 6.0

실렉트 액세스는 우리가 바라는 모든 IAM 기능들을 관리 및 지원하기에 간편했다. 우리는 실렉트 액세스의 셋업 툴을 이용해 보호하고자 하는 모든 웹 서버에 에이전트 플러그인을 설치했다. 테스트한 다른 제품들과 달리 실렉트 액세스는 자체 역 프록시 서버를 제공하지 않았지만, 써드파티 제품을 지원하고 있다. 실렉트 액세스는 관리 서비스를 이용해 정책을 설정 및 저장하며, 검증 서비스(validator servie)를 이용해 관리자와 사용자를 인증한다. 단일 관리 서비스를 설정하는 게 보통이지만 여러 검증기를 설정해 주 서버에 오류가 난 경우 중복성을 제공할 수 있었다.
실렉트 액세스의 관리는 관리 사이트로 로그온을 했을 때 웹 브라우저에서 띄워지는 자바 GUI인 폴리시 빌더(Policy Builder)를 이용해 수행했다. 이 인터페이스는 우리가 살펴본 것들 가운데 최고였다. 사용자와 자원의 조직화된 트리들간에 관계를 매핑하기 위해 시각적인 정책 척도를 이용하기도 간편하고 직관적이었다.
사용자 트리에서는 액티브 디렉토리와 썬 원 디렉토리(Sun One Directory)를 쉽게 추가했다. 각각의 디렉토리 안에서 우리는 사용자와 그룹, 역할들을 보았다. 새로운 역할을 만들어내기는 디렉토리에서 오른쪽 클릭을 하고 역할을 규정하는 사용자 속성을 고르기만 하면 되는 간단한 일이었다. 예를 들어 우리는 역할을 설정해 10만달러 이상의 매출을 예약한 사용자들이 자원으로의 액세스를 가지도록 했다. 적절한 하이콘을 도표로 드래그 앤 드롭한 다음 이들의 값을 구성함으로써 맞춤 규정을 만들 수 있었다. 이러한 아이콘들은 네트워크 어드레스, 날짜, IP 어드레스, 포트, 속성 및 암호화 수준 등 보통의 사양들을 나타내는 것들이다. 셀프 서비스를 셋업하기가 간단해져서, 사용자가 편집을 할 수 있게 허용되는 속성들을 간단히 지정할 수 있었다.
실렉트 액세스에는 사용 가능한 자원과 서비스를 이용해 자원 트리 목록을 파퓰레이팅하는 네트워크 탐색 툴이 있다. 처음에는 이것이 매우 유용하리라고 생각했지만, 기업에서 이 제품을 사용해 본 컨설턴트는 수백, 혹은 수 천 가지 자원에서는 그다지 쓸모가 없다고 설명했는데, 그 이유는 이것이 관리자가 원하는 것처럼 디렉토리와 파일을 그루핑하는 게 아니라 모두를 리스팅하기 때문이다.
이 트리에는 또한 관리 가지(admini strative branch)가 있어 우리가 정책 그리드를 효율적으로 사용해서 사용자나, 그룹, 혹은 역할들에게 권한을 할당할 수 있게 해준다. 이 가지는 속성, 기능, 네트워크 관리 및 사용자 관리를 리스팅하며, 어떠한 조합으로든 이런 모든 작업들에 대한 관리 권한을 위임할 수 있게 해준다.
디폴트로, 모든 사용자는 부모 객체로부터 자신들의 허가(permission)를 상속받는다. 예외나 특별 케이스를 만들기 위해 우리는 그룹 뷰를 이용해 원하는 사용자를 로케이팅하고, 그리드에 있는 박스를 간단히 체크했다. 수천 가지 자원과 사용자가 있는 그리드는 읽기 힘들 수도 있지만 인프라에 대한 완벽한 개략도를 제공한다.

노벨
아이체인 2.3

노벨의 아이체인(iChain)은 테스트한 제품들 가운데 총체적인 제품이라고 부르고 싶은 유일한 제품이었다. 여기에는 계정 저장, 계정관리 및 액세스 제어가 모두 포함돼 있다. 우리가 설치한 시스템은 아이체인을 이용해 우리 웹 자원으로의 액세스를 제어하면서 동시에 DirXML을 이용해 우리의 모든 데이터 저장소들을 통합시켰다.
관리는 아이매니저(iManager)와 콘솔원(ConsoleOne)을 통해 수행됐으며, e디렉토리(eDirectory)는 사용자와 구성 정보를 위한 중앙 데이터 저장소로 작동했다. 다른 업체들도 랩으로 기술자를 보내긴 했지만, 노벨은 위 제품들에 각각 한 명의 전문가를 붙여 네 명을 보내주었다. 이것은 결국 앞으로 다가올 일을 예고한 것과 마찬가지였는데, 노벨 제품은 언제나 우리가 바라던 대로 작동하지 않았을 뿐만 아니라 하나의 전체로서 작동하지 않았다.
그 이름에서 알 수 있는 것처럼, NDS e디렉토리는 하나의 디렉토리 서비스다(원래 NDS 는 네트웨어에서 분리된 것이다). 사용자 데이터를 저장하는 것외에도, 이 제품은 애플리케이션에 대한 정보, 네트워크 장비, 그리고 DirXML용 구성 정보 등을 관리할 수 있다. e디렉토리는 LDAP를 지원하며, 수백만 개의 객체를 저장하도록 확장된다. e디렉토리를 셋업한 후 우리는 모든 사용자를 액티브 디렉토리로부터 임포팅했다. 여기서 디렉토리 저장소를 바꿀 필요만 없었다면 좋았겠지만, DirXML 컴포넌트는 우리로 하여금 이러한 계정을 e디렉토리로 포팅할 것을 요구했다.
조직들로서는 자신들의 모든 계정을 하나의 저장소에 둘 수 있는 행운을 충분히 누릴 수 있으며, 이것이 바로 DirXML이 편리한 부분이다.
DirXML 통신 드라이버를 사용하면 e디렉토리와 기타 애플리케이션들(SAP, 피플소프트, 로터스 노츠, 마이크로소프트 익스체인지, 마이크로소프트 SQL 서버 및 액티브 디렉토리)간의 데이터를 공유하고 동기화할 수 있을 것이다. e디렉토리는 여전히 마스터 디렉토리로 남아서 다른 것들과 동기화를 하지만, 이렇게 되려면 데이터가 마스터 디렉토리 안에 있어야 한다.
드라이버는 어떠한 신분증명서 저장소에서 데이터 변화가 언제 발생하는지를 알려주고, 구성 가능한 필터와 정책을 통해 이러한 정보를 저장소들간에 전파해 준다. 필터는 어떤 정보가 사용될 것인지를 알리며, 정책은 그러한 정보로 어떤 작업이 수행돼야 하는지를 가리킨다. 변화가 e디렉토리에서 발생하면, 우리 정책은 액티브 디렉토리와 SQL 서버로 변화를 전파시켰다. 하지만 이 정책은 액티브 디렉토리나 SQL 안에 있는 패스워드 상의 변화가 e디렉토리에 있는 값에 의해 덮어 씌워졌다고 진술했다.
DirXML은 노벨의 웹 관리 콘솔인 아이매니저(iManager)를 통해 구성된다. DirXML용 인터페이스는 드라이버, 필터 및 정책의 시각적 상징들로 구성돼 있다. 이들을 클릭하면 적절한 구성 양식이 뜬다. 인터페이스는 많은 훈련이 필요없이 간단한 옵션들을 충분히 구성하고 편집할 수 있을 정도로 사용자 친화적이었지만, 인프라를 설치하고 유지보수하는 일은 만만치가 않다.
DirXML은 매우 강력하며, 우리는 다른 업체들이 이것을 자신들의 제품에 통합시킬 수 있으리라 희망한다. 하지만 현재 DirXML은 e디렉토리와만 사용이 가능하다. 아마도 노벨에서 제품의 잠재력을 깨닫고 이것을 써드파티 통합용으로 개방할 날이 올 것이다.
정책을 설정한 다음에는 액세스 제어용으로 사용되는 역 프록시 서버인 아이체인으로 옮겨갔다. 앞서 언급한 것처럼 노벨은 하나의 에이전트 모델이 아니라 역 프록시 서버를 이용하는 유일한 제품이다. 우리는 아이체인 프록시 서버를 통해서만 보호되는 자원으로의 액세스를 허용하도록 네트워크를 재구성해야 했는데, 이는 크고 복잡하거나 분산된 기업 환경이라면 매우 어려워질 수도 있는 일이다. 아이체인 서버를 설치 및 가동시키기 위해서는 인증 서버의 로케이션과 아이체인용 구성 파일인 ISO(iChain Service Object)를 입력하기만 하면 됐다. ISO에는 보호돼야 할 자원에 대한 정보와 그러한 자원들로의 액세스를 허용하기 위한 규정이 포함돼 있다.
ISO는 e디렉토리에 저장이 되며, 우리는 콘솔 원용 아이체인 스냅인을 사용해 IIS와 아파치 웹 서버용으로 ISO를 셋업 및 구성했다. 그리고 정적이거나 동적인 ACL을 설정함으로써 다양한 자원으로의 액세스를 허가 및 거부했다. 역동적 리스는 e디렉토리 내의 사용자 속성 값을 기반으로 할 수 있다. 한 곳에서 모든 구성을 허용할 수 있게 될 아이매니저를 아이체인에 통합시키기를 노벨에게 바라는 바다.

RSA 시큐리티
클리어트러스트 5.5.2

클리어트러스트는 세 가지 컴포넌트, 즉 디스패처(dispatcher), 권한부여(authorization) 및 인타이틀먼트(entitlement)로 구성된 에이전트 모델을 이용함, 이들은 모두 하나의 서버에서 실행된다. 권한부여 서비스는 정책 의사결정을 만들며, 인타이틀먼트 서비스는 신원증명서 저장소로 인터페이스를 제공하고, 디스패처는 컴포넌트들간의 세션 키를 관리한다.
보통의 경우에는 사용자가 보호되는 자원으로 액세스를 시도할 때 에이전트가 사용자가 로그인이 됐는지 여부를 확인한다. 로그인 되지 않았을 경우에는 로그인 양식이 보여진다. 일단 사용자가 로그인이 되면 에이전트는 권한부여 서비스로 연결돼 사용자가 자원으로의 액세스를 허가받았는지 확인한다. 권한부여 서비스가 이 정보를 캐시에 보관하고 있다면 이것은 에이전트에게 직접 적절한 허가를 돌려준다. 그렇지 않을 경우 권한부여 서비스는 인타이틀먼트 서비스와 통신을 하며, 인타이틀먼트 서비스가 계정 저장소로부터 정보를 끌어 온다.
우리는 제한된 액세스가 필요한 각각의 RSA 클리어트러스트 에이전트를 설치했다. IIS에서 에이전트는 하나의 ISAPI 필터로 이행됐으며, 이것은 테스트한 다른 대부분의 제품들에서도 마찬가지였다. RSA는 대부분의 일상적인 웹서비스를 지원하며, 지원되지 않는 서버는 RSA의 역 프록시 서버인 클리어트러스트 ACM(Access Control Module)을 통해 액세스를 제공함으로써 보안될 수 있다.
노벨의 아이체인과 달리, 클리어트러스트는 아웃 오브 더 박스로 다중 계정 저장소를 지원하지 않는다. RSA에서는 조직에서 그 계정을 한 곳에 모아둘 것을 추천하고 있다. 이것이 아마도 가장 좋긴 하겠지만, 사실상 이렇게 하지 못하는 기업들이 많다. RSA는 클리어트러스트가 여러 개의 서로 다른 디렉토리들간에 계정을 관리하는 데 초점을 두고 있지 않다고 말했다. 이것이 조직에서 필요로 하는 것이었다면 아마도 써드파티와 협동해 이 컴포넌트를 제공했을 것이라는 얘기다. RSA의 계정 애플리케이션은 셀프 서비스, 자가 등록 및 패스워드 재설정을 제공하지만, 이것 또한 이 회사의 핵심 기술은 아니다. 그보다 RSA는 쏘어 테크놀로지스(Thor Technologies)와의 파트너십을 통해 이러한 사용자 관리 기능을 확보하고 있다.
클리어트러스트의 관리 인터페이스는 웹 기반이며, BEA 웹로직(BEA WebLogic)이나 톰캣(Tomcat)에서 실행된다. 주로 자원, 관리자, 사용자 및 인타이틀먼트로 구성돼 있는 이 인터페이스는 직관적이고 잘 짜여져 있어 우리가 사용자를 선택하고 이들에게 쉽게 자원으로의 액세스를 허가할 수 있게 해주었다.
우리는 또한 할당된 역할뿐만 아니라 사용자 속성을 기반으로 액세스를 역동적으로 제공할 수 있게 해주는 RSA ‘스마트 룰(smart rules)’도 사용했다. MS SQL 저장소에 있는 정보를 기반으로 액세스를 허용해 줄 맞춤 확장 모듈을 만들려는 시도는 제품에 할당된 한정된 시간 때문에 성공하지 못했지만, 적당한 컨설턴트나 프로그래머만 있다면 클리어트러스트는 고도의 맞춤화가 가능하며, 자바, C, DCOM, JAAS, XML, SOAP 등 300개에 달하는 API를 자랑한다. 이것은 단일 계정 저장소만을 사용하거나, 자신들의 정보를 통합하고자 하는 조직들에게는 셀링 포인트가 되지 못할 것이다. 하지만 몇 개의 계정 저장소를 사용하는 회사라면 얼마간의 액세스 제어 문제를 처리하도록 프로그래머를 둘 필요가 있을 것이다.
또 한 가지 클리어트러스트에서 두드러진 점은 위임 관리와 연방제 계정관리다. 위임을 위해 우리는 분산된 관리자들에게 적용될 역할을 만들었다. 그리고 역할을 이용해 관리자에게 다른 관리자와 사용자, 그룹, 애플리케이션, 서버, 패스워드, 역할 및 특성 등을 추가, 편집, 혹은 삭제할 수 있는 권한이 있는지 여부를 지정했다.
클리어트러스트의 연방제 계정관리 컴포넌트를 사용해 어떠한 테스트도 수행하지는 않았지만, 이 제품은 최신 SAML 표준을 지원한다. 마지막으로 클리어트러스트의 리포팅은 CSV 파일의 익스포팅을 허용하는 것으로 구성돼 있어 그다지 흥분할 만큼은 되지 못했다. 클리어트러스트에게는 보다 상세한 보고서 옵션이 필요해 보였다.

네티그리티
사이트마인더 6.0 & 아이덴티티마인더 웹 5.6

사이트마인더(SiteMinder)와 아이덴티티마인더(IdentityMinder)는 함께 완벽한 IAM 패키지를 제공한다. 사이트마인드는 네티그리티의 액세스 제어 제품인 반면, 아이덴티티마인더는 계정관리용으로 사용된다. 테스트한 대부분의 제품들과 마찬가지로, 사이트마인더는 보호되는 웹 서버에 설치된 에이전트를 이용함으로써 웹 자원을 보호한다. 지원되지 않는 웹 서버용으로 사이트마인드는 역 프록시 서버를 제공하고 있다.
우리는 사이트마인더의 중앙 정책 서비스와의 통신을 위해 셋업한 아파치 웹 서버와 IIS에 에이전트를 설치했다. 모든 정책, 에이전트 및 인증 방안은 정책 서비스에서 구성이 가능하다. 사용자가 보호받는 자원으로의 액세스를 시도하면 에이전트는 요청을 인터셉트해서 사용자에게 증명서 양식을 제시한다. 이러한 증명서들은 정책 서비스로 전달되며, 정책 서비스는 이들을 계정 저장소에 대조해서 검증한 다음, 배치된 정책을 기반으로 액세스를 허가하거나 거부한다. 사용자에게 자원으로의 액세스가 허용되면, 사이트마인더는 HTTP 헤더를 통해 사용자 프로파일 정보를 보안 웹 애플리케이션으로 전달해 콘텐츠 맞춤화를 지원할 수 있다.
사이트마인더는 웹 인터페이스를 통해 제어되는데, 이것은 자바 애플릿을 띄운다. 처음에는 이 인터페이스가 MMC (Microsoft Management Console)와 유사한 모습이라 편안함을 느꼈지만, 곧 네티그리티의 보안 모델을 공부하고 새 단어(realm, policy domains, identity environment 등)를 익혀야만 무엇이든 구성할 수 있다는 사실을 깨달았다. 이 기술의 복잡함을 감안할 때 꼭 나쁘다고 할 수는 없지만, 네티그리티의 인터페이스는 관리하기가 가장 힘들었다. 예를 들어 구성 인터페이스에는 도움말 버튼이 있긴 하지만, 이것이 언제나 관련 정보로 안내해 주는 것은 아니었기 때문에, 하나 이상의 장소를 검색해야 필요한 것을 찾을 수 있었다.
사이트마인더를 이용하면 관리자는 하나 이상의 폴리시 도메인(Policy Domains)을 구성할 수 있다. 테스트를 위해 우리는 하나의 도메인을 만들었으며, 여기에는 우리의 영역(realms), 및 관리자가 포함됐다. 영역은 보안돼야 할 관련 자원 그룹을 말한다. 우리는 IIS 6.0 웹 서버에서 몇 개의 폴더를 이용해, 인증용 계정 데이터 저장소로 액티브 디렉토리를 이용해 자원에 ‘인증 방안’이 할당되고 보호되는 것으로 영역을 구성했다.
사이트마인더는 HTML 양식 기반 인증, 디지털 증명서, 토큰 인증 및 맞춤구축 인증 라이브러리 등 몇 가지 인증 방안을 지원한다. 우리는 각각의 인증 방안용으로 1에서 1천 까지의 숫자 ‘보호 값’을 정했다. 따라서 우리 도메인 안에 있는 서로 다른 영역들은 서로 다른 보호 수준이 필요할 수 있을 것이다. 기본적인 양식 기반의 인증을 이용해 사용자가 로그인을 하면 것은 동등하거나 보다 낮은 보호 수준의 모든 영역에 싱글사인온이 존재하게 되지만, 보다 높은 수준의 보호 영역으로 액세스하고자 할 경우에는 토큰을 이용해 재인증해야 할 것이다.
하나의 영역 안에서 우리는 규정, 응답 및 정책을 셋업할 수 있었다. 규정은 주어진 자원에 어떤 행동이 허용되는지를 지시하며, 응답은 규정이 트리거링됐을 때 취해져야 할 행동을 가리킨다. 그리고 정책은 규정과 응답을 함께 연결시켜 준다. 게다가 정책은 시간, 혹은 IP 어드레스 기반 규제를 자원에 할당하는 데 사용될 수 있을 것이다. 사이트마인드가 다중 사용자 저장소(디렉토리나 관계형 데이터베이스)를 지원하고, 관리자들로 하여금 사용자가 로그인을 할 때 검색되는 순서를 지정할 수 있게 해준다는 사실을 확인할 수 있어 다행이었다. 마지막으로 네티그리티의 최신 릴리즈에서는 인바운드와 아웃바운드 FIM을 둘 다 지원하고 있다.
아이덴티티마인더는 또한 웹 관리자 인터페이스를 채택했는데, 이것은 자바 애플릿 대신 HTML 양식을 사용하고 있다. 우리는 디렉토리, 환경, 워크플로우, 작업 및 역할을 구성할 수 있었다. 아이덴티티마인더의 환경은 테스트를 시작하기 전에 익혀야 할 또 하나의 용어였다. 여기서 환경이란 디렉토리의 맞춤화된 뷰를 말하는 것이기 때문에, 주어진 디렉토리는 몇 개의 환경과 연관될 수 있으며 각각의 환경은 하나의 디렉토리를 사용한다.
게다가 아이덴티티마인더는 위임 관리와 셀프 서비스를 지원한다. 다른 제품들에서와 마찬가지로, 우리는 새 계정들을 승인하는 과정을 자동화하는 워크플로우를 셋업했다. 그리고 마치 제품 안에서 배울 게 충분치 않은 것처럼 맞춤 애플리케이션이 아이덴티티마인더의 API를 이용해 만들어질 수 있다.
사이트마인더는 입중되고 신뢰성 있는 제품으로, 여기에는 수많은 옵션과 기본적인 액세스 제어 기능을 할 수 있는 간편한 방안이 있다. 조직에서는 아이덴티티마인더가 없이 사이트마인더를 사용할 수 있는데, 이것은 아이덴티티마인더가 복잡하다는 점에서 감사한 일이다. 네티그리티에서 주의할 점은, IT 관리자에게서 좋은 소리를 듣고 싶다면 이들의 일을 수월하게 만들어주어야 한다는 사실이다. 이런 제품들에는 기능성과 관리를 보다 잘 통합시키는 데 역점을 두는 게 출발점이 돼야 한다.

엔티그리티 솔루션즈
어슈어액세스

엔티그리티의 어슈어액세스(AssureAccess)는 그 경쟁 제품들처럼 나온 지는 꽤 됐지만 전체적인 기능성과 가치 면에서 뒤쳐졌다. 예를 들어 어슈어액세스는 어떠한 용량에서든 IIS 6.0이나 윈도 2003을 지원하지 않는 유일한 제품이었으며, 아웃 오브 더 박스로 계정관리를 수행하지 않는 유일한 제품이기도 했다.
엔티그리티는 자사의 에이전트를 ‘어댑터(adapter)’라고 표현하고 있다. 어댑터는 대부분의 잘 알려진 웹 및 애플리케이션 서버용으로 사용 가능하며, 진정으로 야심이 있는 사람이라면 사용 가능한 API를 이용해 맞춤 어댑터를 만들 수도 있다. 어슈어액세스에게서 요구되는 세 가지 컴포넌트는 감사 서비스, 인증 서비스 및 관리 콘솔 서비스다. 관리 콘솔은 제품 구성용의 계정 저장소로 연결된다.
웹 기반 관리 콘솔을 가진 경쟁 제품들과 달리, 엔티그리티의 매니지먼트 콘솔(Management Console)은 자바 애플리케이션에 로컬로 설치되기 때문에, 우리는 단말기 서비스를 통해 원격으로 로그인을 해서 외부 로케이션에서 제품을 관리해야 했다. 우리 윈도 2000 서버에 이것을 설치하는 과정에서는 어슈어액세스가 대부분의 LDAP 디렉토리 서버를 지원하긴 하지만 그 설치 프로그램이 아이플래넷만을 자동으로 구성한다는 사실을 발견하고 놀라야 했다. 설명서를 따라 별다른 어려움 없이 액티브 디렉토리를 수동으로 구성해 어슈어액세스에서 요구하는 등급과 속성을 추가할 수 있었다.
사용자 인터페이스는 왼쪽에 있는 도메인 트리로 만들어졌다. 트리에 있는 객체를 선택하면 오른 쪽에 해당되는 구성 옵션이 나타나며, 아래 쪽에는 유용한 컨텍스트 도움말 헬프 패널이 뜬다. 보안 모델은 루트 도메인으로 구성되는데, 여기에는 하나 이상의 서브 도메인들이 포함돼 있다. 서브도메인은 부모로부터 디폴트 특성을 상속받는데, 이것은 복잡한 환경을 구성할 때 유용하다.
도메인 트리 안에는 보호되는 자원, 인증 프로파일, 정책, 구성 및 사용자 저장소 커넥터 등과 같은 몇 가지 옵션이 포함된 폴더들이 있다. 어슈어액세스에는 네 가지 정책이 있는데, 각각 권한부여, 감사, 인증 및 관리가 그것이다. 일단 정책을 만들자 이들을 적절한 자원과 도메인에 적용시킬 수 있었다. 일례로 특정 자원에 대해 우리는 ‘매니저’ 직함을 가진 모든 사용자에게 액세스를 역동적으로 허용하고 싶었다. 이렇게 하기 위해 우선 사용자가 로그인을 할 때 생성된 속성 증명서로 사용자의 ‘직함’을 추가하는 인증 정책을 만들어야 했다. 그런 다음에는 권한부여 정책을 만들어 그 속성만을 기반으로 액세스를 허가하도록 했다.
모든 정책이 중앙으로 관리되지만 이들이 시행되는 것은 로컬로 설치된 어댑터에 의해서라는 점에 유의해야 한다. 다른 제품들에서는 일상적이었던 중앙 인증 서비스는 전혀 없었다. 따라서 정책상의 변화는 관리자가 지정한 간격으로 어댑터가 자신의 정책 캐시를 갱신시킬 때만 효력을 발휘한다. 또한 관리 콘솔에서 ‘업데이트 적용(send update)’을 선택해 모든 정책 캐시를 즉시 업데이트시켜야만 했다.

IAM 소프트웨어 테스트 방법

우리는 본지 리얼월드 랩에서 테스트할 제품을 보내온 다섯 업체들의 기술자를 초대했으며, 여기서 이들은 우리가 각각의 소프트웨어 패키지를 설치 및 구성하는 일을 도왔다. 기업에서의 설치 및 구성 작업은 사용자의 조직와 업체가 함께 많은 계획 작업을 선행한 후 몇 주가 걸릴 것이다. 우리의 경우에는 프로세스를 진행하기 전에 먼저 각 업체에게 우리 랩 환경과 필요조건을 미리 상세하게 설명했다.
우리 테스트베드는 각각 1GB 램이 장착된 6대의 델 파워에지 2650 듀얼 펜티엄 3 93MHz 서버로 구성됐다. 도메인 컨트롤러에서는 액티브 디렉토리, IIS(Internet Information Server) 6.0 및 SQL 2000 데이터베이스 서버가 있는 윈도 2003 엔터프라이즈 에디션이 돌아갔다. 그런 다음에는 IIS 5.0을 돌리는 두 대의 윈도 2000 서버와 익스체인지 서버 2000을 돌리는 한 대를 추가시켰다. 익스체인지 서버에서의 목표는 OWA(Outlook Web Access)와의 테스트 아래 제품을 통합시키는 것이었다. 네 번째 서버는 레드햇 리눅스 엔터프라이즈 어드밴스드 에디션 3(Red Hat Linux Enterprise Advanced Edition 3)를 아파치 웹 서버 및 마이SQL 데이터베이스와 함께 돌렸다. 그리고 나머지 두 대의 서버는 업체들이 자신들이 선택한 OS와 소프트웨어를 설치할 수 있게 개방해 두었다.
윈도 기반 웹 서버는 인증 컴포넌트와 역동적인 콘텐츠를 제공하기 위해 마이크로소프트 SQL 2000 서버로 연결된 ASP(Active Server Page)를 호스팅했다. 유닉스 서버는 마이SQL 데이터베이스로 연결된 PHP 콘텐츠를 호스팅했는데, 이것은 또한 인증 컴포넌트도 제공했다. 우리는 LDIF 파일로부터 2만명의 사용자를 액티브 디렉토리와 썬 원 디렉토리 모두로 임포팅했다.
테스팅을 위해 우리는 다양한 보호받는 자원과 정책을 각각의 제품 안에 설정했으며, 표준 웹 브라우저로부터 액세스를 시도했다. 그런 다음에는 다양한 역할, 사용자 그룹 및 정책을 만들고 특정 사용자에게로의 액세스를 허용하거나 거부했다. 우리는 또한 위임 관리와 셀프서비스 기능도 확인해 보았다. 이것은 우리가 실질적인 기능을 테스트하고, 이것이 리얼월드 환경에서 일일 기반 운영을 얼마나 쉽게 할 수 있는지를 알아볼 수 있도록 관리 인터페이스에 익숙해질 수 있게 해주었다. 마지막으로 우리는 연방제 계정관리 지원과 보고서 맞춤 기능들과 같이 소프트웨어에서 주목할 가치가 있는 몇 가지 기능들을 테스트해 보았으며, 이것은 우리의 전체 평가에 반영됐다.

어플라이언스 對 소프트웨어

주니퍼네트웍스(Juniper Networks)와 임프리바타(Imprivata)는 모두 소프트웨어가 아니라 어플라이언스 형태로 IAM을 제공하고 있다. 이런 장비들을 검토하고 업체들과 이야기를 나누어본 후 우리는 이들이 이번 리뷰의 모든 전제조건들을 충족시키지 못한다고 판단했다.
하지만 어플라이언스들은 대형 IAM 인프라에 투자할 만한 시간이나 돈을 갖지 못한 회사들에게는 훌륭한 대안이 될 수 있는데, 그 이유는 이들이 개입이 전혀 필요가 없고 보통 조직의 서버에 어떠한 변화도 필요로 하지 않기 때문이다.
두 업체는 모두 일부 고객들이 어플라이언스가 직접적인 계정관리보다도 더 보안성이 강한 방안을 제공할 뿐만 아니라 파일이나 애플리케이션에 액세스 제어를 추가해주기 때문에 풀 IAM 패키지와 함께 어플라이언스를 사용하고 있다고 말했다.
임프리바타는 원사인(OneSign)이라는 SSO 어플라이언스를 제공하고 있다. 이 장비의 오토메이티드 프로파일 제너레이터(Automated Profile Generator)는 매우 인상적이다. 하지만 이 제품은 모든 데스크톱에 백그라운드에서 어플라이언스와 통신을 하는 에이전트가 있을 것을 요구한다. 그리고 이 장비는 엔드유저에게 SSO의 편리함을 제공하긴 하지만, 관리자는 여전히 자원 할당 문제를 해결해야 한다.
주니퍼의 넷스크린 시큐어 액세스는 보안 관점에서 액세스 제어를 공략하고 있다. 이 어플라이언스는 기존의 서버나 클라이언트를 중복으로 하거나 변경할 필요 없이 모든 유형의 자원으로 액세스를 제공할 수 있는 보안 강화 게이트웨이다. 넷스크린의 종단지점 보안 뷰는 모든 네트워크 자원들로의 정밀한 제어를 제공한다.

썬의 웨이브셋 인수 효과
썬 마이크로시스템즈는 최근의 웨이브셋(WaveSet)을 인수한 것 때문에 이번 리뷰에 참가하지 않았는데, 이를 통해 썬은 계정관리/프로비저닝 시장을 보다 많이 점유하기를 희망하고 있다. 썬은 또한 완벽한 디렉토리 서버 패키지를 제공함으로써 풀 서비스 사업자로서의 입지를 확보할 수 있기를 희망하고 있다.
이 패키지의 첫 번째 부분은 썬의 아이덴티티 매니저(Identity Manager)로, 이것은 사용자 프로비저닝, 동기화, 패스워드 셀프서비스를 제공하며, 어떠한 디렉토리 저장소든 통합이 될 것이라고 썬은 말했다.
두 번째 부분인 썬 원 디렉토리 서버(Sun One Directory Server)는 이미 시장 선두주자가 돼 있다. 최근의 엔터프라이즈 에디션에는 추가된 보안, 페일오버 및 부하조절 서비스들이 함께 제공된다. 게다가 노벨의 DirXML과 유사하게 서로 다른 디렉토리 저장소들간에 데이터를 동기화해줄 수도 것이라고 썬은 밝혔다.
마지막으로, 썬의 액세스 매니저(Access Manager)는 싱글사인온, 웹 액세스 제어 및 연방제를 제공한다. 썬은 이것이 에이전트 기반 모델을 사용하는데(테스트한 대부분의 제품들처럼), 그 이유는 이 방안이 더 잘 확장된다고 믿기 때문이라고 말했다.
이 세 가지 가운데, 액세스 메니저가 가장 많은 작업이 필요하며, 때문에 썬은 가까운 시일 내에 많은 투자를 계획하고 있다.
본지 독자 설문조사에서, 자신들의 회사에서 IAM을 이행하고 있다고 답한 응답자들을 보면 한 업체의 IAM 애플리케이션을 사용하는 곳과 동종 최고를 골라 사용하는 곳들이 거의 비슷하게 나누어져 있다. 썬이 웨이브셋 인수를 통해 얻고자 하는 효과는 보다 많은 회사에서 단일 업체를 선호하도록 한다는 것이다.