透過開發人員最佳做法進行復原

發行項
07/02/2024

在本文中，您可以受益於我們與大型客戶合作的經驗。您可以針對服務的設計和實作考慮這些建議。

Microsoft 驗證資源庫

Microsoft驗證連結庫（MSAL）和適用於 ASP.NET 的Microsoft身分識別 Web 驗證連結庫可簡化應用程式的取得、管理、快取和重新整理令牌。這些連結庫已優化以支援Microsoft身分識別，包括改善應用程式復原功能的功能。

開發人員可以採用最新版的 MSAL 並保持最新狀態。了解如何提高應用程式的驗證和授權復原能力。可能的話，請避免實作您自己的驗證堆疊。請改用妥善建立的連結庫。

將目錄的讀取和寫入最佳化

Azure AD B2C 目錄服務每天支持數十億次驗證，每秒的讀取率很高。將寫入最佳化，以將相依性降至最低並提高復原能力。

如何將目錄的讀取和寫入最佳化

避免在登入時將函式寫入目錄：避免在自定義原則中執行寫入登入，而不需前置條件（if 子句）。除非像 Just-In-Time 使用者密碼移轉 (英文) 這類使用案例，才需要在登入時寫入。不需要寫入每個登入。使用者旅程圖中的先決條件如下：
```
<Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>
```
瞭解節流：目錄會實作應用程式和租用戶層級節流規則。讀取/GET、寫入/POST、Update/PUT 和 Delete/DELETE 作業有更多速率限制。每個作業都有不同的限制。
- 登入期間的寫入屬於新使用者的POST，或目前使用者的PUT。
- 在每次登入時建立或更新使用者的自定義原則，可以達到應用層級 PUT 或 POST 速率限制。透過 Microsoft Entra ID 或 Microsoft Graph 更新目錄物件時，也適用相同的限制。同樣地，請檢查讀取情況，以將每次登入時的讀取次數維持在最小值。
- 估計尖峰負載以預測目錄寫入的速率，並避免節流。尖峰流量估計應該包括註冊、登入和多重要素驗證（MFA）等動作的估計值。測試 Azure AD B2C 系統和您的應用程式是否有尖峰流量。當下游應用程式或服務不會進行節流時，Azure AD B2C 可以處理負載。
- 了解並規劃您的移轉時程表。規劃使用 Microsoft Graph 將使用者遷移至 Azure AD B2C 時，請考慮應用程式和租使用者限制來計算完成使用者移轉的時間。如果您使用兩個應用程式來分割使用者建立作業或腳本，您可以使用每個應用程式的限制。請確定它仍低於每個租使用者閾值。
- 了解您的移轉作業對其他應用程式的影響。請考慮其他信賴憑證應用程式所提供的即時流量，以確保您的即時應用程式不會在租用戶層級進行節流和資源耗盡。如需詳細資訊，請參閱 Microsoft Graph 節流指引。
- 使用負載測試範例來模擬註冊和登入。
- 深入瞭解 Azure AD B2C 服務限制。

權杖存留期

如果 Azure AD B2C 驗證服務無法完成新的註冊和登入，請為登入的使用者提供風險降低。透過設定，登入的使用者可以使用應用程式，直到他們從應用程式註銷，或會話從非使用中逾時為止。

您的業務需求和用戶體驗會決定 Web 和單頁應用程式令牌重新整理的頻率（SPA）。

延長權杖存留期

Web 應用程式：對於在登入時驗證驗證令牌的 Web 應用程式，應用程式會相依於會話 Cookie，以繼續擴充會話有效性。藉由實作根據用戶活動更新的輪流會話時間，讓使用者保持登入。如果有長期令牌發行中斷，這些會話時間可以增加為應用程式的一次性設定。將工作階段存留期保持在允許的最大值。
SPA：SPA 可能相依於存取令牌來呼叫 API。針對 SPA，我們建議使用授權碼流程搭配程式碼交換證明金鑰（PKCE）流程作為選項，讓用戶繼續使用應用程式。如果您的 SPA 使用隱含流程，請考慮使用 PKCE 移轉至授權碼流程。將您的應用程式從 MSAL.js 1.x 遷移至 MSAL.js 2.x，以實現 Web 應用程式的復原能力。隱含流程不會產生重新整理令牌。如果瀏覽器具有與 Azure AD B2C 的作用中會話，SPA 可以使用隱藏 iframe 來對授權端點執行新的令牌要求。針對 SPA，有幾個選項可讓使用者繼續使用應用程式。
- 延長存取令牌的有效期間。
- 建置您的應用程式，以使用 API 閘道作為驗證 Proxy。在此組態中，SPA 會載入但不進行驗證，而 API 呼叫則會對 API 閘道進行。 API 閘道會使用授權碼授與，根據原則，透過登入程式傳送使用者，並驗證使用者。 API 閘道與客戶端之間的驗證會話會使用驗證 Cookie 來維護。 API 閘道會使用 API 閘道取得的令牌，或其他直接驗證方法來服務 API，例如憑證、客戶端認證或 API 金鑰。
- 切換至建議的選項。將 SPA 從隱含授與移轉至授權碼授與流程，並提供程式碼交換證明金鑰（PKCE）和跨原始來源資源分享（CORS）支援。
- 針對行動應用程式，延長重新整理和存取令牌存留期。
後端或微服務應用程式：後端（精靈）應用程式不是互動式應用程式，而且不在用戶內容中，因此令牌竊取的前景會減少。我們建議在安全性和存留期之間取得平衡，並設定長令牌存留期。

單一登入

使用單一登錄（SSO），使用者只要使用帳戶登入一次，即可存取應用程式：無論平臺或域名為何，Web、行動裝置或單一頁面應用程式（SPA）。當使用者登入應用程式時，Azure AD B2C 會保存以 Cookie 為基礎的會話。

在後續的驗證要求時，Azure AD B2C 會讀取並驗證 Cookie 型會話，併發出存取令牌，而不會提示使用者登入。如果 SSO 在原則或應用程式上設定了有限的範圍，則稍後存取其他原則和應用程式需要新的驗證。

設定 SSO

將 SSO 設定為全租用戶範圍 (預設)，以讓租用戶中的多個應用程式和使用者流程共用同一個使用者工作階段。全租用戶組態提供最新的驗證復原能力。

安全部署實務

最常見的服務中斷是程式代碼和設定變更。採用持續整合和持續傳遞（CICD）程式與工具，可大規模部署，並減少測試和部署期間的人為錯誤。採用 CICD 來減少錯誤、確保效率及一致性。 Azure Pipelines 就是一種 CICD 範例。

保護 Bot

保護您的應用程式免於已知的弱點，例如分散式阻斷服務（DDoS）攻擊、SQL 插入、跨網站腳本、遠端程式代碼執行，以及其他記載於 OWASP Top-10 中的弱點。部署 Web 應用程式防火牆（WAF）以防範常見的惡意探索和弱點。

使用 Azure WAF，以針對攻擊提供集中式保護。
搭配使用 WAF 與 Microsoft Entra Identity Protection 和條件式存取，以在使用 Azure AD B2C 時提供多層保護。
整合 CAPTCHA 系統 (英文)，讓 Bot 驅動的註冊具有復原能力。

密碼

Azure AD B2C 會使用密碼來處理應用程式、API、原則和加密作業。密碼可保護驗證、外部互動和儲存體的安全。國家標準與技術研究所（NIST）是指合法實體使用密鑰授權的時間範圍，作為 密碼編譯。選擇密碼編譯程式所需的長度。設定到期日，並在秘密到期前輪替秘密。

實作秘密輪替

使用適用於支援資源的受控識別，向支援 Microsoft Entra 驗證的任何服務進行驗證。當您使用受控識別時，可以自動管理資源，包括輪替認證。
清查 Azure AD B2C 中設定的金鑰和憑證。此清單可以包含自定義原則、 API、簽署識別元令牌和安全性判斷提示標記語言（SAML）憑證中使用的密鑰。
使用 CICD，輪替秘密，從預期的高峰期到期兩個月內。針對憑證的相關聯私密金鑰，其建議的加密期上限為一年。
監視和輪替 API 存取認證，例如密碼和憑證。

REST API 測試

針對復原能力，REST API 測試必須包含 HTTP 代碼、響應承載、標頭和效能的驗證。請勿只使用快樂的路徑測試，並確認 API 會正常處理問題案例。

測試計劃

建議您的測試計劃包含完整的 API 測試。對於因促銷或假日流量而激增，請以新的估計來修改負載測試。在開發人員環境中執行 API 負載測試和內容傳遞網路（CDN），而不是在生產環境中。

共用方式為