Cisco Secure ACS Solution Engine ユーザ ガイド Version 4.0
ポスチャ確認
ポスチャ確認
発行日;2012/01/10 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 7MB) | フィードバック

目次

ポスチャ確認

ポスチャ確認とは

ネットワーク アクセス コントロールの概要

NAC の利点

NAC アーキテクチャの概要

ポスチャ トークン

ACS でのポスチャ確認

ACS での NAC の設定

ポスチャ確認プロセス

ポリシーの概要

ポスチャのクレデンシャルとアトリビュートについて

拡張アトリビュート

内部ポリシー

内部ポリシーについて

規則、規則要素、およびアトリビュートについて

内部ポリシー設定オプション

外部ポリシー

外部ポリシーについて

外部ポリシー設定オプション

NAH ポリシー

外部監査サーバについて

外部監査サーバ設定オプション

ポリシーの設定

ポスチャ確認ポリシーの設定

内部ポリシーの作成

ポリシーの編集

ポリシーまたはポリシー規則のクローニング

ポリシーの名前の変更

ポリシーまたは規則の削除

条件コンポーネントまたは条件セットの削除

外部ポリシー サーバの設定

外部ポスチャ確認サーバの編集

外部ポスチャ確認サーバの削除

外部監査ポスチャ確認サーバの設定

外部ポスチャ確認監査サーバの編集

外部ポスチャ確認監査サーバの削除

ポスチャ確認がプロファイルベースのポリシーに適合する仕組み

ポスチャ確認

Cisco Secure Access Control Server Release 4.0 Solution Engine(以降は ACS と表記)が幅広い Cisco Network Access Control(NAC; ネットワーク アクセス コントロール)ソリューションの一部として展開される場合、ACS ではポスチャ確認をサポートします。

この章は、次の項で構成されています。

「ポスチャ確認とは」

「ネットワーク アクセス コントロールの概要」

「ACS でのポスチャ確認」

「ポリシーの設定」(内部、外部、および監査サーバを含む)

「ポスチャ確認がプロファイルベースのポリシーに適合する仕組み」

ポスチャ確認とは

ポスチャという用語は、ネットワークへのアクセスを求めるエンドポイント デバイスの実行および「健全性」に関与するアトリビュートの集合を表すために使用されます。このようなアトリビュートには、エンドポイントのデバイス タイプやオペレーティング システムに関連するアトリビュート、およびエンドポイント上のさまざまなセキュリティ アプリケーション(AntiVirus(AV; アンチウイルス)検出ソフトウェアなど)に属するアトリビュートがあります。

ポスチャ確認、つまりポスチャ アセスメントとは、規則のセットをポスチャ データに適用して、そのエンドポイントに対する信頼レベルのアセスメント(ポスチャ トークン)を提供する処理を指します。ポスチャ トークンは、ネットワーク アクセスの認可規則における条件の 1 つです。ポスチャ確認を従来のユーザ認証と併せて使用することで、エンドポイント デバイスおよびユーザの完全なセキュリティ アセスメントを実現します。

ネットワーク アクセス コントロールの概要

NAC は、シスコシステムズが主導する業界で確立されたテクノロジーとソリューションを組み合せたものです。NAC はネットワーク インフラストラクチャを使用して、ネットワーク コンピューティング リソースへのアクセスを求めるすべてのデバイスをセキュリティ ポリシーに適合させます。その結果、新たなセキュリティの脅威による損害を抑えます。NAC を使用することにより、ポリシーに準拠した信頼できるエンドポイント デバイス(PC、サーバ、PDA など)に対してのみネットワーク アクセスを許可し、準拠しないデバイスのアクセスを制限することができます。

この項では、次のトピックについて取り上げます。

「NAC の利点」

「NAC アーキテクチャの概要」

「ポスチャ トークン」

「ACS でのポスチャ確認」

NAC ソリューションの詳細については、 http://www.cisco.com/go/NAC を参照してください。

NAC の利点

NAC には次の利点があります。

すべてのネットワークのセキュリティが大幅に向上する :ネットワークの規模や複雑さに関係なく、 NAC によって確実にすべてのエンドポイントが最新のセキュリティ ポリシーに準拠します。NAC を適切に配置すると、操作の重点を対処ではなく予防に置くことができます。そのため、ワーム、ウイルス、スパイウェア、および悪意のあるソフトウェアがネットワークに入り込む前に、予防的に保護できます。

既存の投資価値が拡大する :NAC はシスコのネットワーク インフラストラクチャに統合されるだけではなく、多数の主要ベンダーによるアンチウイルス、セキュリティ、および管理ソリューションとの広範な統合を実現できます。

展開のスケーラビリティおよび包括的な制御範囲が得られる :NAC はすべてのアクセス方式(LAN、WAN、無線、およびリモート アクセス)に対してアドミッション コントロールを提供します。

企業の復元力が強化される :NAC は、準拠しない不適切なエンドポイントによってネットワークのアベイラビリティが影響を受けないようにします。

運用費用が削減される:NAC は 、不適合なシステム、欠陥のあるシステム、およびウイルス感染したシステムを特定し、修復する費用を削減します。

NAC アーキテクチャの概要

図14-1 に、一般的な NAC 展開のコンポーネントを示します。

図14-1 一般的な NAC 展開のコンポーネント

 

一般的な NAC コンポーネントは次のとおりです。

エンドユーザまたはホスト :エンドポイントとも呼ばれます。エンドポイントとは、スイッチ、アクセス ポイント、またはルータに直接接続される PC、ワークステーション、サーバなどのデバイスです。NAC 展開において Cisco Trust Agent(CTA)アプリケーションを実行するホストは、コンピュータから、さらにはコンピュータにインストール済みの NAC 準拠アプリケーションから、ポスチャ データを収集します。ポスチャ クレデンシャルの詳細については、「ポスチャ確認アトリビュートのデータ タイプ」を参照してください。

NAC 準拠アプリケーションの例には、Cisco Security Agent の他に、Network Associates、Symantec、または Trend Micro のアンチウイルス プログラムがあります。これらのアプリケーションは、ウイルス定義ファイルのバージョン番号など、アプリケーションそのものに関するアトリビュートを CTA に提供します。

NAC Agentless Host(NAH: NAC エージェントレス ホスト)とは、Cisco CTA アプリケーションを実行していないエンドポイントです。

Network Access device(NAD; ネットワーク アクセス デバイス) :NAC 展開において AAA クライアントは NAD と呼ばれます。NAD は、NAC 適用ポイントとして機能するルータやスイッチなど、シスコのネットワーク アクセス デバイスです。

ACS :ACS は内部ポリシー、外部ポリシー サーバ、またはその両方を使用して、ポスチャ クレデンシャルが転送されるエンドポイント デバイスの確認を行います。

外部ポスチャ確認サーバ :これらはポスチャ確認を実行し、ポスチャ トークンを ACS に返します。エージェントレス ホストのある NAC 展開では、特別な種類のポスチャ確認サーバ(監査サーバと呼ばれる)のサービスを呼び出すように ACS を設定できます。監査サーバは、ポート スキャンなど、範囲外の方法を使用してエンドポイント デバイスの健全性を確認し、その結果をポスチャ トークンとして ACS に報告します。

感染修復サーバ :ネットワーク アドミッションの要件を満たさないホストに対して修復やアップグレードのサービスを提供します。

ポスチャ トークン

ポスチャ トークンは、エンドポイント デバイスの状態、またはコンピュータにインストールされた NAC 準拠アプリケーションの状態を示します。コンピュータの状態に関連付けられたトークンは、 System Posture Token (SPT; システム ポスチャ トークン)です。NAC 準拠アプリケーションの状態に関連付けられたトークンは、 Application Posture Token (APT; アプリケーション ポスチャ トークン)です。

APT は、ポスチャ確認要求で受け取るクレデンシャルにポリシーを適用した結果です。ACS は、要求に適用されたすべてのポリシーからの APT を比較することによって、各要求の SPT を決定します。最も重大な APT が SPT になります。

表14-1 に、設定変更できない事前定義済みの 6 つのポスチャ トークンを示します。これらは、システム ポスチャ トークンとアプリケーション ポスチャ トークンに使用されます。ポスチャ トークンを、最小の重大度から順に示します。

 

表14-1 ACS ポスチャ トークン

トークン
説明

Healthy

エンドポイント デバイスは現在必要なクレデンシャルに準拠しているため、このデバイスを制限する必要はありません。

Checkup

エンドポイント デバイスはポリシーの範囲内にありますが、セキュリティ ソフトウェアが最新ではありません。アップデートすることを推奨します。予防的にホストを Healthy 状態に修復するために使用します。

Transition

エンドポイント デバイスはポスチャのチェック処理中です。仮のアクセスが与えられ、完全なポスチャ確認による結果は保留されています。すべてのサービスが実行されていない可能性のあるホストのブート中、または監査結果がまだ利用できない場合に該当します。

Quarantine

エンドポイント デバイスはポリシーの範囲外にあり、修復ネットワークに制限する必要があります。デバイスは実際に他のホストに脅威を与えてはいませんが、攻撃や感染の恐れがあるため、早急にアップデートする必要があります。

Infected

エンドポイント デバイスは、実際に他のホストに対する脅威となっています。ネットワーク アクセスを厳しく制限して修復するか、すべてのネットワーク アクセスを完全に拒否する必要があります。

Unknown

エンドポイント デバイスのポスチャ クレデンシャルを判別できません。ホストを隔離して監査するか、あるいは最終的なポスチャを判別できるまで修復します。

ACS 側から見ると、認可規則に設定されたアクションが SPT の意味を決定します。これらのアクションによって、RADIUS Authorization Component(RAC; RADIUS 認可コンポーネント)、
Downloadable Access-Control list(DACL; ダウンロード可能アクセス コントロール リスト)、またはその両方がトークンに関連付けられます。また、認可規則では条件の一部としてユーザ グループを指定できます。RAC の設定の詳細については、「RADIUS 認可コンポーネントの追加」を参照してください。認可規則をネットワーク アクセス プロファイルの一部として設定する方法の詳細については、「プロファイルの設定」を参照してください。

ポスチャ確認要求の結果、アクセスが厳しく拒否されない SPT が生成された場合は、Passed Authentications ログに記録されます。ポスチャ確認要求の結果、アクセスが拒否される SPT が生成された場合は、Failed Attempts ログに記録されます。ロギングとレポートの詳細については、「ログ内のポスチャ確認アトリビュート」を参照してください。

ACS は APT だけを使用して SPT を判別します。しかし、ポスチャ確認の結果を受信するエンドポイント デバイスでは、関連する NAC 準拠アプリケーションにとっての意味に基づいて APT を使用できます。

ACS でのポスチャ確認

この項では、ACS でのポスチャ確認および NAC サポートについて概要を説明します。

「ACS での NAC の設定」

「ポスチャ確認プロセス」

「ポリシーの概要」

「内部ポリシー」

「外部ポリシー」

「NAH ポリシー」

ACS での NAC の設定

この項では、ACS のポスチャ確認を設定する手順の概要と、より詳細な手順の参照先を示します。


) Posture Validation タブを使用してポスチャ ポリシーを作成してから、Network Access Profiles タブ内の Posture Validation リンクを使用して、ポリシーをプロファイルに割り当てます。


始める前に

ACS でポスチャ確認を実行するには、事前にいくつかの設定手順を完了する必要があります。手順の概要は次のとおりです。Cisco.com で詳細な手順を検索する方法については、「ネットワーク アクセス コントロールの概要」を参照してください。

ポスチャ確認を実装するには、次の手順を実行します。


ステップ 1 サーバ証明書をインストールします。EAP トンネルがエンドユーザ クライアントとの NAC 通信を保護するので、ACS は NAC 用のサーバ証明書を必要とします。第三者 Certificate Authority(CA; 認証局)から取得した証明書を使用するか、自己署名証明書を使用します。

サーバ証明書のインストールの詳細な手順については、「ACS サーバ証明書のインストール」を参照してください。自己署名証明書の生成とインストールの詳細な手順については、「自己署名証明書の生成」を参照してください。


自己署名証明書を使用する場合は、その証明書を ACS からエクスポートし、信頼できるルート CA 証明書として、エンドポイント コンピュータ上のローカル ストレージにインポートすることが必要になる場合があります。


ステップ 2 サードパーティ ベンダーからのポスチャ クレデンシャルについては、対応する NAC Attribute
Definition File(ADF; アトリビュート定義ファイル)をインポートする必要があります。インポートの詳細な手順および ADF については、「ベンダーの AV ペア(AVP)のインポート」を参照してください。

ステップ 3 ACS は HTTP 通信もサポートしますが、外部ポリシーをセットアップする場合、または外部ポリシー監査サーバを使用する場合は、ACS の設定時に HTTPS による外部サーバとの通信を計画する必要があります。

ACS は証明書を使用して、監査サーバおよびポスチャ確認サーバを認証します。ACS から証明書を選択するか、または Certificate Trust List(CTL; 証明書信頼リスト)を設定する必要があります。ACS サーバ証明書を発行した CA とは異なる CA を外部サーバで使用する場合には、CTL を設定する必要があります。詳細な手順については、「証明書信頼リストの編集」を参照してください。

外部サーバで自己署名証明書を使用する場合は、CTL を変更する必要はありません。

Web インターフェイスの NAC Attributes Management ページを使用して、監査ベンダーを ACS 内部ディクショナリに追加する必要があります。

ステップ 4 Passed Authentications ログをイネーブルにします。ACS はこのログを使用して、アクセスが厳しく拒否されない場合は必ずポスチャ確認クレデンシャルをすべて記録します。要求が拒否された場合、ACS は結果を Failed Attempts ログに記録します。Passed Authentications ログをイネーブルにするときは、必ず、NAC 関連のアトリビュートを Passed Authentications File Configuration ページの Logged Attributes カラムに移動してください。

このタイプのログを設定する詳細な手順については、「CSV ログの設定」を参照してください。

ステップ 5 NAC アトリビュートを含めるように Failed Attempts ログを設定します。拒否されたポスチャ確認要求は、Failed Attempts ログに記録されます。このログに NAC アトリビュートを含めると、NAC 実装時のエラーをデバッグするときに有用になる場合があります。たとえば、どのポスチャ確認規則も一致しない場合、要求はここに記録されます。Failed Attempts ログを使用すると、エンドポイントから受信された要求内のアトリビュートと、エンドポイントに送信された応答内のアトリビュートの内容を参照できます。

このタイプのログを設定する詳細な手順については、「CSV ログの設定」を参照してください。

ステップ 6 Global Authentication Setup ページで、EAP の下の Allow Posture Validation を選択して、ポスチャ確認をイネーブルにします。レイヤ 2 またはレイヤ 3 サポートについて、手順を完了します。

詳細な手順については、「認証オプションの設定」を参照してください。

ステップ 7 NAC をサポートする AAA クライアントを Network Configuration セクションでまだ設定していない場合は、ここで設定します。

詳細な手順については、「AAA クライアントの追加」を参照してください。

ステップ 8 Network Access Profiles から、ポスチャ確認に使用するユーザ グループをセットアップします。多くの場合、可能性のある SPT ごとに別々のユーザ グループを使用します。したがって、6 つのユーザ グループを選択します。可能であれば、ユーザを認可するように設定されていないグループを選択します。また、ユーザを認可するグループとは大幅に異なるグループを使用することを考慮します。たとえば、ユーザを認可するときに低位番号のグループが使用されている場合は、グループ 494 ~ 499 を使用することを考慮します。

ステップ 9 プロファイルをセットアップする詳細な手順については、「プロファイルの設定」を参照してください。


ヒント ユーザを認可するためのグループと、エンドポイントを認可するためのグループとを混同することがないよう、グループ名を認識しやすい名前に変更することを考慮します。たとえば、グループ 499 を選択して Unknown SPT 関連の認可を含めた場合は、NAC Unknown というグループ名に変更します。詳細な手順については、「ユーザ グループの名前の変更」を参照してください。

ステップ 10 ポスチャ確認規則ごとに、ポスチャ トークンと SPT を割り当てます。これらは後で、ネットワーク アクセスを適切に制限するダウンロード可能 IP ACL セットまたは RAC、あるいはその両方を含むプロファイルと関連付けることができます。

規則を作成する詳細な手順については、「内部ポリシーの作成」を参照してください。詳細な手順については、「ダウンロード可能 IP ACL の追加」(および 「RADIUS 認可コンポーネントの追加」)を参照してください。ポスチャ規則をプロファイルに関連付けるには、「プロファイルの設定」を参照してください。

ステップ 11 エンドポイント デバイスを確認するため、プロファイルごとに、任意の数の規則を含む複数の異なるポスチャ確認ポリシーを作成できます。次の作業が可能です。

a. ポリシーおよび関連する規則を作成できます。この作業には、必須クレデンシャル タイプおよびポリシーの設定作業も含まれます。

詳細な手順については、「ポリシーの設定」を参照してください。

b. Network Access Profiles を使用して、ポスチャ確認ポリシーをプロファイルに割り当て、エンドポイント デバイスを検証できます。

詳細な手順については、「プロファイルの設定」を参照してください。


 

ポスチャ確認プロセス

ACS は、エンドポイント コンピュータから受信したポスチャ アトリビュートを評価します。次に示す概要は、ポスチャ確認に関する手順とシステムの説明です。ポスチャ トークンやポリシーなど、さまざまな概念の詳細については、下記のトピックを参照してください。

1. ネットワーク イベント(たとえば EoLAN Hello =802.1 または NAD 上で EoU ACL によって取得されたトラフィック)の後、NAD はエンドポイントとの EAP カンバセーションを開始し、EAP メッセージをエンドポイントから ACS に転送します。

2. ACS は、PEAP または EAP-FAST(ACS の設定およびエンドポイントのサポートによって異なる)を使用して、ホストとのセキュア カンバセーションを確立します。

3. (EAP-FAST の場合のみ、オプション)ACS はエンドユーザを認証します。

4. ACS はエンドポイントにポスチャ アトリビュートを問い合せます。応答でエンドポイントはポスチャ アトリビュートを ACS に送信します。

5. ACS はポスチャ アトリビュートの評価を内部で実行し、場合によっては外部ポスチャ確認サーバを使用します。評価の結果はアプリケーション ポスチャ トークン(APT)のセットになります。次に ACS は、最も重大な APT を使用してシステム ポスチャ トークン(SPT)を評価します。

6. ネットワーク アクセス プロファイルに設定された認可規則に基づいて、ACS がエンドポイント コンピュータに、システム ポスチャ トークンと、ポスチャ確認要求に適用した各ポリシーの結果を送信した後、EAP セッションを終了します。評価に基づき、ACS はアクセス制限に応じてクライアントにネットワーク アクセスを許可します。あるいは、準拠しないデバイスについて、アクセスを拒否したり、隔離されたネットワーク セグメントに配置したり、コンピューティング リソースへの制限付きアクセスを与えたりすることができます。

RAC 内の各種 RADIUS アトリビュート(ユーザのグループと組み合せることが可能)、ダウンロード可能 ACL、および url-redirect か status-query-timeout を使用して、認可規則にさまざまなタイプの制限を設定できます。

7. ACS が共有 RAC での設定どおりに RADIUS アトリビュートを AAA クライアントに送信します。このアトリビュートには、ACL や、Cisco IOS/PIX 6.0 RADIUS アトリビュート cisco-av-pair で設定されたアトリビュート値のペアが含まれます。

8. ACS がポスチャ確認要求の結果を記録します。要求が拒否されなかった場合、ACS は結果を Passed Authentications ログに記録します(イネーブルになっている場合)。要求が拒否された場合(たとえば、認可ポリシーによって拒否された場合や、一致する必須クレデンシャル タイプを持つポスチャ確認規則がなかった場合など)、ACS は結果を Failed Attempts ログに記録します。

エンドポイントは、自身の設定に従って、ポスチャ確認要求の結果を処理します。AAA クライアントは、自身の RADIUS 応答に、ACS で指定されたとおりにネットワーク アクセスを適用します。ユーザは、プロファイルを設定し、ポスチャ確認の結果として判別されたシステム ポスチャ トークンに基づいて、認可とネットワーク アクセス制御を定義します。

ポリシーの概要

ACS を使用して、内部または外部のポスチャ確認ポリシーを設定することができます。このポリシーは、ユーザ(または外部サーバ)によってポリシーに設定された規則を確認した後で、ポスチャ トークンおよびアクションを返します。

ポリシーは再使用が可能です。つまり、単一のポリシーを複数のネットワーク アクセス プロファイルに関連付けることができます。たとえば、NAC 実装において、NAI ソフトウェアを使用するエンドポイント用と、Symantec ソフトウェアを使用するエンドポイント用に 2 つのプロファイルが必要な場合、どちらのアンチウイルス アプリケーションがインストールされていても、エンドポイントのオペレーティング システムに関する同一の規則を適用することが必要になる場合があります。オペレーティング システムに関する規則を適用する単一のポリシーを作成し、Symantec と NAI のサーバ情報に関連付けることができます。

ポリシーを適用した結果は次のとおりです。

ポスチャ アセスメント :ポリシーの評価結果が適用されるクレデンシャル タイプおよび NAC 準拠アプリケーション

トークン :結果クレデンシャル タイプによって定義されたエンドポイントとアプリケーションのポスチャを表す 6 つの定義済みトークンのいずれか

通知文字列 :ポスチャ アセスメントによって定義されたアプリケーションへのポスチャ確認応答に含まれるオプションのテキスト文字列

ポスチャのクレデンシャルとアトリビュートについて

ポスチャ確認に使用されるクレデンシャルは、エンドポイントから ACS へ送信されるアトリビュート セットです。受信アトリビュートとも呼ばれるこのアトリビュートには、コンピュータのポスチャを判別するポスチャ確認の際に使用されるデータが含まれています。ACS では、各 NAC 準拠アプリケーションからのアトリビュートと、CTA からのアトリビュートは、異なるクレデンシャル タイプと見なされます。

ACS によって確認用に作成されるポリシーを使用する場合、作成する規則は、受信アトリビュートの内容を使用し、ポリシーを適用した結果返される APT を判別します。外部サーバによって確認用に作成されるポリシーを使用する場合、ACS は、指定されたクレデンシャル タイプを外部 NAC サーバに転送します。どちらの場合も、受信アトリビュートの内容には、ポスチャの判別と、コンピュータのネットワーク アドミッションの制御に使用される情報が含まれています。

ACS は、エンドポイントへの応答に NAC アトリビュートを使用します。このアトリビュートは、送信アトリビュートと呼ばれます。たとえば、APT と SPT は、アトリビュートに格納され、エンドポイントに送信されます。

クレデンシャル タイプは、ベンダー ID とアプリケーション ID という 2 つの ID によって一意に識別されます。ベンダー ID は、 IANA Assigned Numbers RFC の中でベンダーに割り当てられた番号です。たとえば、9 というベンダー ID は、シスコシステムズに対応します。ベンダーは、供給する NAC アプリケーションに番号を割り当てています。たとえば、シスコシステムズ製アプリケーションの場合、1 というアプリケーション ID は CTA に対応します。Web インターフェイスで、ポリシーの結果クレデンシャル タイプを指定する場合、クレデンシャル タイプは、ベンダーおよびアプリケーションに割り当てられた名前で識別されます。たとえば、CTA のクレデンシャル タイプは、Cisco:PA(PA はポスチャ エージェントのことで、CTA の別の表現)です。ポスチャ確認に応答する場合、ACS は、9 と 1 の数字 ID を使用します。これらの数字は、それぞれシスコと CTA の ID です。

アトリビュートは、ベンダー ID、アプリケーション ID、およびアトリビュート ID という 3 つの ID によって一意に識別されます。ベンダーおよびアプリケーションの一意の組み合せの場合も、番号がそれぞれ割り当てられたアトリビュート セットが存在します。ACS がエンドポイントと通信する場合、ID は数字になります。Web インターフェイスで、内部ポリシーの規則を指定する場合、アトリビュートは、ベンダー、アプリケーション、およびアトリビュートに割り当てられた名前で識別されます。たとえば、オペレーティング システムのバージョンに対応する CTA アトリビュートは、Cisco:PA:OS-Version です。ACS が受信するデータでは、9、1、6 の数字 ID によってアトリビュートが識別されます。これらの ID は、それぞれシスコ、CTA、および CTA の 6 番目のアトリビュートに対応します。

内部ポリシーの規則で使用されるデータ タイプや演算子など、アトリビュートに関する詳細については、「ポスチャ確認アトリビュートのデータ タイプ」を参照してください。カスタム RADIUS ベンダーの追加と設定には、RDBMS 同期化機能を使用することを推奨します。

拡張アトリビュート

拡張アトリビュートを使用すると、Linux クライアントをサポートし、各種 Linux パッケージに固有の条件を設定することができます。たとえば、 openssl パッケージ版に対応する条件を設定できます。

これらの Linux パッケージ用の値は、Entity フィールドに入力します。Entity フィールドは、アトリビュートのドロップダウン リストから拡張アトリビュートを入力するときに使用可能になります。その後、ドロップダウン リストからエンティティを選択できます。

たとえば、拡張アトリビュートの Cisco:Host:Package:Version アトリビュートを選択すると、システム(ACS)で設定済みの Linux パッケージがすべて Entity ドロップダウン リストに表示されます。

Web インターフェイスの NAC Attributes Management ページを使用すると、拡張アトリビュートを追加または削除することができます。

ポスチャ確認アトリビュートのデータ タイプ

ポスチャ確認アトリビュートは、次のいずれかのデータ タイプになります。

ブール :アトリビュートには、1 または 0(ゼロ)の値が含まれます。HTML インターフェイスで、ブール アトリビュートを使用して規則要素を定義する場合、有効な入力語は false true です。有効な演算子は、 = (等しい)と != (等しくない)です。ブール アトリビュートを使用した規則要素が評価される場合、 false は 0(ゼロ)値に対応し、 true は 1 に対応します。

たとえば、ブール アトリビュートの規則要素において、アトリビュートが false に等しくないことを要求した場合、特定のポスチャ確認要求内のアトリビュートが 1 になると、ACS はその規則要素を true と評価します。ただし、混乱を避けるため、アトリビュートが true に等しいことを要求して、規則要素をよりわかりやすい表現にします。

文字列 :アトリビュートには、文字列を含めることができます。有効な演算子は、 = (等しい)、 != (等しくない)、 contains starts-with 、および正規表現です。

整数 :アトリビュートには、符号付き整数など、整数を含めることができます。有効な演算子は、 = (等しい)、 != (等しくない)、 > (大なり)、 < (小なり)、 <= (小なりイコール)、および >= (大なりイコール)です。規則要素の有効な入力値は、-65535 ~ 65535 の整数です。

符号なし整数 :アトリビュートには、符号なし整数のみを含めることができます。有効な演算子は、 = (等しい)、 != (等しくない)、 > (大なり)、 < (小なり)、 <= (小なりイコール)、および >= (大なりイコール)です。規則要素の有効な入力値は、0 ~ 4294967295 の自然数です。

ipaddr :アトリビュートには、IPv4 アドレスを含めることができます。有効な演算子は、 = (等しい)、 != (等しくない)、および mask です。規則要素の有効形式は、ドット付き 10 進形式です。演算子が mask の場合、形式は mask / IP になります。詳細については、「内部ポリシー設定オプション」を参照してください。

日付 :アトリビュートには、日付を含めることができます。有効な演算子は、 = (等しい)、 != (等しくない)、 > (大なり)、 < (小なり)、 <= (小なりイコール)、 >= (大なりイコール)、および days-since-last-update です。規則要素の有効形式は、次のとおりです。

mm/dd/yyyy
hh
:mm:ss

バージョン :アトリビュートには、アプリケーションまたはデータ ファイルのバージョンを含めることができます。有効な演算子は、 = (等しい)、 != (等しくない)、 > (大なり)、 < (小なり)、 <= (小なりイコール)、および >= (大なりイコール)です。規則要素の有効形式は、次のとおりです。

n.n.n.n

ここで、各 n は、0 ~ 65535 の整数になります。

octet-array :アトリビュートには、任意のタイプの可変長データを含めることができます。有効な演算子は、 = (等しい)と != (等しくない)です。規則要素の有効な入力値は、7E(126 に相当する 16 進数)など、任意の 16 進数です。

内部ポリシー

この項では、次のトピックについて取り上げます。

「内部ポリシーについて」

「規則、規則要素、およびアトリビュートについて」

「内部ポリシー設定オプション」

内部ポリシーについて

内部ポリシーは、ACS に定義した 1 つ以上の規則で構成されます。ACS は、内部ポリシーを適用する場合、ポリシー規則を使用して、受信されたポスチャ確認要求内のクレデンシャルを評価します。各規則は、APT、クレデンシャル タイプ、およびアクションに関連付けられます。APT とアクションがどの NAC 準拠アプリケーションに関連付けられるかは、クレデンシャル タイプで決まります。

ACS は、各規則を、Posture Validation Policies ページに表示される順序で(上から下へ)適用します。その結果は、次のどちらかになります。

設定可能な規則との一致 :規則の要素すべてが、受信されたポスチャ確認要求内のクレデンシャルによって満たされた場合、ポリシーを適用した結果は、規則に関連付けられた条件、ポスチャ アセスメント、および通知文字列になります。他の追加規則によってクレデンシャルが評価されることはありません。

設定変更できない規則との一致 :ポスチャ確認要求に含まれるアトリビュートがポリシー規則を 1 つも満たさない場合、ACS は、ポリシーの結果として、デフォルト規則に関連付けられた条件、ポスチャ アセスメント、および通知文字列を使用します。


) ポスチャ確認要求にポリシーを適用すると、必ず、設定可能な規則の 1 つまたはデフォルト規則のどちらかと一致します。


ポリシー内の規則の順序を指定する場合は、各規則が true になる可能性を判断し、可能性の最も高い規則を先頭に、最も低い規則を末尾に配置します。このような処置により、規則処理の効率が良くなます。ただし、規則が true になる可能性を判断することは困難な場合があります。たとえば、1 つ目の規則が true になるポスチャのエンドポイントの数が、2 つ目の規則の 2 倍になる場合があるとします。しかし、2 つ目の規則と一致するポスチャのエンドポイントの方が、2 倍以上の頻度でポスチャ確認が発生する場合があるとします。そのため、2 つ目の規則を先頭に配置する必要があります。

規則、規則要素、およびアトリビュートについて

規則とは、1 つまたは複数の規則要素の集合です。規則要素とは、次の項目からなる論理的な文です。

ポスチャ確認アトリビュート

演算子またはポスチャ トークン

値または通知文字列

ACS は、演算子を使用して、アトリビュートの内容を値と比較します。規則全体が満たされるには、規則の規則要素それぞれが true になる必要があります。つまり、規則の規則要素すべてがブール AND で結合されます。

規則の詳細については、「プロファイルの設定」を参照してください。

内部ポリシー設定オプション

ポリシーを構成する規則とその順序などは、Internal Posture Validation Setup ページで指定できます。内部ポリシーの設定オプションは次のとおりです。

Name :ポリシーを識別する名前を指定します。ポリシーを選択する場合は、この名前で選択します。また、ポリシー選択ページに説明は表示されません。したがって、できるだけ有用な名前にする必要があります。


) 名前には、最大で 32 文字まで使用できます。先頭と末尾にスペースを置くことはできません。名前には、左角カッコ([)、右角カッコ(])、カンマ(,)、およびスラッシュ(/)を使用することはできません。


Description :ポリシーを説明する最大 255 文字のテキストを指定します。Description ボックスを使用すると、ポリシーの名前に含められなかった詳細情報を入力できます。たとえば、ポリシーの目的を説明することや、ポリシーの規則を要約することが可能です。同一のポリシーを複数のプロファイルに適用することが可能なため、有用な説明を付加することで、ポリシーを変更するときに、どのサーバがそのポリシーを使用するかを理解していない場合に発生する不測の設定エラーを防ぐこともできます。

Posture Validation Rules :ユーザが定義した規則が一覧表示されます。表示順序は、ACS がポスチャ確認要求の評価にこれらの規則を使用する順序です。各規則はテーブルの別々の行に表示され、規則を識別する規則要素が青色のリンクとして Posture Validation Rules ページに表示されます。このテーブルで規則の順序を変更するには、規則の左にあるオプションを直接選択し、必要に応じて Up と Down をクリックして規則の位置を変更します。規則の順序の詳細については、「内部ポリシーについて」を参照してください。

Posture Validation Rules テーブルには、次の項目が用意されています。

Condition :ベンダーとアプリケーション、つまりクレデンシャル タイプを指定します。規則が true の場合、クレデンシャル タイプは、対応する Token リスト内のトークンが関連付けられたアプリケーションを指定します。たとえば、CTA は Cisco:PA としてリストに表示されます。クレデンシャル タイプの詳細については、「ポスチャのクレデンシャルとアトリビュートについて」を参照してください。

Posture Assessment :ベンダーとアプリケーション、およびトークン(APT)を指定します。規則が true の場合、Token リストは、対応する Posture Assessment リストで選択されたベンダーおよびアプリケーションに関連付けられた APT を指定します。トークンの詳細については、「ポスチャ トークン」を参照してください。

Notification String :Result Credential Type リストで示されたアプリケーションに送信されるテキスト メッセージを指定します。テキスト メッセージを使用できるかどうかは、ベンダーで決まります。一部の NAC 準拠アプリケーションでは、Notification String ボックスは使用できません。

Default Rule設定可能な規則が 1 つも true でない場合、Default Rule は、ACS がポリシーの適用結果として使用するポスチャ アセスメント、トークン、および通知文字列(指定された場合)を指定します。


) Default Rule の下にある、Posture Assessment リスト、Token リスト、および Notification String ボックスの持つ意味は、Posture Validation Rules テーブルの同名のオプションと同じです。ただし、Posture Validation Rules テーブル内の規則が 1 つも true でない場合にデフォルト規則が自動的に true になる点を除きます。


外部ポリシー

この項では、次のトピックについて取り上げます。

「外部ポリシーについて」

「外部ポリシー設定オプション」

外部ポリシーについて

外部ポリシーは、外部 NAC サーバ(通常はアンチウイルス ベンダーからのサーバ)と、外部データベースに転送するクレデンシャル タイプのセットによって定義されるポリシーです。また、セカンダリ外部 NAC サーバを定義するオプションもあります。セカンダリ サーバがある場合は、プライマリ サーバのすべてのポリシーをセカンダリ サーバ、つまりフェールオーバー サーバで評価することができます。

ACS は外部ポリシーの適用結果を判別しません。代わりに、選択されたクレデンシャルを外部 NAC サーバに転送し、ポリシー評価の結果である APT、結果クレデンシャル タイプ、およびアクションを受信します。

外部サーバに関連付けられた外部ポリシーはそれぞれ結果を返す必要があります。結果を返さない外部ポリシーがあった場合、ACS は、対応するプロファイルを使用したポリシー確認要求を拒否します。たとえば、ポスチャ確認要求を評価するときに ACS が使用するプロファイルに 10 個の内部ポリシーと 1 つの外部ポリシーがある場合、外部ポリシーに関連付けられている外部 NAC サーバがオンラインになっていないと、10 個の内部ポリシーすべてが SPT を返すかどうかは関係なくなります。1 つの外部ポリシーに障害が発生すると、ACS はポスチャ確認要求を拒否します。

外部ポリシー設定オプション

External Posture Validation Setup ページでは、ACS がポリシーの適用時に依存する NAC サーバ(およびオプションのセカンダリ NAC サーバ)を指定することや、ACS が転送するクレデンシャル タイプのセットを設定することが可能です。外部ポリシーの設定オプションは次のとおりです。

Name :ポリシーを識別する名前を指定します。


) 名前には、最大で 32 文字まで使用できます。先頭と末尾にスペースを置くことはできません。名前には、左角カッコ([)、右角カッコ(])、カンマ(,)、およびスラッシュ(/)を使用することはできません。


Description :ポリシーを説明する最大 255 文字のテキストを指定します。Description ボックスに入力するテキストは、ポリシーを使用するプロファイルごとに、ポリシーの横に表示されます。Description ボックスを使用すると、ポリシーの名前に含められなかった詳細情報を入力できます。たとえば、ポリシーの目的を説明することや、ポリシーの規則を要約することが可能です。

同一のポリシーを複数のプロファイルに適用することが可能なため、有用な説明を付加することで、ポリシーを変更するときに、どのプロファイルがそのポリシーを使用するかを理解していない場合に発生する不測の設定エラーを防ぐこともできます。

Server Configuration :プライマリ サーバを指定する必要があります。フェールオーバー動作用のセカンダリ サーバを指定することができます。外部ポリシーが適用されるポスチャ確認要求ごとに、ACS は、イネーブルになっているポリシーのイネーブルになっている最初のサーバ設定を使用します。イネーブルになっている最初のサーバがプライマリ サーバのとき、ACS がプライマリ サーバに到達できない場合や、プライマリ サーバが要求への応答に失敗した場合、ACS はセカンダリ サーバを使用します(セカンダリ サーバが設定済みかつイネーブルの場合)。

プライマリ サーバおよびセカンダリ サーバの設定には、それぞれ次の項目があります。

URL :サーバの HTTP または HTTPS URL を指定します。URL の形式は次のようになります。

[http[s]://]host[:port]/resource

host は NAC サーバのホスト名または IP アドレス、 port はポート番号、 resource は URL の残りの部分で、いずれも NAC サーバそのもので必要になります。URL は、サーバのベンダーと設定によって異なります。NAC サーバに必要な URL については、NAC サーバのマニュアルを参照してください。

デフォルト プロトコルは、HTTP です。ホスト名で始まる URL は、HTTP が使用されることを前提としています。HTTPS を使用するには、 https:// で始まる URL を指定し、自己生成 CA 証明書をこのポリシー サーバの ACS にインポートする必要があります。「ACS 証明書のセットアップ」 を参照してください。

ポートが省略された場合は、デフォルト ポートが使用されます。HTTP のデフォルト ポートはポート 80 で、HTTPS のデフォルト ポートはポート 443 です。

NAC サーバのホスト名が antivirus1 の場合、有効な URL は次のようになります。ここで、NAC サーバはポート 8080 を使用して、cnac という Web ディレクトリ内の policy.asp スクリプトが提供されるサービスの HTTP 要求に応答します。

http://antivirus1:8080/cnac/policy.asp
antivirus1:8080/cnac/policy.asp

同じサーバがデフォルト HTTP ポートを使用した場合、有効な URL は次のようになります。

http://antivirus1/cnac/policy.asp
http://antivirus1:80/cnac/policy.asp
antivirus1/cnac/policy.asp
antivirus1:80/cnac/policy.asp

同じサーバがデフォルト ポート上で HTTPS を使用した場合、有効な URL は次のようになります。

https://antivirus1/cnac/policy.asp
https://antivirus1:443/cnac/policy.asp

Username :転送するクレデンシャルをサーバに送信するときに ACS が使用するユーザ名を指定します。サーバがパスワードで保護されていない場合、Username ボックスと Password ボックスに入力した値は無視されます。

Password :Username ボックス内のユーザ名に対応するパスワードを指定します。

Timeout (Sec) :クレデンシャルを転送してからサーバの応答を受信するまで ACS が待機する秒数。

セカンダリ サーバが設定されている場合、タイムアウトしたプライマリ サーバへの要求はセカンダリ サーバに転送されます。

セカンダリ サーバが設定されていない場合や、セカンダリ サーバへの要求もタイムアウトした場合、ACS は外部ポリシーを適用できないため、ポスチャ確認要求は拒否されます。

どのポスチャ確認要求に対しても、常に、ACS は最初にプライマリ サーバを試行します。この場合、以前の要求がタイムアウトしたかどうかは関係ありません。

Trusted Root CA :サーバが使用するサーバ証明書を発行した認証局(CA)。プロトコルが HTTPS の場合、ACS がクレデンシャルをサーバに転送するのは、サーバから提示される証明書が、このリストで指定された CA によって発行されている場合に限られます。信頼できるルート CA がサーバ証明書を発行していないために、ACS が要求をプライマリまたはセカンダリ NAC サーバに転送できない場合、外部ポリシーは適用できないため、ポスチャ確認要求は拒否されます。

NAC サーバ証明書を発行した CA が Trusted Root CA リストにない場合は、CA 証明書を ACS に追加する必要があります。詳細については、「認証局証明書の追加」を参照してください。


) ACS は、Certificate Revocation List(CRL; 証明書失効リスト)で NAC サーバ証明書をチェックしません。この場合、NAC サーバ証明書の CA に対して CRL 発行元を設定しているかどうかは関係ありません。



ヒント CA の名前だけでなく、CA の正しい証明書タイプを選択する必要があります。たとえば、サーバが VeriSign Class 1 Primary CA 証明書を提示した場合、Trusted Root CA リストで VeriSign Class 1 Public Primary CA が選択されているときは、ACS は HTTPS の使用時にクレデンシャルをサーバに転送しません。

Forwarding Credential Types :外部サーバに転送するクレデンシャル タイプを指定するときに使用する 2 つのリストが含まれています。クレデンシャルは次のとおりです。

Available Credentials :外部サーバに送信 されない クレデンシャル タイプを指定します。

Selected Credentials :外部サーバに送信 される クレデンシャル タイプを指定します。


ヒント Web インターフェイスの NAC Attributes Management ページを使用すると、クレデンシャル タイプを追加または削除することができます。

NAH ポリシー

この項では、次のトピックについて取り上げます。

「外部監査サーバについて」

「外部監査サーバ設定オプション」

外部監査サーバについて

監査サーバとは、Posture Agent(PA; ポスチャ エージェント)の存在に依存することなく、ホストに関するポスチャ情報を判別するシスコおよびサードパーティ製のサーバです。 Cisco PA は Cisco Trust Agent(CTA)とも呼ばれます。監査サーバは、組織のセキュリティ ポリシーによってポスチャ確認を評価するために使用されます。セカンダリ外部監査サーバを定義することもできます。セカンダリ監査サーバがある場合、プライマリ サーバがポリシーを拒否したときに、プライマリ サーバからのすべてのポリシーをセカンダリ サーバ、つまりフェールオーバー サーバで評価することができます。

監査ポリシーは、監査サーバを介して NAH のポスチャを評価する処理規則のセットです。監査ポリシーは、EAP サプリカントを持たないホストのポスチャを判断するために使用されます。NAC 適用ポイントとして機能する NAD を介してホストがネットワークにアクセスするときに、NAD は ACS が監査をトリガーできるよう ACS に情報を送信します。ACS は、正しく設定されていれば、監査サーバに監査の結果(ポスチャ トークン)を問い合せた後、監査結果に基づいて認可を決定します。

ネットワークへのアクセスを制御するため、ネットワーク管理のセキュリティ計画に ACS と連携する外部監査サーバを組み込むことができます。

ACS では、監査サーバとの通信に GAME プロトコルを使用します。各監査要求で、ACS は次の情報を監査サーバに転送します。

host id

ip-address

mac-address (オプション)

システム ポスチャ トークンの名前はデバイスに対して動的に送信されます(設定する必要はありません)。

表14-2 では、監査結果の適用時に必要な詳細を定義しています。

 

表14-2 監査ポリシー要件

監査ポリシー
説明

auditServerConfiguration

監査サーバとの通信方法を定義する監査サーバ設定に対するポインタ。

exemptionList

監査が免除される MAC アドレス、IP アドレス、またはその両方のリスト。

inverseExemptionFlag

このフラグが設定された場合、免除リストの意味は逆になります。つまり、リストに指定されたホストだけが監査対象となり、それ以外はすべて監査が免除されます。

exemptionToken

免除されるホストに割り当てるトークン。

defaultInProgressToken

監査が進行中で、キャッシュされたトークンがないときに使用するトークン。

staticAttributes

これらの名前値のペアは、このポリシーが呼び出されたときに監査サーバに送信されます。このリリースでは、このアトリビュート リストを使用してポリシー名を渡します。

tokenMappings

ユーザ グループ マッピングに対するトークン。このスキームでは、各サービスに監査ポリシーが 1 つだけ存在することを想定しています。

外部監査を呼び出す仕組み

エンドポイントに障害が発生すると、外部監査が呼び出されます。この障害は、エンドポイントが要求どおりに応答していないことが適用ポイントで検出された場合に発生します。適用ポイントは、デバイス障害の発生を示す aaa:event 障害メッセージを送信します。

現在の ACS リリースでは、このイベント タイプをサポートしており、どのイベントがポリシー(場合によっては複数)を起動するかをアウトオブバンド ポスチャ ポリシーで設定できます。

ACS はポリシー設定に応じて、監査を呼び出す、または呼び出さない次のイベントを認識できる必要があります。

CTA が機能していないことを NAS が検出し、 aaa:event アトリビュートで NRH 通知を送信する。

エンドポイント デバイス(またはサプリカント)がポスチャ要求に応答できない。

デバイスからの明示的な監査要求。

監査が発生することを ACS が認識すると、監査サーバは問い合せを受けます。監査サーバは、結果または audit-in-progress メッセージで応答します。これには、NAD に渡すためのポーリング タイムアウト ヒントが含まれる場合があります。この時点で ACS は、ポスチャ確認ポリシーに関連付けられたデフォルト APT に基づいて特定のホストに対する適用ポリシーを評価します。適用ポリシーの一部は、ホストを再認証するための NAD 呼び出しに使用されるセッション タイムアウト値にする必要があります。ACS は要求を受信し、監査サーバに問い合せます。このプロセスは、監査サーバが APT で応答するまで繰り返されます。監査応答を受信したら、適用ポリシーは再評価されて NAD に返されます。

NAD はポスチャ トークンをキャッシュします。このトークンは、ホストのセッション中に(セッション タイムアウトが発生した結果、再認証などで)発生した後続のアクセス要求とともに送信されます。ACS はこのトークンを、後続認証の監査中にデフォルト ポリシー評価で使用するため、接続されたホストではセッションのダウングレードが発生しません。

免除リストのサポート

ACS では、監査の起動対象についての免除リストをサポートしています。免除リストには、監査の対象または対象外とする IP アドレスか MAC アドレスのリストが含まれます。ホストが免除されると、ホストにはポスチャの状態を判別する免除トークンが割り当てられます。免除リストは、アウトオブバンド監査ポリシーで定義されます。IP リストには、単一の IP アドレスまたは IP マスク範囲を含めることができます。MAC リストは MAC 範囲にすることができます。範囲の形式は、 begins with 演算子を使用して、ホストの MAC アドレスと一致する部分的な MAC 文字列になります。

外部監査サーバ設定オプション

表14-3 に、外部監査サーバの設定を示します。

 

表14-3 外部監査サーバのオプション

オプション
説明
監査対象のホスト
Audit all hosts

ポスチャ エージェントを含まないすべてのホストを監査します。

Audit these hosts

ホストの IP アドレスと範囲(IP/Mask)、または MAC アドレスが指定されたホストだけを監査します。

Do not audit these hosts

ホストの IP アドレスと範囲(IP/Mask)、または MAC アドレスが指定されたホストを除外し、それ以外のホストをすべて監査します。

Select a token for the hosts that will not be audited

ドロップダウン リストから監査対象外ホストのトークンを選択します。

使用する監査サーバ
Audit server vendor

ADF ファイルにあるベンダー名。

プライマリおよびセカンダリのサーバ設定
URL

監査サーバの URL。形式のガイドラインについては、監査サーバのマニュアルを参照してください。

Username

監査サーバにアクセスするため、クレデンシャル ACS に必要です。

Password

監査サーバにアクセスするため、クレデンシャル ACS に必要です。

Timeout (sec)

ドメインの名前解決を含め、監査サーバから結果を受信するまで ACS が待機する秒数。

Trusted Root CA

指定した URL に HTTPS プロトコルが指定されている場合は、プライマリ サーバにインストールされた監査サーバ証明書を発行した認証局を Trusted Root CA リストから選択します。

Validate Certificate Common Name

URL 内のホスト名と証明書の共通名を比較するには、このオプションをオンにします。一致しない場合、SSL 接続が終了し、ポスチャ確認が失敗して、ユーザ アクセスが拒否されます。この機能をディセーブルにするには、このチェックボックスをオフのままにします。

監査ホストの設定
Use this token while Audit Server does not yet have a posture validation result

結果を待つ間、ACS から NAD に送信される仮のポスチャ トークン。

Polling Intervals and Session-Timeout:

選択すると、監査サーバが送信するタイムアウト、または認可ポリシー設定のセッション タイムアウトを使用します。ポーリング間隔設定(秒)も含まれます。プライマリ監査サーバまたはセカンダリ監査サーバの設定フィールドに、セッション タイムアウトを設定します。

Maximum amount of times the Audit Server should be polled

ACS が監査サーバに結果(ポスチャ トークン)を問い合せる最大回数を選択します。最大 10 回です。

Policy string to be sent to the Audit Server

監査サーバが名前付きポリシーの呼び出しをサポートする場合は、ここにポリシーの名前を入力します。

ポリシーの設定

ネットワークで NAC を使用する場合には、ポスチャ確認の実行方法を定義する必要があります。ポリシーは、ポスチャ確認要求に対するポスチャ トークンの判別に使用される規則のセットです。

ポスチャ確認は、ポスチャ準拠とも呼ばれ、次のように設定できます。

ACS 内部で設定する。「ポスチャ確認ポリシーの設定」を参照してください。

1 つ以上の Posture Validation Server(PVS; ポスチャ確認サーバ)に対し、Host Credential Authorization Protocol(HCAP)プロトコルを使用して外部で設定する。「外部ポリシー サーバの設定」を参照してください。

NAC エージェントレス ホスト(NAH)をサポートするため、監査サーバに対し、GAME プロトコルを使用して外部で設定する。「外部監査ポスチャ確認サーバの設定」を参照してください。

表14-4 に、ポスチャ確認の設定オプションを示します。

 

表14-4 ポスチャ確認オプション

コンポーネント
説明
注釈
Internal Posture Validation

ネットワークのポリシー要件の確認は、ACS の内部(つまりローカル)で行われます。

CTA、Windows、CSA、およびアンチウイルス ソフトウェア アプリケーションに対する NAC ポリシーは、推奨される内部ポリシーの中にあります。「内部ポリシーの作成」を参照してください。

External Posture Validation

ポリシーの確認は、外部のポスチャ確認サーバが行います。

ポスチャ確認を外部の AV サーバで行うと、ACS 管理者とは別の AV 管理者によって独自の AV ポスチャ クレデンシャルに対応し、アンチウイルス ポリシーを管理することが可能になります。

External Audit Posture Validation

PA の存在に依存することなく、ホストに関するポスチャ情報を判別するシスコおよびサードパーティ製のサーバ。このホスト タイプは、 エージェントレス とも呼ばれます。監査サーバは、組織のセキュリティ ポリシーによってポスチャ確認を評価するために使用されます。

Cisco PA は CTA とも呼ばれます。CTA がホストにない場合は、監査サーバを使用できます。


) 内部と外部のポスチャ確認を同時に実行できます。ただし、NAC クレデンシャル タイプ(ベンダーとアプリケーションの組み合せ)が同一の場合は実行できません。


内部または外部のポスチャ確認向けにポリシーを設定するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの Posture Validation をクリックします。

ステップ 2 ポスチャ確認サーバを設定するために、次のコンポーネントのいずれか 1 つを選択します。

Internal Posture Validation Setup:「内部ポリシー」または 「内部ポリシーの作成」を参照してください。

External Posture Validation Setup:「外部ポリシー」または 「外部ポリシー サーバの設定」を参照してください。

External Posture Validation Audit Setup:「NAH ポリシー」または 「外部監査ポスチャ確認サーバの設定」を参照してください。

ステップ 3 内部または外部のポスチャ確認の設定に必要な手順を完了します。


 

ポスチャ確認ポリシーの設定

この項では、次のトピックについて取り上げます。

「内部ポリシーの作成」

「ポリシーまたはポリシー規則のクローニング」

「NAH ポリシー」

「ポリシーの編集」

「ポリシーまたは規則の削除」

内部ポリシーの作成

内部ポスチャ確認を使用して、ネットワークでのアクセス向けに独自のポリシーを作成できます。ポリシーを作成した後で、これらのポリシーを使用するように規則のプロファイルを作成できます。

複数のプロファイルに対応する内部ポリシーを選択できます。ポリシーをプロファイルに追加するには、Network Access Profiles ページを使用します。

Internal Posture Validation Setup ページで使用可能なオプションについては、「内部ポリシー設定オプション」を参照してください。

サードパーティ製コンポーネントのポリシーを設定する方法の詳細については、Cisco.com の Go NAC Web サイトで関連マニュアルを参照してください。内部ポリシーをプロファイルに追加する方法については、「ポスチャ確認ポリシーの設定」を参照してください。

1 つでもポリシーを設定した後に、クローン規則オプションを使用すると、ポリシーをコピーしてカスタマイズすることで時間を節約できます。クローニングの使用方法の詳細については、「ポリシーまたはポリシー規則のクローニング」を参照してください。

内部ポスチャ確認ポリシーを作成するには、次の手順を実行します。


ステップ 1 Internal Policy Validation Setup ページにアクセスします。

a. ナビゲーション バーの Posture Validation をクリックします。

b. Internal Posture Validation Setup をクリックします。

ポスチャ確認ポリシーのリストが表示されます(使用可能な場合)。

c. Add Policy をクリックします。

ステップ 2 Name ボックスに、ポリシーの説明的な名前を入力します。

ステップ 3 Description ボックスに、ポリシーに関する有用な説明を入力します。

ステップ 4 Submit をクリックします。

ステップ 5 Add Rule をクリックします。

ステップ 6 追加する条件セットごとに、次の手順を実行します。

a. アトリビュートを選択する。アトリビュート タイプの詳細については、「ポスチャ確認アトリビュートのデータ タイプ」を参照してください。

b. エンティティを選択する(拡張アトリビュートの場合のみ使用可能)。

c. 演算子を選択する。

d. 値を入力する。

e. Enter キーを押してから Submit をクリックする。

たとえば、Cisco Security Agent(CSA)のポリシーを作成する場合、次の条件セットを作成することができます。

Cisco:PA:PA-Version >= 2.0.0.0 AND Cisco:PA:Machine-Posture-State = 1 with a Posture token=Healthy

Cisco:PA:PA-Version >= 2.0.0.0 AND Cisco:PA:Machine-Posture-State = 2 with a Posture Token=Transition

Match OR inside Condition and AND between Condition Sets(ACS でトークンを選択できるようにする場合)

演算子の詳細については、「内部ポリシー設定オプション」を参照してください。

CTA ポスチャ プラグイン アトリビュートと値については、Cisco Trust Agent のマニュアルを参照してください。

条件セットが Conditions Sets テーブルに表示されます。

ステップ 7 次のいずれかのブール条件を選択して、この条件セットに追加します。

Match OR inside Condition and AND between Condition Set:条件をあまり厳しくしない場合に選択します。

Match AND inside Condition and OR between Condition Sets:ポスチャ確認をより安全なものにする場合に選択します。

ステップ 8 条件セットが意図したとおりに設定されたことを確認します。


ヒント すでに追加した条件セットを変更する場合は、条件要素を選択して Remove をクリックし、アトリビュート、エンティティ、演算子、または値をアップデートしてから Enter キーを押します。

ステップ 9 新規の規則に対して、次の操作をすべて行います。

a. クレデンシャル タイプを選択する。

b. トークンを選択する。

c. アクションを入力する(通知文字列の形式で)。

トークンの詳細については、「ポスチャ トークン」を参照してください。

規則がポスチャ確認要求と一致すると、指定された結果クレデンシャル タイプ、トークン、およびアクションがポリシーに関連付けられます。


ヒント すでに作成したものと同じ条件セットを別個に作成する場合は、Clone をクリックします。その後で、条件セットを必要に応じて変更します。

ステップ 10 Submit をクリックします。

Policy Validation Rules ページが再度表示されます。新規の条件セットが Condition Sets テーブルの一番下に表示されます。


ヒント 規則をクリックすると、Posture Validation Rules ページに戻ることができます。

ステップ 11 ポリシーを定義する規則を作成したら、必要に応じて、規則の順序を設定します。ACS は、ポリシーを適用するときに、Policy Validation Rules ページに表示される規則を上から順に照合します。規則が最初に一致した時点でポリシー処理が停止するため、順序は重要です。規則を移動するには、次の手順を実行します。

a. 規則を選択します。これを行うには、規則の左にあるオプション ボタンをクリックします。

b. 規則が適切な位置に来るまで、 Up または Down ボタンをクリックします。

ステップ 12 Default をクリックして、Posture Validation Rules ページの下部にある Default Rule を設定します。

a. クレデンシャル タイプを選択する。

b. トークンを選択する。

c. アクションを入力する(通知文字列の形式で)。

ACS は、このポリシーをポスチャ確認要求に適用した結果、どの設定可能な規則にも一致しなかった場合、指定されたデフォルトのクレデンシャル タイプ、トークン、およびアクションをポリシーに関連付けます。

ステップ 13 Submit をクリックします。

Posture Validation Rules ページに、新規の規則が表示されます。

ステップ 14 Done をクリックします。

現在の設定は変更されています。

ステップ 15 変更内容を有効にするために、Apply and Restart をクリックします。


 

ポリシーの編集

Posture Validation ページからアクセスする方法でのみ、ポリシーを編集できます。

ポリシーまたはポスチャ確認規則を編集するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの Posture Validation をクリックします。

ステップ 2 Internal Posture Validation Setup をクリックします。

ステップ 3 編集する規則のポリシー名をクリックします。

適切なポリシー規則ページが表示されます。

ステップ 4 ポリシーを編集するには、次の手順を実行します。

a. 条件セットをさらに追加するには、Add Rule をクリックします。

b. すでに追加した条件セットを変更するには、次の手順を実行します。

i. 条件要素を選択します。

ii. Remove をクリックします。

iii. アトリビュート、エンティティ、演算子、または値をアップデートして、 Enter キーを押します。

c. 新規の条件を追加するには、次の手順を実行します。

i. ドロップダウン リストからアトリビュート、エンティティ、および演算子を選択します。

ii. 値を入力します。

iii. Enter キーを押します。

d. Clone をクリックして、既存の条件セットまたはポリシー規則をコピーします。

e. Delete をクリックしてポリシー規則を削除します。条件セットまたは条件セットの要素を削除することもできます。「条件コンポーネントまたは条件セットの削除」を参照してください。

f. 規則を移動するには、次の手順を実行します。

i. 規則の左にあるボタンをクリックして、規則を選択します。

ii. 規則が適切な位置に来るまで、 Up または Down ボタンをクリックします。

g. この条件セットにブール条件を追加するか、あるいはブール条件を変更する場合は、次のオプションのいずれか 1 つを選択します。

Match OR inside Condition and AND between Condition Set:条件をあまり厳しくしない場合に選択します。

Match AND inside Condition and OR between Condition Sets:ポスチャ確認をより安全なものにする場合に選択します。

h. Rename をクリックして、既存の名前を変更します。

新規ポリシーが作成されます。新規ポリシーは格納され、古いポリシーの設定は変更されません。古いポリシーは、Posture Validation Policies テーブルに残ります。

ステップ 5 編集が終了したら、 Submit をクリックします。次に Done をクリックします。

ステップ 6 変更内容を有効にするために、Apply and Restart をクリックします。


 

ポリシーまたはポリシー規則のクローニング

このオプションによって、選択したものと同じポリシーまたは規則が作成されます。その後で設定を簡単に修正できます。

内部ポスチャ確認ポリシーまたはポリシー規則をクローニングするには、次の手順を実行します。


ステップ 1 Internal Policy Validation Setup ページが表示されていない場合は、このページにアクセスします。そのためには、次の手順を実行します。

a. ナビゲーション バーの Posture Validation をクリックします。

b. Internal Posture Validation Setup をクリックします。

ポスチャ確認ポリシーのリストが表示されます。

c. リストからポリシー名を選択します。


ヒント ポリシーが 1 つも設定されていない場合は、Add Policy をクリックして、「内部ポリシーの作成」の指示に従います。

ステップ 2 現在のポリシーのコピーを作成するには、Clone をクリックします。

たとえば、ポリシーとして VPNmgt1 を選択した場合、コピーは Copy-of-VPNmgt1 になります。

ステップ 3 現在のポリシー内にあるポリシー規則のいずれか 1 つについてコピーを作成するには、条件名をクリックします。次に Clone をクリックします。

Policy Validation Rule ページが再度表示されます。新規の条件セットが Condition Sets テーブルに表示されます。

ステップ 4 Rename をクリックして、既存の名前をよりわかりやすい名前または説明に変更します。

新規ポリシーが作成され、古いポリシーの設定は変更されません。古いポリシーは、Posture Validation Policies テーブルに残ります。

ステップ 5 編集が終了したら、 Submit をクリックします。

ステップ 6 クローンの追加が終了したら、Done をクリックします。

ステップ 7 変更内容を有効にするために、Apply and Restart をクリックします。


 

ポリシーの名前の変更

名前の変更機能を使用すると、既存ポリシーまたはクローニングしたポリシーの名前または説明をよりわかりやすい内容に変更できます。

ポリシーの名前を変更するには、次の手順を実行します。


ステップ 1 Internal Policy Validation Setup ページが表示されていない場合は、このページにアクセスします。そのためには、次の手順を実行します。

a. ナビゲーション バーの Posture Validation をクリックします。

b. Internal Posture Validation Setup をクリックします。

ポスチャ確認ポリシーのリストが表示されます。

c. リストからポリシー名を選択します。

ステップ 2 Rename をクリックして、既存のポリシー名を変更するか、よりわかりやすい説明にします。

ステップ 3 ポリシー名または説明に対する変更を入力します。編集が終了したら、 Submit をクリックします。

新規ポリシーが作成されます。新規ポリシーは格納され、古いポリシーの設定は変更されません。古いポリシーは、Posture Validation Policies テーブルに残ります。

ステップ 4 Done をクリックします。

名前の変更されたポリシーが、Posture Validation Policies ページの下部に表示されます。

ステップ 5 変更内容を有効にするために、Apply and Restart をクリックします。


 

ポリシーまたは規則の削除

ポリシーまたは規則を削除するには、次の手順を実行します。


ステップ 1 Internal Policy Validation Setup ページが表示されていない場合は、このページにアクセスします。Internal Policy Validation Setup ページにアクセスするには、次の手順を実行します。

a. ナビゲーション バーの Posture Validation をクリックします。

b. Internal Posture Validation Setup をクリックします。

ポスチャ確認ポリシーのリストが表示されます。

ステップ 2 規則またはポリシーを削除するには、ポスチャ確認ポリシーのリストからポリシー名を選択します。

Posture Validation Rules ページが表示されます。

ステップ 3 ポリシー全体とそのすべての規則を削除するには、 Delete をクリックします。

この操作により、ポリシー確認リストからポリシーが削除されます。ただし、ポリシーが関連付けられたプロファイルからはポリシーは削除されません。取り消すか、OK をクリックするように求める警告メッセージが表示されます。

ステップ 4 要素または条件セットを削除するには、「条件コンポーネントまたは条件セットの削除」を参照してください。

ポリシー規則が削除されます。ポリシー ページが再度表示されますが、ポリシー テーブルに削除済みポリシーは表示されなくなります。そのポリシーを使用するように設定されていたすべてのプロファイルで、削除済みポリシーが表示されなくなります。


 

条件コンポーネントまたは条件セットの削除

条件コンポーネントは、条件セットを構成する要素のリストです。1 つの条件セットまたは条件セット全体から条件コンポーネントを削除するには、次の手順を実行します。


ステップ 1 Internal Policy Validation Setup ページが表示されていない場合は、このページにアクセスします。Internal Policy Validation Setup ページにアクセスするには、次の手順を実行します。

a. ナビゲーション バーの Posture Validation をクリックします。

b. Internal Posture Validation Setup をクリックします。

ポスチャ確認ポリシーのリストが表示されます。

ステップ 2 ポスチャ確認ポリシーのリストからポリシー名を選択します。

Posture Validation Rules ページが表示されます。

ステップ 3 Posture Validation Rules ページの Condition リストで青色のリンクを選択します。

ステップ 4 条件セット全体を削除するには、 Delete をクリックします。次に Done をクリックします。

ステップ 5 選択した条件コンポーネントをセットから削除するには、Condition Sets リストの青色のリンクを選択してから Delete をクリックします。必要な条件コンポーネントをすべて削除したら、Submit をクリックします。

条件セットまたは条件コンポーネントが削除されます。

ステップ 6 Done をクリックします。


 

外部ポリシー サーバの設定

次の手順は、外部ポリシーの作成方法を示しています。

始める前に

複数のプロファイルに対応する外部ポリシーを選択できます。外部ポリシーを作成するには、External Posture Validation Setup ページを使用します。ポリシーをプロファイルに追加するには、Network Access Profiles ページを使用します。「プロファイルの設定」を参照してください。

External Policy Validation ページにアクセスするときに使用する外部サーバによって、新規外部ポリシーを選択できるプロファイルが制約されることはありません。

External Policy Configuration ページで使用可能なオプションについては、「外部ポリシー設定オプション」を参照してください。


ステップ 1 External Posture Validation Setup を選択すると、External Posture Validation Servers ページが表示されます。

ステップ 2 Add Server をクリックします。

Add/Edit External Posture Validation Server ページが表示されます。

ステップ 3 サーバに名前を付けて、必要に応じて説明を入力します。

ステップ 4 プライマリ サーバおよびセカンダリ サーバのアドレッシング情報を入力します。

a. Primary Server configuration チェックボックスをオンにします。


Primary Server Configuration チェックボックスがオンになっていない場合、ACS はセカンダリ サーバ設定を使用します。セカンダリ サーバ設定が存在しない場合や、セカンダリ サーバが到達不能の場合、ポスチャ確認要求は拒否されます。


b. プライマリ NAC サーバに関する詳細設定を入力します。この領域にあるボックスとリストの詳細については、「外部ポリシー設定オプション」を参照してください。

ステップ 5 (オプション) Secondary Server configuration ペインで、次の操作を行います。

a. Secondary Server configuration チェックボックスをオンにします。

b. セカンダリ NAC サーバに関する詳細設定を入力します。この領域にあるボックスとリストの詳細については、「外部ポリシー設定オプション」を参照してください。

ステップ 6 使用可能なクレデンシャルを選択済みクレデンシャル カラムに移動し、プライマリ サーバまたはセカンダリ サーバに転送するクレデンシャルを決定します。

ステップ 7 変更内容を保存するには、Submit をクリックします。

ステップ 8 変更内容を ACS に送信するために、Apply and Restart をクリックします。


 

外部ポスチャ確認サーバの編集

外部ポスチャ確認サーバは、Posture Validation ページからアクセスして編集できます。

外部ポスチャ確認監査サーバを編集するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの Posture Validation をクリックします。

ステップ 2 External Posture Validation Setup をクリックします。

ステップ 3 編集するサーバ名をクリックします。

Add/Edit External Posture Validation Server ページが表示されます。

ステップ 4 フィールドを編集して、Submit をクリックします。


 

外部ポスチャ確認サーバの削除

外部ポスチャ確認サーバは、Posture Validation ページからアクセスして削除できます。

外部ポスチャ確認サーバを削除するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの Posture Validation をクリックします。

ステップ 2 External Posture Validation Setup をクリックします。

ステップ 3 削除するサーバ名をクリックします。

Add/Edit External Posture Validation Server ページが表示されます。

ステップ 4 Delete をクリックします。


 

外部監査ポスチャ確認サーバの設定

このページを使用して、外部ポスチャ確認監査サーバの作成、修正、および削除を行います。ポリシーは再使用が可能です。つまり、1 つの監査ポリシーを複数のネットワーク アクセス プロファイルに関連付けることができます。

Web インターフェイスの NAC Attributes Management ページを使用して、監査ベンダーを ACS 内部ディクショナリに追加する必要があります。

外部ポスチャ確認の監査サーバを設定するには、次の手順を実行します。


ステップ 1 External Posture Validation Audit Setup を選択すると、External Posture Validation Audit Server ページが表示されます。

ステップ 2 Add Servers をクリックします。

Edit External Posture Validation Audit Setup ページが表示されます。

ステップ 3 監査ポリシーの名前を入力します。

ステップ 4 監査するホストを選択します。ドロップダウン リストから次のオプションのいずれか 1 つを選択します。

Audit all hosts:ポスチャ エージェントを含まないすべてのホストを監査します。

Audit these hosts:ホストの IP アドレスと範囲(IP/Mask)、または MAC アドレスが指定されたホストだけを監査します。

Do not audit these hosts:ホストの IP アドレスと範囲(IP/Mask)、または MAC アドレスが指定されたホストを除外し、それ以外のホストをすべて監査します。

Select a Posture Token for the hosts that will not be audited:ドロップダウン リストから監査対象外ホストのトークンを選択します。

ステップ 5 監査サーバのベンダーを選択し、プライマリ監査サーバにアクセスするためのアドレッシング情報とクレデンシャルを入力します。フェールオーバーが必要な場合は、セカンダリ監査サーバについても入力します。

ステップ 6 監査サーバによって返されるさまざまな結果や状態を解析するディレクティブを設定します。ディレクティブには、次のものが含まれます。

Use this Posture Token while the Audit Server does not yet have a posture validation result :ドロップダウン リストからトークンを選択します。監査サーバが NAC エージェントレス ホストの実際のポスチャを判別する前に、進行中のトークンが使用されます。

Polling Intervals and Session-Timeout :監査サーバが送信するポーリング間隔を指定します。デフォルトでイネーブルになります。

Maximum amount of times the Audit Server should be polled :ACS が監査サーバに結果(ポスチャ トークン)を問い合せる最大回数を選択します。

Policy string sent to be sent to the Audit Server :監査サーバが名前付きポリシーの呼び出しをサポートする場合は、ポリシーの名前を入力します。

ステップ 7 外部ポスチャ確認監査サーバの設定を保存するには、Submit をクリックします。


 

外部ポスチャ確認監査サーバの編集

外部ポスチャ確認監査サーバは、Posture Validation ページからアクセスして編集できます。

外部ポスチャ確認監査サーバを編集するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの Posture Validation をクリックします。

ステップ 2 External Posture Validation Audit Setup をクリックします。

ステップ 3 編集するサーバ名をクリックします。

External Posture Validation Audit Server ページが表示されます。

ステップ 4 フィールドを編集して、Submit をクリックします。


 

外部ポスチャ確認監査サーバの削除

外部ポスチャ確認監査サーバは、Posture Validation ページからアクセスして削除できます。

外部ポスチャ確認監査サーバを削除するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの Posture Validation をクリックします。

ステップ 2 External Posture Validation Audit Setup をクリックします。

ステップ 3 削除するサーバ名をクリックします。

External Posture Validation Audit Server ページが表示されます。

ステップ 4 Delete をクリックします。


 

ポスチャ確認がプロファイルベースのポリシーに適合する仕組み

プロファイルベースのポリシーのパラダイムを理解するためには、ネットワーク アクセス プロファイルを理解する必要があります。基本的にプロファイルとは、一般的なポリシーを適用するために、ネットワーク アクセス要求を分類するものです。プロファイルベースのポリシーには、認証、認可、およびポスチャ確認のための規則が含まれます。

認可規則は Posture Validation ではなく、Network Access Profiles タブで設定するようになりました。NAP の認可を使用すると、同一の RADIUS アトリビュートをプロビジョニングして、異なるユーザ、グループ、およびプロファイルに対し別の値を設定できます。1 ユーザ 1 グループ 1 プロファイルという方針は、代わりにプロファイルベースのポリシーを使用することで、さらに柔軟になりました。

ポスチャ確認規則を設定した後は、その規則をネットワーク アクセス プロファイルに関連付ける必要があります。詳細な手順については、「ポスチャ確認ポリシーの設定」を参照してください。

プロファイルベースのポリシーの詳細については、「NAP の概要」を参照してください。