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

  • 發行項

在本文中，我們會分享一些基於我們與大型客戶合作經驗的學習。 您可以在服務的設計和實作中考慮這些建議。

Image shows developer experience components

使用 Microsoft 驗證連結庫 （MSAL）

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

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

優化目錄讀取和寫入

Azure AD B2C 目錄服務每天支援數十億次驗證。 其設計目的是每秒讀取率很高。 將寫入優化，以將相依性降到最低，並增加復原能力。

如何優化目錄讀取和寫入

  • 避免在登入時將函式寫入目錄：在自定義原則中，絕對不要在登入時執行寫入，而不需前置條件 （if 子句）。 登入時需要寫入的其中一個使用案例是 用戶密碼的 Just-In-Time 移轉。 請避免在每次登入時都需要寫入的任何案例。 使用者旅程圖中的前置條件如下所示：

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • 瞭解節流：目錄會同時實作應用程式和租用戶層級節流規則。 讀取/GET、寫入/POST、更新/PUT 和刪除/DELETE 作業還有進一步的速率限制，而且每個作業都有不同的限制。

    • 登入時的寫入將屬於新使用者的POST，或現有使用者的PUT。
    • 在每次登入時建立或更新使用者的自定義原則，可能會達到應用層級 PUT 或 POST 速率限制。 透過 Microsoft Entra ID 或 Microsoft Graph 更新目錄物件時，會套用相同的限制。 同樣地，檢查讀取，以將每個登入的讀取數目保持在最小值。
    • 估計尖峰負載，以預測目錄寫入的速率，並避免節流。 尖峰流量估計應包含動作的估計值，例如註冊、登入和 Multi-Factor Authentication （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 傳統上會使用不會導致重新整理令牌的隱含流程。 如果瀏覽器與 Azure AD B2C 仍有作用中會話，SPA 可以使用隱藏 iframe 來對授權端點執行新的令牌要求。 針對 SPA，有幾個選項可讓使用者繼續使用應用程式。
    • 延伸存取令牌的有效期間，以符合您的商務需求。
    • 建置您的應用程式以使用 API 閘道作為驗證 Proxy。 在此設定中，SPA 會載入沒有任何驗證，而且 API 呼叫會對 API 閘道進行。 API 閘道會使用 以原則為基礎的授權碼授 與，透過登入程式傳送使用者，並驗證使用者。 然後，API 閘道與客戶端之間的驗證會話會使用驗證 Cookie 來維護。 API 閘道會使用 API 閘道取得的令牌來服務 API（或其他一些直接驗證方法，例如憑證、客戶端認證或 API 金鑰）。
    • 使用程式代碼交換證明密鑰（PKCE） 和跨原始來源資源分享 （CORS） 支援，將 SPA 從隱含授 與移轉至 授權碼授與流程 。 將您的應用程式從 MSAL.js 1.x 遷移至 MSAL.js 2.x，以實現 Web 應用程式的復原能力。
    • 針對行動應用程式，建議同時延長重新整理和存取令牌存留期。
  • 後端或微服務應用程式：因為後端（精靈）應用程式不是互動式應用程式，而且不在用戶內容中，因此令牌竊取的前景會大幅降低。 建議在安全性和存留期之間取得平衡，並設定長令牌存留期。

設定單一登錄

使用 單一登錄 （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 AD B2C 會針對應用程式、API、原則和加密使用秘密。 秘密會保護驗證、外部互動和記憶體。 國家標準與技術研究所（NIST）會呼叫特定密鑰獲得授權供密碼編譯機構使用的時間範圍。 選擇正確的密碼編譯時間長度，以符合您的業務需求。 開發人員必須在到期前手動設定到期日，並輪替秘密。

如何實作秘密輪替

  • 針對支持的資源使用 受控識別 ，向任何支援 Microsoft Entra 驗證的服務進行驗證。 當您使用受控識別時，您可以自動管理資源，包括認證輪替。
  • 清查 Azure AD B2C 中設定的所有金鑰和憑證。 此清單可能會包含自定義原則、 API、簽署標識元令牌和SAML憑證中使用的金鑰。
  • 使用 CICD，輪替即將在預期高峰期兩個月內到期的秘密。 與憑證相關聯的私鑰建議上限為一年。
  • 主動監視和輪替 API 存取認證，例如密碼和憑證。

測試 REST API

在復原內容中，REST API 的測試必須包含 – HTTP 程式代碼、響應承載、標頭和效能的驗證。 測試不應只包含快樂的路徑測試，也會檢查 API 是否正常處理問題案例。

如何測試 API

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

下一步