디렉터리 데이터베이스 구성

Red Hat Directory Server 12

Red Hat Directory Server 데이터베이스 구성 및 관리

Red Hat Customer Content Services

초록

데이터베이스, 접미사, 연결 정책, 데이터베이스 링크 및 추천을 구성할 수 있습니다. 가상 디렉터리 트리를 사용하여 사용자 지정 그룹화 또는 계층 구조의 항목을 구성합니다.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 이를 개선할 수 있는지 알려 주십시오. 이렇게 하려면 다음을 수행합니다.

  • Jira (계정 필요)를 통해 피드백을 제출하려면 다음을 수행합니다.

    1. Jira 웹 사이트에 로그인합니다.
    2. 상단 탐색 모음에서 생성 을 클릭합니다.
    3. 요약 필드에 설명 제목을 입력합니다.
    4. 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
    5. 대화 상자 하단에서 생성 을 클릭합니다.
  • Bugzilla (계정 필요)를 통해 피드백을 제출하려면 다음을 수행합니다.

    1. Bugzilla 웹 사이트로 이동하십시오.
    2. 구성 요소로 문서를 사용합니다.
    3. 설명 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
    4. 버그 제출을 클릭합니다.

1장. 별도의 데이터베이스에 접미사 저장

인스턴스의 데이터를 여러 데이터베이스로 나누어 Directory Server에서 분산 데이터 스토리지 논리를 설계할 수 있습니다. 디렉터리 트리의 접미사를 데이터 분할 방법으로 사용할 수 있습니다.

여러 디렉터리 트리를 생성하고 루트 접미사로 별도의 데이터베이스에 저장할 수 있습니다. 단일 디렉터리 트리를 분기로 분할하고 하위 제안에 의해 별도의 데이터베이스에 분기를 저장할 수도 있습니다.

1.1. 데이터 구조에서 접미사의 역할

Directory Server는 디렉터리 트리 트리(DIT)라는 계층 구조로 데이터를 제공합니다. 다음은 간단한 디렉터리 트리입니다.

그림 1.1. 단일 루트 접미사가 있는 간단한 디렉터리 트리

디렉터리 트리 간단한

각 디렉터리 트리에는 dc=example,dc=com 과 같이 해당 디렉터리 트리의 이름 지정 컨텍스트를 정의하는 단일 루트 항목이 있습니다.

다양한 디렉터리 트리를 다른 데이터베이스에 저장한 다음 이러한 데이터베이스를 여러 서버에 배포할 수 있습니다.

접미사를 사용하여 데이터 스토리지의 배포 논리를 정의할 수 있습니다. 접미사는 디렉터리 트리의 분기(하위 트리)를 특정 데이터베이스와 연결합니다.

이렇게 하면 서버의 단일 인스턴스에 여러 개의 데이터베이스를 포함할 수 있습니다. 단일 데이터베이스에 국한되지 않습니다.

1.2. 루트 접미사 vs. sub-suffixes

루트 접미사는 전체 디렉터리 트리(DIT)를 데이터베이스와 연결합니다. 루트 접미사에는 상위 접미사가 없습니다.

디렉터리 트리의 분기를 별도의 데이터베이스에 저장하려는 경우, 트리 분기를 분기와 다른 데이터베이스와 연결하는 하위 제안을 생성합니다. 상위 접미사에 하위suffix를 연결해야 합니다. 상위 접미사는 루트 접미사 또는 하위 항목일 수 있습니다. 즉, 하위 트리의 분기를 별도의 데이터베이스에 저장할 수 있습니다.

그림 1.2. 별도의 데이터베이스에 하위 계정이 있는 디렉터리 트리

다른 데이터베이스가 있는 디렉터리 트리

이 예에서는 ou=people,dc=example,dc=com 하위 suffix가 한 데이터베이스에 저장되고 루트 접미사 아래의 나머지 디렉터리 트리는 다른 데이터베이스에 저장됩니다.

subsuffixes를 사용할 때의 이점:

  • 세분화된 수준에서 데이터베이스 유지 관리(가져오기/내보딩/인덱싱)를 수행할 수 있습니다.
  • 하위 조건을 별도의 디스크에 저장할 수 있으므로 디스크 공간 문제가 해결됩니다.

subsuffixes를 사용하는 방법:

  • 설정 시 더 많은 관리 작업이 필요합니다.
  • 복제에는 각 하위 시스템에 대한 별도의 구성 및 복제 계약이 필요합니다.

1.3. 여러 루트 접미사

단일 인스턴스에서 서로 다른 루트 접미사가 있는 여러 디렉터리 트리 트리(DIT)를 사용할 수도 있습니다. 예를 들어 일부 데이터 부분을 사용자 루트와 분리하려는 경우입니다.

그림 1.3. 루트 접미사로 정의된 여러 디렉터리 트리 트리

디렉터리 트리 다중 루트

클라이언트가 dc=example,dc=com 트리를 검색할 때 검색은 검색 알고리즘에 대한 제한이 부족하기 때문에 검색에서 다른 트리 트리의 항목을 반환하지 않습니다.

그런 다음 인스턴스의 기본 디렉터리 트리 및 이름 지정 컨텍스트를 선택할 수 있습니다.

1.4. 명령줄을 사용하여 루트 접미사 생성

이 절차에서는 명령줄에서 디렉터리 트리의 루트 접미사를 생성하는 방법을 설명합니다.

절차

  1. 선택 사항: 이미 사용 중인 접미사 및 백엔드 데이터베이스를 나열합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
    dc=example,dc=com (userroot)

    대괄호로 있는 이름은 해당 접미사의 데이터를 저장하는 백엔드 데이터베이스입니다. 다음 단계에서 루트 접미사를 생성할 때는 기존 데이터베이스 이름을 사용할 수 없습니다.

  2. --suffix 인수에서 루트 접미사의 DN을 지정하고 --be-name 인수를 사용하여 새 데이터베이스와 연결합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend create --suffix="dc=example,dc=net" --be-name="example"

검증

  • 이 절차의 첫 번째 단계의 명령을 사용하여 접미사 및 데이터베이스를 나열합니다.

1.5. 웹 콘솔을 사용하여 루트 접미사 생성

다음 절차에서는 브라우저에서 디렉터리 트리의 루트 접미사를 생성하는 방법을 설명합니다.

사전 요구 사항

  • 웹 콘솔에서 인스턴스에 로그인되어 있습니다.

절차

  1. Database (데이터베이스)에서 구성 트리 아래에 있는 Create Suffix 버튼을 클릭합니다.
  2. Suffix DN데이터베이스 이름을 입력합니다.
  3. Create the top Suffix Entry 을 선택하고 Create Suffix 를 클릭합니다.

검증

  • 새 접미사는 접미사 트리에 표시되어야 합니다.

1.6. 기본 이름 지정 컨텍스트 변경

이름 지정 컨텍스트는 해당 DIT의 항목에 대한 루트 네임스페이스를 정의하는 디렉터리 트리(DIT)의 속성입니다. 여러 루트 접미사가 있는 인스턴스에서 데이터를 구성할 때 각각 다른 이름 지정 컨텍스트를 사용하여 인스턴스에 여러 개의 DIT가 있습니다.

이 절차에서는 인스턴스에서 여러 루트 접미사로 작업할 때 명령줄에 대한 기본 이름 지정 컨텍스트를 변경하는 방법을 설명합니다.

인스턴스에 액세스하는 클라이언트는 사용해야 하는 이름 지정 컨텍스트를 인식하지 못할 수 있습니다. Directory Server는 클라이언트에 알려진 이름 지정 컨텍스트의 다른 구성이 없는 경우 클라이언트에 기본 이름 지정 컨텍스트를 신호를 보냅니다.

cn=confignsslapd-defaultnamingcontext 속성에 기본 이름 지정 컨텍스트를 설정합니다. Directory Server는 이 값을 Directory Server Agent Service Entry(루트 DSE)에 전파하고 클라이언트가 이 값을 비정상적으로 쿼리할 수 있습니다.

사전 요구 사항

  • 인스턴스의 기본 이름 지정 컨텍스트를 정의하는 루트 접미사를 생성했습니다.

절차

  1. 선택 사항: 현재 기본 이름 지정 컨텍스트를 확인합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com config get nsslapd-defaultnamingcontext
    nsslapd-defaultnamingcontext: dc=example,dc=com
  2. nsslapd-defaultnamingcontext 매개변수 값을 필수 이름 지정 컨텍스트로 바꿉니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-defaultnamingcontext=dc=example,dc=net

검증

  • 현재 기본 이름 지정 컨텍스트를 봅니다. 값을 업데이트해야 합니다.

1.7. 명령줄을 사용하여 sub-suffix 생성

명령줄을 사용하여 디렉터리 트리의 하위 파일을 생성할 수 있습니다.

사전 요구 사항

  • sub-suffix의 상위 접미사를 생성하셨습니다.

절차

  1. 선택 사항: 이미 사용 중인 접미사 및 백엔드 데이터베이스를 나열합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
    dc=example,dc=com (userroot)

    대괄호로 있는 이름은 해당 접미사의 데이터를 저장하는 백엔드 데이터베이스입니다. 다음 단계에서 sub-suffix를 생성할 때는 기존 데이터베이스 이름을 사용할 수 없습니다.

  2. --suffix 인수에서 하위 리소스의 전체 DN을 지정하고 --be-name 인수를 사용하여 새 데이터베이스와 연결한 다음 --parent-suffix 인수에서 상위 접미사를 지정합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend create --suffix="ou=People,dc=example,dc=com" --be-name="example" --parent-suffix="dc=example,dc=com" --create-suffix

    --create-suffix 인수를 사용하면 이 명령은 sub-suffix에 대한 구성 항목을 생성하고 하위 항목 ou=People,dc=example,dc=com.

    --create-suffix 인수는 c,cn,dc,oou 와 같은 RDN 특성 유형을 사용하여 접미사 생성을 지원합니다. l 과 같은 RDN 접미사를 생성하려면 --create-suffix 옵션 없이 dsconf backend create 명령을 사용한 다음 LDAP 추가 작업을 사용하거나 LDIF 파일에서 항목을 가져와서 접미사 항목을 추가할 수 있습니다.

검증

  • 이 절차의 첫 번째 단계의 명령을 사용하여 접미사 및 데이터베이스를 나열합니다.

1.8. 웹 콘솔을 사용하여 하위suffix 생성

이 절차에서는 브라우저에서 디렉터리 트리의 하위 항목을 생성하는 방법을 설명합니다.

사전 요구 사항

  • 웹 콘솔에서 인스턴스에 로그인되어 있습니다.
  • sub-suffix의 상위 접미사를 생성하셨습니다.

절차

  1. 데이터베이스 아래에서 구성 트리의 상위 항목인 접미사를 선택합니다.
  2. Suffix Tasks 를 클릭하고 Create Sub-Suffix 를 선택합니다.
  3. ou=People 과 같은 Sub-Suffix DN 을 입력하고 데이터베이스 이름을 입력합니다.
  4. Create the top Suffix Entry 을 선택하고 Create Sub-Suffix 를 클릭합니다.

검증

  • 새 하위 수정은 구성 트리의 접미사 사이에 표시되어야 합니다.

2장. 보기를 사용하여 가상 디렉터리 계층 구조 생성

가상 디렉터리 트리(DIT) 뷰를 생성하여 사용자 지정 그룹 또는 계층에서 항목을 구성하고 다양한 관점에서 표준 DIT를 탐색할 수 있습니다. 이렇게 하면 디렉토리 관리에 대한 비용을 절약하고 서비스 사용자에게 보다 직관적인 항목을 통해 탐색할 수 있습니다.

2.1. 보기 정보

가상 디렉터리 트리 뷰 또는 는 DIT에서 항목을 분류하고 검색하는 표준 디렉터리 트리(DIT) 외에도 선택적 구조 계층입니다.

보기를 사용하여 표준 DIT에 배치하지 않고도 항목을 쉽게 탐색할 수 있도록 가상 디렉터리 계층을 생성할 수 있습니다. 뷰는 필터링된 역할 또는 동적 그룹의 멤버와 유사하게 가상 계층에 항목을 포함하는 항목의 특성을 사용합니다. 클라이언트 애플리케이션에는 보기가 일반 컨테이너 계층 구조로 표시됩니다.

이렇게 하면 처음에는 플랫 DIT에 항목을 배치하고 뷰를 사용하여 항목을 이동할 필요 없이 복잡한 계층 구조로 항목을 분류할 수 있습니다. 또한 표준 DIT를 사용하여 수행할 수 없는 항목이 여러 뷰에 표시될 수 있습니다.

뷰는 이름이 지정된 필터 로 생각할 수 있습니다. 각 보기는 nsView 개체 클래스의 항목이며 해당 보기에서 표시되는 항목을 나타내는 nsViewFilter 특성을 가질 수 있습니다. 필터에서 개체 클래스를 지정하여 반환할 항목 유형을 제한하는 것이 좋습니다.

뷰를 다른 뷰의 컨테이너로 사용하여 가상 계층 구조를 생성할 수 있습니다. 중첩 뷰는 (&(컨테이너 필터)(view filter)와 같은 필터 시부 필터를 결합하여 뷰를 상속하고 뷰 를 제한합니다.

검색이 기본으로 보기를 사용하여 수행되면 필터와 일치하는 항목이 이 가상 검색 공간에서 반환됩니다. 항목은 사실상 보기 아래에 중첩되는 것으로 표시되지만 실제로 DIT의 어느 위치에든 저장할 수 있습니다.

참고

테스트 인스턴스를 생성하고 /usr/share/dirsrv/data/Example-views.ldif 에 있는 예제 파일에서 가져온 데이터에 대한 보기가 작동하는 방법을 확인할 수 있습니다.

2.2. 디렉터리 설계 고려 사항

디렉터리 트리(DIT)를 설계할 때 조직의 계층 구조를 반영하기 위해 계층 구조를 사용하여 항목을 분류하는 경향이 있습니다. 뷰가 없는 표준 DIT는 DIT의 항목 위치와 해당 항목의 고유 이름(DN)과 연결되어 있으므로 고정 계층과 함께 사용하는 것이 더 적합합니다.

그림 2.1. 기능 단위를 기반으로 하는 표준 계층 DIT

표준 디스크 보기

그러나 조직에서 계층 구조의 특성은 동적입니다. 항목 위치가 변경될 때마다 항목 및 하위 항목을 모두 변경해야 하기 때문에 표준 DIT에서 항목을 이동하는 것은 시간이 오래 걸립니다. 이로 인해 서비스 중단 및 추가 비용, 특히 최상위 하위 트리 변경으로 이어집니다.

리소스 유형(people, equipment 등)과 같이 리소스 유형(people, equipment 등)과 같이 리소스 분류를 분류하여 이 계층을 표준 플랫 DIT로 캡처하는 것이 좋습니다.

그림 2.2. 리소스 유형에 따른 표준 플랫 DIT

플랫 디스크 보기

그러나 플랫 DIT는 리소스를 탐색하는 데 편리하지 않습니다. 다른 사용자는 플랫 DIT의 경우 추가 도구 또는 복잡한 검색 쿼리가 필요한 기능 단위 또는 지리적 위치와의 연결과 같은 다른 관점에서 리소스를 탐색해야 합니다.

플랫 DIT의 제한 사항을 해결하는 솔루션은 가상 계층 구조에서 제공합니다. 뷰를 사용하면 항목의 이름을 계층 항목의 위치와 분리하여 유연한 계층을 만들 수 있습니다. 가상 계층은 대신 속성을 기반으로 합니다.

그림 2.3. 뷰의 가상 계층 사용DIT With Virtual Hierarchies of Views

가상 디스크 보기

2.3. 뷰 사용의 이점

가상 디렉터리 트리 뷰를 사용하면 사용자가 탐색하기가 더 직관적인 사용자 정의 유연한 계층 구조의 장점이 있습니다.DIT(단계 트리 트리)보다 더 효율적으로 유지 관리할 수 있습니다.

유연하고 유연한 이름 지정

가상 DIT 보기에서는 기존 계층 구조에서 제공하는 것과 유사한 탐색 및 관리 지원을 제공하기 때문에 보기에서 플랫 네임스페이스를 쉽게 사용할 수 있습니다.

DIT가 변경될 때마다 항목을 이동하지 않아도 됩니다. 가상 DIT 보기 계층만 변경됩니다. 이러한 계층 구조에는 실제 항목이 포함되어 있지 않으므로 간단하고 빠르게 수정할 수 있습니다.

설계 오류 발생 시 비용 절감
배포 계획 중 감독은 가상 DIT 뷰에서 덜 치명적입니다. 첫 번째 인스턴스에서 계층 구조가 올바르게 개발되지 않으면 서비스를 중단하지 않고 쉽고 빠르게 변경할 수 있습니다.
빠르고 저렴한 유지 관리

보기 계층은 몇 분 내에 완전히 수정될 수 있으며 결과를 즉시 실현하여 디렉토리 유지 관리 비용을 크게 절감할 수 있습니다.

가상 DIT 계층 구조 변경은 즉시 실현됩니다. 조직 변경이 발생하면 새로운 가상 DIT 보기를 빠르게 생성할 수 있습니다. 새로운 가상 DIT 보기는 이전 보기와 동시에 존재할 수 있으므로 항목 자체 및 이를 사용하는 애플리케이션에 대해 보다 점진적으로 변경될 수 있습니다. 디렉터리의 조직 변경은 일괄 처리 작업이 아니므로 서비스 중단 없이 일정 기간 동안 수행될 수 있습니다.

전반적인 유연성 향상

탐색 및 관리에 여러 가상 DIT 보기를 사용하면 디렉터리 서비스를 보다 유연하게 사용할 수 있습니다.

가상 DIT 보기에서 제공하는 기능을 통해 조직은 DIT의 특정 위치에 항목을 배치하지 않고도 이전 방법과 새로운 방법을 모두 사용하여 디렉터리 데이터를 구성할 수 있습니다.

직관적인 사용자 탐색

뷰는 작업 관행의 유연성을 높이고 디렉터리 사용자가 복잡한 검색 필터를 생성하는 요구 사항을 줄일 수 있으며, 그렇지 않으면 알 필요가 없는 속성 이름과 값을 사용합니다.

디렉터리 정보를 보고 쿼리하는 방법에 대한 유연성을 통해 최종 사용자와 애플리케이션이 계층 탐색을 통해 직관적으로 필요한 항목을 찾을 수 있습니다.

자주하는 검색 쿼리를 위한 바로 가기
가상 DIT 보기 계층은 자주 필요한 정보를 쉽게 검색할 수 있도록 준비된 일종의 쿼리로 만들 수 있습니다.

2.4. 다른 기능과 보기의 호환성

뷰를 사용하여 작업할 때 검색 공간은 단일 접미사가 있는 항목으로 제한됩니다. 사용자는 가상 계층에서 결과를 얻으려면 검색 쿼리의 기반을 만들어야 합니다. 액세스 제어에는 약간 다른 접근 방식을 취해야 합니다. 보기의 역할 및 서비스 클래스와 함께 항목 그룹화를 사용할 수 있습니다.

다중 백엔드

가상 DIT 보기는 여러 백엔드와 완전히 호환되지 않습니다.

검색은 단일 백엔드로 제한되며, 이는 보기에서 반환할 항목이 동일한 접미사 아래에 있어야 함을 의미합니다.

검색 공간

가상 검색 공간은 표준 검색 공간과 다릅니다. 가상 검색 공간은 필터가 있는 뷰 노드를 기반으로 하는 경우에만 검색에 액세스할 수 있습니다. 그렇지 않으면 가상 DIT 계층에 포함된 항목을 반환하지 않는 기존의 DIT(표준 디렉터리 트리)를 검색합니다.

예를 들어 dc=example,dc=com 을 기반으로 하는 검색에서는 가상 검색 공간 보기에서 항목을 반환하지 않습니다. 실제로는 virtual-search-space 검색이 수행되지 않습니다. 검색 기반이 ou=Cupertino,ou=Location Views,dc=example,dc=com 과 같은 경우 보기 처리가 수행됩니다.

이렇게 하면 Directory Server가 검색에 두 위치의 항목이 발생하지 않도록 합니다.

액세스 제어
뷰를 사용하려면 액세스 제어를 위해 약간 다른 접근 방식이 필요합니다. 현재 보기에서 ACL(액세스 제어 목록)을 명시적으로 지원하지 않으므로 view 상위에 역할 기반 ACL을 생성하고 뷰 계층의 적절한 부분에 역할을 추가합니다. 이러한 방식으로 계층의 조직 속성을 활용합니다.
항목 그룹화
Directory Server 의 클래스역할 모두 뷰를 지원합니다. 보기 계층 구조에서 서비스 클래스 또는 역할 클래스를 추가할 때 논리적으로 그리고 실제로 보기에 포함된 항목은 범위 내에서 간주됩니다. 즉, 가상 DIT 보기를 사용하여 역할서비스 클래스 를 적용할 수 있지만 flat 네임스페이스를 쿼리할 때 해당 애플리케이션의 영향을 확인할 수 있습니다.

2.5. 클라이언트 애플리케이션과 보기 호환성

가상 디렉터리 트리(DIT) 뷰는 표준 DIT를 높은 수준으로 모방하도록 설계되었습니다. 보기의 존재는 대부분의 애플리케이션에 투명해야 합니다. 뷰를 사용 중이라는 표시는 없어야 합니다. 몇 가지 특수 경우를 제외하고 디렉터리 사용자가 Directory Server 인스턴스에서 뷰가 사용되고 있음을 알 필요가 없습니다. 뷰는 표준 DITs처럼 보이고 작동합니다.

특정 유형의 애플리케이션은 보기 가능 디렉터리 서비스로 작업하는 데 문제가 있을 수 있습니다. 예를 들면 다음과 같습니다.

  • 대상 항목의 고유 이름(DN)을 사용하여 DIT를 탐색하는 애플리케이션입니다.

    이 유형의 애플리케이션은 항목이 발견된 보기 계층 구조 대신 항목이 물리적으로 존재하는 계층을 탐색하는 것을 찾습니다. 이 이유는 보기가 보기의 계층 구조를 준수하도록 항목의 DN을 변경하여 항목의 실제 위치를 위장하지 않기 때문입니다.

    이는 설계에 의한 것입니다 - 항목의 실제 위치가 위장된 경우 많은 애플리케이션이 작동하지 않습니다(예: DN을 사용하여 고유한 항목을 식별하는 애플리케이션). DN을 중단함으로써 이러한 외부 탐색은 클라이언트 애플리케이션에는 비정상적인 기술이지만, 이를 수행하는 클라이언트는 의도한 대로 작동하지 않을 수 있습니다.

  • numSubordinates 운영 특성을 사용하여 노드 아래에 있는 항목 수를 결정하는 애플리케이션입니다.

    보기에 있는 노드의 경우 현재 가상 검색 공간을 무시하고 표준 검색 공간에 존재하는 항목의 수입니다. 결과적으로 애플리케이션은 검색에서 보기를 평가하지 못할 수 있습니다.

2.6. 뷰 생성

이 절차에서는 명령줄에서 가상 directory-tree 보기를 생성하는 방법을 설명합니다.

절차

  • ldapadd 유틸리티를 사용하여 view 항목을 추가합니다.

    nsView 오브젝트 클래스를 지정하고 nsViewFilter 특성에 view 필터를 정의합니다.

    # ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x
    dn: ou=PeopleInRoom0466,dc=example,dc=com
    objectClass: top
    objectClass: organizationalUnit
    objectClass: nsView
    ou: PeopleInRoom0466
    description: People in the room 0466
    nsViewFilter: (&(objectClass=inetOrgPerson)(roomNumber=0466))

검증

  • 뷰를 검색 기반으로 사용하여 검색을 수행합니다.

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b ou=PeopleInRoom0466,dc=example,dc=com

2.7. 명령줄을 사용하여 뷰의 성능을 개선하기 위해 인덱스 생성

보기는 지정된 필터를 기반으로 검색 결과에서 파생됩니다. 필터의 일부는 nsViewFilter 에서 명시적으로 지정된 속성입니다. 나머지 필터는 보기에 포함된 실제 항목의 entryidparentid 운영 속성을 찾는 항목 계층을 기반으로 합니다.

(|(parentid=search_base_id)(entryid=search_base_id)

검색된 속성( entryid,parentid, nsViewFilter 의 속성이 인덱싱되지 않음) 중 하나라도 있는 경우 검색이 부분적으로 인덱싱되지 않고 Directory Server에서 전체 디렉터리 트리를 일치하는 항목을 검색합니다.

뷰 성능을 개선하려면 다음과 같이 인덱스를 만듭니다.

  • entryid 에 대해 같음 인덱스 (eq)를 만듭니다. parentid 속성은 기본적으로 시스템 인덱스에서 인덱싱됩니다.
  • nsViewFilter 테스트 존재(attribute=*)의 필터가 있는 경우 테스트할 속성에 대해 현재 인덱스 (pres)를 생성합니다. 디렉터리 항목의 소수에 표시되는 속성에서만 이 인덱스 유형을 사용해야 합니다.
  • nsViewFilter 테스트 같음(attribute=value)의 필터가 테스트 중인 속성에 대해 같음 인덱스 (eq)를 생성합니다.
  • nsViewFilter 의 필터가 하위 문자열(attribute=value*)을 테스트하는 경우 테스트 중인 속성에 대해 하위 문자열 인덱스 (sub)를 만듭니다.
  • nsViewFilter 의 필터가 approximation(attribute~=value)을 테스트하는 경우 테스트 중인 속성에 대한대략적인 인덱스 (약점)를 생성합니다.

예를 들어 다음 뷰 필터를 사용하는 경우 다음을 수행합니다.

nsViewFilter: (&(objectClass=inetOrgPerson)(roomNumber=*66))

기본적으로 같음 인덱스를 사용하여 objectClass 를 인덱스 해야 하며, 부분 문자열 인덱스가 있는 roomNumber 를 사용해야 합니다.

사전 요구 사항

  • 뷰 필터에서 사용하는 속성을 알고 있습니다.

절차

  1. 선택 사항: 백엔드를 나열하여 데이터베이스를 인덱스로 결정합니다.

    # dsconf -D "cn=Directory Manager" instance_name backend suffix list
    dc=example,dc=com (userroot)

    선택한 데이터베이스 이름(함께 표시)을 기록해 둡니다.

  2. 선택한 백엔드 데이터베이스에 대해 dsconfig 유틸리티를 사용하여 인덱스 구성을 생성합니다.

    특히 국제화된 인스턴스의 경우 속성 이름, 인덱스 유형 및 일치하는 규칙을 지정하여 OID(Giversity Order)를 설정합니다.

    # dsconf -D "cn=Directory Manager" instance_name backend index add --attr roomNumber --index-type sub userroot

    view 필터에 사용되는 각 속성에 대해 이 단계를 반복합니다.

  3. 데이터베이스를 다시 인덱싱하여 새 인덱스를 적용합니다.

    # dsconf -D "cn=Directory Manager" instance_name backend index reindex userroot

검증

  1. 보기에서 사용하는 것과 동일한 필터를 사용하여 표준 디렉터리 트리를 기반으로 검색을 수행합니다.

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b dc=example,dc=com (&(objectClass=inetOrgPerson)(roomNumber=*66))
    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b dc=example,dc=com "(&(objectClass=inetOrgPerson)(roomNumber=*66))"
  2. /var/log/dirsrv/slapd-instance_name/ access 에서 액세스 로그를 봅니다.

    검색 RESULT 에 세부 정보에 note=U 또는 Partially Unindexed 필터 가 포함되어서는 안 됩니다.

추가 리소스

2.8. 웹 콘솔을 사용하여 뷰의 성능을 개선하기 위해 인덱스 생성

보기는 지정된 필터를 기반으로 검색 결과에서 파생됩니다. 필터의 일부는 nsViewFilter 에서 명시적으로 지정된 속성입니다. 나머지 필터는 보기에 포함된 실제 항목의 entryidparentid 운영 속성을 찾는 항목 계층을 기반으로 합니다.

(|(parentid=search_base_id)(entryid=search_base_id)

검색된 속성( entryid,parentid, nsViewFilter 의 속성이 인덱싱되지 않음) 중 하나라도 있는 경우 검색이 부분적으로 인덱싱되지 않고 Directory Server에서 전체 디렉터리 트리를 일치하는 항목을 검색합니다.

뷰 성능을 개선하려면 다음과 같이 인덱스를 만듭니다.

  • entryid 에 대해 같음 인덱스 (eq)를 만듭니다. parentid 속성은 기본적으로 시스템 인덱스에서 인덱싱됩니다.
  • nsViewFilter 테스트 존재(attribute=*)의 필터가 있는 경우 테스트할 속성에 대해 현재 인덱스 (pres)를 생성합니다. 디렉터리 항목의 소수에 표시되는 속성에서만 이 인덱스 유형을 사용해야 합니다.
  • nsViewFilter 테스트 같음(attribute=value)의 필터가 테스트 중인 속성에 대해 같음 인덱스 (eq)를 생성합니다.
  • nsViewFilter 의 필터가 하위 문자열(attribute=value*)을 테스트하는 경우 테스트 중인 속성에 대해 하위 문자열 인덱스 (sub)를 만듭니다.
  • nsViewFilter 의 필터가 approximation(attribute~=value)을 테스트하는 경우 테스트 중인 속성에 대한대략적인 인덱스 (약점)를 생성합니다.

예를 들어 다음 뷰 필터를 사용하는 경우 다음을 수행합니다.

nsViewFilter: (&(objectClass=inetOrgPerson)(roomNumber=*66))

기본적으로 같음 인덱스를 사용하여 objectClass 를 인덱스 해야 하며, 부분 문자열 인덱스가 있는 roomNumber 를 사용해야 합니다.

사전 요구 사항

  • 웹 콘솔에서 인스턴스에 로그인되어 있습니다.
  • 뷰 필터에서 사용하는 속성을 알고 있습니다.

절차

  1. 데이터베이스 아래에서 인덱스를 만들 구성 트리의 접미사를 선택합니다.
  2. 인덱스 및 데이터베이스 인덱스 로 이동합니다.
  3. 인덱스 추가 버튼을 클릭합니다.
  4. 특성 이름을 입력하고 특성을 선택합니다.
  5. 이 특성에 대해 생성해야 하는 인덱스 유형을 선택합니다.
  6. 필요한 경우 일치 규칙 을 추가하여 특히 국제화된 인스턴스의 경우 OID(Billions 순서)를 지정합니다.
  7. 인덱스를 만든 후 인덱스 특성을 선택하여 나중에 인덱스를 다시 작성합니다.
  8. 인덱스 생성을 클릭합니다.
  9. 인덱싱할 각 속성에 대해 단계를 반복합니다.

검증

  • 추가된 특성의 이름을 입력하여 필터링 합니다.
  • 새로 인덱싱된 특성이 결과에 표시되어야 합니다.

추가 리소스

3장. 데이터베이스를 읽기 전용 모드로 전환

Directory Server 데이터베이스는 기본적으로 읽기-쓰기 모드로 실행되며 사용자는 데이터를 검색하고 저장할 수 있습니다.

예를 들어 백업 전 또는 소비자를 수동으로 초기화하기 전에 또는 사용자가 항목을 생성, 수정 또는 삭제하지 못하도록 하는 읽기 전용 모드로 데이터베이스를 전환할 수 있습니다.

3.1. 사전 요구 사항

  • 데이터베이스는 읽기-쓰기 모드입니다.
  • 읽기 전용 모드를 활성화하면 복제가 비활성화되므로 데이터베이스가 복제에 사용되지 않습니다.

3.2. 명령줄을 사용하여 데이터베이스를 읽기 전용 모드로 전환

이 절차에서는 명령줄에서 Directory Server 데이터베이스를 읽기 전용 모드로 전환하는 방법을 지시합니다.

절차

  1. 접미사와 해당 데이터베이스를 나열합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
    dc=example,dc=com (userroot)
    o=test (test_database)

    전환하려는 데이터베이스의 이름 또는 접미사를 확인합니다.

  2. enable-readonly 매개변수를 사용하여 읽기 전용 모드를 활성화하고 name 또는 접미사로 데이터베이스를 지정합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix set --enable-readonly "test_database"

검증

  • 다음과 같은 디렉터리에 쓰기 작업을 시도합니다.

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x
    dn: dc=example,dc=com
    changetype: modify
    add: description
    description: foo

    서버가 실행을 거부해야 합니다.

    modifying entry "dc=example,dc=com"
    ldap_modify: Server is unwilling to perform (53)
    	additional info: Server is read-only

3.3. 웹 콘솔을 사용하여 데이터베이스를 읽기 전용 모드로 전환

이 절차에서는 브라우저에서 Directory Server 데이터베이스를 읽기 전용 모드로 전환하는 방법을 지시합니다.

사전 요구 사항

  • 웹 콘솔에서 인스턴스에 로그인되어 있습니다.

절차

  1. Database 아래로 구성 트리의 접미사를 선택합니다.
  2. Database Read-Only Mode 옵션을 선택합니다.
  3. Save Configuration 을 클릭합니다.

검증

  • 다음과 같은 디렉터리에 쓰기 작업을 시도합니다.

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x
    dn: dc=example,dc=com
    changetype: modify
    add: description
    description: foo

    서버가 실행을 거부해야 합니다.

    modifying entry "dc=example,dc=com"
    ldap_modify: Server is unwilling to perform (53)
    	additional info: Server is read-only

3.4. 추가 리소스

4장. 인스턴스를 읽기 전용 모드로 전환

기본적으로 인스턴스는 읽기-쓰기 모드로 실행되며 사용자는 데이터를 검색하고 저장할 수 있습니다. 예를 들어 복제를 방지하거나 데이터 수정을 비활성화하려는 경우와 같이 디렉터리를 계속 사용할 수 있지만 임시로 인스턴스를 읽기 전용 모드로 전환할 수 있습니다.

Directory Server가 두 개 이상의 데이터베이스를 유지하고 모든 데이터베이스를 읽기 전용으로 전환해야 하는 경우 명령줄 또는 웹 콘솔에서 단일 작업으로 이 작업을 수행할 수 있습니다.

주의

읽기 전용 모드에서는 인스턴스를 다시 시작할 수 없지만 구성을 계속 수정할 수 있습니다.

인스턴스를 읽기 전용 모드로 중지하면 읽기 전용 모드를 수동으로 비활성화할 때까지 다시 시작할 수 없습니다.

읽기 전용 모드를 수동으로 비활성화하려면 /etc/dirsrv/slapd-instance_name/dse.ldif 파일을 열고 cn=config 섹션으로 이동한 다음 nsslapd-readonly 매개변수를 off 로 설정합니다.

4.1. 사전 요구 사항

  • 인스턴스는 읽기-쓰기 모드입니다.
  • 읽기 전용 모드를 활성화하면 복제가 비활성화되므로 인스턴스가 복제에 사용되지 않습니다.

4.2. 명령줄을 사용하여 인스턴스를 읽기 전용 모드로 전환

이 절차에서는 명령줄에서 Directory Server 인스턴스를 읽기 전용 모드로 전환하는 방법을 지시합니다.

절차

  • nsslapd-readonly 매개변수를 on:로 설정합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-readonly=on

검증

  • 다음과 같은 디렉터리에 쓰기 작업을 시도합니다.

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x
    dn: dc=example,dc=com
    changetype: modify
    add: description
    description: foo

    서버가 실행을 거부해야 합니다.

    modifying entry "dc=example,dc=com"
    ldap_modify: Server is unwilling to perform (53)
    	additional info: Server is read-only

4.3. 웹 콘솔을 사용하여 인스턴스를 읽기 전용 모드로 전환

이 절차에서는 브라우저에서 Directory Server 인스턴스를 읽기 전용 모드로 전환하는 방법을 지시합니다.

사전 요구 사항

  • 웹 콘솔에서 인스턴스에 로그인되어 있습니다.

절차

  1. Server;에서 Advanced Settings 탭을 선택합니다.
  2. Server Read-Only 옵션을 선택합니다.
  3. 저장을 클릭합니다.

검증

  • 다음과 같은 디렉터리에 쓰기 작업을 시도합니다.

    # ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x
    dn: dc=example,dc=com
    changetype: modify
    add: description
    description: foo

    서버가 실행을 거부해야 합니다.

    modifying entry "dc=example,dc=com"
    ldap_modify: Server is unwilling to perform (53)
    	additional info: Server is read-only

5장. 더 이상 필요하지 않은 접미사의 데이터베이스 삭제

Directory Server 호스트의 디스크 공간을 회수해야하는 경우 더 이상 사용되지 않는 접미사의 데이터베이스를 삭제할 수 있습니다.

5.1. 명령줄을 사용하여 데이터베이스 삭제

다음 절차에서는 명령줄에서 Directory Server 데이터베이스를 삭제하는 방법을 설명합니다.

절차

  1. 접미사와 해당 데이터베이스를 나열합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
    dc=example,dc=com (userroot)
    o=test (test_database)

    삭제할 데이터베이스의 이름을 기록해 둡니다.

  2. dsconf backend delete 명령을 입력하고 데이터베이스 이름을 지정합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend delete "test_database"
  3. 프롬프트에 "예"를 입력하여 삭제를 확인합니다.

    Deleting Backend cn=test_database,cn=ldbm database,cn=plugins,cn=config :
    Type 'Yes I am sure' to continue: Yes I am sure

검증

  • 접미사/database를 나열합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
    dc=example,dc=com (userroot)

5.2. 웹 콘솔을 사용하여 데이터베이스 삭제

다음 절차에서는 브라우저에서 Directory Server 데이터베이스를 삭제하는 방법을 설명합니다.

사전 요구 사항

  • 웹 콘솔에서 인스턴스에 로그인되어 있습니다.

절차

  1. Database 에서 삭제할 접미사를 선택합니다.
  2. Suffix TasksDelete Suffix 로 이동합니다.
  3. Yes, I am sure를 선택합니다.
  4. Delete Suffix 를 클릭합니다.

검증

  • Database (데이터베이스)에서 구성 트리의 접미사 목록을 검토합니다.

6장. 백엔드 데이터베이스의 무결성 확인

Directory Server 데이터베이스 무결성 검사는 메타데이터 페이지 손상 및 중복 키 정렬과 같은 문제를 감지할 수 있습니다. 문제가 발견되면 문제에 따라 데이터베이스를 다시 인덱싱하거나 백업을 복원할 수 있습니다.

6.1. 데이터베이스 무결성 검사 수행

dsctl dbverify 명령을 사용하면 관리자가 백엔드 데이터베이스의 무결성을 확인할 수 있습니다.

절차

  1. 선택 사항: 인스턴스의 백엔드 데이터베이스를 나열합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
    dc=example,dc=com (userRoot)
  2. 인스턴스를 중지합니다.

    # dsctl instance_name stop
  3. 데이터베이스를 확인합니다. 예를 들어 userRoot 데이터베이스를 확인하려면 다음을 입력합니다.

    # dsctl instance_name dbverify userRoot
    [04/Feb/2022:13:11:02.453624171 +0100] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000
    [04/Feb/2022:13:11:02.465339507 +0100] - WARN - ldbm_instance_add_instance_entry_callback - ldbm instance userroot already exists
    [04/Feb/2022:13:11:02.468060144 +0100] - ERR - ldbm_config_read_instance_entries - Failed to add instance entry cn=userroot,cn=ldbm database,cn=plugins,cn=config
    [04/Feb/2022:13:11:02.471079045 +0100] - ERR - bdb_config_load_dse_info - failed to read instance entries
    [04/Feb/2022:13:11:02.476173304 +0100] - ERR - libdb - BDB0522 Page 0: metadata page corrupted
    [04/Feb/2022:13:11:02.481684604 +0100] - ERR - libdb - BDB0523 Page 0: could not check metadata page
    [04/Feb/2022:13:11:02.484113053 +0100] - ERR - libdb - /var/lib/dirsrv/slapd-instance_name/db/userroot/entryrdn.db: BDB0090 DB_VERIFY_BAD: Database verification failed
    [04/Feb/2022:13:11:02.486449603 +0100] - ERR - dbverify_ext - verify failed(-30970): /var/lib/dirsrv/slapd-instance_name/db/userroot/entryrdn.db
    dbverify failed
  4. 확인 프로세스에서 문제를 보고한 경우 수동으로 해결하거나 백업을 복원합니다.
  5. 인스턴스를 시작합니다.

    # dsctl instance_name start

추가 리소스

7장. 속성 암호화 관리

Directory Server는 디렉터리의 중요한 데이터에 대한 액세스를 보호하는 여러 메커니즘을 제공합니다. 그러나 기본적으로 서버는 암호화되지 않은 데이터를 데이터베이스에 저장합니다. 매우 민감한 정보의 경우 공격자가 데이터베이스에 액세스할 수 있는 잠재적 위험은 심각한 위험이 될 수 있습니다.

속성 암호화 기능을 사용하면 관리자는 데이터베이스에서 암호화된 정부 식별 번호와 같은 중요한 데이터를 사용하여 특정 특성을 저장할 수 있습니다. 접미사에 대해 활성화하면 이러한 속성의 모든 인스턴스, 인덱스 데이터도 데이터베이스의 이 속성에 저장된 모든 항목에 대해 암호화됩니다. 접미사에 대해 속성 암호화를 활성화할 수 있습니다. 전체 서버에 대해 이 기능을 활성화하려면 서버의 각 접미사에 대해 속성 암호화를 활성화해야 합니다. 속성 암호화는 eqpres indexing과 완전히 호환됩니다.

중요

항목 고유 이름(DN) 내에서 사용하는 모든 속성은 효율적으로 암호화할 수 없습니다. 예를 들어 uid 특성을 암호화하도록 구성한 경우 해당 값은 DN이 아닌 항목에서 암호화됩니다.

dn: uid=demo_user,ou=People,dc=example,dc=com
...
uid::Sf04P9nJWGU1qiW9JJCGRg==

7.1. Directory Server가 특성 암호화를 위해 사용하는 키

속성 암호화를 사용하려면 TLS를 사용하여 암호화된 연결을 구성해야 합니다. Directory Server는 서버의 TLS 암호화 키와 동일한 generated 입력 방법을 속성 암호화에 사용합니다.

서버는 무작위로 생성된 대칭 암호화 키를 사용하여 속성 데이터를 암호화 및 암호 해독합니다. 서버는 서버의 TLS 인증서에서 공개 키를 사용하여 이러한 키를 래핑합니다. 결과적으로 특성 암호화의 효과적인 강점은 서버의 TLS 키의 강점보다 높을 수 없습니다.

주의

서버의 개인 키에 액세스하지 않으면 래핑된 복사본에서 대칭 키를 복구할 수 없습니다. 따라서 서버의 인증서 데이터베이스를 정기적으로 백업하십시오. 키를 손실하면 더 이상 데이터베이스에 저장된 데이터의 암호를 해독하고 암호화할 수 없습니다.

7.2. 명령줄을 사용하여 속성 암호화 활성화

이 절차에서는 명령줄을 사용하여 userRoot 데이터베이스 의 phoneNumber 속성에 속성 암호화를 활성화하는 방법을 설명합니다. 이 절차를 수행한 후 서버는 이 특성 AES 암호화의 기존 및 새 값을 저장합니다.

사전 요구 사항

  • Directory Server에서 TLS 암호화를 사용하도록 설정했습니다.

절차

  1. userRoot 데이터베이스를 내보냅니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend export -E userRoot

    서버는 /var/lib/dirsrv/slapd-instance_name/ldif/ 디렉터리에 LDIF 파일에 내보내기를 저장합니다. e 옵션은 내보내기 중 이미 암호화된 속성을 해독합니다.

  2. phone Number 특성에 대해 AES 암호화 를 활성화합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend attr-encrypt --add-attr telephoneNumber dc=example,dc=com
  3. 인스턴스를 중지합니다.

    # dsctl instance_name stop
  4. LDIF 파일을 가져옵니다.

    # dsctl instance_name ldif2db --encrypted userRoot /var/lib/dirsrv/slapd-instance_name/ldif/None-userroot-2022_01_24_10_28_27.ldif

    --encrypted 매개변수를 사용하면 스크립트를 사용하여 가져오기 중 암호화에 구성된 속성을 암호화할 수 있습니다.

  5. 인스턴스를 시작합니다.

    # dsctl instance_name start

7.3. 웹 콘솔을 사용하여 속성 암호화 활성화

이 절차에서는 웹 콘솔을 사용하여 userRoot 데이터베이스의 phoneNumber 속성에 속성 암호화를 활성화하는 방법을 설명합니다. 이 절차를 수행한 후 서버는 이 특성 AES 암호화의 기존 및 새 값을 저장합니다.

웹 콘솔의 내보내기 및 가져오기 기능은 암호화된 특성을 지원하지 않습니다. 따라서 명령줄에서 다음 단계를 수행해야 합니다.

사전 요구 사항

  • Directory Server에서 TLS 암호화를 사용하도록 설정했습니다.
  • 웹 콘솔에서 인스턴스에 로그인되어 있습니다.

절차

  1. userRoot 데이터베이스를 내보냅니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend export -E userRoot

    서버는 /var/lib/dirsrv/slapd-instance_name/ldif/ 디렉터리에 LDIF 파일에 내보내기를 저장합니다. e 옵션은 내보내기 중 이미 암호화된 속성을 해독합니다.

  2. 웹 콘솔에서 DatabaseSuffixessuffix_entryEncrypted Properties로 이동합니다.
  3. 암호화할 속성을 입력하고 속성 추가 를 클릭합니다.
  4. 작업 메뉴에서 인스턴스 중지 를 선택합니다.
  5. 명령줄에서 LDIF 파일을 가져옵니다.

    # dsctl instance_name ldif2db --encrypted userRoot /var/lib/dirsrv/slapd-instance_name/ldif/None-userroot-2022_01_24_10_28_27.ldif

    --encrypted 매개변수를 사용하면 스크립트를 사용하여 가져오기 중 암호화에 구성된 속성을 암호화할 수 있습니다.

  6. 웹 콘솔에서 작업 메뉴를 열고 Start Instance 를 선택합니다.

7.4. 특성 암호화를 활성화한 후 일반 고려 사항

데이터베이스에 이미 있는 데이터에 대해 암호화를 활성화한 후 다음 포인트를 고려하십시오.

  • 암호화되지 않은 데이터는 서버의 데이터베이스 페이지 풀에서 백업 파일에 유지될 수 있습니다. 이 데이터를 제거하려면 다음을 수행합니다.

    1. 인스턴스를 중지합니다.

      # dsctl instance_name stop
    2. /var/lib/dirsrv/slapd-instance_name/db/guardian 파일을 삭제합니다.

      # **rm /var/lib/dirsrv/slapd-instance_name/db/guardian``
    3. 인스턴스를 시작합니다.

      # dsctl instance_name start
  • 암호화를 활성화하고 데이터를 가져온 후 암호화되지 않은 데이터로 LDIF 파일을 삭제합니다.
  • Directory Server는 복제 로그 파일을 암호화하지 않습니다. 이 데이터를 보호하려면 암호화된 디스크에 복제 로그를 저장합니다.
  • 서버의 메모리(RAM)의 데이터는 암호화되지 않으며 일시적으로 스왑 파티션에 저장할 수 있습니다. 이 데이터를 보호하려면 암호화된 스왑 공간을 구성합니다.
중요

암호화되지 않은 데이터가 포함된 파일을 삭제하더라도 특정 상황에서 이 데이터를 복원할 수 있습니다.

7.5. 속성 암호화에 사용되는 TLS 인증서 업데이트

속성 암호화는 서버의 TLS 인증서를 기반으로 합니다. 다음 절차에 따라 TLS 인증서를 갱신하거나 교체한 후 해당 속성 암호화가 실패하지 않도록 합니다.

사전 요구 사항

  • 속성 암호화를 구성하셨습니다.
  • TLS 인증서는 가까운 시일 내에 만료됩니다.

절차

  1. userRoot 데이터베이스를 내보냅니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com backend export -E userRoot

    서버는 /var/lib/dirsrv/slapd-instance_name/ldif/ 디렉터리에 LDIF 파일에 내보내기를 저장합니다. e 옵션은 내보내기 중 이미 암호화된 속성을 해독합니다.

  2. 개인 키 및 CSR(인증서 서명 요청)을 생성합니다. 외부 유틸리티를 사용하여 생성하려면 이 단계를 건너뜁니다.

    • 하나의 이름으로만 호스트에 연결할 수 있는 경우 다음을 입력합니다.

      # dsctl instance_name tls generate-server-cert-csr -s "CN=server.example.com,O=example_organization"
    • 호스트에 여러 이름으로 액세스할 수 있는 경우:

      # dsctl instance_name tls generate-server-cert-csr -s "CN=server.example.com,O=example_organization" server.example.com server.example.net

      호스트 이름을 마지막 매개변수로 지정하면 명령에서 DNS:server.example.com, DNS:server.example.net 항목을 CSR에 사용하여 SAN(Subject Alternative Name) 확장을 추가합니다.

    subject매개변수에 지정된 문자열은 RFC 1485에 따라 유효한 제목 이름이어야 합니다. 주체의 CN 필드가 필요하므로 서버의 FQDN(정규화된 도메인 이름) 중 하나로 설정해야 합니다. 이 명령은 /etc/dirsrv/slapd-instance_name/Server-Cert.csr 파일에 CSR을 저장합니다.

  3. CSR을 CA(인증 기관)에 제출하여 발급된 인증서를 가져옵니다. 자세한 내용은 CA 문서를 참조하십시오.
  4. CA에서 발행한 서버 인증서를 NSS 데이터베이스로 가져옵니다.

    • dsctl tls generate-server-cert-csr 명령을 사용하여 개인 키를 생성한 경우 다음을 입력합니다.

      # dsconf -D "cn=Directory Manager" ldap://server.example.com security certificate add --file /root/instance_name.crt --name "server-cert" --primary-cert

      --name _certificate_nickname매개변수에 설정한 인증서의 이름을 기록하십시오. 이후 단계에서 필요합니다.

    • 외부 유틸리티를 사용하여 개인 키를 생성한 경우 서버 인증서와 개인 키를 가져옵니다.

      # dsctl instance_name tls import-server-key-cert /root/server.crt /root/server.key

      이 명령을 사용하려면 먼저 서버 인증서의 경로를 지정한 다음 개인 키 경로를 지정해야 합니다. 이 방법은 항상 인증서의 닉네임을 Server-Cert 로 설정합니다.

  5. CA 인증서를 NSS 데이터베이스로 가져옵니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com security ca-certificate add --file /root/ca.crt --name "Example CA"
  6. CA 인증서의 신뢰 플래그를 설정합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com security ca-certificate set-trust-flags "Example CA" --flags "CT,,"

    이렇게 하면 TLS 암호화 및 인증서 기반 인증에 사용할 CA를 신뢰하도록 Directory Server가 구성됩니다.

  7. 인스턴스를 중지합니다.

    # dsctl instance_name stop
  8. /etc/dirsrv/slapd-instance_name/dse.ldif 파일을 편집하고 속성을 포함하여 다음 항목을 제거합니다.

    • CN=AES,cn=encrypted 특성 키,cn=database_name,cn=ldbm 데이터베이스,cn=plugins,cn=config
    • CN=3DES,cn=encrypted 특성 키,cn=database_name,cn=ldbm 데이터베이스,cn=plugins,cn=config
    중요

    모든 데이터베이스의 항목을 제거합니다. nsSymmetricKey 속성이 포함된 항목이 '/etc/dirsrv/slapd-instance_name/dse.ldif 파일에 남아 있으면 Directory Server가 시작되지 않습니다.

  9. LDIF 파일을 가져옵니다.

    # dsctl instance_name ldif2db --encrypted userRoot /var/lib/dirsrv/slapd-instance_name/ldif/None-userroot-2022_01_24_10_28_27.ldif

    --encrypted 매개변수를 사용하면 스크립트를 사용하여 가져오기 중 암호화에 구성된 속성을 암호화할 수 있습니다.

  10. 인스턴스를 시작합니다.

    # dsctl instance_name start

10장. 연결 정책 구성

클라이언트 애플리케이션의 요청을 데이터베이스 링크가 포함된 Directory Server로 연결하도록 Directory Server를 구성할 수 있습니다. 연결 정책은 Directory Server에서 생성된 모든 데이터베이스 링크에 적용됩니다.

10.1. 구성 요소 작업 연결

구성 요소는 프런트 엔드의 플러그인 또는 함수와 같이 내부 작업을 사용하는 서버의 모든 기능 단위입니다.

일부 구성 요소는 로컬 데이터에 액세스하려는 내부 LDAP 요청을 서버로 보냅니다. 이러한 구성 요소의 경우 구성 요소가 작업을 성공적으로 완료할 수 있도록 연결 정책을 제어해야 합니다. 예를 들어 인증서 확인 기능은 다음과 같습니다. 함수에서 수행한 LDAP 요청을 연결하여 원격 서버를 신뢰할 수 있는 인증서를 확인할 수 있습니다. 원격 서버를 신뢰할 수 없는 경우 보안 문제가 발생합니다.

기본적으로 모든 내부 작업과 구성 요소를 연결할 수는 없지만 기본값은 재정의할 수 있습니다.

또한 원격 서버에서 ACI 를 생성하여 지정된 플러그인을 활성화하여 원격 서버에서 작업을 수행해야 합니다. ACI 는 데이터베이스 링크에 할당된 접미사 에 있어야 합니다.

다음은 구성 요소 이름, 이러한 구성 요소가 내부 작업을 체인할 수 있을 때 발생할 수 있는 잠재적인 측면 및 원격 서버의 ACI 에 필요한 권한입니다.

  • ACI 플러그인 구성 요소

    ACI 플러그인 구성 요소는 액세스 제어를 구현합니다. 로컬 및 원격 속성을 혼합하는 것이 안전하지 않기 때문에 ACI 속성을 검색하고 업데이트하는 데 사용되는 작업을 체인할 수 없습니다. 그러나 다음 연결 구성 요소 특성을 설정하여 사용자 항목을 검색하는 데 사용되는 요청을 연결할 수 있습니다.

    nsActiveChainingComponents: cn=ACI Plugin,cn=plugins,cn=config

    권한: 읽기, 검색 및 비교

  • 리소스 제한 구성 요소

    리소스 제한 구성 요소는 사용자 바인딩 DN에 따라 서버 제한을 설정합니다. 리소스 제한 구성 요소를 연결하면 원격 사용자에게 리소스 제한을 적용할 수 있습니다. 리소스 제한 구성 요소 작업을 체인하려면 다음 연결 구성 요소 특성을 추가합니다.

    nsActiveChainingComponents: cn=resource limits,cn=components,cn=config

    권한: 읽기, 검색 및 비교

  • 인증서 기반 인증 구성 요소

    외부 바인딩 방법 중에 인증서 기반 인증 구성 요소를 사용할 수 있습니다. 이 구성 요소는 원격 서버의 데이터베이스에서 사용자 인증서를 검색합니다. 이 구성 요소가 체인되도록 허용하면 인증서 기반 인증이 데이터베이스 링크로 작동할 수 있습니다. 이 구성 요소의 작업을 연결하려면 다음 연결 구성 요소 특성을 추가합니다.

    nsActiveChainingComponents: cn=certificate-based authentication,cn=components,cn=config

    권한: 읽기, 검색 및 비교

  • 암호 정책 구성 요소

    암호 정책 구성 요소는 원격 서버에 SASL 바인딩을 추가합니다. SASL 인증의 일부 형태의 경우 사용자 이름 및 암호를 사용하여 인증하는 것이 중요합니다. 암호 정책을 활성화하면 서버가 요청한 특정 인증 방법을 확인하고 구현하여 적절한 암호 정책을 적용할 수 있습니다. 이 구성 요소의 작업을 연결하려면 연결 구성 요소 특성을 추가합니다.

    nsActiveChainingComponents: cn=password policy,cn=components,cn=config

    권한: 읽기, 검색 및 비교

  • SASL 구성 요소

    SASL 구성 요소를 사용하면 SASL이 원격 서버에 바인딩할 수 있습니다. 이 구성 요소의 작업을 연결하려면 연결 구성 요소 특성을 추가합니다.

    nsActiveChainingComponents: cn=password policy,cn=components,cn=config

    권한: 읽기, 검색 및 비교

  • 참조 무결성 후 작업 구성 요소

    참조 무결성 후 작업 구성 요소는 DN을 포함하는 속성과 속성에 대한 포인터가 포함된 항목으로 업데이트를 전파합니다. 예를 들어, 그룹이 삭제될 때 그룹에서 항목을 자동으로 제거할 수 있습니다. 참조 무결성 후 작업 플러그인을 사용하여 그룹 멤버가 정적 그룹 정의로 원격일 때 정적 그룹 관리를 단순화합니다.

    nsActiveChainingComponents: cn=referential integrity postoperation,cn=plugins,cn=config

    권한: 읽기, 검색 및 비교

  • 특성 고유 구성 요소

    특성 고유성 구성 요소는 지정된 특성의 모든 값이 고유한지 확인합니다. 플러그인을 연결하면 데이터베이스 링크를 통해 속성이 변경될 때에도 속성 값이 고유함을 확인합니다. 이 구성 요소의 작업을 연결하려면 연결 구성 요소 특성을 추가합니다.

    nsActiveChainingComponents: cn=attribute uniqueness,cn=plugins,cn=config

    권한: 읽기, 검색 및 비교

  • roles 구성 요소

    역할 구성 요소는 데이터베이스의 항목에 대한 역할 및 역할을 할당합니다. 이 구성 요소를 연결하면 연결된 데이터베이스에서도 역할을 유지합니다. 이 구성 요소의 작업을 연결하려면 연결 구성 요소 특성을 추가합니다.

    nsActiveChainingComponents: cn=roles,cn=components,cn=config

    권한: 읽기, 검색 및 비교

참고

역할 플러그인, 암호 정책 구성 요소, 복제 플러그인 및 참조 무결성 플러그인 구성 요소를 연결할 수 없습니다. 요청을 발행하는 서버에서 Referential Integrity 플러그인을 활성화하면 성능, 리소스, 시간 및 무결성 요구 사항을 분석해야 합니다. 무결성 검사는 시간이 오래 걸리며 메모리 및 CPU에서 드레이닝될 수 없습니다.

10.2. 명령줄을 사용하여 구성 요소 작업 연결

명령줄을 사용하여 체인에 허용된 구성 요소를 추가할 수 있습니다.

절차

  1. 체인에 포함할 구성 요소를 지정합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set \ --add-comp="cn=referential integrity postoperation,cn=components,cn=config"
  2. 인스턴스를 다시 시작하십시오.

    # dsctl instance_name restart
  3. 작업이 연결될 원격 서버의 접미사에 ACI를 생성합니다.

    # ldapmodify -D "cn=Directory Manager" -W -H 389 remoteserver.example.com -x
     dn: ou=People,dc=example,dc=com
     changetype: modify
     add: aci
     aci: (targetattr = "*")(target="ldap:///ou=customers,ou=People,dc=example,dc=com")
     (version 3.0; acl "RefInt Access for chaining"; allow
     (read,write,search,compare) userdn = "ldap:///cn=referential
     integrity postoperation,cn=plugins,cn=config";)

검증

  • 체인에 허용되는 구성 요소를 표시합니다.

    # dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set \ --add-comp="cn=referential integrity postoperation,cn=components,cn=config"

10.3. 웹 콘솔을 사용한 구성 요소 작업 연결

웹 콘솔을 사용하여 체인에 허용된 구성 요소를 추가할 수 있습니다.

사전 요구 사항

  • 웹 콘솔에서 Directory Server 사용자 인터페이스를 열고 인스턴스를 선택했습니다.

절차

  1. 데이터베이스 를 엽니다.
  2. 왼쪽 탐색에서 체인 구성 항목을 선택합니다.
  3. 체인에 구성 요소 필드 아래의 추가 버튼을 클릭합니다.
  4. 연결하려는 구성 요소를 선택하고 새 구성 요소 추가 및 저장 을 클릭합니다.
  5. 작업이 연결될 원격 서버의 접미사에 ACI 를 생성합니다.

    # ldapmodify -D "cn=Directory Manager" -W -H 389 remoteserver.example.com -x
     dn: ou=People,dc=example,dc=com
     changetype: modify
     add: aci
     aci: (targetattr = "*")(target="ldap:///ou=customers,ou=People,dc=example,dc=com")
     (version 3.0; acl "RefInt Access for chaining"; allow
     (read,write,search,compare) userdn = "ldap:///cn=referential
     integrity postoperation,cn=plugins,cn=config";)

검증

  • 선택된 구성요소는 연결되어 있어야 합니다.

11장. LDAP 제어 연결

LDAP 작업에는 동작을 변경하는 일부 데이터(ldap 프로토콜에 이름이 지정되고 일부 데이터)가 포함될 수 있습니다. 원격 서버로 전달할 LDAP 제어를 지정할 수 있습니다.

11.1. 연결 LDAP 제어 정보

다음 제어가 포함된 데이터베이스 링크는 LDAP 제어 연결을 위해 원격 서버에 요청을 전달합니다.

  • VLV(Virtual List View) 컨트롤은 특정 항목의 목록을 제공합니다.
  • 서버 측 정렬 컨트롤은 일반적으로 특정 일치 규칙을 사용하여 특성 값에 따라 항목을 분류합니다.
  • Dereferencing 제어는 참조된 항목에서 지정된 특성 정보를 가져오고 검색 결과의 나머지 부분과 함께 이 정보를 반환합니다.
  • Managed DSA 컨트롤은 이러한 권장 사항을 따르는 대신 스마트 추천을 엔트리로 반환합니다. 따라서 스마트 리포팅 자체는 변경하거나 삭제할 수 있습니다.
  • ECDHE 탐지 컨트롤은 다른 서버와의 서버 체인의 횟수를 추적합니다. 개수가 구성된 번호에 도달하면 10.0.0.1 탐지 가 루프를 감지하고 클라이언트 애플리케이션에 알립니다.
참고

데이터베이스 링크는 클라이언트 애플리케이션이 여러 데이터베이스에 요청할 때 서버 측 정렬을 지원할 수 없으며 VLV 는 제어됩니다.Database links cannot support Server-side sorting and VLV controls when a client application makes a request to multiple databases.

다음은 체인과 해당 오브젝트 식별자(OID)에 허용되는 일부 LDAP 제어입니다.

제어 이름OID

가상 목록 보기(VLV)

2.16.840.1.113730.3.4.9

서버 측 정렬

1.2.840.113556.1.4.473

관리형 DSA

2.16.840.1.113730.3.4.2

루프 탐지

1.3.6.1.4.1.1466.29539.12

역참조 검색

1.3.6.1.4.1.4203.666.5.16

11.2. 명령줄을 사용하여 LDAP 제어 연결

명령줄에서 dsconf chaining config-set --add-control 을 사용하여 LDAP 제어를 연결할 수 있습니다.

절차

  1. 체인 LDAP 제어:

    # dsconf -D "cn=Directory Manager" ldap://server.example.com chaining \ config-set --add-control="2.16.840.1.113730.3.4.9"

    Directory Server 클라이언트가 자체 컨트롤을 만들고 원격 서버에 작업을 체인하는 경우 사용자 지정 컨트롤의 개체 식별자(OID)를 추가합니다.

11.3. 웹 콘솔을 사용하여 LDAP 제어 연결

웹 콘솔을 사용하여 LDAP 제어를 연결할 수 있습니다.

사전 요구 사항

  • 웹 콘솔에서 Directory Server 사용자 인터페이스를 열고 인스턴스를 선택했습니다.

절차

  1. 데이터베이스 메뉴를 엽니다.
  2. 체인 구성 항목을 선택합니다.
  3. Forwarded LDAP Controls 필드 아래에 있는 Add 버튼을 클릭합니다.
  4. LDAP 컨트롤을 선택하고 Add & Save New Controls 버튼을 클릭합니다.

    Directory Server 클라이언트가 자체 컨트롤을 만들고 원격 서버에 작업을 체인하는 경우 사용자 지정 컨트롤의 개체 식별자(OID)를 추가합니다.

  5. Save 버튼을 클릭합니다.

검증

  • 데이터베이스 메뉴를 클릭하고 선택한 LDAP 제어가 연결되어 있는지 확인합니다.

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.