LDAP 프로토콜, 데이터 계층 및 항목 구성 요소 이해

소개

LDAP(Lightweight Directory Access Protocol)는 계층적 디렉토리 구조에서 데이터를 저장하고 검색하는 데 사용되는 개방형 프로토콜입니다. 일반적으로 조직, 해당 자산 및 사용자에 대한 정보를 저장하는 데 사용되는 LDAP는 모든 유형의 엔터티와 해당 품질을 정의하기 위한 유연한 솔루션입니다.

많은 사용자에게 LDAP는 특수 용어에 의존하고 흔하지 않은 일부 약어를 사용하며 종종 상호 작용하는 부분의 더 큰 시스템의 구성 요소로 구현되기 때문에 이해하기 어려울 수 있습니다. 이 가이드에서는 기술 작업을 위한 좋은 기반을 마련할 수 있도록 몇 가지 LDAP 기본 사항을 소개합니다.

디렉터리 서비스란 무엇입니까?

디렉터리 서비스는 데이터를 키-값 유형 형식으로 저장, 구성 및 표시하는 데 사용됩니다. 일반적으로 디렉터리는 쓰기 작업보다 조회, 검색 및 읽기 작업에 최적화되어 있으므로 자주 참조되지만 자주 변경되지 않는 데이터에 대해 매우 잘 작동합니다.

디렉터리 서비스에 저장된 데이터는 종종 본질적으로 설명적이며 엔터티의 품질을 정의하는 데 사용됩니다. 디렉토리 서비스에서 잘 표현되는 물리적 개체의 예로는 주소록이 있습니다. 각 사람은 연락처 정보, 사업장 등을 설명하는 키-값 쌍과 함께 디렉토리의 항목으로 표시될 수 있습니다. 디렉토리 서비스는 정성적이고 설명적인 정보에 액세스할 수 있도록 하려는 많은 시나리오에서 유용합니다.

LDAP란 무엇입니까?

LDAP(Lightweight Directory Access Protocol)는 디렉토리 서비스에 액세스할 수 있는 방법을 정의하는 통신 프로토콜입니다. 보다 광범위하게 말해서 LDAP는 디렉토리 서비스 내의 데이터가 사용자에게 표시되는 방식을 형성하고, 디렉토리 서비스 내의 데이터 항목을 생성하는 데 사용되는 구성 요소에 대한 요구 사항을 정의하며, 항목을 구성하는 데 사용되는 다양한 기본 요소의 개요를 설명합니다.

LDAP는 개방형 프로토콜이므로 다양한 구현이 가능합니다. OpenLDAP 프로젝트는 가장 잘 지원되는 오픈 소스 변형 중 하나입니다.

기본 LDAP 데이터 구성 요소

위에서 LDAP가 디렉토리 데이터베이스와 통신하여 정보를 쿼리, 추가 또는 수정하는 데 사용되는 프로토콜에 대해 논의했습니다. 그러나 이 간단한 정의는 이 프로토콜을 지원하는 시스템의 복잡성을 잘못 나타냅니다. LDAP가 사용자에게 데이터를 표시하는 방식은 일부 정의된 구조적 구성 요소 간의 관계 및 상호 작용에 따라 크게 달라집니다.

속성

LDAP 시스템의 데이터 자체는 주로 속성이라는 요소에 저장됩니다. 속성은 기본적으로 키-값 쌍입니다. 일부 다른 시스템과 달리 키에는 입력을 위해 선택된 objectClasses에 의해 지시되는 미리 정의된 이름이 있습니다(이에 대해서는 잠시 후에 논의하겠습니다). 또한 속성의 데이터는 속성의 초기 정의에 정의된 유형과 일치해야 합니다.

속성에 대한 값 설정은 콜론과 공백으로 구분된 속성 이름과 속성 값으로 수행됩니다. 이메일 주소를 정의하는 mail이라는 속성의 예는 다음과 같습니다.

mail: admin@example.com

속성과 해당 데이터를 참조할 때(설정하지 않을 때) 양쪽이 대신 등호로 연결됩니다.

mail=example.com

속성 값에는 LDAP 시스템에 저장하고 액세스하려는 대부분의 실제 데이터가 포함됩니다. LDAP 내의 다른 요소는 구조, 조직 등에 사용됩니다.

항목

속성 자체는 그다지 유용하지 않습니다. 의미를 가지려면 무언가와 연관되어야 합니다. LDAP 내에서 항목 내의 속성을 사용합니다. 항목은 기본적으로 무언가를 설명하는 데 사용되는 이름 아래의 속성 모음입니다.

예를 들어 시스템의 사용자 또는 인벤토리의 각 항목에 대한 항목을 가질 수 있습니다. 이것은 관계형 데이터베이스 시스템의 행이나 주소록 내의 단일 페이지와 대략 유사합니다(여기서 속성은 이러한 각 모델의 다양한 필드를 나타냅니다). 속성이 어떤 것의 품질이나 특성을 정의하는 반면 항목은 이름 아래 이러한 속성을 단순히 수집하여 항목 자체를 설명합니다.

LDIF(LDAP Data Interchange Format)에 표시되는 예제 항목은 다음과 같습니다.

dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com
objectclass: person
sn: Ellingwood
cn: Justin Ellingwood

위의 예는 LDAP 시스템 내에서 유효한 항목일 수 있습니다.

DIT

LDAP에 익숙해지기 시작하면 속성으로 정의된 데이터가 객체에 대한 사용 가능한 정보의 일부만을 나타낸다는 것을 쉽게 인식할 수 있습니다. 나머지는 LDAP 시스템 내 항목의 위치와 이것이 의미하는 관계에서 찾을 수 있습니다.

예를 들어 사용자와 인벤토리 항목 모두에 대한 항목이 있을 수 있는 경우 누군가가 이를 구분할 수 있는 방법은 무엇입니까? 서로 다른 유형의 항목을 구별하는 한 가지 방법은 관계 및 그룹을 설정하는 것입니다. 이것은 주로 항목이 생성될 때 항목이 배치되는 기능입니다. 항목은 모두 데이터 정보 트리(DIT)라는 트리의 분기로 LDAP 시스템에 추가됩니다.

DIT는 각 항목(최상위 항목 제외)이 정확히 하나의 상위 항목을 갖고 그 아래에 여러 하위 항목을 가질 수 있는 파일 시스템과 유사한 조직 구조를 나타냅니다. LDAP 트리의 항목은 거의 모든 항목을 나타낼 수 있으므로 일부 항목은 파일 시스템 내의 디렉토리와 유사하게 주로 조직 목적으로 사용됩니다.

이러한 방식으로 "people\에 대한 항목과 "inventoryItems\에 대한 항목이 있을 수 있습니다. 유형을 더 잘 구별하기 위해 실제 데이터 항목을 이들의 하위 항목으로 만들 수 있습니다. 데이터를 가장 잘 나타내도록 조직 항목을 임의로 정의할 수 있습니다.

마지막 섹션의 예제 항목에서 dn 줄에 있는 DIT의 한 표시를 볼 수 있습니다.

dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com

이 줄은 항목의 고유 이름(나중에 자세히 설명)이라고 하며 항목을 식별하는 데 사용됩니다. 이는 DIT의 루트로 돌아가는 전체 경로와 같은 기능을 합니다. 이 경우에는 sn=Ellingwood라는 항목이 있으며 생성하고 있습니다. 직계 부모는 ou=people이라는 항목으로 사람을 설명하는 항목의 컨테이너로 사용되고 있을 것입니다. 이 항목의 부모는 DIT의 루트 역할을 하는 digitalocean.com 도메인 이름에서 파생되었습니다.

LDAP 데이터 구성 요소 정의

마지막 섹션에서는 데이터가 LDAP 시스템 내에서 표현되는 방식에 대해 설명했습니다. 그러나 데이터를 저장하는 구성 요소가 정의되는 방식에 대해서도 이야기해야 합니다. 예를 들어, 데이터는 각 속성에 대해 정의된 유형과 일치해야 한다고 언급했습니다. 이러한 정의는 어디에서 오는 것입니까? 다시 복잡성 측면에서 맨 아래부터 시작하여 위로 작업해 봅시다.

속성 정의

속성은 상당히 관련된 구문을 사용하여 정의됩니다. 속성 이름, 속성을 참조하는 데 사용할 수 있는 다른 이름, 입력할 수 있는 데이터 유형 및 기타 다양한 메타데이터를 나타내야 합니다. 이 메타데이터는 속성을 설명하고 LDAP에 속성 값을 정렬 또는 비교하는 방법을 알려주고 다른 속성과 어떻게 관련되는지 알려줍니다.

예를 들어, 다음은 name 특성에 대한 정의입니다.

attributetype ( 2.5.4.41 NAME 'name' DESC 'RFC4519: common supertype of name attributes'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

name은 속성의 이름입니다. 첫 번째 줄의 숫자는 다른 모든 속성과 구별하기 위해 속성에 할당된 전역적으로 고유한 OID(개체 ID)입니다. 나머지 항목은 검색 중에 항목을 비교할 수 있는 방법을 정의하고 속성의 데이터 유형 요구 사항에 대한 정보를 찾을 위치를 알려주는 포인터가 있습니다.

속성 정의의 중요한 부분 중 하나는 속성이 항목에서 두 번 이상 정의될 수 있는지 여부입니다. 예를 들어, 정의는 성이 항목당 한 번만 정의될 수 있다고 정의할 수 있지만 "niece\에 대한 속성은 해당 속성이 단일 항목에서 여러 번 정의되도록 허용할 수 있습니다. 속성은 기본적으로 다중 값이며 반드시 항목당 한 번만 설정할 수 있는 SINGLE-VALUE 플래그를 포함합니다.

속성 정의는 속성을 사용하고 설정하는 것보다 훨씬 더 복잡합니다. 다행스럽게도 대부분의 경우 가장 일반적인 속성이 대부분의 LDAP 구현에 포함되어 있고 다른 속성은 쉽게 가져올 수 있으므로 속성을 직접 정의할 필요가 없습니다.

객체 클래스 정의

특성은 objectClasses라는 엔터티 내에서 수집됩니다. ObjectClasses는 단순히 특정 항목을 설명하는 데 유용한 관련 속성을 그룹화한 것입니다. 예를 들어 \사람은 objectClass입니다.

항목은 objectClass라는 특수 속성을 설정하고 사용하려는 objectClass의 이름을 지정하여 objectClass의 속성을 사용할 수 있는 기능을 얻습니다. 실제로 objectClass는 추가 objectClass를 지정하지 않고 항목에 설정할 수 있는 유일한 속성입니다.

따라서 objectClass person(또는 person에서 파생된 더 구체적인 사람 objectClasses — 나중에 다룰 것임)을 포함하여 사람을 설명하는 항목을 생성하는 경우 모든 속성을 사용할 수 있습니다. 해당 objectClass 내에서:

dn: . . .
objectClass: person

그러면 항목 내에서 다음 속성을 설정할 수 있습니다.

  • cn: 일반 이름
  • description: 항목에 대한 사람이 읽을 수 있는 설명
  • seeAlso: 관련 항목에 대한 참조
  • sn: 성
  • telephoneNumber: 전화번호
  • userPassword: 사용자의 암호

다른 objectClass의 속성이 필요한 경우 objectClass 속성을 여러 번 사용할 수 있지만 허용되는 규칙을 지정하는 규칙이 있습니다. ObjectClass는 여러 "유형\ 중 하나로 정의됩니다.

ObjectClasses의 두 가지 주요 유형은 구조적 또는 보조적입니다. 항목에는 정확히 하나의 구조 클래스가 있어야 하지만 클래스에 사용할 수 있는 속성을 확장하는 데 사용되는 0개 이상의 보조 클래스가 있을 수 있습니다. 구조적 objectClass는 항목을 만들고 정의하는 데 사용되며 보조 objectClass는 추가 속성을 통해 추가 기능을 추가합니다.

ObjectClass 정의는 제공하는 속성이 필수(MUST 사양으로 표시됨) 또는 선택적(MAY 사양으로 표시됨)인지 여부를 결정합니다. 여러 objectClass는 동일한 속성을 제공할 수 있으며 속성의 MAY 또는 MUST 분류는 objectClass마다 다를 수 있습니다.

예를 들어, person objectClass는 다음과 같이 정의됩니다.

objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

이는 항목을 만드는 데 사용할 수 있음을 의미하는 구조적 objectClass로 정의됩니다. 생성된 항목은 반드시 surname 및 commonname 속성을 설정해야 하며 userPassword, telephoneNumber, seeAlso 또는 description 속성.

스키마

ObjectClass 정의와 속성 정의는 차례로 스키마라는 구조로 함께 그룹화됩니다. 전통적인 관계형 데이터베이스와 달리 LDAP의 스키마는 단순히 관련된 objectClasses 및 속성의 모음입니다. 단일 DIT는 필요한 항목과 속성을 생성할 수 있도록 다양한 스키마를 가질 수 있습니다.

스키마에는 종종 추가 속성 정의가 포함되며 다른 스키마에 정의된 속성이 필요할 수 있습니다. 예를 들어 위에서 논의한 person objectClass는 person<을 사용하여 모든 항목에 대해 surname 또는 sn 속성을 설정해야 합니다. /코드> objectClass. 이러한 정의가 LDAP 서버 자체 내에서 정의되지 않은 경우 이러한 정의를 포함하는 스키마를 사용하여 이러한 정의를 서버의 어휘에 추가할 수 있습니다.

스키마의 형식은 기본적으로 다음과 같이 위 항목의 조합입니다.

. . .

objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
  DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )

attributetype ( 2.5.4.4 NAME ( 'cn' 'commonName' )
  DESC 'RFC4519: common name(s) for which the entity is known by' SUP name )

. . .

데이터 구성

우리는 LDAP 시스템 내에서 항목을 구성하는 데 사용되는 공통 요소를 다루었으며 이러한 빌딩 블록이 시스템 내에서 정의되는 방식에 대해 이야기했습니다. 그러나 정보 자체가 LDAP DIT 내에서 구성되고 구조화되는 방식에 대해서는 아직 많이 이야기하지 않았습니다.

DIT 내에 항목 배치

DIT는 단순히 기존 항목의 관계를 설명하는 계층 구조입니다. 생성 시 각각의 새 항목은 자신을 기존 항목의 자식으로 배치하여 기존 DIT에 "후킹\해야 합니다. 이렇게 하면 관계를 정의하고 의미를 할당하는 데 사용되는 트리와 같은 구조가 생성됩니다.

DIT의 상단은 각각의 후속 노드가 어느 정도 후손이 되는 가장 광범위한 분류입니다. 일반적으로 최상위 항목은 DIT가 사용되는 조직을 나타내는 레이블로 사용됩니다. 이러한 항목은 원하는 모든 objectClass가 될 수 있지만 일반적으로 도메인 구성 요소(example.com와 연결된 LDAP 관리 정보의 경우 dc=example,dc=com)를 사용하여 구성됩니다. , 위치(NY의 조직 또는 세그먼트의 경우 l=new_york,c=us) 또는 조직 세그먼트(ou=marketing,o=Example_Co).

구성에 사용되는 항목(폴더처럼 사용됨)은 종종 organizationUnit objectClass를 사용하며, 이를 통해 ou=라는 간단한 설명 속성 레이블을 사용할 수 있습니다. 이는 최상위 DIT 항목(ou=people, ou=groups 및 ou=inventory 공통)입니다. LDAP는 트리 내에서 위아래가 아니라 트리를 따라 측면에서 정보를 찾는 데 최적화되어 있으므로 DIT 계층 구조를 다소 얕게 유지하고 특정 속성 할당을 통해 표시되는 일반 조직 분기 및 추가 세분화를 사용하는 것이 가장 좋습니다.

DIT 내의 항목 이름 지정 및 참조

속성별로 항목을 참조합니다. 즉, 각 항목에는 DIT 계층 구조의 해당 수준에서 명확한 속성 또는 속성 그룹이 있어야 합니다. 이 속성 또는 속성 그룹을 항목의 상대 식별 이름 또는 RDN이라고 하며 파일 이름처럼 작동합니다.

항목을 명확하게 참조하려면 모든 상위 항목의 RDN과 결합된 항목의 RDN을 사용합니다. 이 RDN 체인은 DIT 계층 구조의 맨 위로 돌아가며 해당 항목에 대한 명확한 경로를 제공합니다. 이 RDN 체인을 항목의 고유 이름 또는 DN이라고 합니다. LDAP 시스템이 새 항목을 배치할 위치를 알고 항목의 RDN이 이미 다른 항목에서 사용되고 있지 않은지 확인할 수 있도록 작성 중에 항목에 대한 DN을 지정해야 합니다.

비유하자면 RDN을 파일 시스템에서 볼 수 있는 상대 파일 또는 디렉토리 이름으로 생각할 수 있습니다. 반면에 DN은 절대 경로와 더 유사합니다. 중요한 차이점은 LDAP DN은 왼쪽에 가장 구체적인 값을 포함하고 파일 경로는 오른쪽에 가장 구체적인 정보를 포함한다는 것입니다. DN은 RDN 값을 쉼표로 구분합니다.

예를 들어 John Smith라는 사람에 대한 항목은 example.com 아래 조직의 "People\ 항목 아래에 배치될 수 있습니다. 조직에 여러 John Smith가 있을 수 있으므로 사용자 ID는 항목의 RDN에 대해 더 나은 선택일 수 있습니다. 항목은 다음과 같이 지정될 수 있습니다.

dn: uid=jsmith1,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
cn: John Smith
sn: Smith
uid: jsmith1

이 인스턴스의 uid 속성에 액세스하려면 inetOrgPerson objectClass를 사용해야 했습니다(person에 정의된 모든 속성에 여전히 액세스할 수 있습니다). > objectClass, 다음 섹션에서 볼 수 있음).

LDAP 상속

결국 LDAP 시스템의 데이터가 서로 관련되는 방식의 대부분은 계층, 상속 및 중첩 문제입니다. LDAP는 디자인에 일부 객체 지향 개념을 구현하기 때문에 처음에는 많은 사람들에게 이례적으로 보입니다. 이것은 주로 이전에 논의한 클래스 사용과 지금 이야기할 상속의 가용성에서 비롯됩니다.

객체 클래스 상속

각 objectClass는 해당 유형의 개체 특성을 설명하는 클래스입니다.

그러나 단순 상속과 달리 LDAP의 개체는 여러 클래스의 인스턴스일 수 있으며 종종 인스턴스입니다(일부 프로그래밍 언어는 다중 상속을 통해 유사한 기능을 제공함). 이것은 클래스에 대한 LDAP의 개념이 단순히 클래스가 반드시 가져야 하거나 가질 수 있는 속성의 모음이기 때문에 가능합니다. 이를 통해 하나의 항목에 대해 여러 클래스를 지정할 수 있습니다(단 하나의 STRUCTURAL objectClass만 존재할 수 있고 있어야 함). 그 결과 객체는 가장 엄격한 MUST 또는 MAY 선언으로 병합된 속성 모음에 액세스할 수 있습니다. 우선합니다.

정의에서 objectClass는 속성을 상속할 상위 objectClass를 식별할 수 있습니다. 이것은 SUP 다음에 상속할 objectClass를 사용하여 수행됩니다. 예를 들어 organizationalPerson objectClass는 다음과 같이 시작합니다.

objectclass ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
 . . .

SUP 식별자 다음의 objectClass는 상위 objectClass입니다. 부모는 정의되는 objectClass의 objectClass 유형을 공유해야 합니다(예: STRUCTURAL 또는 AUXILIARY). 자식 objectClass는 자동으로 부모의 속성 및 속성 요구 사항을 상속합니다.

항목에 objectClass를 할당할 때 상속 체인의 가장 구체적인 자손만 지정하면 끝까지 속성에 액세스할 수 있습니다. 마지막 섹션에서 이를 사용하여 person 및 organizationalPerson에 정의된 속성에 계속 액세스하면서 inetOrgPerson을 John Smith 항목의 유일한 objectClass로 지정했습니다. 객체 클래스. inetOrgPerson 상속 계층 구조는 다음과 같습니다.

inetOrgPerson -> organizationalPerson -> person -> top

거의 모든 objectClass 상속 트리는 "top\이라는 특수 objectClass로 끝납니다. 이것은 objectClass 자체를 설정하도록 요구하는 유일한 목적을 가진 추상 objectClass입니다. 이것은 상속 체인의 최상위를 나타내는 데 사용됩니다.

속성 상속

비슷한 방식으로 속성 자체는 정의 중에 상위 속성을 나열할 수 있습니다. 그런 다음 특성은 상위 특성에 설정된 속성을 상속합니다.

일반 속성의 보다 구체적인 버전을 만드는 데 자주 사용됩니다. 예를 들어, 성은 이름의 한 유형이며 같은 방법을 모두 사용하여 동등성을 비교하고 확인할 수 있습니다. 이러한 특성을 상속하여 "이름\ 속성의 일반적인 형식을 얻을 수 있습니다. 사실 실제 성 정의에는 상위 속성에 대한 포인터만 포함될 수 있습니다.

이는 일반적인 형식이 변경되지 않은 경우에도 요소를 해석하는 사람들에게 유용한 특정 속성을 생성할 수 있기 때문에 유용합니다. 여기에서 논의한 성 속성의 상속은 사람들이 성과 보다 일반적인 이름을 구별하는 데 도움이 되지만 값의 의미 외에 LDAP 시스템에서 성과 이름 사이에는 거의 차이가 없습니다.

LDAP 프로토콜 변형

우리는 처음에 LDAP가 실제로 디렉터리 서비스 작업을 위한 통신 인터페이스를 정의하는 프로토콜일 뿐이라고 언급했습니다. 이것은 일반적으로 LDAP 또는 ldap 프로토콜로 알려져 있습니다.

일반 형식에서 몇 가지 변형을 볼 수 있음을 언급할 가치가 있습니다.

  • ldap://: 디렉토리 서비스에 대한 구조화된 액세스를 허용하는 기본 LDAP 프로토콜입니다.
  • ldaps://: 이 변형은 SSL/TLS를 통한 LDAP를 나타내는 데 사용됩니다. 대부분의 LDAP 구현이 이를 지원하지만 일반 LDAP 트래픽은 암호화되지 않습니다. LDAP 연결을 암호화하는 이 방법은 실제로 더 이상 사용되지 않으며 대신 STARTTLS 암호화를 사용하는 것이 좋습니다. 안전하지 않은 네트워크에서 LDAP를 운영하는 경우 암호화를 적극 권장합니다.
  • ldapi://: 이것은 IPC를 통한 LDAP를 나타내는 데 사용됩니다. 이것은 종종 관리 목적으로 로컬 LDAP 시스템과 안전하게 연결하는 데 사용됩니다. 노출된 네트워크 포트를 사용하는 대신 내부 소켓을 통해 통신합니다.

세 가지 형식 모두 LDAP 프로토콜을 사용하지만 마지막 두 형식은 사용 방법에 대한 추가 정보를 나타냅니다.

결론

LDAP 프로토콜과 LDAP 구현이 사용자에게 데이터를 나타내는 방식을 상당히 잘 이해하고 있어야 합니다. 시스템의 요소가 서로 어떻게 관련되어 있고 속성을 가져오는 위치를 이해하면 LDAP 시스템을 더 간단하고 예측 가능하게 관리하고 사용할 수 있습니다.