한빛출판네트워크

By Luke A. Kanies, 역 한빛 리포터 2기 송종범 1~2년 전, 거의 모든 사람들이 LDAP에 관해서 들어봤을 듯하다. 그러나 아무도 그것을 가지고 무엇을 할지 몰랐고 극히 소수의 사람들만이 그것에 대하여 이야기를 했다. 그러던 것이 마침내 관리자들과 개발자들을 위한 것으로 훌륭하게 바뀌고 있다. LDAP는 모든 크기의 네트워크에 있어서 중요한 역할을 할 수 있다. 그러나 다른 대부분의 새로운 기술들과 마찬가지로 지원을 못 받기 때문에 사용하지 않는다는 것과 아무도 사용을 안 하기 때문에 개발자들이 지원을 안 한다는 모순된 상황에 처할 수 있다. 왜, 그리고 어떻게 LDAP가 네트워크 관리자의 생활에 그렇게 중요한 역할을 하게 될 것인가를 이해하기 위해서는, 어떤 문제를 해결하기 위해 LDAP가 개발되었고 앞으로 어떻게 될 것인가를 이해하는 것이 필요하다. 이것은 역시 LDAP 자체를 기술과 도구로써 이해하는 것이 필요하다는 것을 뜻한다. 이번 기사에서는 LDAP와 온라인 디렉토리의 개념을 소개하고 왜 당신이 그것들을 사용하길 원하며, 그것들을 가지고 무엇을 할 수 있을 것인가를 설명 하고자 한다. 다음 기사에서는 보다 깊이 있는 LDAP의 사용에 관한 기술적인 설명을 약간의 예제 애플리케이션을 가지고 하려고 한다. LDAP란 무엇인가? LDAP는 다소 긴 개발 과정으로 X.500 디렉토리 사양과 1980년대 후반과 1990년대 초반사이에 걸쳐 유사한 디렉토리 액세스 프로토콜(DAP)로 시작한 최신의 반복이다. (일반적으로 LDAP의 보다 완벽한 역사와 정보를 알기 위해서는, T.Howes와 M.Smith, 그리고 G.Good이 저술한 "Understanding and Deploying LDAP Directory Services"를 보길 바란다.) DAP는 작동과 실행이 모두 어려운 프로토콜이다. 그래서 그것의 대부분의 기능은 가지지만, 훨씬 덜 복잡한 쉬운 프로토콜이 개발되었다. 결국에는 이러한 버전들은 IETF와 OSI-DS를 통과하면서 Lightweight Directory Access Protocol, 또는 LDAP라는 단어로 명기되었으며, 1993년 RFC 1478로 발표되었다. LDAP는 버전 2에서 널리 사용되었고, RFC 1777에서 명확해졌다. LDAP는 디렉토리라 불리는 특화된 데이터베이스를 액세스하기 위한 프로토콜 정의이다. 그것은 특별한 데이터베이스의 지정 없이도 데이터베이스와 상호작용하기 위한 언어인 SQL과 유사하다. 사실, LDAP 디렉토리를 위한 백엔드는 늘 LDBM이나 Oracle과 같은 일반적인 RDBMS와 유사하다. 데이터 베이스와 상호작용하기 위해서 LDAP를 사용하는 것은 프로토콜을 만드는 사양과 특화된 디렉토리의 전문화된 요구 대 표준 관계형 데이터베이스이기 때문에 데이터베이스에 제약이 가해지기 때문이다. 그러나 이런 제약은 디렉토리가 얻게 될 바람직한 모습들로 필수적인 것이다. 디렉토리란 무엇이며, 왜 나의 네트워크는 그것을 필요로 하나? 이번 글에서 "디렉토리"라는 단어의 사용은 아마도 대부분의 네트워크들이 현재 디렉토리를 사용하지 않거나 LDAP가 네트워크의 유일한 디렉토리이기 때문에 사람들의 생각에 혼란을 줄 지도 모른다. 사실, 디렉토리는 이미 생활의, 특히 컴퓨터 세계에서는 대들보이다. 대부분의 사람들은 전화번호부, 혹은 상점의 지도를 찾는 디렉토리는 잘 알지만, 어떤 이유에선지 디렉토리가 보다 상세하고 맞는 말임에도 불구하고 컴퓨팅에서는 "데이터베이스"란 단어의 사용에 의존한다. 한 예로서 나는 사용자의 정보를 저장하는 유닉스 시스템을 "패스워드 데이터베이스"라 부르지만 데이터베이스는 단연코 디렉토리로서 적합하다. 그것의 가장 기본적인 정의에서, 디렉토리는 기록보다는 읽기에 좀더 전문화되어 있다.: 전화번호부는 1년에 한번씩 나오고, 쇼핑센터의 지도는 오직 쇼핑센터가 변할 때만 바뀌고 패스워드 데이터베이스는 사용자의 정보가 변할 때 갱신된다. 그러나 모든 이런 정보들은 빈번하게 읽혀진다. 일반적으로 말해서 디렉토리는 보여지기보다는 탐색 되는 것이 더 쉬움에도 불구하고, 디렉토리의 자격을 갖출 수 있는 수많은 다른 정보 저장소가 있기 때문에 정의는 실제로 그런 것보다 불명확하다. 종종 대부분의 기술산업에서 디렉토리의 하나로서 언급되는 목록-파일 시스템 디렉토리-역시 이런 정의에 맞는다. 왜냐하면 나열된 파일은 어떤 방식으로든 액세스 될 때마다, 디렉토리는 읽혀지지만 파일은 생성되거나 파괴될 때마다 쓰여진다. 목록을 볼 때보다 다소 구체적인 파일을 찾을 때마다 역시 디렉토리는 더 잘 읽히는 듯하다. 내트워크화 된 응용 프로그램 이나 서비스의 개발과 유지, 보수에 종사하는 대부분의 사람들은 사용자 정보를 유지하는 시스템과 같은 이미 적어도 하나의 디렉토리를 작동 시키고 있다. 거의 모든 서비스는 인증 서비스를 요구하기 때문에 사용자 디렉토리는 항상 같은 서비스를 사용하는 것을 요구한다. 이것으로 인해 온라인 디렉토리의 가장 흔한 형태는 사용자 정보를 위한 것이다. 그럼에도 불구하고 디렉토리는 여러 종류의 정보를 사용하는데 유용하다. 예를들어 유닉스 시스템은 서비스, 그룹, 그리고 많은 다른 데이터 형태들을 위한 디렉토리를 유지하고, 도메인 네임 시스템(DNS)은 호스트네임과 어드레스들의 변환을 위한 글로벌 디렉토리로 매우 특화되어 있으며, 웹 디렉토리는 여기저기 산재해 있는 웹사이트들을 탐색하는데 사용된다. 만일 내가 이미 디렉토리를 사용하고 있다면, 왜 LDAP로 옮겨가는가? 우리는 종종 특화된 서비스를 위해서 대부분의 네트워크들이 다양한 종류의 디렉토리를 사용하는 것을 보아왔다. 데이터베이스의 입장에서, 디렉토리 데이터는 정상적인 것이 아니고 수많은 데이터 조각들이 한군데 이상에 저장되는 것을 뜻하며, 따라서 변화가 필요할 때는 한군데 이상에서 변화되어야만 한다. 이것이 문제가 되는 많은 이유가 있다. 가장 명백한 것은 이 디렉토리에 있는 그 어느 것이든 어떤 정보이든 늘 변한다는 것이며, 모든 다른 디렉토리들도 같은 변화가 일어 남으로써 추적되어져야 한다는 것이다. 이것은 어려울뿐만 아니라 때때로 완벽하게 관리할 수 없게 된다.--다른 서비스에서 같은 사용자의 동기화가 안되는 간단한 증거가 있다. 같은 스타일의 디렉토리가 자신들의 버전으로 동시에 두 가지 서비스를 실행하는 것 외에 중요한 여분의 노력이 있다. 각 서비스를 위해서 개발자들은 그들 자신의 디렉토리를 개발해야 할 뿐만 아니라, 서비스의 운영자들은 개별적으로 디렉토리를 운영해야만 한다. -- 각기 서비스들의 단일 사용자는 거의 확실히 각 서비스마다 다른 사용자 경험을 갖고 있을 것이며, 이런 다중의 디렉토리들을 한데 운영하는 것은 거의 불가능하다. 보안은 더욱 나쁜 문제이다. 아마도 모든 개발자들과 운영자들은 사용자 보안과 관계된 골치거리에 대해 잘 알 것이다. 패스워드들이 안전한가? 전송은 보안되어 있는가? 사용자가 정말로 그/그녀의 신분인가? 나는 종종 상위 접근을 얻을 수 있는 구멍을 두지는 않는가? 같은 정보를 위해서 다중의 서비스들이 분리된 디렉토리들을 실행할 때 그들 각각은 반드시 완벽하게 보안 문제를 포함해야만 한다. 기초 통계학은 가상적으로 단일 디렉토리보다 안전하다는 것을 보장한다. 그리고 이것은 서비스들이 서로 다른, 심지어는 상반되는 보안 정책들을 가지고 있다는 것을 의미한다. 당신이 네트워크에서 정말로 원하는 것이 디렉토리들의 단일화라면, 이것은 LDAP가 정확히 설계되었을 때 나타난다. 이런 단일화로, 데이터의 평준화, 중앙 관리, 사용자 경험의 일치, 관리와 보안정책의 일치, 거의 없는 보안 구멍, 그리고 개발시간 낭비의 단축 등을 얻을 수 있다. 왜 나의 디렉토리를 통합하는데 LDAP를 신뢰하여야 하나? LDAP는 네트워크를 가로지르는 디렉토리들의 확산에 의하여 발생되는 문제점들을 해결하기 위하여 설계되었고, 그러한 능력을 주는 실제 구현에는 일곱 가지의 측면이 있다.

• 다목적 설계 LDAP는 다목적 디렉토리로 설계 되었기 때문에 확장성이 있어야 했다. 객체지향적이며, 어떤 합당한 사용에든지 쉽게 확장성을 제공할 수 있는 상속에 기반한 스키마 정의를 사용했다. LDAP 사양의 한 부분으로 기본 스키마가 있었고, 사실상 다양한 서비스를 위한 표준들이 있었다. 그러나 대부분의 개발자들은 기본 스키마가 확장될 것을 기대했다.
• 프로토콜의 단순화 LDAP 개발의 가장 중요한 측면 중 하나는 DAP를 대체해서 채택되어야 한다는 것이고 상대적으로 단순한 프로토콜이어야 하며 실행과 작업이 상대적으로 간단해야 한다는 것이다. 이는 LDAP가 C와 JAVA, 그리고 Perl을 포함하여 대부분의 주요 프로그래밍 언어에 의해 지원되어야 하며 Solaris와 GNU/Linux, Microsoft Windows, 그리고 Mac OS를 포함하여 대부분의 주요 운영체제에 의해 역시 지원되거나 지원될 예정이어야 한다는 사실에 의해 생겼다.
• 분산 구조 데이터 복사에 있어서 물리적으로 떨어진 위치에 있는 LDAP 디렉토리의 전체, 또는 일부분을 복사하는 것은 가능하다. 이것은 고가용의 데이터를 가능하게 하고, 클라이언트에게 필요한 만큼 데이터를 가깝게 놓아준다. 참조를 사용하여, 디렉토리 일부의 데이터 지배권을 다른 LDAP서버들에 걸쳐서 분산할 수 있고, 단일 권한을 각 데이터의 부분에 걸쳐서 운영하는 동안 엔터프라이즈 부분 또는 필요한 데이터의 전면에 제어를 가질 것을 허가한다.
• 보안 LDAP의 개발은 괄목할 만한 진전을 가져온 LDAP 프로토콜의 버전 3와 함께 보안에 큰 초점을 두어왔다. 디렉토리내의 정보 보안에는 세가지 기본적인 면이 있다.: 접근, 인증, 그리고 공인(AAA, 혹은 Triple-A). 접근은 서비스와 접속할 수 있고 하루의 시간 또는 IP주소와 같은 부분에 기반하여 제한할 수 있는 능력이다. 인증은 클라이언트가 유효한 사용자인지 증명하는 능력이며, 그리고 공인은 클라이언트에게 특별한 권한이나 능력을 공급하거나 부정하는 서비스다. 보안된 접근을 위해, LDAP는 보안 전달 계층(TLS)을 지원하고, 클라이언트와 서버간의 모든 통신을 암호화할 수 있다. 인증을 위해, LDAP는 단순 인증 및 보안층(SASL)을 지원하고 클라이언트와 서버에게 (안전하길 희망하며) 인증방법을 결정할 것을 허락한다. TLS와 SASL은 암호화능력을 주지만 접근과 인증의 전반에 걸친 제어를 제공하지는 않는다. LDAP는 실제로 접근 제어 목록(ACLs)을 통하여 AAA의 모든 세 가지 측면을 제어하는 능력을 공급한다. ACLs는 많은 다른 요소들에 기반하여 접근에 응하게 사용될 수 있다. 그것들은 특정한 타입의 인증을 강요하도록 사용될 수 있고, 클라이언트가 완전히 유효한 사용자로 인증된다면, ACLs는 사용자를 인증하는데 사용된다.
• 공개 표준 LDAP는 IETF에 의하여 유지되는 공개 표준의 하나이기 때문에, 독자적인 프로토콜이나 특정 벤더에 종속될 염려 없이 어떤 개발자들이나 회사들, 또는 관리자들에 의해 사용되어질 수 있다. 그리고 정보처리 상호 운용에 관계하는 것 보다는 오히려 프로젝트의 세부항목에 기반한 실행의 선택을 따른다. 이것은 LDAP가 이익이나 시장점유율에 집중하는 회사보다는 오히려 그것을 사용하는 사람들의 요구에 따라서 발전할 수 있다는 뜻이다.
• 서버의 특징과 스키마 요청들 LDAP 사양은 LDAP 클라이언트가 전체의 특정 목록과 데이터 스키마를 어떤 LDAP 서버로부터도 요청할 수 있어야 한다고 분명히 언급한다. 따라서 클라이언트들에게 서버의 요청에 따라 그것의 기능적 다양화를 허락하고 다른 실행과 다른 버전의 LDAP에 걸친 상호작용을 제공해야만 한다.
• 국제화 LDAP는 내부적인 문자 표현을 위해 UTF-8을 사용한다. 이것은 LDAP에게 세계의 어떤 언어라도 저장하고 조작할 수 있게끔 하는 것이다.

이것이 LDAP의 모든 특징을 완전히 나열한 것은 아니지만 프로토콜의 가장 중요한 측면들을 하나하나 다룬 것이다. 사실 LDAP가 채택되어지고 있는 이유 중 하나는 단지 LDAP 그 자체와 최소한의 관계가 있다. 컴퓨터 산업, 특히 네트워크 관리 영역은 이미 광범위한 기업형 디렉토리가 준비되어 있다. 이는 서버로는 네스케이프 디렉토리 서버와 마이크로소프트의 액티브 디렉토리 서버 등으로부터 클라이언트로는 이메일 프로그램과 운영체제까지 여러 가지로 네트워크가 가능한, Directory Enabled Networks (DEN)과 같은 표준 사양의 선제(先制)가 되어서 곳곳에 보여짐으로 증명되어진다. 난 반했다. 어떻게 그걸 얻을 수 있을까? 운이 나쁘게도, LDAP는 우리가 오늘날 꿈꾸는 완전한 해결책은 아니다. 중요한 문제는 가능한 최대의 지원을 받지 못한다는 점이다. 예를 들면 썬사의 Solaris 운영체제는 자체적인 명칭으로 LDAP를 위해 지원을 제공하고 있지만 어떤 형태의 암호화도 포함하지 않는다. 이것은 기본적으로 용납할 수 없는 것이다. 또한 아직까지도 수많은 벤더와 프로그램들이 그들이 해야 하는 곳에서의 지원을 하지 않고 있으며, 많은 기술 제조사들 역시 LDAP가 무어인지 모르거나 그들에게 문제가 된다고 생각하지 않는다. 이점은 LDAP의 요즘 상황과 함께 다른 문제를 지적한다.: 신뢰할만한 개인적인 문서나 지원의 방법이 그리 많지 않다는 점이다. 물론, 당신은 RFC 문서들과 소스 코드를 읽을 수 도 있다. 그러나 LDAP가 무엇인가에 대한 높은 수준의 설명과 그것이 어떻게 현재와 미래에 유용할 것인가에 대한 설명이 슬프게도 부족한 실정이다. 특히 간결하게 설명해 주는 형태의 자료가 없다는 면에서 더욱 그러하다(오늘날 가장 훌륭한 LDAP 책은 거의 800페이지 나 된다). 심지어 일반적으로 LDAP를 지원하는 응용프로그램 조차도 작업을 위하여 기술을 습득하는 것 보다 그 응용프로그램 자체를 찾는 것이 더 어려운 실정이며, 이것이 바로 LDAP의 채택을 늦어지게 하는 원인이 되고 있다. 그러면 나는 왜 고민해야만 하는가? LDAP의 미래에 대한 비관적인 견해를 갖는 것이 용이함에도 불구하고 - 물론 현재에도 그렇지만 - 실제로는 더 많은 벤더, 응용프로그램, 언어 그리고 운영체제까지 LDAP를 지원하며, 더 많은 업체와 기관에서 핵심 정보의 운영을 위해 LDAP를 채택하고 있는 실정이다. LDAP 디렉토리는 대량의 웹 개발이나 고객 응용프로그램 개발을 하는 업체들을 위한 것이다. 산업적 지원이 지금 당장 최고가 아님에도 불구하고 대부분의 벤더들이 역시 부분적으로나 완전하게 LDAP를 지원하고 있으며 그렇게 해야만 한다고 말하고 있다. 그리고 솔직히 LDAP는 정말로 간단한 프로토콜이며 어떤 언어와도 응용 프로그래밍 인터페이스(API)를 가진다. 만약 당신이 웹 응용 프로그램을 개발하거나, 정보를 저장할 수 있는 훌륭한 디렉토리를 찾고 있다면, LDAP를 생각해 낸 것 만으로도 기회를 잡은 것이다. -- 당신은 찾아 낸 것에 대해 충분히 만족할 것이다. 그래서 지금은 당신이 개발자이든 관리자이든 의사 결정자이든, 또는 세 가지 역할을 모두 다 하던간에 LDAP에 관하여 배우기 시작해야 할 시기이며, 당신이 하는 작업에 LDAP가 어떤 역할을 할 수 있을지 이해하는 노력을 시작할 시기이다. 우리의 산업이 디렉토리의 표준으로서 LDAP를 완전히 지원하는데 걸리는 시간이 길면 길수록, 우리 모두는 넘치는 정보의 저장과 부적당한 정보의 저장 및 그것들과 상호 작용하는 방법을 유지하는데 많은 시간을 소비해야만 한다. 여기로부터 우리는 어디로 가야하나 다음의 기사에서는 LDAP 프로토콜을 좀더 깊이 있게 다룰 것이고, 가장 기초적인 LDAP 디렉토리를 만듦으로써 LDAP 전문 지식을 개발하기 시작할 것이다.

---

Luke A. Kanies는 운영체제에서 완성되는 것보다 운영체제 자체에 좀 더 흥미가 있는 유닉스 시스템 관리자이다. 그는 현재 계약직 연구원으로 일하고 있으며 좀 더 나은 시스템 관리를 만들기 위해 노력하고 있다.