Azure 上 SaaS 工作負載的身分識別和存取管理
應用程式身分識別是 SaaS 工作負載的重要領域，因為它可作為保護數據的第一道防線。 在項目後期，通常會忽略它，但應用程式其他元素的許多決策都取決於穩固的身分識別策略。 請勿低估身分識別在協助保護客戶數據方面的重要性。
在 SaaS 工作負載的內容中，有兩種不同的身分識別類型。
應用程式身分識別，也稱為 客戶身分識別和存取管理 （CIAM），可讓使用者驗證及使用您的 SaaS 應用程式。 登入應用程式識別提供者的使用者有兩個主要方法：
同盟識別身分。 使用者使用由另一個識別提供者維護的現有認證登入。 該提供者可以是社交識別提供者，例如 Google、Facebook 或 LinkedIn，或是您的客戶所使用的企業識別提供者，例如Microsoft Entra 或 Okta。 維護用戶帳戶是同盟識別提供者的責任。
本機身分識別。 使用者只會為您的應用程式建立帳戶。 帳戶會受到使用者名稱和密碼、密碼或其他驗證方法的保護。 維護用戶帳戶是您的責任。
企業身分 識別是用來向商務生產力工具、內部工具或服務及 Azure 服務驗證內部使用者和工作負載的身分識別解決方案。 您可以使用企業身分識別解決方案，讓內部使用者和工作負載向商務生產力工具、內部工具或服務及 Azure 服務進行驗證。
應用程式和企業身分識別有不同的用途，而且可能會使用不同的身分識別提供者。 本文著重於應用程式身分識別的設計考慮，不過這兩種類型可能都存在於您的 SaaS 工作負載環境中。
身分識別管理涉及兩個相關考慮：驗證（驗證使用者的身分識別）和授權（根據身分識別授與許可權）。 本文的前三節著重於 SaaS 的驗證。 最後一節說明 SaaS 提供者的授權考慮。
多租用戶應用程式中的身分識別
在多租用戶應用程式中將租用戶數據分開很重要。 該分割是由您選擇的有效使用者驗證和授權所驅動。 此外，租使用者模型的選擇會大幅影響您對身分識別提供者的決策。 將身分識別排定為主要周邊的優先順序。
如需分割，請參閱 SE：04 建議。
設計考量
瞭解應用程式的租用和部署模型。 可能會影響身分識別策略的細微差別。 例如，部署戳記模式需要每個戳記中的識別提供者，這是一種誤解。 針對大部分的識別提供者，您通常可以使用替代的隔離模型。
當您為多租使用者選擇識別提供者時，請評估失敗的影響。 設定錯誤可能會讓所有租使用者關閉整個應用程式。 根據潛在影響半徑的風險來權衡額外負荷成本。
如果您將解決方案部署至客戶的 Azure 環境並代表其管理，您可能需要與其企業身分識別提供者整合。 清楚了解這些層面：
- 當使用者與應用程式租用戶互動時，用戶類型和其存取需求。 例如，使用者 A 可能只需要登入租使用者 1 的存取權，但使用者 B 可能需要存取權才能登入租使用者 1 和租使用者 2。
- 如果數據落地法規適用於您的識別提供者，則符合數據落地法規。 在某些情況下，識別提供者所儲存的數據可能受限於法規。 許多身分識別提供者都提供此案例的特定指引和功能。 評估此案例是否與您相關，並採取必要步驟以確保合規性。
設計建議
| 建議 | 優點 |
|---|---|
| 請遵循身分識別提供者的最佳做法和指導方針，針對多個租使用者分割解決方案。 | 租用戶隔離可協助您達成安全性和合規性目標。 |
| 避免為同一個使用者有多個帳戶。 用戶應該有一組認證的單一帳戶，即使他們需要存取多個租使用者也一樣。 視需要授與每個租使用者的存取權，而不是為相同的使用者建立多個帳戶。 | 為相同使用者建立多個帳戶會增加安全性風險，並可能會混淆需要記住相同軟體之多個使用者名稱和密碼的使用者。 |
| 當您考慮數據落地時，請規劃如何將用戶數據儲存在不同的位置。 如果您在其他地理位置為使用者部署個別的部署戳記，您可能也需要個別的識別提供者。 如果您需要的話，請確定您有辦法識別用戶數據儲存的位置，以便將他們導向正確的登入區域。 |
您將能夠支持合規性需求，並藉由將使用者路由傳送至適合其位置的登入體驗，來增強用戶體驗。 |
識別提供者選取專案
每個識別提供者都提供獨特的功能、限制、定價模型和實作模式。 Microsoft Entra 和 Okta 是熱門的身分識別即服務 （IDaaS） 選項。 還有其他 開放原始碼 提供者，例如 Keycloak 和 Authentik。
設計考量
記錄您的身分識別需求。 首先，列出您的應用程式現在需要的功能，並在未來需要。 要考慮的一般功能包括：
-
- 同盟身分識別提供者支援，可與客戶的身分識別解決方案整合。 這項功能可讓您避免建立新的身分識別。
- 可自定義的登入/註冊流程，可修改外觀和風格，以維護您的品牌。 這項功能也可讓您將自定義商業規則插入登入/註冊程式。
- 將租用戶數據分割成不同的尋址接收器，以維護租用戶隔離。
- 稽核支援，以保留或匯出用於安全性管理的登入記錄。
重要
當您評估身分識別解決方案的成本時，請考慮規劃的使用者成長。 解決方案可能長期不具成本效益或可調整，但目前可能很有用。 如有需要，您可以利用移轉計劃。
例如，500 位使用者可能負擔得起解決方案，但 500 萬使用者不可持續。 如果它需要最少的設定，而且容易移轉，它仍然是正確的選擇，直到調整成本證明切換到不同的解決方案是正當的。
徹底研究識別提供者功能。 請確定身分識別解決方案符合您的必要功能清單。 即使您目前不需要複雜的案例，例如同盟身分識別，請考慮未來的需求。 針對企業對企業 （B2B） SaaS 解決方案，最終可能需要同盟身分識別。
考慮管理額外負荷。 不同的識別提供者需要不同層級的管理額外負荷。 已知的 IDaaS 解決方案通常負擔較少，因為它們會處理裝載、維護和安全性。 不過，如果解決方案更適合您的特製化需求，則 開放原始碼 解決方案的額外額外負荷可能值得。
設計建議
| 建議 | 優點 |
|---|---|
| 請勿建立您自己的身分識別解決方案。 身分識別是高度特製化的區域，而建立身分識別解決方案相當複雜且昂貴。 很難建立安全且可靠的身分識別解決方案。 | 您將避免建立自己的提供者並增強解決方案的安全性、可靠性和營運效率的反模式。 |
| 建立識別提供者所提供的功能功能矩陣，並根據您的身分識別需求對應。 | 您將確保能夠發展，而不會受限於一組有限的身分識別功能。 |
| 偏好使用 IDaaS 選項，而不是 開放原始碼 解決方案。 自行裝載 開放原始碼 解決方案會產生顯著的作業額外負荷和安全性風險。 不過，您可以選擇該選項，以符合提供者無法滿足的合規性、數據落地或可靠性的特定需求。 如需詳細資訊，請參閱 IDaaS 識別提供者。 |
藉由使用 IDaaS 身分識別提供者，您將避免不必要的複雜度，並將精力集中在核心業務上。 |
同盟身分識別
同盟身分識別，也稱為 單一登錄 （SSO），可讓使用者使用他們已在其他地方使用的認證登入。 您可以建立應用程式識別提供者與客戶現有識別提供者之間的信任關係，以啟用同盟身分識別。 同盟身分識別是 SaaS 解決方案的常見需求，特別是在 B2B 中，因為客戶偏好其員工使用公司認證。 它為 B2B 解決方案提供數個優點，例如集中式身分識別管理和自動生命週期管理。 在 B2C SaaS 產品中，與社交識別提供者整合很常見，可讓使用者使用現有的認證登入。
取捨：複雜度和營運效率。 藉由使用同盟識別提供者，您可以卸除管理使用者身分識別的複雜性。 不過，您會承擔與另一個識別提供者整合的成本。 決定您想要將作業工作放在何處。
雖然實作同盟身分識別一開始很簡單，但隨著支持的識別提供者數目增加，它變得更加複雜。 仔細規劃很重要，特別是當每位客戶使用唯一的身分識別提供者時。 即使他們使用相同的識別提供者，也經常需要每個客戶的唯一信任關係，因為特定設定詳細數據。
此影像顯示您的應用程式、應用程式識別提供者和您可能選擇使用身分識別同盟實作的下游識別提供者之間的關聯性。
設計考量
估計您需要支持的識別提供者類型和數目。 您可能需要靜態數目的社交識別提供者，或您可能需要每個客戶的唯一同盟識別提供者。 您應該知道您的客戶是否會使用 OpenID Connect （OIDC）、安全性判斷提示標記語言 （SAML）， 或兩者進行整合。
對應登入體驗。 將註冊和登入程式的使用者流程可視化。 請注意任何可能改變使用者流程設計的特殊需求。 例如：
自訂商標。 每個客戶的白標或自定義登入網域。
自訂資訊。 在註冊或登入期間收集其他用戶資訊，例如具有多個租使用者存取權之使用者的租用戶選擇。
識別提供者選取專案。 如果您使用單一應用程式識別提供者，其中有許多同盟識別提供者信任它，請決定如何選取提供者。 此選取專案可能透過按鈕手動完成，或根據已知的使用者信息自動完成。 隨著提供者數目的增加，自動選擇變得更加實用。 這項功能稱為 主領域探索。
設計建議
| 建議 | 優點 |
|---|---|
| 選擇可調整的識別提供者，以容納您需要的同盟識別提供者數目。 請注意提供者的硬性限制，無法超過此限制。 |
您將確保身分識別解決方案可在成長時進行調整。 |
| 規劃每個同盟識別提供者的上線，並盡可能自動化程式。 貴組織與客戶之間的這種共同作業工作牽涉到交換資訊以建立信任關係，通常是透過 OIDC 或 SAML 通訊協定。 |
身分識別整合對於您和您的客戶來說，可能需要時間和精力。 藉由規劃程式，您將提升作業效率。 |
| 在定價和商務模型中反映同盟身分識別的複雜性和成本。 讓客戶使用自己的身分識別提供者會增加作業複雜性和成本，因為維護多個同盟身分識別信任關係的額外負荷。 企業通常會在 SaaS 解決方案中支付較高層級的帳戶，以啟用同盟登入。 |
與客戶的身分識別提供者同盟，可能是 SaaS 解決方案中的隱藏成本。 藉由規劃，您將避免在實作期間產生非預期的成本。 |
| 規劃如何在登入流程期間選取使用者的身分識別提供者。 請考慮使用主領域探索。 Microsoft Entra ID 提供內 建的主領域探索。 |
您將簡化客戶體驗，並確保使用者導向正確的登入程式。 |
授權
使用者授權對於 SaaS 應用程式而言非常重要，通常會儲存多個租用戶的數據。 明確定義使用者如何只存取其數據，而不小心存取其他租用戶的數據。 此外，在租使用者內提供細微的授權，允許使用者讀取或存取特定資訊，同時限制更新或存取其他數據。
設計考量
為使用案例選擇正確的授權模型。 主要類型有兩種：
- 角色型授權。 用戶會獲指派角色或群組，且特定功能僅限於特定角色。 例如，系統管理員可以執行任何動作，但其他角色中的使用者具有有限的許可權。
- 資源型授權。 每個資源都有自己的一組許可權。 使用者可能是某個資源的系統管理員，但無法存取另一個資源。
決定儲存授權數據的位置。 應用程式的授權資料可以儲存在：
- 您的識別提供者。 利用內建群組或角色，將許可權呈現為向您的應用程式發出的令牌中的宣告。 接著，您的應用程式可以使用這些令牌宣告來強制執行授權規則。
- 您的應用程式。 開發您自己的授權邏輯，並將用戶權力儲存在資料庫或類似系統中，允許更精細的角色型或資源層級授權控件。
取捨：複雜度、彈性和安全性。 將授權資料儲存在識別提供者中，並透過令牌宣告呈現通常比管理您自己的授權系統簡單。 不過，宣告型授權會限制您的彈性，而且您必須接受只有在重新發出令牌時才會重新整理宣告，這可能會導致套用變更的許可權延遲。評估委派管理的影響。 在大部分的 SaaS 應用程式中，特別是在 B2B 應用程式中，角色和許可權管理會委派給客戶。 如果沒有這項功能，如果客戶經常變更其用戶的許可權，您可能會增加管理額外負荷。
評估多租使用者存取。 在某些系統中，單一使用者可能需要存取來自多個租用戶的數據。 例如，顧問可能需要存取來自多個租用戶的數據。 規劃客戶如何授與這些使用者的存取權，以及您的登入流程如何支援在租用戶之間選取和切換。
設計建議
| 建議 | 優點 |
|---|---|
| 除非明確允許該存取，否則防止使用者跨租使用者界限存取數據。 | 未經授權存取另一個租用戶的數據，甚至是意外存取，可視為重大安全性事件，並削弱客戶對平臺的信任。 封鎖不必要的存取可協助您避免這些情況。 |
| 如果數據是靜態的，而且不常變更，請將它儲存在識別提供者中。 如果使用者使用軟體時需要頻繁的變更，請將授權資料儲存在您的應用程式中。 | 為您的授權數據選取最佳數據存放區，可提升作業效率，並協助您符合延展性需求。 |
| 如果您將許可權管理委派給客戶，請提供明確的方法來管理許可權。 例如，建立只能供租用戶系統管理員存取以變更使用者許可權的入口網站。 | 您將為客戶提供更多控制權，並避免對支援小組造成不必要的操作負擔。 |
其他資源
多租用戶是設計 SaaS 工作負載的核心商務方法。 這些文章提供有關身分識別和存取管理的詳細資訊：
後續步驟
瞭解如何選擇計算裝載模型、操作層面，以及如何優化技術選項，以協助您符合您的服務等級協議和目標。