Azure Front Door における Mutual TLS authentication (preview)

適用対象: ✔️ Front Door Premium

相互TLS(mTLS)認証、またはクライアント認証は、クライアントとサーバー間の双方向でトラフィックが安全かつ信頼されることを保証します。 mutual TLSを使うことで、Azure Front Doorで有効なクライアント証明書を提示してクライアントのアイデンティティを検証できます。 相互TLS認証は、B2B(B2B)アプリケーション、モノのインターネット(IoT)アプリケーション、銀行アプリ、VPN、エンタープライズネットワークなど、クライアントを安全に識別・管理するリソースをターゲットにする必要があるシナリオに役立ちます。

相互TLSやAzure Front Doorでサポートされている他の認証・認証方法を組み合わせて利用できます。

相互TLS検証モード

• mTLSを無効にしてください:クライアント証明書や検証は不要です。 このオプションが既定値です。

• mTLSを有効にする:

  • クライアント証明書の必要性と検証: クライアント証明書は必須です。 Azure Front Doorはクライアント証明書の存在確認、有効性、取り消しやRoot CAチェーン、SAN/CNリストのチェックを含む完全な検証を行います。 Azure Front DoorはヘッダーX-Azure-ClientCertificateのリクエストを送信元に転送します。 このオプションはmTLSが有効化された場合のデフォルトシナリオです。

  • クライアント証明書が必要だが検証されていない: クライアント証明書は必須です。 Azure Front Doorは他の検証を行いません。 Azure Front Doorは証明書を含まないリクエストをドロップします。 オリジンはすべての検証を行う必要があります。 デフォルトでは、Azure Front Doorはこのモードで証明書をヘッダー経由でバックエンドに渡します。

    • クライアント証明書の検証(提示がある場合): クライアント証明書は必須ではありません。 Azure Front Doorクライアント証明書が存在する場合に完全な検証を行い、X-Azure-ClientCertificateヘッダーを通じてクライアント証明書を送信元に転送します。 クライアントがクライアント証明書を提示しない場合、Azure Front Doorはリクエストを送信元に渡し、さらなる検証を行います。

  • mTLSパススルーから発信地へ: クライアント証明書は必須ではありません。 Azure Front Doorは検証を一切行いません。 オリジンはすべての検証を行う必要があります。

クライアント認証検証

Azure Front Doorでクライアント証明書の検証を設定すると、以下の情報がチェックされます:

• 現在の日付は証明書 Not After 日付より短いです。

• 現在の日付は証明書 Not Before 日付以上です。

• 証明書拡張キー使用は存在しませんか、存在してもクライアント認証OIDを含んでいます。

• 証明書のフォーマットが変更されていない有効性と完全性。

• 証明書チェーンを確認し、クライアント証明書が指定されたドメインの信頼できる発行者によって発行されている場合、認証のCN(証明書名)は途切れないチェーンを形成します。

また、以下のようなオプションの検証設定も可能です:

• クライアント証明書のSAN/CN拡張を、Azure Front Doorにアップロードされた許可されたSANリストと照らし合わせて検証してください。 Azure Front Doorのカスタムドメインホスト名は、相互TLS検証のために有効とみなされるために、このリストに明示的に含まれている必要があります。 SANが最初に検証され、マッチがなければ、またはSANが空ならCNが検証されます。 SANまたはCNのいずれかがAzure Front Doorで設定された許可されたSANリストと一致すれば、検証は成功します。

• クライアント証明書の取り消し状態はOCSP(オンライン証明書ステータスプロトコル)を使用して確認できます。

証明書失効の確認

Azure Front Doorは証明書の取り消し状態に対する検証をサポートしています。 既定では、有効になっています。 検証中、Azure Front DoorはAuthority Information Access(AIA)拡張機能の定義されたOCSPレスポンダーを使ってクライアントが提示した証明書を検索します。 クライアント証明書が取り消された場合、Azure Front DoorはクライアントにHTTP 403ステータスコードと理由を返します。 証明書が有効であれば、Azure Front Doorは引き続きリクエストの処理を続けます。

mTLSは公開証明書とプライベート証明書の両方をサポートしていますか?

Azure Front Doorは現在、有名な公開証明書局と民間設立の証明書局の両方から発行される証明書をサポートしています。

• 著名な証明書局から発行されるCA証明書: 信頼された証明書ストアには、中間証明書とルート証明書が含まれることが多く、デバイスに追加の設定がほとんどないか、ほとんど必要ないです。

• 組織が確立した認証機関から発行されるCA証明書: あなたの組織は通常、これらの証明書を非公開で発行しており、他の団体は信用していません。 クライアントがチェーントラストを確立するためには、中間証明書とルート証明書を信頼できる証明書ストアにインポートする必要があります。

しかし、Azure Front Doorはクライアント証明書がクライアント認証用かどうかを確認するために拡張キー使用(EKU)チェックを行います。 業界の変化により、公的証明書機関(CA)は間もなく必要なEKUを備えたクライアント認証証明書の発行を停止します。

Azure Front DoorのmTLSシナリオでは、正しいEKUで証明書を発行し続けるプライベートCAに移行しましょう。 この移行により、クライアント認証が途切れず安全なものとなります。

フロントドアドメインでmTLSを実装する前に重要な設計上の考慮事項

• 新しいドメインやエンドポイントでmTLSを有効にし、不要なダウンタイムを避けましょう。

• mTLSを有効にすると、ルートやルールエンジンのルートオーバーライドをキャッシュで有効にすることはできません。 この制限により、認証されていないクライアントにキャッシュされたコンテンツを返すことができません。

• mTLSはドメイン上で機能的に動作します。 しかし、悪意のあるユーザーがmTLSを迂回して送信元に到達できないセキュリティを確保するために、Azure Front DoorエンドポイントにはmTLSコントロールがあります。 カスタムドメインでmTLSを有効にする前に、まずカスタムドメインが関連付けられるAzure Front DoorエンドポイントでmTLSを有効にしてください。 mTLSを持つすべてのドメインは、そのようなエンドポイントのルートにのみ関連付けることができます。 相互認証の混合状態を持つドメインを同じエンドポイントに関連付けることはできません。

• Azure Front Doorのエンドポイントドメインをルートに関連付けることはできません。Front DoorエンドポイントでmTLSが有効になっている場合です。 逆に、エンドポイント上でmTLSを有効にする前に、エンドポイントドメインをすべてのルートからアソシエイト解除する必要があります。

• 既存のAzure Front DoorドメインでmTLSを有効にすると、以下の変更を行う必要があるためダウンタイムがあります。 新しいカスタムドメインにmTLSを有効にしてください。

1. mTLSを有効にした新しいエンドポイントを作成するか、既存のAzure Front DoorエンドポイントでmTLSを有効にして使用してください。

2. mTLSが有効でない既存のルートやエンドポイントからカスタムドメインを切り離してください。

3. その後、カスタムドメインをエンドポイントに再関連付けします。

• ドメインで相互認証が有効になると、それを無効にするとダウンタイムも発生します。

  1. 既存のmTLS対応エンドポイントのすべてのルートからカスタムドメインをアソシエイト解除してください。

  2. ドメイン上でmTLSを無効にしてください。

  3. ドメインをmTLSを有効にしていない別のエンドポイントに再関連付けしてください。

• 発信元にアクセス制御を追加して、リクエストが有効なフロントドアから来ているか確認してください。 詳細については、「Azure Front Door のオリジンへのトラフィックのセキュリティ保護」を参照してください。

• CA証明書管理:ルートと最大3つの中間ファイル(PEM、<25 KB)をAzure Key Vault経由でアップロードします。 オートローテーションはありませんが、デュアルCA対応によりシームレスなロールオーバーが可能です。

• Azure Front Doorはクライアント証明書に対して拡張キー使用(EKU)チェックを行い、それがクライアント認証用であることを確実にします。これは重要なセキュリティ対策です。 しかし、業界の変化により、公的証明書局(CA)はまもなく必要なEKUを備えたクライアント認証証明書の発行を停止します。 プライベートCAの利用に移行しましょう。これにより、Azure Front Door上でmTLSシナリオに適したEKU付きの証明書を発行し続け、途切れなく安全なクライアント認証を確保しましょう。

• 顧客はOCSPから離れつつあります。 Front Doorの証明書取り消しチェック中、Azure Front Doorは現在OCSPのみをチェックしています。

• クライアントが以下のヘッダーでリクエストを送ると、Azure Front Doorはヘッダーをドロップし、リクエストを発信元に転送します。

  • X-Azure-ClientCertEndDate
  • X-Azure-ClientCertFingerprint
  • X-Azure-ClientCertIssuer
  • X-Azure-ClientCertSerial
  • X-Azure-ClientCertStartDate
  • X-Azure-ClientCertSubject
  • X-Azure-ClientCertVerify
  • X-Azure-ClientCertificate

解法はどのような指標や対数フィールドを公開しますか?

解は以下の指標を明らかにします:

• mTLSリクエストの数。

• mTLSのリクエストが失敗しました。

• mTLSエラー要求は、エラータイプ、SNIホスト名、TLSプロトコルごとに分類されます。

構成クォータの上限

• クライアントCA証明書チェーンはルートと最大3つの中間ファイルを含めることができます。

• CA証明書はPEMエンコードで、25KB未満でなければなりません。

• 自動回転はサポートされていません。

• 失効や取り消しの際にシームレスにロールオーバーできるCA証明書を2枚付けることができます。 Azure Front Doorはランタイム中の検証に有効なCA証明書を使用します。

コンフィギュレーションの手順

1. 制限について詳しく知りたい方は、「 重要な設計上の考慮事項 」セクションをご覧ください。 新しいエンドポイントやドメインではmTLSを有効にすることが推奨されています。

2. Azureポータルにサインインし、Front Doorのプロフィールを検索してください。

3. セキュリティ欄でMutual TLS CA証明書を選択してください。 過去にアップロードしたmTLS証明書チェーンのリストが表示されます。

4. [+ 追加] を選択します。 アクセスできるKey VaultやSecretオブジェクトが見えます。 mTLSハンドシェイクの公開鍵部分として使いたいものを選択してください。

5. 設定の中から「フロントドアマネージャー」を選択してください。 エンドポイントのリストが表示されます。

6. +エンドポイントを追加し、「相互TLSの強制」を選択してください。

   Note

   .z01.azurefd.netが有効になっている場合、このエンドポイントのルートにAzure Front Doorデフォルトドメイン(例えば)をドメインとして追加することはできません。 次のステップでmTLSを有効にしたカスタムドメインを作成し、その後ルートを作成してください。

7. [設定] の下にある [Domains (ドメイン)] を選択します。 既存のカスタムドメインのリストが表示されます。

8. [+ 追加] を選択します。

9. ドメインを追加ページでドメインを設定し、詳細設定にスクロールして「相互TLSを有効にする」を選択してドメインの相互TLSを設定できます。

10. ドメインを作成するために 「追加」 を選択してください。

    1. 相互TLSモード:4つの選択肢から選択

       • クライアント証明書が必要で、検証済み
       • クライアント証明書は必要ですが、検証されていません
       • 提示された場合のクライアント証明書検証
       • mTLSの発信元へのパススルー

    2. Azure Front Doorに入力された際にCA証明書を選択してクライアント証明書を検証してください。

    3. 証明書取り消しチェックを有効にしてください。

    4. SAN/CNリストを追加して照合してください。 Azure Front Doorのカスタムドメインホスト名は、相互TLS検証のために有効とみなされるために、このリストに明示的に含まれている必要があります。

11. ドメイン作成が成功したら、Front Door Managerの先に作成したエンドポイントに移動し、このドメインを適切なオリジングループに関連付けるルートを追加します。

12. mTLSが正常に動作しているか確認してください。 この条件を確認するには、ローカルホストIPをAzure Front DoorのIPのいずれかに割り当てることができます。

13. 検証に成功した後、DNSのカスタムドメインCNMAEレコードをAzure Front Doorエンドポイントに更新します。

    バックエンド/オリジンアクセスをAzure Front Doorからのトラフィックのみに制限し、これによりmTLSを直接オリジン経由で回避するのを防ぎます。 詳細については、「Azure Front Door のオリジンへのトラフィックのセキュリティ保護」を参照してください。

ドメイン上の既存のmTLS設定を編集するには、 ドメインページ でドメイン名を選択してください。 ドメイン 編集 ページは現在のmTLS構成で表示されます。

Unexpected 403 (Forbidden) from Azure Front Door for mTLS request

さらなる診断情報については、Azure Front DoorリクエストとともにヘッダーX-Azure-DebugInfo:1を渡してください。 応答に対して、Front Doorはデバッグヘッダー X-Azure-Externalerrorを返し、エラーの可能性を示す値を付けます。 以下の表は誤差値とその意味を一覧にしています。

関連するコンテンツ

• Azure Front DoorによるTLS暗号化
• Azure Front Door TLS ポリシー