디렉토리는 국내에서는 많이 활용되지 않는 부문이다. 하지만, 웹의 시대로 접어들면서 디렉토리에 대한 요구가 높아지고 있다. 웹의 경우, 디렉토리를 통한 인증관리가 보다 더 많은 이점을 줄 수 있기 때문이다. 따라서 사용자인증과 권한관리를 디렉토리서버(DS)를 기반으로 구성한다면 보다 쉽게 권한관리와 보안설계가 가능하게 된다. <편집자>

송상준 // 서진아이앤티 부장
sjsong@seojinint.co.kr

일반적으로 웹사이트에서 사용하는 사용자 정보(ID, 패스워드)는 관계형 데이터베이스(RDB)의 경우에는 사용자(User)가 아닌 하나의 테이블의 데이터일 뿐이지만, DS(Directory Server)의 경우에서는 하나의 사용자로 취급된다. 이러한 차이는 다양한 이점을 제공한다.
하나의 유저이기 때문에 이 사용자에 대한 패스워드 정책, 로그인을 차단하는 유저록(User Locked) 기능뿐만 아니라 사용자를 그룹과 룰(Role)로 나눠 사용자별, 그룹별, 역할별로 사용자 권한을 부여하는 정책 적용이 가능하다. 즉, 웹 화면별로 그룹을 만들어 사용자를 멤버로 추가하므로써 웹사이트 화면에 대한 권한을 줄 수 있는 것이다.
<그림 1>은 포털에서 사용되는 기능들로 사용자를 그룹별로 묶고 이 그룹별로 가상 포털을 연결해 각 그룹별로 권한을 줄 수 있는 것을 보여 주고 있다.
RDB에서는 별로 활용하지 않는 기능이지만, DS를 기반으로 웹사이트 인증에 활용하면 보안이나 권한관리에 다양한 이점을 가져다주는 기능들이 있다. ACL, 암호화 등이 이러한 대표적 예라고 할 수 있다.

ACL(Access Control List)
ACL은 DS에 인가된 사용자에게 부여하는 DS내부 데이터에 대한 접근권한 설정의 집합을 말한다. 즉 누가(who), 언제(When), 어디서(Where), 어떠한(How) 권한을 어떤 데이터에 적용하는 접근권한명령(ACI : Access Control Instruction)의 집합이다. 권한 설정은 어트리뷰트(Attribute) 단위까지 권한설정이 가능하다. 이를 이용하면 웹 화면별 권한 설정 및 관리가 가능하도록 구성이 가능하다.
ACL은 <그림 2>로 간단히 설명할 수 있는데 누가 DS안에 있는 무엇을 읽을 권한이 있는지 설정하는 것을 말한다. IBM 티볼리 디렉토리(Tivoli Directory)의 경우 기본적 엔트리로 ACL 설정이 가능하다.
예를 들어 하나의 ou에 사용자권한설정이라는 ou를 만들고 그 안에 각각의 권한을 만들고 화면을 읽으려 하는 경우를 가정해보자. 사용자가 이 자료를 읽을 수 있는지 DS에서 확인하고 화면을 열어준다면 ACL 설정별로 화면을 나타나게 간단히 구현할 수 있다.
이러한 ACL은 다른 부분에 활용할 수 있다. 관리자 권한이양 등이 DS를 기반으로 쉽게 구현할 수 있는 ACL 기능이다. 예를 들어, 행정자치부의 경우 각 지자체 별로 관리자를 운영하고 있다. 이를 해결하기 위해서 어드민(admin) 그룹을 만들어 멤버를 추가한 후 그룹에 해당 지자체의 DIT에 대해 쓰기나 읽기 권한을 주게 되면, 그 DIT 아래만 관리할 수 있도록 할 수 있다. 또한 웹 인증 후에 자기가 권한이 있는 하위 사용자만 수정이 가능하도록 쉽게 구현하는 것도 가능하다.

그룹 및 롤(Role)
웹사이트 인증에서 화면에 대한 인증을 사용할 경우 각각의 개인에게 권한을 주는 경우는 없을 것이다. 대부분 그룹별로 혹은 역할별로 권한을 주기를 원하며 그 권한도 해당 그룹의 하위 그룹에는 자동으로 권한이 이양되기를 바랄 것이다. 또 관리자의 권한이양도 원하게 된다. 이를 RDB로 구현한다면 여러 테이블과 이에 필요한 설계가 필요하게 되지만, DS를 사용할 경우에는 이미 이런 기능이 내장돼 있고, 권한이양에 대한 정의가 이미 구현돼 있어 간편하게 설정할 수 있다.
그룹에 대해 좀더 자세히 알아보면, 그룹은 크게 정적그룹(Static Group), 동적그룹(Dynamic Group), 중첩그룹(Nested Group), hybrid Grroup(하이브리드 그룹)으로 나눌 수 있다.
먼저 그룹은 정적과 동적으로 나눠 볼 수 있다. 여기서 정적이라 함은 그룹을 만들고 그 그룹에 멤버(member)라는 어트리뷰트를 이용해 그룹에 사용자를 입력하는 방식이다. 이러한 정적 방식의 경우에는 그룹 사용자가 200명 이상의 경우 그룹멤버 관리가 어려우므로 많은 멤버가 그룹에 등록하지 않도록 해야 된다.
<예제 1>은 정적 그룹의 예를 나타내는 LDIF내용이다. Dev.staff라는 그룹을 만들었으며, 이 그룹에는 cn=John, cn=jane, cn=James라는 사용자가 멤버로 등록돼 있다.
동적그룹은 사용자 데이터가 가지고 있는 정보를 가지고 그룹핑을 하는 방법으로 많은 사용자의 그룹핑에 사용되는 방법이다. 동적 그룹 방식의 경우에는 사용자의 데이터만 변경을 하면 해당 그룹을 보다 자유롭게 이동시킬 수 있다.
<예제 2>는 동적 그룹의 예다. 여기에서는 cn=users 아래에 있는 ibm-group 멤버 중 어트리뷰트값이 그룹1이라는 값을 가진 사용자들이 그룹1의 멤버로 지정돼 있다.
이렇듯 정의한 그룹을 통해 권한을 부여하면, 좀 더 편하게 사용자 권한 관리가 가능하도록 구성할 수 있다. IBM 티볼리 디렉토리 서버를 예로 들면, 이 그룹별로 DS에 사용권한 조정 뿐 아니라 DS 검색 시 갖고 올 수 있는 검색 개수(Search Limit)도 조정할 수 있다. 나아가 중첩그룹을 사용하게 되면 그룹에 사용자(member)뿐만 아니라 다른 그룹도 그룹의 멤버로 추가할 수 있다.

어트리뷰트 암호화와 SSL
RDB의 경우 어트리뷰트의 암호화나 SSL을 하기 위해서는 다른 제품의 도움을 받거나 자체 내적으로 개발해야 된다. 하지만 DS는 이런 기능들이 내장돼 DS만으로도 어트리뷰트 암호화와 SSL이 가능하다.
티볼리 디렉토리의 경우 어트리뷰트 암호화를 쌍방향 암복호화가 가능한 ASE256방식으로 암호화함으로써 권한에 따라 데이터에 대한 접근을 제한할 수 있다. 또한 SSHA, SHA, DSE와 같은 해쉬암고리즘을 이용한 메시지 다이제스트로 사용이 가능해 어트리뷰트 암호화를 손쉽게 구성하는 한편, 추가 개발이나 인력이 들어가지 않는다는 장점을 제공한다.
그리고 DS의 데이터를 읽어갈 때 일반적으로 보안을 생각하지 않는 방법도 있지만 SSL을 이용한 보다 보안적인 방법으로도 데이터를 주고받을 수 있다. 이를 위해서는 DS 서버 쪽에서 구성을 해야 한다. 구성 방법에는 클라이언트에게 꼭 인증서를 필요하게 하는 방법과 인증서를 요구하지 않는 방법, 항상 서버 인증서를 이용하여 SSL연결하는 방법 등이 있다.

패스워드 정책
패스워드 정책(Password Policy)으로 티볼리 디렉토리의 경우 EAL4를 지원한다. EAL4(Evaluation
Assurance Level 4)를 인증받은 디렉토리 서버는 IBM 티볼리 디렉토리 서버가 유일하다.
RDB의 경우, RDB 유저는 패스워드 정책을 설정할 수 있지만, 웹 사용자는 RDB에서의 유저가 아닌 테이블 데이터이므로 패스워드 정책을 설정하기 위해 웹 인증개발 업체에서 재개발이 필요하다. DS의 경우 이미 이런 기능이 포함돼 있다. 따라서 설정만으로 사용할 수 있도록 되어 있어 웹 인증을 쉽게 구현을 할 수 있다. <그림 3>처럼 DS 웹 콘솔을 사용, 패스워드 정책을 설정하는 그림이다.
이 외에 DS서버의 특징 중에 하나로 볼 수 있는 것이 복제(Replication)와 참조(Referral)로 이들 기능을 이용해 DS의 특징인 분산환경을 구성할 수가 있다. 분산환경을 구성하면 자신의 웹에서 인증할 계정만을 서버에서 필요로 하고 다른 곳의 계정은 관리할 필요가 없게 된다. 하지만, 현재 자신에게 없는 계정에 대해서도 참조를 통해 타 DS를 이용한 인증을 수행할 수 있어 마치 분산처리와 같은 효과를 얻을 수 있다.

<예제 1> 정적그룹 LDIF
DN: cn=Dev.Staff,ou=Austin,c=US
objectclass: accessGroup
cn: Dev.Staff
member: cn=John Doe,o=IBM,c=US
member: cn=John Smith,o=IBM,c=US
member: cn=James Smith,o=IBM,c=US

<예제 2> 동적그룹 LDIF
dn: cn=GROUP1,ou=Austin
objectclass: group0fURLs
cn: GROUP1
memberURL: 1dap:///cn=users,ou=Austin??one?(ibm-group=GROUP1)
dn: cn=Group 1 member, cn=users, ou=austin
objectclass: person
objectclass: ibm-dynamicMember
cn: Group 1 member
sn: member
userpassword: memberpassword
ibm-group: GROUP1

<예제 3> 중첩그룹 LDIF
dn: cn=GROUP 2, cn=Groups, o=IBM, c=us
objectclass: group0fNames
objectclass: ibm-nestedGroup
objectclass: top
cn: GROUP 2
description: Group composed of static, and nested members.
member: cn=Person 2.1, cn=Dept 2, cn=Employees, o=IBM, c=US
member: cn=Person 2.2, cn=Dept 2, cn=Employees, o=IBM, c=US
ibm-memberGroup: cn=Group 8, cn=Nested Static, cn=Group, o=IBM, c=US

데이터넷