アダプティブ プロファイルが有効になっていることの確認

アダプティブ プロファイルが無効な場合（デフォルト状態）、アクセス コントロール ルールは、アプリケーション制御を実行できません。

アプリケーション ディテクタの自動有効化

ディテクタが検出対象のアプリケーションに対して有効でない場合、システムは、そのアプリケーションに対応するシステム提供のすべてのディテクタを自動的に有効にします。存在しない場合、システムはそのアプリケーション対応で最近変更されたユーザ定義のディテクタを有効にします。

アプリケーション識別の速度

システムは、次が実行されるまで、インテリジェント アプリケーション バイパス（IAB）とレート制限を含めアプリケーション制御を実行できません。

• モニタ対象の接続がクライアントとサーバの間で確立され、

• システムがセッションでアプリケーションを識別する

この識別は 3 ～ 5 パケット以内で、またはトラフィックが暗号化されている場合は、SSL ハンドシェイクのサーバ証明書交換の後に行われる必要があります。

早期のトラフィックがその他のすべての基準に一致するが、アプリケーション識別が不完全な場合、システムは、パケットの受け渡しと接続の確立（または、SSL ハンドシェイクの完了）を許可します。システムは識別を完了した後、残りのセッション トラフィックに適切なアクションを適用します。

アクセス コントロールの場合、これらの受け渡されたパケットは、アクセス コントロール ポリシーのデフォルトの侵入ポリシー（デフォルト アクション侵入ポリシーでもほぼ一致するルールの侵入ポリシーでもない）によりインスペクションが実行されます。

アプリケーションや他のルールより前に配置される URL ルール

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

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

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

暗号化および復号トラフィックのアプリケーション制御

システムは暗号化トラフィックと復号トラフィックを識別し、フィルタ処理することができます。

• 暗号化トラフィック：システムは、SMTPS、POPS、FTPS、TelnetS、IMAPS を含む StartTLS で暗号化されたアプリケーション トラフィックを検出できます。さらに、TLS ClientHello メッセージの Server Name Indication、またはサーバ証明書のサブジェクト識別名の値に基づいて、特定の暗号化されたアプリケーションを識別できます。これらのアプリケーションに SSL Protocol タグが付けられます。SSL ルールでは、これらのアプリケーションのみを選択できます。このタグがないアプリケーションは、暗号化されていないまたは復号されたトラフィックでのみ検出できます。

• 復号トラフィック：システムは、復号されたトラフィック（暗号化されたまたは暗号化されていないトラフィックではなく）のみで検出を行うことができるアプリケーションに decrypted traffic タグを割り当てます。

アプリケーションのアクティブ認証の免除

アイデンティティ ポリシーでは、特定のアプリケーションのアクティブ認証を免除し、トラフィックにアクセス コントロールの続行を許可できます。これらのアプリケーションには、User-Agent Exclusion タグが付けられます。アイデンティティ ルールでは、これらのアプリケーションのみを選択できます。

ペイロードのないアプリケーション トラフィック パケットの処理

アクセス コントロールを実行している場合、システムは、アプリケーションが識別された接続内にペイロードがないパケットに対してデフォルト ポリシー アクションを適用します。

参照されるアプリケーション トラフィックの処理

アドバタイズメント トラフィックなどの Web サーバによって参照されるトラフィックを処理するには、参照しているアプリケーションではなく、参照されるアプリケーションを照合します。

複数のプロトコルを使用するアプリケーション トラフィックの制御（Skype）

システムは、Skype の複数のタイプの アプリケーション トラフィックを検出できます。Skype のトラフィックを制御するには、個々のアプリケーションを選択するのではなく、[アプリケーション フィルタ（Application Filters）] リストから [Skype] タグを選択します。これにより、システムは同じ方法で Skype のすべてのトラフィックを検出してコントロールできるようになります。

コンテンツ制限機能用にサポートされる検索エンジン

システムは、特定の検索エンジンの場合のみ、セーフ サーチ フィルタリングをサポートします。システムは、これらの検索エンジンからのアプリケーション トラフィックに safesearch supported タグを割り当てます。

URL 識別の速度

システムは以下の動作の前に URL をフィルタリングできません。

• モニタ対象の接続がクライアントとサーバの間で確立される。

• システムがセッションで HTTP または HTTPS アプリケーションを識別する。

• システムが要求された URL を識別する（ClientHello メッセージまたはサーバ証明書からの暗号化されたセッションの場合）。

この識別は 3 ～ 5 パケット以内で、またはトラフィックが暗号化されている場合は、SSL ハンドシェイクのサーバ証明書交換の後に行われる必要があります。

早期のトラフィックがその他のすべてのルール条件に一致するが、識別が不完全な場合、システムは、パケットの受け渡しと接続の確立（または、SSL ハンドシェイクの完了）を許可します。システムは識別を完了した後、残りのセッション トラフィックに適切なルール アクションを適用します。

アクセス制御の場合、これらの受け渡されたパケットは、デフォルト アクション侵入ポリシーでもほぼ一致するルールの侵入ポリシーでもなく、アクセス制御ポリシーのデフォルトの侵入ポリシーによりインスペクションが実行されます。

アプリケーションや他のルールより前に配置される URL ルール

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

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

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

カテゴリまたはレピュテーションが不明な URL

URL のカテゴリまたはレピュテーションが不明な場合、Web サイトの閲覧は、カテゴリまたはレピュテーションベースの URL 条件を持つルールには一致しません。URL に手動でカテゴリやレピュテーションを割り当てることはできません。

手動 URL フィルタリング

特定の URL を手動でフィルタリングする場合は、影響を受ける可能性のある他のトラフィックを慎重に考慮してください。ネットワーク トラフィックが URL 条件に一致するかどうか判別するために、システムは単純な部分文字列マッチングを実行します。要求された URL が文字列の任意の部分に一致する場合、URL は一致するとみなされます。

暗号化された Web トラフィックの URL フィルタリング

暗号化された Web トラフィックに対して URL フィルタリングを実行すると、システムは次のように動作します。

• 暗号化プロトコルを無視します。ルールに URL 条件はあるがプロトコルを指定するアプリケーション条件がない場合、ルールは HTTPS および HTTP 両方のトラフィックを照合します。

• URL リストを使用しません。代わりに、URL オブジェクトとグループを使用する必要があります。

• トラフィックを暗号化するために使用する公開キー証明書のサブジェクト共通名に基づいて HTTPS トラフィックを照合し、サブジェクト共通名に含まれるサブドメインを無視します。

• アクセス制御ルール（または、その他の設定）によってブロックされている暗号化された接続の場合は HTTP 応答ページを表示しません。HTTP 応答ページの制限 を参照してください。

URL での検索クエリ パラメータ

システムでは、URL 条件の照合に URL 内の検索クエリ パラメータを使用しません。たとえば、すべてのショッピング トラフィックをブロックする場合を考えます。amazon.com を探すために Web 検索を使用してもブロックされませんが、amazon.com を閲覧しようとするとブロックされます。

選択したデバイス モデルのメモリ制限

メモリの制約上、一部のモデルでは、小規模でそれほど細分化されていないカテゴリとレピュテーションによってほとんどの URL フィルタリングが実行されます。たとえば、親 URL のサブサイトがそれぞれ異なる URL カテゴリとレピュテーションを持っている場合でも、一部のデバイスでは、親 URL のデータのみが保存される場合があります。これらのデバイスによって処理される Web トラフィックの場合、システムはクラウド ルックアップを実行して、ローカル データベースにないサイトのカテゴリとレピュテーションを判断できます。

メモリが少ないデバイスには、7100 ファミリと次の ASA モデルが含まれます：ASA5506-X、ASA5506H-X、ASA5506W-X、ASA5508-X、ASA5512-X、ASA5515-X、ASA5516-X、ASA5525-X。NGIPSv で、カテゴリおよびレピュテーション ベースの URL フィルタリングを実行するための正しいメモリ量を割り当てる方法ついて、詳しくは Firepower System Virtual Installation Guideを参照してください。

アイデンティティ ソース/認証方式の設定

実行する認証タイプのアイデンティティ ソースを設定します。詳細については、ユーザ アイデンティティ ソースについてを参照してください。

ユーザ エージェント、TS エージェント、または ISE/ISE-PIC デバイスのモニタ対象に多くのユーザ グループを設定した場合、またはネットワークでホストにマップされるユーザ数が非常に多い場合、Firepower Management Center のユーザ制限が原因で、システムがグループに基づいてユーザ マッピングをドロップすることがあります。その結果、レルム、ユーザ、またはユーザ グループの条件のルールが、一致することが想定されているトラフィックと一致しなくなる可能性があります。

レルムの設定

監視対象の各 AD または LDAP サーバ（ISE/ISE-PIC、ユーザ エージェント、および TS エージェント サーバを含む）のレルムを設定し、ユーザのダウンロードを実行します。詳細については、レルムの作成を参照してください。

（注）	ISE SGT 属性ルール条件を設定する場合、レルムの設定は任意です。ISE SGT 属性ルール条件は、アイデンティティ ポリシー（レルムの呼び出し元）が関連付けられているかどうかにかかわらず、ポリシー内で設定できます。

レルムを設定するときには、アクティビティを監視するユーザおよびユーザ・グループを指定します。ユーザ グループを含めると、自動的に、すべてのセカンダリ グループのメンバーを含む、そのグループのすべてのメンバーが含まれます。ただし、セカンダリ グループをルール条件として使用する場合は、セカンダリ グループをレルム構成に明示的に含める必要があります。

レルムごとに、ユーザ データの自動ダウンロードを有効にすると、ユーザおよびユーザ グループの信頼できるデータを更新することができます。

アイデンティティ ポリシーの作成

レルムを認証方式に関連付けるアイデンティティ ポリシーを作成し、そのポリシーをアクセス制御に関連付けます。詳細については、アイデンティティ ポリシーの作成を参照してください。

デバイスのユーザ制御（アクセス制御、SSL、QoS）を実行するポリシーは、アイデンティティ ポリシーを共有します。そのアイデンティティ ポリシーによって、それらのデバイス上のトラフィックに影響するルールで使用できるレルム、ユーザ、およびグループが決まります。

QoS ルールでユーザ条件を設定する前に、QoS ポリシーの対象となるデバイスが、デバイスに適用されたアクセス制御ポリシーで定義されている正しいアイデンティティ ポリシーを使用していることを確認する必要があります。同じデバイスに適用された QoS ポリシーとアクセス制御ポリシーは明示的にリンクされていないため、QoS ルール エディタで無効なレルム、ユーザ、およびグループを選択することが可能です。これらの無効な要素は、Firepower Management Center に存在するが、QoS 対象のデバイスには適用されないアイデンティティ ポリシーから取得された要素です。これらの要素を使用すると、実際に適用されるまで、無効な選択をしたことが判別されません。

ユーザ ルールの予期しない動作に気付いたら、ルール、アイデンティティ ソース、またはレルムの設定を調整することを検討してください。その他の関連するトラブルシューティング情報については、以下を参照してください。

• ユーザ エージェント アイデンティティ ソースのトラブルシューティング

• ISE/ISE-PIC アイデンティティ ソースのトラブルシューティング

• TS エージェント アイデンティティ ソースのトラブルシューティング

• キャプティブ ポータルのアイデンティティ ソースのトラブルシューティング

• レルムとユーザのダウンロードのトラブルシューティング

レルム、ユーザ、またはユーザ グループを対象とするルールがトラフィックと一致しない

ユーザ エージェント、TS エージェント、または ISE/ISE-PIC デバイスのモニタ対象に多くのユーザ グループを設定した場合、またはネットワークでホストにマップされるユーザ数が非常に多い場合、Firepower Management Center のユーザ制限が原因で、システムがユーザ レコードをドロップすることがあります。その結果、ユーザ条件のルールが、一致することが想定されているトラフィックと一致しない可能性があります。

ユーザ グループまたはユーザ グループ内のユーザを対象とするルールが、一致することが想定されているトラフィックと一致しない

ユーザ グループ条件を含むルールを設定する場合は、LDAP または Active Directory サーバでユーザ グループを設定している必要があります。サーバが基本的なオブジェクト階層でユーザを整理している場合、システムはユーザ グループ制御を実行できません。

セカンダリ グループ内のユーザを対象とするルールが、一致することが想定されているトラフィックと一致しない

Active Directory サーバのセカンダリ グループのメンバーであるユーザを含めるか除外するユーザ グループ条件を含むルールを設定する場合、サーバは報告するユーザの数を制限していることがあります。

デフォルトでは、Active Directory サーバはセカンダリ グループから報告するユーザの数を制限します。この制限は、セカンダリ グループ内のすべてのユーザが Firepower Management Center に報告され、ユーザ条件を含むルールでの使用に適するようにカスタマイズする必要があります。

ルールが、初めて表示されたユーザと一致しない

システムは、以前に表示されていないユーザからのアクティビティを検出すると、サーバからそれらのユーザに関する情報を取得します。システムがこの情報を正常に取得するまで、このユーザに表示されるアクティビティは、一致するルールによって処理されません。代わりに、ユーザ セッションが、一致する次のルール（または該当する場合はポリシーのデフォルト アクション）によって処理されます。

たとえば、次のような状況が考えられます。

• ユーザ グループのメンバーであるユーザが、ユーザ グループ条件を含むルールに一致しない。

• ユーザ データの取得に使用されたサーバが Active Directory サーバである場合、ユーザ エージェント、TS エージェント、または ISE/ISE-PIC デバイスによって報告されたユーザがルールと一致しない。

これにより、システムがユーザ データをイベント ビューおよび分析ツールに表示するのが遅れる可能性があることに注意してください。

ルールがすべての ISE ユーザと一致しない

これは想定されている動作です。Active Directory ドメイン コントローラで認証された ISE ユーザに対してユーザ制御を実行することができます。LDAP、RADIUS、または RSA ドメイン コントローラで認証された ISE ユーザに対するユーザ制御は実行できません。

ルールがすべての ISE/ISE-PIC ユーザと一致しない

これは想定されている動作です。Active Directory ドメイン コントローラで認証された ISE/ISE-PIC ユーザに対してユーザ制御を実行することができます。LDAP、RADIUS、または RSA ドメイン コントローラで認証された ISE/ISE-PIC ユーザに対するユーザ制御は実行できません。

予期しないルールの動作に気付いたら、カスタム SGT オブジェクトの設定を調整することを検討してください。

使用不可のセキュリティ グループ タグ オブジェクト

カスタム SGT オブジェクトは、ISE/ISE-PIC をアイデンティティ ソースとして設定していない場合にのみ使用できます。詳細については、カスタム セキュリティ グループ タグ（SGT）から ISE セキュリティ グループ タグ（SGT）への自動遷移を参照してください。