Cisco Firepower Threat Defense バージョン 6.1 コンフィギュレーション ガイド（Firepower Device Manager 用）
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年12月8日
章のタイトル： アイデンティティ ポリシー
アイデンティティ ポリシー
アイデンティティポリシーを使用して、接続からユーザ アイデンティティ情報を収集できます。その後、ダッシュボードにユーザ アイデンティティに基づく使用状況を表示し、ユーザまたはユーザグループに基づくアクセス コントロールを設定できます。
アイデンティティ ポリシーの概要
接続に関連付けられているユーザを検出するためにアイデンティティ ポリシーを使用できます。ユーザを識別することで、脅威、エンドポイント、およびネットワーク インテリジェンスをユーザ ID 情報に関連付けることができます。ネットワーク動作、トラフィック、およびイベントを個別のユーザに直接リンクすることによって、ポリシー違反、攻撃、またはネットワークの脆弱性の発生源の特定に役立てることができます。
たとえば、侵入イベントのターゲットとされたホストを誰が所有し、誰が内部攻撃やポート スキャンを開始したかを確認できます。また、高帯域幅のユーザや、望ましくない Web サイトまたはアプリケーションにアクセスしているユーザを確認することもできます。
ユーザの検出は、分析用のデータを収集するだけではありません。ユーザ名またはユーザ グループの名前に基づいてアクセス ルールを書き込み、ユーザの権限に基づいて選択的にリソースへのアクセスを有効化またはブロックすることもできます。
 （注） | システムは、同じホストに対して異なるユーザによる複数のログインを検出すると、特定のホストにログインするユーザは一度に 1 人だけであり、ホストの現在のユーザが最後の権限のあるユーザ ログインであると見なします。複数のユーザがリモート セッション経由でログインしている場合は、サーバによって報告された最後のユーザがユーザであると見なされます。 |
アクティブ認証によるユーザ ID の確立
認証は、ユーザのアイデンティティを確認する動作です。
アクティブ認証を使用すると、HTTP トラフィック フローがユーザ ID のマッピングがないシステムの IP アドレスから送られてきたときに、ネットワークに設定されたディレクトリを使用して、トラフィック フローを開始したユーザを認証するかどうかを決定できます。ユーザが正常に認証された場合、IP アドレスは、認証されたユーザのアイデンティティがあると見なされます。
認証が失敗しても、ユーザのネットワーク アクセスは妨げられません。アクセス ルールは最終的に、これらのユーザにどのアクセスを提供するか決定します。
ユーザ数の制限
Firepower Device Manager は、ディレクトリ サーバから最大 2000 人のユーザに関する情報をダウンロードできます。
ディレクトリ サーバに 2000 人以上のユーザ アカウントが含まれる場合、アクセス ルールでユーザを選択するとき、またはユーザ ベースのダッシュボード情報を閲覧するときに、すべての可能な名前を確認することができません。ルールは、ダウンロードしたこれらの名前だけに書き込むことができます。
2000 までの制限は、グループに関連付けられた名前に適用されます。グループに 2000 人以上のメンバーがいる場合、ダウンロードされた 2000 の名前のみをグループ メンバーシップと一致させることができます。
2000 人以上のユーザがいる場合、Firepower Device Manager ではなく Firepower Management Center（リモート マネージャ）の使用を検討してください。Firepower Management Center では、はるかに多くのユーザをサポートします。
サポートされるディレクトリ サーバ
アイデンティティ ポリシーとともに Windows Server 2008 および 2012 で Microsoft Active Directory（AD）を使用できます。
サーバの設定に関して次の点に注意してください。
ディレクトリ ベース DN の決定
ディレクトリのプロパティを設定する際は、ユーザおよびグループに共通のベース識別名（DN）を指定する必要があります。このベースは、ディレクトリ サーバで定義され、ネットワークごとに異なります。アイデンティティ ポリシーが動作するためには、正しいベースを入力する必要があります。ベースが誤っている場合、システムがユーザやグループ名を判別できないため、アイデンティティ ベースのポリシーが動作不能になります。
 ヒント | 正しいベースを取得するには、ディレクトリ サーバを担当する管理者に問い合わせてください。 |
Active Directory の場合、ドメイン管理者として Active Directory サーバにログインし、コマンド プロンプトで dsquery のコマンドを次のように使用することで、正しいベースを判別できます。
- ユーザ検索ベース
-
dsquery user コマンドを入力し、ベース識別名を調べたい既知のユーザ名（一部または全部）を指定します。たとえば、次のコマンドでは、「John*」という部分名を使用して、「John」から始まるすべてのユーザの情報を返します。
C:\Users\Administrator>dsquery user -name “John*” “CN=John Doe,CN=Users,DC=csc-lab,DC=example,DC=com”
ベース DN は「DC=csc-lab,DC=example,DC=com」となります。
- グループ検索ベース
-
dsquery group コマンドを入力し、ベース識別名を調べたい既知のグループ名（一部または全部）を指定します。たとえば、次のコマンドは、Employees グループ名を使用して識別名を返します。
C:\>dsquery group -name “Employees” “CN=Employees,CN=Users,DC=csc-lab,DC=example,DC=com”
グループのベース DN は「DC=csc-lab,DC=example,DC=com」となります。
また、ADSI Edit プログラムを使用して、Active Directory 構造をブラウズすることもできます（）。ADSI Edit で組織ユニット（OU）、グループ、ユーザなどのオブジェクトを右クリックし、[プロパティ（Properties）]を選択すると、識別名が表示されます。DC 値の文字列をベースとしてコピーできます。
ベースが正しいことを確認するには、次のように操作します。
-
ディレクトリ プロパティの [接続テスト（Test Connection）] ボタンをクリックして、接続を確認します。問題を解決し、ディレクトリ プロパティを保存します。
-
デバイスに対する変更をコミットします。
-
アクセス ルールを作成し、[ユーザ（Users）]タブを選択して、ディレクトリから既知のユーザおよびグループ名の追加を試みます。ディレクトリが含まれるレルム内のユーザおよびグループに入力が一致すると、自動コンプリートによる候補が表示されます。これらの候補がドロップダウン リストに表示された場合、システムがディレクトリを正常にクエリーできたことが分かります。候補が表示されず、入力した文字列は確実にユーザ名またはグループ名に含まれることが既知である場合には、対応する検索ベースを修正する必要があります。
不明なユーザの対処
アイデンティティ ポリシーのディレクトリ サーバを設定すると、システムはディレクトリ サーバからユーザおよびグループ メンバーシップ情報をダウンロードします。この情報は、24 時間ごとに夜中に更新されるか、またはディレクトリ設定を編集して保存するたびに（変更がなくても）更新されます。
アクティブな認証アイデンティティ ルールによって求められた認証に成功したにも関わらず、ユーザ名がダウンロードしたユーザ ID 情報の中に存在しない場合、不明なユーザとしてマークされます。ID 関連のダッシュボードにそのユーザの ID は表示されず、ユーザ一致グループ ルールにも検出されません。
ただし、不明なユーザに対するアクセス コントロール ルールが適用されます。たとえば、不明なユーザの接続をブロックすると、これらのユーザは、たとえ認証に成功（ディレクトリ サーバがユーザとパスワードが有効であると認識したことを意味する）してもブロックされます。
そのため、ユーザの追加や削除、グループ メンバーシップの変更などの変更をディレクトリ サーバに加えた場合、システムがディレクトリから更新情報をダウンロードするまで、これらの変更はポリシーの適用に反映されません。
毎日の深夜の更新まで待てない場合、ディレクトリ サーバ情報を編集することで強制的に更新を実行できます（ から [ディレクトリ サーバ（Directory Server）]ボタンをクリックする）。[保存（Save）]をクリックして変更を展開します。システムはただちに更新情報をダウンロードします。
（注） | 新規または削除されたユーザ情報がシステムに反映されているかどうかを確認するには、 に移動して [ルールを追加（Add Rule (+)）] ボタンをクリックし、[ユーザ（Users）]タブのユーザ リストを確認します。新規ユーザを検出できないか、または削除されたユーザが検出される場合、システムには古い情報があります。 |
アイデンティティ ポリシーの設定
アイデンティティ ポリシーを使用して、接続からユーザ アイデンティティ情報を収集できます。その後で、ダッシュボードにユーザ アイデンティティに基づく使用状況を表示し、ユーザまたはユーザ グループに基づくアクセス コントロールを設定できます。
次に、アイデンティティ ポリシーでユーザ アイデンティティを取得するために必要な要素を設定する方法の概要を示します。
| ステップ 1 | を選択します。 アイデンティティ ポリシーをまだ定義していない場合、ウィザードを開始してアイデンティティ ポリシーを設定するように求められます。[開始（Get Started）]をクリックしてウィザードを開始します。ウィザードでは次の手順を実行します。 |
| ステップ 2 | アイデンティティ ポリシーを管理します。
アイデンティティ設定を設定すると、このページにすべてのルールが順番にリストアップされます。上から下に向かってルールがトラフィックと照合され、最初に適合したルールによって、適用されるアクションが決定されます。このページで次の操作を実行できます。
アイデンティティ ルールの作成と変更の詳細については、アイデンティティ ルールの設定を参照してください。 |
）。
）。
ディレクトリ サーバの設定
ディレクトリ サーバには、ネットワークへのアクセスが許可されているユーザおよびユーザ グループに関する情報が含まれています。毎日、一日の最後の時間（UTC）にすべてのユーザとグループに関する更新情報がダウンロードされます。
ディレクトリ管理者と協力して、ディレクトリ サーバのプロパティの設定に必要な値を入手します。
（注） | レルムを追加したら、設定を確認し、[ディレクトリ サーバ（Directory Server）]ボタンをクリックし、[ディレクトリ サーバ（Directory Server）] ダイアログボックスの [テスト（Test）]ボタンをクリックして接続をテストします。テストが失敗した場合は、すべてのフィールドを確認し、管理 IP アドレスとディレクトリ サーバ間にネットワーク パスが存在することを確認します。 |
| ステップ 1 | を選択します。 |
| ステップ 2 | 次のいずれかを実行します。 |
| ステップ 3 | ディレクトリ サーバに関する次の情報を入力します。
|
| ステップ 4 | （ウィザードで）[次へ（Next）]をクリックするか、[保存（Save）] をクリックします。 |
アクティブ認証キャプティブ ポータルの設定
アイデンティティ ルールでユーザのアクティブ認証を必要とする場合、ユーザは接続されているインターフェイス上のキャプティブ ポータル ポートにリダイレクトされ、認証を求めるプロンプトが表示されます。証明書をアップロードしないと、ユーザには自己署名証明書が提示されます。ブラウザがすでに信頼している証明書をアップロードしない場合、ユーザは証明書を承認する必要があります。
（注） | HTTP Basic、HTTP 応答ページ、および NTLM 認証方式では、ユーザはインターフェイスの IP アドレスを使用してキャプティブ ポータルにリダイレクトされます。ただし、HTTP ネゴシエートでは、ユーザは完全修飾 DNS 名 firewall-hostname.AD-domain-name を使用してリダイレクトされます。HTTP ネゴシエートを使用する場合、アクティブ認証を必要としているすべての内部インターフェイスの IP アドレスにこの名前をマッピングするように DNS サーバを更新する必要があります。そうしないと、リダイレクトは実行できず、ユーザを認証できません。 |
ディレクトリ サーバ、Firepower Threat Defenseデバイス、およびクライアント間で、時刻設定が一致していることを確認します。これらのデバイス間で時刻にずれがあると、ユーザ認証が成功しない場合があります。「一致」とは、別のタイム ゾーンを使用できますが、たとえば、10 AM PST = 1 PM EST など、それらのゾーンに対して相対的に同じになっている必要があることを意味しています。
アイデンティティ ルールの設定
アイデンティティ ルールは、一致するトラフィックに対してユーザ識別情報を収集する必要があるかどうかを定義します。一致するトラフィックのユーザ識別情報を取得しない場合は、「No Authentication」を設定します。
ルール設定に関係なく、アクティブ認証は HTTP トラフィックに対してのみ実行されることに注意してください。したがって、HTTP 以外のトラフィックをアクティブ認証から除外するルールを作成する必要はありません。すべての HTTP トラフィックに対してユーザ識別情報を取得する場合は、アクティブ認証ルールをすべての送信元および宛先に適用するだけで済みます。
（注） | また、認証に失敗してもネットワーク アクセスには影響しません。アイデンティティ ポリシーは、ユーザ識別情報のみを収集します。認証に失敗したユーザがネットワークにアクセスできないようにするには、アクセス ルールを使用する必要があります。 |
| ステップ 1 | を選択します。 | ||
| ステップ 2 | 次のいずれかを実行します。
不要になったルールを削除するには、ルールの [削除（delete）] アイコン（ | ||
| ステップ 3 | [順序（Order）]で、ルールの番号付きリストのどこにルールを挿入するかを選択します。
ルールは最初に一致したものから順に適用されるため、限定的なトラフィック一致基準を持つルールは、同じトラフィックに適用され、汎用的な基準を持つルールよりも上に置く必要があります。 デフォルトでは、ルールはリストの最後に追加されます。ルールの順序を後で変更する場合、このオプションを編集します。 | ||
| ステップ 4 | [ユーザ認証（User Authentication）]のタイプを選択します。 | ||
| ステップ 5 | （アクティブ認証のみ）。ディレクトリ サーバでサポートする認証方法（[タイプ（Type）]）を選択します。
| ||
| ステップ 6 | （アクティブ認証のみ）。アクティブ認証に失敗したユーザがゲスト ユーザとしてラベル付けされているかどうかを確認するには、 を選択します。
ユーザは、正常に認証する 3 つの機会が得られます。失敗した場合、このオプションの選択により、ユーザがどのようにマーク付けされるかが決まります。これらの値に基づき、アクセス ルールを書き込みできます。 | ||
| ステップ 7 | [送信元/宛先（Source/Destination）]タブで、トラフィック一致基準を定義します。
アクティブ認証は、HTTP トラフィックに対してのみ試されることに注意してください。したがって、HTTP 以外のトラフィックに対して 「No Auth」ルールを設定する必要はなく、また HTTP 以外のトラフィックに対してアクティブ認証ルールを作成するポイントもありません。 アイデンティティ ルールの送信元/宛先基準は、トラフィックが通過するセキュリティ ゾーン（インターフェイス）、IP アドレス、または IP アドレスの国または大陸（地理的位置）、またはトラフィックで使用されるプロトコルおよびポートを定義します。デフォルトは、すべてのゾーン、アドレス、地理的位置、プロトコル、およびポートです。 条件を変更するには、条件内の [+]ボタンをクリックし、希望するオブジェクトまたは要素を選択し、 ポップアップ ダイアログボックスの [OK] をクリックします。基準にオブジェクトが必要で、そのオブジェクトが存在しない場合、[新規オブジェクトの作成（Create New Object）] をクリックします。オブジェクトまたは要素をポリシーから削除するには、そのオブジェクトまたは要素の [x]をクリックします。 次のトラフィック一致基準を設定できます。
| ||
| ステップ 8 | [OK]をクリックします。 |
透過的なユーザ認証のイネーブル化
- HTTP Basic
-
HTTP 基本認証では、ユーザは常に自分のディレクトリ ユーザ名とパスワードを認証するように要求されます。パスワードはクリア テキストで送信されます。そのため、基本認証はセキュアな認証形式とは見なされません。
基本認証は、デフォルトの認証メカニズムです。
- HTTP 応答ページ
-
これは、HTTP 基本認証の一種であり、ユーザがログイン ブラウザ ページに表示されます。
- NTLM、HTTP ネゴシエート（Active Directory のための統合 Windows s認証）
-
統合 Windows 認証では、ユーザがドメインにログインしてワークステーションを使用するという事実が利用されます。ブラウザは、アクティブ認証中のFirepower Threat Defenseキャプティブ ポータルを含め、サーバへのアクセス時にこのドメイン ログインの使用を試みます。パスワードは送信されません。認証が成功すると、ユーザは透過的に認証されます。ユーザは、何らかの認証チャレンジが実行され、それが満たされたことを意識しません。
ブラウザがドメイン ログイン クレデンシャルを使用して認証要求を満足できない場合、ユーザは、ユーザ名とパスワードの入力を要求されますが、これは基本認証と同じユーザ エクスペリエンスとなります。したがって、統合 Windows 認証を設定した場合、同じドメイン内のネットワークまたはサーバにアクセスするときに、ユーザがクレデンシャルを入力する必要性を減らすことができます。
なお、HTTP ネゴシエートは、アクティブ ディレクトリ サーバとユーザ エージェントの両方がサポートする、最も強力な方式を選択することに注意してください。ネゴシエーションが認証方式として HTTP 基本認証を選択した場合、トランスペアレント認証は行われません。強度の順序は、NTLM、次に基本認証です。トランスペアレント認証を可能にするには、ネゴシエーションが NTLM を選択する必要があります。
透過的な認証をイネーブルにするには、統合 Windows 認証をサポートするようにクライアント ブラウザを設定する必要があります。以下に、統合 Windows 認証をサポートする、広く使用されている一部のブラウザに関して、一般的な要件と基本設定について説明します。ソフトウェア リリースごとに技術が変更される場合があるため、詳細情報についてはブラウザ（または他のユーザ エージェント）のヘルプを参照してください。
ヒント | Chrome および Safari など、すべてのブラウザが統合 Windows 認証をサポートするとは限りません（これが書かれたときに使用可能なバージョンに基づく）。ユーザはユーザ名とパスワードの入力を要求されます。使用しているバージョンでサポートが使用可能かどうかを確認するには、ブラウザのマニュアルを参照してください。 |
トランスペアレント認証の要件
トランスペアレント認証を実装するには、ブラウザまたはユーザ エージェントを設定する必要があります。これは、個別に実行することも、そのための設定を作成し、ソフトウェア配布ツールを使用してその設定をクライアント ワークステーションにプッシュすることもできます。この作業をユーザが自分で実行する場合は、ネットワークで機能する具体的な設定パラメータを提供する必要があります。
-
ユーザがネットワークへの接続に使用する Firepower Threat Defense インターフェイスを [信頼済みサイト（Trusted Sites）] リストに追加します。IP アドレスか、使用可能な場合は完全修飾ドメイン名（たとえば、inside.example.com）を使用できます。また、ワイルドカードまたはアドレスの一部を使用して、汎用化された信頼済みサイトを作成できます。たとえば、一般的には *.example.com または単に example.com を使用してすべて内部サイトを網羅し、ネットワーク内のすべてのサイトを信頼することができます（自身のドメイン名を使用）。インターフェイスの特定アドレスを追加する場合は、信頼済みサイトに複数のアドレスを追加して、ネットワークへのすべてのユーザ アクセス ポイントに対処することが必要な場合があります。
-
統合 Windows 認証は、プロキシ サーバ経由で機能しません。したがって、プロキシを使用しないか、またはプロキシを通過しないアドレスにFirepower Threat Defenseインターフェイスを追加する必要があります。プロキシを使用する必要がある場合、ユーザは NTLM を使用する場合でも認証を要求されます。
ヒント | トランスペアレント認証の設定は必須ではありませんが、エンド ユーザにとって便利です。トランスペアレント認証を設定しなかった場合、ユーザはすべての認証方式に対するログイン チャレンジを提示されます。 |
トランスペアレント認証用の Internet Explorer の設定
NTLM トランスペアレント認証を有効にするよう Internet Explorer を設定するには、次の手順を実行します。
トランスペアレント認証用の Firefox の設定
NTLM トランスペアレント認証を有効にするよう Firefox を設定するには、次の手順を実行します。
アイデンティティ ポリシーのモニタリング
認証が必要なアイデンティティ ポリシーが正しく機能している場合、 ダッシュボード、およびユーザ情報を含むその他のダッシュボードにユーザ情報が表示されます。
また、 に表示されるイベントにもユーザ情報が含まれます。
ユーザ情報が表示されない場合は、ディレクトリ サーバが正しく機能していることを確認します。ディレクトリ サーバの設定ダイアログ ボックスにある [テスト（Test）]ボタンを使用して、接続を確認します。
ディレクトリ サーバが機能していて使用可能な場合、認証が必要なアイデンティティ ルールのトラフィック一致条件がユーザを照合する方法で記述されていることを確認します。たとえば、ユーザ トラフィックがデバイスに入るインターフェイスが送信元ゾーンに含まれていることを確認します。
アイデンティティ ルールは HTTP トラフィックのみを照合するため、ユーザはそのタイプのトラフィックをデバイス経由で送信している必要があります。
フィードバック