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

發行項
09/30/2024

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

Microsoft 驗證資源庫

Microsoft 驗證程式庫 (MSAL) 和適用 ASP.NET 的 Microsoft 身分識別網頁驗證程式庫，可簡化應用程式所需的權杖取得、管理、快取和重新整理作業。這些程式庫是為支援 Microsoft 身分識別而進行最佳化，包括可改善應用程式復原能力的功能。

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

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

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

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

避免在登入時將函式寫入目錄：在您的自定義原則中，避免在不含前置條件 (if 子句) 的情況下，於登入時執行寫入。除非像 Just-In-Time 使用者密碼移轉 (英文) 這類使用案例，才需要在登入時寫入。不需要寫入每次登入。使用者旅程圖中的先決條件如下：
```
<Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>
```
了解節流：目錄會實作應用程式和租用戶層級的節流規則。 Read/GET、Write/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 驗證服務無法完成新的註冊和登入時，可為登入的使用者提供緩解措施。透過設定，讓登入的使用者得以使用應用程式，無須中斷，直到登出應用程式，或工作階段因閒置逾時為止。

網頁和單頁應用程式 (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 提供服務。
- 切換至建議選項。使用程式碼交換證明金鑰 (PKCE) 和跨原始資源共用 (CORS) 支援，將 SPA 從隱含授與移轉至授權碼授與流程。
- 若是行動應用程式，同時延長重新整理和存取權杖存留期。
後端或微服務應用程式：後端 (精靈) 應用程式並非互動式，且不在使用者內容中，因此可降低權杖遭竊的風險。建議您盡量在安全性和存留期之間取得平衡，並設定較長的權杖存留期。

單一登入

使用單一登錄 (SSO)，使用者只需使用帳戶登入一次，即可存取應用程式：網頁、行動裝置或單頁應用程式 (SPA)，無論平台或網域名稱。當使用者登入應用程式時，Azure AD B2C 會保留 Cookie 型工作階段。

在後續的驗證要求中，Azure AD B2C 會讀取並驗證 Cookie 型工作階段，並在不提示使用者登入的情況下發出存取權杖。如果原則或應用程式上已設定有限範圍的 SSO，稍後存取其他原則和應用程式時會需要全新驗證。

設定 SSO

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

安全部署實務

最常見的服務干擾因素是程式碼和設定變更。採用持續整合與持續傳遞 (CICD) 程序和工具得以大規模快速部署，並減少測試和部署的人為錯誤。採用 CICD 來減少錯誤、確保效率及一致性。 Azure Pipelines 就是一種 CICD 範例。

防範 Bot

保護應用程式免遭已知的弱點所傷，例如分散式阻斷服務 (DDoS) 攻擊、SQL 插入、跨網站指令碼、遠端程式碼執行，以及 OWASP 前 10 大弱點中所記載的其他弱點。部署 Web 應用程式防火牆 (WAF)，防範常見的惡意探索和弱點。

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

密碼

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

實作密碼輪替

使用適用於支援資源的受控識別，向支援 Microsoft Entra 驗證的任何服務進行驗證。當您使用受控識別時，可以自動管理資源，包括輪替認證。
請清查 Azure AD B2C 中設定的金鑰和憑證。此清單可以包括自定義原則、API、ID 簽署權杖和安全性聲明標記語言 (SAML) 憑證中使用的金鑰。
使用 CICD，將會在預期旺季起兩個月內到期的密碼進行輪替。針對憑證的相關聯私密金鑰，其建議的加密期上限為一年。
監視和輪替 API 存取認證，例如密碼和憑證。

REST API 測試

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

測試計劃

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

共用方式為