Cisco Firepower Threat Defense バージョン 6.2 コンフィギュレーション ガイド（Firepower Device Manager 用）
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年12月8日
章のタイトル： アイデンティティ ポリシー
アイデンティティ ポリシー
アイデンティティ ポリシーを使用して、接続からユーザ アイデンティティ情報を収集できます。その後で、ダッシュボードにユーザ アイデンティティに基づく使用状況を表示し、ユーザまたはユーザ グループに基づくアクセス コントロールを設定できます。
アイデンティティ ポリシーの概要
アイデンティティ ポリシーを使用して、接続に関連付けられているユーザを検出できます。ユーザを特定することで、脅威、エンドポイントおよびネットワーク インテリジェンスをユーザ アイデンティティ情報に関連付けることができます。ネットワークの行動、トラフィックおよびイベントを直接個々のユーザにリンクすることで、システムは、ユーザがポリシー違反、攻撃またはネットワーク脆弱性の元を特定できるように助長します。
たとえば、誰が侵入イベントによって標的とされたホストを所有しているか、誰が内部攻撃またはポート スキャンを開始したかなどを特定できます。また、帯域幅使用率の高いユーザや望ましくない Web サイトまたはアプリケーションにアクセスしているユーザも特定できます。
ユーザ検出では、分析用のデータ収集以上のことができます。ユーザ名またはユーザ グループ名に基づいてアクセス ルールを記述し、ユーザ認証に基づいてリソースへのアクセスを選択的に許可またはブロックすることもできます。
 （注） | システムは、同じホストに対して異なるユーザによる複数のログインを検出すると、特定のホストにログインするユーザは一度に 1 人だけであり、ホストの現在のユーザが最後の権限のあるユーザ ログインであると見なします。複数のユーザがリモート セッションを通じてログインしている場合は、サーバによってレポートされた最後のユーザがユーザとみなされます。 |
アクティブ認証によるユーザ アイデンティティの確立
認証は、ユーザのアイデンティティを確認する手段です。
アクティブな認証では、ユーザ アイデンティティのマッピングが確認できない IP アドレスから HTTP トラフィック フローが送信されてきた場合、システムに設定したディレクトリに照会して、トラフィック フローを開始したユーザを認証するかどうか決定できます。このユーザが認証に成功すると、この IP アドレスは、認証したユーザのアイデンティティを持つとみなされます。
認証に失敗しただけでは、このユーザのネットワーク アクセスは禁止されません。このようなユーザに許可されるアクセスの種類は、事前に指定したアクセス ルールによって最終的に決定されます。
ユーザ数の上限
Firepower デバイス マネージャは、最大 2000 ユーザに関する情報をディレクトリ サーバからダウンロードできます。
ディレクトリ サーバに 2000 を超えるユーザ アカウントが含まれており、アクセス ルールでユーザを選択したか、ユーザベースのダッシュボード情報を表示した場合、候補となるすべての名前は表示されません。ダウンロードされた名前に対してのみルールを記述できます。
2000 の制限は、グループに関連付けられた名前にも適用されます。1 つのグループに 2000 を超えるメンバーがいる場合、ダウンロードされた 2000 のみの名前をグループ メンバーシップに対して照合できます。
2000 ユーザを超える場合は、Firepower デバイス マネージャではなく、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）] タブを選択し、ディレクトリから既知のユーザおよびグループ名の追加を試みます。ディレクトリを含むレルム内の一致ユーザ名およびグループ名を入力すると、入力中にオートコンプリートによる候補が表示されます。ドロップダウン リストに候補が表示される場合は、システムがディレクトリに適切に照会できたことを意味します。入力した文字列がユーザ名またはグループ名として表示されることが確かであるにもかかわらず、候補が表示されない場合は、対応する検索ベースを修正する必要があります。
不明なユーザの処理
アイデンティティ ポリシー用にディレクトリ サーバを設定すると、ユーザおよびグループ メンバーシップの情報がディレクトリ サーバからダウンロードされます。この情報は午前 0 時から 24 時間ごと、またはディレクトリの設定を編集および保存する都度（変更を何も加えなかった場合も同様）更新されます。
アクティブな認証アイデンティティ ルールの要求する認証に成功したユーザであっても、ダウンロードされたユーザ アイデンティティ情報内にこのユーザの名前が含まれていない場合は、このユーザは「不明」とマークされます。アイデンティティ関連のダッシュボードにはこのユーザの ID は表示されず、このユーザはグループ ルールにも一致しません。
代わりに、不明ユーザを対象としたすべてのアクセス コントロール ルールが適用されます。たとえば、不明ユーザの接続をブロックするように設定している場合は、認証に成功したユーザ（ディレクトリ サーバに認識され、パスワードも有効であるユーザ）であっても、不明ユーザとみなされればブロックされます。
したがって、ユーザの追加や削除、またはグループ メンバーシップの変更など、ディレクトリ サーバに何らかの変更を加えた場合は、システムがディレクトリから更新情報をダウンロードするまで、これらの変更はポリシーの適用には反映されません。
毎日の午前 0 時の更新時まで待機することが難しい場合は、ディレクトリ サーバ情報を編集することで、更新を強制的に適用できます（ を選択して [ディレクトリ サーバ（Directory Server）] ボタンをクリック）。[保存（Save）]をクリックして、変更を展開します。更新情報がただちにダウンロードされます。
（注） | 新規に追加したユーザ、または削除したユーザの情報がシステムに反映されているかどうかを確認するには、 を選択して、[ルールの追加(+)（Add Rule (+)）] ボタンをクリックします。[ユーザ（Users）]タブに表示されたユーザのリストを確認してください。新規ユーザが表示されない場合、または削除したはずのユーザが表示される場合は、システム上の情報が古いことを意味します。 |
アイデンティティ ポリシーの設定
アイデンティティポリシーを使用して、接続からユーザ アイデンティティ情報を収集できます。その後で、ダッシュボードにユーザ アイデンティティに基づく使用状況を表示し、ユーザまたはユーザ グループに基づくアクセス コントロールを設定できます。
次に、アイデンティティ ポリシーからユーザ アイデンティティ を取得するために必要な要素の設定方法の概要を示します。
| ステップ 1 | を選択します。 まだアイデンティティ ポリシーを定義していない場合は、ウィザードを開始して設定するように求められます。[開始（Get Started）]をクリックしてウィザードを開始します。ウィザードでは次の手順を実行します。 |
| ステップ 2 | アイデンティティ ポリシーを管理します。
アイデンティティの設定を行うと、このページにすべてのルールが順番に表示されます。ルールが上から下の順番でトラフィックと照合され、最初に一致したルールによって適用するアクションが決まります。このページから次の操作を実行できます。
アイデンティティ ルールの作成と編集の詳細については、アイデンティティ ルールの設定を参照してください。 |
）をクリックします。
）をクリックします。
ディレクトリ サーバの設定
ディレクトリ サーバには、ネットワークへのアクセスを許可されたユーザおよびユーザ グループについての情報が保存されます。システムは毎日深夜 11 時（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 ネゴシエートを使用する場合は、DNS サーバも更新して、アクティブな認証が必要なすべての内部インターフェイスの IP アドレスにこの名前をマッピングする必要があります。そうしないと、リダイレクションが完了できず、ユーザは認証できません。 |
ディレクトリ サーバ、FirePOWER Threat Defenseデバイスおよびクライアント間で、時刻設定が一致していることを確認します。これらのデバイス間で時刻にずれがあると、ユーザ認証が成功しない場合があります。「一致」とは、別のタイム ゾーンを使用できるが、たとえば、10 AM PST = 1 PM EST など、時刻がそれらのゾーンに対して相対的に同じになっている必要があることを意味しています。
アイデンティティ ルールの設定
アイデンティティ ルールは、一致するトラフィックのユーザ アイデンティティ情報を収集する必要があるかどうかを決定します。一致するトラフィックのユーザ アイデンティティ情報を取得しない場合は、[認証なし（No Authentication）] を設定できます。
ルールの設定に関係なく、アクティブ認証は HTTP トラフィックに対してのみ実行される点に注意してください。そのため、HTTP 以外のトラフィックをアクティブ認証から除外するルールを作成する必要はありません。すべての HTTP トラフィックに関するユーザ アイデンティティ情報を取得する場合は、すべての送信元と宛先にアクティブ認証ルールを適用するだけで取得できます。
（注） | また、認証の失敗は、ネットワークのアクセスには影響しない点にも注意してください。アイデンティティ ポリシーは、ユーザ アイデンティティ情報のみを収集します。認証に失敗したユーザがネットワークにアクセスするのを阻止する場合は、アクセス ルールを使用する必要があります。 |
| ステップ 1 | を選択します。 | ||
| ステップ 2 | 次のいずれかを実行します。
不要になったルールを削除するには、ルールの削除アイコン（ | ||
| ステップ 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 基本認証
-
HTTP 基本認証では、ユーザは常に、ディレクトリのユーザ名およびパスワードによる認証を促されます。パスワードはクリア テキストで送信されます。このため、基本認証は安全な認証形態とみなされません。
基本認証は、デフォルトの認証メカニズムです。
- HTTP 応答ページ
-
HTTP 基本認証の一種であり、ユーザにブラウザのログイン ページが表示されます。
- NTLM、HTTP ネゴシエート（Active Directory 向けの統合 Windows 認証）
-
統合 Windows 認証では、ユーザがドメインにログインして、各自のワークステーションを使用することを利用します。アクティブ認証中、ブラウザはサーバにアクセスするとき（FirePOWER Threat Defenseキャプティブ ポータルも含む）、このドメイン ログインを使用しようとします。パスワードは送信されません。認証が成功すると、ユーザは透過的に認証されます。つまり、認証チャレンジが行われたことも、適合したことも、ユーザが意識することはありません。
ドメインのログイン クレデンシャルを使用した認証要求をブラウザが満たすことができなかった場合は、ユーザはユーザ名とパスワードを要求されます。これは、基本認証と同じユーザ エクスペリエンスです。このように、統合 Windows 認証を設定すると、同一ドメイン内のネットワークまたはサーバにアクセスしようとするユーザは、クレデンシャルを提示する必要がなくなります。
HTTP ネゴシエートでは、Active Directory サーバとユーザ エージェントの両方でサポートされるものの中から、最強の認証方式が選択されることに注意してください。ネゴシエーションによって HTTP 基本認証が認証方式として選択された場合は、トランスペアレント認証は行われません。強度の順位は、NTLM、基本認証の順です。トランスペアレント認証を使用するには、ネゴシエーションで NTLM が選択される必要があります。
トランスペアレント認証を有効にするには、統合 Windows 認証をサポートするようにクライアント ブラウザを設定する必要があります。以下のセクションでは、一般的に使用され、統合 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 の設定
Internet Explorer を NTLM のトランスペアレント認証用に設定するには、次の手順を実行します。
トランスペアレント認証用の Firefox の設定
NTLM（NT LAN マネージャ）の透過的な認証のために Firefox を設定するには、次の手順を実行します。
アイデンティティ ポリシーのモニタリング
認証を必要とするアイデンティティ ポリシーが正常に動作している場合は、 ダッシュボードやユーザ情報を含むその他のダッシュボードにユーザ情報が表示されます。
さらに、 に表示されるイベントにもユーザ情報が含まれています。
ユーザ情報が表示されない場合は、ディレクトリ サーバが正常に機能していることを確認します。接続を確認するには、ディレクトリ サーバの設定ダイアログ ボックスの [テスト（Test）]ボタンを使用します。
ディレクトリ サーバが機能していて使用可能な場合は、認証を必要とするアイデンティティ ルールのトラフィック一致基準がユーザに一致するように記述されていることを確認します。たとえば、送信元ゾーンに、ユーザ トラフィックがデバイスに入力するために経由するインターフェイスが含まれていることを確認します。
アイデンティティ ルールは HTTP トラフィックのみに一致するため、ユーザはデバイス経由でそのタイプのトラフィックを送信している必要があります。
フィードバック