Cisco ISEのPolicy Setの理解

Cisco ISE(Identity Service Engine)と言うプロダクトがあります。平たく言うとRADIUSサーバですが、もっと色々な機能があります。AAA(Authentication、Authorization、Accounting)をひとつで担えるようなプロダクトです。もちろん外部ADサーバと連携したりもできます。

このAAAの中核を為すのがポリシーで、ISEの操作画面上では「Policy Set」として出てきます。これが(私は)一癖ある(と思っている)もので、自分の勉強も兼て記載しておきます。

なお、スクリーンショットを何枚か載せていますが、正しい設定という保証はないです。と言うか、画面の雰囲気を共有するのが目的なので設定値は適当なものを入れてスクリーンを撮っています。

Policy Set(ポリシー)とは

こう言う条件の時に認証(Authentication)して、認証されたらこんな権限(Authorization)を与えますよ、と言う方針(Policy)を定義する機能です。

Policyに当てはめる条件

まず最初に設定することになるのは、「どんな時にそのPolicyに当てはめるか」と言う設定です。

Policy Setの設定画面を開くとまず出てきます。Conditionsは条件ですので、例えば、「有線なら」「無線なら」「Network Deviceが東京なら」「802.1X認証リクエストなら」と言った条件を設定します。

Allowed Protocolsは許可するプロトコルで、別途定義したプロファイルを当てはめます。そのプロファイルでは例えばPEAPを許可するか、EAP-TLSを許可するか、と言った設定ができます。

そのため、例えばConditionsに「802.1X認証なら」と言う条件を設定しても、Allowed ProtocolでPEAPやMS-CHAPV2等のプロトコルが許可されてなければ、このポリシーに引っ掛からなくなります。

今回は詳細を割愛しますが、意図したポリシーに引っ掛からない時は、Live Logを見て、想定のクライアントがどのようなプロトコルを使用しているか、Cisco ISEがどんな情報を取得できているかを確認してトラブルシュートを行って行きます。

Authentication Policy

Policy Setを作成したら、「その中に」Authentication Policyと言うものがあります。その名の通りでどういう時に認証するかを定義します。例えば、証明書認証が成功したら、クライアントがISEに登録されていたら、と言う条件を設定します。

Authorization Policy

Authentication Policyを設定したら、次にAuthorizationつまり認可の設定をします。条件にマッチしたら事前定義したネットワークへのアクセスを認可します。例えば、特定のポスチャを持っていればVLAN10へのネットワークを許可します。

Authentication vs. Authorization

私だけでしょうか、このAuthentication PolicyとAuthorization Policyの使い分けが難しい、癖があると感じています。Authenticationは認証なので、どういう時に許可する、Authorizationは認可なので、どういう認証をされたクライアントがどんな権限を得るか、と言う考え方はさほど難しくありません。

しかし、実際に設計を進めると、ここが難しいのです。具体的には認証と思ったことを認可で行わなければならなかったり、そこの境界線が私にはまだまだ慣れない部分であります。

例:証明書認証+ポスチャチェック

証明書認証とポスチャチェックを組み合わせた認証認可という設定をする必要がありました。結論から言うと、証明書認証の部分はAuthenticationで良いのですが、ポスチャチェックの部分はAuthorizationでした。

理由としては、ポスチャチェックのためにクライアントにAgentをインストールさせる必要があり、それをダウンロードするためのポータルサイトにリダイレクトさせ、ダウンロードした後にAgentを実行してISEがポスチャを確認します。そのため、認証後に暫定的にネットワークアクセスを与えてISEと通信するのです。確かに言われてみれば、ネットワークアクセスが全くない状態でポータルサイトにアクセスしたり、AgentとISEが通信するのは無理なので納得がいきます。

例:MACアドレス認証(MAC Address Authentication Bypass)

MACアドレス認証のことをCiscoではMAB(MAC Address Authentication Bypass)と呼んでいるようです。と言うのは余談ですが、要はISEに事前に登録されているMACアドレスを持つクライアントなら認証しますと言う認証方法です。

このケースの場合、「MABであること」をAuthentication Policyの条件として、ISEに登録されているかをチェックします。「Use」の部分がInternal Endpointになります。

そして認可の方に、クライアントがどのIdentityグループに所属していたら、どんな許可を与える、と言う設定をするようです。

私としては、特定のADに所属していたら認証して、同様の条件で特定の認可をする、と言うイメージだったのですが、実際にはそもそも登録があれば認証して、事前定義のIdentity Groupに登録されていたら認可と言う設定だったようです。

伝わりますか。つまり、私の理解はこうでした。

①クライアントがISEに登録されていて(認証条件)

②それが事前定義したIdentity Groupのクライアントなら(認証条件)

③ネットワークへのアクセスをする(認可)

しかし実際には、

①クライアントがISEに登録されていて(認証条件)

②それが事前定義したIdentity Groupのクライアントなら(認可条件)

③ネットワークへのアクセスをする(認可)

と言うことです。認証と認可の「結果」については、セオリー通り、認証されたらどうするか、認可されたらどうするかを定義するので難しくありませんが、それぞれの「条件」が難しいと感じます。

めっさん
  • めっさん
  • 当サイトの管理人。ニューヨークの大学を飛び級で卒業。その後日系企業でグローバル案件に携わる。大小様々な企業を転々としながら、マレーシアやアメリカへの赴任経験を持つ。バイリンガルITエンジニアとしていかに楽に稼ぐか日々考えている。年齢は秘密だけど定年も間近かな。

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です