HTTPS トラフィックに隠された脅威は、ペイロードが暗号化されているため検出を回避します。TLS インスペクション機能は Cloud Firewall で提供され、元の TLS 証明書をプライベートルート CA に置き換えることでアウトバウンドトラフィックを復号し、IPS エンジンがプレーンテキストを検査できるようにした後、安全に再暗号化して転送します。
TLS インスペクションはパブリックプレビュー段階であり、正式リリース前に変更される可能性があります。ご質問やフィードバックがある場合は、アカウントマネージャーまでお問い合わせください。
TLS インスペクションが必要な理由
HTTPS はリクエストペイロードを暗号文に暗号化するため、IPS エンジンがコンテンツを解析できない「ブラインドスポット」が生じます。TLS インスペクションはクライアントとファイアウォール間で元の TLS 証明書をプライベート証明書に置き換え、トラフィックを復号してディープパケットインスペクションを実行し、高度な攻撃やデータ持ち出しを検出します。
暗号化トラフィックによるセキュリティリスク
リスク 1：高度な攻撃およびデータ侵害が IPS によって検出されない
攻撃者は HTTPS トンネルを利用して悪意のあるペイロードを配信したり、データを持ち出したり、C2 サーバーと通信したりします。暗号化されたトラフィックでは、IPS エンジンが攻撃シグネチャやデータ漏えいを特定できません。TLS インスペクションによりプレーンテキストトラフィックが可視化され、IPS がこれらの脅威を検出してブロックできます。
リスク 2：Web フィルタリングが HTTPS トラフィックに対してパスレベルの制御を適用できない
Web フィルタリングは HTTP リクエスト内のホスト名およびパス（例：example.com/upload/*）と照合します。復号を行わないと、ファイアウォールは SNI からドメイン名しか読み取れず、URL パスを抽出できません。そのため、「閲覧は許可するがアップロードは拒否する」といった詳細なポリシーが機能しません。TLS インスペクションにより、HTTPS トラフィックでも完全なパス照合が可能になります。
リスク 3：暗号化下でのアプリケーション識別精度が低下し、制御粒度が制限される
アプリケーションコントロールはディープパケットインスペクション (DPI) を使用してペイロードデータからアプリケーションを識別します。復号を行わないと、DPI は SNI や証明書などのハンドシェイク情報のみに依存するため、同一ドメイン内での動作（例：「GitHub の閲覧」と「GitHub へのアップロード」）を区別できなくなります。TLS インスペクションによりトラフィック全体が可視化され、正確な動作識別が可能になります。
注意事項
課金方法の制限：この機能は、レガシ従量課金 1.0 課金方法を使用する Cloud Firewall インスタンスではサポートされていません。
リージョンの制限：この機能は以下のリージョンでのみ利用可能です：中国 (北京)、中国 (上海)、中国 (杭州)、中国 (張家口)、中国 (ウランチャブ)、中国 (深セン)、中国 (香港)、インドネシア (ジャカルタ)、イギリス (ロンドン)、ドイツ (フランクフルト)。
TLS プロトコルバージョンの制限：
ECH を使用しない TLS 1.3：ECH (Encrypted Client Hello) 拡張を使用しない TLS 1.3 接続の TLS チェックをサポートしています。
ECH を使用する TLS 1.3：ECH 拡張を使用する TLS 1.3 接続の TLS チェックはサポートしていません。ただし、トラフィックは正常に転送されます。
レガシ SSL プロトコル：SSL 1.0、SSL 2.0、SSL 3.0 などの古いプロトコルバージョンはサポートしていません。クライアントがこれらのプロトコルを使用している場合、トラフィックが中断される可能性があります。
プロトコルタイプの制限：UDP を使用する QUIC トラフィックなど、TCP 以外のリクエストは転送されますが、インスペクションは行われません。
ネットワーク診断への影響：TLS インスペクションを有効化すると、TCP MTR (My Traceroute) でオリジンサーバーまでの経路をトレースできなくなります。
認証モードの制限：この機能は相互 TLS (mTLS) をサポートしていません。クライアントがサーバー証明書を検証する標準的な TLS のみをサポートしています。
SNI 要件：TLS インスペクションを有効にするには、TLS サーバ名表示 (SNI) が構成済み証明書のドメイン名と一致している必要があります。
操作手順
Cloud Firewall コンソールにログインします。 左側のナビゲーションウィンドウで、 を選択して、TLS 検査ページに移動します。
ステップ 1：TLS インスペクションポリシーの構成
TLS 検査ページで、ポリシーリストの上にあるTLS 検査ポリシーを作成をクリックします。右側にTLS 検査ポリシーを作成ドロワーが表示されます。
証明書を関連付ける。
パラメーター
説明
ポリシー名
ポリシーのわかりやすい名前を入力します。
TLS 証明書を関連付ける
既存の証明書を選択します。
説明初めてポリシーを作成する際、証明書ドロップダウンリストにはトライアル証明書のリクエストオプションが含まれます。これをクリックして TLS インスペクションの評価用テスト証明書を生成できます。試用証明書は 1 回のみ使用可能です。本番環境では、ご自身で証明書を購入して使用してください。
現在、PCA 証明書のみサポートされています。証明書は以下の要件を満たす必要があります：
証明書の目的は「社内企業利用」に設定されていること。
中国暗号アルゴリズム証明書はサポートされていません。
RSA 秘密鍵アルゴリズムを使用する場合、キー長は 2048 ビット以上であること。
ECC 秘密鍵アルゴリズムを使用する場合、P-256 を選択すること。
利用可能な証明書がない場合は、証明書の購入をクリックして Certificate Management Service コンソールに移動します。証明書を購入する際、PCA 証明書の目的が「社内企業利用」に設定されていることを確認してください。PCA 証明書とは。
証明書の有効期間
選択後に証明書の有効期間が表示されます。残りの有効期間が 1 年未満になると警告が表示されます。証明書の有効期間が常に 1 年以上あることを確認してください。
説明
ポリシーの説明を入力します。
パラメーターを構成したら、次へをクリックして検査範囲の設定ステップに進みます。次のステップに進むと、ポリシーが作成・保存されます。
検査範囲の設定。
重要すべてのインスペクション範囲の合計クォータは 20,000 です。
単一の TLS インスペクションポリシーが消費するクォータは、そのポリシーに含まれるすべてのインスペクション範囲のクォータの合計です。
単一のインスペクション範囲が消費するクォータは、次の式で計算されます：送信元 IP アドレス数 × 送信元ポート範囲数 × 宛先 IP アドレス数 × 宛先ポート範囲数。
パラメーター
説明
プロトコルタイプ
現在、
TCPプロトコルのみサポートされています。ソース IP
アウトバウンドトラフィックの検査対象となるホストの IP アドレスを選択します。最大 1,000 個のアドレスを指定できます。
説明サポートされるアセットタイプ：
ECS EIP、ECS パブリック IP、NAT EIP、EIP、およびENI EIP。送信元ポート
開始ポート/終了ポート形式でポートを指定します。有効範囲：0-65535。複数の範囲を指定する場合はコンマで区切ります。最大 100 範囲まで指定できます。説明単一ポートの場合も範囲形式を使用します。例：
8080/8080はポート 8080 のみをチェックします。すべてのポートをチェックするには、
0/65535を使用します。
宛先 IP アドレス
送信元ホストがアクセスする宛先 IP アドレスです。
説明IPv4 アドレスまたは CIDR 表記のアドレス範囲を使用する必要があります。例：
192.0.2.0/24,8.8.8.8/32。最大 100 個の IP アドレスオブジェクトを入力できます。複数のオブジェクトを指定する場合はコンマ (,) で区切ります。
すべてのアドレスを表すには、
0.0.0.0/0を使用します。
宛先ポート
宛先サービスポートです。形式：
開始ポート/終了ポート。有効範囲：0-65535。複数の範囲を指定する場合はコンマで区切ります。最大 100 範囲まで指定できます。説明
インスペクション範囲の説明を入力します。
その他の操作
保存： 次へをクリックせずに、検査範囲セクション下部の保存をクリックしてインスペクション範囲を保存できます。範囲が保存されると、セクションの右上隅に保存が完了しましたと表示されます。
追加： 検査範囲を追加をクリックして、別のインスペクション範囲を追加できます。単一のポリシーで最大 10 個のインスペクション範囲をサポートします。
削除: 現在の検査範囲を削除するには、検査範囲 セクションの右上隅にある
アイコンをクリックします。削除を確認すると、次へ をクリックする必要なく、その範囲は即座に削除されます。このオプションは慎重に使用してください。
パラメーターを構成したら、次へをクリックしてポリシー構成を完了します。
ポリシー情報を確認します。
ポリシー構成後、ポリシーとそのインスペクション範囲の詳細が表示されます。ポリシー IDはログに含まれます。
ステップ 2：TLS 証明書のインストール
インスペクション範囲内のすべてのホストに、関連付けられた証明書をインストールします。
検査対象のアセットがNAT EIPの場合、インターネット NAT ゲートウェイ経由でインターネットにアクセスするすべての ECS インスタンスに証明書をインストールする必要があります。インストールしないと、トラフィックが中断される可能性があります。
証明書をダウンロードします。
TLS 検査ポリシーの設定リストで、作成したポリシーを見つけ、右側の操作列にある証明書をダウンロードをクリックします。証明書がローカルマシンにダウンロードされます。パッケージを解凍して証明書ファイル (
.crt) を取得します。送信元 IP ホストにログインします。
送信元 IP アドレスとして指定したホストにログインします。検査範囲を作成した際に指定したホストです。証明書をホスト上の任意のディレクトリにアップロードします。ファイル転送方法。
証明書をインストールします。
証明書を OS の信頼ストアにコピーし、更新コマンドを実行します。手順はオペレーティングシステムによって異なります。
説明TLS ポリシーで中間 CA 証明書を使用する場合、ルート CA と中間 CA の両方をインストールする必要があります。
以下の例は、信頼ストアがシステム信頼ストアであるシナリオに適用されます。アプリケーションが別の信頼ストアを使用している場合は、正しい信頼ストアに証明書をインストールしてください。
CentOS/Alibaba Cloud Linux/Anolis/Red Hat
証明書ファイルをコピー：
cp <certificate_file_name> /etc/pki/ca-trust/source/anchors/証明書を更新：
sudo update-ca-trust更新された証明書を表示：
cat /etc/ssl/certs/ca-bundle.crt出力に証明書の内容が表示されたら、インストールは成功です。
Ubuntu
証明書ファイルをコピー：
cp <certificate_file_name> /usr/local/share/ca-certificates/証明書を更新：
sudo update-ca-certificates更新された証明書を表示：
cat /etc/ssl/certs/ca-certificates.crt出力に証明書の内容が表示されたら、インストールは成功です。
Windows
重要中間 CA (intermediate CA) を参照する証明書を使用する場合、Windows のネイティブ Certificate Manager は証明書チェーンファイル内のすべての CA を一度にインストールしません。ファイル内の最初の CA のみをインストールします。このような場合は、各 CA のコンテンツブロックを個別のファイルに手動で分割してから、それぞれのファイルをインストールする必要があります。
ダウンロードして解凍した証明書ファイルをテキストエディターで開き、
-----BEGIN CERTIFICATE-----から-----END CERTIFICATE-----までのコンテンツブロックを切り取り、.crt拡張子で新しいファイルとして保存することで証明書を分割します。
分割後：
証明書をインストール：証明書ファイルを右クリックして証明書のインストールをクリックし、次の手順に従います：
1
2
3
次へをクリックして証明書のインポートを完了します。
インポートされた証明書を表示：コマンドプロンプトで
certmgr.mscを入力して Certificate Manager を開きます。
SUSE
証明書ファイルをコピー：
cp <certificate_file_name> /etc/pki/trust/anchors証明書を更新：
sudo c_rehash .更新された証明書を表示：
sudo trust list --filter=ca-anchors |grep -C 2 <Certificate CN>証明書情報が表示されたら、証明書は正常にインストールされています。
Fedora および Fedora CoreOS
証明書ファイルをコピー：
sudo cp <certificate-file-name> /etc/pki/ca-trust/source/anchors/証明書を更新：
sudo update-ca-trust extract更新された証明書を表示：
sudo trust list --filter=ca-anchors |grep -C 2 <certificate_CN>証明書情報が表示されたら、証明書は正常にインストールされています。
Container Service (ACK)
ACK クラスター内の Pod からアウトバウンドトラフィックが発生する場合、コンテナ環境がホストから分離されているため、各 Pod 内に PCA 証明書をインストールする必要があります。ノードも HTTPS リクエスト（パブリックリポジトリからのイメージプルなど）を開始する場合は、ノードにも証明書をインストールしてください。
説明以下の手順は Alibaba Cloud Linux 3.2104 LTS 64 ビット (コンテナ最適化) 向けのものであり、参考情報です。オペレーティングシステムおよびビジネス要件に応じてコマンドを調整してください。
以下のコマンドの一部はリソースを再起動します。業務中断を避けるため、オフピーク時間帯にこれらの操作を実行することを推奨します。
ノードへの証明書インストール
各ノードにログインして、以下のコマンドを実行します。
証明書ファイルをコピー：
cp <certificate_file_name> /etc/pki/ca-trust/source/anchors/証明書を更新：
sudo update-ca-trust更新された証明書を表示：
cat /etc/ssl/certs/ca-bundle.crt証明書の内容が表示されたら、証明書はインストールされています。
変更を反映させるためにコンテナサービスを再起動：
sudo systemctl restart containerd。
Pod 内への証明書インストール
対象クラスターのコンソールで Secret を作成します。以下は設定例です。キー値は証明書ファイルの内容です。Secret の作成方法の詳細については、「シークレットの管理」をご参照ください。
または、以下の kubectl コマンドを実行して Secret を作成することもできます（効果は同じです）。コマンド内の ca_chain.crtは実際の証明書ファイル名に置き換えてください。kubectl create secret generic cfw-pca-cert \ --from-file=ca_chain.crt=./ca_chain.crt \ -n defaultDeployment の例として、その YAML ファイルに以下の内容を追加します：
spec.template.spec.containersフィールドに移動し、証明書をマウントしてトラストストアを更新するための以下の内容を追加します。ここでのsecretNameは、前のステップで作成した Secret の名前（例：cfw-pca-cert）です。volumes: - name: custom-ca-volume secret: secretName: cfw-pca-cert volumeMounts: - name: custom-ca-volume mountPath: /etc/ssl/custom readOnly: truespec.template.spec.containersフィールドの下に起動コマンドをさらに追加します。説明以下の例は CentOS コンテナシステムに基づいており、参考情報です。オペレーティングシステムおよびビジネス要件に応じてコマンドを調整してください。
command: - "/bin/sh" - "-c" - | # 1. curl をインストールします。 echo "Installing curl......" yum install -y curl # 2. 証明書がマウントされていることを確認します。ca_chain.crt を実際の証明書ファイル名に置き換えてください。 if [ ! -f /etc/ssl/custom/ca_chain.crt ]; then echo "ERROR: Certificate file not found!" exit 1 fi # 3. CentOS の手順に基づいて証明書を注入します。 echo "Copying certificate to anchors directory..." cp /etc/ssl/custom/ca_chain.crt /etc/pki/ca-trust/source/anchors/ echo "Updating CA trust store..." update-ca-trust # 4. Pod を実行したままにします。 echo "Pod ready for manual testing. Use 'kubectl exec' to test further." sleep infinity
ブラウザの信頼ストア
Firefox などのブラウザは、システム CA 信頼ストアではなく独自の証明書信頼データベースを維持しています。update-ca-certificates を実行しても、ブラウザは引き続き証明書を信頼されていないと表示する可能性があります。証明書をブラウザの信頼データベースに直接インポートしてください。
これらのブラウザへの証明書インポート手順は、Linux および Windows で同じです。
1 | 2 |
|
|
ステップ 3：インスペクションの有効化とトラフィックログのクエリ
すべてのホストに証明書をインストールしたら、ポリシーを有効化します。
重要TLS インスペクションを有効化すると、新しい接続に対する保護が約 1 分で有効になります。既存の接続保持中の接続には影響せず、保護されません。
すでに保護されており TLS インスペクションが有効になっている EIP について、TLS インスペクションを無効化すると接続保持中の接続が中断されます。中断の持続時間は、アプリケーションの再接続時間に依存します。
TLS 検査ページにはすべてのポリシーがリスト表示されます。ステータススイッチを切り替えてポリシーを有効化します。有効化後、Cloud Firewall は構成に従って暗号化されたアウトバウンドトラフィックを検査します。
説明ポリシーは無効化されている場合にのみ削除できます。
トラフィックログをクエリします。
検査対象ホストがトラフィックを生成した後、Cloud Firewall コンソールの左側ナビゲーションウィンドウで、 を選択します。
で、ホストが生成したトラフィック（一致した TLS インスペクションポリシーおよびインスペクション範囲を含む）をクエリします。
ログにはポリシーおよびインスペクション範囲の ID が表示されます。
