|
| |
| Sun Java(TM) System Directory Proxy Server 5.2 2005Q1 관리 설명서 | |
2장
Directory Proxy Server 배포 시나리오Directory Proxy Server는 컴퓨팅 환경에 따라 여러 가지 방법으로 배포될 수 있습니다. 이 장에서는 다음을 포함하여 일반적인 배포에 대해 설명합니다.
내부 고가용성 구성그림 2-1에 표시된 구성의 경우 고객이 LDAP 인프라를 회사 내부용으로 배포했습니다. 따라서 이 구성에는 회사 LDAP 서비스에 대한 외부 네트워크 액세스 요구 사항이 없습니다. 이 고객은 방화벽 외부에서 시도되는 내부 LDAP 서비스에 대한 액세스를 거부하도록 회사 방화벽을 배포했습니다. 고가용성을 위해 내부에서 초기화된 모든 클라이언트 LDAP 요청 역시 Cisco Local Director를 통해 Directory Proxy Server를 통과해야 합니다. 여기에서 Cisco Local Director는 클라이언트가 하나 이상의 Directory Proxy Server에 대한 액세스 권한이 있음을 확인하는 IP 패킷 전환의 예로만 표시됩니다. 이 고객은 Directory Proxy Server를 실행하는 호스트를 제외한 모든 사용자가 Directory Server에 직접 액세스하지 못하도록 금지합니다. 방화벽을 배포하여 직접 액세스를 금지하면 Directory Server 및 Directory Proxy Server를 실행하는 호스트를 보호할 수 있습니다.
그림 2-1 내부 고가용성 구성
분산 LDAP 디렉토리 인프라다음 절에서는 분산 LDAP 디렉토리 인프라에서의 Directory Proxy Server의 역할에 대해 설명합니다.
고객 시나리오
그림 2-2의 구성에 표시된 대형 금융 기관은 London에 본사를 두고 London, New York 및 Hong Kong에 데이터 센터를 가지고 있습니다. 현재 직원들이 사용할 수 있는 대부분의 데이터는 London의 기존 RDBMS 저장소에 집중되어 있습니다. 이 금융 기관의 클라이언트 커뮤니티는 항상 WAN(Wide Area Network)을 통해 이 데이터에 액세스합니다. 이 회사는 집중화된 모델의 확장성 및 성능 문제에 직면하여 분산 데이터 모델로 전환하고, 동시에 LDAP 디렉토리 인프라를 배포하기로 결정했습니다. 문제의 데이터는 "미션 크리티컬" 데이터로 간주되기 때문에 가용성이 높은 내결함성 인프라에 배포되어야 합니다. 클라이언트 응용 프로그램 프로필 분석을 통해 데이터는 고객을 기반으로 하기 때문에 지리적으로 분포한 클라이언트 커뮤니티에서 액세스하는 데이터의 95%가 해당 커뮤니티에 한정된다는 사실을 밝혀냈습니다. 즉, 아시아의 클라이언트가 북아메리카의 고객 데이터에 액세스할 수는 있지만 그런 일은 극히 드물게 발생하는 현상입니다. 또한 클라이언트 커뮤니티는 고객 정보를 자주 업데이트해야 합니다.
그림 2-2 분산 LDAP 디렉토리 인프라
고객 배포
이 금융 회사는 프로필을 통해 데이터 액세스의 95%가 해당 지역의 데이터에 한정된다는 사실을 확인하고 자사의 LDAP 디렉토리 인프라를 지역적으로 분산하기로 결정했습니다. 그 결과 다중 디렉토리 고객 서버를 각 지역(예: Hong Kong, New York 및 London, London 고객 서버는 다이어그램에 표시 안 됨)에 배포했습니다. 해당 지역의 고객 데이터는 각 고객 서버에 보관하도록 구성되어 있습니다. 즉, 유럽과 중동 지역의 고객 데이터는 London 고객 서버에 보관되고, 북아메리카와 남아메리카 지역의 고객 데이터는 New York 고객 서버에 보관되고, 아시아 환태평양 지역의 고객 데이터는 Hong Kong 고객 서버에 보관됩니다. 이 배포에는 로컬 클라이언트 커뮤니티의 압도적인 데이터 요구 사항이 해당 커뮤니티에 있습니다. 이 배포에서는 클라이언트 요청을 로컬로 처리하여 네트워크 오버헤드를 줄이고, 각 Directory Server에 디렉토리 인프라를 효과적으로 분할하여 향상된 Directory Server 성능과 확장성을 제공하기 때문에 집중화된 모델에 비해 성능 향상이 두드러집니다. 각 고객 Directory Server는 클라이언트가 업데이트 요청을 제출하거나 다른 지역의 데이터를 검색 요청할 경우 참조를 반환하도록 구성되어 있습니다.
LDAP 요청 흐름
클라이언트 LDAP 요청은 Cisco LocalDirector를 통해 Directory Proxy Server로 보내집니다. 여기에 표시된 LocalDirector 제품은 클라이언트가 항상 하나 이상의 Directory Proxy Server에 액세스할 수 있는 권한을 갖는지를 확인하는 IP 패킷 전환의 예로만 제공됩니다. 로컬로 배포된 Directory Proxy Server는 로컬 고객 데이터가 보관된 로컬 Directory Server 배열에 모든 요청을 라우팅합니다. Directory Proxy Server 인스턴스는 Directory Server 배열을 통해 로드 균형을 조정하여 자동 페일오버 및 페일백을 제공하도록 구성되어 있습니다. 로컬 고객 정보에 대한 클라이언트 검색 요청은 로컬 디렉토리에서 처리되며 해당 응답은 Directory Proxy Server를 통해 클라이언트에게 반환됩니다. "외부"(지리적) 고객 정보에 대한 클라이언트 검색 요청은 로컬 Directory Server에서 Directory Proxy Server로 참조를 다시 반환하여 처리됩니다.
이 참조에는 지리적으로 적절히 분산된 Directory Proxy Server 인스턴스를 가리키는 LDAP URL이 포함되어 있습니다. 로컬 Directory Proxy Server는 로컬 클라이언트 대신 참조를 처리하여 분산된 해당 Directory Proxy Server 인스턴스에 검색 요청을 보냅니다. 분산 Directory Proxy Server는 검색 요청을 분산 Directory Server로 전달하고 해당 응답을 받습니다. 그런 다음 이 응답을 Directory Proxy Server의 분산 인스턴스 및 로컬 인스턴스를 통해 로컬 클라이언트에 반환합니다.
로컬 Directory Proxy Server가 받은 업데이트 요청 또한 로컬 Directory Server에서 반환된 참조를 기준으로 처리됩니다. 또한 Directory Proxy Server는 로컬 클라이언트를 대신하여 참조를 따르지만 이 경우에는 업데이트 요청을 London에 있는 공급업체 Directory Server에 전달합니다. 공급업체 Directory Server는 공급업체 데이터베이스에 업데이트를 적용한 다음 로컬 Directory Proxy Server를 통해 로컬 클라이언트에 응답을 보냅니다. 공급업체 Directory Server는 업데이트를 해당 고객 Directory Server로 전파합니다.
모든 Directory Proxy Server는 시작한 다음 공급업체 Directory Server에서 해당 구성을 조사하도록 구성되어 있습니다. 이렇게 하면 여러 Directory Proxy Server 인스턴스를 지리적으로 분산할 수 있습니다. 이 경우에도 해당 구성은 집중 방식으로 관리됩니다.
집중 LDAP 디렉토리 인프라다음 절에서는 집중 LDAP 디렉토리 인프라에서 Directory Proxy Server의 역할에 대해 설명합니다.
고객 시나리오
그림 2-3에서는 고객과 직원이 전세계에 분산되어 있는 대형 글로벌 기업에 대해 설명합니다. 이 회사에서는 회사 화이트 페이지 및 옐로우 페이지(전자 전화 번호부)를 배포하여 전화 번호부 인쇄비를 줄이고, 회사 정보의 정확도를 높이고, 환경 자원의 사용을 줄이려고 합니다. 화이트 페이지 및 옐로우 페이지 정보는 해당 액세스 권한이 있는 고객과 직원이 모두 사용할 수 있어야 합니다. 고객과 직원이 전세계의 모든 시간대에 분산되어 있기 때문에 이러한 정보는 24시간 연중무휴로 사용 가능하고 임무 중심으로 분류되어야 합니다.
그림 2-3 집중 LDAP 디렉토리 인프라
고객 배포
글로벌 기업에서 집중 LDAP 디렉토리 인프라를 배포하여 화이트 페이지 및 옐로우 페이지의 배포를 지원하기로 결정했습니다. 화이트 페이지 및 옐로우 페이지는 회사 직원 전용이기 때문에 이 인스턴스에서 집중 배포를 선택했습니다. 이 데이터베이스는 고객이 일부 정보에 액세스할 수 있지만 고객 데이터베이스가 아닙니다. 확장성과 성능이 고려되지 않았기 때문에 데이터베이스의 프로젝트 크기(~200,000 항목)가 부족하여 이보다 복잡한 분산 배포 모델은 요청할 수 없습니다.
고가용성 요구 사항으로 인해 이 회사는 단일 공급업체 Directory Server에서 제공하는 다중 고객 Directory Server 복제본을 배포하기로 결정했습니다. 단일 공급업체 Directory Server에서 발생되는 단일 사고점을 제거하기 위해 이 회사는 백업 공급업체 Directory Server를 배포했습니다.
Directory Proxy Server는 세 가지 이유로 배포되었습니다. 첫째, 모든 LDAP 클라이언트와 Directory Server 복제본 배열 간의 로드 균형 조정 및 자동 페일오버/페일백을 제공합니다. 둘째, 외부 클라이언트와 내부 클라이언트를 구별하고 해당 액세스 권한을 설정할 수 있습니다. 셋째, 화이트 페이지 및 옐로우 페이지를 사용하는 LDAP 클라이언트와 Directory Server 간의 호환성을 제공합니다. LDAP 클라이언트는 사용자 작성 화이트 페이지 및 옐로우 페이지 응용 프로그램뿐만 아니라 고정 스키마 요구 사항에 부합하는 많은 기성 LDAP 사용 응용 프로그램을 사용합니다. 이러한 스키마 요구 사항이 회사에서 설계한 디렉토리 스키마와 항상 일치하는 것은 아니기 때문에 일부 기본 스키마 속성을 매핑해야 합니다. 또한 클라이언트가 사용하는 모든 LDAP 사용 응용 프로그램이 Directory Server로부터 받은 참조를 올바르게 처리할 수 있는 것은 아닙니다. Directory Proxy Server는 클라이언트를 대신하여 이러한 참조를 따르도록 구성되었습니다.
LDAP 요청 흐름
보낸 사람이 내부 클라이언트인지 외부 클라이언트인지 여부와 검색 요청인지 업데이트 요청인지 여부에 관계 없이 모든 클라이언트 요청은 Cisco LocalDirector를 통해 Directory Proxy Server 인스턴스로 보내집니다. 여기에 표시된 LocalDirector 제품은 클라이언트가 항상 하나 이상의 Directory Proxy Server에 액세스할 수 있는 권한을 갖는지를 확인하는 IP 패킷 전환의 예로만 제공됩니다. 단일 사고점이 발생하지 않도록 여러 Directory Proxy Server 인스턴스를 배포합니다. Directory Proxy Server 인스턴스는 클라이언트로부터 받은 모든 요청을 배열에 있는 모든 고객 Directory Server로 분산하여 로드 균형을 조정합니다. 또한 Directory Proxy Server는 고객 서버의 실패를 감지하여 배열 내의 사용 가능한 고객 서버에 페일오버합니다.
고객 서버는 읽기 전용 복제본이기 때문에 클라이언트로부터 업데이트 요청을 받을 경우 LDAP 참조를 반환하도록 구성됩니다. 이 참조에는 공급업체 Directory Server를 가리키는 LDAP URL이 포함되어 있습니다. Directory Server가 참조를 반환하면 Directory Proxy Server는 참조를 인식하여 클라이언트 대신 해당 참조를 따릅니다. 그런 다음 공급업체 Directory Server에 바인드하여 업데이트 요청을 보냅니다. 공급업체 Directory Server는 공급업체 데이터베이스에 업데이트를 적용한 다음 Directory Proxy Server를 통해 클라이언트에 응답을 보냅니다. 공급업체 Directory Server는 업데이트를 해당 고객 Directory Server로 전파합니다.
클라이언트가 보낸 검색 요청은 Directory Proxy Server를 통해 고객 Directory Server 복제 배열에 라우팅됩니다. 검색 요청을 Directory Server에 보내기 전에 "검사" 하여 특정 클라이언트 그룹에 대해 구성된 액세스 제어 및 보안 규칙에 맞지 않는 요청을 필터링하고 필요한 매핑을 수행하도록 Directory Proxy Server를 구성할 수 있습니다. 또한 Directory Server에서 반환되는 검색 결과를 "검사" 하여 해당 필터링 및 매핑을 다시 수행하도록 Directory Proxy Server를 구성할 수 있습니다. 그림 2-3에 표시된 예에서 내부 클라이언트와 외부 클라이언트가 모두 "Trevor" 항목에 대한 검색을 요청했습니다. 이러한 인바운드 요청은 클라이언트 유형에 관계 없이 Directory Proxy Server에서 동일하게 처리됩니다. Directory Server는 요청을 성공적으로 실행하고 "Trevor" 에 대한 항목을 Directory Proxy Server에 다시 반환합니다. Directory Proxy Server는 원본 요청을 보낸 사람이 내부 클라이언트인지 외부 클라이언트인지에 따라 검색 결과를 다르게 조작하도록 구성되어 있습니다. 외부 클라이언트의 경우에는 휴대 전화 번호 필드와 집 전화 번호 필드가 모두 고객에게 부적합한 데이터이기 때문에 필터링 됩니다. ou: development 속성/값 쌍이 department: development에 매핑되었습니다. 클라이언트가 디렉토리에 액세스하는 데 사용하는 응용 프로그램(예: Outlook, Outlook Express) 중 하나에 회사 Directory Server에 배포된 스키마 엘리먼트와 일치하지 않는 고정 스키마 요소가 있기 때문에 이 과정이 필요합니다. 내부 클라이언트의 경우에는 휴대 전화 번호는 직원 간에 공유할 중요한 데이터 요소이지만 집 전화 번호는 중요한 데이터 요소가 아닙니다. 따라서 내부 클라이언트의 경우 집 전화 번호만 필터링하고 클라이언트가 휴대 전화 번호는 볼 수 있도록 Directory Proxy Server를 구성합니다. ou 속성의 동일한 매핑이 department 속성에도 수행됩니다.
모든 Directory Proxy Server는 시작한 다음 공급업체 Directory Server에서 해당 구성을 조사하도록 구성되어 있습니다. 그렇게 하면 여러 Directory Proxy Server 구성을 한 디렉토리에서 집중 관리할 수 있습니다.
단일 방화벽이 있는 Directory Proxy Server 배포LDAP 클라이언트만 Directory Proxy Server가 실행 중인 시스템 및 포트에 액세스할 수 있도록 허용하려면 조직의 방화벽을 그림 2-4에 표시된 것처럼 구성해야 합니다. 일반적으로 LDAP 클라이언트는 TCP 포트 389에 연결합니다. 여기서는 액세스 권한이 없는 클라이언트가 무단으로 액세스하지 못하도록 Directory Proxy Server를 실행하는 호스트를 보호합니다. 또한 라우터 스위치를 사용하여 프록시 서버를 실행하는 호스트를 자체 LAN에 배치하여 불필요한 트래픽으로 네트워크 용량 초과 등과 같은 서비스 거부(DoS) 공격으로부터 내부 네트워크를 보호합니다. 방화벽은 LDAP가 LDAP Directory Server에서 "숨겨진" 시스템 및 포트에 액세스하지 못하게 하여 LDAP 디렉토리 데이터베이스를 보호해야 합니다.
그림 2-4 단일 방화벽이 있는 Directory Proxy Server 설정
두 개의 방화벽이 있는 Directory Proxy Server 배포그림 2-5에 표시된 구성은 그림 2-4에 표시된 구성의 모든 장점을 가지며 몇 가지 추가 보안을 제공합니다. 사이트 관리자가 외부 네트워크로부터의 트래픽을 제한할 수 있도록 두 방화벽을 설치하여 "프록시" 주위에 통제 영역을 만듭니다. 또한 "프록시" 서버 중 하나를 손상시켜 내부 네트워크에 있는 다른 시스템을 직접 공격할 수 없습니다. 방화벽 A는 대상 IP 주소가 해당 TCP 또는 UDP 프로토콜을 처리하는 프록시의 IP 주소일 경우 들어오는 패킷만 허용하도록 구성되어 있습니다. 방화벽 B는 프록시가 액세스하는 데 필요한 서버에 해당하는 프록시 시스템에서 가져온 패킷만 허용하도록 구성되어 있습니다.
그림 2-5 두 개의 방화벽이 있는 Directory Proxy Server 설정
