Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

ClearPassを使用したセキュリティポリシーの適用

セキュリティ ポリシーを設定することで、ユーザー名とグループ名に基づいてユーザーのインターネットへのアクセスを制御できます。

ClearPass ユーザーおよびグループ認証の実施について

このトピックでは、ユーザーがリソースにアクセスしようとしたときに、SRXシリーズのファイアウォールまたはNFXシリーズのデバイスがユーザーとグループの認証を適用する方法について説明します。また、ユーザー エントリー内のグループを参照するセキュリティ ポリシーが削除されたときに、デバイスが ClearPass 認証テーブルのユーザー エントリー内の情報をどのように処理するかについても説明します。このプロセスを理解することは、グループIDに関連する問題のトラブルシューティングに役立ち、ClearPass認証テーブルのユーザーエントリの変更に関する洞察を得ることができます。

デバイスがClearPass認証テーブルを管理する方法の理解

統合されたClearPass認証およびポリシー適用機能により、SRXシリーズまたはNFXシリーズデバイスとAruba ClearPass Policy Manager(CPPM)が協力して会社のリソースを保護できます。これにより、デバイスはユーザートラフィックにファイアウォールセキュリティポリシーを適用し、ユーザーまたはグループのIDに基づいて保護されたリソースへのユーザーアクセスを制御できます。ユーザーの身元を確認するために、デバイスは CPM から受信した認証済みユーザー情報に依存します。

デバイスが CPM から認証されたユーザー ID 情報を取得し、ClearPass 認証テーブルにエントリを生成し、セキュリティ ポリシーとユーザー イベントに関連してそれらのエントリを管理する方法を理解しておくと役立ちます。これらのプロセスを理解することは、関連する問題を迅速に特定して解決するのに役立ちます。

このトピックでは、次の内容に焦点を当てています。

  • デバイスがCPPMからユーザーID情報を取得して管理する方法、およびこの情報をセキュリティポリシーで使用する方法。

  • グループをソース(source-identity)として参照するセキュリティポリシーが、ClearPass認証テーブルのユーザーエントリにリストされているグループにどのように影響するか。セキュリティー・ポリシーによって参照されるグループは、 対象グループと呼ばれます。

ClearPass 認証テーブルのユーザー認証エントリ

両者のコラボレーションでは、ClearPassはSRXシリーズまたはNFXシリーズデバイスの認証ソースとして機能します。CPPMは、認証したユーザーに関するID情報をデバイスに送信します。デバイス内の UserID デーモン・プロセスは、この情報を受信して処理し、この目的のために生成される独立した ClearPass 認証テーブル内のパケット転送エンジン側に同期させます。

デバイスの管理者は、セキュリティポリシーで認証されたユーザーID情報を使用して、保護されたリソースとインターネットへのアクセスを制御できます。

デバイスが CPPM から取得し、個々の ClearPass 認証テーブルに同期されるグローバル ルーティング エンジン認証テーブルにエントリを作成するために使用するユーザー ID 情報の収集は、ユーザー名と関連グループリストがユーザーのデバイスの IP アドレスにマップされるため、マッピング、またはより一般的には IP ユーザー マッピングと呼ばれます。

グループリストは、ClearPass認証テーブルのユーザー認証エントリーごとに、ユーザーが属するグループに加えて、デバイスが正常かどうかなどのデバイスの状態を示すポスチャトークンなどの他の情報も識別します。

ClearPass 認証とアクティブ ディレクトリ認証の両方の統合ユーザー ファイアウォール機能は、認証テーブルにユーザー ID と認証エントリがあるユーザーごとに最大 2048 セッションを管理します。サポートされている 2048 セッションを超える追加のセッションがユーザーに関連付けられている可能性がありますが、それらは統合ユーザー ファイアウォールによって管理されません。認証テーブル内の認証エントリが削除されると、統合ユーザファイアウォールはそのエントリに関連付けられているセッションのみを閉じます。管理されていないセッションは閉じられません。つまり、認証エントリに関連付けられていないセッションは閉じられません。

デバイスのIPアドレスは、ClearPass認証テーブルエントリ内のユーザー名とそのグループに関連付けられているため、セキュリティポリシーでユーザー名またはグループ名を使用してユーザーを識別することができ、使用するデバイスのIPアドレスに直接依存する必要はありません。

ユーザーエントリごとに、エントリ内のグループまたはロールの数は200を超えることはできません。容量に達すると、追加のロールは破棄され、次の syslog メッセージが送信されます。

Junos OSリリース18.4R3、19.4R2、19.1R3、19.2R2、19.3R3では、eUSBを搭載したSRX300デバイス(SRX300、SRX320、SRX340、SRX345)の場合、SRXシリーズユーザーファイアウォール(UserFW)モジュールは、起動後にドメインコントローラまたはJIMS(Juniper Identity Management Service)からのユーザーエントリーを同期しようとします。ドメインコントローラーで履歴ログインイベントの有効期限が切れている場合、SRXシリーズのUserFWモジュールは、UserFWモジュールの起動後にそれらのユーザーエントリーを取得できません。

CPPMは、次の形式でユーザー情報をデバイスに投稿します。デバイスはこの情報のすべてを使用するわけではありません。

次に、ユーザーの ClearPass 認証テーブル エントリの形式を示し、その後にエントリの例とそのコンポーネントの説明を示します。

次の例では、ユーザは human-resources-grp グループと posture-healthy グループの 2 つのグループに属しています。SRXシリーズファイアウォールは、ポスチャ情報をCPPMからグループ名に変換します。デバイスが posture-healthy グループ (ロール) に属している場合、すべてのユーザーにマーケティング サーバーへのアクセスを許可するセキュリティ ポリシーを構成できます。

  • IPアドレス

    これは、使用されるデバイスのIPアドレスです。

  • ユーザーが属するドメインの名前。

    この例では、ドメイン名は "会社ドメイン" です。ドメイン名が指定されていない場合は、デフォルトのドメイン名 GLOBAL が使用されます。

  • ユーザー名

    ユーザー名は、ネットワークへの接続に使用されるユーザーのログイン名で、この例では lin です。

    この名前は、使用するデバイスに関係なく一定です。

    source-identity タプルが、使用するデバイスの IP アドレスではなく、ユーザ名またはグループ名でトラフィックの送信元を識別するセキュリティ ポリシーを設定すると、セキュリティ ポリシーがデバイスに依存しないかのように設定されます。これは、使用するデバイスに関係なく、ユーザーのアクティビティに適用されます。

  • ユーザーが属する 1 つ以上のグループ

    ここで、 関心のあるグループ の概念とセキュリティポリシーとの関係が作用します。関心のあるグループとは、セキュリティ ポリシーで参照されるグループです。関心のあるグループの概念については、このトピックの後半で説明します。

ユーザーが複数のデバイスを使用してネットワークに接続している場合、そのユーザーに複数の IP ユーザー マッピングが存在する可能性があることに注意してください。各マッピングには、ユーザー名と IP アドレスに加えて、独自の値セット(ドメイン名とグループリスト)があります。

例えば、3 つの別々のデバイスを使用してネットワークに接続しているユーザー abe には、次の 3 つの IP アドレスからユーザー名へのマッピングが存在する可能性があります。

SRXシリーズファイアウォールが110.208.132.23、abeのログアウトメッセージを受信すると仮定します。次のユーザー認証エントリの一部は、ユーザー abe が現在 2 つのデバイスのみを使用してネットワークにログインしていることを示しています。

警告:

ClearPass 認証テーブル内の 1 つの認証エントリに 2048 を超えるセッションが関連付けられている場合、ClearPass の統合ユーザー ファイアウォールは、オーバーフローの原因となったセッションを管理しません。その結果、それらのセッションのセッション終了ログに報告されたセッションのユーザー識別情報はありません。

ClearPassとSRXシリーズファイアウォールまたはNFXシリーズデバイス間の通信

SRXシリーズファイアウォールまたはNFXシリーズデバイスとClearPassの通信方法の概要を以下に示します。

  • ユーザーは、有線または無線 LAN 経由で企業ネットワークに参加します。

  • CPPMはユーザーを認証します。

  • CPPMは、統合されたWeb APIを使用してデバイスとのセキュアな接続を開始します。

  • UserID デーモンは、CPM から完全な IP ユーザー・マッピングを取得します。認証されたユーザーごとに、UserID デーモンはルーティング・エンジン認証テーブルにエントリーを生成します。

    ルーティング エンジン認証テーブルは、ClearPass に加えて他の認証ソースからの情報に基づく認証エントリを保持するという点で一般的です。たとえば、Microsoft Active Directory によって認証されたユーザーのエントリも保持される場合があります。

  • UserID デーモンは、ユーザー認証情報をルーティング エンジン認証テーブルからパケット転送エンジンの ClearPass 認証テーブルに同期させます。ClearPass 認証テーブルは、ClearPass 認証情報のみを保持する専用テーブルです。 図1を参照してください。

    図1:CPPMからSRXシリーズファイアウォールルーティングエンジンへのユーザー情報クリアパス認証テーブルに User Information from the CPPM to the SRX Series Firewall Routing Engine Synchronized to the ClearPass Authentication Table同期

デバイスは、次のプロセスで認証されたユーザー ID 情報を使用します。ユーザーが内部の保護されたリソースまたはインターネットにアクセスしようとすると、デバイスは次のことを行います。

  • ユーザーが生成したトラフィックで、一致するセキュリティ ポリシーがないか確認します。送信元トラフィックは、セキュリティポリシーで指定されたすべてのタプルに一致する必要があります。一致には、ユーザー名またはグループ名を指定する source-identity フィールドが含まれます。

    一致を識別するために、デバイスは、ユーザー名またはグループ名を、セキュリティ ポリシーで構成された source-identity 仕様、および他のすべてのセキュリティ ポリシー値と比較します。

  • セキュリティ ポリシーの一致が見つかった場合、ClearPass 認証テーブルでユーザーの認証エントリをチェックします。

    ClearPass 認証テーブルにエントリが見つからない場合、デバイスは、一致するものが見つかるまで、指定した順序で他のローカル認証テーブルをチェックします。ただし、ユーザークエリ機能が設定されている場合は、他のローカル認証テーブルはチェックされません。 統合されたClearPass認証およびエンフォースメントユーザークエリ機能についてを参照してください。

    デバイスは、特定の状況下で、CPPMからその情報をまだ受信していない場合に、個々のユーザー情報をCPPMに照会できます。この機能は、ユーザー クエリと呼ばれます。

図2 は、デバイスとCPM間の接続と通信を示しています。また、ユーザーを認証し、インターネットおよび内部の保護されたリソースへのアクセスを許可するために必要なパスも示します。

図2:ClearPassおよびSRXシリーズファイアウォールの通信とユーザー認証プロセス ClearPass and SRX Series Firewall Communication and User Authentication Process

図 2 に示すように、次のアクティビティが発生します。

  1. CPPMは、Web APIを使用してSRXシリーズファイアウォールとのセキュアな接続を開始します。

  2. 3 人のユーザーがネットワークに参加し、CPM によって認証されます。

    • タブレットユーザーが企業WANを介してネットワークに参加します。

    • スマートフォンのユーザーが、企業WANを介してネットワークに参加します。

    • ワイヤレス ラップトップ ユーザーは、企業 LAN に接続されているレイヤー 2 スイッチに接続された有線ラップトップからネットワークに参加します。

  3. CPPMは、Web APIを使用してPOSTリクエストメッセージで、ネットワークにログインしているユーザーのユーザー認証情報とID情報をデバイスに送信します。

    ユーザーからのトラフィックがデバイスに到着すると、デバイスは次のことを行います。

    • トラフィックが一致するセキュリティ ポリシーを識別します。

    • ClearPass 認証テーブルでユーザーの認証エントリを検索します。

    • ユーザーを認証した後、トラフィックにセキュリティ ポリシーを適用します。

  4. 内部の保護されたリソースへのアクセスを要求しているスマートフォンユーザーからのトラフィックがデバイスに到着します。ステップ 3 で識別されたすべての条件が満たされ、セキュリティー・ポリシーで許可されているため、デバイスは保護リソースへのユーザー接続を許可します。

  5. 保護されたリソースへのアクセスを要求している有線ラップトップ ユーザーからのトラフィックがデバイスに到着します。手順 3 で識別されたすべての条件が満たされ、セキュリティ ポリシーで許可されているため、デバイスはリソースへのユーザー接続を許可します。

  6. インターネットへのアクセスを要求しているタブレットユーザーからのトラフィックがデバイスに到着します。手順 3 で特定されたすべての条件が満たされ、セキュリティ ポリシーで許可されているため、デバイスはユーザーのインターネットへの接続を許可します。

ドメインと関心のあるグループについて

デバイス上でユーザー ID グループ情報を管理する方法は、次の 2 つの概念によって決まります。

  • ドメイン グループ

    デバイスは、ドメイン名前空間内のユーザー名の処理方法に関して、通常のコースに従います。名前空間を使用して、同じ名前 ( adminなど) を区別しますが、異なるソースからのものであり、異なるドメインにあります。これらは異なるドメインに属しているため、名前が競合することはありません。

    IP ユーザー マッピングの一部であるグループは、そのドメインが特定のドメインであるか GLOBAL ドメインであるかに関係なく、常にドメインに属します。IP ユーザー マッピングでドメイン名が指定されていない場合は、GLOBAL ドメインが想定されます。

    表1は、CPMから得られたIPユーザーマッピング情報に基づいて、グループのドメインがどのように決定されるかを示しています。

    表 1: グループへのドメインの割り当て

    IP ユーザー マッピングにドメイン名が含まれていますか。

    グループにはどのドメインが適用されますか?

    いいえ

    例えば:

    IP, , user1, group-list
    

    2 番目のコンマはドメイン名のプレースホルダーとして機能し、GLOBAL ドメインが適用されます。

    グループリストに含まれるグループは、GLOBALドメインに属します。

    はい

    例えば:

    IP, domain1, user1, group-list
    
    メモ:

    この例では、IP ユーザー マッピングにより、ドメイン名が domain1 として指定されています。

    ドメイン名 domain1 は、CPM からの IP ユーザーマッピングに含まれ、使用されます。これは、パケット転送エンジンの ClearPass 認証テーブル内の認証済みユーザーのエントリに保持されます。

  • 関心のあるグループ

    グループは、セキュリティ ポリシーによって参照されている場合、つまりポリシーの source-identity フィールドで指定されている場合に、 対象グループ として認定されます。ルーティングエンジン認証テーブルの各ユーザーエントリーには、セキュリティポリシーが存在するグループの名前を識別するポリシーリストによって参照されるグループが含まれています。ユーザーエントリーに含まれるグループが現在セキュリティポリシーで使用されていない場合、そのグループはこのリストに含まれません。グループは、ポリシー リストによって参照されるグループに出入りできます。

    • 関心のあるグループリスト

      関心のあるグループリスト、またはポリシーによって参照されるグループのリストは、グループ全体のサブセットです。これは、ユーザー認証エントリ内のグループリストとセキュリティポリシーのソースIDリストの共通部分です。つまり、ClearPass 認証テーブルのユーザー エントリに含まれるすべてのグループは、関心のあるグループと見なされます。ルーティング エンジンは、セキュリティ ポリシーによって参照されるグループのみをパケット転送エンジンの ClearPass 認証テーブル内のユーザー エントリに同期します。

      仕組みは次のとおりです。

      • UserID デーモンは、CPM から完全な IP ユーザーロール (グループ) マッピングを取得します。

      • UserID デーモンは、各グループについて、そのグループを参照するセキュリティー・ポリシーがあるかどうかを判別することによって、それがインタレスト・グループであるかどうかを識別します。該当するグループはすべて、ルーティング エンジンのポリシー リストで参照されるグループに含まれます。UserID デーモンは、パケット転送エンジン対象グループの ClearPass 認証テーブル内のユーザーエントリーに、残りのユーザー認証情報および ID 情報とともに同期します。

      ルーティング・エンジン上のユーザー・エントリーの対象グループ・リストは、以下のイベントに基づいて変わることがあります:

      • ルーティング エンジンのユーザー エントリーに含まれるグループを参照する新しいセキュリティ ポリシーが設定されていますが、そのグループはエントリーの参照先グループのリストにまだ含まれていません。

      • source-identity でグループを参照する現在設定されているセキュリティポリシーは削除されます。

      次の例を考えてみます。

      • CPPMが2人のユーザーに関する次の情報をSRXシリーズファイアウォールに投稿したとします。

      • デバイスがポスチャをマッピングし、グループとして定義すると、デバイスのルーティング エンジン認証テーブル内の 2 つのユーザー エントリーは次のように表示されます。

      • 複数のセキュリティ ポリシーに、group1、group3、posture-healthy のいずれかを参照する source-identity フィールドが含まれているとします。

        上記のセット (元のグループリストと、グループを参照するセキュリティポリシーのリスト) の共通部分により、次の対象グループリストが作成されます。

        • ユーザ John の場合、ポリシー リストで参照されるグループには、group1 と posture-healthy が含まれます。

        • ユーザ abe の場合、ポリシー リストで参照されるグループには、group1、group3、および posture-healthy が含まれます。

      ここで、source-identity フィールドに group1 を指定したセキュリティ ポリシーが削除されたとします。2 人のユーザー(john と abe)のユーザー認証エントリのポリシー リストによって参照されるグループが変更され、次の結果が生成されます。

      • ユーザー John の場合、リストには posture-healthy のみが含まれます。

      • ユーザ abe の場合、リストには group3 と posture-healthy が含まれます。

    表 2 は、グループを参照するセキュリティ ポリシーが ClearPass 認証テーブルにどのように影響するかを示しています。また、グループがセキュリティ ポリシーによって参照 されていない ため、関心のあるグループではない場合の ClearPass 認証テーブルへの影響も示します。

    表 2: 関心のあるグループ: ClearPass 認証テーブルへの影響

    セキュリティ ポリシーの構成と変更

    ClearPass 認証テーブルのパケット転送エンジン エントリーへの影響

    Case 1:

    SRXシリーズファイアウォールは、ユーザーのIPユーザーマッピングをCPPMから取得します。

    ユーザー マッピング内のどのグループも、セキュリティ ポリシーによって参照されません。

    CPMからのIPユーザーマッピング:

    203.0.113.9, ,user1, g1, g2, g3, g4
    

    このユーザーのパケット転送エンジンの ClearPass 認証テーブルに書き込まれるユーザー認証エントリーには、グループが含まれていません。

    203.0.113.9 , ,user1 
    

    Case 2:

    SRXシリーズファイアウォールは、ユーザーのIPユーザーマッピングをCPPMから取得します。グループリストをセキュリティポリシーリストと照合し、そのうちの2つのグループがセキュリティポリシーによって参照されていることを検出します。

    ルーティングエンジンでのIPユーザーマッピング:

    192.0.2.1, domain1, user2, g1, g2, g3, g4
    

    このユーザーのパケット転送エンジン上の ClearPass 認証テーブルに書き込まれるユーザー認証エントリーには、ルーティング エンジンのポリシー リストで参照されるグループに含まれる以下のグループが含まれています。

    192.0.2.1, domain1, user2, g2, g4
    

ユーザーが他のソースによってすでに認証されている場合

例えば、パケット転送エンジン上のデバイス ルーティング エンジン認証テーブルや個々の Microsoft Active Directory 認証テーブルには、Active Directory によって認証されたユーザーのエントリーが含まれていることがあります。通常どおり、CPPMはユーザーのIPユーザーマッピングをデバイスに送信します。ルーティング エンジンの認証テーブルは Active Directory と ClearPass の両方に共通であるため、デバイスはこの問題を解決する必要があります。

デバイスが状況を処理する方法は次のとおりです。

  • ルーティングエンジン認証テーブルで、次の操作を行います。

    • デバイスは、共通のルーティングエンジン認証テーブルにあるユーザーのActive Directory認証エントリーを、CPMからのユーザーのIPユーザーマッピングから新しく生成されたもので上書きします。

      これで、IPアドレスまたはユーザー名の競合は発生しません。

  • パケット転送エンジン上:

    • デバイスは、ユーザーの既存のアクティブディレクトリ認証エントリをアクティブディレクトリ認証テーブルから削除します。

      これにより、IPアドレスに関連付けられているアクティブなセッションが削除されます。

    • デバイスは、パケット転送エンジンのClearPass認証テーブルに、PPM認証されたユーザーの新しいエントリを生成します。

      IPユーザー マッピング エントリに関連付けられたトラフィックは、ClearPass 認証テーブル内のユーザー認証に基づいて新しいセッションを開始します。

例:Aruba ClearPassを認証ソースとして使用したSRXシリーズのセキュリティポリシーの適用

この例では、Aruba ClearPass Policy Managerを認証ソースとする、SRXシリーズファイアウォールに統合されたClearPass認証および実施機能を使用して、リソースを保護し、インターネットへのアクセスを制御するためのセキュリティを構成する方法について説明します。SRXシリーズの統合されたClearPass機能を使用すると、ユーザー名、グループ名、またはユーザーのグループとデバイスタイプを結び付けるロールの名前でユーザーを識別することで、会社のリソースとインターネットへのアクセスを制御するセキュリティポリシーを構成できます。

今日のネットワーク環境は、 場所、時間 、デバイスへのアクセスを多かれ少なかれサポートし、ユーザーがネットワーク接続された複数のデバイスを同時に使用できるため、さまざまな種類の攻撃に対してよりオープンになっています。ユーザー名でユーザーを識別できるため、統合されたClearPass認証および強制機能により、これらの機能がもたらすセキュリティギャップが狭まります。

ユーザー認証情報とID情報がCPPMからSRXシリーズファイアウォールに伝達される方法の詳細については、以下のトピックを参照してください。

この例では、次のプロセスについて説明します。

  • デバイスのIPアドレスではなく、ユーザー名またはグループ名に基づいてユーザーレベルでアクセスを制御する方法。

    セキュリティー・ポリシーで source-identity パラメーターを使用して、ユーザーの名前、または CPM によって認証が行われるユーザー・グループの名前を指定できます。このポリシーは、使用するデバイスに関係なく、ユーザーが保護されたリソースまたはインターネットにアクセスしようとしたときに生成されたトラフィックに適用されます。アクセス制御は、ユーザーのデバイスのIPアドレスに直接ではなく、ユーザー名に関連付けられています。

    1 人のユーザーに対して、指定したゾーンと宛先アドレス、またはユーザーが属するグループによって区別される異なるアクションを指定する異なるセキュリティ ポリシーを構成できます。

  • ClearPass 認証テーブルの内容を表示および解釈する方法。

    SRXシリーズファイアウォールは、CPMから受信したユーザー認証情報とID情報を含むClearPass認証テーブルを作成します。デバイスは、リソースへのアクセスを要求するユーザーを認証するためにテーブルを参照します。

    ClearPass 認証テーブルの内容は動的です。これらは、さまざまなイベントに応答するユーザーアクティビティや、グループを参照するセキュリティポリシーに関するユーザーアクティビティを反映するように変更されます。

    たとえば、ユーザーがネットワークからログアウトしたり、ネットワークにログ インしたりすると、ClearPass 認証テーブルが変更されます。これは、ユーザーがグループから削除された場合や、ユーザーが属するグループを指定する参照セキュリティ ポリシーが削除された場合と同様です。後者の場合、ユーザーエントリには、そのグループに属するユーザーが表示されなくなります。

    この例では、ClearPass 認証テーブルの内容が表示され、2 つのイベントによって行われた変更が示されます。ユーザーのコンテンツが表示されます。

    • 特定のユーザーがネットワークからログアウトする前後

    • 参照されたセキュリティポリシーが削除される前と後

      セキュリティ ポリシーによって参照されるグループに属していたユーザーのエントリは、ポリシーが削除される前と後に表示されます。

要件

このセクションでは、この例のトポロジーのソフトウェア要件とハードウェア要件を定義します。トポロジの設計については、 図 3 を参照してください。

ハードウェアおよびソフトウェアコンポーネントは次のとおりです。

  • Aruba ClearPass。ClearPass Policy Manager(CPPM)は、ローカル認証ソースを使用してユーザーを認証するように構成されています。

    CPPMは、ユーザー名、ユーザーが属するグループの名前のリスト、使用されているデバイスのIPアドレス、デバイスポスチャトークンなどのユーザー認証情報とID情報をSRXシリーズファイアウォールに提供するように設定されていることを前提としています。

  • 統合されたClearPass機能を含むJunos OSを実行するSRXシリーズファイアウォール。

  • 6 台のサーバーで構成されるサーバー ファームで、すべてサーバー ゾーン内にあります。

    • マーケティングサーバー保護(203.0.113.23)

    • 人事サーバー (203.0.113.25 )

    • アカウンティングサーバ(203.0.113.72)

    • パブリックサーバー(203.0.113.62)

    • 企業サーバー (203.0.113.71)

    • 販売サーバー (203.0.113.81)

  • ArubaOSを実行するAC 7010 Arubaクラウドサービスコントローラ。

  • ArubaOSを実行するAruba AP無線アクセス・コントローラー。

    Aruba APはAC7010に接続されています。

    無線ユーザーは、Aruba APを介してCPPMに接続します。

  • 有線802.1アクセスデバイスとして使用されるジュニパーネットワークスEX4300スイッチ。

    有線ユーザーは、EX4300スイッチを使用してCPPMに接続します。

  • 6つのエンドユーザーシステム:

    • Microsoft OS を実行する有線ネットワークに接続された 3 台の PC

    • Aruba APアクセスデバイスを介してネットワークにアクセスする2台のBYODデバイス

    • Microsoft OSを実行している1台のワイヤレスラップトップ

概要

CPPMは、統合されたClearPass機能の認証ソースとして、SRXシリーズファイアウォールのユーザー認証情報とID情報を投稿します。この情報を受信すると、SRXシリーズのUserIDデーモンがその情報を処理し、認証済みユーザーのエントリーをルーティングエンジン認証テーブルに生成してから、その情報をパケット転送エンジン側のClearPass認証テーブルに同期させます。

SRXシリーズファイアウォールでは、ユーザーがアクセスリクエストを行い、ユーザーのデバイスから生成されたトラフィックがSRXシリーズファイアウォールに到達する際に、ユーザーが認証されていることを確認するために、ユーザー認証情報とID情報が必要です。source-identity パラメータに、ユーザーが属するユーザー名またはグループの名前を指定するセキュリティ ポリシーが存在する場合、SRX シリーズ ファイアウォールは ClearPass 認証テーブルの内容からそのユーザーのエントリーを検索します。

ClearPass認証テーブルにユーザーのエントリーが見つからない場合、SRXシリーズファイアウォールは、他の認証テーブルを含む検索順序を設定していれば、他の認証テーブルを検索できます。認証テーブルの検索順序については、 統合 型ClearPass認証および強制の設定 を参照してください。

統合されたClearPass機能を使用すると、ユーザー名または所属するグループの名前に基づいてユーザーが発行したトラフィックを照合するように構成されたID認識セキュリティポリシーを作成できます。

ロールマッピングは、SRXシリーズファイアウォールではなく、CPMで設定します。

たとえば、デバイスの種類のロール マッピングでは、ユーザー ID を会社所有のコンピューターに結び付けることができます。このロールは、ルールにマップされているすべてのユーザーに適用するように構成されたセキュリティ ポリシー内のグループとして指定できます。この場合、CPPMがルールに対して設定した条件(会社所有のコンピューターの使用)は、ルールにマッピングされたすべてのユーザーに適用されます。SRXシリーズファイアウォールは条件を考慮せず、CPMからのルールを受け入れます。

この例に含まれる以下の構成は、ルールマッピングを通じてCPPMによって定義されたために使用されるデバイスのタイプに基づいて適用されるセキュリティポリシーをカバーしています。CPPMは、セキュリティポリシーでグループとして使用される以下のマッピングされたルールをSRXシリーズファイアウォールに投稿したことを前提としています。

  • Marketing-Access-for-PCS-limited-group

    jxchan をデバイス タイプ PC にマップします。

    source-identity フィールドに marketing-access-for-pcs-limited-group を指定するポリシーでは、jxchan およびそれにマップされている他のユーザーが、会社所有であるかどうかにかかわらず、自分の PC を使用してマーケティングサーバーで保護されたサーバーにアクセスできます。

  • アカウンティンググループと会社デバイス

    会社のデバイスを使用して会計グループに所属するユーザーをマッピングします。CPPMは、ロールaccounting-grp-and-company-deviceをSRXシリーズファイアウォールに送信します。マッピングは、役割マッピング規則によって CPPM 上で行われます。

    ソース ID フィールドで accounting-grp-and-company-device を指定するポリシーでは、ルールにマップされているユーザーがアカウンティングサーバー上の保護されたリソースにアクセスできます。グループ会計-grpがルールにマッピングされます。したがって、マッピングされたルールは accounting-grp のメンバーに適用されます。

    ユーザー viki2 は accounting-grp に属しています。すべての条件に当てはまる場合、つまり、viki2が会社所有のデバイスを使用していて、ポリシーでアクセスが許可されている場合、viki2はaccounting-server上のリソースへのアクセスを許可されます。ただし、SRXシリーズファイアウォールはルールを分析しないことを思い出してください。代わりに、CPMによってマップされているすべてのユーザーに適用されます。

  • ゲストデバイス-BYOD

    ゲスト グループをデバイス タイプ byod(ネットワークに持ち込まれるユーザー所有のデバイス)にマッピングします。

    ソース ID フィールドで guest-device-byod を指定するポリシーは、ルールにマップされているユーザーがスマートフォンまたはその他のユーザー所有デバイスを使用している場合、サーバー ゾーン内のすべてのサーバーへのアクセスを拒否します。ユーザー名 guest2 は、CPM によってこのルールにマッピングされます。

いずれの場合も、ユーザーがセキュリティ ポリシーの条件に従ってアクセスを許可または拒否されている場合は、次の条件が存在すると見なすことができます。

  • CPPMは、ユーザーとグループの正しい認証情報をSRXシリーズファイアウォールに投稿しました。

  • SRXシリーズファイアウォールは、認証されたユーザー情報を正しく処理し、ClearPass認証テーブルにユーザーとグループのエントリーを生成しました。

Junos OSリリース15.1X49-D130以降、SRXシリーズファイアウォールは、セキュリティポリシーでソースIDに関連付けられたIPv6アドレスの使用をサポートしています。IPv4 または IPv6 エントリが存在する場合、そのエントリに一致するポリシーがトラフィックに適用され、アクセスが許可または拒否されます。

表 3 は、ユーザー、そのグループ、およびユーザーが属するゾーンをまとめたものです。すべてのユーザーは、デフォルトの GLOBAL ドメインに属しています。

表 3: セキュリティ ポリシーの例の認証済みユーザー情報

ユーザー

グループ

ゾーン

阿部 (abew1)

  • マーケティング-アクセス-制限-GRP

マーケティングゾーン

ジョン(jxchan)

  • 姿勢健康

  • Marketing-Access-for-PCS-limited-group

  • マーケティング一般

  • 販売限定

  • コーポレートリミテッド

マーケティングゾーン

林 (陳1)

  • 姿勢健康

  • 人事グループ:

  • アカウンティング限定

  • コーポレートリミテッド

人材ゾーン

Viki (viki2)

  • 姿勢健康

  • アカウンティング-GRP

  • アカウンティンググループと会社デバイス

  • コーポレートリミテッド

アカウンティングゾーン

ゲスト1

  • 姿勢健康

  • ゲスト

パブリックゾーン

ゲスト2

  • 姿勢健康

  • ゲストデバイス-BYOD

パブリックゾーン

トポロジ

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

図 3: セキュリティ ポリシーによる統合型 ClearPass 認証強制のトポロジーの例 Topology for the Integrated ClearPass Authentication Enforcement Through Security Policies Example

構成

このセクションでは、CPMによって認証されたユーザーによって発行されたトラフィックと一致するセキュリティポリシーを含めるようにSRXシリーズファイアウォールを設定する方法について説明します。

CLIクイック構成

この例を迅速に設定するには、以下のステートメントをコピーして、テキストファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、ステートメントを 階層レベルでCLI [edit] にコピーアンドペーストして、設定モードから を入力します commit

インターフェイス、ゾーン、アドレス帳の設定

手順

次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、 設定モードでのCLIエディターの使用を参照してください。

次のインターフェイスを設定し、ゾーンに割り当てます。

  • ge-0/0/3.0 > マーケティングゾーン

  • ge-0/0/3.1 >人的資源ゾーン

  • ge-0/0/3.2> アカウンティングゾーン

  • ge-0/0/4.0 >パブリックゾーン

  • ge-0/0/4.1 > servers-zone

この例では論理インターフェイスを使用しているため、VLAN タギングを設定する必要があります。

  1. SRXシリーズファイアウォールのインターフェイスを設定します。

  2. ゾーンを設定します。

  3. セキュリティポリシーで宛先アドレスとして使用するサーバーのIPアドレスを含むアドレス帳を設定します。

  4. サーバーゾーンアドレスのアドレス帳をサーバーゾーンにアタッチします。

結果

設定モードから、 コマンドを入力して show interfaces インターフェイスの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。

設定モードから、 コマンドを入力して show security zones ゾーンの設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。

設定モードから、 コマンドを入力して show security address-book アドレス帳の設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。

会社のリソースへのユーザーアクセスを制御するためのID対応セキュリティポリシーの構成

手順

このタスクでは、使用するデバイスのIPアドレスではなく、ユーザー名またはグループ名に基づいて、ユーザーのリソースへのアクセスに適用されるセキュリティポリシーを設定します。

すべてのユーザーがデフォルトの GLOBAL ドメインに属していることに注意してください。

  1. source-identityとしてマーケティングアクセス-for-pcs-limited-groupを指定するセキュリティポリシーを設定します。これにより、このグループに属するユーザーjxchanは、PCを使用しているときに、個人デバイスであろうと会社所有デバイスであろうと、サーバーゾーン内の任意のサーバーにアクセスできます。ユーザー名jxchanは、CPPMによって、PC限定グループのマーケティングアクセスルールにマッピングされます。

  2. ユーザー abew1 が使用するデバイスに関係なく、servers-zone 内のマーケティングゾーンで保護されたサーバー (IP アドレス 203.0.113.23) へのアクセスを許可するセキュリティポリシーを設定します。

  3. ユーザーviki2が会社所有のデバイスを使用しているときに、サーバーゾーン内のアカウンティングサーバー(IPアドレス203.0.113.72)へのアクセスを許可するセキュリティポリシーを構成します。ユーザーviki2は、CPMによって会社所有デバイスルール(accounting-grp-and-company-device)にマッピングされているaccounting-grpに属しています。

  4. 企業限定グループに属するユーザーが、人事ゾーンから要求を開始するときに、サーバー ゾーン内の企業サーバー サーバー (IP アドレス 203.0.113.71) への制限付きアクセスを許可するセキュリティ ポリシーを構成します。

    送信元アドレスが「any」として指定されている場合、ポリシーは企業限定グループにも属する他のユーザーに適用されます。

  5. サーバー ゾーン内の企業サーバー (IP アドレス 203.0.113.71) サーバーへのユーザー abew1 アクセスを許可するセキュリティ ポリシーを構成します。ユーザー abew1 は、セキュリティー・ポリシーが適用される marketing-access-limited-grp に属しています。

  6. sales-limited-group に属するユーザーがマーケティング ゾーンから要求を開始するときに、人事サーバー (IP アドレス 203.0.113.81) サーバーへのアクセスを許可するセキュリティ ポリシーを構成します。ユーザーjxchanは販売限定グループに属しています。

  7. ゲスト グループに属するユーザーが servers-zone 内のpublic-server(IP アドレス 203.0.113.91)にアクセスできるようにするセキュリティ ポリシーを構成します。

  8. guest-device-byodグループに属するユーザーが、自分のデバイスを使用する場合に、サーバーゾーン内のサーバーへのアクセスを拒否するセキュリティポリシーを設定します。

結果

設定モードから、 コマンドを入力して show security policies 、統合 ClearPass のセキュリティ ポリシーの設定を確認します。

出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。

検証

このセクションでは、ユーザー認証エントリの一部が変更される原因となる特定のイベントが発生した後、ClearPass 認証テーブルの内容を検証します。また、delete コマンドの発行後に ClearPass 認証テーブルが正常に削除されたことを確認する方法も示します。次の部分が含まれています。

認証済みユーザーがネットワークからログアウトする前後の ClearPass 認証テーブルの内容の表示

目的

特定の認証済みユーザーがネットワークにログインしたとき、およびそのユーザーがログアウトした後に、ClearPass 認証テーブルの内容を表示します。

アクション

show services user-identification authentication-table authentication-source authentication-source aruba-clearpassと呼ばれるClearPass認証テーブルのコマンドを入力します。ClearPass 認証テーブルにユーザー viki2 のエントリが含まれていることに注意してください。

viki2がネットワークからログアウトした後、同じコマンドをもう一度入力します。ClearPass 認証テーブルに viki2 のエントリが含まれなくなっていることに注意してください。

参照されたセキュリティポリシーを削除する前後の認証テーブルの内容を表示する

目的

セキュリティ ポリシーによって参照されるグループに属する特定のユーザー(lchen1)の ClearPass 認証テーブルの内容を表示します。そのセキュリティ ポリシーを削除してから、そのユーザーのエントリを再度表示します。

アクション

show service user-identification authentication-table authentication-source user user-nameコマンドを入力して、特定のユーザー lchen1 の ClearPass 認証テーブルのエントリーを表示します。グループ企業限定が含まれていることに注意してください。

人事-p1 セキュリティ ポリシー source-identity フィールドは、グループ企業限定を参照します。上記の ClearPass 認証エントリに示されているように、ユーザー lchen1 はそのグループに属しています。次に、person-resources-p1 が参照するセキュリティポリシーの設定を示します。

source-identity パラメーターが corporate-limited というグループを参照している human-resources-p1 セキュリティー・ポリシーを削除した後、同じコマンドを再度入力します。lchen1 の認証エントリに企業限定グループが含まれていないことに注意してください。

変更後の ClearPass 認証テーブルの状態の確認には、別の方法を使用します。テーブル全体を表示して、グループ(企業限定)がどのユーザーエントリにも含まれていないことを確認します。複数のユーザーが企業限定グループに属している場合、影響を受けるすべてのユーザーの認証エントリにはそのグループ名が表示されないことに注意してください。

動作モードから コマンド show services user-identification authentication-table authentication-source aruba-clearpass を入力します。

リリース履歴テーブル
リリース
説明
15.1X49-D130
Junos OSリリース15.1X49-D130以降、SRXシリーズファイアウォールは、セキュリティポリシーでソースIDに関連付けられたIPv6アドレスの使用をサポートしています。IPv4 または IPv6 エントリが存在する場合、そのエントリに一致するポリシーがトラフィックに適用され、アクセスが許可または拒否されます。