2.3. 사이트 설문 조사 수행
사이트 설문 조사는 디렉터리 콘텐츠를 검색하고 특성화하는 공식적인 방법입니다. 디렉터리 아키텍처에 대한 준비가 중요하므로 설문 조사를 수행하는 데 더 많은 시간을 계획합니다. 사이트 설문 조사는 다음 작업으로 구성됩니다.
디렉터리를 사용하는 애플리케이션을 식별합니다.
엔터프라이즈에 배포하는 디렉터리 지원 애플리케이션과 해당 데이터 요구 사항을 결정합니다.
데이터 소스 식별.
엔터프라이즈를 조사하고 Active Directory, 기타 LDAP 서버, PBX 시스템, 인적 리소스 데이터베이스 및 이메일 시스템을 포함한 데이터 소스를 식별합니다.
디렉터리에 포함해야 하는 데이터를 특성화합니다.
디렉터리에 있어야 하는 오브젝트(예: 사용자 이름 및 그룹)와 디렉터리에 유지할 이러한 오브젝트의 속성(예: 사용자 이름 및 암호)을 결정합니다.
제공할 서비스 수준을 결정합니다.
클라이언트 애플리케이션에 대한 디렉터리 데이터의 가용성을 결정하고 그에 따라 아키텍처를 설계합니다. 디렉터리 가용성은 원격 서버에 저장된 데이터를 연결하기 위해 데이터 복제 및 연결 정책을 구성하는 방법에 영향을 미칩니다.
데이터 공급자를 식별합니다.
데이터 공급자에는 디렉터리 데이터에 대한 기본 소스가 포함되어 있습니다. 로드 밸런싱 및 복구를 위해 이 데이터를 다른 서버에 미러링할 수 있습니다. 각 데이터 세그먼트에 대한 데이터 공급자를 결정합니다.
데이터 소유권을 결정합니다.
모든 데이터에 대해 데이터 업데이트에 대한 책임이 있는 사람을 결정합니다.
데이터 액세스를 결정합니다.
다른 소스에서 데이터를 가져올 때 대량 가져오기 및 증분 업데이트에 대한 전략을 개발합니다. 이 전략의 일부로 데이터를 한 곳에서 관리하고 데이터를 변경할 수 있는 애플리케이션 수를 제한합니다. 또한 지정된 데이터에 쓰는 사용자의 수를 제한합니다. 소규모 그룹은 관리 오버헤드를 줄이는 동시에 데이터 무결성을 보장합니다.
- 사이트 설문 조사를 문서화합니다.
디렉터리의 여러 조직에 영향을 미치는 경우 영향을 받는 각 조직의 대표자가 포함된 디렉터리 배포 팀을 생성하여 사이트 설문 조사를 수행하는 것이 좋습니다.
기업은 일반적으로 인사관리 부서, 회계 또는 계정, 제조 기관, 영업 조직 및 개발 조직을 보유하고 있습니다. 각 조직의 대표를 포함하면 설문 조사 프로세스를 수행하고 로컬 데이터 저장소에서 중앙 집중식 디렉터리로 마이그레이션하는 데 도움이 될 수 있습니다.
2.3.1. 디렉터리를 사용하는 애플리케이션 식별
디렉터리에 액세스하는 애플리케이션 및 이러한 애플리케이션의 데이터 요구 사항은 디렉터리 콘텐츠 계획을 안내합니다. 디렉터리를 사용하는 다양한 일반적인 애플리케이션은 다음과 같습니다.
- 온라인 전화 서적과 같은 디렉터리 브라우저 애플리케이션. 사용자가 필요로 하는 정보를 결정하고 디렉터리에 포함합니다.
- 이메일 애플리케이션, 특히 이메일 서버. 모든 이메일 서버에는 디렉터리에서 일부 라우팅 정보를 사용할 수 있어야 합니다. 그러나 일부에는 사용자 username이 저장된 디스크의 위치, 휴가 알림 세부 정보 및 프로토콜 정보(예: Cryostat 대 POP)와 같은 고급 정보가 필요할 수 있습니다.
- 디렉터리 지원 인적 리소스 애플리케이션. 여기에는 정부 식별 번호, 집 주소, 집 전화번호, 생년월일, 급여 및 직책과 같은 추가 개인정보가 필요합니다.
- Microsoft Active Directory. Windows 사용자 동기화를 통해 Windows 디렉터리 서비스를 통합하여 Directory Server와 함께 작동할 수 있습니다. 두 디렉토리 모두 사용자 정보와 그룹 정보를 저장할 수 있습니다. 사용자, 그룹 및 기타 디렉터리 데이터를 동기화할 수 있도록 기존 Windows 서버 배포 후 Directory Server 배포를 구성합니다.
디렉터리를 사용할 애플리케이션을 평가할 때 각 애플리케이션에서 사용하는 정보 유형을 고려하십시오. 다음 표에서는 애플리케이션의 예와 애플리케이션에서 사용하는 정보를 제공합니다.
표 2.1. 애플리케이션 데이터 요구 예
| 애플리케이션 | 데이터 클래스 | data |
|---|---|---|
| 전화북 | 사람 | 이름, 이메일 주소, 전화번호, 사용자 ID, 비밀번호, 부서 번호, 매니저, 메일 중지 |
| 웹 서버 | 사람, 그룹 | 사용자 ID, 암호, 그룹 이름, 그룹 멤버, 그룹 소유자 |
| 일정 서버 | 자주하는 질문 | 이름, 사용자 ID, 항목 번호, 컨퍼런스실 이름 |
각 애플리케이션에서 사용하는 애플리케이션 및 정보를 식별하면 둘 이상의 애플리케이션에서 사용하는 데이터 유형을 파악할 수 있습니다. 계획의 이 단계는 디렉터리의 데이터 중복성을 방지하고 데이터 디렉터리 종속 애플리케이션에 필요한 데이터를 명확하게 표시할 수 있습니다.
다음 요인은 디렉터리에서 유지 관리되는 데이터 유형과 정보를 디렉터리로 마이그레이션할 때 최종 결정에 영향을 미칩니다.
- 다양한 레거시 애플리케이션 및 사용자에게 필요한 데이터
- 레거시 애플리케이션이 LDAP 디렉터리와 통신할 수 있는 기능
2.3.2. 데이터 소스 식별
디렉터리에 포함할 모든 데이터를 확인하려면 기존 데이터 저장소에 대한 설문 조사를 수행합니다. 설문 조사에는 다음이 포함되어야 합니다.
정보를 제공하는 조직을 식별합니다.
정보 서비스, 인적 자원, 급여 및 회계 부서와 같은 중요한 정보를 관리하는 모든 조직을 찾으십시오.
정보 소스인 툴 및 프로세스를 식별합니다.
일반적인 정보에는 네트워킹 운영 체제(예: Windows, Novell Netware, UNIX NIS), 이메일 시스템, 보안 시스템, PBX(tele phone switching) 시스템 및 인적 리소스 애플리케이션이 포함됩니다.
각 데이터를 중앙 집중화하는 것이 데이터 관리에 어떤 영향을 미치는지 결정합니다.
중앙 집중식 데이터 관리에는 새로운 도구와 새로운 프로세스가 필요할 수 있습니다. 경우에 따라 중앙 집중화에 조직의 직원 및 실패가 필요할 수 있습니다.
설문 조사 중에 아래 표와 같이 엔터프라이즈의 모든 정보 소스를 식별하는 매트릭스를 개발하십시오.
표 2.2. 정보 소스 예
| 데이터 소스 | 데이터 클래스 | data |
|---|---|---|
| 인사관리 데이터베이스 | 사람 | 이름, 주소, 전화번호, 부서 번호, 매니저 |
| 이메일 시스템 | 사용자, 그룹 | 이름, 이메일 주소, 사용자 ID, 비밀번호, 이메일 기본 설정 |
| 시설 시스템 | 기능 | 이름, 플로어 이름, 항목 번호, 액세스 코드 구축 |
2.3.3. 디렉터리 데이터 특성화
디렉터리에 포함할 데이터를 다음과 같은 방식으로 특성화합니다.
- 형식
- 크기
- 다양한 애플리케이션의 발생 수
- 데이터 소유자
- 다른 디렉터리 데이터와의 관계
디렉터리에 포함할 데이터에서 일반적인 특성을 찾습니다. 이렇게 하면 디렉터리 스키마 설계에 설명된 스키마 설계 단계에서 시간을 절약할 수 있습니다.
디렉터리 데이터를 특징으로 하는 아래 표를 고려하십시오.
표 2.3. 디렉터리 데이터 특성
| data | 형식 | 크기 | 소유자 | 관련 정보 |
|---|---|---|---|---|
| 직원 이름 | 텍스트 문자열 | 128자 | 인적 리소스 | 사용자 항목 |
| Fax 번호 | 전화 번호 | 14자리 | 기능 | 사용자 항목 |
| 이메일 주소 | 텍스트 | 여러 문자 | IS 부서 | 사용자 항목 |
2.3.4. 서비스 수준 확인
제공하는 서비스 수준은 디렉터리 지원 애플리케이션에 의존하는 사용자의 기대치에 따라 다릅니다. 각 애플리케이션에 필요한 서비스 수준을 확인하려면 애플리케이션이 사용되는 방법과 시기를 결정합니다.
디렉터리가 진화하면 이 디렉터리는 프로덕션에서 미션 크리티컬 수준에 이르기까지 다양한 서비스 수준을 지원해야 할 수 있습니다. 디렉토리 배포 후 서비스 수준을 올리기 어렵기 때문에 초기 설계가 향후 요구 사항을 충족하는지 확인합니다.
예를 들어 총 실패 위험을 제거하려면 여러 공급업체가 동일한 데이터를 처리하는 다중 공급 업체 구성을 사용합니다.
2.3.5. 데이터 공급자 고려
데이터 공급자는 데이터를 제공하는 서버입니다. 여러 위치에 동일한 정보를 저장하면 데이터 무결성이 저하됩니다. 데이터 공급자는 여러 위치에 저장된 모든 정보가 일관되고 정확한지 확인합니다. 다음 시나리오에는 데이터 공급자가 필요합니다.
- 디렉터리 서버 간 복제
- Directory Server와 Active Directory 간의 동기화
- Directory Server 데이터에 액세스하는 독립 클라이언트 애플리케이션
다중 제공 복제를 사용하면 Directory Server에 여러 서버의 기본 정보 사본을 포함할 수 있습니다. 여러 공급업체가 변경 로그를 유지하고 충돌을 안전하게 해결합니다. 변경을 수락하고 데이터를 복제본 또는 소비자 서버에 복제할 수 있는 제한된 수의 공급업체 서버를 구성할 수 있습니다. [1]. 여러 데이터 공급자 서버는 서버가 오프라인 상태가 되면 안전한 페일오버를 제공합니다. 다중 제공 복제에 대한 자세한 내용은 TBA[복제 프로세스 설계]를 참조하십시오.
동기화를 사용하면 Directory Server 사용자, 그룹, 속성 및 암호를 Microsoft Active Directory 사용자, 그룹, 속성 및 암호와 통합할 수 있습니다. 두 개의 디렉터리 서비스가 있는 경우 동일한 정보를 관리할지 여부, 공유할 정보의 양 및 데이터를 제공할 서비스를 결정합니다. 데이터를 관리하고 동기화 프로세스에서 다른 서비스에서 항목을 추가, 업데이트 또는 삭제할 수 있도록 하나의 애플리케이션을 선택하는 것이 좋습니다.
디렉터리와 간접적으로 통신하는 애플리케이션을 사용하는 경우 데이터 공급자 소스를 고려하십시오. 데이터 변경 프로세스를 가능한 한 간단하게 유지합니다. 데이터 조각을 관리하기 위한 위치를 결정한 후 동일한 위치를 사용하여 여기에 포함된 다른 모든 데이터를 관리합니다. 단일 위치에서 데이터베이스의 동기화가 손실될 때 문제 해결을 단순화합니다.A single place simplifies troubleshooting when databases lose synchronization across the enterprise.
다음과 같은 방법으로 데이터 공급을 제공할 수 있습니다.
디렉터리를 사용하지 않는 디렉터리 및 모든 애플리케이션에서 데이터를 관리합니다.
여러 데이터 공급업체를 유지 관리하는 데는 데이터 전송을 위한 사용자 지정 스크립트가 필요하지 않습니다. 이 경우 기업 전체에서 데이터 동기화를 방지하기 위해 다른 모든 사이트의 데이터를 변경해야 하지만 이는 디렉터리 목적에 반합니다.
비 디렉터리 애플리케이션에서 데이터를 관리하고 해당 데이터를 디렉터리로 가져오기 위해 스크립트, 프로그램 또는 게이트웨이를 작성합니다.
비 디렉터리 애플리케이션에서 데이터를 관리하는 것은 이미 애플리케이션을 사용하여 데이터를 관리하는 경우 가장 적합합니다. 또한 이 디렉터리는 온라인 회사 전화 서적과 같은 조회에만 사용할 수 있습니다.
데이터의 주요 복사본을 유지 관리하는 방법은 특정 디렉터리의 필요에 따라 다릅니다. 그러나 항상 유지 관리를 간단하고 일관되게 유지합니다. 예를 들어 여러 위치에서 데이터를 관리한 다음 경쟁하는 애플리케이션 간에 데이터를 자동으로 교환하지 마십시오. 이렇게 하면 업데이트가 손실되고 관리 오버헤드가 증가합니다.
예를 들어 디렉터리는 LDAP 디렉터리와 인사 리소스 데이터베이스 모두에 저장된 직원 홈 전화 번호를 관리합니다. 인적 리소스 애플리케이션은 LDAP를 사용할 수 있으며 LDAP 디렉토리에서 인사 데이터베이스로 데이터를 자동으로 전송할 수 있으며 그 반대의 경우도 마찬가지입니다.
LDAP 디렉토리 및 인적 리소스 데이터베이스 모두에서 해당 직원 전화 번호 변경 사항을 관리하려고 하면 전화 번호가 변경된 마지막 위치가 다른 데이터베이스의 정보를 덮어씁니다. 이는 데이터를 작성한 마지막 애플리케이션에 올바른 정보가 있는 경우에만 허용됩니다.
해당 정보가 오래된 경우(예: 인적 리소스 데이터가 백업에서 복원되었기 때문에) LDAP 디렉터리의 올바른 전화 번호가 삭제됩니다.
2.3.6. 데이터 소유권 확인
데이터 소유권 은 데이터가 최신 상태인지 확인하는 사람 또는 조직을 나타냅니다. 데이터 설계 단계에서 디렉터리에 데이터를 쓸 수 있는 사람을 결정합니다. 다음은 데이터 소유권을 결정하기 위한 몇 가지 일반적인 전략입니다.
- 작은 디렉토리 콘텐츠 관리자 그룹을 제외한 모든 사용자에 대해 디렉토리에 대한 읽기 전용 액세스를 허용합니다.
- 개별 사용자가 자신의 암호, 조직 내의 역할, 자신의 라이센스 번호, 전화 번호 또는 사무실 번호와 같은 연락처 정보와 같은 정보의 전략적 하위 집합을 관리할 수 있습니다.
- 개인 관리자가 연락처 정보 또는 직무 제목과 같은 해당 개인 정보의 전략적 하위 집합을 작성할 수 있습니다.
- 조직 관리자가 해당 조직의 항목을 생성하고 관리하도록 허용하여 디렉터리 콘텐츠 관리자 역할을 할 수 있습니다.
- 사용자 그룹이 액세스 권한을 읽거나 쓸 수 있도록 하는 역할을 생성합니다. 인적 리소스, 재무 또는 회계에 대한 역할을 생성할 수 있습니다. 이러한 각 역할에 대해 그룹에 필요한 데이터에 대한 읽기 액세스, 쓰기 액세스 또는 둘 다 가질 수 있도록 허용합니다. 여기에는 급여 정보, 정부 식별 번호 및 집 전화번호와 주소가 포함될 수 있습니다.
여러 개인에서 동일한 정보에 대한 쓰기 권한이 필요할 수 있습니다. 예를 들어 정보 시스템 또는 디렉터리 관리 그룹에는 직원 암호에 대한 쓰기 권한이 필요할 수 있습니다. 또한 직원에게는 자신의 암호에 대한 쓰기 액세스 권한이 필요합니다. 여러 사용자가 동일한 정보에 액세스할 수 있지만 이 그룹을 작게 유지하여 데이터 무결성을 보장하십시오.
2.3.7. 데이터 액세스 확인
데이터 소유권을 확인한 후 각 데이터를 읽을 수 있는 사용자를 결정합니다. 예를 들어, 직원 홈 전화번호를 디렉터리에 저장할 수 있습니다. 이 데이터는 직원 관리자 및 인적 자원 부서를 포함한 여러 사용자에게 유용할 수 있습니다. 직원은 확인 목적으로 이 정보를 읽을 수 있어야 합니다. 그러나 집의 연락처 정보는 민감한 것으로 간주 될 수 있습니다.
디렉터리에 저장된 모든 정보에 대해 다음을 고려하십시오.
누군가가 익명의 데이터를 읽을 수 있습니까?
LDAP 프로토콜은 익명 액세스를 지원하며 쉽게 정보를 조회할 수 있습니다. 그러나 누구나 디렉토리에 액세스할 수 있는 이러한 익명성으로 인해 이 기능을 신중하게 사용하십시오.
누군가가 기업 전체에서 데이터를 광범위하게 읽을 수 있습니까?
특정 정보를 읽기 위해 클라이언트가 디렉토리에 로그인(또는 바인딩)해야 하는 방식으로 액세스 제어를 설정할 수 있습니다. 익명 액세스와 달리 이러한 유형의 액세스 제어를 통해 조직의 멤버만 디렉터리 정보에 액세스할 수 있습니다. 또한 Directory Server 액세스 로그에는 정보에 액세스한 사용자에 대한 레코드가 포함되어 있습니다.
액세스 제어에 대한 자세한 내용은 액세스 제어 설계를 참조하십시오.
데이터에 액세스해야 하는 식별 가능한 사용자 또는 애플리케이션 그룹이 있습니까?
데이터에 대한 쓰기 권한이 있는 모든 사용자에게 읽기 액세스 권한도 필요합니다(암호에 대한 쓰기 액세스 제외). 디렉터리에는 특정 조직 또는 프로젝트 그룹과 관련된 데이터를 포함할 수도 있습니다. 이러한 액세스 요구 사항을 식별하면 필요한 그룹, 역할 및 액세스 제어 권한을 결정하는 데 도움이 됩니다.
그룹 및 역할에 대한 자세한 내용은 디렉터리 트리 설계를 참조하십시오. 액세스 제어에 대한 자세한 내용은 액세스 제어 설계를 참조하십시오.
디렉터리 데이터의 각 부분에 대해 이러한 결정을 내릴 때 디렉터리에 대한 보안 정책을 정의합니다. 이러한 결정은 사이트의 특성과 사이트에서 이미 사용 가능한 보안에 따라 달라집니다. 예를 들어 방화벽이 있거나 인터넷에 직접 액세스할 수 없으므로 디렉터리가 인터넷에 직접 배치된 것보다 익명 액세스를 지원하는 것이 더 안전합니다. 또한 일부 정보는 액세스를 적절하게 제한하기 위해 액세스 제어 및 인증 조치만 필요할 수 있습니다. 다른 민감한 정보는 저장 시 데이터베이스 내에서 암호화해야 할 수 있습니다.
대부분의 국가의 데이터 보호 법률은 기업이 개인 정보를 유지하고 액세스하는 방법을 관리합니다. 예를 들어, 법률에 따라 정보에 대한 익명 액세스를 금지하거나 사용자가 해당 정보를 나타내는 항목에서 정보를 보고 편집할 수 있도록 요청할 수 있습니다. 조직의 법률 부서에 문의하여 디렉터리 배포가 기업이 운영하는 국가의 데이터 보호법을 준수하는지 확인하십시오.
보안 정책 생성 및 구현 방법은 보안 디렉토리 설계에 자세히 설명되어 있습니다.
복제에서 소비자 서버 또는 복제본 서버는 공급자 서버 또는 허브 서버에서 업데이트를 수신합니다.
