復号ルール ベスト プラクティス
この章では、復号ルール を持つ 復号ポリシー の例を示し、シスコのベストプラクティスと推奨事項について説明します。まず、復号ポリシー とアクセス コントロール ポリシーの設定について説明し、次にすべてのルール、および特定の方法でルールを順序付けすることを推奨する理由について説明します。
一般的なガイドライン
-
トラフィックの復号には、処理とメモリが必要です。トラフィックを過剰に復号すると、パフォーマンスに影響を与える可能性があります。復号ポリシーとルールを設定する前に、トラフィックを復号する場合としない場合。
-
復号から除外する必要があるトラフィックの中には、性質上復号不可能なトラフィックがあります。通常、復号不可能なトラフィックは TLS/SSL 証明書ピンニングを使用しています。。
以下は、この章で説明する 復号ルールです。

プレフィルタとフローオフロードによる検査のバイパス
プレフィルタはアクセス制御の最初のフェーズで、システムがより大きいリソース消費の評価を実行する前に行われます。プレフィルタリングはシンプルかつ高速で、初期に実行されます。プレフィルタリングでは、限定された外部ヘッダーを基準にしてトラフィックを迅速に処理します。内部ヘッダーを使用し、より堅牢なインスペクション機能を備えた後続の評価とこのプレフィルタリングを比較します。
次の目的でプレフィルタリングを設定します。
-
パフォーマンスの向上:インスペクションを必要としないトラフィックの除外は、早ければ早いほど適切です。特定のタイプのプレーン テキストをファストパスまたはブロックし、カプセル化された接続を検査することなく外側のカプセル化ヘッダーに基づいてトンネルをパススルーします。早期処理のメリットがあるその他の接続についても、ファストパスやブロックをすることができます。
-
カプセル化トラフィックに合わせたディープインスペクションの調整:同じ検査基準を使用してカプセル化接続を後で処理できるように、特定のタイプのトンネルを再区分できます。アクセス制御はプレフィルタ後に内側のヘッダーを使用するため、再区分は必須です。
Firepower 4100/9300 または Cisco Secure Firewall 3100/4200 が使用可能な場合は、大規模なフローオフロードを使用できます。フローオフロードは、信頼できるトラフィックに検査エンジンをバイパスさせてパフォーマンスを向上させる手法です。たとえば、データセンターでサーバーのバックアップを転送するために使用できます。
[復号しない(Do Not Decrypt)] のベストプラクティス
評価期間中のトラフィックのロギング
通常、[復号しない(Do Not Decrypt)] ルールではロギングを無効化にする必要がありますが、ルールに一致するトラフィックが不明な場合は、ロギングを一時的に有効にすることができます。正しいトラフィックが一致していることを確認したら、それらのルールのロギングを無効にします。
復号できないトラフィックのガイドライン
Web サイト自体が復号できない、または Web サイトで TLS/SSL ピン留めが使用されている場合、特定のトラフィックを復号できないと判断できます。SSL ピン留めでは、ブラウザにエラーが表示されることなく、復号されたサイトへのユーザーアクセスが効果的に阻止されます。
証明書のピン留めの詳細については、TLS/SSL のピニングについてを参照してください。
そのようなサイトのリストは次のように管理されています。
-
Cisco-Undecryptable-Sites という名前の識別名(DN)グループ
-
ピン留めされた証明書または復号不可のアプリケーションフィルタ
トラフィックを復号しており、ユーザーが復号されたサイトにアクセスしたときにブラウザにエラーが表示されないようにする場合は、復号ルール の下部に [復号しない(Do Not Decrypt)] ルールを設定することを推奨します。
ピン留めされた証明書のアプリケーションフィルタの設定例を次に示します。
[復号-再署名(Decrypt - Resign)] と [復号-既知のキー(Decrypt - Known Key)] のベストプラクティス
このトピックでは、[復号-再署名(Decrypt - Resign)] と [復号-既知のキー(Decrypt - Known Key)] のベストプラクティスについて説明します。復号ルール
バージョンまたは暗号スイートのルール条件を使用しない
![]() 重要 |
[復号 - 再署名(Decrypt - Resign)] または [復号 - 既知のキー(Decrypt - Known Key)] ルールアクションを含むルールでは、[暗号スイート(Cipher Suite)] または [バージョン(Version)] ルール条件を使用しないでください 。これらの条件をルールで他のルールアクションとともに使用すると、システムの ClientHello 処理に干渉し、予測できないパフォーマンスが生じる可能性があります。 |
[復号 - 再署名(Decrypt - Resign)] の証明書のピン留めによるベストプラクティス
一部のアプリケーションでは、アプリケーション自体に元のサーバー証明書のフィンガープリントを埋め込む、ピニングまたは証明書ピニングと呼ばれる技術が使用されます。TLS/SSL そのため、[復号 - 再署名(Decrypt - Resign)] アクションで 復号ルール を設定した場合は、アプリケーションが管理対象デバイスから再署名された証明書を受信すると、検証が失敗し、接続が中断されます。
TLS/SSL のピン留めは中間者攻撃を避けるために使用されるため、防止または回避する方法はありません。ピニングトラフィックが復号対象から除外されるように、[復号 - 再署名(Decrypt - Resign)] ルールの前に [復号しない(Do Not Decrypt)] ルールを追加することを推奨します。
証明書のピン留めの詳細については、『Cisco Secure Firewall Management Center デバイス設定ガイド』の TLS/SSL のピニングについて
[復号 - 既知のキー(Decrypt - Known Key)] のベストプラクティス
[復号 - 既知のキー(Decrypt - Known Key)] ルールアクションは、内部サーバーに向かうトラフィックに使用するアクションであるため、常に 復号 ルール([ネットワーク(Networks)] ルール条件)に宛先ネットワークを追加するか、アクセスコントロールルール([ゾーン(Zones)] タブページ)にセキュリティゾーンを追加する必要があります。その結果、サーバーが配置されているネットワークまたはインターフェイスにトラフィックが直接送信され、ネットワーク上のトラフィックが減少します。
最初に配置する 復号ルール
パケットの最初の部分に一致するルールを最初に配置します。例として、IP アドレスを参照するルール([ネットワーク(Networks)] ルール条件)があります。
最後に配置する 復号ルール
次のルール条件を持つルールは最後に配置する必要があります。そのようなルールの場合、システムでトラフィックを長時間検査する必要があるためです。
-
アプリケーション
-
カテゴリ
-
証明書
-
識別名(DN)
-
証明書ステータス
-
暗号スイート
-
バージョン