|
| Sun ONE Directory Proxy Server 管理員指南 |
第 2 章 Sun ONE Directory Proxy Server 部署方式
根據您的運算環境，部署 Sun ONE Directory Proxy Server 的方法可能有幾種。本章描述並說明一般的部署方式，包括：
· 內部高可用性組態
· 部署有單一防火牆的 Directory Proxy Server
· 部署有兩個防火牆的 Directory Proxy Server
內部高可用性組態
圖 2-1 所示的組態中，客戶已部署一個 LDAP 基礎架構僅供內部企業使用。外部網路沒有存取任何企業 LDAP 服務的需求。客戶已經部署了企業防火牆，會拒絕從防火牆外、向內部 LDAP 服務發出的任何存取要求。從內部發出的所有用戶端 LDAP 要求，都必須利用 Cisco LocalDirector 經由 Directory Proxy Server (才能有高可用性功能)，此處僅為範例，說明 IP 封包切換能確保用戶端能至少存取一個 Directory Proxy Server。客戶禁止任何人 (除了執行 Sun ONE Directory Proxy Server 的主機之外) 直接存取目錄伺服器，您可以使用防火牆來保護執行目錄伺服器及 Directory Proxy Server 的主機，以達成此目的。
圖 2-1 內部高可用性組態
分散式 LDAP 目錄基礎架構
以下各節說明 Directory Proxy Server 在分散式 LDAP 目錄基礎架構中的角色：
· 客戶案例
· 客戶部署
客戶案例
圖 2-2 所示的組態中，某大型金融機構的總部在倫敦，資料中心則在倫敦、紐約及香港。目前員工可使用的資料大部分都集中在倫敦的舊型 RDBMS 儲存庫。金融機構用戶端群體對這些資料發出的所有存取要求，都是透過廣域網路 (WAN)。該金融機構的這種集中模式碰到了擴充及效能問題，並決定改成分散式資料模式。該金融機構也決定要同時部署 LDAP 目錄基礎架構。此處所討論的資料已視為「關鍵任務」，因此應以高可用性、容錯的基礎架構來部署。分析用戶端應用程式設定檔後，發現各地區用戶端群體所存取的資料，有 95% 是各區群體所特有，因為該資料是以客戶為基礎。亞洲的用戶端鮮少存取北美洲的客戶資料，但是偶爾還是會有。用戶端群體也需要偶爾更新客戶資訊。
圖 2-2 分散式 LDAP 目錄基礎架構
客戶部署
由於結果顯示 95% 是本地資料存取，所以金融機構決定將 LDAP 目錄基礎架構依地理區域分散。該機構在各個地理位置部署多個目錄取用者伺服器 (這些地理位置例如香港、紐約、倫敦；圖表中並未顯示倫敦取用者伺服器)。每個取用者伺服器設定成只存放該地區的客戶資料。歐洲及中東的客戶資料存放在倫敦的取用者伺服器中，南、北美洲的客戶資料存放在紐約的取用者伺服器中，亞太地區的客戶資料存放在香港的取用者伺服器中。這種部署方式將本地用戶端群體過於龐大的資料需求放在各群體中。此舉可大幅改善集中模式的效能，因為用戶端要求是在當地處理，所以降低了網路的額外負荷；當地的目錄伺服器以有效率的方式分割目錄基礎架構，所以增加目錄伺服器的效能及擴充性。每一組取用者目錄伺服器，都設定成如果用戶端提交更新要求或其他地方資料的搜尋要求，就會傳回轉介。
LDAP 要求流程
系統透過 Cisco LocalDirector，將用戶端 LDAP 要求傳送給 Sun ONE Directory Proxy Server。此處的 LocalDirector 產品僅為範例，說明 IP 封包切換能確保用戶端一定至少能存取一個 Directory Proxy Server。在本地部署的 Directory Proxy Server 一開始會將所有要求導向存放本地客戶資料的本地目錄伺服器陣列。 Directory Proxy Server 實例設定成讓目錄伺服器陣列負載平衡，所以提供自動容錯移轉及容錯回復功能。本地目錄及透過 Directory Proxy Server 傳回用戶端的適當回應，滿足了用戶端對本地客戶資訊的搜尋要求。本地目錄伺服器將轉介傳回 Directory Proxy Server，初步滿足用戶端對「外地」客戶資訊的搜尋要求。
此轉介包含 LDAP URL，指向依地區分散的適當 Directory Proxy Server 實例。本地的 Directory Proxy Server 代表本地用戶端處理此轉介，並將搜尋要求傳送給適當的分散 Directory Proxy Server 實例。分散的 Directory Proxy Server 會將搜尋要求轉送給分散的目錄伺服器，並接收適當的回應。然後透過分散的本地 Directory Proxy Server 實例，將此回應傳回到本地用戶端。
本地目錄伺服器傳回的轉介，也初步滿足了本地 Directory Proxy Server 接收的更新要求。 Directory Proxy Server 也是代表本地用戶端跟隨此轉介，可是這次是將更新要求轉送給倫敦的供應者目錄伺服器。供應者目錄伺服器將更新套用到供應者資料庫，並透過本地的 Directory Proxy Server 將回應傳送回本地用戶端。然後供應者的目錄伺服器會將更新向下傳送給適當的取用者伺服器。
所有的 Sun ONE Directory Proxy Server 都設定成啟動並在供應者目錄伺服器中尋找自己的組態。此舉允許您依地理位置分散多個 Directory Proxy Server 實例，但是能集中管理組態。
集中式 LDAP 目錄基礎架構
以下各節說明 Directory Proxy Server 在集中式 LDAP 目錄基礎架構中的角色：
· 客戶案例
· 客戶部署
客戶案例
圖 2-3 描述的是客戶與員工遍佈全球的大型國際企業，該企業想要部署全企業的電子電話簿，以降低印刷紙本電話簿的成本、提升企業資訊的正確性、並節省自然環境資源。電子電話簿資訊必須讓客戶及員工都能使用，並且有適當的存取控制措施。而且要全天候都能使用，又因為客戶與員工散佈全球各時區，所以將這個特色視為關鍵任務。
圖 2-3 集中式 LDAP 目錄基礎架構
客戶部署
該國際企業決定部署集中式 LDAP 目錄基礎架構，以部署電子電話簿。在本實例中選擇集中式部署，是因為電子電話簿僅供企業員工參考。此並非客戶資料庫，雖然目的是讓客戶存取某些資訊。目前認為預估的目錄資料庫大小 (大約 200,000 個項目) 不足以要求更複雜的分散式部署模式，因為擴充性及效能都不會是問題。
由於有高可用性的要求，該企業決定部署多個取用者目錄伺服器副本，由單一供應者目錄伺服器提供。為了消除單一供應者目錄伺服器所衍生的單一失效點問題，此企業部署了備份供應者目錄伺服器。
部署 Sun ONE Directory Proxy Server 有三個理由。首先要在所有 LDAP 用戶端及目錄伺服器副本陣列之間，提供負載平衡及自動容錯移轉及容錯回復功能。其次要能分辨外部及內部的用戶端，並依此設定適當的存取控制措施。第三要讓使用電子電話簿的 LDAP 用戶端之間，以及目錄伺服器之間相容。除了利用自訂建立的電子電話簿應用程式以外，LDAP 用戶端也利用許多現成的啟用 LDAP 應用程式，內附固定結構需求。這些結構需求不一定符合此企業設計的目錄結構，所以需要基本的結構屬性對應作業。此外，用戶端使用的啟用 LDAP 應用程式，並非全都能正確處理目錄伺服器傳送的轉介。Sun ONE Directory Proxy Server 設定成代表用戶端跟隨這些轉介。
LDAP 要求流程
系統會透過 Cisco LocalDirector，將所有的用戶端要求 (不管是從內部或外部用戶端發出，也不管是搜尋要求或更新要求) 傳送給 Directory Proxy Server 實例。此處的 LocalDirector 產品僅為範例，說明 IP 封包切換能確保用戶端一定至少能存取一個 Directory Proxy Server。部署多個 Directory Proxy Server 實例是為了確保沒有單一失效點問題。 Directory Proxy Server 實例會在陣列中所有取用者目錄伺服器之間，負載平衡用戶端傳送的所有要求。 Directory Proxy Server 也會偵測任何取用者伺服器的失效情形，並容錯移轉至陣列中可使用的取用者伺服器。
由於取用者伺服器是唯讀的副本，所以設定成在從用戶端接收更新要求時，會傳回 LDAP 轉介。此轉介包含 LDAP URL，指向供應者目錄伺服器。目錄伺服器傳回轉介時， Directory Proxy Server 會辨識出來，並代表用戶端跟隨此轉介。此舉會連結至供應者目錄伺服器，並將更新要求傳送至此。供應者目錄伺服器將更新套用到供應者資料庫，並透過 Directory Proxy Server 將回應傳送回用戶端。然後供應者的目錄伺服器會將更新向下傳送給適當的取用者伺服器。
用戶端傳送的搜尋要求會透過 Directory Proxy Server，導向至取用者目錄伺服器副本陣列。您可設定讓 Sun ONE Directory Proxy Server 先「檢查」這些搜尋要求，再傳送給目錄伺服器，並篩選掉哪些要求不符合特定用戶端群組組態的存取控制措施及安全規則，並執行必要的對應作業。您也可設定讓 Directory Proxy Server「檢查」目錄伺服器傳回的搜尋結果，再執行適當的篩選及對應作業。在圖 2-3 所示的範例中，內部及外部的用戶端已要求搜尋屬於 Trevor 的項目。 Directory Proxy Server 將這些傳入的要求都用相同方式處理，不管用戶端類型。目錄伺服器順利執行要求，並將 Trevor 項目傳回給 Directory Proxy Server。 Directory Proxy Server 已經設定好，會根據原始要求是從內部或是外部用戶端發出，而用不同的方式操作搜尋結果。如果是外部用戶端，就會篩選掉項目中的行動電話號碼及家用電話號碼欄位，因為這些資料不適合讓客戶知道。還要注意 ou: development 屬性/值已經對應到 department: development。這是必要的，因為用戶端用來存取目錄的應用程式之一 (例如 Outlook、Outlook Express) 有固定的結構元素，它們並不符合部署在企業目錄伺服器中的結構元素。如果是內部用戶端，就會判斷行動電話號碼是很重要的資料元素，要公佈給員工，家用電話號碼就不是。如果是內部用戶端， Directory Proxy Server 的設定，就只會篩選掉家用電話號碼，讓用戶端看到行動電話號碼。請注意，系統也會執行將 ou 屬性對應到 department (部門) 屬性的功能。
所有的 Sun ONE Directory Proxy Server 都設定成啟動並在供應者目錄伺服器中尋找自己的組態。此舉允許從一個目錄集中管理多個 Directory Proxy Server 組態。
部署有單一防火牆的 Directory Proxy Server
您的組織的防火牆必須依圖 2-4 所示來設定，僅允許 LDAP 用戶端存取執行 Directory Proxy Server 的機器及連接埠。通常 LDAP 用戶端會連線到 TCP 連接埠 389 上。這個動作會保護執行 Directory Proxy Server 的主機，使其不會受到用戶端未經授權即嘗試存取。此外，利用路由器切換將執行代理伺服器的主機放在自己的區域網路上，可保護您的內部網路不會受到阻絕服務攻擊，譬如以不必要的網路流量對網路進行流量攻擊。防火牆也應禁止 LDAP 存取「隱藏」LDAP Directory Server 的機器及連接埠，藉以保護 LDAP 目錄資料庫。
圖 2-4 Directory Proxy Server 有一個防火牆的設定
部署有兩個防火牆的 Directory Proxy Server
圖 2-5 所示的組態有圖 2-4 所示組態的所有優點，還有其他的安全性。安裝兩個防火牆可以在「代理伺服器」周圍建立控制區，允許網站管理員評估從外部網路發出的網路流量限制。此舉也確保如果「代理」伺服器之一受到入侵，不會被用來直接攻擊內部網路中的其他機器。防火牆 A 會設定成僅允許傳入封包通過 (如果目標 IP 位址是處理 TCP 或 UDP 通訊協定的代理伺服器)。防火牆 B 會設定成僅允許從代理伺服器機器發出的封包通過 (此機器需適合代理伺服器必須存取的伺服器)。
圖 2-5 Directory Proxy Server 有兩個防火牆的設定
