アプリケーション制御に関する次の注意事項と制約事項に注意してください。

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

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

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

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

アプリケーションを識別する前に通過する必要のあるパケットを調べるためのポリシーの設定

システムは、次の両方の条件が満たされるまで、インテリジェント アプリケーション バイパス（IAB）およびレート制限を含むアプリケーション制御を実行できません。

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

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

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

重要これらの初期パケットをシステムが確実に調べるようにするには、トラフィック識別の前に通過するパケットを処理するためのポリシーの指定を参照してください。

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

URL とアプリケーションのフィルタリング用の個別のルールの作成

アプリケーションと URL の基準を組み合わせることで、予期しない結果が生じることがある（特に暗号化されたトラフィックの場合）ため、可能な限り、URL とアプリケーションのフィルタリング用に個別のルールを作成します。

アプリケーションと URL の基準の両方を含むルールは、より一般的なアプリケーションのみまたは URL のみのルールの例外として機能している場合を除き、アプリケーションのみまたは URL のみのルールの後に来る必要があります。

アプリケーションや他のルールより前に配置される 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、Zoho）

一部のアプリケーションは、複数のプロトコルを使用します。このようなアプリケーションのトラフィックを制御するには、関連するすべてのオプションがアクセス コントロール ポリシーの対象となっていることを確認します。次に例を示します。

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

• Zoho：Zoho メールを制御するには、[使用可能なアプリケーション（Available Application）] リストから [Zoho] と [Zohoメール（Zoho mail）] の両方を選択します。

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

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

回避的アプリケーション トラフィックの制御

用途別の注意事項と制限事項を参照してください。

アプリケーション制御のルールの順位付けに関するその他のガイドライン

アプリケーション コントロール ルールの順位付けに関するガイドラインについては、アプリケーション制御の設定のベストプラクティスを参照してください。

アプリケーションによるネットワークへのアクセスを次のように制御することをお勧めします。

• 安全性の低いネットワークからより安全なネットワークへのアプリケーションアクセスを許可またはブロックするには、アクセス コントロール ルールでポート(選択された宛先ポート) 条件を使用します。

  たとえば、インターネット（安全性が低い）から内部ネットワーク（安全性が高い）への ICMP トラフィックを許可します。

• ユーザーグループによってアクセスされるアプリケーションを許可またはブロックするには、アクセス コントロール ルールでアプリケーション条件を使用します。

  たとえば、契約業者グループのメンバーによる Facebook へのアクセスをブロックします。

注意

アクセス コントロール ルールを適切に設定しないと、ブロックする必要があるトラフィックを含め、予期しない結果が発生する可能性があります。一般的に、アプリケーション制御ルールは、たとえば IP アドレスに基づくルールよりも照合に時間がかかるため、アクセス コントロール リスト内の順位を低くする必要があります。 特定の条件 (ネットワークや IP アドレスなど) を使用するアクセス コントロール ルールは、一般的な条件 (アプリケーションなど) を使用するルールの前にオーダーする必要があります。オープン システム相互接続（OSI）モデルに精通している場合は、考え方として同様の順位付けを使用してください。レイヤ1、2、および 3 (物理、データリンク、およびネットワーク) の条件を持つルールは、アクセス コントロール ルールで最初に注文する必要があります。レイヤ5、6、および 7 (セッション、プレゼンテーション、およびアプリケーション) の条件は、アクセス コントロール ルールの後で順序付けする必要があります。OSI モデルの詳細については、こちらの Wikipedia の記事を参照してください。

次の表に、アクセス コントロール ルールを設定する方法の例を示します。

• Office 365 管理者用ポータル：

  制限：アクセス ポリシーのロギングが最初と最後で有効になっている場合、最初のパケットは Office 365 として検出され、接続の終了は Office 365 管理者用ポータルとして検出されます。これがブロッキングに影響を与えないようにする必要があります。

• Skype:

  アプリケーション制御のベストプラクティスを参照してください

• GoToMeeting

  GoToMeeting を完全に検出するには、ルールに次のすべてのアプリケーションが含まれている必要があります。

  • GoToMeeting

  • Citrix Online

  • Citrix GoToMeeting プラットフォーム

  • LogMeIn

  • STUN

• Zoho:

  アプリケーション制御のベストプラクティスを参照してください

• Bittorrent、Tor、Psiphon、および Ultrasurf などの回避的なアプリケーションの場合：

  回避的なアプリケーションの場合、デフォルトでは、信頼性の高いシナリオのみが検出されます。このトラフィックに対するアクション（ブロックや QoS の実装など）を実行する必要がある場合、より効果の高い、さらに積極的な検出の設定が必要なことがあります。これを実行する場合、設定の変更によって誤検出が発生する可能性がありますので、TAC に問い合わせて設定を確認してください 。

• WeChat：

  WeChat を許可する場合、WeChat のメディアを選択的にブロックすることはできません。

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

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

ISE/ISE-PIC 、ユーザーエージェント、または TS エージェントデバイスのモニター対象に多くのユーザーグループを設定した場合、またはネットワークでホストにマップされるユーザー数が非常に多い場合、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 または Cisco TrustSec の問題のトラブルシューティング

• 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 ユーザーに対するユーザー制御は実行できません。

ユーザーとグループによる大量のメモリの使用

ユーザーとグループの処理によって大量のメモリが使用されている場合、/var/log/messages に次のようなメッセージが表示されます。

UserGroup [WARN] User/Group mem usage is above 80 percent

別のメッセージには、ユーザーとグループによって使用されているメモリのパーセンテージが表示されます。

こうしたメッセージの表示が続く場合には、次のオプションのいずれかを実行できます。

• アクセス コントロール ポリシーによって処理されるユーザを制限します。

• 管理対象デバイスをメモリが大きなモデルにアップグレードします。

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

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

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