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

發行項
06/19/2024

我們會在本文中分享一些和大型客戶合作的經驗法則。您可以在設計和實行服務時考慮這些建議。

圖片顯示開發人員體驗元件

使用 Microsoft 驗證程式庫 (MSAL)

Microsoft 驗證程式庫 (MSAL) 和適用於 ASP.NET 的 Microsoft 身分識別 Web 驗證程式庫，可簡化應用程式所需的權杖取得、管理、快取和重新整理作業。這些程式庫是專為支援 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 Active Directory 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 前 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 測試。如果您要為即將而來的促銷或假日流量爆量做規劃，則必須使用新的估計值來修改負載測試。在開發人員環境中進行 API 與內容傳遞網路 (CDN) 的負載測試，而不是在生產環境中執行。

共用方式為