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

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

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

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

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

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

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

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

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

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

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

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

（注）

システムがアプリケーションを認識できるようにするため、サーバーはアプリケーションのプロトコル要件に準拠する必要があります。たとえば、ACK が期待されるときに ACK ではなくキープアライブパケットを送信するサーバーがある場合、そのアプリケーションは識別されない可能性があり、接続はアプリケーションベースのルールに一致しません。代わりに、接続は別の一致するルールまたはデフォルトアクションによって処理されます。これは、許可したい接続がむしろ拒否される可能性があることを意味します。この問題が発生し、プロトコルの標準規格に準拠するようにサーバーを修正できない場合は、たとえば、IP アドレスとポート番号を照合することで、そのサーバーのトラフィックをカバーする非アプリケーションベースのルールを作成する必要があります。

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 タグを割り当てます。

TLS サーバーアイデンティティ検出とアプリケーション制御

RFC 8446 で定義されている最新バージョンの Transport Layer Security（TLS）プロトコル 1.3 は、セキュアな通信を提供するために多くの Web サーバーで採用されているプロトコルです。TLS 1.3 プロトコルが、セキュリティを強化するためにサーバーの証明書を暗号化する一方で、証明書が、アクセスコントロールルールのアプリケーションおよび URL フィルタリング基準に適合する必要があるため、Firepower システムは、パケット全体を復号せずにサーバー証明書を抽出する方法を提供します。

この機能は、アプリケーションまたは URL の基準に適合させたいトラフィックに関して、特にそのトラフィックの詳細な検査を実行する必要がある場合に、有効にすることを強くお勧めします。サーバー証明書を抽出するプロセスでトラフィックが復号されないため、復号ポリシー は必要ありません。

詳細については、アクセス コントロール ポリシーの詳細設定を参照してください。

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

アイデンティティ ポリシーでは、特定のアプリケーションのアクティブ認証を免除し、トラフィックにアクセス コントロールの続行を許可できます。これらのアプリケーションには、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 のメディアを選択的にブロックすることはできません。

• RDP（Remote Desktop Protocol）：

  RDP アプリケーションを許可してもファイル転送が許可されない場合は、RDP のルールに TCP と UDP の両方のポート 3389 が含まれていることを確認してください。RDP ファイル転送では UDP が使用されます。