アクセス制御のベストプラクティス

アクセス制御の一般的なベストプラクティス

次の要件と一般的なベストプラクティスを確認してください。

  • 展開のライセンスを取得せずにシステムを設定することはできますが、多くの機能では、展開する前に適切なライセンスを有効にする必要があります。

  • システムがトラフィックに影響を与えるためには、ルーテッド、スイッチド、トランスペアレント インターフェイスまたはインライン インターフェイスのペアを使用して関連する設定を管理対象デバイスに展開する必要があります。

    場合によっては、タップ モードのインライン デバイスを含むパッシブに展開されたデバイスにインライン設定を展開することがシステムによって阻害されます。

    それ以外の場合、ポリシーは正常に展開されますが、パッシブに展開されたデバイスを使用してトラフィックのブロックや変更を試みると、予期しない結果になる可能性があります。ブロックされた接続はパッシブ展開で実際にはブロックされないため、システムにより、ブロックされた各接続に対し複数の接続開始イベントが報告される場合があります。

  • URL フィルタリング、アプリケーション検出、レート制限、インテリジェント アプリケーション バイパスなどの特定の機能では、システムがトラフィックを識別するために、一部のパケットの通過を許可する必要があります。

    これらのパケットが検査されずに接続先に到達しないようにするには、トラフィック識別の前に通過するパケットを処理するためのベストプラクティスおよびトラフィック識別の前に通過するパケットを処理するためのポリシーの指定を参照してください。

  • アクセス コントロール ポリシーのデフォルトアクションで処理されるトラフィックでは、ファイルまたはマルウェアのインスペクションを実行できません。

  • 一部の機能は、特定のデバイスモデルでのみ使用できます。サポートされていない機能は、警告アイコンおよび確認ダイアログ ボックスに示されます。

  • syslog またはストアイベントを外部で使用する場合は、ポリシー名やルール名などのオブジェクト名に特殊文字を使用しないでください。オブジェクト名には、カンマなどの特殊文字を含めることはできません。受信側アプリケーションで区切り文字として使用される可能性があります。

  • デフォルト アクションで処理される接続のロギングは、初期設定では無効ですが、有効にすることもできます。

  • アクセスコントロールルールを作成、順序付け、および実装するためのベストプラクティスについては、アクセス制御ルールのベストプラクティス およびサブトピックを参照してください。

アクセス制御ルールのベストプラクティス

ルールを適切に設定して順序付けることは、効果的な導入を確立する上で不可欠な要素です。次のトピックでは、ルールのパフォーマンスに関するガイドラインを要約します。


（注）  

設定の変更を展開すると、システムはすべてのルールをまとめて評価し、ターゲット デバイスでネットワークトラフィックを評価するために使用する拡張基準セットを作成します。それらの基準がターゲット デバイスのリソース（物理メモリ、プロセッサなど）を上回っている場合、そのデバイスに展開することはできません。

順序付けルールのベストプラクティス

一般的なガイドライン：

  • 通常、すべてのトラフィックに適用する必要がある最優先順位のルールはポリシーの先頭近くに配置します。

  • 固有のルールは一般的なルールの前に来る必要があります（特に特定のルールが一般的なルールの例外である場合）。

    そうしないと、トラフィックはまず一般ルールに一致し、適用する特定のルールにヒットしません。

  • 可能な限り、固有のドロップ ルールはポリシーの最上位近くに配置します。これにより、望ましくないトラフィックへの可能な限り早期の決定が保証されます。

  • レイヤ 3/4 基準（IP アドレス、セキュリティゾーン、ポート番号など）のみに基づいてトラフィックをドロップするルールはできるだけ上に配置する必要があります。

  • URL フィルタリングルール、アプリケーションルール、および検査が必要なその他のルールは、レイヤ 3/4 基準（IP アドレス、セキュリティゾーン、ポート番号など）のみに基づいてトラフィックをドロップするルールの後（ただしファイルポリシーと侵入ポリシーを指定するルールの前）に配置する必要があります。

  • URL フィルタリングルールをアプリケーションルールの上に配置し、アプリケーションルールの後にマイクロ アプリケーション ルールと Common Industrial Protocol（CIP）の下位分類アプリケーション フィルタリング ルールを続けます。

  • ファイルポリシーと侵入ポリシーを指定するルールは、ルールの順序の最後に配置する必要があります。これらのルールに関しては、リソースを大量に消費する詳細な検査が必要です。パフォーマンス上の理由から、詳細な検査が必要とされる潜在的な脅威の数を最小限に抑えるために、最初はそれほどリソースを消費しない方法で可能な限り多くの脅威を排除する必要があります。

  • 常に、ルールを組織のニーズに適した順序に配置する必要があります。

上記のガイドラインの例外と補足事項は、以下のセクションに記載されています。

ルールのプリエンプション

ルールのプリエンプションが発生するのは、評価する順番が前のルールがトラフィックと一致するために、その後のルールが全くトラフィックと一致しない場合です。ルールの条件により、そのルールが他のルールをプリエンプション処理するかどうかが決まります。次の例では、最初のルールが管理トラフィックを許可するため、2 番目のルールがそのトラフィックをブロックできません。

  • アクセス コントロール ルール 1：管理ユーザを許可
  • アクセス コントロール ルール 2：管理ユーザをブロック

どのようなタイプのルール条件でも、後続のルールを回避する可能性があります。次の例では、最初の SSL ルールでの VLAN 範囲に 2 番目のルールでの VLAN が含まれるため、最初のルールが 2 番目のルールをプリエンプション処理します。

  • SSL ルール 1：VLAN 22 ～ 33 を復号しない
  • SSL ルール 2：VLAN 27 をブロック

次の例では、VLAN が設定されていないルール 1 はあらゆる VLAN と一致します。そのため、ルール 1 がルール 2 をプリエンプション処理し、ルール 2 での VLAN 2 の照合は行われません。

  • アクセス コントロール ルール 1：送信元ネットワーク 10.4.0.0/16 を許可
  • アクセス コントロール ルール 2：送信元ネットワーク 10.4.0.0/16、VLAN 2 を許可

あるルールとその後続のルールがまったく同じで、いずれもすべて同じ条件が設定されている場合、後続のルールがプリエンプション処理されます。

  • QoS ルール 1: VLAN 1 URL www.netflix.com をレート制限
  • QoS ルール 2: VLAN 1 URL www.netflix.com をレート制限

条件が 1 つでも異なる場合は、後続のルールがプリエンプション処理されることはありません。

  • QoS ルール 1: VLAN 1 URL www.netflix.com をレート制限
  • QoS ルール 2: VLAN 2 URL www.netflix.com をレート制限
例：プリエンプションを避けるための SSL ルールの順序付け

ここで 1 つのシナリオとして、信頼できる CA（Good CA）が悪意のあるエンティティ（Bad CA）に間違って CA 証明書を発行してしまい、その証明書を取り消していない状況を考えてみましょう。信頼できない CA によって発行された証明書で暗号化されたトラフィックは SSL ポリシーを使用してブロックしたいものの、信頼できる CA の信頼チェーン内にあるそれ以外のトラフィックは許可したいとします。CA 証明書とすべての中間 CA 証明書をアップロードした後、ルールを以下の順序で設定した SSL ポリシーを構成します。

  • SSL ルール 1：発行元 CN=www.badca.com をブロック
  • SSL ルール 2：発行元 CN=www.goodca.com を復号しない

上記のルールを逆の順序にすると、不正な CA で信頼されたトラフィックを含め、正当な CA で信頼されたすべてのトラフィックが最初に一致することになります。どのトラフィックも後続の不正な CA ルールに一致しないため、悪意のあるトラフィックはブロックされずに許可される可能性があります。

ルールのアクションとルールの順序

ルールのアクションによって、一致したトラフィックの処理方法が決まります。パフォーマンスを向上させるには、リソースを集約的に使用するルールを実行する前に、トラフィックの追加処理を実行または保証しないルールを配置してください。これにより、システムはさらに検査する必要のあるトラフィックだけを転送できます。

以下の例は、一連のルールがすべて同等に重要であり、プリエンプションが問題にならない場合に、さまざまなポリシーでルールを順序付ける方法を示しています。

ルールにアプリケーション条件が含まれている場合は、アプリケーション制御の設定のベストプラクティスも参照してください。

最適な順序：SSL ルール

復号にはリソースが必要になるだけでなく、復号後のトラフィックの分析も必要になります。したがって、トラフィックを復号する SSL ルールを最後に配置します。


（注）  

特定の管理対象デバイスはハードウェアの TLS/SSL トラフィックの暗号化と復号化をサポートしているため、パフォーマンスが大幅に向上します。詳細については、TLS 暗号化アクセラレーションを参照してください。

  1. [モニター（Monitor）]：一致する接続をログに記録するだけで、トラフィックに対して他のアクションは実行しないルール。

  2. [ブロック（Block）]、[リセットしてブロック（Block with reset）]：それ以上のインスペクションを行わずにトラフィックをブロックするルール。

  3. [復号しない（Do not decrypt）]：暗号化トラフィックを復号しないまま、暗号化セッションをアクセス コントロール ルールに渡すルール。これらのセッションのペイロードにディープ インスペクションは適用されません。

  4. [復号 - 既知のキー（Decrypt - Known Key）]：既知の秘密キーを使用して着信トラフィックを復号するルール。

  5. [復号 - 再署名（Decrypt - Resign）]：サーバ証明書に再署名することによって発信トラフィックを復号するルール。

最適な順序：アクセス コントロール ルール

複数のカスタム侵入ポリシーと変数セットを使用している場合は特に、侵入、ファイル、マルウェアのインスペクションにリソースが必要です。したがって、ディープ インスペクションを呼び出すアクセス コントロール ルールを最後に配置します。

  1. [モニター（Monitor）]：一致する接続をログに記録するだけで、トラフィックに対して他のアクションは実行しないルール。ただし、重要な例外と注意事項をアクセス コントロール ルールのモニター アクションで確認してください。

  2. [信頼（Trust）]、[ブロック（Block）]、[リセットしてブロック（Block with reset）]：それ以上のインスペクションを行わずにトラフィックを処理するルール。信頼できるトラフィックは、アイデンティティ ポリシーが課す認証要件、およびレート制限の対象となることに注意してください。

  3. [許可（Allow）]、[インタラクティブ ブロック（ディープ インスペクションなし）（Interactive Block (no deep inspection)）]：それ以上のインスペクションを行わずにトラフィックのディスカバリを許可するルール。許可されるトラフィックは、アイデンティティ ポリシーが課す認証要件、およびレート制限の対象となることに注意してください。

  4. [許可（Allow）]、[インタラクティブ ブロック（ディープ インスペクションあり）（Interactive Block (deep inspection)）]：禁止されているファイル、マルウェア、エクスプロイトのディープ インスペクションを実行するファイル ポリシーまたは侵入ポリシーに関連付けられているルール。

コンテンツ規制ルールの順序

SSL とアクセス コントロール ポリシーの両方でルールのプリエンプションを避けるため、YouTube 規制を制御するルールは、セーフサーチ規制を制御するルールの上に配置します。

アクセス コントロール ルールに対してセーフサーチを有効にする場合、システムは検索エンジンのカテゴリを [選択したアプリケーションとフィルタ（Selected Applications and Filters）] リストに追加します。このアプリケーション カテゴリには YouTube が含まれます。結果として、YouTube EDU がさらに上位の評価優先順位を持つルールで有効にされていない限り、YouTube トラフィックはセーフサーチ ルールに一致します。

同様のルールのプリエンプションは、セーフサーチ サポート フィルタを持つ SSL ルールを、評価順序内で特定の YouTube アプリケーション条件を持つ SSL ルールよりも高い順序に配置した場合に生じます。

アプリケーション ルールの順序

アプリケーション条件を使用するルールは、ルールのリストでより低い順序に移動すると、トラフィックに一致する可能性が高くなります。

特定の条件 (ネットワークや IP アドレスなど) を使用するアクセス コントロール ルールは、一般的な条件 (アプリケーションなど) を使用するルールの前にオーダーする必要があります。オープン システム相互接続（OSI）モデルに精通している場合は、考え方として同様の順位付けを使用してください。レイヤ1、2、および 3 (物理、データリンク、およびネットワーク) の条件を持つルールは、アクセス コントロール ルールで最初に注文する必要があります。レイヤ5、6、および 7 (セッション、プレゼンテーション、およびアプリケーション) の条件は、アクセス コントロール ルールの後で順序付けする必要があります。OSI モデルの詳細については、こちらの Wikipedia の記事を参照してください。

詳細と例については、アプリケーション制御の設定のベストプラクティスおよびアプリケーション制御のベストプラクティスを参照してください。

SSL ルールの順序

通常、特定の条件（IP アドレスとネットワークなど）を使用するルールは、一般的な条件（アプリケーションなど）を使用するルールの前に順位付けします。

証明書がピニングされたサイトからのトラフィックの許可

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

TLS/SSL ピニングが行われていることを確認するには、Facebook などのモバイル アプリケーションへのログインを試みます。ネットワーク接続エラーが表示された場合は、Web ブラウザを使用してログインします。（たとえば、Facebook のモバイル アプリケーションにログインすることはできませんが、Safari または Chrome を使用して Facebook にログインすることはできます）。Firepower Management Center の接続イベントは、TLS/SSL ピニングのさらなる証明として使用できます


（注）  

TLS/SSL ピニングはモバイル アプリケーションに限定されません。

このトラフィックを許可するには、サーバ証明書の共通名または識別名と一致させるために、[復号しない（Do Not Decrypt）] アクションを使用して SSL ルールを設定します。SSL ポリシーでは、このルールを、トラフィックと一致するすべての [復号 - 再署名（Decrypt - Resign）] ルールの前に配置してください。Web サイトに正常に接続された後で、クライアント ブラウザから、ピニングされた証明書を取得できます。また、接続が成功したか失敗したかに関わらず、ログに記録された接続イベントから証明書を表示できます。

ClientHello の変更の優先順位付け

ClientHello の変更を優先順位付けするには、ServerHello またはサーバ証明書条件に一致するルールの前に、ClientHello メッセージで使用可能な条件に一致するルールを配置します。

管理対象デバイスが SSL ハンドシェイクを処理するときに、ClientHello メッセージを変更して、復号の可能性を高めることができます。たとえば、Firepower システムは圧縮されたセッションを復号できないので、圧縮メソッドを削除できます。

システムは [復号 - 再署名（Decrypt - Resign）] アクションを含む SSL ルールに最終的に一致させることができる場合のみ、ClientHello メッセージを変更します。システムが新しいサーバーへの暗号化セッションを最初に検出したときは、サーバー証明書データを ClientHello の処理には使用できません。これは復号されていない最初のセッションとなる可能性があります。同じクライアントからの後続の接続で、システムはサーバー証明書条件を含むルールに ClientHello メッセージを最終的に一致させ、メッセージを処理して、復号の可能性を最大化できます。

ServerHello またはサーバー証明書条件（証明書、識別名、証明書のステータス、暗号スイート、バージョン）と一致するルールを、ClientHello 条件（ゾーン、ネットワーク、VLAN タグ、ポート、ユーザー、アプリケーション、URL カテゴリ）と一致するルールの前に配置する場合、ClientHello の変更をプリエンプション処理し、復号されないセッションの数を増やすことができます。

SSL ポリシーがバイパスされる状況

SSL ポリシーは、[信頼（Trust）]、[ブロック（Block）]、または [リセットしてブロック（Block With Reset）] のアクションを持つアクセス コントロール ルールが次に当てはまる場合、それらのルールに一致する接続に関してバイパスされます。

  • セキュリティ ゾーン、ネットワーク、地理位置情報、およびポートだけをトラフィック照合基準として使用する。

  • 検査を必要とする他のルール（アプリケーションまたは URL に基づいて接続を照合するルールなど）に先立つか、侵入またはファイル検査を適用するルールを許可する。

URL ルールの順序

URL マッチングを最も効果的に行うには、URL 条件を含むルールを他のルールより前に配置します。特に、URL ルールがブロック ルールで、他のルールが次の条件を両方とも満たす場合には、URL 条件を含むルールを前に配置します。

  • その他のルールがアプリケーション条件を含んでいる。

  • 検査対象のトラフィックが暗号化されている。

ルールに例外を設定する場合は、例外を他のルールの上に配置してください。

ルールの簡素化および絞り込みのベストプラクティス

簡素化：設定しすぎない

処理するトラフィックの照合が 1 つの条件で十分な場合には、2 つの条件を使用しないでください。

個々のルール条件を最小化します。できる限り少ない個々の要素をルールの条件に使用します。たとえば、ネットワーク条件では、個々の IP アドレスではなく IP アドレス ブロックを使用します。

要素をオブジェクトに組み合わせても、パフォーマンスは向上しません。たとえば、50 個の IP アドレスを 1 つのネットワーク オブジェクトに含めて使用することにパフォーマンス的なメリットはなく、条件にこれらの IP アドレスを個別に含めるよりも単に構成上のメリットがあるだけです。

アプリケーション検出の推奨事項については、アプリケーション制御の設定のベストプラクティスを参照してください。

絞り込み：特にインターフェイスによってリソース消費ルールを絞り込んで制約する

できる限り、ルールの条件を使用してリソース消費ルールが処理するトラフィックを絞り込んで定義します。絞り込まれたルールは、広範な条件を持つルールが多様なタイプのトラフィックを照合し、後でより多くの特定のルールをプリエンプション処理できるという理由からも重要です。以下は、リソース消費ルールの例です。

  • トラフィックを復号する SSL ルール：復号だけでなく、復号されたトラフィックの更なる分析にもリソースが必要です。絞り込みを細かくし、また可能な場合は、暗号化トラフィックをブロックするか、復号しないようにします。

    Certain Firepower Management Center モデルはハードウェアで SSL 暗号化と復号化を実行します。これによりパフォーマンスが大きく向上します。詳細については、TLS 暗号化アクセラレーションを参照してください。

  • ディープ インスペクションを呼び出すアクセス コントロール ルール：特に複数のカスタム侵入ポリシーと変数セットを使用している場合、侵入ファイルやマルウェアのインスペクションにはリソースが必要です。ディープ インスペクションは必要な場所でのみ呼び出されることを確認してください。

最大のパフォーマンスによるメリットを得るため、インターフェイスによってルールを制約します。ルールがデバイスのすべてのインターフェイスを除外する場合、そのルールはそのデバイスのパフォーマンスに影響しません。

アクセス制御ルールと侵入ポリシーの最大数

ターゲットデバイスでサポートされるアクセス制御ルールまたは侵入ポリシーの最大数は、ポリシーの複雑性、物理メモリ、デバイスのプロセッサ数などの、多くの要因によって異なります。

デバイスでサポートされる最大を超えるとアクセス コントロール ポリシーは展開できず、再評価する必要があります。

侵入ポリシーのガイドライン：

アクセス コントロール ポリシーでは、1 つの侵入ポリシーを各許可ルール、インタラクティブ ブロック ルール、およびデフォルト アクションと関連付けることができます。侵入ポリシーと変数セットの固有のペアはすべて、1 つのポリシーと見なされます。

いくつかの侵入ポリシーまたは変数セットを統合すると、複数のアクセス コントロール ルールに 1 つの侵入ポリシーと変数セットのペアを関連付けることができます。一部のデバイスでは、すべての侵入ポリシーに関して 1 つの変数セットだけを使用できる場合や、デバイス全体でただ 1 つの侵入ポリシー/変数セット ペアだけを使用できる場合があります。