開発者ベスト プラクティスによるレジリエンス向上

  • [アーティクル]

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

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 移行があります。 しかし、サインインのたびに書き込みをする必要はありません。 ユーザー体験における前提条件は次のとおりです。

    <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 つのアプリケーションを使用してユーザー作成ジョブまたはスクリプトを分割する場合は、アプリケーションごとの制限を使用できます。 確実に 1 テナント当りのしきい値を下回るようにしてください。
    • 他のアプリケーションに対する移行ジョブの影響を把握すること。 他の依存アプリケーションによって提供されるライブ トラフィックを考慮して、テナント レベルでの速度制限やライブ アプリケーションのリソース不足が発生しないようにします。 詳しくは、「Microsoft Graph 速度制限ガイド」をご覧ください。
    • ロード テストのサンプルを使用して、サインアップとサインインをシミュレートします。
    • 詳しくは、「Azure AD 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) の証明書を含めることができます。
  • CI/CD を使用して、予想されるピーク シーズンから 2 か月以内に期限が切れるシークレットをローテーションします。 証明書に関連付けられている秘密キーの推奨される最大暗号化期間は 1 年です。
  • パスワードや証明書などの API アクセス認証情報を監視してローテーションします。

REST API のテスト

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

テスト計画

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

次のステップ