10장. 디렉터리 설계 예
디렉터리 서비스의 설계는 엔터프라이즈의 크기와 특성에 따라 다릅니다. 이 장에서는 다양한 설정 내에서 디렉토리를 적용하는 방법에 대한 몇 가지 예를 제공합니다. 이 예제는 실제 디렉터리 서비스 배포 계획을 개발하기 위한 시작점입니다.
10.1. 설계 예: 로컬 엔터프라이즈
예제 Corp.는 500명의 직원으로 구성된 소규모 회사입니다. Example Corp.은 사용하는 디렉터리 지원 애플리케이션을 지원하기 위해 Red Hat Directory Server를 배포하기로 결정합니다.
10.1.1. 로컬 엔터프라이즈 데이터 설계
예제 Corp.은 먼저 디렉터리에 저장할 데이터 유형을 결정합니다. 이를 위해 Example Corp.은 사이트 설문 조사를 수행하여 디렉터리의 사용 방법을 결정하는 배포 팀을 만듭니다. 배포 팀은 다음을 결정합니다.
- 예를 들어 Corp.s 디렉터리는 메시징 서버, 웹 서버, 일정 서버, 인적 리소스 애플리케이션 및 흰색 페이지 애플리케이션에서 사용됩니다.
- 메시징 서버는
uid,mailServerName,mailAddress와 같은 속성에 대한 정확한 검색을 수행합니다. 데이터베이스 성능을 개선하기 위해 Example Corp.는 메시징 서버의 검색을 지원하기 위해 이러한 속성의 인덱스를 유지합니다.인덱스 사용에 대한 자세한 내용은 6.4절. “인덱스를 사용하여 데이터베이스 성능 개선” 을 참조하십시오. - 흰색 페이지 애플리케이션은 자주 사용자 이름과 전화 번호를 검색합니다. 따라서 디렉터리에는 많은 결과를 반환하는 자주 하위 문자열, 와일드카드 및 퍼지 검색이 가능합니다. 예를 들어 Corp.은 phone
Number특성에 대한cn,sn및givenName속성, 같음 및 하위 문자열 인덱스에 대한 존재, 같음 및 하위 문자열 인덱스를 유지 관리하기로 결정합니다. - 예제 Corp.의 디렉터리는 조직 전체에 배포된 LDAP 서버 기반 인트라넷을 지원하기 위해 사용자 및 그룹 정보를 유지 관리합니다. Example Corp.의 대부분의 사용자 및 그룹 정보는 디렉토리 관리자 그룹에 의해 중앙 집중식으로 관리됩니다. 그러나 Example Corp.에서는 별도의 메일 관리자 그룹에서 이메일 정보를 관리하려고 합니다.
- Example Corp.은 향후 S/MIME 이메일과 같은 공개 키 인프라(PKI) 애플리케이션을 지원할 계획이므로 사용자의 공개 키 인증서를 디렉터리에 저장할 준비가 되어 있어야 합니다.
10.1.2. 로컬 엔터프라이즈 스키마 설계
예를 들어 Corp.의 배포 팀은 inetOrgPerson 오브젝트 클래스를 사용하여 디렉터리의 항목을 나타냅니다. 이 오브젝트 클래스는
userCertificate 및 uid (userID) 속성을 허용하므로 이 두 클래스는 Example Corp.의 디렉터리에서 지원하는 애플리케이션에 필요합니다.
Example Corp.은 기본 디렉터리 스키마도 사용자 지정하려고 합니다. example Corp.은 examplePerson 개체 클래스를 생성하여 Example Corp의 직원을 나타냅니다. 이 개체 클래스는 inetOrgPerson 개체 클래스에서 파생됩니다.
examplePerson 오브젝트 클래스는 하나의 속성인
exampleID 속성을 허용합니다. 이 속성에는 각 Example Corp. employee에 할당된 특수 직원 번호가 포함됩니다.
나중에 Example Corp.은 필요에 따라 examplePerson 개체 클래스에 새 특성을 추가할 수 있습니다.
10.1.3. 로컬 엔터프라이즈 디렉터리 트리 설계
이전 섹션에 설명된 데이터 및 스키마 설계에 따라 Example Corp.는 다음 디렉터리 트리를 생성합니다.
- 디렉터리 트리의 루트는 Example Corp.의 인터넷 도메인 이름인
dc=example,dc=com입니다. - 디렉터리 트리에는
ou=people,ou=groups,ou=roles,ou=resources의 네 가지 분기 지점이 있습니다. - Example Corp.의 모든 people 항목은
ou=people분기 아래에 생성됩니다.people 항목은 모두 사람 ,organizational,inetOrgPerson, examplePerson 개체 클래스의 멤버입니다.Personuid속성은 각 항목의 DN을 고유하게 식별합니다. 예를 들어 Example Corp.에는 Babs Jensen (uid=bjensen)및 Emily Stanton (uid=estanton)에 대한 항목이 포함되어 있습니다. - Example Corp.의 각 부서에 대해 세 가지 역할, 즉 영업, 마케팅 및 회계를 생성합니다.각 person 항목에는 해당 사람이 속한 부서를 식별하는 역할 특성이 포함되어 있습니다. Example Corp.에서 이러한 역할을 기반으로 ACI를 생성할 수 있습니다.역할에 대한 자세한 내용은 4.3.2절. “역할 정보” 을 참조하십시오.
ou=groups분기 아래에 두 개의 그룹 분기를 생성합니다.첫 번째 그룹인cn=administrators에는 디렉터리 콘텐츠를 관리하는 디렉터리 관리자에 대한 항목이 포함되어 있습니다.두 번째 그룹cn=messaging admin에는 메일 계정을 관리하는 메일 관리자의 항목이 포함되어 있습니다. 이 그룹은 메시징 서버에서 사용하는 관리자 그룹에 해당합니다. 예 Corp.에서는 메시징 서버에 대해 구성하는 그룹이 Directory Server에 대해 만드는 그룹과 다른지 확인합니다.- 두 개의 분기를
ou=resources분기 아래에 만듭니다. 하나는 회의실(ou=conference room)과사무실용(ou= Cryostats )입니다. - 항목이 관리 그룹에 속하는지 여부에 따라
mailquota속성 값을 제공하는 서비스 클래스(CoS) 를 생성합니다.이 CoS는 관리자에게 100GB의 메일 할당량을 제공하며 일반적인 Example Corp. 직원은 5GB의 메일 할당량을 갖습니다.서비스 클래스에 대한 자세한 내용은 5.3절. “서비스 클래스 정보” 을 참조하십시오.
다음 다이어그램은 위에 나열된 설계 단계에서 발생하는 디렉터리 트리를 보여줍니다.
그림 10.1. Example Corp의 디렉터리 트리입니다.
10.1.4. 로컬 엔터프라이즈 토폴로지 설계
이 시점에서 Example Corp.는 데이터베이스 및 서버 토폴로지를 설계해야 합니다. 다음 섹션에서는 각 토폴로지에 대해 자세히 설명합니다.
10.1.4.1. 데이터베이스 토폴로지
회사는 사람 분기가 하나의 데이터베이스(DB1)에 저장되는 데이터베이스 토폴로지를 설계하고, 그룹 분기는 다른 데이터베이스(DB2)에 저장되고, 리소스 분기, 역할 분기 및
루트 접미사 정보는 세 번째 데이터베이스(DB3)에 저장됩니다. 이는 그림 10.2. “Example Corp의 데이터베이스 토폴로지.” 에 설명되어 있습니다.
그림 10.2. Example Corp의 데이터베이스 토폴로지.
두 공급자 서버 각각 Example Corp.의 Directory Server 배포 3개의 소비자 서버를 모두 업데이트합니다. 이러한 소비자는 하나의 메시징 서버와 다른 통합 사용자 관리 제품에 데이터를 제공합니다.
그림 10.3. Example Corp의 서버 토폴로지.
호환되는 서버의 요청 수정 은 적절한 소비자 서버로 라우팅됩니다. 소비자 서버는 스마트 추천을 사용하여 수정되는 데이터의 주요 사본을 담당하는 공급자 서버로 요청을 라우팅합니다.
10.1.5. 로컬 엔터프라이즈 복제 설계
예제 Corp.은 디렉터리 데이터의 고가용성을 보장하기 위해 다중 제공 복제 설계를 사용하기로 결정합니다. 다중 제공 복제에 대한 자세한 내용은 7.2.2절. “Multi-Supplier Replication” 을 참조하십시오.
다음 섹션에서는 공급자 서버 아키텍처 및 공급자 소비자 서버 토폴로지에 대한 자세한 내용을 제공합니다.
10.1.5.1. 공급업체 아키텍처
Example Corp.은 다중 제공 복제 아키텍처에서 두 개의 공급업체 서버를 사용합니다. 공급업체는 디렉터리 데이터가 일관되게 유지되도록 서로를 업데이트합니다. Example Corp.의 공급자 아키텍처는 다음과 같습니다.
그림 10.4. Example Corp의 공급업체 아키텍처.
10.1.5.2. Engineering Consumer Architecture
다음 다이어그램에서는 공급업체 서버가 Example Corp. 배포의 각 소비자에 복제하는 방법을 설명합니다. 세 개의 소비자 서버 각각이 두 공급자 서버에 의해 업데이트됩니다. 이렇게 하면 공급자 서버 중 하나에 오류가 있는 경우 소비자의 영향을 받지 않습니다.
그림 10.5. Example Corp을 위한 공급업체 및 소비자 아키텍처.
10.1.6. 로컬 엔터프라이즈 보안 설계
예제 Corp.은 디렉터리 데이터를 보호하기 위해 다음 보안 설계를 결정합니다.
- 직원이 자체 항목을 수정할 수 있는 ACI를 생성합니다.사용자는
uid,manager및department속성을 제외한 모든 속성을 수정할 수 있습니다. - 직원 데이터의 개인 정보를 보호하기 위해 직원과 관리자만 직원의 홈 주소와 전화 번호를 볼 수 있는 ACI를 생성합니다.
- 두 관리자가 적절한 디렉터리 권한을 그룹화할 수 있는 디렉터리 트리의 루트에 ACI를 생성합니다.디렉터리 관리자 그룹에는 디렉터리에 대한 전체 액세스 권한이 필요합니다. 메시징 관리자 그룹에는 mailRecipient 및 mailGroup 개체 클래스와 해당 오브젝트 클래스에 포함된 속성 및
mail속성에 대한 쓰기 및 삭제 권한이 필요합니다. Example Corp.은 또한 메시징 관리자 그룹에 메일 그룹 생성을 위해 그룹 하위 디렉터리에 대한쓰기,삭제및추가권한을 부여합니다. - 디렉터리 트리의 루트에 일반 ACI를 만들어 읽기, 검색 및 비교 액세스를 허용합니다.이 ACI는 암호 정보에 대한 익명 쓰기 액세스를 거부합니다.
- 서버가 서비스 거부 공격 및 부적절한 사용으로부터 보호하기 위해, 디렉터리 클라이언트가 바인딩하는 데 사용하는
DN에 따라 리소스 제한을 설정합니다.예 Corp.을 사용하면 익명 사용자가 검색 요청에 응답하여 한 번에 100개의 항목을 수신할 수 있으며, 메시지 관리 사용자는 1,000개의 항목을 수신할 수 있으며, 디렉터리 관리자는 항목을 무제한으로 수신할 수 있습니다.바인딩 DN을 기반으로 리소스 제한 설정에 대한 자세한 내용은 Red Hat Directory Server 관리자 가이드의 "사용자 계정 관리" 장을 참조하십시오. - 암호를 8자 이상이어야 하고 90일 후에 만료되도록 지정하는 암호 정책을 생성합니다.암호 정책에 대한 자세한 내용은 9.6절. “암호 정책 설계” 을 참조하십시오.
- 모든 급여 정보에 대한 회계 역할 액세스 권한을 부여하는 ACI를 생성합니다.
10.1.7. 로컬 엔터프라이즈 운영 결정
회사는 디렉터리의 일상적인 운영에 대해 다음과 같은 결정을 내립니다.
- 매일 매일 데이터베이스를 백업하십시오.
- SNMP를 사용하여 서버 상태를 모니터링합니다.SNMP에 대한 자세한 내용은 Red Hat Directory Server 관리자 가이드를 참조하십시오.
- 액세스 및 오류 로그를 자동으로 순환합니다.
- 오류 로그를 모니터링하여 서버가 예상대로 수행 중인지 확인합니다.
- 인덱싱해야 하는 검색에 대한 액세스 로그를 화면에 모니터링합니다.
액세스, 오류 및 감사 로그에 대한 자세한 내용은 Red Hat Directory Server 관리자 가이드의 "서버 및 데이터베이스 활동 모니터링" 장을 참조하십시오.
