Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの目次
 

デバイス ID 認証を使用したネットワーク アクセスの制御

デバイスのアイデンティティと属性に基づいて、デバイスの識別機能を設定することで、ネットワークへのアクセスを制御できます。

デバイスID情報に基づくネットワークリソースへのアクセスコントロールについて

統合ユーザー ファイアウォール デバイス ID 認証機能を使用すると、使用するデバイスの属性または特性に基づいてネットワーク リソースへのアクセスを制御できます。デバイス ID 認証機能を構成した後、ポリシー アクションに基づいて、識別されたデバイスからのトラフィックを許可または拒否するセキュリティ ポリシーを構成できます。

デバイスID情報を使用してネットワークへのアクセスを制御する理由

さまざまな理由から、ユーザーの ID ではなく、ユーザーのデバイスの ID に基づいてネットワーク リソースへのアクセスを制御できます。たとえば、ユーザーの ID がわからない場合があります。ユーザが自分のデバイス(BYOD)を使用してネットワーク リソースにアクセスできるようにし、キャプティブ ポータル認証を使用しないようにすることができます。企業によっては、802.1 をサポートしていない古いスイッチを所有していたり、ネットワーク アクセス制御(NAC)システムを備えていない場合があります。統合されたユーザー ファイアウォール デバイス ID 認証機能は、ユーザーのデバイスの属性に基づいてネットワーク アクセスを制御できるようにすることで、このような状況やその他の同様の状況に対するソリューションを提供するように設計されています。

背景

基本的に、デバイスは、認証ソースに応じて、ユーザーID情報を取得するのと同じ方法で、認証ソースからデバイスID情報を受信または取得します。Microsoft Windows Active Directory が認証ソースである場合、デバイスは Active Directory ドメイン コントローラーからデバイス情報を取得します。サードパーティ製の NAC(ネットワークアクセスコントロール)システムの場合、デバイスは、この目的のためにデバイスが公開する RESTful Web サービス API を通じて、認証ソースから情報を受信します。デバイスは、デバイス ID 情報を取得した後、デバイス ID 認証テーブルにそのエントリを作成します。

デバイス情報を取得してデバイス ID 認証テーブルに入力する目的は、デバイスの ID に基づいてネットワーク リソースへのユーザー アクセスを制御することです。これを実現するには、指定されたデバイス ID プロファイルに基づいてデバイスを識別し、そのデバイスから発行されるトラフィックに対して実行するアクションを指定するセキュリティ ポリシーも設定する必要があります。

大まかに言えば、デバイス ID 情報を取得してデバイス ID 情報テーブルに格納されるプロセスには、デバイス側で次のアクションが伴います。

  • デバイス ID 情報を取得します。

    認証ソースに応じて、デバイスは次の 2 つの方法のいずれかを使用してデバイス ID 情報を取得します。

    • アクティブディレクトリ:アクティブディレクトリの場合、デバイスはドメインコントローラのイベントログからデバイス情報を抽出し、アクティブディレクトリLDAPサーバーに接続してデバイスが属するグループの名前を取得できます。デバイスは、イベントログから取得した情報を使用して、LDAP ディレクトリでデバイスの情報を見つけます。

    • サードパーティ NAC システム - これらの認証システムは、Web API と呼ばれる RESTful Web サービス API の POST サービスを使用します。デバイスはAPIを実装し、認証システムに公開して、デバイスID情報をSRXシリーズファイアウォールに送信できるようにします。

      API には正式な XML 構造と制限があり、認証ソースはこの情報をデバイスに送信する際に従う必要があります。

  • デバイス ID 認証テーブルにデバイスのエントリを作成します。

    SRXシリーズファイアウォールは、デバイスID情報を取得した後、デバイスID認証テーブルにそのエントリを作成します。デバイス識別認証テーブルは、Active Directory認証テーブルや、サードパーティ認証ソースに使用される他のローカル認証テーブルとは別のものです。また、認証ソースまたは機能に固有のローカルユーザー認証テーブルとは異なり、デバイスID認証テーブルには、すべての認証ソースのデバイスID情報が保持されます。ただし、Active Directory など、一度にアクティブにできる認証ソースは 1 つだけです。SRXシリーズファイアウォールでは、認証ソースのみを一度に使用できるようにすることで、システムへの情報処理要求を抑制します。

デバイス ID 認証機能は、Active Directory やサードパーティの認証ソースなど、さまざまな種類の認証システムをサポートします。つまり、デバイス ID 認証機能は、認証ソースに関係なく、デバイス ID 情報を同じテーブルに格納する汎用ソリューションを提供します。

Junos OSリリース17.4R1以降、SRXシリーズはユーザーファイアウォール(UserFW)認証にIPv6アドレスをサポートしています。アクティブディレクトリが認証ソースである場合、デバイスIDテーブルにはIPv6アドレスを持つエントリを含めることができます。

図1 は、SRXシリーズと、デバイスID認証に使用されるサードパーティのNAC認証ソース間の通信を示しています。SRXシリーズファイアウォールは、NACシステムからデバイスID情報を受信し、ローカルデバイスID認証テーブルに保存します。デバイス ID プロファイルを指定するセキュリティ ポリシーは、1 つ以上のデバイスに適用されます。デバイスがデバイス ID プロファイルおよびセキュリティ ポリシーの他の部分と一致する場合、セキュリティ ポリシーはそのデバイスから発行されるトラフィックに適用されます。

図1:デバイスID認証でのサードパーティ製ネットワークアクセスコントロール(NAC)システムの使用 Using a Third-Party Network Access Control (NAC) System for Device Identity Authentication

セキュリティ ポリシーでのデバイス ID プロファイルの使用はオプションです。

セキュリティ ポリシーの source-end-user-profile フィールドにデバイス ID プロファイルが指定されていない場合は、「any」プロファイル が想定されます。ただし、キーワード「any」をセキュリティポリシーのソースエンドユーザープロファイルフィールドに使用することはできません。これは予約済みのキーワードです。

統合ユーザー ファイアウォール デバイス ID 認証機能のデバイス ID 属性とプロファイルについて

デバイスIDプロファイルは、CLIend-user-profileでは と呼ばれ、統合ユーザー ファイアウォール デバイス ID 認証機能の主要コンポーネントです。デバイスを識別し、その属性を指定します。デバイス ID 認証機能を使用すると、デバイスのユーザーの ID ではなく、使用するデバイスの ID に基づいてネットワーク リソースへのアクセスを制御できます。この機能は、Microsoft Windows Active Directoryおよびサードパーティのネットワークアクセス制御(NAC)システムを認証ソースとしてサポートします。

このトピックでは、デバイス ID とデバイス ID プロファイルを中心に説明します。

デバイスID

デバイスIDは、基本的に、デバイスのIPアドレス、名前、ドメイン、およびデバイスが属するグループで構成されます。

たとえば、次の出力は、デバイス ID プロファイルから参照されるデバイスに関する情報を示しています。

この例では、デバイス ID 認証テーブルに 2 つのデバイスのエントリが含まれていることを示しています。エントリごとに、デバイスの IP アドレス、デバイスに割り当てられた名前、デバイスが属するグループが表示されます。両方のデバイスがグループgrp4に属していることに注意してください。

デバイス ID プロファイルの内容

デバイス ID プロファイルは、プロファイルで設定された属性に応じて、特定のデバイス グループまたは特定のデバイスの特性である属性のコレクションです。デバイスのパケット転送エンジンは、デバイスの IP アドレスをデバイス ID プロファイルにマッピングします。

デバイス ID プロファイルは、デバイスの名前と、デバイスの IP アドレス、デバイスが属するグループ、およびまとめてホスト属性と呼ばれるデバイスの属性を含む情報を指定します。

メモ：

CLI を使用して設定できる属性は、デバイスの名前とそれが属するグループのみです。その他の属性は、NACシステムまたはActive Directory LDAPで使用されるサードパーティのRESTful WebサービスAPIを使用して設定されます。

デバイスからのトラフィックがSRXシリーズのファイアウォールまたはNFXシリーズのデバイスに到着すると、デバイスはトラフィックの最初のパケットからデバイスのIPアドレスを取得し、それを使用してデバイスID認証テーブルで一致するデバイスIDエントリを検索します。次に、そのデバイス ID プロファイルを、フィールドが source-end-user-profile デバイス ID プロファイル名を指定するセキュリティ ポリシーと照合します。一致が見つかった場合、デバイスから発行されるトラフィックにセキュリティ ポリシーが適用されます。

同じデバイス ID プロファイルを、同じ属性を共有する他のデバイスにも適用できます。ただし、同じセキュリティ ポリシーを適用するには、デバイスとそのトラフィックがセキュリティ ポリシーの他のすべてのフィールドと一致する必要があります。

デバイス ID プロファイルにはドメイン名が含まれている必要があります。複数の属性セットが含まれている場合がありますが、少なくとも 1 つ含まれている必要があります。マーケティング・メイン・アリスというプロファイルに属する次の 2 つの属性セットについて考えてみます。

プロファイルには、次の属性のセットが含まれています。

  • alice-T430 をデバイスの名前として使用します。

  • マーケティングとウェストコースト (デバイスが属するグループとして)。

  • example.net は、それが属するドメインの名前として示されます。

プロファイルには、デバイスを特徴付ける次の属性もあります。

  • デバイスのカテゴリとしてのラップトップ(デバイスカテゴリ)

  • デバイスベンダー(device-vendor)としてのLenovo

  • ThinkPad T430, デバイスのタイプとして (デバイスタイプ)

デバイスに付けられた名前を含む marketing-main-alice プロファイルなどの場合、プロファイルはそのデバイスに排他的に適用されます。

しかし、ここで、marketing-west-coast-T430 という別のプロファイルが設定され、marketing-main-alice プロファイルと同じ属性が含まれているとしますが、1 つの例外: marketing-main-alice プロファイルでデバイスに指定された名前が、marketing-west-coast-T430 プロファイルの属性として含まれていないとします。この場合、プロファイルに含まれる属性によってグループ・プロファイルが構成されます。プロファイルの適用は、プロファイルで定義された残りの特性または属性に適合するすべてのLenovo ThinkPad T430デバイス(ラップトップ)を含むように拡大されます。

他のすべての属性が一致する場合、デバイスはプロファイルの対象となります:マーケティンググループまたはウェストコーストグループのいずれかに属するデバイス(marketing-west-coast-T430プロファイルがグループとして指定するデバイス)、または両方のグループがプロファイルに一致するデバイス。

前述のように、デバイス アイデンティティ プロファイルには複数のグループを含めることができます。デバイスは、複数のグループに属することもできます。

さらに説明するために、marketing-west-coast-T430 と呼ばれるグループ デバイス ID プロファイルは、alice-T430 というデバイスにも適用されることに注意してください。これは、このデバイスが MARKETING グループと WEST-COAST グループの両方に属しており、プロファイルで定義されている他のすべての属性と一致するためです。もちろん、マーケティングメインアリスデバイスIDプロファイルは、alice-T430と呼ばれるデバイスにも適用されます。したがって、alice-T430 というデバイスは少なくとも 2 つのグループに属し、少なくとも 2 つのデバイス ID プロファイルによってカバーされます。

marketing-human-resources という別のプロファイルが、marketing-west-coast-T430 デバイス ID プロファイルのすべての属性で定義されているが、新しいデバイス ID プロファイルには HUMAN-RESOURCES というグループが含まれ、WEST-COAST というグループが含まれていないとします。ただし、マーケティング グループが含まれています。

alice-T430 というデバイスはマーケティング グループに属しており、マーケティング人事プロファイルのグループとして残っているため、alice-T430 デバイスもマーケティング人事デバイス ID プロファイルと一致します。これで、alice-T430デバイスが3つのプロファイルと一致します。これらのプロファイルの名前がセキュリティ ポリシーのソースエンドユーザープロファイルで指定され、alice-T430 デバイスがセキュリティ プロファイルの他のすべてのフィールドと一致する場合、そのプロファイルのアクションがそのデバイスからのトラフィックに適用されます。

前述のデバイス ID プロファイルの例では、次の点を示しています。

  • プロファイルは、1 つのデバイスのみを識別するように定義することも、多数のデバイスに適用するように定義することもできます。

  • デバイス ID プロファイルには、特定のデバイスが属する複数のグループを含めることができます。

  • デバイスは、プロファイルに設定された特性、または少なくとも 1 つのグループを含む属性を照合することにより、複数のデバイス ID プロファイルを照合できます。

デバイス ID プロファイルの柔軟な使用は、source-end-user-profile フィールドを含むように設計されたセキュリティ ポリシーを設定するとき、特にポリシーのアクションを多数のデバイスに適用する場合に明らかになります。

事前定義されたデバイスID属性

SRXシリーズファイアウォールは、NACシステムまたはActive Directory LDAPで使用されるサードパーティのRESTful WebサービスAPIを使用して設定される、事前定義されたデバイスIDポリシー属性を提供します。

  • デバイスID

  • デバイスカテゴリ

  • デバイスベンダー

  • デバイスタイプ

  • デバイス-OS

  • device-os-version

これらの属性の値は、デバイス ID プロファイルで指定します。

デバイスIDプロファイルの特性、属性とターゲットのスケーリング

このセクションでは、SRXシリーズおよびNFXシリーズのデバイスが、デバイスID属性とプロファイルをどのように扱うかについて説明します。また、これらのエンティティのデバイス非依存およびデバイス依存のスケーリング数も提供します。

次の属性とプロファイルの特性は、サポートされているすべてのSRXシリーズおよびNFXシリーズデバイスでの使用に適用されます。

  • 次のエンティティの最大長は 64 バイトです。 デバイスアイデンティティ プロファイル名(CLIでは次のように end-user-profile呼ばれます) 属性名、属性値。

  • 同じ属性に複数のデジタル値範囲を設定する場合、範囲内の値を重複させることはできません。

  • デバイスがデバイス ID プロファイルをセキュリティ ポリシーと照合すると、プロファイル内のすべての属性が考慮されます。それらがどのように扱われるかは次のとおりです。

    • デバイス アイデンティティ プロファイルに属性の複数の値が含まれている場合、その属性の値は個別に処理されます。それらはORedされていると言われています。

      セキュリティポリシーをデバイスに適用するには、以下の条件を満たす必要があります。デバイスは以下と一致する必要があります。

      • 複数の値を持つ各属性の値の 1 つ。

      • デバイス ID プロファイルで指定された残りの属性値。

      • セキュリティ ポリシー フィールドの値。

    • 1 つの値を持つ個々の属性はすべて別々に扱われ、値の集合としてまとめて考慮されます。つまり、AND 演算が適用されます。デバイスは、標準のポリシー一致基準を使用して、これらの属性を処理します。

表 1 は、デバイス ID 認証機能で使用されるプラットフォームに依存しないスケーリング値を示しています。

表 1: プラットフォームに依存しないスケーリング

項目

最大

属性あたりの値

20

プロファイルあたりの属性数

100

セキュリティポリシーごとのデバイスIDプロファイル仕様(ソースエンドユーザープロファイル)

1

表 2 に、デバイス ID 認証機能で使用されるプラットフォーム依存のスケーリング値を示します。

表 2: プラットフォーム依存のスケーリング

プラットフォーム

プロファイルの最大数

属性値の最大数

SRX5000ライン

4000

32000

SRX シリーズ 1500

1000

8000

SRX シリーズ 550M

500

4000

SRXシリーズ300およびSRXシリーズ320

100

1000

SRXシリーズ340およびSRXシリーズ345

100

1000

SRX シリーズ 4100-4XE

1000

8000

SRX シリーズ 4200-8XE

2000

16000

vSRX仮想ファイアウォール

500

4000

NFX150

100

1000

デバイス ID プロファイルに対する次の変更とセキュリティ ポリシーでの使用によって、デバイスはセッション スキャンを実行しません。

  • セキュリティポリシーで参照されているプロファイルの更新。

  • プロファイル構成の更新。

  • NAC システムで使用される RESTful Web サービス API、または Active Directory LDAP を介して行われる属性の更新。

デバイス ID 認証テーブルとそのエントリについて

デバイスには、さまざまな目的でユーザー認証に使用される多数のローカル認証テーブルが含まれています。例えば、Microsoft Windows Active Directoryが認証ソースとして使用されている場合、デバイスにはユーザ認証用のローカルActive Directory認証テーブルが含まれています。

デバイス ID とその属性に基づく認証に統合ユーザー ファイアウォール デバイス ID 認証機能を使用するようにデバイスを設定すると、デバイスはデバイス ID 認証テーブルと呼ばれる新しいテーブルを作成します。

デバイス ID 認証機能を完全に把握するには、このテーブル、その内容、および他のエンティティとの関係を理解すると役立ちます。

このトピックでは、デバイス ID 認証テーブルとそのデバイス エントリ、およびいくつかの要因に基づいてテーブルの内容がどのように変化するかについて説明します。

デバイス ID 認証テーブル

他のローカル認証テーブルとは異なり、デバイス ID 認証テーブルには、ユーザーに関する情報は含まれず、ユーザーのデバイスに関する情報が含まれています。また、ユーザー認証テーブルとは異なり、1つの認証ソースで認証されたデバイスの情報は含まれません。むしろ、認証ソースに関係なく、すべてのデバイスのデバイスID情報のリポジトリとして機能します。たとえば、Active Directory またはサードパーティーの NAC 認証ソースで認証されたデバイスのエントリーが含まれる場合があります。

デバイス ID 認証テーブルのエントリには、次の部分が含まれています。

  • デバイスの IP アドレス。

  • デバイスが属するドメインの名前。

  • デバイスが関連付けられているグループ。

  • デバイス ID。

    デバイス ID は、実際にはデバイス ID プロファイル(CLI end-user-profileでは と呼びます)の ID です。このタイプのプロファイルには、特定の個々のデバイスまたは特定のデバイスグループ(特定のタイプのラップトップなど)を特徴付ける属性のグループが含まれています。

Junos OS 17.4R1以降、SRXシリーズファイアウォールは、ユーザーファイアウォールモジュール(UserFW)認証用のIPv6アドレスをサポートしています。この機能により、IPv6 トラフィックを送信元 ID に設定されたセキュリティ ポリシーに一致させることができます。以前は、セキュリティポリシーがソースIDに設定され、そのIPアドレスに「any」が指定されている場合、UserFWモジュールはIPv6トラフィックを無視していました。

IPv6 アドレスは、以下の認証ソースでサポートされています。

  • アクティブディレクトリ認証テーブル

  • アクティブディレクトリ認証を使用したデバイスID

  • ローカル認証テーブル

  • ファイアウォール認証テーブル

デバイス ID 認証テーブルの内容が変更される理由

デバイスID認証テーブルのデバイスIDエントリは、特定のイベントが発生したときに変更されます:デバイスIDエントリが関連付けられているユーザー認証エントリの有効期限が切れた場合、デバイスが属するグループの参照に関してセキュリティポリシーの変更が発生した場合、デバイスがグループに追加またはグループから削除された場合、 または、そのグループが属するグループが削除され、その変更が Windows Active Directory LDAP サーバーに加えられた場合。

  • デバイス ID エントリが関連付けられているユーザー ID エントリの有効期限が切れたとき

    デバイスは、デバイス ID 認証テーブルにデバイスのエントリを生成すると、そのエントリを、Active Directory などのデバイスのユーザーを認証した特定の認証ソースのローカル認証テーブル内のユーザー ID エントリに関連付けます。すなわち、デバイスID認証テーブル内のデバイスIDエントリを、ユーザ認証テーブル内のデバイスのユーザ用のエントリに結び付ける。

    デバイス ID エントリが関連付けられているユーザ認証エントリが期限切れになり、ユーザ認証テーブルから削除されると、デバイス ID エントリはデバイス ID 認証テーブルからサイレントに削除されます。つまり、このイベントを通知するメッセージは発行されません。

  • デバイスが属するグループの参照に関してセキュリティポリシーが変更された場合

    デバイス ID に基づいてネットワーク リソースへのアクセスを制御するには、セキュリティ ポリシーで参照できるデバイス ID プロファイルを作成します。デバイス アイデンティティ プロファイルには、他の属性に加えて、グループの名前も含まれています。デバイス ID プロファイルがセキュリティ ポリシーによって参照される場合、それに含まれるグループは 対象グループと呼ばれます。

    グループは、セキュリティ ポリシーによって参照されている場合(つまり、セキュリティ ポリシーの e フィールドで指定されたデバイス ID プロファイルsource-end-user-devicに含まれている場合)、対象グループとして適格になります。セキュリティ ポリシーで現在使用されていないデバイス ID プロファイルにグループが含まれている場合、そのグループは対象グループのリストに含まれません。グループは、セキュリティ ポリシーによって参照されるグループのリスト内およびリストから移動できます。

  • デバイスがグループに追加された場合、グループから削除された場合、またはグループが削除されたとき

    ローカルデバイスID認証テーブルのデバイスIDエントリーを最新の状態に保つために、SRXシリーズまたはNFXシリーズはActive Directoryイベントログの変更を監視します。デバイスがネットワークからログアウトしたか、またはログアウトしたかを判断するだけでなく、デバイスが属している可能性のあるグループへの変更を判断できます。デバイスが属するグループに変更が発生した場合(つまり、デバイスがグループに追加または削除された場合、またはグループが削除された場合)、デバイスは、Microsoft Windows Active Directory LDAP サーバーに加えられた変更を反映するために、自身のデバイス ID 認証テーブル内の影響を受けるデバイス エントリの内容を変更します。

表 3 に示すように、デバイス ID 認証テーブルは、デバイスが LDAP サーバー内で関連付けられているグループに対する変更に応じて更新されます。

表 3: アクティブディレクトリ LDAP 内のデバイスに対するグループの変更 と SRX シリーズまたは NFX シリーズの応答

LDAP に加えられた変更

SRXシリーズまたはNFXシリーズのLDAPメッセージおよびユーザーIDデーモンアクション

デバイスのグループ情報が変更されました。デバイスがグループに追加または削除されたか、デバイスが属するグループが削除された。

アクティブディレクトリLDAPモジュールは、SRXシリーズまたはNFXシリーズのUserIDデーモンに変更の通知を送信し、ローカルデバイスID認証テーブルの情報を変更するように指示します。

デバイスはこれらのメッセージを 2 分ごとに処理します。

LDAP のデバイスエントリが削除されます。

アクティブディレクトリ LDAP モジュールは、変更の通知を UserID デーモンに送信し、ローカルデバイス ID 認証テーブル内の情報を修正するように指示します。

デバイスはこれらのメッセージを 2 分ごとに処理します。

SRXシリーズまたはNFXシリーズのデバイスUserIDデーモンに変更が通知されます。デバイスが属するグループがセキュリティポリシーで指定されているかどうかは、影響を受けるデバイスのデバイスID認証テーブルエントリに格納される情報に影響します。 表 4 は、グループがアクティブ・ディレクトリー LDAP に追加または削除されたときに発生するアクティビティーを示しています。

表 4: セキュリティ ポリシーの仕様に基づくデバイス ID エントリの変更

デバイスIDプロファイルの変更

デバイスグループ マッピングの動作

SRX シリーズまたは NFX シリーズのユーザー ID デーモンの応答

アクティブディレクトリLDAPに追加された新しいグループが、SRXシリーズファイアウォールIDプロファイルに追加されます。

デバイスは、新しいグループとそのサブグループに属するデバイスのリストを Active Directory LDAP サーバーから取得します。リストをローカル LDAP ディレクトリに追加します。

UserID デーモンは、デバイス ID 認証テーブルに、影響を受けるデバイスのセットのエントリーが含まれているかどうかを判別します。その場合は、これらのエントリのグループ情報が更新されます。

たとえば、新しいグループを含むように更新される前、およびグループが追加された後の device1 のエントリを次に示します。

  • デバイス1、g1

  • デバイス1、G1、G2

グループがアクティブディレクトリLDAPから削除されます。デバイスによって、デバイス ID プロファイルからグループが削除されます。

デバイスは、削除されたグループに属するデバイスのリストをローカル LDAP データベースから取得します。

ローカル LDAP ディレクトリからデバイスグループのマッピングを削除します。

UserID デーモンは、デバイス ID 認証テーブルで、グループに属する項目がないか検査します。影響を受けるエントリからグループを削除します。

たとえば、グループが削除される前と削除された後の device1 のエントリを次に示します。

  • デバイス1、G1、G2

  • デバイス1、g1

表 5 は、グループの削除によって影響を受ける複数のデバイスのデバイス認証エントリの内容を詳しく説明しています。

表 5: LDAP およびセキュリティ ポリシーの変更によるデバイス ID 認証テーブルの変更

デバイス ID 認証テーブルのエントリの変更

IPアドレス

デバイス情報

グループ

元のエントリ

192.0.2.10

デバイス1

グループ1、グループ2

192.0.2.11

デバイス2

グループ3、グループ4

192.0.2.12

デバイス3

グループ2

group2 が削除された後も同じエントリ

192.0.2.10

デバイス1

グループ1

192.0.2.11

デバイス2

グループ3、グループ4

192.0.2.12

デバイス3

このエントリにはグループが含まれなくなりました。

セキュリティ ポリシーの照合とデバイス ID プロファイル

デバイスは、トラフィックをセキュリティポリシーと照合するための標準ルールに従います。次の動作は、一致を判断するためのセキュリティ ポリシーでのデバイス ID プロファイルの使用に関連しています。

  • セキュリティ ポリシーでのデバイス ID プロファイルの使用はオプションです。

    • ソース エンド ユーザ プロファイル フィールドにデバイス アイデンティティ プロファイルが指定されていない場合は、 any プロファイルが想定されます。

    • セキュリティ ポリシーのフィールドでキーワードanysource-end-user-profileを使用することはできません。

      セキュリティポリシーでソースエンドユーザープロファイルフィールドを使用する場合は、特定のプロファイルを参照する必要があります。アクセス試行が発行されるデバイスは、プロファイルの属性と一致する必要があります。

  • 1 つのセキュリティ ポリシーで指定できるデバイス ID プロファイルは 1 つだけです。

  • セキュリティ ポリシーのフィールド値が変更されたときに source-end-user-profile 、セキュリティ ポリシーの再照合がトリガーされます。プロファイルの属性値が変更されても、再マッチはトリガーされません。

SRXシリーズがネットワークアクセスコントロールのためにWindowsアクティブディレクトリから認証済みデバイスID情報を取得する方法を理解する

統合ユーザー ファイアウォール デバイス ID 認証機能を使用すると、ユーザー ID ではなく、使用されるデバイスの ID と属性に基づいてネットワーク リソースへのアクセスを制御できます。デバイスに関する情報は、デバイス ID 認証テーブルに格納されます。セキュリティポリシーのソースエンドユーザープロファイルフィールドにデバイス属性を含むデバイスIDプロファイルの名前を指定できます。すべての条件が満たされた場合、セキュリティポリシーのアクションがそのデバイスから発行されるトラフィックに適用されます。

セキュリティポリシーでデバイスIDプロファイルを使用できるようにするには、SRXシリーズファイアウォールまたはNFXシリーズデバイスが、認証済みデバイスのデバイスID情報を取得する必要があります。デバイスは、デバイス ID エントリを格納するために使用するデバイス ID 認証テーブルを作成します。デバイスからトラフィックが到着したときに、一致するデバイステーブルを検索します。このトピックでは、Active Directory が認証ソースとして使用される場合に従うプロセスについて説明します。

Active Directory ドメイン コントローラは、ユーザーがドメインにログインするときにユーザーを認証し、そのイベントのレコードを Windows イベント ログに書き込みます。また、ユーザーがドメインからログアウトしたときに、イベント ログにレコードを書き込みます。ドメイン コントローラーのイベント ログは、ドメイン内で現在アクティブな認証済みデバイスと、それらのデバイスがドメインからログアウトされた日時に関する情報をデバイスに提供します。

UserID デーモンは、以下のアクションを実行します。

  1. Active Directory ドメイン コントローラーのイベント ログを読み取って、ドメインにログインし、Windows によって認証されたデバイスの IP アドレスを取得します。

    デバイス ルーティング エンジンの UserID デーモンは、Microsoft 分散 COM/Microsoft RPC スタックと、Active Directory ドメイン内の Windows Active Directory ドメイン コントローラーと通信するための認証メカニズムを備えた Windows 管理インストルメンテーション (WMI) クライアントを実装します。プロセスは、アクティブ ディレクトリ コントローラから取得したイベント ログ情報を使用して、アクティブ アクティブ ディレクトリ デバイスの IP アドレスを取得します。このプロセスは、同じ WMI DCOM インターフェイスを使用してアクティブ ディレクトリ イベント ログの変更を監視し、ローカル認証テーブル内のデバイス ID 情報を調整して、Active Directory サーバーに加えられた変更を反映します。

  2. イベント ログから取得したデバイスの IP アドレスを使用して、デバイスが属するグループに関する情報を取得します。このグループ情報を取得するために、デバイスはこの目的のために LDAP プロトコルを使用してアクティブディレクトリコントローラの LDAP サービスに接続します。

このプロセスの結果として、デバイスはデバイス ID 認証テーブル内のデバイスのエントリを生成できます。デバイスは、デバイス ID 認証テーブルにデバイスのエントリを生成すると、そのエントリをローカル Active Directory 認証テーブル内の適切なユーザー エントリに関連付けます。その後、セキュリティ ポリシーのデバイス ID プロファイル エントリを参照して、リソースへのアクセスを制御できます。

動作と制約

  • イベント ログを読み取るプロセスでは、ドメイン コントローラーの CPU リソースが消費されるため、ドメイン コントローラーの CPU 使用率が高くなる可能性があります。このため、Active Directory ドメイン コントローラーには、少なくとも 4 コアと 8 ギガバイトのメモリの高パフォーマンス構成が必要です。

  • ドメイン コントローラーのイベント ログには、null ターミネータを含むデバイス ID の最大長が 16 バイトに記録されます。したがって、デバイスがドメイン コントローラーから取得するデバイス ID の最大長は 15 バイトです。

  • ドメイン コントローラーがイベント ログをクリアした場合、またはイベント ログに書き込まれたデータが欠落しているか遅延している場合は、デバイス ID マッピング情報が不正確になる可能性があります。SRX シリーズまたは NFX シリーズ デバイスがイベント ログを読み取れない場合、または NULL データが含まれている場合、デバイスは自身のログにエラー状態を報告します。

  • デバイス ID 情報テーブルが容量に達すると、新しいデバイス ID エントリを追加できなくなります。その場合、デバイスからのトラフィックはドロップされます。

サードパーティ NAC 認証システム用のデバイス ID XML ソリューションについて

統合されたユーザー ファイアウォール デバイス ID 認証機能を使用すると、デバイスの ID に基づいてネットワーク リソースへのアクセスを制御できます。次のいずれかのデバイス ID ソリューションを使用できます。

  • 認証ソースとしてのMicrosoft Active Directory。

    Microsoft Active Directoryを使用するように環境が設定されている場合、SRXシリーズまたはNFXシリーズのデバイスは、Active DirectoryドメインコントローラとLDAPサービスからデバイスのIPアドレスとグループを取得します。

  • ネットワークアクセス制御(NAC)認証システム。

    ネットワーク環境がNACソリューション用に設定されており、このアプローチを採用することにした場合、NACシステムはデバイスID情報をSRXシリーズまたはNFXシリーズデバイスに送信します。RESTful Web サービス API を使用すると、デバイス情報を正式な XML 構造でデバイスに送信できます。

    警告：

    このアプローチを採用する場合は、NAC ソリューションがデバイスで動作することを確認する必要があります。

SRXシリーズおよびNFXシリーズデバイスでのXML Web APIの実装

RESTful Web サービス API を使用すると、デバイス ID 情報を正式な XML 構造で SRX シリーズまたは NFX シリーズ デバイスに送信できます。これにより、NACソリューションをデバイスと統合し、デバイス情報を効率的にデバイスに送信できます。API を使用してデバイスに情報を送信する際には、正式な構造と制限に従う必要があります。

NACサービスからSRXシリーズまたはNFXシリーズデバイスに送信されるデータの整合性の確保

次の要件は、NAC サービスから送信されるデータが侵害されないようにすることです。

  • API の実装は、HTTP/HTTPS POST 要求のみの処理に制限されています。その他の種類の要求を受信すると、エラー メッセージが生成されます。

  • API デーモンは、以下の専用 URL からの HTTP/HTTPS リクエストのみを分析および処理します。

  • NACソリューションがSRXシリーズファイアウォールに投稿するHTTP/HTTPSコンテンツは、一貫した正しいフォーマットである必要があります。正しい XML 形式は、妥協がないことを示し、ユーザー ID 情報が失われないようにします。

データ サイズの制限とその他の制約

SRXシリーズまたはNFXシリーズ デバイスにポストされたデータには、次のデータ サイズの制限と制限が適用されます。

  • NAC 認証システムは、ポストするデータのサイズを制御する必要があります。それ以外の場合、Web API デーモンはそれを処理できません。Web API デーモンは、最大 2 メガバイトのデータを処理できます。

  • ロールおよびデバイスのポスチャ情報の XML データには、次の制限が適用されます。Web API デーモンは、これらの量を超える XML データ (つまり、オーバーフロー データ) を破棄します。

    • デバイスは、最大 209 の役割を処理できます。

    • デバイスは、6 つの可能なポスチャ トークン(値)を持つ 1 種類のポスチャのみをサポートします。個々のユーザのアイデンティティ情報は、ポスチャ トークンを 1 つだけ持つことができます。

例:アクティブディレクトリ環境でのSRXシリーズファイアウォールID機能の設定

この例では、統合ユーザー ファイアウォール デバイス ID 認証機能を設定して、ユーザーではなく認証済みデバイスの ID に基づいてネットワーク リソースへのアクセスを制御する方法を示します。この例では、Microsoft Active Directory を認証ソースとして使用しています。デバイスまたはデバイスのセットを特徴付けるデバイス ID プロファイルを設定する方法と、セキュリティ ポリシーでそのプロファイルを参照する方法について説明します。デバイスがデバイスIDとセキュリティポリシーパラメータに一致する場合、セキュリティポリシーのアクションがそのデバイスから発行されるトラフィックに適用されます。

さまざまな理由から、リソースのアクセス制御にデバイスの ID を使用できます。たとえば、ユーザーの ID がわからない場合があります。また、企業によっては、802.1をサポートしていない古いスイッチを所有していたり、ネットワークアクセス制御(NAC)システムを導入していない場合もあります。デバイス ID 認証機能は、デバイス ID に基づいてネットワーク アクセスを制御できるようにすることで、このような状況やその他の同様の状況に対するソリューションを提供するように設計されています。デバイス ID 仕様または個々のデバイスに適合するデバイス グループのアクセスを制御できます。

要件

この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。

  • Junos OSリリース15.1X49-D70以降を実行するSRXシリーズサービスゲートウェイデバイス。

  • ドメイン コントローラとライトウェイト ディレクトリ アクセス プロトコル (LDAP) サーバーを使用した Microsoft Active Directory

    Active Directory ドメイン コントローラーには、4 コアと 8 ギガバイトのメモリの高パフォーマンス構成があります。

    メモ：

    SRXシリーズは、ドメインコントローラーのイベントログを読み取ることで、デバイスのIPアドレスを取得します。イベント ログを読み取るプロセスは、ドメイン コントローラーの CPU リソースを消費するため、CPU 使用率が高くなる可能性があります。このため、Active Directory ドメイン コントローラーには、少なくとも 4 コアと 8 ギガバイトのメモリの高パフォーマンス構成が必要です。

  • 社内ネットワーク上のサーバー。

概要

Junos OSリリース15.1X49-D70およびJunos OSリリース17.3R1以降、SRXシリーズでは、Active Directoryまたはサードパーティ製のネットワークアクセス制御(NAC)システムによって認証されたデバイスのIDに基づいて、ネットワークリソースへのアクセスを制御するサポートがサポートされています。この例では、認証ソースとしてアクティブディレクトリを使用しています。

メモ：

この機能を使用するには、認証ソースを構成する必要があります。

この例では、次の構成部分について説明します。

  • ゾーンとそのインターフェイス

    セキュリティ ポリシーで指定された送信元エンティティと送信先エンティティが属するゾーンを設定する必要があります。設定しないと、デバイス ID プロファイルを参照するセキュリティ ポリシーが無効になります。

  • デバイス ID プロファイル

    デバイス ID プロファイルは、セキュリティ ポリシーとは別に設定します。セキュリティポリシーから参照します。デバイス ID プロファイルは、1 つ以上のデバイスで照合できるデバイス ID を指定します。アクティブディレクトリの場合、プロファイルでデバイスID属性のみを指定できます。

    この例では、デバイス ID 属性の指定は会社のコンピューターです。

    メモ：

    デバイス アイデンティティ プロファイルは、CLI で と呼ばれます end-user-profile 。

  • セキュリティポリシー

    セキュリティ ポリシーを設定し、そのアクションは、デバイス ID プロファイル属性とセキュリティ ポリシーの残りのパラメータに一致するデバイスから発行されるトラフィックに適用されます。

    メモ：

    セキュリティ ポリシー source-end-user-profile のフィールドにデバイス ID プロファイルの名前を指定します。

  • 認証ソース

    デバイスの認証に使用する認証ソースを設定します。この例では、デバイス ID 認証ソースとして Active Directory を使用しています。

    Active Directoryが認証ソースの場合、SRXシリーズはActive Directoryドメインのイベントログを読み取ることで、認証済みデバイスのID情報を取得します。次に、デバイスは Active Directory の LDAP インターフェイスにクエリーを行い、クエリーに使用したデバイスの IP アドレスを使用して、デバイスが属するグループを識別します。

    この目的のために、デバイスは、Microsoft 分散 COM/Microsoft RPC スタックと、Active Directory ドメイン内の Windows Active Directory コントローラーと通信するための認証メカニズムを備えた Windows 管理インストルメンテーション (WMI) クライアントを実装します。これは、Active Directory ドメインのイベント ログからデバイス情報を抽出するデバイス wmic デーモンです。

    また、wmic デーモンは、同じ WMI DCOM インターフェイスを使用して、アクティブ ディレクトリ イベント ログの変更を監視します。変更が発生すると、デバイスはローカル デバイス ID 認証テーブルを調整して、それらの変更を反映します。

    Junos OS リリース 17.4R1 以降、IPv6 アドレスをアクティブディレクトリドメインコントローラと LDAP サーバーに割り当てることができます。Junos OS リリース 17.4R1 以前までは、IPv4 アドレスのみを割り当てることができました。

トポロジ

この例では、マーケティング ゾーン領域に属するユーザーが、社内サーバー上のリソースにアクセスしたいと考えています。アクセス制御は、デバイスの ID に基づいています。この例では、会社のコンピューターがデバイス ID として指定されています。したがって、セキュリティ ポリシー アクションは、その仕様に適合し、セキュリティ ポリシーの条件に一致するデバイスにのみ適用されます。これは、サーバー リソースへのアクセスを許可または拒否されるデバイスです。ユーザー ID に基づいてアクセスが制御されることはありません。

ネットワークデバイスを含むゾーン(マーケティングゾーン)と内部サーバーを含むゾーン(サーバーゾーン)の2つのSRXシリーズゾーンが確立されます。IPアドレスが192.0.2.18/24であるSRXシリーズファイアウォールインターフェイスge-0/0/3.1が、マーケティングゾーンゾーンに割り当てられます。IPアドレスが192.0.2.14/24であるSRXシリーズファイアウォールインターフェイスge-0/0/3.2は、サーバーゾーンゾーンに割り当てられています。

この例では、次のアクティビティについて説明します。

  1. SRXシリーズファイアウォールは、WMI DCOMインターフェイスを使用してアクティブディレクトリドメインコントローラに接続し、アクティブディレクトリによって認証されたデバイスに関する情報を取得します。

    ユーザーがネットワークにログインして認証されると、ユーザーのデバイスに関する情報がイベントログに書き込まれます。

  2. SRX シリーズは、Active Directory ドメイン コントローラのイベント ログからデバイス情報を抽出します。

  3. SRXシリーズは、抽出された情報を使用して、デバイスが属するグループのリストをActive Directory LDAPサーバーから取得します。

  4. SRXシリーズは、ローカルデバイスID認証テーブルを作成し、ドメインコントローラやLDAPサーバーから取得したデバイスID情報をこのテーブルに保存します。

  5. デバイスからのトラフィックがSRXシリーズファイアウォールに到着すると、SRXシリーズはデバイスID認証テーブルで、トラフィックを発行したデバイスと一致するエントリーを探します。

  6. SRXシリーズは、アクセスを要求しているデバイスに一致するエントリーを検出すると、セキュリティポリシーテーブルで、アクセスを要求しているデバイスのデバイスID仕様と一致するデバイスID仕様を持つデバイスIDプロファイルをフィールドに指定しているセキュリティポリシー source-end-user-profile を探します。

  7. 一致するセキュリティポリシーが、デバイスから発行されるトラフィックに適用されます。

図 2 に、この例のトポロジを示します。

図2:認証ソースとしてActive Directoryを使用したデバイスID機能のトポロジー Topology for the Device Identity Feature with Active Directory as the Authentication Source

構成

Active Directory 環境でデバイス ID 機能を設定するには、次のタスクを実行します。

CLIクイック構成

この例を素早く設定するには、以下のコマンドをテキストファイルにコピーし、改行を削除し、ネットワーク設定に合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストし、設定モードから を入力してください commit 。

Active Directory 環境での統合ユーザー ファイアウォール デバイス ID 認証機能の設定

手順

この手順には、Active Directory環境でデバイスID認証機能をサポートするようにSRXシリーズファイアウォールを設定するために必要な設定ステートメントが含まれています。

  1. マーケティングゾーンとサーバーゾーンに使用するインターフェイスを設定します。

  2. マーケティングゾーンとサーバーゾーンを設定し、それらにインターフェイスを割り当てます。

  3. Microsoft Active Directory を指定するように認証ソースを構成します。デバイス ID 機能が機能するには、認証ソースを指定する必要があります。これは必須の値です。

  4. デバイス ID プロファイルのデバイス ID 仕様を構成します。これは end-user-profile、 とも呼ばれます。

  5. marketing-west-coastと呼ばれるデバイスIDプロファイルを参照するmark-server-accessと呼ばれるセキュリティポリシーを設定します。セキュリティ ポリシーでは、マーケティング ゾーンに属する (およびデバイス ID プロファイルの仕様に一致する) すべてのデバイスが、ターゲット サーバーのリソースにアクセスできます。

  6. アクティブディレクトリと通信し、LDAPサービスを使用するようにSRXシリーズファイアウォールを設定します。

    デバイスID認証機能の実装に必要なグループ情報を取得するために、SRXシリーズファイアウォールはライトウェイトディレクトリアクセスプロトコル(LDAP)を使用します。SRXシリーズは、LDAPサーバーと通信するLDAPクライアントとして機能します。通常、アクティブディレクトリドメインコントローラはLDAPサーバーとして機能します。デバイスの LDAP モジュールは、デフォルトでは、ドメイン コントローラ内の Active Directory にクエリを実行します。

結果

構成モードで を入力します show interfaces 。

構成モードで を入力します show security zones 。

構成モードで を入力します show services user-identification device-information end-user-profile 。

構成モードで を入力します show services user-identification device-information authentication-source 。

構成モードで を入力します show security policies 。

構成モードで を入力します show services user-identification active-directory-access 。

構成モードで を入力します show services user-identification active-directory-access domain example-net 。

検証

デバイス ID 認証テーブルの内容を確認する

目的

デバイス ID 認証テーブルに、予期されるエントリとそのグループが含まれていることを確認します。

アクション

この場合、デバイス ID 認証テーブルには 3 つのエントリが含まれています。次のコマンドは、3 つのエントリすべての広範な情報を表示します。

操作モードで コマンドを入力して show services user-identification device-information table all extensive 、テーブルの内容を表示します。

サンプル出力
コマンド名
意味

テーブルには、認証されたすべてのデバイスとそのデバイスが属するグループの情報を含むエントリが含まれている必要があります。

リリース履歴テーブル
リリース
説明
17.4R1
Junos OSリリース17.4R1以降、SRXシリーズはユーザーファイアウォール(UserFW)認証にIPv6アドレスをサポートしています。アクティブディレクトリが認証ソースである場合、デバイスIDテーブルにはIPv6アドレスを持つエントリを含めることができます。
17.4R1
Junos OS 17.4R1以降、SRXシリーズファイアウォールは、ユーザーファイアウォールモジュール(UserFW)認証用のIPv6アドレスをサポートしています。この機能により、IPv6 トラフィックを送信元 ID に設定されたセキュリティ ポリシーに一致させることができます。以前は、セキュリティポリシーがソースIDに設定され、そのIPアドレスに「any」が指定されている場合、UserFWモジュールはIPv6トラフィックを無視していました。