ASA CX および Cisco Prime Security Manager 9.3 ユーザ ガイド
コンテキスト対応アクセス ポリシーによるネットワーク アクセスの制御
コンテキスト対応アクセス ポリシーによるネットワーク アクセスの制御

目次

コンテキスト対応アクセス ポリシーによるネットワーク アクセスの制御

次のトピックでは、ネットワークへのアクセスを制御する CX デバイスのコンテキスト対応アクセス ポリシーを使用する方法について説明します。

コンテキスト対応アクセス ポリシーの概要

コンテキスト対応アクセス ポリシーは、CX デバイスからアクセプタブル ユース ポリシーを実装するための主要ポリシーです。 コンテキスト対応アクセス ポリシーを使用すると、次のサービスが提供されます。
  • 送信元 IP アドレスと宛先 IP アドレス、プロトコル、トラフィック フローのポートをベースにした従来のコンテキスト対応アクセス ポリシー。

  • ユーザが現在使用している IP アドレスに関係なく、アクセスを要求しているユーザに基づいて、アクセスを許可または拒否する ID ベースのアクセス コントロール。 ID ベースのアクセス コントロールは、個々のユーザではなく、ユーザ グループの指定によって実行されます。したがって、ユーザにはグループ メンバーシップをベースにしたアクセスが提供されます。

  • 特定のアプリケーションまたは一般的なアプリケーションのタイプを許可または拒否するアプリケーション ベースのアクセス コントロール。 望ましくないアプリケーションの中には、ポートの使用方法を変更できるものがあるため、プロトコルとポートのサービス定義を従来どおりに使用しても有効でない場合があります。 インスペクションでは、トラフィック フローで使用されるアプリケーションがよく検出されます。 そのため、Facebook や LinkedIn などのアプリケーション名をベースにしたポリシーを記述すると、使用するポリシーを理解および評価しやすいものにすることができます。

    一部のアプリケーションには許可や拒否を選択できる複数の動作があります。 たとえば、Facebook(へのアクセス)は許可するが、Facebook への投稿を拒否することができます。

  • トラフィック フロー(Web ブラウザなど)を開始するために使用されている HTTP ユーザ エージェント、または、リモート アクセス VPN ユーザの場合は、ユーザのクライアントのオペレーティング システムをベースにした選択によるアクセスを許可するクライアント ベースのアクセス コントロール。

  • 望ましくない Web サイトへのアクセスを防止する URL フィルタリング。 ギャンブルに関する Web サイトなどの特定の URL または Web サイト カテゴリ全体へのアクセスを制御することができます。

  • 特定のサイトへのアクセスがポリシーに反していることを、これらのサイトへのアクセスを公然と拒否せずに、ユーザに通知する警告ポリシー。 ユーザは、リンクをクリックしてサイトに進むことができます。 (HTTP および復号化された HTTPS でのみ動作します。他のすべてのトラフィックは単に許可されます)。

  • パブリック レピュテーション スコアが低い Web サイトへのアクセスを防止する Web レピュテーション フィルタリング。 レピュテーションに基づいたフィルタリングを実施すると、外部の低レピュテーション サイトからホスティングされるサイト上の広告または他の素材を防止しながら、高レピュテーション Web サイトへのアクセスを許可することができます。 したがって、低レピュテーション情報が含まれているため、空のボックスとして表示されるページが出現することがあります。

  • MIME タイプをベースにしたファイルのアップロードまたはダウンロードの拒否を選択できるファイル転送制御。 たとえば、使用中のネットワークにセキュリティ レベルの高いゾーンがある場合、そのゾーンからのファイルのアップロードをすべて禁止することができます。

  • 攻撃の脅威に対してトラフィックの内容を比較する Next Generation IPS フィルタリング。 接続が脅威に一致した場合は、脅威をブロックする接続をドロップできます。 問題のないと決定した脅威を、モニタするが許可すること、または完全に無視することを選択することもできます。

  • 設定した最大レートを超えるトラフィックが発生しないようにして、帯域幅を消費するトラフィック フローがすべてのリソースを占有しないようにするレート制限(ポリシングとも呼ばれる)。

  • ユーザが検索エンジンの制御を緩和することにより不適切または明示的な検索結果が含まれることを防止するセーフサーチの適用。

  • ヘッダーをサポートする Web サイトへの HTTP 要求ヘッダーをメッセージに追加するヘッダーの挿入。 ヘッダーを挿入すると、それらのサイトに要求の特殊な処理を適用できます。

デフォルトのコンテキスト対応アクセス ポリシーの動作

トラフィック フローがアクセス ポリシーのいずれにも適合しない場合、暗黙のアクションがそのフローに適用されます。 適合しないすべてのトラフィック フローは、デフォルトでは無条件に許可されます。 このデフォルト ポリシーは、ダッシュボードまたはイベントに出現する際には Implicit Allow と呼ばれます。


(注)  


デフォルトのコンテキスト対応アクセス ポリシーの動作は、従来のファイアウォール アクセス ポリシーの動作とは正反対です。 たとえば、ASA は、グローバルまたはインターフェイス固有のアクセス ポリシーで、許可ルールに適合しないすべてのトラフィック フローを拒否します。


ベスト プラクティスは、適合しないトラフィック フローに適用するアクションを定義した、明示的なルールを作成することです。 そのポリシーをアクセス ポリシー セットの最後に配置します。 必要に応じて、[Allow] アクションではなく [Deny] アクションを適用できます。 トラフィック一致条件については、[Source]、[Destination]、[Application] にデフォルトの [Any] を使用します。

コンテキスト対応アクセス ポリシーの設定

ネットワーク リソースへのアクセスを制御するには、コンテキスト対応アクセス ポリシーを使用します。 アクセスの制御は次に基づいて行われます。

  • 送信元および宛先の IP アドレス、プロトコル、ポートなどの従来の 5 タプル形式。

  • 要求を作成したユーザ、またはユーザがメンバとなっているユーザ グループ。

  • 使用されているアプリケーション。 汎用的なアプリケーションのタイプに対するアクセスも制御できます。

  • 要求を作成するために使用された HTTP クライアントのタイプ(ブラウザのタイプなど)、または VPN クライアントのオペレーティング システム。

  • 汎用的な URL のカテゴリが含まれる Web 要求の宛先 URL。

ネットワーク アクセスを許可するアクセス ポリシーを作成すると、Next Generation IPS フィルタリングを適用したり、特定のファイル タイプのアップロードまたはダウンロードを禁止したり、パブリック レピュテーションが非常に低い Web サイトへのアクセスを禁じて、許可するアクティビティを制限することができます。

手順
    ステップ 1   Configurations > Policies/Settings を選択し、[Access Policies][Access Policies]タブを開きます。

    (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

    ヒント   

    マルチ デバイス モードモードでは、このタブに CX デバイスおよび親 ASA の両方のアクセス ポリシーが含まれます。 [Context-Aware Policies] をクリックして、CX アクセス ポリシーのセクションで作業していることを確認します。

    ステップ 2   次のいずれかを実行します。
    • 新しいポリシーを追加するには、[Add Policy] ボタンの 1 つを使用します。 ポリシー セットを選択した場合、セットの上部または下部にポリシーを追加できます。 ポリシーを選択した場合、その上または下に新しいポリシーを追加できます。
    • 既存のポリシーを編集するには、ポリシーを選択し、[Edit Policy] ボタンをクリックします。
    • 類似した既存のポリシーを基に新規ポリシーを作成するには、ポリシーを選択し、[Duplicate Policy] ボタンをクリックします。

    ポリシーのプロパティとともに、フォームが開きます。

    ステップ 3   一致するトラフィックに適用するポリシー アクションを選択します。
    • [Allow]:ポリシーでのプロファイルおよびアプリケーション動作の設定に従うトラフィックを許可します。
    • [Warn]:HTTP および復号化された HTTPS 接続の場合、サイトへのアクセスが推奨されないことをユーザに通知する警告通知を表示します。 ユーザは、リンクをクリックして接続を続行できます。 したがって、接続は最初に拒否されますが、潜在的には許可されています。 HTTP および復号化された HTTPS 以外のトラフィックは単純に許可されます。
    • [Deny]:トラフィックを無条件でドロップします。
    ステップ 4   トラフィック一致基準を [Source]、[Destination]、[Application] の各フィールドを使用して定義します。
    基準に基づいてトラフィックを制限しない場合は、フィールドをブランクのままにします。 各フィールドの詳細については参照トピックを参照してください。ただし、次のヒントも考慮してください。
    • 非常に複雑な送信元または宛先基準を作成する必要がある場合は、送信元および宛先オブジェクト グループを使用します。 これらのオブジェクトを使用して、複雑な組み合わせの他のオブジェクトでトラフィック フローを正確に定義できます。

    • URL フィルタリングを実装するには、宛先基準で URL オブジェクトを使用します。 URL カテゴリを使用すると、特定のタイプのサービスを提供するすべての Web サイトへのアクセスを制御することができます。 たとえば、ギャンブル カテゴリを使用すると、すべてのギャンブル サイトの URL を知らなくても、ギャンブルに関するすべての Web サイトを拒否することができます。 カテゴリを拒否する URL オブジェクトをセットアップすることもできますが、カテゴリ内で許可する特定の Web サイトは除外してください。

    • アプリケーション制御を実装するには、[Application] フィールドに基準を指定します。 アプリケーション タイプに基づいて制御するかによって分類されたすべてのアプリケーションに適用する、または、ユーザが自分で定義するアプリケーション サービスなど、特定のアプリケーションを制御します。タグ 使用のアプリケーション詳細、制御を制限せずに特定のポートへのアクセスを制御できます。

      (注)     

      Facebook や LinkedIn などの一部のアプリケーションでは、アプリケーションの特定の動作について、詳細な制御ができるようになっています。 これらの動作は、制御可能な動作のあるアプリケーションを含む項目を選択すると発生します。

    ステップ 5   必要に応じて、ポリシーの時間範囲を設定します。

    時間範囲オブジェクトを指定した場合、トラフィックは指定された期間だけにポリシーを照合できます。 時間範囲外で、ポリシーはほとんどなく、ポリシーに一致するトラフィックは、後続のポリシーと比較されます。 デバイスの現地時間が使用されます。

    ステップ 6   (任意)ポリシー アクションが [Deny] でない限り、アクションを選択的に拒否するように次のプロファイルを設定することもできます。
    • [Bandwidth Limit]:このポリシーに一致する各トラフィック フローを許可する最大帯域幅(1 Kbps ~ 4000 Mbps)。 [Mbps] または [Kbps] で制限を指定でき、適切な基準を選択します。
    • [Safe Search: On/Off]:検索エンジンまたはサポートされている他のコンテンツ検索要求にセーフサーチを適用するかどうか。 セーフサーチを適用することによって、ユーザが検索エンジンの設定を緩和しないようにし、検索結果から不適切なまたは明示的なコンテンツをフィルタリングによって除外できるようにします。 デフォルトは [Off] で、ユーザは必要に応じて検索エンジンを設定できます。
    • [File filtering]:ダウンロードもアップロードもできないファイルの MIME タイプを定義するプロファイル オブジェクトを選択できます。
    • [Web reputation]:ブロックする必要のあるパブリック レピュテーション スコアの範囲を定義するプロファイル オブジェクトを選択できます。 これは、マルウェアからの保護に使用します。 デバイス レベルのプロファイルを使用するには、[Device Level Profile (name)] を選択します。設定されたプロファイルの名前がオプションに表示されます。 事前定義システム オブジェクト [Default web reputation profile] では、レピュテーション スコアが -10 から -6 のサイトで推奨されるブロックが実装されます。
    • [NG IPS]:適用する Next Generation IPS フィルタリング ポリシーを定義するプロファイル オブジェクトを選択できます。 プロファイルを選択しない場合は、フィルタリングは適用されません。 デバイス レベルのプロファイルを使用するには、[Device Level Profile (name)] を選択します。設定されたプロファイルの名前がオプションに表示されます。 事前定義システム オブジェクト [Default NG IPS profile] では、推奨されるポリシーが実装されます。
    • ヘッダーの挿入 :ヘッダー、学校向けなど、 YouTube をサポートする Web サイトに送信される HTTP 要求メッセージを注入するヘッダー プロファイルを定義するオブジェクトを選択できます。 ヘッダーを挿入すると、それらのサイトに要求の特殊な処理を適用できます。 ポリシーの宛先がヘッダーをサポートする少なくとも Web サイトを含めることを保障します。 ヘッダーは非サポート サイトへの要求に注入されません。
    ヒント   

    アクセス ポリシー リストの上のステータス情報を調べることによって、デバイスの侵入防御(Next Generation IPS フィルタリング)およびマルウェア保護(Web レピュテーション)がオンかオフか確認できます。 各機能ごとにデバイスレベルのプロファイルの詳細を表示するには、オン/オフ インジケータ上にマウスを置きます。 機能の設定タブを開くための [Edit Settings] リンクがポップアップにあり、そこで条件とプロファイルを変更することができます。

    ステップ 7   親デバイスの特定のインターフェイス上のトラフィックにのみポリシーを制限する場合は、そのインターフェイスを特定する [Source Interface Role] または [Destination Interface Role]、あるいはその両方を選択します。

    デフォルトでは、デバイス上のあらゆるインターフェイス間のトラフィックにポリシーが適用されます。 デバイスに存在しないインターフェイスを選択すると、トラフィックにはポリシーが適用されません。

    ステップ 8   [Save Policy] をクリックします。
    ステップ 9   優先順位に収まるように、必要に応じてポリシーを移動します。

    ポリシーは、最初に一致したものから順に適用されるため、限定的なトラフィック一致基準を持つポリシーは、同じトラフィックに適用され、汎用的な基準を持つポリシーよりも上に置く必要があります。

    ポリシー セットまたはルールを移動するには、[Move] アイコン(左端の垂直な両方向矢印)をクリックしたまま、挿入位置のすぐ前のポリシーまでドラッグします。 単にシーケンス番号を編集し、目的の値に変更することもできます。


    次の作業

    ポリシーのアクティビティを分析します。 ポリシー リストの各ポリシーには、ヒット カウント情報が含まれています。これは、ポリシーの詳細なポリシー ヒット ダッシュボードにリンクしています。 また、[Dashboard] > [Policies] を選択して、ポリシー ヒット ダッシュボードに直接アクセスすることもできます。

    コンテキスト対応アクセス ポリシーのプロパティ

    ネットワークへのアクセスを制御するには、CX デバイスでコンテキスト対応アクセス ポリシーを使用します。

    アクセス ポリシーには次のプロパティがあります。

    Policy Name

    ポリシーの名前。 この名前は、このポリシーと一致するトラフィックによって生成されるデータとイベントについて、ダッシュボードと Event Viewer に表示されます。そのため、ダッシュボードとイベント データの解析に役立つ名前を選択します。

    Enable Policy:On/Off

    ポリシーがイネーブルかどうかを示します。 ポリシーをオフにすると、ポリシーを削除せずに一時的にディセーブルにできます。 ディセーブルに設定されたポリシーはトラフィックに適用されません。

    Policy Action

    次のいずれかが必要です。

    • [Allow]:ポリシーでのプロファイルおよびアプリケーション動作の設定に従うトラフィックを許可します。

    • [Warn]:HTTP および復号化された HTTPS 接続の場合、サイトへのアクセスが推奨されないことをユーザに通知する警告通知を表示します。 ユーザは、リンクをクリックして接続を続行できます。 したがって、接続は最初に拒否されますが、潜在的には許可されています。 HTTP および復号化された HTTPS 以外のトラフィックは単純に許可されます。

    • [Deny]:トラフィックを無条件でドロップします。

    Eventing:On/Off

    ポリシーに適合するトラフィック フローがイベントとダッシュボード データを生成するかどうかを示します。 デフォルトは [On] です。 イベンティングをオフにすると、このポリシーに一致するトラフィックはダッシュボードに反映されず、Event Viewer にはフローのイベントが表示されません。

    Capture Packets:On/Off

    ポリシーの一致基準がレイヤ 3/レイヤ 4(L3/L4)基準(ネットワーク オブジェクト、サービス オブジェクト)に制限されているか、パケットがデフォルトの [Any] を使用している場合に限り、このポリシーに一致するフローのパケットをキャプチャするかどうかを示します。 パケット キャプチャのデフォルトは [Off] です。 すべてのパケットがキャプチャされるため、パケット キャプチャをイネーブルにする前に、フローに適合するトラフィック ボリュームについて慎重に考慮してください。

    パケットは、L3/L4 以外の基準を使用するポリシーについては、パケット キャプチャがイネーブルになっていてもキャプチャされません。

    パケット キャプチャ ファイルは、パケット キャプチャをオフにするまでディスクに書き込まれません。 パケット キャプチャをサーバにアップロードするには、システム CLI にログインし、support diagnostic コマンドを使用します。

    パケットのキャプチャ方法の詳細については、パケットのキャプチャを参照してください。

    Traffic Matching Criteria

    複雑なトラフィック一致基準を作成して、正確なポリシーを定義することができます。 アクセス ポリシーと一致するためには、フローは指定したすべてのプロパティと一致する必要があります。つまり、プロパティの間には AND 関係があります。 条件に基づいてポリシーを制限しない場合は、デフォルトの [Any] を選択します。 考えられるすべてのトラフィック フローを照合するには、すべてのフィールドをデフォルトの [Any] のままにします。

    [Source]、[Destination]、[Application/Service] 基準は、ポリシーが適用されるトラフィックを決定するために使用されます。 項目の追加、編集、削除方法などの項目の選択方法、選択リストのフィルタリング方法、オブジェクトの作成または編集方法、オブジェクト内容の表示方法については、項目の選択を参照してください。

    Source

    次のタイプのポリシー オブジェクトのリスト:ネットワーク グループ(IP アドレス)、アイデンティティ(ユーザまたはユーザ グループ名)、ユーザ エージェント(Web 要求を作成するクライアント アプリケーションのタイプ)、セキュア モビリティ(リモート アクセス VPN クライアントのタイプ)、または送信元オブジェクト グループ(ポリシーで直接定義できない複雑な AND/OR 関係のオブジェクトのコレクション)。 選択したいずれかのオブジェクトとパケットが一致すると、送信元条件を満たしていると見なされます。


    (注)  


    マルチ デバイス モード)。PRSMマルチ デバイス モード で使用する際には、送信元基準または宛先基準には、CX デバイスを含むデバイスで定義されているネットワーク オブジェクトまたはグループを使用し、サービス基準には、ASA サービス オブジェクトを使用することもできます。 ネットワーク グループ オブジェクトには 2 つのタイプがあります。1 つは ASA と CX デバイスの両方で使用できます。もう 1 つは CX デバイスでのみ使用でき、特に CX ネットワーク グループと呼ばれます。


    Destination

    次のタイプのポリシー オブジェクトのリスト:URL(URL または Web カテゴリ)、または宛先オブジェクト グループ(ポリシーで直接定義できない複雑な AND/OR 関係のオブジェクトのコレクション)。 選択したいずれかのオブジェクトとパケットが一致すると、宛先条件を満たしていると見なされます。

    URL フィルタリング機能を無効にするか、有効な Web Security Essentials ライセンスを持っていない場合、このフィールドや宛先オブジェクト グループで URL オブジェクトを使用することはできません。


    ヒント


    アクセス ポリシーに応じたオブジェクトを設定する際には、暗号化されたトラフィック(復号化ポリシーでフローが復号化されていないもの)または HTTPS ではない復号化されたフローに対して、パスを照合できないことに注意してください。こうした場合、アクセス ポリシーではドメイン名のみが指定された URL が照合されます。


    Application/Service

    (サービスおよびアプリケーションの固有の組み合わせに基づいてアプリケーションを定義する)アプリケーション、アプリケーション タイプ、アプリケーション タグ、アプリケーション、サービス オブジェクト グループ(プロトコルとポートの組み合わせ)、アプリケーション サービスのリストを送信します。 トラフィックは検査されるため、トラフィック フローのアプリケーションは、フローで使用されるポートに関係なく決定されることがよくあります。使用されるポートを予測しようとするよりも、名前によって特定のアプリケーションまたはアプリケーション タイプに送信されるルールを作成することができます。 選択したいずれかのアプリケーション仕様とパケットが一致すると、アプリケーション条件を満たしていると見なされます。


    ヒント


    Application Services 機能をディセーブルにした場合、または有効な Application Visibility and Control ライセンスがない場合、このフィールドは [Services] という名前になり、サービス オブジェクトとグループの使用に限定されます。


    一部のアプリケーションには複数のアプリケーション動作があります。 たとえば、Facebook には投稿やタグ付けなどの動作があり、イベント、一般、メッセージ、注、写真、場所などの Facebook エリアや機能でカテゴリ分けされます。 アクションが [Deny] となっていないアクセス ポリシーに複数の動作があるアプリケーション タイプを指定すると、これらの動作に対して細かい制御を実施します。そのため、通常は、アプリケーション タイプを許可し、特定の動作を拒否することができます。 たとえば、Facebook の投稿は許可するが、写真のアップロードやメッセージの添付は許可しないなどです。

    [Applications]を選択した場合は複数の動作を含む、 set アプリケーション動作機能制御は、[Application]ボックスの下に表示されます。 各動作は別々にリストされます。 特定の動作を制御するため、次の手順を実行します。
    • すべての動作の設定を一度に変更するには、[Set Global Behavior To] に [Allow All] または [Deny All] を選択します。 これらのオプションによって、動作リスト全体の Allow/Deny 設定を変更するショートカットが提供されます。 たとえば、動作の大半を拒否し、数個の動作だけを許可する場合は、まず [Deny All] を選択し、次に目的の動作を [Allow] に変更することができます。 デフォルトでは、すべてのアプリケーション動作が許可されます。

    • 個々の動作の設定を変更するには、[Allow/Deny] フィールドをクリックして目的のオプションを表示します。 [Allow/Deny] フィールドは、全体のポリシー アクションを [Allow] に変更した場合にのみ表示されます。

    Shared/Local

    マルチ デバイス モードのみ)。このポリシーを設定するデバイス。 このフィールドを空白のままにした場合は、ポリシーは、ポリシーを含むポリシー セットを共有するすべてのデバイスで設定されます。 ポリシー セットを共有するデバイスのサブセットにこのポリシーを制限する場合は、それらのデバイスをここで選択します。ポリシーは、別の状況でポリシー セットを共有する、リストにないデバイスでは設定されません。 選択可能なデバイスは、現在ポリシー セットを共有するデバイスに制限されます。

    たとえば、別の状況でデバイス グループと同じポリシーを使用するデバイスに固有の少数のポリシーを作成するには、この設定を使用できます。

    時間範囲:

    このポリシーがアクティブになっている時間を定義するデバイスの現地時間で評価される時間範囲オブジェクト。 オブジェクトを選ばなければ、ポリシーは常にアクティブです。 オブジェクトを希望した場合、ポリシーは、指定された期間に有効です。

    Profile

    ポリシー アクションに [Deny] を選択しなかった場合は、アクセプタブル ユース ポリシーを実装するため、プロファイル オプションを選択することもできます。 プロファイルを使用すると、特定のタイプのトラフィックをドロップできます。このタイプは、アクション プロファイルを使用しない場合は許可されます。

    • [Bandwidth Limit]:このポリシーに一致するトラフィックを許可する最大帯域幅(1 Kbps ~ 4000 Mbps)。 [Mbps] または [Kbps] で制限を指定でき、適切な基準を選択します。

    • [Safe Search: On/Off]:検索エンジンまたはサポートされている他のコンテンツ検索要求にセーフサーチを適用するかどうか。 セーフサーチを適用することによって、ユーザが検索エンジンの設定を緩和しないようにし、検索結果から不適切なまたは明示的なコンテンツをフィルタリングによって除外できるようにします。 デフォルトは [Off] で、ユーザは必要に応じて検索エンジンを設定できます。

    • [File Filtering]:ユーザがアップロードまたはダウンロードできるファイルのタイプを指定するプロファイル オブジェクト。

    • [Web Reputation]:トラフィックの Web レピュテーションに基づいてドロップされるトラフィックを判定するプロファイル オブジェクト。 プロファイルを選択しない場合は、フィルタリングは適用されません。 デバイス レベルのプロファイルを使用するには、[Device Level Profile (name)] を選択します。設定されたプロファイルの名前がオプションに表示されます。 事前定義システム オブジェクト [Default web reputation profile] では、レピュテーション スコアが -10 から -6 のサイトで推奨されるブロックが実装されます。

    • [NG IPS]:適用する Next Generation IPS フィルタリング ポリシーを定義するプロファイル オブジェクト。 プロファイルを選択しない場合は、フィルタリングは適用されません。 デバイス レベルのプロファイルを使用するには、[Device Level Profile (name)] を選択します。設定されたプロファイルの名前がオプションに表示されます。 事前定義システム オブジェクト [Default NG IPS profile] では、推奨されるポリシーが実装されます。

    • ヘッダーの挿入 :HTTP 要求メッセージを注入するヘッダー プロファイルを定義するオブジェクトは、ヘッダー、学校向けなど、 YouTube をサポートする Web サイトに送信されます。 ヘッダーを挿入すると、それらのサイトに要求の特殊な処理を適用できます。 ポリシーの宛先がヘッダーをサポートする少なくとも Web サイトを含めることを保障します。 ヘッダーは非サポート サイトへの要求に注入されません。

    Interface Roles

    ポリシーの適用先とする親デバイスのインターフェイスを特定する条件です。 ポリシーに一致するには、該当の送信元インターフェイスのいずれかでデバイスにトラフィックが着信し、該当の宛先インターフェイスのいずれかでデバイスからトラフィックが発信される必要があります。 デフォルトでは、送信元と宛先のいずれにも任意のインターフェイスを使用できます。つまり、ポリシーが特定のインターフェイスに制限されていません。

    特定のインターフェイスにポリシーを制限するには、[Source Interface Role] フィールドまたは [Destination Interface Role] フィールド、あるいはその両方で適切なインターフェイス ロール オブジェクトを選択します。 インターフェイス ロール オブジェクトは、インターフェイス名またはインターフェイスの命名パターンを定義します。


    ヒント


    インターフェイス ロールを指定しても、そのロールで定義しているインターフェイス名に一致するインターフェイスがデバイス上にない場合は、そのデバイス上のどのトラフィックにもポリシーは適用されません。


    Tags

    この項目の識別に役立つ語とフレーズ。 たとえば、同じタグを複数の項目に割り当てると、検索での表示が容易になります。 タグでは、ユーザが選択した使用例、目的、またはその他の特性を識別できます。 これらのタグは、ユーザの目的にのみ対応しています。システムやポリシーの機能には影響しません。 複数のタグを入力(または選択)できます。

    Ticket ID

    ご使用のサポート システム(Remedy など)からのケース ID またはチケット ID。 ネットワーク サポート ケースに関連する変更を行う場合、トラッキング用にここにチケット ID を入力できます。 新しい ID を入力するか、保留中の変更に使用されている既存の ID から選択することができます。必要なだけの ID を指定します。 (すでにコミットされている変更で使用した ID は、このリストに表示されません)

    ユーザへの望ましくないサイトの警告

    望ましくないと考えられるサイトにユーザがアクセスしようとするときに通知するには、警告アクセス ポリシーを使用できます。

    警告ポリシーに一致する HTTP または復号化された HTTPS の場合、接続は最初に拒否され、警告のエンド ユーザ通知ページが表示されます。 メッセージを読んだ後に、ユーザはそのサイトに進むリンクをクリックすることを選択できます。 つまり、警告ポリシーは、最初は拒否アクションになりますが、許可アクションと組み合わせることができます。 Event Viewer では、拒否の理由に、このような場合ユーザによる警告の受け入れが保留中であることが示されます。 [User Accepted Warning] フィールドに [Yes] が指定された HTTP Complete メッセージは、ユーザがサイトに進んだことを示しています。

    ユーザに HTML の警告ページを表示する必要があるため、警告ポリシーはブラウザでホストされた HTTP/HTTPS トラフィックのみ意味をなします。 したがって、警告ポリシーは宛先の URL オブジェクトを使用する必要があります。 たとえば、警告アクションを GRE トラフィックのルールに適用することは意味がありません。 具体的には次のとおりです。

    • 警告を証明できない HTTP/HTTPS トラフィックはドロップされます。 つまり、ブラウザで通常ドロップされる催されない Web ベースのアプリケーション向けにセールスします。 そのため、警告のポリシーは、アプリケーションのフィルタにかけてからのない選択肢ではありません。

    • 警告ポリシーに一致するすべての非 HTTP または復号化されない HTTPS トラフィックは単純に許可されます。

    組織のアクセプタブル ユース ポリシーを説明するには、警告のエンド ユーザ通知ページを変更できます。

    警告ポリシーの制限

    ユーザがリンクをクリックしてサイトに進むと、システムは宛先ではなく、ユーザの IP アドレスと警告ポリシーに基づいて受け入れを追跡します。 ポリシーに一致するその IP アドレスからの後続のトラフィックは、8 時間後に受け入れがタイムアウトするまで警告なしで許可されます。 ユーザが警告を受け入れるときに、トラッキングのこの方法には次の影響があります。

    • NAT を使用して複数のアドレスを単一の IP アドレスにのマッピングする場合、警告を受け入れた最初のユーザはすべてのユーザに対して警告を受け入れます。 警告しているサイトにアクセスしようとする後続のユーザには、警告は表示されません。

    • 警告ポリシーで Web カテゴリを使用する場合、ユーザはそのカテゴリのすべてサイトの警告を受け入れます。 したがって、ユーザがギャンブル サイト A に移動し、警告を受け入れた場合、ユーザにはギャンブル サイト B の警告は表示されません。

    • 警告ポリシーで複数の Web カテゴリを指定した場合、ユーザは一度にそのすべてのカテゴリの警告を受け入れます。 したがって、ギャンブルおよびゲームの警告のポリシーを作成した場合に、ユーザがギャンブル サイト A に移動して、警告を受け入れると、ユーザにはゲーム サイト B の警告は表示されません。

    警告ポリシーに関する推奨事項

    カスタマイズできる警告のエンド ユーザ通知ページが 1 つあります。 警告するすべての Web カテゴリおよぼアプリケーションをリストするには、このページを使用できます。

    警告ポリシーを設定する場合、採用できる 2 つの主な戦略があります。

    1. すべての境界線サイトを含む単一のポリシーを作成します。 これは最も簡単な方法ですが、複数のサイトまたはカテゴリを指定した場合に、ユーザが 1 つの警告を受け入れると、ユーザはそれらすべての警告を受け入れます。 ユーザは、すべての境界線のアクセスの試行に対して警告されない場合があります。

    2. サイトまたはカテゴリごとに個別の警告ポリシーを作成します。 境界線領域に一致するサイトおよびカテゴリの数に応じて、ポリシー リストが膨れることがあります。 ただし、疑わしいアクセス試行に対してユーザに警告する機会が増えます。 また、ポリシーのヒット カウントに基づいてカテゴリごとにアクセス試行の量を追跡することができます。

    レート制限の適用(ポリシング)

    レート制限は、ポリシングとも呼ばれ、設定した最大レート(ビット/秒単位)を超えるトラフィックが発生しないようにして、帯域幅を消費するアプリケーションがすべてのリソースを占有しないようにする方法です。 トラフィックが最大レートを超えると、CX は超過した分のトラフィックをドロップします。

    レート制限を適用するには、CX コンテキスト対応アクセス ポリシーの [Profile] の下で、[Bandwidth Limit] フィールドに値を入力します。 [Mbps] または [Kbps] で制限を指定でき、適切な基準を選択したことを確認します。

    たとえば、次のいずれかに対して 50 Kbps のレート制限を適用するアクセス ポリシーを作成することができます。

    • [Application/Service] では、ファイル共有、iTunes、およびソーシャル ネットワーキングのアプリケーション タイプを選択します。

    • [Destination] では、エンターテインメント、ゲーム、ストリーミング オーディオ、およびストリーミング ビデオなどの高帯域幅のカテゴリを指定する URL オブジェクトを選択します。

    • [Source] では、アクセスを制限する必要があるユーザ グループを指定するアイデンティティ オブジェクトを選択します。

    ポリシーに一致するすべての同時トラフィック フローは一括されて制限が適用されます。 制限は、他のアクセス ポリシーに一致するフローには影響しません。 一致フローのイベントは制限が適用されたことを示します。

    ASA でも、ポリシングのレート制限およびその他の Quality of Service(QoS)設定を設定できることに注意してください。 両方のデバイスにレート制限を適用した場合、実際の最大制限は、アクセス ポリシーで設定した制限よりも低くなる場合があります。 さらに、ASA レート制限は、CX で制限しようとしていないトラフィックに適用される場合があります。

    セーフサーチの適用

    Google および Yahoo など、多くの検索エンジンおよび他のコンテンツの多い Web サイトには、セーフサーチと呼ばれる機能があります。 セーフサーチを使用すると、検索要求から不適切なまたは明示的な結果をフィルタリングするようにサイトを設定できます。 Google の「明示的な結果のフィルタリング」または Yahoo の「成人向け Web、ビデオ、および画像の検索結果のフィルタリング」など、各サイトはこの検索オプションに異なる用語を使用しています。

    セーフサーチはオプションなので、ユーザはオフにし、フィルタリングされていない結果を取得することができます。 これは、特に、他のユーザが簡単に見ることができる画像が検索結果に含まれる場合、組織で望ましくない場合があります。 したがって、CX コンテキスト対応アクセス ポリシーを使用してセーフサーチを適用できます。

    セーフサーチを適用にするには、CX コンテキスト対応アクセス ポリシーの [Profile] セクションで [Safe Search: On] を選択するだけです。 セーフサーチの適用が必要なユーザやネットワークに合わせてポリシーを調整するには、[Source] および [Destination] フィールドを使用します。

    セーフサーチを適用するときに、CX は適度なブロックではなく、厳密なブロックを実装します。 HTTP インスペクタは、ターゲットの検索エンジンで使用される実装に基づいて、必要な文字列を含むように検索 URL を変更するか、または HTTP ヘッダーを変更します。 CX が特定の検索エンジンをサポートしていない場合、そのエンジンにアクセスするすべてのユーザは、セーフサーチ対応ポリシーに一致するトラフィック フローのために拒否されます。

    セーフサーチを有効にするときは、次のことに注意してください。

    • CX がユーザの検索 URL を書き換える必要がある場合、トラフィック イベントの [Safe Search] 列は [Yes] になります。

    • CX が検索エンジンをサポートしていない場合、ユーザにはサイトがブロックされたという通知が表示され、管理者には [HTTP Deny] イベントが表示されます。

    • トラフィックを復号化する復号化ポリシーがある場合だけ、セーフサーチの適用は HTTPS のサイトに適用されます。 トラフィックが復号化されない場合は、検索 URL を書き換えられません。

    • サポートされているサイトのリストについては、リリース ノートについては、 http:/​/​www.cisco.com/​c/​en/​us/​support/​security/​asa-next-generation-firewall-services/​products-release-notes-list.html を参照してください。

    ユーザへのブロッキング ポリシーの通知

    トラフィック フローを拒否するアクセス ポリシーを作成すると、エンドユーザは宛先からブロックされます。 一般的なポリシーは、特に URL フィルタリングを実装したり、アプリケーションまたはアプリケーションの動作のブロッキングの選択を実装した場合は、公開が必要になることがあります。 たとえば、ギャンブルに関するすべての Web サイトや Facebook へのアクセスがブロックされていることを、ユーザが前もって知っている場合、これらのサイトへのアクセスは試行しません。また、試行してもアクセス先がブロックされることを予想できます。

    次のトピックで、エンド ユーザの通知と、独自の通知ページを設定する方法について説明します。

    通知が送信される条件

    多くの場合、CX デバイスは、Web 宛先をブロックするとユーザのブラウザにエンド ユーザの通知のページを表示します。 この通知には、組織のポリシーによってリソースへのアクセスがブロックされていることが示されます。

    エンドユーザへの通知ページはいつでも表示できるわけではありません。 通常は、ユーザが Web 宛先への標準 URL を開こうとしたときに、その Web サイトにブロッキングが広範囲に適用されている場合に通知が表示されます。 ただし、通知は常に可能ではありません。 次のリストで、通知なしでユーザがリソースからブロックされるいくつかの状況を示します。
    • 通知は Web 以外のトラフィックに対して送信されることがありません。ユーザが通知を確認できるのは、HTTP リソースまたは HTTPS リソースにアクセスした場合だけです。

    • トランザクションがブロックしている Next Generation IPS 脅威に一致するため、宛先が拒否される場合、通知が送信されることはありません。

    • IP アドレス、ユーザ名、またはユーザ グループ メンバーシップに基づいてアクセスが拒否された場合の通知は送信されません。

    • 警告ポリシーの場合、トラフィックが一致する要素(IP アドレス、ユーザ名、ユーザ グループ メンバーシップ、URL アプリケーションなどを含む)に関係なく、通知が表示されます。 通知が表示できない HTTP/HTTPS トラフィックは、非 HTTP/HTTPS トラフィックだけが妨げに割り当てられます。

    • 標準 Web ページではなく、自己完結したアプリケーションの外観を与える Web 2.0 スタイル アプリケーションのサイトへのアクセスを拒否すると、ユーザに通知が表示されない可能性が高くなります。 この現象は、Web サイトがユーザ エクスペリエンスの制御に Javascript を使用しているために発生します。新しいページを読み込む代わりに、AJAX 呼び出しを使用して、URL を変更せずにページのコンテンツを更新することがよくあります。 デバイスは、ユーザが定義したアプリケーションの動作に対する要求を認識できますが、ユーザへの通知をサイトの Javascript に挿入することはできません。

    • その結果、一部のポリシーは、フローが許可されるか、拒否されるかにかかわらず、評価が「遅延」します。 適切なネットワーク パフォーマンスを保証するために、フローの拒否を決定する前に、デバイスが宛先にトラフィック フローの一部を送信する場合があります。 これは、ファイルのアップロードまたはダウンロードが妨害される、またはアプリケーションの仕様に基づいてフローを妨げるポリシーがある場合に発生することがあります。 宛先からの最初の応答を受信してからフローが最終的に拒否された場合、そのフローは途中でドロップされ、通知できません。

    • アクセス ポリシーの順序が重要です。 アクセス ポリシー セット内の下部にある拒否ポリシーとトラフィック フローが一致し、ポリシー セット内の上部にあるポリシー(アプリケーション基準を指定するポリシーなど)で、フローが一致するかどうかの判断に追加の分析が必要な場合は、フローの一部が送信され、最初の応答を受信してから、遅れて拒否の判断が行われることがあります。 ポリシー セットは最初に一致したものから順に分析されるため、必ず汎用性の高いポリシーよりも上に、限定的なポリシーを配置する必要があります。 URL フィルタリングなどの単純なポリシーも、複雑なアプリケーション フィルタ ポリシーよりも上に配置する必要があります。

    [End User Notifications] ページ

    サイトへのアクセスが拒否されるか、それに対して警告されたときにユーザに表示されるページをカスタマイズするために、エンド ユーザ通知機能を使用します。 アクセスをブロックした可能性のある原因によって異なる通知を作成できます。 次のイメージとテキストで、このページの基本的な使用方法について説明します。

    図 1. [End User Notification] ページ



    次に、イメージのコールアウトを説明します。

    (1)[Notification Type]

    リソースへのアクセスが拒否された理由に基づいて異なる通知を設定できます。 複数の拒否の原因がトラフィックに適用された場合、使用される通知は次の優先順位に基づきます。 (警告通知は常に警告ポリシーに対して表示されます)。

    • Web reputation:トラフィックは、ポリシーに結び付けられている Web レピュテーション プロファイルで定義された許可レピュテーション範囲に違反しました。

    • File type:トラフィック フローのファイルは、アクセス ポリシーに結び付けられているファイル フィルタリング プロファイルに基づき、許可されませんでした。

    • URL filtering:宛先 Web サイトは許可されていません。 これは、URL に基づくことも、サイトのカテゴリに基づくこともあります。

    • アプリケーション:トラフィック フローが許可されていないアプリケーションまたはアプリケーション動作のためでした。

    • Destination:何らかの理由で許可されていないサイトのトラフィック フローでした。 これには、ユーザのアイデンティティ、ユーザ グループ メンバーシップなど、送信元の基準に基づくサイト アクセスの拒否が含まれます。 このメッセージは、他のメッセージが拒否の原因に適合しない場合に表示されます。

    • Warning:トラフィックは、警告アクションを持つポリシーに一致しました。 通知ページには、ユーザが望ましくないサイトに進むことができるリンクが含まれています。

    • 認証:トラフィックは「スタイル」認証方式を使用して、アイデンティティ ポリシーに一致する。 このページでは、ユーザー名とパスワードのユーザを同。

    (2)[Import]

    選択した通知タイプの独自の HTML ファイルをインポートするには、このボタンをクリックします。

    (3)[Preview Draft]

    編集中のメッセージがユーザにどのように表示されるかを確認するには、このボタンをクリックします。 変数には、値の例を使用しています。

    (4)[Restore Default]

    編集中のメッセージをシステム デフォルトに戻すには、このボタンをクリックします。 デフォルト メッセージが表示され、確認するプロンプトが表示されます。操作を完了するには、[Restore] をクリックします。

    (5)[Background Color]

    通知パネルの背景色を表す 16 進数。 ボックスをクリックしてカラー パレットを開き、目的の色をクリックするか、または目的の値を知っている場合はその数値を直接編集します。 数値を編集した場合、変更を完了するために、ボックスの外側をクリックします。

    (6)メッセージの左側のペイン

    エンド ユーザの通知メッセージの左側のペインには、上から順に、次の項目が含まれています。

    • ロゴ イメージ:組織独自のロゴを追加するには、[Upload Logo] をクリックします。 ページに、イメージの制限に関する説明が表示されます。 グラフィックが必要ない場合は、[Remove Logo] をクリックできます。

    • アクション イメージ:実行するアクションを示すイメージ。 [Upload Graphic] をクリックして独自のイメージを追加するか、または必要ない場合は [Remove Graphic] をクリックします。

    • メッセージの見出し:実行するアクションを示すテキスト メッセージ。

    (7)メッセージの右側のペイン

    メッセージの詳細部分です。 上部の編集コントロールで、メッセージを操作できます。 ペインのコントロールおよび要素は、次のとおりです。

    • [Undo]、[Redo]ボタン:必要に応じて使用して、変更の取り消しとやり直しを循環させることができます。

    • [B]、[I]、[U]:テキストを太字、イタリック体または下線付きにします。

    • 右、左、中央または均等にテキストを配置します。

    • チェーン リンク:ハイパーリンク URL を入力します。 リンクの URL およびテキストの入力を求められます。 カーソルの位置にリンクを追加するには、[Set] をクリックします。

    • [Insert variable]:カーソルの位置にシステム変数を挿入します。 拒否されたトラフィック フローに関する変数に割り当てられた値はエンド ユーザに表示されます。 変数は、二重波カッコで囲まれます({{variable_name}})。

    • HTML ソースの[<>]ボタン:形式作成中のメッセージ本文のビューをソース・コード切り替えます。 ソース・コードの表示はカスタム ページを設計し、場合によっては、ページを更新しやすくなります。

    • メッセージ本文:メッセージ本文ボックスに入力します。 インデントを追加または削除するには Tab キー/Reverse Tab キーを使用します。

    エンド ユーザの通知のカスタマイズ

    エンドユーザが Web ページへのアクセスを拒否されたり、サイトへのアクセスに対して警告されたりするときに、エンドユーザに表示される通知を変更できます。 事前定義された通知を編集してページをカスタマイズするか、または通知ページとして使用する独自の HTML をインポートできます。

    次のトピックで、通知ページを変更する方法について説明します。

    エンド ユーザの通知の編集

    サイトへのアクセスを拒否されるか、それに対して警告されたときにユーザに表示されるページを編集できます。 拒否の理由ごとに異なるページがあります。

    手順
      ステップ 1   [Administration] > [End User Notification] を選択します。

      使用可能な通知タイプなど、このページの詳細については、[End User Notifications] ページを参照してください。

      ステップ 2   [Notification Type] リストから編集する通知のタイプを選択します。
      ステップ 3   編集します。

      次に、通知メッセージを編集するためのヒントを示します。

      • 右ペインの上部のツールバーで、テキストのいくつかの特性を操作することができます。 テキストのインデントの管理に、Tab キー/Reverse Tab キーを使用することもできます。

      • フォーマットの作成後にソース・コードの表示を切り替えるため表示 HTML ソースの[<>]ボタンをクリックします。 場合によっては、可視化ソース・コードをより簡単に編集します。

      • 通知で表示される独自のロゴのイメージおよびアクション イメージをアップロードできます。 Web インターフェイスに、イメージのサイズとファイル タイプの制限について説明が表示されます。

      • 内部ヘルプまたはアクセプタブル ユース ポリシー ページへのリンクを構築するには、ハイパーテキスト リンク ボタンを使用します。

      • 拒否しているトラフィック フローに関するユーザの詳細情報を表示するには、変数を挿入します。 拒否はページ全体ではなく、ページの一部である可能性があるため、ユーザは、参照しているサイトが許可されないサイトから情報をプルしていることに気づかない場合があります。

      • 編集した内容がどのように表示されるかを確認するには、[Preview Draft] をクリックします。

      • 最初からやり直すには、[Restore Default] をクリックします。

      ステップ 4   [Save] をクリックします。 通知タイプごとに編集を保存する必要があります。

      追加のメッセージを編集するプロセスを繰り返します。


      エンド ユーザの通知のインポート

      事前定義された通知ページを編集する代わりに、独自のページを作成し、アプリケーションにインポートできます。 ページをインポートすることにより、エディタを使用して編集できるものより複雑なページを作成できます。

      インポートされたファイルは編集できません。 変更を加える必要がある場合は、元のファイルを編集し、再びインポートします。

      はじめる前に

      置き換える通知タイプごとに個別の HTML ページを作成します。 プレーン テキストをインポートできますが、アプリケーションは HTML を要求し、適切なマーク アップ タグを挿入しない場合は、良好な結果が得られない可能性があります。

      次に、通知ページの HTML ファイルを設定する方法に関するいくつかのヒントを示します。

      • ファイルには、<html> コンテナのタグを含む完全で有効な HTML マーク アップが含まれている必要があります。 適切なマーク アップを生成するために HTML エディタを使用することをお勧めします。 目的の表現が得られるように、インポートする前に、ブラウザでファイルをテストします。

      • 認証ページには、ユーザ名およびパスワードの入力ボックスがなければなりません。 次のコードが最小要件です:

        <form enctype="text/plain" method="POST" name="loginform" id="loginform">
        <input type="text" name="name" id="name"/>
        <input type="password" name="pass" id="pass"/>
        </form>
        
        
      • 必要な CSS スタイルはすべて HTML ファイルに直接挿入します。

      • <img> タグを使用して Web サーバに存在するイメージを参照できますが、ポリシーで一部のユーザがサーバにアクセスできないようにすることが可能です。 イメージを含み、すべてのユーザがイメージを常に使用できるようにする場合、イメージ用の Base-64 エンコーディングを生成し、次のマーク アップに挿入できます。 この例は、PNG グラフィックを想定していますが、イメージのメディア タイプの宣言を調整すると、ブラウザでサポートされる JPEG または他のグラフィック タイプを使用できます。

        <div 
           class="class_name" 
           style="background-image: url 
                 (data:image/png;base64,insert-string-here)">
        </div>
        
      手順
        ステップ 1   [Administration] > [End User Notification] を選択します。

        使用可能な通知タイプなど、このページの詳細については、[End User Notifications] ページを参照してください。

        ステップ 2   [Notification Type] リストからインポートする通知のタイプを選択します。
        ステップ 3   [Import] をクリックします。
        ステップ 4   [Import EUN File] ポップアップで、[Browse] をクリックして、HTML ファイルを選択します。
        ステップ 5   [Upload] をクリックします。

        ファイルに受け入れ可能なコンテンツが含まれている場合、アップロードおよび表示され、「Upload Successful」というメッセージがページの下部に表示されます。 [Preview Draft] をクリックすると、期待どおりにエンド ユーザに表示されることを確認できます。

        結果が受け入れられない場合、[Do Not Use Imported Version] クリックして事前定義されたページに戻ります。

        ファイルをアップロードできない場合は、ページの下部にエラー メッセージが表示されるはずです。 次に、一般的な問題を示します。

        • File not composed of valid text:ファイルの内容は HTML として認識されません。 たとえば、RTF ファイルを選択した可能性があります。 インポートを試行する前に HTML としてファイルを保存することを確認します。

        • Error:Invalid variable name {{var_name}}var_name は認識された変数名ではありません。 2 組の波カッコ内に表示されるテキストは認識された変数である必要があります。 メッセージは最初に見つかった不正な変数名について言及しますが、ファイル内には誤った変数が複数ある場合があります。 すべての変数名を修正して、もう一度試行します。


        エンド ユーザの通知の変数

        二重波カッコ内の任意のテキスト({{variable_name}} など)が、システム変数と見なされます。 変数は、エンド ユーザの通知メッセージがユーザに提供されたときに、フローの値と置き換えられます。 変数を使用すると、ユーザが、実行しているアクションの理由を理解し、説明をヘルプ デスクのスタッフに問い合わせたときに役立ちます。

        使用可能な変数は通知タイプによって異なります。 次の表で説明されているように、多くの変数はすべてのメッセージ タイプで使用できますが、1 つのタイプに制限されているものもあります。

        変数名が次の表に示す名前と一致しない場合、変数名ではなくスペースが表示されます。

        変数名

        説明

        通知タイプ

        application_behavior

        Tweet

        アプリケーションの動作。すべてのアプリケーションで使用可能ではありません。

        Application

        application_name

        Twitter

        アプリケーションの名前。

        Application

        application_tag

        クラウド

        アプリケーションに割り当てられているタグ。

        アプリケーション

        application_type

        Social Networking

        アプリケーションの一般的なタイプ。

        アプリケーション

        blocking_reason

        Application

        アクセスがブロックされた原因。

        All

        continue_url

        http://server.com? redirect= http://www.example.com /index/

        ユーザがリンクをクリックして続行する場合に使用する URL。

        Warning

        認証

        destination_ip

        10.100.10.10

        宛先サイトの IP アドレス。

        All

        destination_port

        80

        宛先サイトの TCP/UDP ポート。

        All

        file_type

        audio

        ファイル タイプのメディア、または MIME。

        File type

        flow_id

        384

        ファイアウォールによってトラフィック フローに付けられた ID。

        All

        full_url

        http://www.example.com /index/

        フル パスを含む宛先の URL。

        All

        source_ip

        10.100.10.10

        トラフィックの送信元 IP アドレス。

        All

        source_port

        80

        トラフィックの送信元 TCP/UDP ポート。

        All

        time

        02:50:55pm UTC

        トラフィック フローが発生した時刻。

        All

        threat_type

        Phishing

        低レピュテーション サイトに関連付けられている脅威のタイプ。 脅威のタイプが付けられるのは、レピュテーションが -6 以下の場合だけです。

        Web reputation

        uploads_or_downloads

        upload

        ファイル転送がアップロード(送信元から宛先へ)か、ダウンロード(宛先から送信元へ)か。

        File type

        web_category

        Social Networking

        宛先 URL が属する一般的な Web カテゴリ。

        URL filtering

        web_reputation

        -6.7

        宛先サイトの Web レピュテーション。-10(最低)~ 10(最高)。

        Web reputation

        URL フィルタリングとアプリケーション フィルタリング

        コンテキスト対応アクセス ルールにより、個々の URL または URL カテゴリをベースにしたネットワーク アクセスの制御(URL フィルタリングと呼ばれます)およびアプリケーション、アプリケーション タイプ、アプリケーションと従来のポート ベースのサービス仕様、さらには個々のアプリケーションのさまざまな動作をベースにしたネットワーク アクセスの制御(アプリケーション フィルタリングと呼ばれます)ができるようになります。 これらの機能を利用すると、禁止または許可しようとしているトラフィック、特にファイアウォールをブロックしないようにするポートを意図的に変更するトラフィックについての完全な特性を指定しなくても、ポリシーの定義と適用がより簡単に行えるようになります。

        URL フィルタリングとアプリケーション フィルタリングを使用して同様のポリシーを定義することはできますが、こうしたフィルタリングのタイプは同等ではありません。 たとえば、ゲーム関連の URL カテゴリを拒否するアクセス ルールを作成した場合、ゲーム関連のアプリケーション タイプを拒否するアクセス ルールを作成した場合と同じ結果は得られません。

        ここでは、URL フィルタリングとアプリケーション フィルタリングについてより詳細に説明します。

        URL フィルタリングとアプリケーション フィルタリングの比較

        URL フィルタリングとアプリケーション フィルタリングには 2 つの異なる目的があります。

        URL フィルタリング

        URL フィルタリングは、宛先サイトの URL をベースにしたトラフィックを拒否または許可し、HTTP または HTTPS トラフィックのみに対して機能します。

        URL フィルタリングの目的は、主に Web サイトへのアクセスを完全にブロックまたは許可することです。 個々のページをターゲットにすることができますが、通常はホスト名(www.example.com など)または特定のタイプのサービスを提供するホスト名の一覧を定義する URL カテゴリ(ギャンブルなど)を指定します。

        したがって、URL フィルタリング ルールはアプリケーションに幅広く普及しており、適用が容易であるため、トラフィックを許可または拒否するデバイスには遅延が発生しません。

        URL フィルタリングは、復号化ポリシーで使用することもでき、特定のタイプの復号化処理を受ける必要のあるトラフィック フローの識別に役立ちます。 たとえば、金融関連カテゴリをターゲットにして、[Do Not Decrypt] アクションを適用すると、一般的に信頼できるサイトへのトラフィックの復号化にデバイス リソースが消費されなくなります。 アプリケーション フィルタリングは復号化ポリシーでは使用できません。

        URL フィルタリングを設定するには、アクセス ポリシーまたは復号化ポリシーの [Destination] フィールドに URL オブジェクトを指定します。 URL オブジェクトは宛先オブジェクト グループに含めることもでき、そのポリシーでの宛先指定に使用できます。

        アプリケーション フィルタリング

        アプリケーション フィルタリングは、トラフィック フローの細かい特性に基づいてトラフィックを拒否または許可します。 一部のアプリケーションでは、たとえば Facebook へのアクセスは許可するが、写真の投稿はできないようにするなど、アプリケーションで可能な動作に基づいたさまざまなアクションを指定できます。 アプリケーション タイプおよびタグを使用して特定のアプリケーション、またはアプリケーションのグループに基づいてポリシーを作成できます。

        さらに、HTTP/HTTPS 以外の多くのトラフィック フローに対するアプリケーションとアプリケーション タイプがあります。 ICMP やさまざまなルーティング プロトコルなどの、TCP/UDP 以外のフローに対しても、アプリケーションとアプリケーション タイプがあります。 そのため、Web ブラウジングに関係のないトラフィック フローのアプリケーション レベルで、ポリシーを定義することができます。


        (注)  


        通常、HTTP または HTTPS 以外のプロトコルを使用するアプリケーションが認識されるためには、デフォルトのポートを使用している必要があります。


        アプリケーション タイプに含まれるアプリケーションには、同等の URL カテゴリに含まれるすべての同じ Web サイトが含まれるわけでも、それらだけが含まれるわけでもないことにも注意してください。

        トラフィック フローの開始時には、どのアプリケーションまたは動作がフローに含まれるかどうか明らかではないため、フローの内容に対する決定が行われるまでは、フローの一部が許可されることがあります。 拒否アクセス ポリシーは、フローの開始時ではなくフローの途中で適用されることがあります。

        HTTP/HTTPS トラフィック フローに対して、URL フィルタリングとアプリケーション フィルタリングのどちらを使用するかを決定する際は、その Web サイトに送信するすべてのトラフィックに適用するポリシーを作成するかどうかを考慮に入れてください。 このようにすべてのトラフィックを同じように処理する(トラフィックを拒否または許可する)場合は、URL フィルタリングを使用します。 トラフィックをサイトでブロックするか、許可するかを選択する場合は、アプリケーション フィルタリングを使用します。

        URL フィルタリングとアプリケーション フィルタリングには、専用のライセンスが必要であることにも注意してください。

        アプリケーションの制御

        Application Visibility and Control(AVC)エンジンは、トラフィックを検査し、トラフィック フローに関連付けられたアプリケーションを判別します。 たとえば、検査によって、Facebook と LinkedIn の区別をするなどの、HTTP トラフィック フローに転送される特定のアプリケーションを識別することができます。

        さまざまな Web ベースのアプリケーションがあるため、AVC では、すべての Web トラフィックに包括的なポリシーを適用したり、特定の Web サイトに関連付けられたアプリケーションを制御する URL フィルタリングを使用したりするのではなく、特定の Web ベースのアプリケーションを制御できるようにします。 アプリケーション制御によって、URL フィルタリングだけではなく、Web トラフィックを経由した細かな制御ができるようになります。

        AVC は、Web 以外のトラフィックも識別できるため、プロトコル/ポートに基づくポリシーではなく、アプリケーションに基づくポリシーを作成できます、 たとえば、TCP/179 サービスではなくボーダー ゲートウェイ プロトコル トラフィック用のアプリケーション ベースのポリシーを作成できます。 AVC エンジンを使用すると、各アプリケーションの基盤技術を完全に理解しなくても、ネットワーク上でのアプリケーション アクティビティを制御するポリシーを作成できます。

        アプリケーションに基づいてトラフィック フローを制御するには、[Application] フィールドで次の組み合わせを指定するコンテキスト対応アクセス ポリシーを作成します。
        • アプリケーション タイプ。関連するアプリケーションのグループの使用を制御します。 たとえば、AOL Instant Messenger、Google Talk、ICQ、および他の多くの IM アプリケーションをすべて同じように扱う場合、これらを処理するインスタント メッセージング アプリケーションのポリシーを記述します。 アプリケーションは、単一のモデルにマッピングされます。

        • アプリケーション タイプ。関連するアプリケーションのグループの使用を制御します。 タグは、タイプと比較してグループ化のレベルでさまざまなタイプのアプリケーションをグループ化できます。 たとえば、クラウド アプリケーションのポリシーを作成できます。 タイプとは異なり、アプリケーションは複数のタグにマッピングできます。 また、タグはタイプに類似します。 したがって、とタグに基づいたフィルタからゴールドことがわかります。

        • 特定のアプリケーションの使用を制御するアプリケーション。

        • アプリケーション・オブジェクトは、アプリケーションのポリシー オブジェクトで定義したアプリケーションの基準のみに基づくアプリケーションのグループを制御します。

        • ユーザーが定義する制御アプリケーションへのアプリケーション サービス オブジェクトは、プロトコルおよびポートを指定する従来のサービス グループ オブジェクトとアプリケーションの基準に基づいています。

        アプリケーション フィルタリング用の復号化要件

        アプリケーション情報が暗号化されたトラフィック フローで使用できる場合があります。 ただし、トラフィック フローが暗号化されていない場合に限り、多くの場合、トラフィック フローで使用されるアプリケーションまたは動作に影響する場合があります。 また、識別されたアプリケーションは、 Facebook、たとえば、可能性のある、ない Facebook ゲーム可能性がある程度に固有ではない。

        そのため、あるアプリケーションが通常 HTTPS(暗号化)を使用する場合、そのアプリケーションに対して記述したアクセス ポリシーは、アプリケーションのトラフィックを復号化するアクションを適用する復号化ポリシーとペアになります。

        たとえば、任意の送信元から任意の宛先へのアクセス ポリシーを記述し、暗号化を使用するアプリケーションを指定した場合、復号化ポリシーも任意の送信元と任意の宛先に適用する必要があります。そうしないと、アプリケーションが常に復号化されないことになり、そのアプリケーションが識別されない場合が発生します。

        アプリケーション フィルタリングのヒント

        アプリケーション基準を使用しているアクセス ポリシーにトラフィック一致基準を作成する場合、通常は目的のアプリケーションまたはアプリケーション タイプを選択するだけです。 選択は直接実行するか、再利用可能なアプリケーションまたはアプリケーション サービス オブジェクトを作成して実行します。

        ただし、期待どおりの結果を得るためのテクニックもあります。 次の表に、特定のアプリケーションにアプリケーション フィルタリングを使用する際のいくつかのヒントを示します。

        アプリケーション

        フィルタリング基準

        AOL Instant Messenger(AIM)

        すべての AIM トラフィックを対象にするには、[AOL Instant Messenger] と [AOL protocol] の 2 つのアプリケーションを選択する必要があります。

        (注)     

        AOL プロトコルは ICQ でも使用されるため、ICQ と AIM のどちらか一方を許可し、もう一方を拒否する場合は、AOL プロトコルを許可する必要があります。

        BitTorrent

        複数のアプリケーションが存在する BitTorrent に関連付ける。 特に BitTorrent の BitTorrentネットワーキング アプリケーションを扱う場合に 1 を受信しますが、別の deny 予想外の結果を取得できます。 BitTorrent または暗号化されたアプリケーションがあります。 ベスト・プラクティスは、これらのいずれかでポリシーを作成する場合は、これらのアプリケーションを選択します。 グループとしてそれらを許可または拒否します。

        ICMP

        Internet Control Message Protocol(ICMP)トラフィックを対象にするには多くの方法があります。
        • サービス オブジェクト:アプリケーション フィルタリングの代わりにサービス オブジェクトを使用できます。 事前定義済みの [protocol-icmp] または [protocol-icmp6] を使用してすべての ICMP トラフィック(IPv4 または IPv6)を対象とするか、([icmp-*] および [icmp6-*] という名前の)各 ICMP メッセージ タイプを対象とする事前定義済みオブジェクトがあります。 任意の組み合わせのメッセージ オブジェクトを定義するオブジェクトを作成することもできます。

        • アプリケーション:[internet control message protocol]、[internet control message protocol version 4]、[ipv6-icmp] などいくつかのアプリケーションがあります。 ただし、これらのアプリケーションは独自のアプリケーションを持ち、[ping] とは一致しません。 また、[ipv6-*] という名前の、他のメッセージ タイプに対するアプリケーションもありますが、すべてのメッセージ タイプに独自のアプリケーションがあるわけではありません。

        ICQ

        すべての ICQ(「I seek you」)トラフィックを対象にするには、[icq] と [AOL protocol] の 2 つのアプリケーションを選択する必要があります。

        (注)     

        AOL プロトコルは AIM でも使用できるため、ICQ と AIM のどちらか一方を許可し、もう一方を拒否する場合は、AOL プロトコルを許可する必要があります。

        eMule

        eMule トラフィックを対象にするには、[eDonkey] アプリケーションと [encrypted emule] アプリケーションを選択します。

        Application Viewer の使用

        Application Viewer の用途は次のとおりです。
        • アクセス コントロールとレポート作成で現在使用できるアプリケーションとアプリケーション タイプを探索します。

        • アプリケーション タイプ内に含まれるアプリケーションか、アプリケーションが属するタイプを判別します。

        • アプリケーションで使用できる制御可能な動作を判別します(ある場合)。

        • ポリシーまたはポリシー オブジェクト内のアプリケーションまたはアプリケーション タイプの現在の使用状況を表示します。

        • ユーザがアプリケーションを使用しようとした回数を示す、各アプリケーションのヒット数を表示します。 ヒット カウントは、アプリケーションの詳細ダッシュボードにリンクされます。

        • ユーザがそのタイプのアプリケーションを使用しようとした回数を示す、各アプリケーション タイプのヒット カウントを表示します。 カウントはタイプ内のすべてのアプリケーション ヒットの要約です。 ヒット カウントは、アプリケーション タイプの詳細のダッシュボードにリンクされます。


        ヒント


        ヒット カウントは現在ダッシュボードで選択されている時間範囲に基づいています。 時間範囲を確認するには、ヒット カウントの上にマウスを置きます。


        アプリケーション ビューアを開くには、[Components] > [Applications] を選択します。

        Application Viewer には次の項目が含まれます。
        • [I want to]:次のコマンドが含まれています。
          • [View by Application Types]:個々のアプリケーションではなく、リスト内のアプリケーション タイプを表示します。

          • [View by Application Names]:アプリケーション タイプではなく、リスト内の個々のアプリケーションを表示します。

          • [View New Applications]:過去 30 日以内に、アプリケーション シグニチャのダウンロードから追加されたアプリケーションを表示します。

        • [List of applications or application types]:各アプリケーションは、名前、説明、アプリケーション タイプ、動作、ポート、アプリケーションが追加された時期を示します。 リストをアプリケーション タイプ別に表示する場合、アプリケーションは、アプリケーション タイプ フォルダに編成されます。 フォルダを開くと、タイプ内に含まれているアプリケーションが表示されます。

          次の情報も確認できます。
          • アプリケーションまたはアプリケーション タイプのトラフィックが表示されている場合、ヒット カウントも表示されます。アプリケーションまたはアプリケーション タイプの詳細ダッシュボードを表示するには、ヒット カウントのリンクをクリックします。

          • アプリケーションまたはアプリケーション タイプがポリシーまたはポリシー オブジェクトで使用される場合、使用状況の要約がリストに表示されます。 項目の上にマウスを置き、[View Usage Details] コマンドをクリックすると、ポリシーおよびオブジェクトに関する詳細が表示されます。 また、切り捨てられて省略記号が付いているオブジェクトの詳細を表示するときも、このリンクをクリックします。

        URL フィルタリング

        URL フィルタリングにより、特定の HTTP 要求または HTTPS 要求の Web サーバ カテゴリをベースにしたユーザ アクセスを制御することができます。 たとえば、ギャンブル関連の Web サイトに対するすべての HTTP 要求をブロックしたり、Web ベースの電子メール Web サイトに対するすべての HTTPS 要求を復号化することができます。

        個々の URL ごとに、アクセスを許可またはブロックすることもできます。 たとえば、社内ネットワークにあるすべての Web サーバに対するアクセスを許可したり、まだカテゴリが決まっていない新しい Web サイトへのアクセスをブロックできます。

        URL フィルタリングを実装するには、次の手順を実行します。
        • カテゴリまたは個々の URL、または両方を定義し、同じように処理する URL オブジェクトを作成します。 オブジェクトのブロック リストにカテゴリまたは URL を含めると、許可リスト内のカテゴリまたは URL と一致するサイト以外を除外できます。 たとえば、ほとんどのゲームをブロックするためゲーム カテゴリ用の URL オブジェクトを作成し、アクセスを許可する特定のゲーム サイトの URL をいくつかブロック リストに含めると、そのサイトへのアクセスを許可できます。

        • (任意)。ネットワーク グループ オブジェクトと関連付けられた URL オブジェクトの、複雑な組み合わせを定義した宛先オブジェクトを作成し、ホストまたはネットワークの宛先 IP アドレスと、一致するアドレスを持つ URL またはサーバのカテゴリの組み合わせに基づいたアクセスを定義します。

        • 次のポリシーで URL オブジェクトまたは宛先オブジェクトを使用します。
          • アクセス。含まれる URL またはカテゴリに対するアクセスを許可またはブロックします。

          • 復号化。含まれる URL またはカテゴリに対する HTTPS アクセスが復号化されるかどうかを判別し、アプリケーションの内容や動作など、トラフィックの特性をさらに掘り下げて調査できるようにします。

        URL カテゴリ

        利用可能な URL カテゴリの説明を表示するには、選択 コンポーネント > 網フィルタリング カテゴリします。

        また、ビューの詳細をクリックして URL オブジェクトの選択リストにリンクするカテゴリの説明を表示できます。

        私は、 PSTN からフィルタリングの[Categories]ページのメニューに、次のアクションを実行できます。必要です:

        • 表示または再分類に URL を送信します :に検査するどのカテゴリが特定 URL が属するか。 これは目的のフィルタリングを実行する URL フィルタリング ポリシーを設計することができます。 分類に同意しない場合、再分類に推奨事項を送信できます。 このコマンドは、別の Cisco.com Web ページを開き、使用する Cisco.com のログインを持っていなければなりません。 詳細については、URL のカテゴリの判別を参照してください。

        • ネットワークのレピュテーション スコアを確認してください :Web サイトの評価を指示するため。 これは網レピュテーション フィルタリング ポリシーを設計することができます。 Web サイト(www.example.com)を入力して、スコア[Get]をクリックします。

        URL のカテゴリの判別

        URL カテゴリはルール作成の強力なツールです。 たとえば、ギャンブルが企業のアクセプタブル ユース ポリシーに適合しない場合、社内ネットワークでギャンブル関連サイトをブロックすることができます。 ギャンブル カテゴリを拒否するアクセス ルールを作成すると、ギャンブル Web サイトのすべてのアドレスの入力をしなくてもポリシーが実装されます。ギャンブル関連サイトの可能性があるすべてのアドレスを判別するために、時間を使ってインターネットを細かく調べる必要もありません。

        ただし、許容されるサイトが属する URL カテゴリを誤ってブロックしてしまい、そのサイトへのトラフィックをブロックしてはいけません。

        そのため、サイトへのトラフィックに影響する可能性のあるルールを定義する前に、サイトの Web カテゴリを判別することができます。 サイトがブロック対象のカテゴリに属していると判断すると、許容されるサイトを他の好ましくないカテゴリが含まれた URL オブジェクト内のブロック リストに追加する可能性があります。

        Web サイトの URL カテゴリを判別するには、次の方法のいずれかを使用できます。
        • そのサイトへのトラフィックがすでに を通過している場合、ダッシュボードまたは Event Viewer でサイトを見つけることができます。
          • ダッシュボード:Web 宛先ダッシュボードから Web サイトを検索します。 サイトをクリックすると、宛先の詳細ダッシュボードが表示されます。 先頭の宛先グループには、URL カテゴリとアプリケーションおよびアプリケーション タイプが表示されます。

          • Event Viewer:その Web サイトを宛先としているイベントを検索します。 たとえば、リアルタイムにイベントを検索しているときに、トラフィックがデバイスを通過しているワークステーションから Web サイトを開きます。 イベントの詳細に URL カテゴリが含まれます。

        • サイトのカテゴリを検索するには次の手順を使用します。特に、サイトがマルウェアをホスティングしている、または好ましくない(サイトを直接開きたくない)と確信するだけの確実な理由がある場合に、この手順が有効です。 アクセスするには、Cisco.com のアカウントが必要です。
          1. Web ブラウザで次の URL を開きます。https:/​/​securityhub.cisco.com/​web/​submit_​urls に直接アクセスすることも、取り外す コンポーネント > 網フィルタリング カテゴリことから、表示またはサイトを開いて Recategorization > の URL を送信してもよろしい[i]を選択します。 すでにログインしていない場合は、 Cisco.com にログインするように促されます。

          2. [Lookup] タブまたは [Submit URLs] タブで、[Lookup] ボックスの [URLs] に URL を入力します。 一度に複数の URL を入力できます。

          3. [ASA CX] を選択します。

          4. [Lookup] をクリックします。

            検索が成功すると、入力した URL と関連する URL カテゴリが表示されます。 カテゴリがない場合は URL は未分類のまま表示されます。 このカテゴリに同意しない場合、または未分類の URL について提案がある場合は、適切であると思われるカテゴリを選択し、[Submit] をクリックしてカテゴリの変更を要求します。 この要求は [Submitted URLs] タブの [Status] でトラッキングできます。

        Web レピュテーション フィルタリング(マルウェア防止)

        ユーザは常に、インターネット サイトからマルウェアを取得するリスクにさらされています。 信頼されるサイトでも、ハイジャックされて、無警戒なユーザにマルウェアを配布することがあります。 下に示すように、Web ページには、別の送信元からのオブジェクトを含めることができます。 このオブジェクトには、イメージ、実行可能ファイル、Javascript、広告などがあります。 改ざんされた Web サイトには、しばしば、外部の送信元でホストされているオブジェクトが組み込まれます。 真のセキュリティとは、最初の要求だけではなく、各オブジェクトを個別に調べることです。





        Cisco Threat Operations Center は、動的な更新と、ASA、IPS、電子メール セキュリティ アプライアンス、Web セキュリティ アプライアンス、およびシステム管理者から取得したアクション可能な知識を使用して、Web サイトの Web レピュテーション スコアを計算します。 Web レピュテーションは、コンテキストおよび過去の動作に基づいた統計的な評価で、重要度が異なる多くの要素を組み合わせて 1 つの関連付けられたメトリックにするものです。 個人の信用スコアと同様に、Web レピュテーションは、-10 ~ 10 の段階的なスケールに沿った連続値です。 低レピュテーション ゾーンを定義することで、ユーザにマルウェアを提供する可能性が高い、低レピュテーション サイトに対して予防的なゼロデイ保護を実装できます。

        次のトピックで、Web レピュテーション フィルタリングを実装する方法について説明します。

        Web レピュテーション スコアのためのガイド

        以下は、Web レピュテーション スコアの一般的なガイドラインです。

        -10 ~ -6

        レピュテーションが最も低いゾーンのサイトは、継続的にキー ロガー、ルートキット、およびその他のマルウェアを配布する専用サイト、またはハイジャックされたサイトです。 フィッシング サイト、ボット、ドライブバイ インストーラも含まれます。 このレピュテーション範囲のサイトは、ほぼ確実に悪意のあるサイトです。

        事前定義されているデフォルトの Web レピュテーション プロファイルで、このゾーンは低レピュテーション ゾーンとして定義されています。

        -6 ~ -3

        このゾーンのサイトは、攻撃的な広告シンジケートおよびユーザ トラッキング ネットワークの可能性があります。 これらのサイトは、悪意がある疑いがありますが、確実ではありません。

        -3 ~ 3

        このゾーンのサイトは、管理された信頼できるコンテンツ シンジケート ネットワークおよびユーザが生成したコンテンツ サイトの可能性があります。

        0 ~ 5

        このゾーンのサイトは、信頼できる動作の歴史がある、または第三者の検証を受けたサイトです。

        5 ~ 10

        このゾーンのサイトは、信頼できる動作の長い歴史があり、トラフィック量が多く、広くアクセスされているサイトです。


        ヒント


        [ コンポーネント > 網フィルタリング カテゴリサイトの評判を調べると、ネットワークのレピュテーション スコアを確認し > たい[i]を選択します。


        Web レピュテーション フィルタリングの設定

        レピュテーション ベースの処理を実装するには、次のタイプのポリシーに Web レピュテーション プロファイルを適用します。
        • トラフィックを許可するアクセス ポリシー。 Web レピュテーション プロファイルを追加することで、一致するトラフィックは全般的に許可され、低レピュテーション サイトからのトラフィックはすべてドロップされます。 [Allow] アクションがあるアクセス ポリシーの一部またはすべてにプロファイルを適用できます。

        • アクションが [Decrypt Potentially Malicious Traffic] の復号化ポリシー。 Web レピュテーション プロファイルを追加することで、ポリシーと一致する低レピュテーション サイトが復号化され、アクセス ポリシーによってトラフィックの内容が認識されます。 その後、設定に従って、アクセス ポリシーでトラフィックをドロップできます。 トラフィックをドロップする、一致するアクセス ポリシーがなくても、低レピュテーション トラフィックを復号化することで、暗号化された TLS/SSL トラフィック フローでは利用できなかったデータがレポートに提供されます。

        アクセス ポリシーに対して、デバイス レベルのプロファイルを設定し、ポリシーにそのプロファイルを使用させることができます。 次に、[Malware Protection][Malware Protection]設定を編集して、デフォルトのフィルタリング ポリシーを簡単に変更できます。

        Web レピュテーション フィルタリングを実装するには、Web Security Essentials ライセンスが必要です。

        手順
          ステップ 1   [Components] > [Objects] を選択し、フィルタリング ポリシーを実装するために必要な Web レピュテーション プロファイルを作成します。

          デフォルトの Web レピュテーション プロファイル オブジェクトがあります。 このオブジェクトが要件を満たせば、独自のオブジェクトを作成する必要はありません。 それ以外の場合は、[I want to] > [Add Web Reputation Profile] を選択し、オブジェクトを作成します。 ブロックされる(拒否される)低レピュテーション ゾーン、および許可される高レピュテーション ゾーンを決定するために、スライダを調整します。

          サイトのレピュテーション スコアは時間の経過とともに変化することがあるので、相対的な危険アセスメントが変化するにつれて、サイトがゾーン間を移動することがあることに注意してください。

          [ コンポーネント > 網フィルタリング カテゴリサイトの評判を調べると、ネットワークのレピュテーション スコアを確認し > たい[i]を選択します。

          ステップ 2   Configurations > Policies/Settings を選択し、[Malware Protection][Malware Protection]タブを開き、Web レピュテーション フィルタリングをイネーブルにし、デバイスレベルのプロファイルを選択します。

          デバイスレベルのプロファイルは、デバイスレベルのプロファイルを使用するように設定されたアクセス ポリシーに一致するすべてのトラフィックに適用されます。 デフォルトの Web レピュテーション フィルタリング フィルタリング ポリシーを定義するには、オプションを使用します。

          (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

          ステップ 3   目的のプロファイルを適用するアクセス ポリシーを編集します。

          Web レピュテーション フィルタリング プロファイルを適用するアクセス ポリシーごとに、ポリシーを編集し、適切なプロファイルを選択します。 デバイスレベルのプロファイルを使用するには、[Device Level Profile (name)] を選択します。設定されたプロファイルの名前がオプションに表示されます。 プロファイルを選択しない場合(またはデバイスレベルのプロファイルが「none」の場合)、Web レピュテーション フィルタリングは一致するトラフィックに適用されません。 Web レピュテーション プロファイルは、[Policy Objects] ページで作成するか、またはアクセス ポリシーの編集中に作成することができます。

          ステップ 4   暗号化されたトラフィックを複合化する基準としてレピュテーションを使用する場合は、復号化ポリシーを設定します。

          復号ポリシーのアクションとして [Decrypt Potentially Malicious Traffic] を選択した場合、低レピュテーション ゾーンを設計するために Web レピュテーション プロファイルを選択します。 そのゾーンのサイトは復号化されますが、高ゾーンのサイトは復号化されません。

          ステップ 5   結果を監視します。
          • [Dashboard] > [Malware Traffic] を選択します。
          • [Events] > [Events] を選択し、コンテキスト対応セキュリティまたは暗号化トラフィックのビューを選択します。

          マルウェア防止(Web レピュテーション)設定の指定

          デバイスレベルの Web レピュテーション プロファイルを設定し、CX コンテキスト対応アクセス ポリシーに適用できます。 デバイスレベルのプロファイルを設定することによって、ポリシー全体に均一なレピュテーション フィルタリングを簡単に適用し、デバイス レベルのプロファイルを単に交換するか、または編集することによって、すばやく設定を変更できます。

          Web レピュテーション フィルタリングはデフォルトでイネーブルですが、これらの設定でオフにすることができます。


          (注)  


          Web レピュテーション設定はレピュテーションベースの復号化ではオプションではないため、ここで設定されたデバイス レベルのプロファイルを使用するように復号化ポリシーを設定できません。 プロファイルを必要とする各復号ポリシーにプロファイルを明示的に選択する必要があります。


          手順
            ステップ 1   Configurations > Policies/Settings を選択し、[Malware Protection][Malware Protection]タブを開きます。

            (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

            ステップ 2   [Malware Protection: On] を選択して、Web レピュテーション フィルタリングをイネーブルにします。

            この設定を変更する場合、変更をコミットしたときにフィルタリングがイネーブルまたはディセーブルになります。 ただし、この変更は新しいトラフィック フローに適用されます。既存のトラフィック フローは、前の設定に基づいて引き続きフィルタリングされるか、またはフィルタリングされないままです。

            サービスを有効にするには、Web Security Essentials ライセンスが必要です。

            ステップ 3   [Web Reputation Profile] でデバイスレベルの Web レピュテーション プロファイル オブジェクトを選択します。

            システム定義の [Default web reputation profile] は推奨されるフィルタリングを実装しますが、[Create New Profile] を選択して独自に作成するか、すでに定義されている他のプロファイルを選択することができます。

            アクセス ポリシーで [Device Level Profile (name)] を指定した場合、ここに定義されたプロファイルが一致するトラフィックに使用されます。

            デバイスレベルのプロファイルを空のままにした場合は、Web レピュテーション フィルタリングはそれを使用するように設定されたアクセス ポリシーで無効になります。

            ステップ 4   [Save] をクリックします。

            Next Generation IPS フィルタリング

            Next Generation IPS(侵入防御システム)フィルタリングは、トラフィックの内容を既知の脅威に対して比較して、リアル タイムでネットワーク トラフィックを分析します。 接続が脅威に一致した場合は、脅威をブロックする接続をドロップできます。 問題のないと決定した脅威を、モニタするが許可すること、または完全に無視することを選択することもできます。

            Cisco Security Intelligence Operations(SIO)は、脅威を識別するシグニチャを開発します。 複数のシグニチャを 1 つの脅威にマッピングできます。 更新をディセーブルにしない限り、新しいシグニチャ セットが定期的にダウンロードされます。 また、常に危険と見なされるサイトである、ブラック リストに登録されているサイトの自動ブロッキングを実装できます。

            次のトピックで、Next Generation IPS フィルタリングを実装する方法について説明します。

            Next Generation IPS フィルタリングの設定

            Next Generation IPS フィルタリングのデバイスレベルおよびアクセスごとのポリシー設定を行うことができます。

            フィルタリングを有効にするには、Next Generation IPS ライセンスが必要です。

            手順
              ステップ 1   [Components] > [Objects] を選択し、フィルタリング ポリシーを実装するために必要な NG IPS プロファイルを作成します。

              デフォルトの NG IPS プロファイル オブジェクトがあります。 このオブジェクトが要件を満たせば、独自のオブジェクトを作成する必要はありません。 それ以外の場合は、[I want to] > [Add NG IPS Profile] を選択し、オブジェクトを作成します。 ブロックする(拒否する)ゾーン、許可およびモニタする(アラートする、つまり、イベントを生成する)ゾーン、および許可するがモニタしない(無視する、つまり、イベントを生成しない)ゾーンを決定するためにスライダを調整します。 ゾーンに分類されますが、別の方法で処理したい特定の脅威がある場合は、これらのゾーンに例外を設定することもできます。

              脅威のスコアは時間の経過とともに変化することがあるので、相対的な危険アセスメントが変化するにつれて、脅威がゾーン間を移動することがあることに注意してください。

              [Components] > [Threats] を選択すると、さまざまな脅威の説明を表示できます。

              ステップ 2   Configurations > Policies/Settings を選択し、[Threat Protection][Intrusion Prevention]タブを開き、Next Generation IPS フィルタリングをイネーブルにし、デバイスレベルのプロファイルを選択し、その他の設定を行います。

              デバイスレベルのプロファイルは、デバイスレベルのプロファイルを使用するように設定されたアクセス ポリシーに一致するすべてのトラフィックに適用されます。 デフォルトの Next Generation IPS フィルタリング ポリシーを定義するには、オプションを使用します。

              (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

              ステップ 3   目的のプロファイルを適用するアクセス ポリシーを編集します。

              Next Generation IPS フィルタリング プロファイルを適用するアクセス ポリシーごとに、ポリシーを編集し、適切な NG IPS プロファイルを選択します。 デバイスレベルのプロファイルを使用するには、[Device Level Profile (name)] を選択します。設定されたプロファイルの名前がオプションに表示されます。 プロファイルを選択しない場合(またはデバイスレベルのプロファイルが 「none」 の場合)、Next Generation IPS フィルタリングは一致するトラフィックに適用されません。 NG IPS プロファイルは、[Policy Objects] ページで作成するか、またはアクセス ポリシーの編集中に作成することができます。

              ステップ 4   暗号化されたトラフィック用の最も効果Next Generation IPS的なフィルタリングが必要な場合は復号化ポリシーを設定します。 場合によっては、Next Generation IPSフィルタにかけてからは、暗号化されたトラフィックの脅威を認識できます。 ただし、その他の場合には、トラフィックが識別される脅威を復号化します。 したがって、復号化がフィルタに、Next Generation IPS必須ではありません。
              ステップ 5   結果を監視します。
              • [Dashboard] > [NG Intrusion Prevention] を選択します。
              • [Events] > [Events] を選択し、NG IPS ビューを選択します。

              侵入防御設定の指定

              サービスをイネーブルにし、デバイスレベルのフィルタリング プロファイルを定義し、他の高度なオプションを設定するには、Next Generation IPS 設定を使用します。

              手順
                ステップ 1   Configurations > Policies/Settings を選択し、[Threat Protection][Intrusion Prevention]タブを開きます。

                (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

                ステップ 2   [Intrusion Prevention: On] を選択して、Next Generation IPS フィルタリングをイネーブルにします。

                この設定を変更する場合、変更をコミットしたときにフィルタリングがイネーブルまたはディセーブルになります。 ただし、この変更は新しいトラフィック フローに適用されます。既存のトラフィック フローは、前の設定に基づいて引き続きフィルタリングされるか、またはフィルタリングされないままです。

                サービスを有効にするには、Next Generation IPS ライセンスが必要です。

                ステップ 3   [NG IPS Profile] でデバイスレベル NG IPS プロファイル オブジェクトを選択します。

                システム定義の [Default NG IPS profile] は推奨されるフィルタリングを実装しますが、[Create New Profile] を選択して独自に作成するか、すでに定義されている他のプロファイルを選択することができます。

                アクセス ポリシーで [Device Level Profile (name)] を指定した場合、ここに定義されたプロファイルが一致するトラフィックに使用されます。

                デバイスレベルのプロファイルを空のままにした場合は、Next Generation IPS フィルタリングはそれを使用するように設定されたアクセス ポリシーで無効になります。

                ステップ 4   必要に応じて、次の高度な設定を行います。
                • [Scan High Reputation Traffic : On/Off]:低リスク、つまり、バイパスされるに値すると定義されている、高レピュテーション サイトへのトラフィック フローの Next Generation IPS フィルタリングを実行するかどうか。 Next Generation IPS は特定タイプのトラフィックを、脅威を含む可能性が非常に低いと識別でき、Web レピュテーションはこの識別の一部になることができます。 レピュテーション スコアは WBRS のダウンロードで定期的に更新され、これらのダウンロードが行われるにはアクティブな Web Security Essentials ライセンスが必要であることに注意してください。そうしない場合は、この評価で使用されるレピュテーション スコアが古くなります。
                • [Block Blacklisted Traffic: On/Off]:エンジンとシグニチャの更新によって定期的にダウンロードされるブラックリストのサイトをブロックするかどうか。 これらのサイトは、とても脅威的とみなされるので、それらに対するすべてのトラフィックは危険です。 リストの実際のサイトは、更新が行われるたびに変更されます。 このオプションをイネーブルにした場合、ブラック リストに登録されているトラフィック フローは、他のアクセス ポリシーが考慮される前にブロックされます。
                • [Blacklisted Traffic Eventing: On/Off]:ブラックリストに登録されているサイトに関係しているトラフィックがドロップされたときにイベントを生成するかどうか。 これをオフにすると、ブラックリストに登録されているフローがサイレントにドロップされます。 イベンティングをイネーブルにした場合、ドロップされたトラフィックは [Flow Deny] イベントを生成します。そのイベントでのポリシー名は、ブラック リスト サイトがトラフィックの送信元か、宛先かによって Blacklist(Source)または Blacklist(Destination)になります。
                ステップ 5   [Save] をクリックします。

                Next Generation IPS 脅威の表示

                システムで使用可能な脅威の説明を表示できます。

                [Components] > [Threats] を選択してリストを表示します。

                長い説明が切り捨てられた脅威については、脅威の上にマウスを置き、[Read More] をクリックします。 [Go to Information Site] リンクをクリックして、外部ソースから追加詳細を探します。リンクが新しいウィンドウで開きます。

                シグニチャおよびエンジン更新の設定

                アプリケーションおよびアプリケーション タイプ、URL カテゴリおよび Web レピュテーションはシグニチャによって定義され、セキュリティ アプリケーション スキャナ(SAS)エンジンによって適用されます。 Next Generation IPS には、シグネチャおよびエンジン パッケージも含まれています。 これらのコンポーネントのアップデートはアップデート サーバで使用できるようになります。 これらの更新を取得する期間と HTTP プロキシを設定できます。

                更新設定を変更しなかった場合、デバイスは更新サーバを常時 5 分間隔でチェックし、更新が見つかった場合はダウンロードします。 更新によって次の設定が変更されます。
                • 新しい URL カテゴリ、アプリケーション、アプリケーションの動作、アプリケーション タイプまたはタグ、またはNext Generation IPS脅威。

                • ある URL カテゴリへの変更、アプリケーション、属性、または脅威Next Generation IPS。 既存の項目は、名前が変更されたり、削除されることがあります。 複数の項目が結合されることがあります。あるいは、1 つの項目が 1 つ以上の項目に分割されることがあります。

                  • 項目の名前が単純に変更されると、この項目を使用するすべてのポリシーに新しい名前が表示され、ポリシーは予想どおりに引き続き動作します。

                  • 項目が削除、分割または結合された場合、項目はサポートされていないことを示すエラー メッセージに置き換えられます。 その項目と一致するトラフィックはなくなります。 影響を受ける個々のポリシーを編集して、適切に置き換える必要があります。

                • URL カテゴリ内に含まれる URL の変更。

                • Web サイトの Web レピュテーションの変更。

                アプリケーションまたは Web サイトの分類方法が変更されると、アプリケーションのトラフィック、または Web サイトへのトラフィックが、既存のポリシーに基づいてどのように処理されるかが変わることがあります。 たとえば、ブロックしているカテゴリに新しいサイトを追加し、更新以前はそのサイトへのトラフィックが許可されていた場合、ユーザは更新後にトラフィックがブロックされることに突然気付きます。

                ポリシーを記述したアプリケーションに新しい動作が追加されると、その新しい動作は初期状態で許可されます。 この動作を拒否するには、該当するポリシーを編集する必要があります。 Application Viewer を使用すると、過去 30 日以内に追加された新しいアプリケーションが表示され、新しいアクセス ポリシーが予想どおり機能しているかどうかを識別できます。 アプリケーション ビューアを開くには、[Components] > [Applications] を選択します。


                ヒント


                プロキシを PRSM マルチ デバイス モードで定義すると、同じプロキシが管理対象のすべての CX デバイスで使用されます。 管理対象デバイスとプロキシの地理的位置関係に問題がないことを確認してください。 管理対象のすべてのデバイスに同じプロキシを使用できない場合は、複数の PRSM サーバを使用して、同じプロキシを使用できるデバイスのグループを管理します。 あるいは、個々のデバイスの管理ネットワーク用ファイアウォール ルールを、インターネットへのアクセスを許可するよう変更し、プロキシを不要にします。


                手順
                  ステップ 1   [Configurations] > [Updates] を選択します。

                  [Updates]ページが更新できる最新のアップデートと構成のバージョンの日時などのさまざまなコンポーネントを示します。 PRSM マルチ デバイス モードでは、PRSM 用と、管理対象の個々の CX デバイス用に別々のリストがあり、システム中のコンポーネントのバージョンを比較することができます。 メッセージが更新に失敗したことがあるかどうかを示します。

                  コンポーネントは次を含む:
                  • アプリケーションの表示およびコントロールの署名:これらのシグニチャは、ポリシーを設定できる属性とアプリケーションを定義します。

                  • ネットワーク参加エンジン:このクライアントは、分析のために Cisco ネットワーク参加を選択した場合、攻撃、および使用率データ収集を返送します。

                  • 次世代 IPS コンポーネント:これらのコンポーネントはフィルタ的な脅威にNext Generation IPS使用され、脅威のシグニチャ エンジン トラフィックを評価する、高脅威のサイトのブラックリストにある、基本評価のドロップダウン リストの個々のコンポーネントが含まれます。

                  • ルート CA 証明書:復号化の処理に使用される独自の信頼できるルート CA 証明書のリスト。

                  • セキュリティ スキャナ アプリケーション エンジン:このエンジンは、宛先に関連づけられたアプリケーション、網カテゴリ、またはネットワークの評価を設定するためにトラフィックを評価します。

                  • WSE (Network Security Essentials)コンポーネント:これらのコンポーネントは、 URL および網レピュテーション フィルタリングで使用され、レピュテーション評価、 URL カテゴリ、網レピュテーション URL カテゴリおよび網レピュテーション評価をサポートするルールおよびデータをサポートするための IPv4 データのための別個のコンポーネントが含まれます。

                  ステップ 2   更新頻度を変更する場合は、[Edit]をクリックし、頻繁に更新をダウンロードする方法の選択:
                  • 5 分ごとに検査します。 :アップデート サーバは 5 分ごとに 7 時間の検査されます。 これはデフォルトです。

                  • ウィンドウ内に 5 分ごとに検査します。 :アップデート サーバは許可期間にのみ検査されるデータです。 ボックスをクリックし、開始時刻と終了時刻を選択します。この時刻は 15 分刻みになっています。 たとえば、「From 12:00 AM to 04:00 AM」と選択すると、更新をトラフィック量の少ない早朝に限定することができます。 時間枠は 1 日の中に制限されます。 午前を挟みます時間枠を指定できません。

                  • は更新しません。 :アップデート サーバは検査しますが、更新はダウンロードされません。 この設定は一時的に使用するか、機能ライセンスを購入しない場合に使用します。

                  ステップ 3   HTTP プロキシを使用する必要があり、すでにイネーブルにされていません。設定されていない場合は、プロキシ情報の編集]をクリックし、に入力します。

                  より多くの情報のプロキシのウィンドウで[Help]をクリックします。


                  次の作業

                  • イベント ビューアを使用すると、更新に関連したシステム イベントを確認できます。 [System Events] ビューでアップデータ接続イベントがあるかどうか確認します。

                  • Application Viewer を使用すると、過去 30 日以内にインストールされた新しいアプリケーションを確認できます。

                  • 新しい項目を使用するようにポリシーを設定します。

                  • ダッシュボードを表示して、新しい項目の統計情報を表示します。 新しい項目は、システムを通過するすべてのトラフィックが一致すると想定して、ダッシュボードですぐに使用できます。

                  シグニチャとエンジン更新のトラブルシューティング

                  Event Viewer を使用すると、更新に関連したシステム イベントを確認できます。 [System Events] ビューでアップデータ接続イベントがあるかどうか確認します。

                  以下は発生する可能性のある一般的な問題の一部です。
                  • シグニチャまたはエンジン更新に関連付けられたサービスのアクティブなライセンスがシステムにある場合のみ、更新が行われます。 使用している機能に適切なライセンスがあることを確認します。

                  • 更新はシステムにインターネットへのルートがあり、シスコの更新サーバに到達できる場合にのみ行われます。 管理インターフェイスの接続先ネットワークにインターネットへのルートを確立するか、アップデータに HTTP プロキシ サーバを設定するという、2 つの選択肢があります。

                  • PRSM マルチ デバイス モードを使用する場合、CX デバイスと PRSM サーバの両方が更新をダウンロードすることに注意してください。

                    • PRSM サーバよりも新しいバージョンを持つデバイスをインポートすると、インポートされたアクセス ポリシーに、PRSM で使用できないアプリケーションの仕様を含む「(Unrecognized application)」が表示されることがあります。 これらのポリシーは正しく配置され、シグニチャが更新されるとすぐに、PRSM で適切なアプリケーション名が表示されます。

                    • PRSM サーバに最新の更新がある場合、シグニチャで定義されなくなったアプリケーションは、ポリシーで名前に「(deprecated)」が付加されます。 ただし、これらのアプリケーション名はダッシュボードやレポートにこの指定なしで表示されます。 廃止されたアプリケーソンを指定するポリシーをプロアクティブに定義する必要があります。

                  • プロキシを PRSM マルチ デバイス モードで定義すると、同じプロキシが管理対象のすべての CX デバイスで使用されます。 管理対象デバイスとプロキシの地理的位置関係に問題がないことを確認してください。 管理対象のすべてのデバイスに同じプロキシを使用できない場合は、複数の PRSM サーバを使用して、同じプロキシを使用できるデバイスのグループを管理します。 あるいは、個々の CX デバイスの管理ネットワーク用ファイアウォール ルールを、インターネットへのアクセスを許可するよう変更し、プロキシを不要にします。

                  • シグニチャは、関連するエンジンが必要なバージョンになっていなければ、アップロードされません。 新しいエンジンがインストールされると、このエンジンを必要とする新しいシグニチャ ファイルがインストールされます。

                  • システムは誤った更新を正しく識別し、その更新を削除して、前の正しいバージョンに戻ります。ユーザの介入は不要です。 最後に認識された正しいバージョンは、リカバリ用として必ず保存されます。