証明書の管理 - Server Load Balancer - Alibaba Cloud ドキュメントセンター

TCPSSL リスナーを使用して暗号化されたデータ転送を行うには、Network Load Balancer (NLB) インスタンスに証明書を構成する必要があります。構成の前に、証明書を購入するか、既存の証明書を Alibaba Cloud Certificate Management Service にアップロードして、証明書を一元管理します。

仕組み

証明書の種類

CA 証明書: 認証局 (CA) は、デジタル証明書を発行する信頼できる第三者機関です。CA 証明書は、他の証明書の信頼性を検証し、信頼できるソースによって発行されたことを保証するために使用されます。
サーバー証明書: SSL 証明書とも呼ばれ、CA によって発行され、サーバーの公開鍵とドメイン名などの ID 情報が含まれています。クライアントに対してサーバーの ID を証明するために使用されます。
クライアント証明書: CA によって発行され、この証明書にはクライアントの公開鍵と ID 情報が含まれています。サーバーに対してクライアントの ID を証明するために使用されます。

ルート CA、中間 CA、証明書チェーンとは何ですか？

ルート CA は、証明書階層における最上位の権限であり、その証明書は信頼チェーン全体の開始点となります。ルート CA 証明書は通常自己署名されており、オペレーティングシステム、ブラウザ、その他のアプリケーションによってプリインストールされ、暗黙的に信頼されています。これらは、中間 CA 証明書やエンドエンティティ証明書など、他の証明書の信頼性を検証するために使用されます。

中間 CA は、ルート CA とエンドエンティティ証明書の間のリンクとして機能します。中間 CA の証明書はルート CA によって発行され、サーバー証明書やクライアント証明書などのエンドエンティティ証明書を発行するために使用されます。中間 CA を使用すると、ルート CA の秘密鍵をオフラインで安全に保護できるため、セキュリティが強化され、信頼の連鎖も拡張されます。

クライアントまたはサーバーが証明書を検証するとき、信頼の証明書チェーンをたどります。このプロセスは、エンドエンティティ証明書 (サーバー証明書など) から始まり、中間 CA を経て、信頼できるルート CA 証明書に到達するまで続きます。

サーバー証明書 → 中間 CA 証明書 → ルート CA 証明書 のような典型的なチェーンの場合、クライアントは次のチェックを実行します:

サーバー証明書は中間 CA によって発行されましたか？
中間 CA 証明書はルート CA によって発行されましたか？
ルート CA 証明書はクライアントの信頼された証明書ストアに存在しますか？

すべてのチェックに合格した場合にのみ、サーバーは信頼できると見なされます。サーバーが完全な証明書チェーン (たとえば、中間 CA 証明書が欠落している場合) を提供できない場合、クライアントはサーバー証明書を信頼できないものとして報告します。

認証モード

NLB は、一方向認証と相互認証の両方をサポートしています。

一方向認証: クライアントはサーバーの ID を検証します。このモードでは、NLB リスナーにはサーバー証明書のみが必要です。これは最も一般的な認証モードであり、ほとんどの Web アプリケーションおよび API サービスに適しています。
相互認証 (mTLS): サーバーとクライアントが相互に相手の ID を検証します。これには、NLB リスナーにサーバー証明書と、クライアント証明書を検証するための CA 証明書の両方を構成する必要があります。このモードは、金融、IoT、またはイントラネット環境など、高いセキュリティが求められるシナリオに最適です。

一方向認証ハンドシェイク	相互認証ハンドシェイク

前提条件

一方向認証または相互認証のどちらが必要かに基づいて、必要な証明書を準備していることを確認してください。Alibaba Cloud からの証明書の購入に関する情報については、次のドキュメントをご参照ください:

一方向認証用の証明書の構成

コンソール

TCPSSL リスナーを構成する際、[SSL 証明書の構成] ステップで、サーバー証明書を選択し、TLS セキュリティポリシーを構成します。

詳細なチュートリアルについては、「NLB を使用して TCP 経由の SSL オフロードを有効にする (一方向認証)」をご参照ください。

API

CreateListener オペレーションを次のパラメーターで呼び出します:

ListenerProtocol を TCPSSL に設定して TCPSSL リスナーを作成します。
CertificateIds を使用してサーバー証明書を指定します。
SecurityPolicyId を使用して TLS セキュリティポリシーを指定します。

相互認証用の証明書の構成

コンソール

TCPSSL リスナーを構成する際、[SSL 証明書の構成] ステップで、サーバー証明書を選択し、相互認証を有効にしてから、CA 証明書を指定します。また、TLS セキュリティポリシーも構成します。

詳細なチュートリアルについては、「NLB を使用して TCP 経由の SSL オフロードを有効にする (相互認証)」をご参照ください。

API

CreateListener オペレーションを次のパラメーターで呼び出します:

ListenerProtocol を TCPSSL に設定します。
CertificateIds を使用してサーバー証明書を指定します。
CaEnabled を true に設定して相互認証を有効にします。
CaCertificateIds を使用して CA 証明書を指定します。
SecurityPolicyId を使用して TLS セキュリティポリシーを指定します。

一方向認証と相互認証の切り替え

既存の TCPSSL リスナーに対しては、いつでも相互認証を有効または無効にして認証モードを切り替えることができます。

コンソール

NLB コンソールで、ターゲット NLB インスタンスを見つけ、インスタンス ID をクリックします。
[リスナー] タブで、ターゲット TCPSSL リスナーを見つけ、[アクション] 列で [証明書の管理] をクリックします。
[CA 証明書] タブで、[相互認証] トグルをクリックしてこの機能を有効または無効にします。有効にする場合は、CA 証明書を選択して [OK] をクリックします。

API

UpdateListenerAttribute オペレーションを呼び出します。ListenerId パラメーターを使用してリスナーを指定します。CaEnabled パラメーターを設定して相互認証を有効または無効にし、CaCertificateIds パラメーターを使用して CA 証明書を指定します。

サーバー証明書の管理

デフォルトのサーバー証明書の置き換え

TCPSSL リスナーの作成時に選択したサーバー証明書が、そのデフォルト証明書になります。この証明書が有効期限切れに近づいた場合や、ビジネスニーズが変更された場合に置き換えてください。

デフォルトのサーバー証明書の置き換え中、新しい接続が中断される可能性があります。既存の接続は影響を受けません。この操作はオフピーク時間帯に実行してください。

コンソール

NLB コンソールで、ターゲット NLB インスタンスを見つけ、インスタンス ID をクリックします。
[リスナー] タブで、ターゲット TCPSSL リスナーを見つけ、[アクション] 列で [証明書の管理] をクリックします。
[サーバー証明書] タブで、[デフォルトのサーバー証明書] の [アクション] 列にある [変更] をクリックし、新しい証明書を選択します。
[OK] をクリックします。

API

UpdateListenerAttribute オペレーションを呼び出します。ListenerId パラメーターを使用してリスナーを指定し、CertificateIds パラメーターを使用して新しい証明書を指定します。

複数ドメインサポートのための追加証明書の追加

単一のリスナーが複数のドメインのトラフィックを処理する必要があり、各ドメインで異なる証明書が必要な場合は、NLB リスナーに追加の証明書を追加します。

追加の証明書を追加すると、NLB はクライアントからリクエストされたドメイン名に基づいて、適切な証明書を自動的に照合して提供します。

クライアントリクエストが追加証明書のドメインと一致する場合、その証明書が使用されます。
一致するものが見つからない場合は、デフォルトのサーバー証明書が使用されます。

1. 各 NLB インスタンスは、最大 25 個の追加証明書をサポートします。

2. 一度に最大 15 個の追加証明書を追加または削除できます。

コンソール

NLB コンソールで、ターゲット NLB インスタンスを見つけ、インスタンス ID をクリックします。
[リスナー] タブで、ターゲット TCPSSL リスナーを見つけ、[アクション] 列で [証明書の管理] をクリックします。
[サーバー証明書] タブで、[追加証明書の追加] をクリックし、他のドメインの証明書を選択します。
[OK] をクリックします。

追加の証明書を削除するには、その証明書の [アクション] 列にある [削除] をクリックします。

API

証明書を追加するには、AssociateAdditionalCertificatesWithListener オペレーションを呼び出します。ListenerId パラメーターを使用してリスナーを指定し、AdditionalCertificateIds パラメーターを使用して追加する証明書を指定します。
証明書を削除するには、DisassociateAdditionalCertificatesWithListener オペレーションを呼び出します。ListenerId パラメーターを使用してリスナーを指定し、AdditionalCertificateIds パラメーターを使用して削除する証明書を指定します。

CA 証明書の管理

CA 証明書の置き換え

コンソール

NLB コンソールで、ターゲット NLB インスタンスを見つけ、インスタンス ID をクリックします。
[リスナー] タブで、ターゲット TCPSSL リスナーを見つけ、[アクション] 列で [証明書の管理] をクリックします。
[CA 証明書] タブで、相互認証が有効になっている場合は、[アクション] 列の [変更] をクリックします。新しい CA 証明書を選択し、[OK] をクリックします。

API

UpdateListenerAttribute オペレーションを呼び出します。ListenerId パラメーターを使用してリスナーを指定し、CaCertificateIds パラメーターを使用して CA 証明書を置き換えます。

課金

TCPSSL リスナーに証明書を構成しても、追加料金は発生しません。ただし、証明書自体には課金されます。詳細については、「SSL 証明書の課金」および「PCA の課金」をご参照ください。

本番環境での適用

考慮事項
- 証明書管理: Certificate Management Service を使用して、すべての証明書を管理します。これにより、一元的な表示、更新、デプロイが可能になります。
- 最新の TLS ポリシー: 特別な互換性要件のない公開アプリケーションには、tls_cipher_policy_1_2 またはそれ以上のバージョンを使用してください。
- 自動化: API または Terraform を Certificate Management Service と組み合わせて使用し、証明書の更新とデプロイを自動化して、証明書の有効期限切れによるサービスの中断を防ぎます。
リスク防止とフォールトトレランス
- 内部トラフィックの保護: TCPSSL はクライアントと NLB 間のトラフィックを暗号化しますが、NLB とバックエンドサーバー間のトラフィックはデフォルトで暗号化されません。エンドツーエンドのセキュリティを確保するには、NLB とバックエンドサーバーを同じ Virtual Private Cloud (VPC) にデプロイし、セキュリティグループを使用して厳格なアクセスの制御を実施します。
- プロアクティブな有効期限の監視: CloudMonitor でアラートルールを構成して、証明書の有効期限が切れることを通知されるようにします。交換に十分な時間を確保するために、有効期限の 30 日前、7 日前、1 日前にアラートを設定することをお勧めします。
- 変更管理とロールバック: 証明書を置き換えたり、TLS ポリシーを変更した後に問題が発生した場合は、リスナーの構成を更新して直ちに変更をロールバックします。これらの変更はオフピーク時間帯に実行してください。