AppNote：身分識別管理解決方案目錄設計

Novell Cool Solutions：AppNote
作者：Blair Thomas、Garth Williamson、Jeremy Carter、Stuart Smith

在 Digg 上推薦這篇文章 - 在 Slashdot 上推薦這篇文章 發佈日期：2005 年 4 月 21 日

簡介

過去幾年來，目錄設計的理想方式已產生大幅演變。過去，許多人認為所有組織皆應採單一目錄設計以簡化管理工作，而這也是最早期的趨勢。過去的管理員努力設計出階層式的樹狀結構，以便在邏輯層面上將使用者置於接近其所需資源的位置。這種設計方式用在檔案/列印目錄上雖然非常理想，但對驗證或 LDAP 目錄而言卻是困難重重。管理員也發現，在他們的環境中，仍會用到許多需要獨立管理及進行安全維護的其他目錄。這些獨立的異質目錄及其相對應的身分，通常需要由獨立的 IT 群組管理。

圖 1 - 異質目錄

近來，IT 業界開始推行一種作法，以求簡化組織內各種目錄的管理工作，降低目錄及其所屬身分的相關管理成本。新近推出的安全身分識別管理 (SIM) 解決方案能為組織有效簡化目錄管理，並且安全地處理身分識別問題。SIM 建置的成敗端賴於目錄設計的健全與否。本文件將介紹 SIM 目錄設計與同步作業的幾項原則，讓您為 SIM 解決方案奠定穩固的基礎。

SIM 設計與 Identity Vault

Identity Vault 是 SIM 設計的起點。作為一項安全的中央儲存機制，Identity Vault 可用來儲存所有身分 (身分的屬性、角色及關係皆包括在內)。

圖 2 - Identity Vault

Identity Vault 同時還扮演著中樞的角色，可視需求接受來自其他目錄的身分資訊，或將身分資訊傳送至其他目錄。把身分識別資料傳送給 Identity Vault 的目錄是資訊提供者。從 Identity Vault 接收身分識別資料的目錄是資訊消費者。由於 Identity Vault 需要作為組織內其他目錄的介面，因此 Identity Vault 的底層目錄必須具備安全、可靠、靈活、快速等四大特性。Novell eDirectory 最適合作為 Identity Vault 的目錄。

基本 SIM 目錄同步模型如下：

圖 3 - SIM 目錄同步模型

想在不同目錄與資料庫間共享資料，還要保持資料的時效性，這在過去絕非易事。

多重目錄

由於過去的說法泰半強調單一目錄即可提供一切所需功能，在此，您可能會感到疑惑。多重目錄為何有其必要性？貴公司又該如何運用多重目錄？

簡單說來，理想不等於現實。讓我們藉此機會探討單一目錄為何無法成為貴組織完整的身分識別解決方案。讓我們簡短列出部分單一目錄的侷限所在，看看這些限制為何會成為安全風險、效能瓶頸，或衍生出諸多其他問題。

單一目錄的侷限、需求與挑戰

以下是單一目錄的侷限所在 (僅部分列舉，按照類別排列)：

1. 安全性：

• 內部與外部駭客
• 使用者身分資訊暴露

2. 效能問題

• 針對特定類型作業進行調校
• 索引

3. 分割區大小

• 需要較多分割區以支援 LAN/WAN 基礎結構
• 使用階層式設計進行管理

4. 僵化的設計

• 索引
• 查詢
• 管理
• 綱要

5. 複製與容錯

• 複製本太過靠近資訊消費者
• 網狀複製模型無法擴充

6. 物件

• 包含所有使用者屬性
• 可能導致身分識別資料完全暴露在所有資訊消費者面前

7. 綱要

過於僵化，必須考量到所有存取資料並進行標準化

綱要變更會影響所有使用者

以下為目錄需求 (僅部分列舉)：

• 企業需求
• 安全性
• 廠商、合作夥伴與客戶關係
• 風險管理
• 設計
• 效能
• 綱要
• 成長
• 管理
• 組織目標與模型
• 地理需求
• 結構
• 法律顧慮

從以上的清單看來，不管目錄規劃做得多詳盡，單一目錄恐怕還是無法完整提供必要的功能。IT 專業人員都知道，目錄可能因以下任何事件而改變：收購、合併、企業縮編、企業擴張、新產品線、新增/擴大合作夥伴與廠商陣容。因此，目錄設計的關鍵在於彈性：這點說來也許容易，但實際上做起來卻有一定難度在。

除上述各項需求外，在使用單一目錄時，以下狀況也將為您帶來挑戰：

1. 嘗試供應來自多位提供者的使用者身分識別資料
2. 內部與外部資訊消費者進行多重存取，意圖不明
3. 透過單一目錄管理安全性與效能

單一目錄既要保護使用者身分識別資訊，還要提供檔案與列印等多種服務，實在難以負荷。

多重目錄優勢

現在，讓我們來考慮如何以多重目錄改變身分識別管理解決方案的規則，並簡化其建置。我們要探索多重目錄解決方案在身分識別供應環境中的用途。我們相信，多重目錄適合絕大多數的組織，無論其規模大小，目錄物件數量多寡皆然。從下圖看來，設計考量有三：

1. Identity Vault
2. 身分識別提供者 - 目錄/資料庫
3. 使用者身分識別資訊的身分識別消費者

圖 4 - 身分識別管理模型

要建構穩固的使用者身分識別解決方案，Identity Vault 是關鍵所在。Identity Vault 應該和銀行的金庫一樣，只能讓少數個人接觸。這些人必須是可以信任的管理員，並獲賦予適當的存取控制權限。以下幾點可以協助您瞭解 Identity Vault 所代表的意義。

1. 我們可以將 Identity Vault 稱為超級目錄、儲存機制、安全目錄、全域目錄或中繼樹狀結構。
2. 使用者身分識別資訊會從「使用者資料提供者」流向「使用者資料消費者」，Identity Vault 則是資訊流動的中樞。
3. 所有的身分識別資料/屬性都將由 Identity Vault 加以彙總。其他目錄一律只能擁有這些身分識別資料/屬性的子集。
4. Identity Vault 絕不可供使用者存取，能夠存取的只有 1) 高階的目錄管理員 2) 在提供者與消費者之間同步處理使用者身分識別資料的 IDM2 連接器。
5. 只要輸入屬性值，所有使用者帳戶皆可在 Identity Vault 中停用，而且不會影響到這些帳戶在其他系統內的有效性。如此一來，便可強化安全性。此外，您也可以只讓特定 IP 位址或節區存取 Identity Vault，藉此達到隔離效果。
6. 您可以使用 Identity Vault 的連接器，讓其他目錄、資料庫與網域獲得調整設定的能力，以支援運用它們的服務。
7. 當使用者身分識別資料流經 Identity Vault 時，便可加以轉換。透過這種方式轉換屬性值，您便能設計出多種綱要來支援不同系統的需求。
8. 這是一種堅若磐石的存取控制基礎。
9. 您可以藉此發展出以角色為基礎的個人化和權限管理。

只要有良好的設計與建置，Identity Vault 便能成為所有使用者身分識別資料的儲存機制，無論其事涉機密與否。貴組織可保障使用者身分識別資料不致對內或對外洩漏。公司整體的安全性也可獲得嚴格把關。使用 IDM2 連接器建立 Identity Vault 後 (請參閱以下的「Identity Manager 驅動程式與同步化」一節)，便可透過 Identity Vault 提供使用者身分識別資料。這些連接器只能使用安全連線 (例如最基本的 SSL) 執行存取。您也可以視需求增加連線種類。

提供者

目錄提供者是現有或新增的目錄、資料庫或應用程式，其他目錄必須依靠它們所提供的使用者身分識別資料來滿足其用途。身分識別資料通常需靠手動方式在目錄間轉移。這會造成資料不一致、使用存取等待期過長，以及產生安全問題。我們的目標在於只需輸入資料一次，然後即可向其他系統提供該資料

資料提供者或來源可能是以下任一者：

• HR 資料庫
• 平台目錄
• 電子郵件與訊息系統
• 其他資料庫
• PBX
• RACF
• AS400

提供者通常會是使用者身分識別資訊的某個子集中，獲得授權的來源。使用者身分識別資訊可透過單一來源提供，亦可透過多重來源提供。它們共同構成使用者的身分，然後同步處理至 Identity Vault。

個別使用者屬性可透過連接器加以控制，使其流向 Identity Vault，然後再視需求回流給提供者。組織業務策略與需求都將反映在這套控制上。資料提供者也可以同時作為 Identity Vault 使用者資料子集的資料消費者。

只要使用了 IDM2 連接器，通常就不需要變更資訊提供者結構與綱要。如需變更，也是業務上的需求使然。如前所述，我們的目標在於只需輸入資料一次，便可為所有具備 IDM2 連線的系統更新其所需資訊。運用此模型後，整體擁有成本 (TCO) 可望隨之下降，資料正確性也會大幅增強。

資訊消費者與服務目錄

服務目錄是針對組織中特定用途或角色而設計的目錄、資料庫或應用程式。舉例來說，平台目錄/網域 (檔案與列印目錄) 便是一項服務目錄。服務目錄可採用符合資料消費者需求的設計，因其綱要與結構通常與 Identity Vault 不同。服務目錄所能獲得的，僅止於資料消費者所需的使用者身分識別資料 - 其他資料皆無法跨越雷池一步。過去在單一目錄中，使用者身分識別資料所受到的侵害，如今將可完全獲得消弭。

以下是服務目錄的優點 (僅部分列舉)：

• 它們會保護使用者資料，使其不致洩漏。
• 驗證規則、安全性、資訊消費者需求皆可針對服務目錄提供項目的需求加以調整。舉例來說，驗證目錄會需要白頁目錄用不到的屬性。
• 服務目錄綱要 (請參閱「綱要」一節) 能依據服務所使用的資料，採用符合服務需求的設計，因此可能異於 Identity Vault 或身分識別解決方案中的其他目錄。
• 在設計上，服務目錄要符合的是資訊消費者的需求。
• 服務目錄可位於 DMZ 中，這對使用者身分識別資訊而言完全不會有任何影響。

以下是服務目錄的部分特徵：

• 由應用程式、業務需求、組織或資料消費者加以定義，針對特定服務等級需求 (SLR) 進行調整。保護 Identity Vault 免受不當存取。
• 一般用途目錄針對一般用途進行調整，如讀/寫作業、一般索引。LDAP 存取機制所使用的目錄會針對讀取作業和特定索引功能進行調整。
• 可視為存放小量使用者資訊，以供驗證和白頁等功能使用的專門目錄。

服務目錄對應的若是特定角色或角色群組，而非互不關連，或可能牽涉到內、外部存取機制的多個角色，IT 人員便能更加輕鬆地設計和保護該目錄。舉例來說，服務目錄可位於 DMZ 中，供客戶進行 Web 存取。透過 IDM2 連接器，服務目錄資料將可與 Identity Vault 或儲存機制同步化。因為 Identity Vault 是使用者身分識別資料的中樞，連接器會確保只有必要的使用者屬性會同步到目錄中。將供應範圍限制在使用者身分識別資訊的子集上，可以減少安全風險和使用者身分洩露的可能性。

換成幾年前，建立這套資料流程根本是不可能的任務。但後來，由於目錄、HR 系統和資料庫開始共用通訊協定 (如 LDAP、XML 等)，原本的不可能也因而化為可能。現在，這些通訊協定能讓廠商共用身分識別資料，讓建置的公司降低整體擁有成本。

綱要

目錄物件的身分是由綱要構成。eDirectory 預設提供具備完整功能的基礎綱要，用以定義各種物件及其屬性。若基礎綱要不符公司所需，IT 人員可以透過許多方式來擴充綱要，加以彌補。舉使用者物件的使用為例。一家公司可能擁有數種類型的使用者，例如員工、約聘人員和廠商。這些使用者物件都需要特定屬性，才能完整構成該使用者類型。綱要擴充後，員工使用者便能擁有不同於廠商使用者或約聘人員使用者的屬性或身分。

公司可以透過不同的方式，精確辨識出目錄中的物件。下表列出四個可供運用，藉以達到成效的綱要選項。各選項的優缺點也將一併說明。

綱要選項	優點	缺點
使用基礎綱要	1. 簡單 2.以現有的未使用屬性來精確辨識出類別 3.以現有的屬性作為 IDM2 暫存屬性；未使用的屬性可用於儲存物件的永久值	1. 綱要無法符合公司需求 2.屬性名稱不符或不代表實際使用的屬性 3.Novell 或協力廠商軟體供應商可能已使用該屬性 4.非常缺乏彈性
擴充基礎綱要	1. 建立符合公司需求的屬性 2.易於建立	1. 缺乏彈性 2.有效類別一經建立後便難以刪除 3.新增至基礎類別的屬性難以刪除 4.像 Server (伺服器)、User (使用者)、Organization (組織) 這類的基礎類別，其擴充為永久性 5.可能導致綱要浮濫 6.無法處理使用者物件類別的預設 ACL 規則 7.無法變更現有類別的包含規則
在基礎綱要中使用輔助類別與屬性	1. 允許輔助類別以更為獨特的方式來代表不同類型的使用者或不同的物件群組 (此處僅為舉例說明) 2.刪除容易 - 如果要移除輔助類別與該類別所使用的延伸屬性，只需讓所有使用該屬性的物件成為空值即可 3.靈活、動態 4.輔助類別是可以附加到現有物件上的屬性群組 5.可在整體樹狀結構或特定使用者中輕鬆刪除新屬性與類別 6.物件可從屬於多個輔助類別 7.物件由所有有效屬性和繼承自輔助類別的屬性構成	1. 無法提供給舊版的 eDirectory 使用 (NDS8 之前) 2.若特定類型的每個物件都需要屬性，則本選項可能不甚理想
自定綱要	1. 可定義所有類別與屬性，以符合公司需求。不使用 eDirectory 基礎綱要。例如：不會用到使用者基礎類別。 2.類別可依照公司需求進行繼承，不用遵循 Novell 設定	1. eDirectory 管理需要自定或 LDAP 2.參考資料完整性無法由 eDirectory 維護，需要管理員手動作業 3.eDirectory 公用程式不會修復自定綱要 4.支援不易 5.伺服器物件等項目仍需使用基礎綱要

透過單獨或整合使用上述選項的方式，公司便可開發出能夠確實支援其業務需求的綱要。綱要策略的成功與否，關鍵在於讓綱要能有效符合公司需求、正確代表儲存在目錄中的物件，並且能隨著業務變更而加以修改。請記住，eDirectory 是定義 IDM2 驅動程式的要角，後者能使系統間的資訊達到同步化。

根據各使用者/物件的屬性而定，驅動程式會以屬性作為資料元素，主掌整體解決方案中的決策或企業規則與邏輯。

Identity Manager 驅動程式與同步化

我們已經討論過用來協助物件身分識別的目錄與綱要，但使用者身分識別資訊若不能在公司中共用，以上的一切都將失去意義。Identity Manager 2 (IDM2) 是一套應用程式。它不但可以在公司內部的所有系統間共享使用者資訊，還能視業務需求，與外界共用使用者資訊。IDM2 會以驅動程式或連接器作為連接架構，連接支援目錄功能的解決方案。這些驅動程式可將使用者資料與密碼同步到網路中的其他異質系統。身分同步與供應共同形成了管理個別使用者身分不同例項的跨系統流程。

圖 5 - 身分同步

Identity Manager 驅動程式是 eDirectory 和網路中其他不同系統間的連接器。當應用程式中的資料改變時，資料會傳送到 DirXML 引擎，然後儲存在 Identity Vault 中。其他連線的系統可視需求使用這些資料。這種動態共用資訊的方式，可讓企業網路擁有更加精確的資料儲存區，因為資料只需經輸入一次，即可同步到其他系統中。

建置

下一步是串連 Identity Solution 的各個環節，形成完整的解決方案。以下是身分識別解決方案的一個簡單例子。

XYZ 企業在促成 Identity Management 解決方案自動化時遭遇了若干挑戰。這些挑戰包括了：

• 降低身分識別管理的相關管理成本
• 減少取得電腦帳戶所需的時間
• 為員工與約聘人員提供多個系統的安全內部存取機制

XYZ 企業在本專案上的主要目標是減少企業應用程式存取的相關管理成本，其中包括供 XYZ 員工使用的 HR 系統與 XYZ 網域。更明確地說，這項需求評估作業的目標在於判定完成下列任務的最佳方法。

• 自動建立、刪除及停用 HR 系統與 Active Directory/ Exchange 2000 中的員工帳戶
• 身分識別與帳戶管理程序自動化，藉以降低管理成本

讓我們繼續針對這些需求來提供解決方案。必須處理的決策有三項：

1. 綱要需求
2. Identity Vault 設計
3. IDM2 驅動程式

XYZ 企業決定採用擴充綱要，並搭配使用以下屬性的輔助類別「XYZUsers」：

• XYZorgUnit - 用於在 XYZ 網域中放置使用者及建立群組
• XYZaction - 用於 HR 通往 Identity Vault 間的連線，決定是否要在 XYZ 網域中建立使用者物件

為使這項解決方案能作為 Identity Vault，需要新建目錄樹。Identity Vault 樹狀結構通常是扁平式樹狀設計。XYZ Identity Vault 在設計上將採用 3 個分割區：根分割區、使用者、服務。根分割區只會包含少數物件，並且採靜態設計。所有使用者物件都將放置在 Users (使用者) 容器中，而 Services (服務) 容器則會容納伺服器相關物件、IDM2 物件等。另外，此項建置會需要兩個 IDM2 驅動程式：HR 驅動程式和 AD/Exchange 驅動程式。

XYZ 企業的 Identity Management 解決方案如下圖所示：

圖 6 - 範例 Identity Management 解決方案

如遇下列情況，HR 驅動程式會將所有位於 HR 資料庫中的員工同步到 XYZ Identity Vault 中：

• Identity Vault 中的配置將由 XYZaction 值決定：
  若 XYZaction=Y，使用者物件將放置在 o=Users,ou=Active 容器中
  若 XYZaction=N，使用者物件將放置在 Users (使用者) 容器內部的 o=Users,ou=Disabled 容器中。
• Identity Vault 中的所有使用者帳戶都將設定為「login disabled = true」。
• Identity Vault 中的使用者帳戶不會遭到刪除；它們只會在 Active (有效) 和 Disable (停用) 容器間移動。

如遇下列情況，AD/Exchange 驅動程式將同步化：

• 除非 XYZaction=Y，否則使用者將不會同步到 XYZ 網域中。
• 若 XYZaction=Y，使用者將使用 XYZorgUnit 屬性值並放置在容器中。若 XYZorgUnit 容器結構不存在，將自動建立。XYZorgUnit 值會用來建立群組物件，然後使用者物件隨之建立，並新增至群組中。
• 使用者群組成員將隨時間累積，不會因 AD 驅動程式移除。舉例來說，當使用者因 HR 系統內的 XYZorgUnit 值變更而移動到新容器時，使用者將新增為新群組成員，但不會由先前的群組中移除。
• 在 XYZ 網域中建立的使用者將獲得一份電子郵件地址，然後同步到 Identity Vault，再同步到 HR 系統。
• 若使用者已存在於 XYZ 網域中，且若 XYZaction 屬性值由「Y」變更為「N」，則使用者物件將停用並移動至 o=XYZUsers,ou=Disabled 容器。在移動到 Disable (停用) 容器後，所有群組成員都將由使用者物件中移除。
• 若使用者已存在於 XYZ 網域中，且若 XYZaction 屬性值由「N」變更為「Y」，則使用者物件將啟用並由 o=XYZUsers,ou=Disabled 容器中移出。它會依照使用者的 XYZorgUnit 屬性值放置在容器中。若 XYZorgUnit 容器結構不存在，將自動建立，且使用者物件將在該處建立。使用者將會新增至所有與新增該使用者的容器相關的群組中。
• IDM2 不會由 XYZ 網域中刪除使用者帳戶。

結論

從這個簡單的例子中可以看出，Identity Vault 是由現有的 HR 系統建立，並取用其中資料。Identity Vault 中的綱要獲得擴充，以便採邏輯方式決定使用者物件的配置，無視乎使用者物件是不是在 AD 網域中所建立。群組物件依照屬性建立並填入資料。此範例說明了 IDM2 的能力、Identity Vault 的使用價值，以及如何按照未來需要或新業務需求來使用綱要。

Novell Cool Solutions (企業網路社群) 是由 WebWise Solutions 所製作。www.webwiseone.com