Cisco クラウド Web セキュリティに関する情報
ASA でクラウド Web セキュリティを有効にすると、ASA は、サービス ポリシー ルールに基づいて、選択された HTTP および HTTPS トラフィックをクラウド Web セキュリティ プロキシ サーバに透過的にリダイレクトします。クラウド Web セキュリティ プロキシ サーバは、コンテンツをスキャンし、Cisco ScanCenter で設定されたポリシーに基づいてトラフィックに関する警告を許可、ブロックまたは送信します。これにより許容範囲での使用をユーザに促し、マルウェアから保護します。
ASA では、アイデンティティ ファイアウォールおよび AAA ルールによりユーザを認証および識別させることもできます(オプション)。ASA は、ユーザ クレデンシャル(ユーザ名およびユーザ グループを含む)を暗号化して、クラウド Web セキュリティにリダイレクトするトラフィックに含めます。クラウド Web セキュリティ サービスは、このユーザ クレデンシャルを使用して、ポリシーとトラフィックを照合します。また、ユーザベースのレポーティングでもこのクレデンシャルを使用します。ASA は、ユーザ認証を行わずに(オプションの)デフォルトのユーザ名およびグループを指定できます。ただし、クラウド Web セキュリティ サービスがポリシーを適用するために、ユーザ名とグループは必要ありません。
サービス ポリシー ルールを作成するときに、クラウド Web セキュリティに送信するトラフィックをカスタマイズできます。また、サービス ポリシー ルールに一致する Web トラフィックのサブセットが最初に要求された Web サーバに代わりに直接移動し、クラウド Web セキュリティにスキャンされないように、「ホワイトリスト」を設定できます。
プライマリおよびバックアップのクラウド Web セキュリティ プロキシ サーバを設定できます。ASA は各サーバを定期的にポーリングして、可用性を確認します。
ユーザ アイデンティティおよびクラウド Web セキュリティ
ユーザ アイデンティティを使用して、クラウド Web セキュリティでポリシーを適用できます。また、ユーザ アイデンティティは、クラウド Web セキュリティ レポーティングにも役立ちます。クラウド Web セキュリティを使用するには、ユーザ アイデンティティは必要はありません。クラウド Web セキュリティ ポリシーのトラフィックを識別する他の方法があります。
ユーザのアイデンティティを決定したり、デフォルト アイデンティティを提供したりする次の方法をサポートします。
-
アイデンティティ ファイアウォール:ASA が Active Directory(AD)でアイデンティティ ファイアウォールを使用すると、AD エージェントからユーザ名とグループが取得されます。アクセス ルールなどの機能またはサービス ポリシーで ACL のユーザおよびグループを使用するか、ユーザ アイデンティティ モニタを設定してユーザ アイデンティティ情報を直接ダウンロードしたときに、ユーザ名およびグループが取得されます。
-
AAA ルール:ASA が AAA ルールを使用してユーザ認証を実行すると、ユーザ名が AAA サーバまたはローカル データベースから取得されます。AAA ルールによるアイデンティティには、グループ情報が含まれていません。デフォルト グループを設定すると、これらのユーザがそのデフォルト グループに関連付けられます。AAA ルールの設定については、レガシー機能ガイドを参照してください。
-
デフォルトのユーザ名とグループ:関連付けられたユーザ名またはグループがないトラフィックの場合、オプションのデフォルトのユーザ名およびグループ名を設定できます。これらのデフォルトは、クラウド Web セキュリティのサービス ポリシー ルールに一致するすべてのユーザに適用されます。
認証キー
各 ASA は、クラウド Web セキュリティから取得した認証キーを使用する必要があります。認証キーを使用して、クラウド Web セキュリティは、Web 要求に関連付けられた会社を識別し、ASA が有効なカスタマーに関連付けられていることを確認できます。
ASA では、2 つの認証キー(企業キーおよびグループ キー)のいずれか 1 つを使用できます。
-
企業認証キー:同じ企業内の複数の ASA で企業認証キーを使用できます。このキーは、単に ASA のクラウド Web セキュリティ サービスを有効にします。
-
グループ認証キー:グループ認証キーは 2 つの機能を実行する各 ASA に固有の特別なキーです。
-
1 つの ASA のクラウド Web セキュリティ サービスを有効にします。
-
ASA からのすべてのトラフィックが識別されるため、ASA ごとに ScanCenter ポリシーを作成できます。
-
ScanCenter(https://scancenter.scansafe.com/portal/admin/login.jsp)でこれらのキーを生成します。詳細については、次の URL にあるクラウド Web セキュリティのマニュアルを参照してください。
ScanCenter ポリシー
ScanCenter では、トラフィックは、ルールに一致するまで順にルールに照合されます。その後、クラウド Web セキュリティがルールの設定済みのアクションを適用し、トラフィックを許可またはブロックしたり、ユーザに警告したりします。警告では、Web サイトに進むオプションがあります。
ASA ではなく、ScanCenter で URL フィルタリング ポリシーを設定します。
ただし、ポリシーの一部は、ポリシーが適用されるユーザに対するものです。ユーザ トラフィックはグループの関連付け(ディレクトリ グループまたはカスタム グループ)に基づいて ScanCenter ポリシー ルールと照合できます。グループ情報が ASA からリダイレクトされた要求に含まれているため、ASA から取得する可能性があるグループ情報の内容を理解する必要があります。
ディレクトリ グループ
ディレクトリ グループはトラフィックが属するグループを定義します。アイデンティティ ファイアウォールを使用する際、グループが存在する場合、グループはクライアントの HTTP 要求に含まれています。アイデンティティ ファイアウォールを使用しない場合は、クラウド Web セキュリティ インスペクションの ASA ルールに一致するトラフィックのデフォルト グループを設定できます。
ScanCenter では、ポリシーにディレクトリ グループを設定する場合、グループ名を正確に入力する必要があります。
-
アイデンティティ ファイアウォール グループ名は次の形式で送信されます。
domain-name\group-name
ASA での形式は domain-name\\group-name です。ただし、リダイレクトされた HTTP 要求にグループを含めるときに一般的な ScanCenter 表記に準拠させるため、ASA はバックスラッシュ(\)を 1 つだけ使用するように名前を変更します。
-
デフォルト グループ名は次の形式で送信されます。
[domain\]group-name
ASA では、オプションのドメイン名を 2 つのバックスラッシュ(\\)が続くように設定する必要があります。ただし、一般的な ScanCenter 表記に準拠させるため、ASA はバックスラッシュ(\)を 1 つだけ使用するように名前を変更します。たとえば、「Cisco\\Boulder1」と指定すると、ASA は、グループ名をクラウド Web セキュリティに送信するときに、バックスラッシュ(\)を 1 つのみ使用する「Cisco\Boulder1」に変更します。
カスタム グループ
カスタム グループは、次の 1 つ以上の基準を使用して定義されます。
-
ScanCenter グループ認証キー:カスタム グループのグループ認証キーを生成できます。その後、ASA を設定するときにこのグループ キーを識別すると、ASA からのすべてのトラフィックがグループ キーでタグ付けされます。
-
送信元 IP アドレス:カスタム グループの送信元 IP アドレスを特定できます。ASA サービス ポリシーが送信元 IP アドレスに基づくため、代わりに ASA で IP アドレスベースのポリシーを設定することもできます。
-
ユーザ名:カスタム グループのユーザ名を識別できます。
-
アイデンティティ ファイアウォール ユーザ名は次の形式で送信されます。
domain-name\username
-
RADIUS または TACACS+ を使用する場合、AAA ユーザ名は次の形式で送信されます。
LOCAL\username
-
LDAP を使用する場合、AAA ユーザ名は次の形式で送信されます。
domain-name\username
-
デフォルトのユーザ名は、次の形式で送信されます。
[domain-name\]username
たとえば、デフォルトのユーザ名を「Guest」に設定すると、ASA は「Guest」を送信します。デフォルトのユーザ名を「Cisco\Guest」に設定すると、ASA は「Cisco\Guest」を送信します。
-
グループおよび認証キーの相互運用の仕組み
カスタム group+group キーが提供する ASA ごとのポリシーが必要ない場合は、企業キーを使用します。すべてのカスタム グループがグループ キーに関連付けられているわけではありません。キーを使用しないカスタム グループを使用して、IP アドレスまたはユーザ名を識別できます。また、キーを使用しないカスタム グループは、ディレクトリ グループを使用するルールとともにポリシー内で使用できます。
ASA ごとのポリシーが必要であり、グループ キーを使用している場合でも、ディレクトリ グループおよびキーを使用しないカスタム グループによって提供される照合機能を使用できます。この場合、グループ メンバーシップ、IP アドレス、またはユーザ名に基づいていくつかの例外を除いて ASA ベースのポリシーが必要になる場合があります。たとえば、すべての ASA 間で America\Management グループのユーザを除外する場合は、次の手順を実行します。
-
America\Management 用のディレクトリ グループを追加します。
-
このグループに対する免除ルールを追加します。
-
免除ルールの後に各カスタム group+group キーのルールを追加して、ASA ごとのポリシーを適用します。
-
America\Management のユーザからのトラフィックは免除ルールに一致し、その他すべてのトラフィックは発信元の ASA のルールに一致します。
キー、グループ、およびポリシー ルールの組み合わせが可能です。
プライマリ プロキシ サーバからバックアップ プロキシ サーバへのフェールオーバー
Cisco Cloud Web Security サービスに登録すると、プライマリ Cloud Web Security プロキシ サーバとバックアップ プロキシ サーバが割り当てられます。
クライアントがプライマリ サーバに到達できない場合、ASA は可用性を判定するためにタワーのポーリングを開始します。(クライアントのアクティビティが存在しない場合、ASA は 15 分ごとにポーリングします)。設定された回数だけ再試行してもプロキシ サーバが使用できない場合(デフォルトは 5 回。この設定は設定可能)、サーバは到達不能として宣言され、バックアップ プロキシ サーバがアクティブになります。ASA は、TCP スリーウェイ ハンドシェイクを完了するサーバの機能に基づいて可用性を判定します。
バックアップ サーバへのフェールオーバー後、ASA はプライマリ サーバをポーリングし続けます。プライマリ サーバが到達可能になると、ASA はプライマリ サーバの使用に戻ります。
クラウド Web セキュリティ アプリケーションの状態をチェックすることで、フェールオーバーをさらに改善することができます。場合によっては、サーバが TCP スリーウェイ ハンドシェイクを完了できても、サーバ上のクラウド Web セキュリティ アプリケーションが正しく機能していないことがあります。アプリケーション健全性チェックを有効にすると、スリーウェイ ハンドシェイクが完了しても、アプリケーション自体が応答しない場合、システムはバックアップ サーバにフェールオーバーできます。これにより、より信頼性の高いフェールオーバー設定が確立されます。
ヘルス チェックでは、クラウド Web セキュリティ アプリケーションにテストの URL を使用して GET リクエストが送信されます。設定されているタイムアウト期限とリトライ限度内で応答に失敗すると、サーバはダウンとしてマーキングされ、システムはフェールオーバーを開始します。バックアップ サーバもまた、アクティブ サーバとしてマーキングされる前に、正しく機能していることを確認するためにテストされます。フェールオーバーの後、プライマリ サーバのアプリケーションは、オンラインに戻り再度アクティブ サーバとしてマーキングされるまで 30 秒ごとに再テストされます。
ASA がプライマリまたはバックアップのクラウド Web セキュリティ プロキシ サーバに到達できない場合の、ASA による Web トラフィックの処理方法を選択できます。これにより、すべての Web トラフィックがブロックされたり、許可されたりする可能性があります。デフォルトでは、Web トラフィックをブロックします。