SSO 업무 수행 전 관련 내용 용어 및 개념 정리 ( SSO, EAM, IM, IdM, IAM, EP, TIM, TAM, LDAP )

1   SSO (Single Sign On)

1.1        SSO 개요

1.1.1   SSO 정의

하나의 아이디로 여러 사이트를 이용할 수 있는 시스템으로 'single sign on'의 첫글자를 따서 SSO라고도 한다. 여러 개의 사이트를 운영하는 대기업이나 인터넷 관련 기업이 각각의 회원을 통합 관리할 필요성이 생김에 따라 개발된 방식으로, 1997년 IBM이 개발하였으며 우리나라에는 2000년 코리아닷컴이 처음 도입하였다. 이후 삼성전자(주)와 SK 등이 도입하며 활성화되어, 애니패스와 오케이캐쉬백·롯데타운 등 다양한 사이트와 네티그리티·다우기술 등 솔루션 공급업체도 많이 설립되었다.

개인의 경우, 사이트에 접속하기 위하여 아이디와 패스워드는 물론 이름·전화번호 등 개인정보를 각 사이트마다 일일이 기록해야 하던 것을 한 번의 작업으로 끝나므로 불편함이 해소되며, 기업에서는 회원에 대한 통합관리가 가능해 마케팅을 극대화시킬 수 있다는 장점이 있다. 특히 권한관리시스템(EAM)과 함께 사용할 경우 보안성과 효율성을 함께 갖춘 통합인증시스템으로 활용할 수 있어 향후 더욱 인기를 끌 것으로 전망된다. 

 

1.2        SSO 도입 목적

기하급수적인 인터넷 사용자의 증가와 발전으로 우리는 업무나 일상생활에서 수많은 인터넷 서비스를 접하게 되었고, 이제 인터넷은 우리 생활의 필수 불가결적인 요소가 되었다.그런데 이러한 여러 인터넷 서비스들은 사용자들의 개인 정보를 요구하고, 사용자가 이를제공해주는 경우에만 아이디를 발급하여 필요한 정보들을 얻을 수 있게끔 하고 있다. 이와같은 이유 때문에 사용자들은 그 수많은 서비스들 각각에 해당하는 자신의 인증 정보를 기억해야만 하는 불편함을 가지고 있다. 그래서 어떤 사람은 아이디와 패스워드를 따로 관리하는 목록을 만들거나 아이디와 패스워드를 관리하는 소프트웨어를 사용하거나 모든 아이디와 패스워드를 하나로 통일에서 사용하는 사람도 있다. 그러나 이런 현상은 보안의 관점에서 보면 상당한 취약성을 가지고 있다. 서비스 업체들에 제공된 개인 정보들이 유출되어악용되는 문제점을 가지고 있는 것이다. 만일 아이디와 패스워드의 목록이 다른 사람에게노출된다면 그 사람이 사용하고 있는 모든 아이디와 패스워드를 변경해야 한다. 시스템의아이디와 패스워드의 잦은 변경은 기업의 생산력을 떨어뜨리는 원인들이 되며 또한 보안상의 상당한 취약성을 가지고 있다. 이러한 보안상의 취약성과 생산력 저하를 극복하기 위해서 싱글사인온(Single Sign On, 이하 SSO)이란 개념이 나오게 되었다.

 

예를들어 A라는 게임 포탈사이트는 게임 흥행의 성공으로 User가 폭발적으로 추가 되었고, 그에 따라 UserDB(사용자데이터베이스)는 증가 되어야만 했습니다.기타 관리 서버등의 증설도 불가피하게 되었지요.거기에 사업 확장에 따른 B포털사이트와의 전략적 제휴까지 맺게 되어 A와B라는 포탈은 성격은 다르지만 A,B어느쪽의 유저라도 A와 B의 서비스를 부분적으로 이용가능 하게 되었습니다.
이렇듯 시스템의 규모가 커질 수록 시스템의 구조는 더욱 복잡해지고 관리하기는 더욱 힘들게 될 것입니다. 전문가가 아니라면 그 복잡한 구조를 이해하는 데, 더 어려움이 생길뿐만 아니라, 문제가 발생했을때 그 문제를 처리하는 과정에서도 더 많은 시간과 노력을 초래하게 만듭니다. 그래서 SSO이란 하나의 솔루션이 등장한 것입니다.
이러한 이슈를 중심으로 SSO은 상품에 따라 방식에 차이가 있습니다. 마치 DataBase가 여러 종류 인것 처럼요.
인터넷 뱅킹하실때 XecureWeb이란 보안 프로그램이 설치되는 걸 보신적이 있을겁니다.
자물쇠모양의 프로그램이 설치 되어 오른쪽 하단 트레이에 설치 되는데 이것은 PKI(Public key Infrastructure)란 인증 형태를 가지는 SSO이라고 볼 수 있습니다. 엄밀하게는 EAM(Extranet Access Management)라고 말해야 할지 모르겠지만, 사실상 SSO->EAM->IAM(Identify Access Management)과 같은 형태가 됩니다. 어떤 관점에서 바라보느냐 또는 어떤 대상을 주로 하는가가 차이랄까요.
SoftForum의 XecureWeb의 주된 이슈는 '지금 이 계좌에 접근 할 수 있는 권한이 있는 사람은 오직 '나뿐' 그리고 PKI방식을 통해 인증 받는다' 라는 것에 있는 것 같습니다.
보통 우리가 생각하는 session과 cookie의 개념으로 보면여기서는 xecureWeb이란 프로그램을 통해 Client측에 그 고유의 정보를 보관한다. 정도가 되겠습니다.
반면 Netegrity의 Siteminder의 경우는위의 XecureWeb이 하는 방식과 달리 서버측에서 Siteminder Policy Server란 정책 서버를 통해 통합 관리를 하게 됩니다.User의 인증, 인가정책, UserDB의 통합 등의 모든 컨트롤 역시 이 Policy Server에서 제어 합니다. Siteminder는 다양한 인증 방식을 제공하며(일반 ID/PW방식부터 지문인식에 이르기까지), 다양한 인증스키마를 웹 프로그래밍언어등과 연동해서 구현 할 수 있는 API를 제공하기도 합니다.
성격과 구현 방식의 차이로 인해, XecureWeb은 주로 은행권에서 , 그리고 Siteminder는 Korea.com을 비롯한 대기업이나 통합포털 사이트에서 많이 적용되어 왔습니다.

 

 

1.3        SSO 구성

1.3.1 SSO 개념도

 

1.3.2  SSO 구성요소

강력한 인증 기법을 이용한 SSO 시스템에는 인증서에 의한 인증 메커니즘, LDAP에 의한 접근제어 및 내부사용자 정보관리, 클라이언트와 서버 간의 데이터 암호화를 위한 통신보안 기술등이 필요하다.

2  EAM (Extranet Access Management)

2.1        EAM 정의

EAM - 엑스트라넷 접근 관리 [ EAM, Extranet Access Management, -接近管理 ]

인트라넷, 엑스트라넷 및 일반 클라이언트/서버 환경에서 자원의 접근 인증과 이를 기반으로 자원에 대한 접근 권한을 부여, 관리하는 통합 인증 관리 솔루션. 하나의 ID와 암호 입력으로 다양한 시스템에 접근할 수 있고 각 ID에 따라 사용 권한을 차등 부여하는 통합 인증과 권한 관리 시스템이다.

 

2.2        EAM 도입 배경

사내 어플리케이션이 다양해지면서 기업의 Portal구축 증가 → 시스템별 권한 제어 필요
기업의 “정보공유”마인드 확산에 따라 공개된 정보의 접근통제 요구
B2C, E-Commerce활성화로 사용자별 접근제어

 

2.3        EAM 구조

2.3.1 구성도

 

 

 

 

2.3.2 구성요소

구성요소	설 명
Policy Manager	-사용자 인증 정책 관리 -보안 및 접근통제 정책 관리
권한관리 저장소	-사용자 정보 및 권한 정보 통합 저장 및 관리 -DB, LDAP
Agent	-EAM Server인가여부 검사, 접근 처리
Client	-사용자 인증 인터페이스 -EAM Server에 응용 서버 접근 권한 요청 -접근정보를 이용한 응용 서버접근
EAM Server	-보안 및 접근통제 정책 적합 여부 검증(권한 인증) -사용자 인증 -응용서버 접근 정보 제공(token 등)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.4        EAM 특징 및 기능

기능	설 명
인증방식	-사용자ID와 비밀번호 인증시 암호화 기능(표준SSL지원) -인증기관에서 발행한 인증서 사용가능
SSO	-한번의 인증으로 상이한 시스템에 접근가능
인가기능 (Authentication)	-사용자 권한에 따라 웹페이지의 개인화 -디렉토리서버의 사용자정보를 통해 응용서버 접근
모니터링 기능	-Tool에 의한 로그감사 및 리포팅 기능 제공
성능	-로그인/로그아웃, 인증/인가 등의 신속한 과정 수행

 

 

 

 

 

 

 

 

 

 

3  IM, IdM (Identity Management)

3.1        IM 정의

IM - 계정 관리 [ identity management, 計定管理 ]

한번의 로그인으로 다양한 시스템 혹은 인터넷 서비스를 사용할 수 있게 해주는 통합 인증(SSO)과 애플리케이션의 접근 권한 중심의 솔루션인 엑스트라넷 접근 관리(EAM)를 보다 포괄적으로 확장한 보안 솔루션이다.

3.2        IM 구조

EAM이 통합인증(SSO)과 애플리케이션의 접근권한 중심의 솔루션이라면, 여기에 보다 포괄적으로 확장된 개념이 계정관리다.
계정관리 솔루션은 고객의 요구를 반영한 기능 조합 및 확장이 가능한 솔루션으로 단순한 보안 솔루션이라기보다는 업무 프로세스를 정의하고 관리하는 인프라로써 업무효율성, 생산성, 보안성의 극대화를 통해 확실한 이익창출을 보장하는 비즈니스 툴로 정의할 수 있다.

3.3        IM 특징

3.3.1 통합 저장소
사용자 계정 정보는 애플리케이션, 시스템별로 흩어져 있다. 하지만 계정관리는 통합 저장소를 제공해 모든 애플리케이션 및 시스템 사용자의 이름, 아이디, 이메일, 전화번호, 부서 등과 함께 접근할 수 있는 애플리케이션, 시스템에 대한 접근 권한 정보가 저장된다. 통합 저장소 정보를 통해 사용자의 인증, 인가가 행해진다.

3.3.2 프로비져닝
조직내에 인사 이동이나 직무 변경이 발생해 사용자가 접근하는 자원의 범주가 변경됐을 경우 프로비져닝(Provisioning)이 발생한다. 일반적으로 신입 사원이 입사했을 때 인사팀은 이메일, 그룹웨어, ERP 등 다양한 애플리케이션과 시스템 업무 담당자에게 직접 연락해 필요한 계정을 만들게 한다.

하지만 계정관리 솔루션은 각 담당자가 시스템에 접근할 필요없이 자동으로 계정을 만들어 준다. 벤더들은 필요한 시스템에 에이전트를 설치하고 이 기능들을 제공하고 있으며 OS부터 저장소, SAP, 로터스 노츠 등 상용 애플리케이션까지 폭넓게 적용된다.

프로비져닝 - 권한 설정 [ provisioning, 權限設定 ]
이용자에게 계정, 계정 접근 권한, 계정 관련 권한, 계정 관리에 필요한 제반 자원을 제공하는 서비스 설정 과정. 특히 이용자 측면에서 볼 때 하나의 서비스 형태로서, 통신 사업자가 이용자 회선을 적절한 네트워크에 연결하기 위해 프로그램에 의해 자동 설정하는 것과, 이용자가 웹 기반 인터페이스나 다른 클라이언트 인터페이스로부터 자기가 원하는 서비스를 설정하는 것이 있다.

3.3.3  워크플로우
계정관리에서 워크플로우는 계정을 만들기 위한 일련의 프로세스를 정의하고 이에 따라 계정 요청이 수행되도록 하는 과정이다. 프로비져닝을 통해 계정을 만들 때 워크플로우에 따라 사용자에게 통보하고 담당자의 승인을 받도록 한다. 대부분의 벤더들은 워크플로우 프로세스 생성을 위해 GUI 형태의 디자인 프로그램을 제공한다.

3.3.4  정책 관리
누가 어느 시스템과 애플리케이션에 접근할 수 있는가하는 문제는 계정관리에서 우선 고려해야할 과제다. 사용자가 접근할 수 있는 서비스가 다양하고 사용자의 직무와 역할에 따라 이런 서비스가 제대로 제공되어야 한다. 이런 관점에서 정책관리는 각 조직의 특성에 맞는 애플리케이션과 시스템의 계정과 접근권한을 부여한다. 사전에 정의된 정책에 따라 프로비져닝이 발생하고 통합 저장소에 저장된 사용자의 계정과 권한을 통해 사용자에 대한 인가와 거부를 결정한다.

3.3.5  액세스 컨트롤
액세스 컨트롤은 기존의 EAM 솔루션과 동일한 기능을 수행한다고 볼 수 있다. 즉 프로비져닝과 워크플로우, 정책관리에 의해 수립된 정보를 통해 사용자가 특정 애플리케이션이나 시스템의 자원 요청을 확인하고 조절한다.

3.3.6  감사·리포트
계정관리 솔루션은 계정의 요청, 승인, 수정 및 삭제된 감사기록을 저장한다. 이 과정에서 잘못된 요청, 중복된 인증, 인가 취소 등에 대해 담당자가 필요로 할 경우 언제든 가시화된 보고서로 제공한다. 이 같은 감사기록을 통해 현재 진행되고 있는 정책과 향후 계획에 대해 대처할 수 있다.

3.3.7  패스워드 관리
헬프데스크 업무중 가장 많은 비중을 차지하고 있는 것은 패스워드와 관련된 부분이다. 패스워드 관리는 사용자 자신이 패스워드를 관리하고 여러 시스템의 패스워드를 동기화할 수 있도록 한다.

 

 

4  IAM (Identity and Access Management)

4.1        IAM 개요

4.1.1   IAM 정의
IAM - 식별/접근 관리 [ IAM, Identity and Access Management]

ID와 패스워드를 종합적으로 관리해 주는 역할 기반의 사용자 계정 관리 솔루션. ID 도용이나 분실로 인한 보안 사고에 대비하여 보안 관리자에게는 사용자 역할에 따른 계정 관리를, 사용자에게는 자신의 패스워드에 대한 자체 관리 기능을 제공한다. 또한 시스템과 각종 자원에 대해 고객ㆍ기업 내 사용자ㆍ관리자 등의 접근을 제어할 수 있어, 한 번의 ID와 패스워드 입력으로 다양한 시스템에 접속할 수 있도록 싱글 사인온(SSO)이나 ID에 따라 사용 권한을 차등적으로 부여하는 엑스트라넷 접근 관리(EAM)를 확장 또는 보완한 것이다.

4.1.2   IAM 성장

IAM을 이루는 구성 요소인 IdM과 EAM 가운데 먼저 주목받은 것은 EAM 분야다. SSO(Single Sign-On)를 중심으로 한 EAM은 보안 강화의 효과도 있지만, 사용자 편의성을 향상시키고, 생산성 향상을 가져오는 이점이 있어 빠르게 시장에서 받아들여진 것이다. SSO는 편의성과 효율성을 높이는 EAM의 이점을 극명하게 보여주는 부분이다. 한 번의 로그인으로 업무수행을 위해 필요한 다수의 시스템, 애플리케이션에 접근할 수 있게 하는 SSO는 통일화되지 않은 계정관리로 각 시스템과 애플리케이션에 접근할 때마다 별개의 ID와 패스워드를 설정해야 했던 불편을 해소할 수 있는 장점으로 빠르게 시장에 받아들여졌다.

이와 달리 IdM 시장은 더딘 발걸음을 보였던 것이 사실이다. ID 라이프사이클 관리와 권한 프로필의 통합, 분배, 동기화를 지원하는 IdM은 필요성에는 공감을 얻고 있지만, 이러한 공감이 실질적 수요로 연결되지는 못했으며, 이에 IdM과 EAM을 기반으로 한 IAM의 확산을 어렵게 하는 요소가 됐다.

IdM의 확산, 나아가 IAM의 확산의 걸림돌 중 하나로 꼽히는 요인은 바로 SI(System Integration) 형태로 진행돼야 한다는 점이다. 사용자와 사용자 인증, 시스템, DB, 애플리케이션, 기기 등을 아우르는 프레임워크인 IAM은 SI성으로 전개돼야만 하며, 이러한 특성은 도입비용을 높이는 결과를 낳아 쉽게 IdM을 구축, EAM과 연계한 IAM으로의 진화를 어렵게 하고 있는 것이다.

프로젝트 비용이 높다는 이러한 단점은 기초적인 계정 관리의 경우, 수작업으로도 가능하다는 점과 연계되면서 중소중견 기업군에서 IdM 도입을 통한 IAM 구축을 외면하는 결과로 연결되고 있다. IAM을 구축, 자동화된 관리를 구현함으로써 투자회수 효과를 얻을 수 있지만, 높은 구축 비용에 대한 부담으로 인해 쉽게 투자를 결정하지 못하고 있는 것이다.

2010년 IAM 시장의 어려움은 이를 방증한다. 전세계적인 금융위기의 여파로 전반적으로 IT 투자는 위축됐지만 보안 시장의 경우, 위협증가에 따라 고성장을 기록했다. 한국인터넷진흥원(KISA)이 지식정보산업협회(KISIA)와 공동으로 조사한 2010년 정보보안산업 실태조사에 따르면, 국내 IT 보안 시장은 2009년 대비 21.6%의 급성장을 이뤘다. 그러나 통합계정관리(IM/IAM) 분야는 전년 대비 2.6% 성장에 그쳤다. 이는 경기 위축 상황에서 높은 투자가 요구될 뿐만 아니라 기존과 같이 수작업으로 가능하다는 점에서 IdM 및 IAM에 대한 투자가 지연된 것이 원인으로 분석할 수 있다.

그렇지만 2011년에는 IdM, 나아가 IAM의 성장이 기대되고 있다. 일본 대지진, 리비아 사태란 변수가 존재하지만, 몇 년간 미뤄졌던 투자를 더 이상 미룰 수 없는 시점이 다가오고 있을 뿐 아니라 비용효율성 향상을 위한 클라우드 컴퓨팅 환경으로의 전환이 점차 대두되고 있기 때문이다. 가상화를 기반으로 한 클라우드 컴퓨팅 환경에서 정교한 계정 및 접근권한 관리는 필수다. 다시 말해 클라우드 컴퓨팅 이슈를 발판으로 IAM의 성장을 기대할 수 있는 상황이다.

 

4.2        IAM 접근 방식

개별 시스템들이 늘어 나고 시스템의 Identity 관리 비용도 비례해서 늘어나는 상황에 직면 하면서, 개별 시스템들에 대한 Identity를 공동 으로 사용 하고자 하는 통합론이 대두 되었다. 이러한 환경은 개별 시스템이 늘어 나더라도 개별 서비스에서 Identity를 따로 관리 하지 않기 때문에 개별 시스템의 Identity 관리 비용을 혁신적으로 줄일 수 있다. 또한, 사용자가 늘어 난다고 하더라도 중앙 디렉토리에 사용자만 추가 하면 모든 시스템이 해당 사용자 정보를 참조할 수 있기 때문에 개별 시스템 별로 사용자를 추가 해야 하던 기존 관리 시스템보다 관리 비용을 혁신적으로 줄일 수 있게 된다.
실제로 대부분의 유닉스OS 들은 LDAP 디렉토리에서 사용자 ID/PWD를 확인할 수 있는 서비스를 제공하고 있으며, 윈도우OS 는 액티브 디렉토리에서 관리 되는 사용자를 지원 한다.
  또한, SAP/Domino Notes 과 같은 ERP, 그룹 웨어들도 LDAP 디렉토리를 통해 사용자를 인증하고 사용자 정보를 얻을 수 있다.
  그러나, 계정 통합 만으로 모든 것이 해결 되는 것은 아니다. 디렉 토리에 사용자 Identity를 추가 한다는 것 만으로 개별 시스템들을 바로 사용할 수 있는 준비 작업이 완료된 것은 아니다. 준비 작업에 필요한 개별 시스템 관리자의 관리 비용은 여전히 그대로 유지 된다. 또한, 계정 통합을 하기 위해서 기존 시스템들을 업그레이드 해야 하고, 개별 시스템의 Identity를 같게 하기 위한 초기 비용도 상당 하다.
  개별 시스템을 Identity가 사용할 수 있도록 하는 일련의 작업을 프로비저닝(Provisioning)이라 한다. 프로비저닝 시스템은 개별 시스템 관리자가 수행 하던 프로비저닝 관리 업무를 소프트웨어를 통해 수행 하도록 함으로써 관리 비용을 혁신적으로 줄여 준다. 예를 들어, Unix Shell에서 새로운 사용자를 추가할 때 관리자가 adduser 라는 shell 명령을 통해 사용자 디렉토리를 만들 거나, 관리자가 직접 사용자 디렉토리를 만들고 권한을 부여 해야 했지만, 프로 비저닝 시스템을 통해서 이제 관리자는 더 이상 유닉스 명령어를 알아야 할 필요 없이 익숙한 인터페이스를 이용하여 관리 업무를 수행할 수 있다. 여기에 계정 통합까지 같이 이루어 진다면, 새로운 사용자가 계정을 가지고 해당 업무를 수행하는 환경을 제공하는데 까지 기존에 비해서 매우 큰 비용 절감이 이루어 진다.
  이제 프로비저닝의 개념을 좀더 확장해서 아이덴티티 프로비저닝 (Identity Provisioning)을 Identity에게 사용이 허가된 모든 서비스를 사용 가능 하게 하는 일련의 작업들로 보자. 아이덴티티 프로비저닝은 개별 시스템별 단위 Provisioning 작업 들을 하나로 묶는다. 예를 들어, 홍길동이라는 사용자가 회사에 고용 되는 경우 회사는 홍길동에게 메일 계정과 그룹 웨어 계정을 제공할 수 있다. 홍길동이라는 사용자를 중앙 관리 툴을 이용 해서 사용자 등록을 하면, 이후 Identity Provisioning Process 에 의해서 자동으로 메일 계정을 만드는 프로비저닝 작업과 그룹 웨어 계정을 만드는 프로비저닝 작업이 수행될 수 있다. 또한, 홍길동에게 개발자 역할(role)을 부여하면 개발자에게 허용 되는 유닉스, 윈도우서버 시스템의 계정 및 홈 디렉토리를 자동으로 생성하는 프로비저닝 작업이 수행될 수 있다. 이와 같은 경우 아이덴티티 프로비저닝은 최초 사용자 등록 시 와 개발자 역할(role) 부여시에 대한 두 개의 프로세스가 정의 될 수 있으며, 개별 프로세스는 각각 메일 계정 프로비저닝, 그룹 웨어 계정 프로비저닝(Provisioning)과 유닉스, 윈도우 시스템 계정 프로비저닝 작업 으로 구성 된다.
개별 프로비저닝 작업들은 동시에 혹은 순서대로 이루어 질 수 있다. 개별 프로비저닝 작업 들 간에 아무런 연관이 없으면 동시에 이루어 질 수 있으며, 종속 관계가 있다면 반드시 순서대로 이루어 져야 한다. 예를 들어, 그룹웨어 계정을 만들기 전에 반드시 메일 계정이 있어야 한다는 종속 관계가 있다면 이 두 작업은 동시에 수행될 수 없고 메일 계정 작업이 먼저 선행 되어야 한다. 또한, 개별 작업들은 개별 서비스 관리자 혹은 Identity의 상급자 등에 의해 인가를 받아야만 진행이 되어야 할 수 도 있다. 예를 들어, 개발자 역할(role)을 할당했을 경우 유닉스 계정을 발급 받기 위해서는 반드시 해당 유닉스 시스템 관리자의 인가가 필요 하도록 사내 규칙이 정해져 있을 수 있다. 또는, 개별 작업 수행에 대한 Identity 상급자에게 사후 결과 통보가 필요할 수 도 있다. 아이덴티티의 프로세스 워크 플로우(Workflow)는 프로비저닝 작업들의 수행 순서, 승인, 거부, 통보 등의 절차를 정의하고, 정의된 플로우에 따라 프로세스가 진행될 수 있도록 하는 시스템이다. 아이덴티티 프로비저닝의 프로세스 워크플로우 시스템은 개별 프로비저닝 작업들이 순서대로 수행될 수 있도록 해주며, 승인 절차를 통해 시스템 관리의 권한과 책임을 부여하면서도 관리 비용은 최소화 하도록 해준다.

 

5 SSO, EAM, IM, IAM 의 차이

최근 보안시장에서 인증(Authentication), 권한(Authorization), 관리(Administration) 등 3A 소프트웨어의 중요성이 점점 커지고 있다. 이와 관련해 올해 가장 이슈가 될 것으로 전망되는 솔루션은 계정(Identity)이다. 이 같은 분위기를 증명하듯 이미 해외에서는 계정관리 솔루션 강화를 위해 인수, 합병이 활발하게 진행되고 있으며 국내에서도 계정관리에 대한 다양한 세미나들이 개최되고 있고 몇몇 프로젝트들이 이미 성공적으로 끝마치기도 했다.
기존 직원의 아이디와 패스워드 관리 및 통합권한관리를 위한 솔루션으로 싱글 사인 온(Single Sign-On)과 EAM (Extranet Access Management) 등이 있었다.

 

5.1        SSO
싱글 사인 온은 한번의 로그인으로 다양한 시스템 혹은 인터넷 서비스를 사용할 수 있게 해주는 보안 솔루션이다. 싱글 사인 온을 사용할 경우 인증 절차를 거치지 않고도 1개의 계정만으로 다양한 시스템 및 서비스에 접속할 수 있어 사용자 편의성과 관리비용을 절감할 수 있다.

5.2        EAM
EAM은 가트너 그룹에서 정의한 용어로써 싱글 사인 온과 사용자의 인증을 관리하고 애플리케이션이나 데이터에 대한 사용자 접근을 결정하는 기업 내 정책을 구현하는 단일화된 메카니즘을 제공하는 솔루션을 말한다.
EAM이 통합인증(SSO)과 애플리케이션의 접근권한 중심의 솔루션이라면, 여기에 보다 포괄적으로 확장된 개념이 계정관리다.

5.3        IM
계정관리 솔루션(IM)은 고객의 요구를 반영한 기능 조합 및 확장이 가능한 솔루션으로 단순한 보안 솔루션이라기보다는 업무 프로세스를 정의하고 관리하는 인프라로써 업무효율성, 생산성, 보안성의 극대화를 통해 확실한 이익창출을 보장하는 비즈니스 툴로 정의할 수 있다

5.4        IAM
IAM(Identity Access Management)은 글자 그대로 계정과 접근권한을 관리한다는 개념의 솔루션이다. IAM은 크게 계정관리(IdM : Identity Management)와 접근관리(EAM : Enterprise Access Management)로 나눌 수 있으며, 최근에는 컴플라이언스 이슈의 대두로 감사/보고서가 중시되면서 누가, 언제, 어떤 데이터를 활용할 수 있는지를 알게 하는 기반이 되는 IAM의 중요성이 보다 높아지고 있다

 

6  EP (Enterprise Portal)

6.1        EP 개요

6.1.1  EP 정의
- 경영자, 종업원, 공급사, 파트너, 고객등이 유무선방식의 Web 인터페이스를 통하여, SSO (Single Sign-On) 방식으로 기업내·외의 정보와 가치사슬내의 프로세스 및 Transaction에 접근함으로써 목적에 맞는 업무를 처리하도록 해주는 정보시스템

- 단일화 된 창구를 통하여 기업 내/외부의 정보를 개인화 된 정보로 활용할 수 있는 포털시스템

6.1.2  EP 도입 목적

- 기업 내에 다양하게 도입된 정보시스템들의 통합 View를 제공하여 정보활용 극대화를 꾀함
- 철저한 사용자 편의성 위주로 구축함으로써 정보시스템 활용성을 높임

 

 

6.2        EP 구성

6.2.1  EP 개념도

 

6.2.2 EP 기능 구성도

 

6.2.3   EP 주요기능

구분	내용	요구기술
통합	내/외부Application들간의수직/수평적유연한통합제공 단일화면에서모든정보의조회가가능	EAI, 데이터통합기술
보안	SSO지원, 침입차단및탐지, 보안과 인증, 권한기반Application 접속 단일ID, Password 를통한편리한접근	접근 SSO, PKI 등
개인화	개인및조직에종속적인 Personalization 지원 다양한정보를개인화된View를통해 얻을수있는기능 웹 Publishing을 통해모두가공유할 수 있는정보를자유롭게 제공	Widget, X-Internet, RIA
검색	문서, 컨텐츠및정형, 비정형정보의 효율적검색기능지원 Full-text 검색엔진에의한정보의 수집과카테고리분류	검색엔진, Agent, ECM
협업	개인의경험, 지식을다른사람과 공유할수있는작업공간제공	P2P, 메신저

 

6.2.4   EP 유형

구 분	내  용
EIP	Enterprise Information Portal 기업내.외부정보를기업구성원이 접근할수있는단일창구기능제공
ECP	Enterprise Collaboration Portal 기업구성원간협업컴퓨팅지원
EEP	Enterprise Expert Portal 관심사및전문성에기반한사람과 사람을연결
EKP	Enterprise Knowledge Portal (EIP+ECP+EEP) 업무특성에따른개인화된지식제공

6.3        EP 도입절차

 

단  계	구  분	주 요 사 항
환경분석	경영환경분석	내/외부경영환경분석 핵심성공요소및정보요구사항을 도출
	정보기술분석	정보기술의향후발전방향 파악 정보기술의활용가능성정의
현황분석	업무프로세스분석	지식의생성, 축적, 활용등의 지식 프로세스 분석 포탈과연계할대상업무의처리 흐름 분석 Application 통합범위를 고려
	정보시스템분석	기술기반구조분석 - Application, 데이터베이스 보안, 네트워크 등 포탈구축을위한정보시스템 문제점 및 개선방향 도출
	요구사항정의및 선진사벤치마킹	사용자의요구사항과개선과제 도출 포탈도입한선진사례연구 및 분석
비전수립	포탈도입목적및 목표	기업의EP 도입목적, 역할 및 임무를 설정 핵심성공요소및정보요구사항을 도출
	구축원칙설정	포탈구축및 설계기본원칙 정의 포탈에적용할기술요건, 정보관리 전략 수립
솔루션선정	솔루션선정과정	솔루션선정절차(Prototyping 여부 등), 선정기준, 솔루션평가, 솔루션결과등
	포탈주요대상솔루션	통합검색, CMS(컨텐츠관리시스템),EAM(통합인증권한관리솔루션), PKI(공개키기반구조) 등
도입효과분석	정성적효과분석	임직원, 비즈니스파트너, 고객의효과: 임직원계층별분석(CEO, CIO, 관리자등)
	정량적효과분석	정보기술자산에대한 활용과시스템에대한투자대비효과분석(ROI분석) BSC에근거한효과분석
실행계획	단계별실행계획	EP 단계별추진일정및 소요자원계획, 구현의우선순위설정 - 단계별투자예산, 변화관리(홍보, 교육등) 일정계획

 

 

 

 

 

 

6.4        EP 구축시 고려사항

6.4.1  전략과비전

- 조직의장기적인IT 비전과전략을고려

- 조직의요구사항에대한면밀한파악

6.4.2  컨텐츠와서비스
- 제공할컨텐츠와서비스를누구에게어떻게 제공할것 인지에대한고려

6.4.3  보안측면
- 연계방법, 권한관리수행여부, SSO 연계방식에대해보안과사용자편의성모두고려

6.4.4  변화관리
- 변화에대한저항을최소화하기위한방법준비

6.4.5  접근방법
- EP 구축은유연성을가지고단계별로적용을추진하는방법이바람직함
- EP 구축은패키지제품이아닌각기업의경영환경에적합한요구사항을도출하고최적해야함
- 최신의정보와기술방향을적용하여정보수집과분석/활용에대한유연성확보필요
- 다양한사용자(고객, 파트너, 내부직원등)를고려한보안측면의이슈에대응
- 기업의비전과전략을공유하고, 다양한경영환경의극복과문제해결을위한도구로인식
- EP 도입을위한전문적인서비스지원팀선정필요
- 기업에EP 적용을위해벤더를선정시벤더와제품을면밀히파악하여선정하여야함

 

6.5        EP 도입 효과

구분	추진 목 표	기대효과
CEO	OLAP 기능을통한신속한의사결정	e-Biz 촉진으로경영혁신가속화
	사내/외통합된포탈로임원정보시스템 활용극대화	EP를통한전략적통합으로경영목표달성
CIO	전략적목표와정보기술의일치화	e-Biz 정책의리더로서EP에의한IT 통합추진
	대내외정보채널확보	변화하는고객니즈에신속한서비스제공
	시스템확장에따른안정성보장	포탈에대한체계적평가및관리용이
관리자	기간시스템과의연계로임직원의정보활용극대화	프로세스혁신및통합을통한업무생산성향상
	시스템확장에따른안정성보장	e-Business에 맞는 선진업무프로세스확립
End-User	개인화된정보서비스	업무표준화및 합리화를 통한효율성 증대
	커뮤니티를통한동호회운영	포탈Workplace의제공으로업무생산성향상
	Collaboration	One-Stop 작업을 통해 고부가가치 업무에 집중
비즈니스	업무처리에따른리드타임감소	EP를통한비즈니스파트너간긴밀한관계구축
파트너	EC (B2B, B2C) 지원	포탈을 통한 신속한 업무처리 수행

7 TIM (Tivoli Identity Management)

7.1        TIM 소개
보안 관리를 위한 Tivoli의 핵심 보안관리 어플리케이션인 IBM Tivoli Identity Manager는 하나의 자동화 된 안전한 방법을 제공하여 이질적인 분산 통신망에서 사용자 및 시스템을 관리하게 됩니다.

시스템 관리자에게 중앙 제어기능을 부여하도록 설계된 IBM Tivoli Identity Manager(TIM)는 정책 기반의 관리, TIM 컴포넌트 간의 암호화된 통신, 안전한 권한 위임과 플랫폼에 독립적인 사용자 인터페이스 등 필적할 수 없는 수준의 보안과 제어를 제공합니다. 계정을 사용하고 있는 기업 내 IT 자산들을 서비스로 등록하여, 미리 정의된 Provisioning Policy 를 따라 대상 시스템의 계정을 관리하게 됩니다.
IBM TIM의 핵심 기능이라고 할 수 있는 Provisioning policy에는 다음과 같은 기능들이 정의되어 있어 허가된 서비스에만 변경사항을 적용하고, 변경사항 적용 전 필요한 사전 승인 등의 작업을 통제하게 됩니다.

7.2        TIM 특징

7.2.1  Role Based Access Control (RBAC)
계층적으로 구성된 Organization 안에 Organization Role을 정의합니다. Organization Role은 IBM TIM 관리대상 시스템 별로 접근할 수 있는 사용자/그룹을 정의하고 있습니다. 이 Organization Role을 Provisioning Policy에 적용 함으로서 Provisioning Policy를 통해 사용자 계정 생성 대상이 되는 시스템을 선택할 수 있습니다. 이때 IBM TIM 서비스에 사용자 계정이 생성/변경되는 과정에서 필요한 관리자 승인 등의 작업을 workflow 엔진을 통해 IBM TIM 서비스에 정의 함으로서 자동으로 적용하게 됩니다.

7.2.2  Provisioning Policy
Provision 서비스는 IBM TIM의 핵심 서비스로서 IBM TIM 서비스로 정의된 계정관리 대상 시스템에 대해 어떤 사용자/그룹이 접근권한을 가지고 계정이 생성되어야 하는지에 대한 정책과, 실제 계정이 만들어 지는 프로세스를 정의하고 있습니다. 이를 위해 Organization Role, ITIM Service(계정 관리대상 서버), Workflow가 우선적으로 정의되어야 합니다. Organization Role을 Provisioning Policy에 적용함으로서 사용자 계정 생성 대상이 되는 membership을 정의할 수 있고, Workflow 엔진을 통해 계정생성/변경에 따른 관리자 승인등의 작업을 자동으로 적용하게 됩니다.

7.2.3  Workflow
Workflow란 사용자 계정 생성/변경 등의 요청이 발생했을 때 이를 처리하기 위한 승인/거부/시스템 반영 등의 작업을 정의한 프로세스입니다. 사용자 계정관리를 승인해야 하는 관리자는 e-mail을 통해 승인요청을 통보 받을 수 있으며 관리자는 IBM TIM 서버에 로긴 하여 계정관리 요청을 승인/거부할 수 있습니다. 이후 프로세스는 Workflow 에 정의된 흐름을 따라가게 됩니다.

7.2.4  User Self-Service
사용자는 IBM TIM 콘솔을 통해 자신의 정보를 수정할 수 있으며 시스템 별 패스워드 변경, 패스워드 분실 시 질문/답에 대한 항목 작성 등의 작업을 할 수 있습니다. 이러한 기능을 통해 사용자의 정보관리 기능을 강화시킬 수 있고 계정관리자의 업무로드가 격감됩니다.

7.2.5  Reconciliation
IBM TIM 서버에서 요청된 사용자 계정관련 변경사항을 IBM TIM 서비스(관리대상 시스템)에 반영하고, 역으로 관리대상 시스템에 직접적인 변경이 이루어진 경우 이를 IBM TIM 디렉터리에 반영하는 작업을 합니다. Reconciliation 작업 후 사용자 계정 정보가 일치하지 않는 경우 orphan 계정으로 정의합니다.

7.2.6  보고서 기능
IBM TIM 서버는 시간대 별로 사용자 계정 생성/삭제 작업, 사용자 계정 관리작업 요청현황, 승인 및 반송 현황, reconciliation 작업현황 등에 대한 보고서를 제공합니다

 

7.3        TIM 데이터 객체 관계

 

8 LDAP (Lightweight Directory Access Protocol)

8.1        LDAP 개요

8.1.1   기존 사용자 인증의 문제점
개별 시스템별로 개별 애플리케이션별로 사용자 정보를 관리합니다. 그래서 제대로 계정 관리도 안되고 패스워드 관리도 안됩니다.
DBMS를 이용하는 경우 replcation 을 별도로 설정해야 하는 문제가 있습니다.

8.1.2  LDAP의 장점
LDAP은 표준프로토콜이며 다양한 프로그램 및 장비에서 지원합니다.
그래서 사용자 인증 또는 사용자 정보가 필요한 프로그램에서 손쉽게 연동할 수 있습니다.
replication 이 DBMS에 비해서 상대적으로 쉽습니다. multi master도 지원을 합니다.

8.1.3  LDAP을 지원하는 다양한 프로그램
일단 LDAP쪽에 사용자 아이디와 비밀번호 및 기타 정보가 있으면 다양한 프로그램에서 연동을 하여 사용을 할 수 있습니다.
다양한 프로그램이란 : OS 계정, 각종 이메일 프로그램의 주소록, apache, svn, VPN, 네트워크 장비(네트워크 장비의 경우 RADIUS 같은 것을 통하여 연결되는 것으로 알고 있습니다), 원격접속콘솔(Drac), 메신저, 게시판, DNS서버의 백엔드, /etc/hosts, 기타
사용자 인증이 필요한 프로그램이나 장비의 경우는 거의 대부분 LDAP을 지원합니다. 하다못해 해외에서 개발되는 오픈소스 게시판을 보면 ldap을 지원합니다.

8.1.4  LDAP과 리눅스 OS 계정 관리
- 리눅스 OS를 LDAP과 연동하여 일반 사용자 계정 관리
이 부분은 NIS를 이용하되 사용자 정보는 LDAP을 이용하는 것입니다. 제가 위에 글을 적었던 것도 이 방식이구요. openldap에서 특정 호스트나 사용자를 지정하여 시스템 접속 계정을 관리할 수 있습니다. 그렇지만 이 방식의 경우는 ldap을 통한 호스트, 사용자별 접근 제한하는 것이 편리하지 않습니다.
또한 LDAP 서버가 죽으면 LDAP에 있는 계정으로는 로그인을 하지 못하는 문제가 있습니다.

- 사용자 정보는 LDAP을 이용하되 각 시스템 계정은 별도로 관리 (각 시스템에 접속하기 위한 게이트웨이 서버 구축시 유용)
이 부분은 실제 LDAP과 연관이 된다기 보다는 게이트웨이 서버 구축과 연관된 부분인데요.
사용자 계정은 LDAP에 넣습니다. 그렇지만 보안을 위해서 각 서버에 직접 접속하는 것이 아니라 게이트웨이 서버를 통해서 접속하도록 합니다.
게이트웨이 서버는 jail, chroot 기능을 위해서 보안을 강화를 하구요.
ldap에서 업데이트가 있는 경우 스크립트 등을 통하여 게이트웨이 서버에 해당 계정 정보를 변경합니다. http://linux.die.net/man/5/slapd-perl 이런 것을 쓰면 ldap 에서 특정 작업이 있을 경우 perl 스크립트를 실행하여 원하는 작업을 할 수 있습니다.
게이트웨이를 제외한 다른 시스템은 모든 사용자 계정이 있을 필요가 없습니다.
그래서 각 시스템은 admin1, admin2, admin3 등으로 사용자 계정을 만들고(puppet 으로 관리) 각 사용자별로 sudo를 통하여 실행할 수 있는 명령을 제한합니다. 각 시스템도 용도별로 또는 접근권한별로 구분을 합니다.
그러면 예를 들어 웹서버 호스트 그룹에 taejoon 이라는 사용자는 admin3 권한을 가진다고 지정합니다. 이 정보도 ldap에 넣을 수 있고 별도 db에 넣고 관리를 합니다.
이 경우 ldap 서버가 문제가 생겨도 사용자는 게이트웨이 서버에 ssh로 접속할 수 있고 각 시스템별로 접근하는 것은 호스트 그룹별, 사용자별로 제어가 가능합니다.
글로벌을 고려하는 경우 ldap replication 을 이용하면 되므로 필요한 경우 ldap slave 역할을 하는 게이트웨이 서버만 계속 추가하면 됩니다.
리눅스에서 NIS기능을 이용하여 처리하려고 하는 경우는 여러가지 면에서 막히는 것이 많은데 지금 방식대로 하면 보안도 강화하고 사용자별로, 호스트그룹별로 좀 더 상세한 접근제어가 가능합니다.

8.1.5  OpenLDAP, Active Directory
기존에 이미 AD로 사내 인프라 구축이 된 경우가 많을 것입니다. 일반적인 LDAP 연동이라면 AD를 이용하여 모두 처리할 수 있습니다. 그렇지만 위의 게이트웨이 서버구축의 경우처럼 스키마를 수정하고 부가기능을 사용하려면 AD를 사용하기가 쉽지는 않을 것입니다.
이런 경우는 AD와 다른 LDAP서버와의 동기화를 생각해 볼 수 있을 듯 합니다.
질의가 많지 않으면 openldap 서버의 multi-master, replication 으로도 모두 처리가 가능한데 질의가 많은 경우 openldap 서버는 문제가 생긴다고 합니다.
저는 아직 이런 경우가 없었지만 그 경우에는 다른 오픈소스로 된 ldap 서버 이용하시면 됩니다.

 정책
- 모든 사용자 정보는 ldap에 저장한다
- 인증이 필요한 애플리케이션의 경우는 ldap에서 사용자 계정, 비밀번호, 그룹 등의 질의를 한다. 각 애플리케이션에서 개별적으로 사용자 인증 정보를 구축하지 않는다. (단 사용자나 그룹별 상세한 acl 설정 등은 각 app에서 처리해야 함. LDAP 스키마를 확장해서 특정 필드를 추가하여 사용할 수는 있음)
- LDAP 사용여부와 관계없이 전체 시스템의 uid, gid는 통일해서 사용한다. (puppet 같은 툴 이용)