TLS/SSL ルール ベスト プラクティス

TLS/SSL ルール ベスト プラクティス

この章では、TLS/SSL ルール を持つ SSL ポリシーの例を示し、シスコのベストプラクティスと推奨事項について説明します。まず、SSL ポリシーとアクセス コントロール ポリシーの設定について説明し、次にすべてのルール、および特定の方法でルールを順序付けすることを推奨する理由について説明します。

以下は、この章で説明する SSL ポリシーです。

サンプルの SSL ポリシーには、最もシンプルなルールから最も複雑なルールへと順序付けられた複数のルールがあります。そのため、最もシンプルなルールに一致するトラフィックは迅速に処理され、より複雑なルールと一致するトラフィックに多くの時間が費やされます。

プレフィルタとフローオフロードによる検査のバイパス

プレフィルタはアクセス制御の最初のフェーズで、システムがより大きいリソース消費の評価を実行する前に行われます。プレフィルタリングはシンプルかつ高速で、初期に実行されます。プレフィルタリングでは、限定された外部ヘッダーを基準にしてトラフィックを迅速に処理します。内部ヘッダーを使用し、より堅牢なインスペクション機能を備えた後続の評価とこのプレフィルタリングを比較します。

次の目的でプレフィルタリングを設定します。

  • パフォーマンスの向上：インスペクションを必要としないトラフィックの除外は、早ければ早いほど適切です。特定のタイプのプレーン テキストをファストパスまたはブロックし、カプセル化された接続を検査することなく外側のカプセル化ヘッダーに基づいてトンネルをパススルーします。早期処理のメリットがあるその他の接続についても、ファストパスやブロックをすることができます。

  • カプセル化トラフィックに合わせたディープインスペクションの調整：同じ検査基準を使用してカプセル化接続を後で処理できるように、特定のタイプのトンネルを再区分できます。アクセス制御はプレフィルタ後に内側のヘッダーを使用するため、再区分は必須です。

Firepower 4100/9300 が使用可能な場合は、大規模なフローオフロードを使用できます。フローオフロードは、信頼できるトラフィックに検査エンジンをバイパスさせてパフォーマンスを向上させる手法です。たとえば、データセンターでサーバーのバックアップを転送するために使用できます。

[復号しない（Do Not Decrypt）] のベストプラクティス

トラフィックのロギング

何もログに記録しない [復号しない（Do Not Decrypt）] ルールは、管理対象デバイスでの処理に時間がかかるため、作成しないことを推奨します。いずれかの TLS/SSL ルールタイプを設定する場合は、ロギングを有効にして、一致するトラフィックを確認できるようにします。

復号できないトラフィックのガイドライン

Web サイト自体が復号できない、または Web サイトで SSL ピン留めが使用されている場合、特定のトラフィックを復号できないと判断できます。SSL ピン留めでは、ブラウザにエラーが表示されることなく、復号されたサイトへのユーザーアクセスが効果的に阻止されます。

そのようなサイトのリストは次のように管理されています。

  • Cisco-Undecryptable-Sites という名前の識別名（DN）グループ

トラフィックを復号しており、ユーザーが復号されたサイトにアクセスしたときにブラウザにエラーが表示されないようにする場合は、TLS/SSL ルール の下部に [復号しない（Do Not Decrypt）] ルールを設定することを推奨します。

[復号-再署名（Decrypt - Resign）] と [復号-既知のキー（Decrypt - Known Key）] のベストプラクティス

このトピックでは、[復号-再署名（Decrypt - Resign）] と [復号-既知のキー（Decrypt - Known Key）] のベストプラクティスについて説明します。TLS/SSL ルール

[復号-再署名（Decrypt - Resign）]：証明書のピン留めによるベストプラクティス

一部のアプリケーションでは、アプリケーション自体に元のサーバー証明書のフィンガープリントを埋め込む、ピニングまたは証明書ピニングと呼ばれる技術が使用されます。TLS/SSL そのため、[復号 - 再署名（Decrypt - Resign）] アクションで TLS/SSL ルール を設定した場合は、アプリケーションが管理対象デバイスから再署名された証明書を受信すると、検証が失敗し、接続が中断されます。

TLS/SSL のピン留めは中間者攻撃を避けるために使用されるため、防止または回避する方法はありません。次の選択肢があります。

  • そのアプリケーション用に、[復号-再署名（Decrypt - Resign）] ルールよりも順序が前の、[復号しない（Do Not Decrypt）] ルールを作成します。

  • Web ブラウザを使用してアプリケーションにアクセスするようユーザに指示します。

証明書のピン留めの詳細については、Firepower Management Center デバイス構成ガイドの「SSL pinning」セクションを参照してください。

[復号-既知のキー（Decrypt - Known Key）] のベストプラクティス

[復号-既知のキー（Decrypt - Known Key）] ルールアクションは、内部サーバーに向かうトラフィックに使用するアクションなので、ルール（[ネットワーク（Networks）] ルール条件）には宛先ネットワークを常に追加する必要があります。その結果、サーバーが配置されているネットワークにトラフィックが直接送信され、ネットワーク上のトラフィックが減少します。

最初に配置する TLS/SSL ルール

パケットの最初の部分に一致するルールを最初に配置します。例として、IP アドレスを参照するルール（[ネットワーク（Networks）] ルール条件）があります。

最後に配置する TLS/SSL ルール

次のルール条件を持つルールは最後に配置する必要があります。そのようなルールの場合、システムでトラフィックを長時間検査する必要があるためです。

  • アプリケーション

  • カテゴリ

  • 証明書

  • 識別名（DN）

  • 証明書ステータス

  • 暗号スイート

  • バージョン