Cisco Secure Access Control Server 4.2.1 ユーザ ガイド
ポスチャ確認
ポスチャ確認
発行日;2012/02/02 | 英語版ドキュメント(2011/05/27 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

ポスチャ確認

ポスチャ確認とは

ネットワーク アクセス コントロールでのポスチャ確認

ポスチャ確認とネットワーク アクセス プロファイル

ポスチャ トークン

ポスチャ確認プロセス

ポリシーの概要

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

拡張アトリビュート

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

内部ポリシー

内部ポリシーについて

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

外部ポリシー

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

外部監査サーバについて

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

免除リストのサポート

デバイス タイプの監査

ポリシーの構成

ユーザ グループとデバイス タイプ

グループの割り当て

グループ マッピングの規則

ネットワーク アクセス コントロールのレイヤ 2 監査

ACS での NAC の設定

NAC および NAP 環境の ACS の設定

ポリシーの設定

ポスチャ確認オプション

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

内部ポリシーの作成

ポリシーの編集

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

ポリシーの名前の変更

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

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

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

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

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

外部 AAA サーバの設定

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

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

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

外部ポスチャ確認監査サーバの追加

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

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

MAC 認証バイパスを使用した監査処理

ワークフロー

処理

ポリシーの設定

[Posture Validation] ページのリファレンス

[Posture Validation Components Setup] ページ

[Internal Posture Validation Setup] ページ

[Posture Validation Policies] ページ

[Posture Validation Policy] ページ

ポスチャ確認

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

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

「ポスチャ確認とは」

「ネットワーク アクセス コントロールでのポスチャ確認」

「ポスチャ確認とネットワーク アクセス プロファイル」

「ポスチャ トークン」

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

「ポリシーの概要」

「内部ポリシー」

「外部ポリシー」

「外部ポスチャ確認監査サーバ」

「ACS での NAC の設定」

「NAC および NAP 環境の ACS の設定」

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

「[Posture Validation] ページのリファレンス」

ポスチャ確認とは

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

ポスチャ確認では、エンドポイントに関連付けられているポスチャ データに規則のセットを適用します。結果として、そのエンドポイントに対する信頼レベルのアセスメントが得られます。 Healthy または Infected などのポスチャ トークンは、エンドポイントの状態を表します。

ポスチャ トークンは、ネットワーク アクセスの認可規則における条件の 1 つになります。ポスチャ確認を従来のユーザ認証と併せて使用することで、エンドポイントおよびユーザの完全なセキュリティ アセスメントを実現します。

ネットワーク アクセス コントロールでのポスチャ確認

ポスチャ確認は、ネットワーク アクセス コントロール(NAC)で使用できます。NAC は、ネットワーク インフラストラクチャを使用して、ネットワーク コンピューティング リソースへのアクセスを求めるすべてのデバイスをセキュリティ ポリシーに適合させます。

セキュリティ ポリシーでは、新たなセキュリティの脅威による損害を抑えます。NAC を使用することにより、ポリシーに準拠した信頼できるエンドポイント デバイス(PC、サーバ、PDA など)に対してのみネットワーク アクセスを許可し、準拠しないデバイスのアクセスを制限することができます。NAC ソリューションの詳細については、 http://www.cisco.com/go/NAC を参照してください。

図 13-1 に、ポスチャ確認を含む、一般的な NAC 展開のコンポーネントを示します。

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

 

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

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

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

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

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

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

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

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

ポスチャ確認とネットワーク アクセス プロファイル

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

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

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

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

ポスチャ トークン

ポスチャ トークンは、エンドポイント デバイスの状態、またはコンピュータにインストールされた NAC 準拠アプリケーションの状態を示します。ACS は、次の 2 種類のポスチャ トークンを認識します。

System Posture Token(SPT; システム ポスチャ トークン)は、コンピュータの状態を示します。

Application Posture Token(APT; アプリケーション ポスチャ トークン)は、NAC 準拠のアプリケーションの状態を示します。

ACS は、要求に適用されたすべてのポリシーから得られた APT どうしを比較して、各要求の SPT を判別します。最も重大な APT が SPT になります。

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

 

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

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 準拠アプリケーションからのアトリビュートと、Cisco Trust Agent からのアトリビュートは、異なるクレデンシャル タイプと見なされます。

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

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

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

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

内部ポリシーの規則で使用されるデータ タイプや演算子など、アトリビュートに関する詳細については、「ポスチャ確認アトリビュートのデータ タイプ」を参照してください。 CSUtil.exe を使用して、カスタム RADIUS ベンダーと VSA 設定を追加および設定できます。 CSUtil.exe を使用したポスチャ確認アトリビュートのエクスポート、追加、または削除については、「ユーザ定義の RADIUS ベンダーと VSA のセット」を参照してください。

拡張アトリビュート

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

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

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

拡張アトリビュートを追加または削除できます。

ACS for Windows の場合、 CSUtil.exe コマンドを使用します。詳細については、「ポスチャ確認アトリビュート」を参照してください。

ACS SE の場合、Web インターフェイスの [NAC Attributes Management] ページを使用します。詳細な手順については、「[NAC Attribute Management](ACS SE のみ)」を参照してください。

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

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

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

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

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

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

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

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

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

mm/dd/yyyy
hh
:mm:ss

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

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 つめの規則を先に配置する必要があります。

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

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

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

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

値または通知文字列

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

規則の詳細については、「アクセス要求の分類」を参照してください。

設定方法については、「内部ポリシーの作成」および 「[Internal Posture Validation Setup] ページ」を参照してください。

外部ポリシー

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

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

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

外部ポリシー設定オプションについては、「外部ポスチャ確認サーバの編集」および 「[External Posture Validation Setup] ページ」を参照してください。

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

ここでは、次の項目について説明します。

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

「デバイス タイプの監査」

「ACS での NAC の設定」

外部監査サーバについて

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

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

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

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

host id

ip-address

mac-address (オプション)

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

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

 

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

監査ポリシー
説明

auditServerConfiguration

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

exemptionList

監査が免除される MAC アドレス と IP アドレスのいずれか(またはその両方)、およびグループのリスト。

inverseExemptionFlag

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

exemptionToken

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

defaultInProgressToken

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

staticAttributes

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

tokenMappings

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

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

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

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

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

Cisco Trust Agent が機能していないことを 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 文字列になります。

デバイス タイプの監査

MAC 認証のセキュリティ チェックの強化として、デバイス タイプを確認し、デバイスを適切な宛先ユーザ グループに割り当てる監査ポリシーを設定できます。たとえば、問題のあるデバイスが Mismatch というユーザ グループに割り当てられる場合があります。または、プロセスでグループが割り当てられないと、デバイスが Quarantine というユーザ グループに割り当てられることがあります。MAC 認証および監査ポリシーが、プリンタなどの同じデバイス タイプを返した場合、監査ポリシーはデバイスをプリンタ グループに割り当てることができます。

ポリシーの構成

[External Posture Validation Audit Server Setup] ページのオプションを使用して、監査ポリシーを定義します。これらのオプションでは、監査サーバからのデバイス タイプ要求をイネーブルにしたり、またはデバイス タイプがないときにグループを割り当てることができます。また、このページのオプションを使って、論理比較に基づいて特にグループの割り当てを管理できる規則を作成することもできます。

完全な監査ポリシーもまた、以前 [External Posture Validation Server Setup] ページで設定した要素に依存します。それらの要素には、ホスト、監査サーバおよび監査フローのセットアップが含まれます。さらに、ポリシーには、フェールオーバー シナリオで機能するセカンダリ監査サーバの設定オプションも含まれます。

ACS は、監査サーバとのカンバセーションで GAME プロトコルを使用します。カンバセーションには、デバイスのスキャンによって監査サーバが決定するデバイス タイプの要求が含まれます。プロトコルまたは監査ポリシー フローがエラーを返すと、システムにエラー メッセージが表示されます。

ポリシーを設定する際は、次の点に留意してください。

ACS は、デバイス タイプ アトリビュートのないベンダーに対して、この機能を設定できません。Qualys は、このアトリビュートに対してテスト済みで、現在これをサポートしている唯一のベンダーです。

監査サーバがデバイス タイプ アトリビュートを返さないと、アトリビュートが要求されなかったかのようにポリシー評価が継続されます。

ACS は、Passed および Failed ログにデバイス タイプ アトリビュートを記録します。

ユーザ グループとデバイス タイプ

MAC 認証は、Printer または PC といったユーザ グループの形式でデバイス タイプを返します。監査ポリシーは、NAC アトリビュートのデバイス定義リストに依存します。このリストには、MAC ユーザ グループとの比較のための Printer と PC が含まれます。または、監査ポリシーはユーザ定義のデバイス タイプ文字列によって決めることもできます。

MAC ユーザ グループの場合、ポリシーは Any のユーザ グループをサポートします。この場合、ACS は返されたグループが任意のグループか、またはグループがないものと見なします。デバイス タイプでは、監査によって返されたデバイス タイプを解釈する場合、ポリシーは Match-all をサポートします。

グループの割り当て

グループの割り当ては、ネットワークの設定に応じて異なります。ネットワークで複数デバイスをサポートしている場合もあれば、特定のデバイスのみをサポートしている場合もあります。監査ポリシーをサポートするには、Mismatch や Quarantine などの宛先デバイス グループを追加する必要があります。設定によっては追加グループが必要な場合もあります。

宛先ユーザ グループへの割り当ては、次の条件に基づきます。

Device-Type Returned:グループの割り当ては、MAC デバイス タイプと NAC デバイス タイプ アトリビュートを比較する規則に基づきます。

No Device-Type:グループの割り当ては、選択したグループに基づきます。

No Device-Type or Group:グループの割り当ては、選択したグループに基づきます。

No Token or Group:グループの割り当ては、ポスチャ トークン、タイムアウトおよびグループを含むフェール オープンの設定に基づきます。フェール オープンの設定がない場合、システムはエラーを返します。

グループ マッピングの規則

各グループ マッピングの規則では、MAC 認証が返すデバイス ユーザ グループと監査サーバが返すデバイス タイプを比較する演算子を使用します。比較では、次のいずれかの演算子を定義できます。

Match all device types(ACS は、すべてのデバイス タイプでワイルドカードでの照合を実行)

Device type equals(等しいデバイス タイプ)

Device type does not equal(等しくないデバイス タイプ)

Contains(中間一致)

Starts with(前方一致)

Regular expression(正規表現)

次の例を参考にしてください。

グループが printers に等しく、デバイス タイプが Printer に等しくない場合、グループ Mismatch (または Quarantine )を割り当てます。

グループが NotKnown に等しく、かつデバイス タイプが Printer に等しい場合、グループ printers を割り当てます。

グループが embedded-os に等しく、デバイス タイプが Printer に等しくない場合、グループ quarantine を割り当てます。

グループが Any に等しく、かつデバイス タイプが PC に等しい場合、グループ reject を割り当てます(これは、管理者がコンピュータに許可していない LAN であることが予想されます)。

グループが Any に等しく、かつデバイス タイプが unknown に等しい場合、 quarantine を割り当てます。

ポリシー リスト

各規則の定義は、優先度順に並べ替えることができるポリシー リストに表示されます。

ネットワーク アクセス コントロールのレイヤ 2 監査

ACS では、まず、IP アドレスを受信できる隔離ネットワークにデバイスがアクセスできるようにします。デバイスが IP アドレスを受信するまで監査は開始されません。開始する監査は、レイヤ 3(L3)ホストの監査と同じです。

ホストの IP アドレスを認識するように NAD を事前に設定しておく必要があります。ACS は、最初のアクセス要求に応答し、NAD が IP アドレスを認識したときに別のアクセス要求を発行するように NAD に通知します。NAD がホストの IP アドレスを認識しない場合、ACS は失敗条件を呼び出し、ポリシー フローは audit fail-open ポリシーに従います。管理者は audit fail-open ポリシーを使用して、ユーザを拒否するか、ポスチャ トークンおよびオプションのユーザ グループを割り当てるかを選択できます。

監査ポリシーは、MAC Authentication Bypass(MAB; MAC 認証バイパス)が失敗した場合のバックアップの検証として機能させることができます。監査ポリシーでは、現在のセッションに割り当てられた ACS ユーザ グループをテストするポリシー条件を適用して、MAB が失敗したかどうかをテストします。たとえば、ユーザ グループが、MAB によって失敗した認証に割り当てられたユーザ グループと一致するかどうかをテストでき、一致した場合にのみ監査が継続します。

設定情報については、「ネットワーク アクセス プロファイル」を参照してください。

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; アトリビュート定義ファイル)をインポートする必要があります。

監査ベンダーを ACS 内部ディクショナリに追加する必要があります。

ACS for Windows の場合、外部ポスチャ確認監査サーバを設定する前に、 CSUtil.exe コマンドを使用します。詳細な手順については、「外部監査ポスチャ確認サーバのインポート」を参照してください。

ACS SE の場合、Web インターフェイスの [NAC Attributes Management] ページを使用します。詳細な手順については、「[NAC Attribute Management](ACS SE のみ)」を参照してください。


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


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

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

ステップ 3 [Advanced Options] ページで、[Microsoft Network Access Protection Settings] のチェックボックスをオンにします。

ステップ 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 プロファイルをセットアップする詳細な手順については、「NAP とプロファイルベース ポリシーの設定ワークフロー」を参照してください。


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


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

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

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

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

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

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

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


 

NAC および NAP 環境の ACS の設定

ACS には、Cisco ネットワーク アクセス コントロール(NAC)および Microsoft Network Access Protection(NAP; ネットワーク アクセス保護)環境で ACS が動作するように設定するための次のオプションがあります。

外部 AAA サーバの設定

Microsoft NAP 環境では、NAP サーバが Statement of Health(SoH; 正常性ステートメント)を ACS または他の AAA サーバに送信します。SoH の処理に基づいて、アクセスやアクセス レベルを許可または拒否するように ACS を設定できます。外部 AAA サーバを設定する方法の詳細については、「外部 AAA サーバの設定」を参照してください。

正常性ステートメントのポスチャ確認規則の設定

ACS が SoH のアトリビュートに基づいてユーザ アクセスに関する決定を行うように、SoH のポスチャ確認規則を設定できます。SoH のポスチャ確認規則を設定する方法の詳細については、「正常性ステートメントを処理するポスチャ確認ポリシーの設定」を参照してください。


) NAC および NAP 環境の ACS を設定する方法の詳細については、『Configuration Guide for Cisco Secure ACS, 4.2』の第 9 章「NAC/NAP Configuration Scenario」を参照してください。


ポリシーの設定

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

ここでは、次の項目について説明します。

「ポスチャ確認オプション」

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

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

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

「MAC 認証バイパスを使用した監査処理」

ポスチャ確認オプション

次のポスチャ確認オプションを設定できます。

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

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

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

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

 

表 13-3 ポスチャ確認オプション

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

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

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

External Posture Validation

外部のポスチャ確認サーバはポリシーを確認します。

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

External Audit Posture Validation

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

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


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


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


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

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

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

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

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

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


 

内部ポリシーの作成

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

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

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

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

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] をクリックする。

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

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

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

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

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

Cisco Trust Agent ポスチャ プラグイン アトリビュートと値については、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. すでに追加した条件セットを変更するには、次の手順を実行します。

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

b. [Remove] をクリックします。

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

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

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

b. 値を入力します。

c. Enter キーを押します。

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

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

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

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

b. 規則が適切な位置に来るまで、[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] をクリックします。


 

外部 AAA サーバの設定

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

始める前に

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

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

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

Microsoft Vista クライアントを含むネットワーク(NAC および NAP ネットワーク)の SoH を評価するために使用する外部 AAA サーバを設定することもできます。

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


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

ステップ 2 [External Posture AAA Servers] テーブルで、[Add Server] をクリックします。

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

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

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

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


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


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

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

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

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

ステップ 6 使用可能な転送アトリビュートを選択済み転送アトリビュート カラムに移動し、プライマリ外部サーバまたはセカンダリ外部サーバに送信する転送アトリビュートを決定します。

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

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


 

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

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

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


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

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

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

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

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


 

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

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

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


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

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

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

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

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


 

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

[External Posture Validation Audit Server Setup] ページで、外部ポスチャ確認監査サーバの追加、編集および削除を行います。ポリシーは再使用が可能です。つまり、1 つの監査ポリシーを複数のネットワーク アクセス プロファイルに関連付けることができます。

ACS はデフォルトでシスコ以外のアトリビュートを含めません。したがって、NAC ポスチャ確認ポリシーで確認する各ベンダー アプリケーションから、NAC Attribute Definition File(ADF; アトリビュート定義ファイル)をインポートする必要があります。追加したアトリビュートを使用して、内部ポリシーの条件を作成できます。

NAC により、ユーザまたはマシンの ID だけでなく、ホストのポスチャ確認にも基づいて、ネットワーク ホストを認可できるようになりました。ポスチャ確認は、ホストのクレデンシャルと、シスコおよび NAC パートナーである他のベンダーによって定義された Attribute-Value Pair(AVP; アトリビュートと値のペア)から作成するポスチャ確認ポリシーとを比較することで、判別されます。NAC アトリビュートの範囲はさまざまなベンダーとアプリケーションに及ぶため、シスコ以外のアトリビュートをインポートする必要があります。

始める前に

始める前に、次の手順を実行する必要があります。

監査ベンダーを ACS 内部ディクショナリに追加します。

ACS for Windows の場合、CSUtil.exe コマンドを使用します。詳細な手順については、「外部監査ポスチャ確認サーバのインポート」を参照してください。

ACS SE の場合、Web インターフェイスの [NAC Attributes Management] ページを使用します。詳細な手順については、「[NAC Attribute Management](ACS SE のみ)」を参照してください。

宛先ユーザ グループを定義します。「デバイス タイプの監査」を参照してください。

必要に応じて RAC を設定します。「RADIUS 認可コンポーネント」を参照してください。

外部ポスチャ確認監査サーバの追加

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


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

[Posture Validation Components Setup] ページが表示されます。

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

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

ステップ 3 [Add Server] をクリックします。

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

ステップ 4 監査ポリシーを識別する [Name] を入力します。この手順のすべてのオプションについては、表 13-13を参照してください。

ステップ 5 監査ポリシーの [Description] を入力します。

ステップ 6 [Which Groups and Hosts are Audited] 領域で適切なオプションを選択します。必要に応じて、IP および MAC アドレスを使用してホストを特定します。

ステップ 7 [Posture Token] を選択します。

ステップ 8 [Use These Audit Servers] 領域で [Audit Server Vendor] を選択します。

ステップ 9 [Primary Server Configuration] オプションをオンにしてプライマリ サーバを設定します。

ステップ 10 プライマリ サーバの設定情報を入力します。

監査ベンダーが表示されない場合、内部 ACS ディクショナリでベンダーの監査 APT を定義する必要があります。

ACS for Windows の場合、CSUtil.exe コマンドを使用します。詳細な手順については、「ポスチャ確認アトリビュート」を参照してください。

ACS SE の場合、Web インターフェイスの [NAC Attributes Management] ページを使用します。詳細な手順については、「[NAC Attribute Management](ACS SE のみ)」を参照してください。

ステップ 11 [Secondary Server Configuration] オプションをオンにしてプライマリ サーバを設定します。

ステップ 12 セカンダリ サーバの設定情報を入力します。

ステップ 13 [Audit Flow Settings] 領域のドロップダウン リストから一時ポスチャ トークンを選択します。

ステップ 14 タイムアウト オプションを選択します。

ステップ 15 ポーリング間隔を入力します。

ステップ 16 [Maximum amount of times the Audit Server should be polled] を選択します。

ステップ 17 [Policy string to be sent to the Audit Server] を入力します。

ステップ 18 監査サーバと MAC 認証が返すデバイス タイプを相互チェックする場合は、[Audit Policy] 領域の [Request Device Type from Audit Server] オプションをオンにします。

チェックボックスが使用できない場合(グレー表示)、内部 ACS ディクショナリでベンダーの監査デバイス タイプ アトリビュートを定義します。

ACS for Windows の場合、CSUtil.exe コマンドを使用します。詳細については、「ポスチャ確認アトリビュート」を参照してください。

ACS SE の場合、Web インターフェイスの [NAC Attributes Management] ページを使用します。詳細は「[NAC Attribute Management](ACS SE のみ)」を参照してください。

ステップ 19 デフォルトの宛先グループを設定する場合は、[Assign This Group if Audit Server Did not Return a Device-Type] オプションをオンにします。

ステップ 20 [Add] をクリックしてデバイス タイプ フィードバック規則を追加します。

ステップ 21 デバイス タイプを選択します。

ステップ 22 MAC 認証が返すデバイス タイプと最初に比較する [User Group] を選択します。

ステップ 23 演算子とデバイス タイプを選択して、[Device Type] の比較ロジックを完成させます。ドロップダウン ボックスにデバイス タイプが表示されない場合は、テキスト ボックスにデバイス タイプを入力します。

ステップ 24 デバイス タイプの比較ロジックの結果に基づいて ACS が割り当てるユーザ グループを選択します。

ステップ 25 外部ポスチャ確認監査サーバの設定を保存するには、[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] をクリックします。


 

MAC 認証バイパスを使用した監査処理

監査要求に、エージェントレス ホスト認証との照合を含めることができます。監査サーバ処理は、MAB 認証ポリシーと監査ポリシーに対する監査要求を二重にチェックしてから、2 つのポリシーの評価を統合できます。

監査要求にはエンドポイントの MAC アドレスと IP アドレスが必要なため、統合ポリシーの評価は、レイヤ 2 IP およびレイヤ 3 NAC 展開のみで可能です。

ACS では、MAB および監査が相互に運用するために、次の主要なアトリビュートが必要です。

[10] Service-type = 10

[31] Calling-Station-ID = Endpoint MAC Address

[8] Framed-IP-Address = Endpoint IP address

[26:9:1] Cisco-AV-Pair = audit-session-id = Id

[26:9:1] Cisco-AV-Pair = aaa:service = ip_admission

ワークフロー

この機能では、次の設定が必要です。

エージェントレス ホスト テンプレートを使用する NAP

MAB 認証

外部ポスチャ確認監査

GAME グループ フィードバック ポリシー

監査対象ユーザ グループ

監査サーバとネットワーク アクセス プロファイルとの関連付け

処理

要求の処理は次のようになります。

1. エージェントレス ホスト ポリシーと照合して監査要求が評価されます。

2. エージェントレス ホスト ポリシーによって、監査要求にユーザ グループが割り当てられます。

3. 監査ポリシーは、割り当てられたユーザ グループと設定されているグループ セットを比較します。

4. 割り当てられたグループが設定されているグループ セットに一致する場合、GAME 要求が作成され、応答が処理されます。割り当てられたグループが一致しない場合、GAME 要求は作成されません。

5. 一致がある場合、認可ポリシーが処理され、その結果の監査応答が発信元のネットワーク アクセス デバイスに送られます。

ポリシーの設定

ACS では、エージェントレス ホストの認証と認可のためのさまざまな設定および機能をサポートしています。 表 13-4 は、ポリシーの組み合せ、機能、および設定をまとめたものです。

 

表 13-4 エージェントレス ホストの認証および認可のサポート

使用例
監査
認可の基盤
説明
MAB
グループ フィルタ
ポスチャ
デバイス タイプ
トークン
グループ
の所属

MAB のみ

Y

N

N

N

N

MAB

ポスチャのみの監査

N

N

Y

N

Y

なし

ポスチャとデバイス タイプのみの監査。たとえば、デバイス タイプに基づいた認可とは異なります。

N

N

Y

Y

Y

なし* またはデバイス タイプ

MAB およびポスチャの監査。たとえば、MAB が失敗したときでも、Healthy は割り当てられます。

Y

N

Y

N

Y

MAB

MAB およびポスチャとデバイス タイプの監査。たとえば、MAC が認証されないときでも、printers は含まれます。

Y

N

Y

Y

Y

MAB またはデバイス タイプ

MAB およびポスチャの監査。MAB の成功は必須です。MAC が認証されない場合、監査は不要です。

Y

MAB の失敗グループ以外すべて監査

Y

N

Y

MAB

MAB、ポスチャおよびデバイス タイプの監査。MAB の成功は必須です。MAC が認証されない場合、監査は不要です。

Y

MAB の失敗グループ以外すべて監査

Y

Y

Y

MAB またはデバイス タイプ

MAB。ただし、MAC が認証されない場合はポスチャの監査。たとえば、MAB または Healthy トークンをネットワークに対して許可できます。

Y

MAB の失敗グループのみ監査

Y

N

Y

MAB

MAB。ただし、MAC が認証されない場合は、ポスチャとデバイス タイプの監査。たとえば、管理デバイスはネットワークに対して許可されます。または、認可はデバイス タイプまたはトークンに基づきます。

Y

MAB の失敗グループのみ監査

Y

Y

Y

MAB またはデバイス タイプ

 
*この場合、グループの割り当てはデバイスの一致に応じて異なります。一致しない場合、デバイス タイプのグループ割り当てポリシーはユーザ グループを作成しません。

次の手順を使用して、エージェントレス ホストと監査の相互運用性を設定します。


ステップ 1 ナビゲーション バーの [Network Access Profiles] をクリックします。

ステップ 2 [Add Template Profile] をクリックします。

ステップ 3 プロファイルの [Name] と [Description] を入力します。

ステップ 4 [Agentless Host] テンプレートを選択します。

ステップ 5 [Active] をオンにしてプロファイルをアクティブにするか、または非アクティブのままにします。

ステップ 6 ナビゲーション バーの [Network Access Profiles] をクリックします。

ステップ 7 エージェントレス ホスト <profile_name> の [Protocols] で、[Allow Agentless Request Processing] をオンにします。

ステップ 8 エージェントレス ホスト <profile_name> の [Authentication] で、[Authenticate MAC With] セクションに入力します。「エージェントレス要求処理」 を参照してください。

ステップ 9 ナビゲーション バーの [Posture Validation] をクリックして、[External Posture validation Audit Setup] を選択します。

ステップ 10 Game グループ フィードバック機能をセットアップします。「外部ポスチャ確認監査サーバの追加」 を参照してください。

ステップ 11 監査サーバとネットワーク アクセス プロファイルを関連付けます。「エージェントレス ホストに対するポスチャ確認の設定」 を参照してください。


 

[Posture Validation] ページのリファレンス

次のトピックでは、ナビゲーション バーの [Posture Validation] ボタンからアクセスするページについて説明します。

「[Posture Validation Components Setup] ページ」

「[Internal Posture Validation Setup] ページ」

「[External Posture Validation Setup] ページ」

「[External Posture Validation Audit Setup] ページ」

[Posture Validation Components Setup] ページ

このページを使用して、ポスチャ確認の各ページにアクセスします。

[Posture Validation Components Setup] ページを表示するには、ナビゲーション バーの [Posture Validation] をクリックします。

 

表 13-5 [Posture Validation Components Setup] ページ

オプション
説明

Internal Posture Validation Setup

[Posture Validation Policies] ページを表示します。内部ポリシーには、ポスチャ確認要求に適用されるポスチャ トークンを決定する規則が含まれます。

External Posture Validation Setup

[External Posture Validation Servers] ページが表示されます。ACS はクレデンシャルを外部ポスチャ確認サーバに転送し、サーバはポスチャ トークンを返します。

External Posture Validation Audit Setup

[External Posture Validation Audit Server] ページが表示されます。監査サーバは、エージェントレス ホストのポスチャ情報を返します。

[Internal Posture Validation Setup] ページ

次のトピックでは、[Internal Validation Setup] ページについて説明します。

「[Posture Validation Policies] ページ」

「[Posture Validation Policy] ページ」

「[Posture Validation Rules for <policy_name>] ページ」

「[Posture Validation Rule - <policy_name>] ページ」

「[Add/Edit Condition] ページ」

[Posture Validation Policies] ページ

このページで、ポリシーを追加したり、既存のポリシーにアクセスして編集します。

[Posture Validation Policies] ページを表示するには、ナビゲーション バーの [Posture Validation] をクリックして、[Internal Posture Validation Setup] を選択します。

 

表 13-6 [Posture Validation Policies] ページ

オプション
説明
Posture Validation Policies

[Name] および [Description] でポリシーを特定します。[Policy Details] には、ポリシーに関連付けられている規則が ID 番号で示されます。

Name <policy_name>

[Posture Validation Policies] ページを表示して編集します。

Add Policy

[Posture Validation Policy] ページを表示して、新しいポリシーを作成します。

[Posture Validation Policy] ページ

このページで、新規ポリシーの名前と説明を指定します。

[Posture Validation Policy] ページを表示するには、[Posture Validation] > [Internal Posture Validation Setup] > [Add Policy] を選択します。

 

表 13-7 [Posture Validation Policy] ページ

オプション
説明

Name

ポリシー名を定義します。ポリシー名を選択していると [Descriptions] が表示されないため、名前は説明的なものにする必要があります。

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

Description

ポリシーを説明する最大 255 文字のテキストを指定します。

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

Submit

[Posture Validation Rules for <policy_name>] ページを表示します。この場合の <policy_name> は新規ポリシーの名前です。

[Posture Validation Rules for <policy_name>] ページ

このページを使用して規則を表示したり、規則の順番を設定します。

規則を編集するときに [Posture Validation Rules for <policy_name>] ページを表示するには、[Posture Validation] > [Internal Posture Validation Setup] > [<policy_name>] を選択します。

 

表 13-8 [Posture Validation Rules for <policy_name>] ページ

オプション
説明
Posture Validation Rules for <Name>

各規則を ID 番号で表示します。規則の Conditions and Actions(ポスチャ トークンおよび通知文字列として)を指定します。[Description](指定された場合)には、ポリシーの情報が表示されます。

Condition <condition_name>

[Posture Validation Rule - <policy_name>] ページを表示して、既存の条件を編集します。

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

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

Add Rule

[Posture Validation Rule - <policy_name>] ページを表示して、規則を作成します。

Up、Down

選択した規則を移動します。ソート順序をデータベースに送信します。

Rename

[Posture Validation Policy] ページを表示して、ポリシーの名前を変更します。

Clone

選択したポリシーと同一のポリシーを作成します。クローニングされたポリシーを編集して新規ポリシーを作成します。

Delete

ポリシーを削除します。

Done

[Posture Validation Policies] ページを表示します。

[Posture Validation Rule - <policy_name>] ページ

このページを使用して規則を表示および編集します。

規則を追加するときに [Posture Validation Rule - <policy_name>] ページを表示するには、[Posture Validation] > [Internal Posture Validation Setup] > [<policy_name>] > [<condition>] を選択します。

 

表 13-9 [Posture Validation Rule - <policy_name>] ページ

オプション
説明
Condition Sets

規則に関連付けられている条件セットを表示します。<condition_name> によって、[Add/Edit Condition] ページが表示されます。

規則を追加または編集する場合、複合ブール式によって、規則に関連付けられている条件の論理上の処理が決定されます。

[Match OR inside Condition and AND between Condition Sets]:条件をそれほど厳しく処理しません。

[Match AND inside Condition and OR between Condition Sets]:条件を厳しく処理します。

Add Condition Set

[Add/Edit Condition] ページを表示します。

Posture Token

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

Notification String

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

[Add/Edit Condition] ページ

このページを使用して条件を追加または編集します。

規則を追加するときに [Posture Validation Rules for <policy_name>] ページを表示するには、[Posture Validation] > [Internal Posture Validation Setup] > [<policy_name>] > [<condition>] > [<condition_set>] を選択します。

 

表 13-10 [Add/Edit Condition] ページ

オプション
説明

Condition Elements Table

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

Attribute

使用可能なアトリビュートが表示されます。

Entity

エンティティが必要なアトリビュートについて、使用可能なエンティティを表示します。

Operator

アトリビュートの適切な演算子を表示します。

Value

アトリビュートの適切な値を指定します。

[External Posture Validation Setup] ページ

次のトピックでは、[External Posture Validation Setup] ページについて説明します。

「[External Posture Validation Servers] ページ」

「[Add/Edit External Posture Validation Server] ページ」

[External Posture Validation Servers] ページ

このページで、既存の外部ポスチャ確認サーバを表示します。

[External Posture Validation Servers] ページを表示するには、[Posture Validation] > [External Posture Validation Setup] を選択します。

 

表 13-11 [External Posture Validation Servers] ページ

オプション
説明

Name

[Add/Edit External Posture Validation Server] ページを表示して、既存のポリシーを編集します。[Description]、[Forward Credential Type]、および [Server Details] には、ポリシーの現在の設定が表示されます。

Add Server

[Add/Edit External Posture Validation Server] ページを表示して、新しいポリシーを作成します。

[Add/Edit External Posture Validation Server] ページ

このページで、外部ポスチャ確認サーバを追加または編集します。

[Add/Edit External Posture Validation Server] ページを表示するには、[Posture Validation] > [External Posture Validation Setup] を選択します。次に [Add Server] をクリックしてサーバを追加するか、または <server_name> をクリックしてサーバを編集します。

 

表 13-12 [Add/Edit External Posture Validation Server] ページ

オプション
説明

Name

サーバを識別する名前を指定します。

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

Description

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

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

Primary Server Configuration
Secondary Server Configuration

プライマリ NAC サーバ(およびオプションのセカンダリ NAC サーバ)をイネーブルにします。ACS は、これらのサーバを使用してポリシーを適用し、ACS が転送するクレデンシャル タイプのセットを設定します。

外部ポリシーが適用されるポスチャ確認要求ごとに、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

サーバへのアクセスに必要なユーザ名を指定します。サーバがパスワードで保護されていない場合、[Username] および [Password] フィールドの値は無視されます。

Password

サーバへのアクセスに必要なパスワードを指定します。サーバがパスワードで保護されていない場合、[Username] および [Password] フィールドの値は無視されます。

Timeout (sec)

ドメインの名前解決を含め、外部サーバから結果を受信するまで ACS が待機する秒数。Timeout は、ゼロ(0)よりも大きな値で指定してください。デフォルト値は 10 です。

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

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

Trusted Root CA

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

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

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

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

Forwarding Credential Types

[Available Credentials] リストは、外部サーバに送信 されない クレデンシャル タイプを指定します。[Selected Credentials] は、外部サーバに送信 される クレデンシャル タイプを指定します。

[Available Credential] リストにクレデンシャル タイプを追加するには、次の情報を参照してください。ACS for Windows の場合、CSUtil.exe コマンドを使用します。詳細な手順については、「外部監査ポスチャ確認サーバのインポート」を参照してください。

ACS SE の場合、Web インターフェイスの [NAC Attributes Management] ページを使用します。詳細な手順については、「[NAC Attribute Management](ACS SE のみ)」を参照してください。

[External Posture Validation Audit Setup] ページ

次のトピックでは、[External Posture Validation Audit Setup] ページについて説明します。

「[External Posture Validation Audit Server] ページ」

「[External Posture Validation Audit Server Setup] ページ」

[External Posture Validation Audit Server] ページ

[External Posture Audit Server] ページで、設定された各サーバの名前、説明、サーバの詳細、および現在のポスチャ トークンを表示します。

[Add/Edit External Posture Validation Server] ページを表示するには、[Posture Validation] > [External Posture Validation Audit Setup] を選択します。

[External Posture Validation Audit Server Setup] ページ

このページで、外部ポスチャ確認監査サーバを追加または編集します。

[Add Server] ページ

このページを表示するには、[Posture Validation] > [External Posture Validation Audit Setup] > [Add Server] を選択します。

[Edit Server] ページ

このページを表示するには、[Posture Validation] > [External Posture Validation Audit Setup] を選択し、<server_name> をクリックします。必要に応じて、[Audit Server] 設定を編集できますが、次のような例外があります。

監査ポリシーが複数の NAP に関連付けられている場合、ポリシーへの変更は、関連付けられている各 NAP のポスチャ確認に影響します。

ポリシーの名前を変更する場合、[Submit] をクリックすると新しいポリシーが作成されます。ポリシーの名前を変更したり、既存の複数のポリシーの設定を同時に変更したりすることはできません。

 

表 13-13 [External Posture Validation Audit Server Setup] オプション

オプション
説明

Name

監査ポリシーの名前。

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

Description

監査ポリシーの説明(最大 255 文字)。

Which Groups and Hosts are Audited

Audit all user groups
Audit these user groups
Do not audit these user groups

ユーザ グループ オプションでは、[Selected Groups] リストのグループの監査を決定します。

Audit all hosts

Audit these hosts
Do not audit these hosts

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

特定のホストだけを監査するか、または [Host IP Addresses and Ranges (IP/MASK)](カンマ区切り形式)フィールドに定義されている特定のホストを除外します。

Host MAC Address(カンマ区切り形式)の場合、ACS は 00-0D-60-FB-16-D3 または 000D.60FB.16D3 の 2 つの MAC アドレス形式を受け入れます。範囲を示す MAC プレフィクスを入力できます。たとえば、00-0D-60-FB-16 または 000D.60 は、これらのバイトで始まる任意の MAC アドレスに一致します。

MAC プレフィクスには、偶数の 16 進数字を含める必要があります。

MAC アドレスのマッチングでは、大文字と小文字が区別されます。

Select a token for the hosts that will not be audited

監査されないホストに ACS が適用するポスチャ トークン

Use These Audit Servers

Audit Server Vendor

ドロップダウン リストに、内部 ACS ディクショナリに定義されている監査 Application Posture Token(APT; アプリケーション ポスチャ トークン)のあるベンダーが表示されます。

ドロップダウン リストに監査サーバが表示されない場合、監査サーバのセットアップについては、「ポスチャ確認アトリビュート」(ACS for Windows の場合)または「[NAC Attribute Management](ACS SE のみ)」を参照してください。

Primary Server Configuration、Secondary Server Configuration

いずれのオプションも、監査サーバの設定をイネーブルにします。ACS では、プライマリ サーバが必要です。セカンダリ サーバは、フェールオーバー機能を果たします(必須ではありません)。[Secondary Server Configuration] のオプションは、[Primary Server Configuration] のオプションと同じです。

URL

監査サーバの URL。HTTP または HTTPS プロトコルを指定します。

URL は、次のフォーマットに従う必要があります。

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

host は 外部サーバのホスト名または IP アドレス、port はポート番号、resource は URL の残りの部分で、いずれも外部サーバそのもので必要になります。URL は、サーバのベンダーと設定によって異なります。

監査サーバ マニュアルには、フォーマットに関する特定のガイドラインがあります。

Username

監査サーバで必要なユーザ名。

Password

監査サーバで必要なパスワード。

Timeout (sec)

ドメインの名前解決を含め、監査サーバから結果を受信するまで ACS が待機する秒数。Timeout は、ゼロ(0)よりも大きな値で指定してください。

Trusted Root CA

監査サーバの URL が HTTP プロトコルを指定する場合に必要な認証局。このオプションは、プライマリ サーバにインストールされている監査サーバ証明書を発行した認証局と一致します。

Validate Certificate Common Name

このオプションをオン(イネーブル)にすると、証明書の共通名との比較のために、URL 内のホスト名が表示されます。名前が一致しない場合、ACS は SSL 接続を閉じ、ポスチャ確認が失敗して、ユーザ アクセスが拒否されます。

Audit Flow Settings

Use this Posture Token while Audit Server does not yet have a posture validation result

結果を待つ間、ACS から NAD に送信される仮のポスチャ トークン。監査サーバが応答のないホストの実際のポスチャを決定する前に、ACS は進行中のトークンを使用します。

Polling Intervals and Session-Timeout

監査サーバによって送信されたタイムアウト値、または認可ポリシーで設定されたタイムアウト値。設定に認可ポリシーで設定された値を使用する場合、ACS にポーリング間隔が必要になります。最終結果のトークンに特定のタイムアウト値を割り当てるために、認可ポリシーには必要な RAC を含める必要があります。「認可規則の設定」 を参照してください。

Maximum amount of times the Audit Server should be polled

ACS が監査サーバに結果(ポスチャ トークン)を問い合せる最大回数。範囲は 1 ~ 10 回です。

Policy string to be sent to the Audit Server

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

[GAME Group Feedback]

Request Device Type from Audit Server

監査ポリシーの設定オプションをイネーブルにします。イネーブルにした場合、監査機能は、監査サーバにデバイス タイプを要求し、そのデバイス タイプを MAC 認証が返すデバイス タイプと照合できます。

チェックボックスが使用できない場合、内部 ACS ディクショナリでベンダーの監査デバイス タイプ アトリビュートを定義します。

ACS for Windows の場合、CSUtil.exe コマンドを使用します。詳細については、「ポスチャ確認アトリビュート」を参照してください。

ACS SE の場合、Web インターフェイスの [NAC Attributes Management] ページを使用します。詳細は「[NAC Attribute Management](ACS SE のみ)」を参照してください。

Assign This Group if Audit Server Did not Return a Device Type

監査サーバがデバイス タイプを返さないときに、任意の管理者定義のグループにデバイスを割り当てられるようにします。

User Group

Any を含むすべてのユーザ グループを表示します。MAC 認証が返すデバイス タイプは、最初にこのデバイス タイプのリストと比較されます。

Device Type

演算子とデバイス タイプを使用して、[User Group] の比較基準を定義します。

演算子の有効な値は次のとおりです。
match-all
=
!=
contains
starts-with
regular-expression

デバイス タイプ ドロップダウンの有効な値は編集できません。次の値が含まれます。
Printer
IP Phone
Network Infrastructure
Wireless Access Point
Windows
Unix
Mac
Integrated Device
PDA
Unknown

デバイス タイプ ドロップダウンに特定のデバイスがない場合は、テキスト ボックスにデバイス タイプを入力します。

Assign User Group

管理者定義のユーザ グループのドロップダウン リスト。最初の [User Group] と [Device Type] の比較が成功すると、ACS はこのユーザ グループを割り当てます。

Add、Delete、Up、Down

ユーザ グループに影響するコントロール。

Submit、Delete、Cancel

ポリシー全体に影響するコントロール。

監査ポリシーは、複数の NAC ネットワーク アクセス プロファイルで使用できます。ポリシーを削除する前に、削除の影響を受ける NAC ネットワーク アクセス プロファイルを確認する必要があります。