LDAP 편집하기
최신판 | 당신의 편집 | ||
1번째 줄: | 1번째 줄: | ||
− | '''LDAP'''(Lightweight Directory Access Protocol)는 네트워크상에서 조직이나 개인, [[파일]], [[디바이스]] 등을 찾아볼 수 있게 해 주는 [[소프트웨어]] [[프로토콜]]이다 | + | '''LDAP'''(Lightweight Directory Access Protocol)는 네트워크상에서 조직이나 개인, [[파일]], [[디바이스]] 등을 찾아볼 수 있게 해 주는 [[소프트웨어]] [[프로토콜]]이다. '''경량 디렉터리 액세스 프로토콜'''이라고도 한다. |
− | + | {{:자동차 배너}} | |
− | {{: | ||
== 개요 == | == 개요 == | ||
8번째 줄: | 7번째 줄: | ||
== 구조 == | == 구조 == | ||
; 인포메이션 모델 | ; 인포메이션 모델 | ||
+ | |||
인포메이션 모델은 [[데이터]]의 형태와 데이터를 통해 디렉터리 구조로 정보를 저장하는 방식에 관한 것이다. LDAP 디렉터리에서 표현하는 정보 구조는 두 가지 요소로 이루어진다. 엔트리(Entry)는 디렉터리에서 정보를 표현하는 기본 단위이다. 엔트리는 다수의 애트리뷰트(Attribute)로 구성된다. 애트리뷰트는 엔트리의 각 타입을 저장하는 공간으로 1개의 애트리뷰트에 하나, 또는 다수의 값을 담을 수 있다. LDAP 디렉터리 구조는 이러한 엔트리 데이터들을 트리 구조로 형성하고 관리한다. 그리고 이러한 트리 형태의 구조를 DIT(Directory information Tree)라고 한다. 추가적으로 LDAP 디렉터리에서 데이터를 구성하는데 중요한 오브젝트 클래스(ObjectClass)와 스키마(Schema)라는 개념이 있다. 오브젝트 클래스는 엔트리에서 꼭 필요하거나 가질 수 있는 애트리뷰트 타입을 정의한다. 엔트리를 만들 때 오브젝트 클래스를 통해 데이터에 필수적으로 들어가야 하는 정보를 담을 수 있게 정의할 수 있다. 또한 오브젝트 클래스는 다른 오브젝트 클래스를 상속해 구현하며 개념을 확장할 수 있다. 스키마는 오브젝트 클래스와 애트리뷰트에 대해 정의하는 규칙으로 보면 된다. 오브젝트 클래스에 어떤 애트리뷰트가 들어갈지, 애트리뷰트의 값에 대한 제약 및 조건 등 관련된 규칙들을 정의할 수 있다. 스키마 정의를 통해 여러 응용 프로그램에서 디렉터리 서비스를 읽고 사용할 때 상호운용성을 보호해주는 역할을 한다. | 인포메이션 모델은 [[데이터]]의 형태와 데이터를 통해 디렉터리 구조로 정보를 저장하는 방식에 관한 것이다. LDAP 디렉터리에서 표현하는 정보 구조는 두 가지 요소로 이루어진다. 엔트리(Entry)는 디렉터리에서 정보를 표현하는 기본 단위이다. 엔트리는 다수의 애트리뷰트(Attribute)로 구성된다. 애트리뷰트는 엔트리의 각 타입을 저장하는 공간으로 1개의 애트리뷰트에 하나, 또는 다수의 값을 담을 수 있다. LDAP 디렉터리 구조는 이러한 엔트리 데이터들을 트리 구조로 형성하고 관리한다. 그리고 이러한 트리 형태의 구조를 DIT(Directory information Tree)라고 한다. 추가적으로 LDAP 디렉터리에서 데이터를 구성하는데 중요한 오브젝트 클래스(ObjectClass)와 스키마(Schema)라는 개념이 있다. 오브젝트 클래스는 엔트리에서 꼭 필요하거나 가질 수 있는 애트리뷰트 타입을 정의한다. 엔트리를 만들 때 오브젝트 클래스를 통해 데이터에 필수적으로 들어가야 하는 정보를 담을 수 있게 정의할 수 있다. 또한 오브젝트 클래스는 다른 오브젝트 클래스를 상속해 구현하며 개념을 확장할 수 있다. 스키마는 오브젝트 클래스와 애트리뷰트에 대해 정의하는 규칙으로 보면 된다. 오브젝트 클래스에 어떤 애트리뷰트가 들어갈지, 애트리뷰트의 값에 대한 제약 및 조건 등 관련된 규칙들을 정의할 수 있다. 스키마 정의를 통해 여러 응용 프로그램에서 디렉터리 서비스를 읽고 사용할 때 상호운용성을 보호해주는 역할을 한다. | ||
; 네이밍 모델 | ; 네이밍 모델 | ||
+ | |||
네이밍 모델은 LDAP 디렉토리 구조에서 각 엔트리를 어떻게 식별하고 구성하는지에 대해 설명한다. 엔트리는 여러 자식 엔트리들을 가지는 형태의 트리 구조로 나타난다. 각 엔트리 계층에서는 해당 계층을 나타내는 고유한 주소 애트리뷰트를 지니는데, 이를 RDN(Relative Distinguished Name)이라고 부른다. 엔트리 옆에 적힌 "OU=People", "CN=Gerald Carter"와 같은 값은 해당 계층을 나타내는 고유한 주소 애트리뷰트에 해당한다. 이렇게 트리 구조에서 각 엔트리마다 존재하는 RDN 값들을 통해 원하는 경로에 있는 엔트리 정보를 찾을 수 있다. 또한 경로 내 RDN값들을 이어 붙여 생성된 고유한 문자를 DN(Distinguished Name)이라고 부른다. LDAP의 DIT 형태에서 가장 위에 존재하는 엔트리는 DIT의 시작점, 데이터 트리의 루트로 보며 하나의 데이터셋으로 이해할 수 있다. | 네이밍 모델은 LDAP 디렉토리 구조에서 각 엔트리를 어떻게 식별하고 구성하는지에 대해 설명한다. 엔트리는 여러 자식 엔트리들을 가지는 형태의 트리 구조로 나타난다. 각 엔트리 계층에서는 해당 계층을 나타내는 고유한 주소 애트리뷰트를 지니는데, 이를 RDN(Relative Distinguished Name)이라고 부른다. 엔트리 옆에 적힌 "OU=People", "CN=Gerald Carter"와 같은 값은 해당 계층을 나타내는 고유한 주소 애트리뷰트에 해당한다. 이렇게 트리 구조에서 각 엔트리마다 존재하는 RDN 값들을 통해 원하는 경로에 있는 엔트리 정보를 찾을 수 있다. 또한 경로 내 RDN값들을 이어 붙여 생성된 고유한 문자를 DN(Distinguished Name)이라고 부른다. LDAP의 DIT 형태에서 가장 위에 존재하는 엔트리는 DIT의 시작점, 데이터 트리의 루트로 보며 하나의 데이터셋으로 이해할 수 있다. | ||
; 범함수 모델 | ; 범함수 모델 | ||
+ | |||
범함수 모델(Functional)은 LDAP 디렉토리에서 작업하는 명령을 다룬다. 보통 8가지의 작업 명령을 나누게 되고, 작업 명령의 기능에 따라 3가지로 구분한다. | 범함수 모델(Functional)은 LDAP 디렉토리에서 작업하는 명령을 다룬다. 보통 8가지의 작업 명령을 나누게 되고, 작업 명령의 기능에 따라 3가지로 구분한다. | ||
31번째 줄: | 33번째 줄: | ||
; Security 모델 | ; Security 모델 | ||
+ | |||
디렉토리에 접근하는 사용자 인증과 데이터 접근 권한을 통해 서비스를 보호하는 방식에 대해 설명한다. SSL/TLS 인증 방식을 통해 서버-클라이언트 간 연결을 구성할 수 있으며, 데이터 전송 시 바이너리 암호화를 적용해 정보를 보호한다. LDAP v3 버전에서는 기존의 보안 방식뿐만 아니라 외부의 인증 방법을 제공할 수 있는 SASL 방식도 제공한다.<ref name="장영준"></ref> | 디렉토리에 접근하는 사용자 인증과 데이터 접근 권한을 통해 서비스를 보호하는 방식에 대해 설명한다. SSL/TLS 인증 방식을 통해 서버-클라이언트 간 연결을 구성할 수 있으며, 데이터 전송 시 바이너리 암호화를 적용해 정보를 보호한다. LDAP v3 버전에서는 기존의 보안 방식뿐만 아니라 외부의 인증 방법을 제공할 수 있는 SASL 방식도 제공한다.<ref name="장영준"></ref> | ||
37번째 줄: | 40번째 줄: | ||
검색 및 읽기 처리 방식에도 차이가 있다. LDAP은 저장된 데이터를 신속하게 조회하기 위해 단순 쿼리 위주로 작업을 처리한다. 하지만 관계형 데이터베이스는 여러 데이터, 테이블들의 관계를 통해 필요한 데이터를 종합적으로 가져오는 복합적 쿼리를 처리하는 작업에 중점을 둔다. 읽기와 달리 추가, 삭제와 같은 쓰기 작업에서는 관계형 데이터베이스보다 안정성이 떨어진다. 관계형 데이터베이스와 다르게 트랜잭션과 같은 유효성 검사가 제한적이기에 쓰기보다 읽기 작업이 많은 데이터 서비스에 주로 활용한다.<ref name="장영준"></ref> | 검색 및 읽기 처리 방식에도 차이가 있다. LDAP은 저장된 데이터를 신속하게 조회하기 위해 단순 쿼리 위주로 작업을 처리한다. 하지만 관계형 데이터베이스는 여러 데이터, 테이블들의 관계를 통해 필요한 데이터를 종합적으로 가져오는 복합적 쿼리를 처리하는 작업에 중점을 둔다. 읽기와 달리 추가, 삭제와 같은 쓰기 작업에서는 관계형 데이터베이스보다 안정성이 떨어진다. 관계형 데이터베이스와 다르게 트랜잭션과 같은 유효성 검사가 제한적이기에 쓰기보다 읽기 작업이 많은 데이터 서비스에 주로 활용한다.<ref name="장영준"></ref> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{{각주}} | {{각주}} |