8장. 디렉터리 설계 예
디렉터리 서비스의 설계는 엔터프라이즈의 크기와 특성에 따라 다릅니다. 다음 예제는 실제 디렉터리 서비스 배포 계획을 개발하기 위한 시작점입니다.
8.1. 로컬 엔터프라이즈 설계 예
ExampleCom은 소규모 부품 제조업체이며 500 명의 직원이 있습니다. ExampleCom은 사용하는 디렉터리 지원 애플리케이션을 지원하기 위해 Red Hat Directory Server를 배포하기로 결정했습니다.
8.1.1. 로컬 엔터프라이즈의 데이터 설계
디렉터리가 저장할 데이터 유형을 결정하기 위해 ExampleCom은 사이트 설문 조사를 수행하는 배포 팀을 만듭니다. 배포 팀은 다음 주요 포인트를 결정합니다.
- 메시징 서버, 웹 서버, 일정 서버, 인적 리소스 애플리케이션 및 흰색 페이지 애플리케이션은 이 디렉터리를 사용합니다.
메시징 서버는
uid,mailServerName,mailAddress와 같은 속성에 대한 정확한 검색을 수행합니다. 데이터베이스 성능을 개선하기 위해 ExampleCom은 이러한 특성에 대한 인덱스를 유지 관리합니다.인덱스 사용에 대한 자세한 내용은 인덱스를 사용하여 데이터베이스 성능을 향상합니다.For more information about using indexes, see Using indexes to improve database performance.
흰색 페이지 애플리케이션은 사용자 이름과 전화 번호를 검색합니다. 따라서 디렉토리는 많은 수의 하위 문자열, 와일드카드 및 유사 항목 검색을 처리하여 많은 결과를 반환해야 합니다. ExampleCom 회사는 다음 인덱스를 유지 관리하기로 결정했습니다.
-
cn,sn및givenName속성에 대한 ,동일성,대략적인 및 하위 문자열 인덱스입니다. -
telephone Number특성에 대한 ,같음 및 하위 문자열 인덱스입니다.
-
- 이 디렉터리는 조직에 배포된 LDAP 서버 기반 인트라넷을 지원하기 위해 사용자 및 그룹 정보를 유지해야 합니다. 디렉터리 관리자 그룹은 대부분의 ExampleCom 사용자 및 그룹 정보를 관리합니다. 그러나 ExampleCom은 별도의 메일 관리자 그룹이 이메일 정보를 관리하고자 합니다.
- 디렉터리는 S/MIME 이메일과 같은 PKI(공개 키 인프라) 애플리케이션을 지원하기 위해 사용자 공개 키 인증서를 저장해야 합니다.
8.1.2. 로컬 엔터프라이즈의 스키마 설계
ExampleCom 디렉터리에서 지원하는 애플리케이션에는 userCertificate 및 uid (userID) 속성이 필요합니다. 따라서 ExampleCom 배포 팀은 inetOrgPerson 오브젝트 클래스를 사용하여 두 특성을 모두 허용하므로 디렉터리의 항목을 나타냅니다.
또한 ExampleCom은 예제Person 오브젝트 클래스를 생성하여 직원을 나타내는 기본 디렉터리 스키마를 사용자 지정하려고 합니다. 이 개체 클래스는 inetOrgPerson 개체 클래스에서 파생됩니다. examplePerson 은 하나의 exampleID 속성을 허용합니다. 이 속성에는 각 직원에 할당된 특수 직원 번호가 포함됩니다. 나중에 ExampleCom은 examplePerson 오브젝트 클래스에 새 속성을 추가할 수 있습니다.
8.1.3. 로컬 엔터프라이즈의 디렉터리 트리 설계
준비된 데이터 및 스키마 설계에 따라 ExampleCom은 다음 디렉터리 트리를 생성합니다.
그림 8.1. 예제Com의 디렉터리 트리
-
디렉터리 트리의 루트는 회사 인터넷 도메인 이름인
dc=example,dc=com입니다. 디렉터리 트리에는 4개의 분기 지점이 있습니다.
-
ou=people -
ou=groups -
ou=resources -
ou=roles
-
모든 ExampleCom 사용자 항목은
ou=people분기 아래에 생성됩니다.people 항목은 모두 사람 ,
organizational,PersoninetOrgPerson,examplePerson개체 클래스의 멤버입니다.uid속성은 각 항목에 대해 고유 이름(DN)을 고유하게 식별합니다. 예를 들어, 회사는 Babs Jensen (uid=bjensen) 및 Emily Stanton (uid=estanton)에 대한 항목이 포함되어 있습니다.ExampleCom의 각 부서에 대해
영업,마케팅및회계역할이 생성됩니다.각 person 항목에는 해당 사람이 속한 부서를 식별하는 역할 특성이 포함되어 있습니다. 이제 회사는 이러한 역할을 기반으로 액세스 제어 지침(ACI)을 생성할 수 있습니다.
역할에 대한 자세한 내용은 다음을 참조하십시오. 4.3.2절. “Directory Server의 역할 정보”
다음 그룹 분기는
ou=groups분기 아래에 생성됩니다.-
cn=administrators그룹에는 디렉터리 콘텐츠를 관리하는 디렉터리 관리자에 대한 항목이 포함되어 있습니다. -
cn=messaging admins그룹에는 메일 계정만 관리하는 메일 관리자의 항목이 포함되어 있습니다. 이 그룹은 메시징 서버에서 사용하는 관리자 그룹에 해당합니다.
-
ou=resources분기 아래의 다음 분기가 생성됩니다.-
ou=conference room은 회의룸을 위한 방입니다. -
사무실의 ou= Cryostats 분기입니다.
-
-
항목이 관리 그룹에 속하는지 여부에 따라
mailquota속성 값을 제공하는 서비스 클래스(CoS)가 생성됩니다. 이 CoS는 관리자에게 100GB의 메일 할당량을 제공하는 반면 일반적인 ExampleCom 직원은 5GB의 메일 할당량을 갖습니다.
8.1.4. 로컬 엔터프라이즈의 토폴로지 설계
ExampleCom 배포 팀은 디렉터리 데이터베이스 및 서버 토폴로지를 설계하기 시작합니다.
ExamleCom은 다음과 같은 데이터베이스 토폴로지를 설계합니다.
그림 8.2. 로컬 엔터프라이즈 데이터베이스 토폴로지
-
데이터베이스 1은ou=people분기를 저장합니다. -
데이터베이스 2는ou=groups분기를 저장합니다. -
데이터베이스 3은ou=resources및ou=roles분기와dc=example,dc=com루트 접미사를 저장합니다.
ExamleCom은 다음 서버 토폴로지를 설계합니다.
그림 8.3. 로컬 엔터프라이즈 서버 토폴로지
ExampleCom은 두 개의 공급자 서버와 세 개의 소비자 서버가 있는 서버 토폴로지를 사용하기로 결정했습니다. 두 공급자 각각은 Directory Server 배포에서 세 명의 소비자를 모두 업데이트합니다.
소비자는 하나의 메시징 서버 및 다른 서버에 데이터를 제공합니다. 호환되는 서버의 요청 수정은 적절한 소비자 서버로 라우팅됩니다. 소비자 서버는 스마트 추천을 사용하여 요청이 수정되는 데이터의 주요 사본에 대한 책임이 있는 공급자 서버로 라우팅합니다.
8.1.5. 로컬 엔터프라이즈의 복제 설계
ExampleCom은 디렉터리 데이터의 고가용성을 보장하기 위해 다중 제공 복제 설계를 사용하기로 결정했습니다. 다중 제공 복제에 대한 자세한 내용은 다음을 참조하십시오.
Multi-supplier 아키텍처
ExampleCom은 다중 제공 복제 아키텍처에서 두 개의 공급자 서버를 사용합니다. 공급업체는 디렉터리 데이터가 일관되게 유지되도록 서로를 업데이트합니다. 다음 다이어그램은 ExampleCom의 공급업체 제공 아키텍처를 보여줍니다.
그림 8.4. ExampleCom 다중 공급 아키텍처
vendor-consumer 아키텍처
다음 다이어그램에서는 디렉터리의 ExampleCom 배포에서 공급업체 서버가 각 소비자에게 복제하는 방법을 설명합니다.
그림 8.5. 예Com 공급자 소비자 아키텍처
두 공급자 서버 모두 세 개의 소비자 서버를 업데이트합니다. 이렇게 하면 공급자 서버 중 하나가 실패하면 소비자가 영향을 받지 않습니다.
8.1.6. 로컬 엔터프라이즈 보안 설계
디렉터리 데이터를 보호하기 위해 ExampleCom은 다음 액세스 제어 명령(ACI)을 생성합니다.
-
직원이 항목을 수정할 수 있는 ACI입니다. 사용자는
uid,manager및department속성을 제외한 모든 속성을 수정할 수 있습니다. - 직원 및 직원 관리자만 직원 데이터 개인 정보를 보호하기 위해 직원 홈 주소와 전화 번호를 볼 수 있는 ACI입니다.
두 관리자 그룹에 적절한 디렉터리 권한을 부여하는 디렉터리 트리의 루트에 있는 ACI입니다.
- 디렉터리 관리자 그룹에는 디렉터리에 대한 전체 액세스 권한이 필요합니다.
-
메시징 관리자 그룹에는
mailRecipient및mailGroup개체 클래스와mail특성을 포함하여 이러한 오브젝트 클래스에서 허용하는 속성에 대한쓰기및삭제권한이 필요합니다. ExampleCom은 또한 메시징 관리자 그룹에 메일 그룹을 생성하기 위해 그룹 하위 디렉터리에 대한쓰기,삭제및추가권한을 부여합니다.
-
읽기,검색및 액세스에 대한 익명 액세스를 허용하는 디렉터리 트리의 루트에 있는 일반 ACI입니다.또한 이 ACI는 익명의 사용자가 암호 정보에 대한 액세스를 거부합니다. - 모든 급여 정보에 대한 회계 역할 액세스 권한을 부여하는 ACI입니다.
또한 ExampleCom은 다음과 같은 보안 조치를 결정합니다.
서비스 거부 공격 및 부적절한 사용으로부터 서버를 보호하기 위해 ExampleCom은 클라이언트가 바인딩하는 데 사용하는 DN에 따라 리소스 제한을 설정합니다.
- 익명 사용자는 검색 요청에 대한 응답으로 한 번에 100 개의 항목을 수신할 수 있습니다.
- 메시지 관리자는 1,000개의 항목을 수신할 수 있습니다.
- 디렉터리 관리자는 무제한의 항목을 수신할 수 있습니다.
ExampleCom은 암호가 8자 이상이어야 하고 90일 후에 만료되는 암호 정책을 생성합니다.
암호 정책에 대한 자세한 내용은 암호 정책 설정을 참조하십시오.
8.1.7. 로컬 엔터프라이즈의 운영 결정
회사는 디렉터리의 일상적인 운영에 대해 다음과 같은 결정을 내립니다.
- 매일 매일 데이터베이스를 백업하십시오.
- SNMP를 사용하여 서버 상태를 모니터링합니다.
- 액세스 및 오류 로그를 자동으로 순환합니다.
- 오류 로그를 모니터링하여 서버가 예상대로 수행 중인지 확인합니다.
- 액세스 로그를 모니터링하여 인덱싱할 수 있는 검색을 나타냅니다.
추가 리소스
