開発者のベスト プラクティスによる回復性

  • [アーティクル]

この記事では、大規模な顧客との共同作業の経験に基づいた教訓について説明します。 サービスの設計と実装において、次の推奨事項を検討してください。

開発者エクスペリエンス コンポーネントのダイアグラム

Microsoft Authentication Library

Microsoft Authentication Library (MSAL) と ASP.NET 用 Microsoft ID Web 認証ライブラリを使用すると、アプリケーションのトークンの取得、管理、キャッシュ、更新が簡素化されます。 これらのライブラリは、アプリケーションの回復性を向上させる機能など、Microsoft ID をサポートするように最適化されています。

開発者は、MSAL の最新リリースを導入し、最新の状態を維持できます。 アプリケーションで認証と認可の回復性を向上させる方法に関する記事を参照してください。 可能な限り、独自の認証スタックを実装しないでください。 代わりに、確立されたライブラリを使用してください。

ディレクトリの読み取りと書き込みを最適化する

Azure AD B2C ディレクトリ サービスは、1 秒あたりの読み取り率が高く、1 日に数十億件の認証をサポートします。 書き込みを最適化して、依存関係を最小限に抑え、回復性を向上させます。

ディレクトリの読み取りと書き込みを最適化する方法

  • サインイン時にディレクトリへの書き込み関数を使用しない: カスタム ポリシーの中で、前提条件 (if 句) を指定せずに、サインイン時に書き込みを実行しないようにします。 サインイン時に書き込みを必要とするユース ケースの 1 つとして、ユーザー パスワードの Just-In-Time 移行があります。 サインインのたびに書き込みをする必要はありません。 ユーザー体験での Preconditions は次のとおりです。

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

  • 調整について: ディレクトリには、アプリケーションおよびテナントのレベルで調整規則が実装されています。 読み取り/GET、書き込み/POST、更新/PUT、削除/DELETE の操作には、より多くのレート制限があります。 各操作には異なる制限があります。

    • サインイン中の書き込みは、新しいユーザーの場合は POST、現在のユーザーの場合は PUT に該当します。
    • サインインのたびにユーザーを作成または更新するカスタム ポリシーは、アプリケーション レベルの PUT または POST のレート制限に達する場合があります。 Microsoft Entra ID または Microsoft Graph を使用してディレクトリ オブジェクトを更新する場合にも同じ制限が適用されます。 同様に、読み取りを調べて、毎回のサインインでの読み取り回数を最小限に抑えます。
    • ピーク時の負荷を推定して、ディレクトリの書き込みレートを予測し、調整を回避します。 ピーク時のトラフィックの見積もりには、サインアップ、サインイン、多要素認証 (MFA) などのアクションの見積もりを含める必要があります。 Azure AD B2C システムとアプリケーションで、ピーク時のトラフィックをテストします。 Azure AD B2C は、ダウンストリーム アプリケーションまたはサービスが処理しない場合に、調整なしで負荷を処理できます。
    • 移行タイムラインを理解して、計画します。 Microsoft Graph を使用して Azure AD B2C にユーザーを移行する計画を立てる場合は、アプリケーションとテナントの制限を考慮して、ユーザーの移行を完了するまでの時間を計算します。 2 つのアプリケーションを使用してユーザー作成ジョブまたはスクリプトを分割する場合は、アプリケーションごとの制限を使用できます。 確実にテナントごとのしきい値を下回るようにします。
    • 他のアプリケーションに対する移行ジョブの影響を理解します。 他の依存アプリケーションによって提供されるライブ トラフィックを考慮して、テナント レベルでの調整やライブ アプリケーションのリソース不足が発生しないようにします。 詳しくは、「Microsoft Graph 調整ガイド」をご覧ください。
    • ロード テストのサンプルを使用して、サインアップとサインインをシミュレートします。
    • Azure Active Directory B2C サービスの制限と制約について理解してください。

トークンの有効期間

Azure AD B2C 認証サービスが新しいサインアップとサインインを完了できない場合は、サインインしているユーザーに軽減策を提供します。 構成により、サインインしているユーザーは、アプリケーションからサインアウトする、または非アクティブ状態によりセッション タイム アウトするまで、中断なしでアプリケーションを使用できます。

ビジネス要件とエンド ユーザー エクスペリエンスによって、Web およびシングルページ アプリケーション (SPA) のトークン更新頻度が決まります。

トークンの有効期間を延長する

  • Web アプリケーション: サインイン時に認証トークンが検証される Web アプリケーションの場合、そのアプリケーションはセッション Cookie に依存してセッションの有効性を延長し続けます。 ユーザー アクティビティに基づいて更新するローリング セッション時間を実装することで、ユーザーがサインインを維持できるようにします。 長期的なトークン発行の停止が発生した場合、これらのセッション時間は、アプリケーション上での 1 回限りの構成として延長できます。 セッションの有効期間は、許可されている最大値に維持します。
  • シングルページ アプリケーション: SPA は、API を呼び出すためにアクセス トークンに依存する場合があります。 SPA の場合は、認証コード フローと Proof Key for Code Exchange (PKCE) フローをオプションとして使用し、ユーザーがアプリケーションを引き続き使用できるようにすることをお勧めします。 SPA で暗黙的フローを使用している場合は、PKCE を使用した認証コード フローに移行することを検討してください。 アプリケーションを MSAL.js 1.x から MSAL.js 2.x に移行して、Web アプリケーションの回復性を実現します。 暗黙的フローでは、更新トークンは生成されません。 ブラウザーに Azure AD B2C とのアクティブなセッションがある場合、SPA は非表示の iframe を使用して、承認エンドポイントに対して新しいトークン要求を実行できます。 SPA の場合、ユーザーがアプリケーションを引き続き使用できるようにするためのオプションがいくつかあります。
    • アクセス トークンの有効期間を延長します。
    • API ゲートウェイを認証プロキシとして使用するようにアプリケーションを構築します。 この構成では、SPA は認証なしで読み込み、API 呼び出しは API ゲートウェイに対して行われます。 API ゲートウェイは、ポリシーに基づく認証コード許可を使用して、サインイン プロセスを通じてユーザーを送信し、ユーザーを認証します。 API ゲートウェイとクライアント間の認証セッションは、認証 Cookie を使用して維持されます。 API ゲートウェイは、API ゲートウェイによって取得されたトークン、または別の直接認証方法 (証明書、クライアント資格情報、API キーなど) を使用して、API にサービスを提供します。
    • 推奨されるオプションに切り替えます。 Proof Key for Code Exchange (PKCE) とクロスオリジン リソース共有 (CORS) のサポートを使用して、SPA を暗黙的な許可から認証コード許可のフローに移行します。
    • モバイル アプリケーションの場合は、更新およびアクセス トークンの有効期間を延長します。
  • バックエンドまたはマイクロサービス アプリケーション: バックエンド (デーモン) アプリケーションは非対話型であり、ユーザー コンテキスト内にないため、トークン盗難の可能性は減少します。 セキュリティと有効期間との間のバランスを取り、トークンの有効期間を長く設定することをお勧めします。

シングル サインオン

シングル サインオン (SSO) を使用すると、ユーザーはアカウントを使用して 1 回サインインし、プラットフォームまたはドメイン名に関係なく、Web、モバイル、シングル ページ アプリケーション (SPA) のアプリケーションにアクセスできます。 ユーザーがアプリケーションにサインインすると、Azure AD B2C によって Cookie ベースのセッションが保持されます。

それ以降の認証要求では、Azure AD B2C によって Cookie ベースのセッションが読み取られて検証され、ユーザーにサインインを求めずにアクセス トークンが発行されます。 SSO がポリシーまたはアプリケーションで、制限されたスコープを使用して構成されている場合、後で他のポリシーやアプリケーションにアクセスするには、新しい認証が必要です。

SSO の構成

テナント内の複数のアプリケーションおよびユーザー フローで同じユーザー セッションを共有できるように、テナント全体 (既定) を対象とするように SSO を構成します。 テナント全体の構成では、新しい認証に対して最も高い回復性が提供されます。

安全なデプロイ プラクティス

最も一般的なサービス中断は、コードと構成の変更です。 継続的インテグレーションと継続的デリバリー (CICD) のプロセスとツールを導入することで、大規模なデプロイが可能になり、テストおよびデプロイ中の人的エラーが減少します。 エラーの削減、効率、および整合性のために CI/CD を導入します。 Azure Pipelines は、CI/CD の 1 つの例です。

ボットからの保護

分散型サービス拒否 (DDoS) 攻撃、SQL インジェクション、クロスサイト スクリプティング、リモート コード実行、「OWASP Top-10」に記載されているその他のものなど、既知の脆弱性からアプリケーションを保護します。 Web アプリケーション ファイアウォール (WAF) をデプロイして、一般的な悪用と脆弱性から防御します。

シークレット

Azure AD B2C では、アプリケーション、API、ポリシー、および暗号化にシークレットが使用されます。 シークレットにより、認証、外部の相互作用、およびストレージがセキュリティで保護されます。 National Institute of Standards and Technology (NIST) は、正当なエンティティによって使用されるキー認可の期間を、cryptoperiod と呼んでいます。 必要な長さの cryptoperiod を選択します。 有効期限を設定し、有効期限が切れる前にシークレットをローテーションします。

シークレットのローテーションを実装する

  • サポートされているリソースに対してマネージド ID を使用して、Microsoft Entra 認証がサポートされているサービスに対して認証を行います。 マネージド ID を使用すると、資格情報のローテーションを含め、リソースの管理を自動的に行うことができます。
  • Azure AD B2C 内で構成されているキーと証明書のインベントリを取得します。 この一覧には、カスタム ポリシーの中で使用されるキー、API、署名 ID トークン、Security Assertion Markup Language (SAML) の証明書を含めることができます。
  • CICD を使用して、予想されるピーク シーズンから 2 か月以内に期限が切れるシークレットをローテーションします。 証明書に関連付けられている秘密キーの推奨される最大暗号化期間は 1 年です。
  • パスワードや証明書などの API アクセス資格情報を監視してローテーションします。

REST API のテスト

回復性のために、REST API のテストには、HTTP コード、応答ペイロード、ヘッダー、パフォーマンスの確認を含める必要があります。 正常系のテストのみを実行するのではなく、問題のあるシナリオを API が適切に処理することを確認してください。

テスト計画

テスト計画には、包括的な API テストを含めることをお勧めします。 キャンペーンまたは休日によるトラフィック急増の場合は、新しい見積もりでロード テストを改訂します。 運用内ではなく、開発環境内で API ロード テストとコンテンツ配信ネットワーク (CDN) を実施します。

次のステップ