アプリケーション・ロードバランサーにおける TLS の相互認証について
相互トランスポート層セキュリティ（ mTLS ）認証は、クライアントとロードバランサー間、およびロードバランサーとバックエンドサーバー間の証明書ベースの認証を有効にすることで、 IBM Cloud® アプリケーション・ロードバランサー（ALB）のセキュリティを強化します。
「 TLS 」とは何ですか？
mTLS これは、標準の TLS プロトコルの拡張であり、接続の両当事者がデジタル証明書を使用して相互に認証を行うことを要求するものです。 標準の TLS では、サーバーがクライアントに対して証明書を提示するだけでよいのに対し、 mTLS では、クライアントとサーバーの両方が証明書を提示する必要があり、双方向認証の仕組みが構築されます。
mTLS のALBサポートを利用すると、2つのレベルで証明書ベースの認証を実装できます：
- フロントエンド認証
- ロードバランサーのリスナーに接続する際、クライアントに有効な証明書の提示を義務付けることで、クライアントの身元を確認します。
- バックエンド認証
- クライアント証明書を提示して、ロードバランサーをバックエンドサーバーに対して認証し、必要に応じてバックエンドサーバーの証明書を検証します。
主要な機能
ALB mTLS サポートでは、以下の機能を提供しています：
- リスナーでのクライアント証明書の検証
- クライアント証明書を検証するために、認証局（CA）証明書を設定し、ロードバランサーのフロントエンドでクライアント認証を有効にします。 この検証により、信頼できるCAによって署名された有効な証明書を持つクライアントのみが接続を確立できるようになります。
- 証明書失効リスト（CRL）のサポート
- CRLをアップロードして、クライアント証明書が失効していないかを確認し、不正アクセスを受けた証明書や有効期限が切れた証明書を拒否することで、セキュリティをさらに強化します。
- バックエンドサーバーの証明書検証
- TLS のハンドシェイク中にバックエンドサーバーの証明書を検証し、ロードバランサーが信頼できるバックエンドサーバーにのみ接続するようにします。 バリデーションは、中間者攻撃を防ぐのに役立ちます。
- バックエンドでのクライアント認証
- バックエンドインフラストラクチャで mTLS が要求される場合、ロードバランサーからバックエンドサーバーに対してクライアント証明書を提示し、安全な双方向認証を実現します。
ユース・ケース
mTLS 認証は、セキュリティの強化や本人確認が必要な場面において有用です：
- ゼロトラスト・セキュリティアーキテクチャ
- すべての接続に対して証明書ベースの認証を義務付けることでゼロトラストの原則を実装し、通信が確立される前にすべてのクライアントとサーバーの認証が行われるようにします。
- APIセキュリティー
- クライアントに有効な証明書の提示を義務付けることでAPIエンドポイントを保護し、機密性の高いAPIへの不正アクセスを防止するとともに、認証済みのアプリケーションのみがサービスを利用できるようにします。
- マイクロサービス間の通信
- フロントエンドとバックエンドの両方で mTLS を実装し、すべてのサービス間通信が認証および暗号化されるようにすることで、マイクロサービス間の通信の安全性を確保します。
- コンプライアンス要件
- 金融サービス、医療、政府機関などの分野において、強力な認証メカニズムを義務付ける規制遵守要件を満たします。
- バックエンドサーバーでの検証
- バックエンドサーバーの証明書を確認し、ロードバランサーが正当なバックエンドサーバーにのみ接続するようにすることで、不正なバックエンドインスタンスや侵害されたバックエンドインスタンスからの攻撃を防ぎます。
mTLS とアプリケーションロードバランサーの連携方法
ALBは、クライアントからロードバランサーへの接続およびロードバランサーからサーバーへの接続の両方において、 mTLS をサポートしています。 以下のワークフローは、 TLS の各ハンドシェイクにおいて、証明書の検証がどのように行われるかを示しています。
フロントエンドの mTLS （リスナーレベル）
リスナーレベルでクライアント認証（ mTLS ）を有効にすると：
- クライアントは、ロードバランサーに対して HTTPS 接続を確立します。
- ロードバランサーは、クライアントに対して自身のサーバー証明書を提示します。
- ロードバランサーは、クライアントに対してクライアント証明書の提示を要求します。
- クライアントは、ロードバランサーに証明書を提示します。
- ロードバランサーは、設定されたCA証明書と照合してクライアント証明書を検証します。
- CRLが設定されている場合、ロードバランサーは、その証明書が失効しているかどうかを確認します。
- 検証に成功すると、接続が確立されます。 それ以外の場合は、接続が拒否されます。
バックエンドの mTLS （プールレベル）
プールレベルでサーバー認証またはクライアント証明書の提示を有効にする場合：
- ロードバランサーは、バックエンドサーバーへの接続を開始します。
- バックエンドサーバーは、ロードバランサーに対して自身の証明書を提示します。
- サーバーの検証が有効になっている場合、ロードバランサーは、設定されたCA証明書に対してバックエンドサーバーの証明書の有効性を検証します。
- バックエンドサーバーがクライアント認証を要求した場合、ロードバランサーは自身のクライアント証明書を提示します。
- バックエンドサーバーは、クライアント証明書を検証します。
- 認証に成功すると、接続が確立され、トラフィックがバックエンドサーバーへと流れる。
証明書失効リスト（CRL）のサポート
CRLとは、有効期限が切れる前にCAによって失効処理された証明書のリストのことです。 証明書は、以下のようなさまざまな理由により失効する場合があります
- 秘密鍵が漏洩しました
- 証明書が誤って発行されました
- 証明書保有者の権限が変更されました
- その証明書はもう必要ありません
リスナーのCRLを設定すると、ロードバランサーは TLS ハンドシェイク中に、各クライアント証明書を失効リストと照合します。 証明書がCRLに掲載されている場合、その証明書がそれ以外では有効であり、適切に署名されているとしても、接続は拒否されます。
CRLのサポートにより、有効期限が切れていない場合でも、不正取得された証明書や無効化された証明書がサービスへのアクセスに使用されないよう保証することで、セキュリティをさらに強化します。
前提条件
ALB 向けに「 mTLS 」を設定する前に、以下の要件を満たしていることを確認してください
- mTLS をサポートするプロファイルを持つALBがあります。 ロードバランサーのプロファイルで、
mtls_supportedプロパティを確認してください。 - このリスナーは HTTPS プロトコルを使用しています。 mTLS は、 HTTPS リスナーでのみ利用可能です。
- Secrets Manager には、 PEM 形式の有効な証明書が保存されています。
- Secrets Manager において、ロードバランサーの管理および証明書へのアクセスを行うための適切な IAM 権限をお持ちです。
証明書の要件
mTLS で使用されるすべての証明書は、以下の要件を満たす必要があります：
- 証明書は、 PEM 形式でなければなりません。
- 証明書は Secrets Manager に保存し、CRNで参照できるようにする必要があります。
- 検証に使用されるCA証明書には、完全な証明書チェーン（ルート証明書および中間証明書）が含まれている必要があります。
- ロードバランサーがバックエンドサーバーに提示するクライアント証明書には、秘密鍵が含まれている必要があります。
- 証明書は有効（有効期限が切れていない）であり、信頼できる認証局（CA）によって適切に署名されている必要があります。
重要な考慮事項
実装する際には、以下の点に留意してください mTLS:
- 証明書管理の責任
- 証明書の取得、アップロード、更新、失効処理など、すべての証明書の管理はお客様の責任となります。 IBM Cloud では、証明書の自動管理や自動更新は行われません。
- 証明書の検証
- 証明書が所定の認証局によって適切に署名されており、信頼関係が正しく確立されていることを確認する必要があります。 無効な証明書や不一致の証明書があると、 TLS のハンドシェイクが失敗し、サービスが利用できなくなります。
- バックエンドサーバーの検証
- 下位互換性を維持するため、バックエンドサーバーの検証はデフォルトで無効になっています。 この機能を有効にする場合は、適切なCA証明書をアップロードすることで、ロードバランサーとバックエンドサーバーの間に有効な信頼関係が確立されていることを確認する必要があります。
- プールレベルの設定
- バックエンドサーバーの検証とクライアント認証は、いずれもプールレベルで設定されます。 プール内のすべてのバックエンドサーバーは、同じ設定を使用します。 バックエンドサーバーごとに異なる証明書ポリシーが必要な場合は、個別のプールを作成してください。
- 証明書の更新
- 証明書の更新や失効が反映されるには、ロードバランシングサービスの再起動が必要になる場合があります。 サービスの中断を最小限に抑えるため、メンテナンス時間帯に証明書の更新を計画してください。
- 複数のCA
- 同じプール内のバックエンドサーバーが、それぞれ異なるCAによって署名されている場合、関連するすべてのルート証明書および中間証明書を含むCAファイルのバンドルを提供することができます。 すべてのバックエンドサーバーは、その証明書チェーンがバンドル内の任意のCAに連なっている場合、信頼されます。