Cisco Clean Access (NAC アプライアンス) Manager インストレーション アドミニストレーション ガイド Release 4.1(1)
CAA 要件の設定
CAA 要件の設定
発行日;2012/01/11 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 7MB) | フィードバック

目次

CAA 要件の設定

概要

CAA 要件の設定手順

CAA 要件の作成

Windows Update 要件の設定

Windows Update 要件の作成

Windows 規則への Windows Update 要件のマップ

Windows Server Update Services 要件の設定

Windows Server Update Service 要件の作成

Windows 規則への Windows Server Update Service 要件のマップ

AV および AS Definition Update 要件の設定

AV 規則および AS 規則

AV/AS サポート情報の確認

AV 規則の作成

AV Definition Update 要件の作成

AS 規則の作成

AS Definition Update 要件の作成

Launch Programs 要件の設定

カスタム チェック、規則、および要件の設定

カスタム要件

シスコの規則

シスコの設定済み規則(「pr_」)

カスタム チェック

シスコの設定済みチェック(「pc_」)

CSA をチェックするための設定済み規則の使用

チェックおよび規則のコピー

設定の概要

カスタム チェックの作成

カスタム規則の作成

規則の検証

カスタム 要件の作成

規則への要件のマップ

ロールへの要件の適用

要件の検証

Optional および Audit 要件の設定

Launch Programs の例

CAA レポートの表示

レポート数の制限

CAA ユーザ ダイアログ

Windows Agent ダイアログ

Mac OS X Agent のダイアログ(認証のみ)

RADIUS のチャレンジ/レスポンス方式 Agent ダイアログ

Windows RADIUS チャレンジ/レスポンス方式ユーザ ログイン セッション ダイアログの例

Mac OS X RADIUS チャレンジ/レスポンス方式ユーザ ログイン セッション ダイアログの例

Agent のローカライズされた言語テンプレート

Agent のトラブルシューティング

クライアントが接続およびログインできない

Agent がポップアップしない、ログインがディセーブル

クライアントが接続できない(トラフィック ポリシー関連の問題)

AV/AS 規則のトラブルシューティング

Windows Script 5.6 の既知の問題

MS Update Scanning Tool の既知の問題(KB873333)

対処法

CAA 要件の設定

この章では、クライアント マシンの脆弱性評価および復旧に使用する Clean Access Agent(CAA)を設定する方法について説明します。

「概要」

「CAA 要件の設定手順」

「CAA 要件の作成」

「CAA レポートの表示」

「CAA ユーザ ダイアログ」

「Agent のトラブルシューティング」

概要

CAA には、クライアント マシンに対して、ローカルマシン エージェントベースの脆弱性評価および復旧を行う機能があります。ユーザは CAA(読み取り専用クライアント ソフトウェア)をダウンロードおよびインストールして、ホストのレジストリ、プロセス、アプリケーション、およびサービスをチェックすることができます。CAA を使用すると、Windows アップデートまたは AV(アンチウイルス)や AS(アンチスパイウェア)の定義のアップデートを実行したり、正規の復旧プログラムを起動したり、Clean Access Manager(CAM)にアップロードされたファイルを配布したり、ユーザがファイルをダウンロードしてシステムを修復できるように Web サイト リンクを Web サイトに配布したり、情報や手順を配布することができます。

CAA は、ユーザがログインすると、ユーザ ロールまたは OS に設定された要件を Clean Access Server(CAS)から取得し、要求されたパッケージを検索し、レポートを(CAS を介して)CAM に送信します。クライアントに関する要件が満たされている場合、ユーザはネットワークにアクセスできます。要件が満たされていない場合、Agent は要件ごとに、ユーザにダイアログを表示します。このダイアログ(New Requirement フォームで設定)には、クライアント マシンを要件に適合させる手順および対処法が表示されます。

CAA の脆弱性評価を CAM に設定するには、規則およびチェック(任意)に基づいて要件を作成してから、ユーザ ロールまたはクライアント OS に適用します。この章では、これらの要件の設定方法について説明します。


) 概要については、を参照してください。


CAA 要件の設定手順

CAA 設定するために必要な基本手順は、次のとおりです。


ステップ 1 第 10 章「CAA の配布」 の手順に従って、CAA の配布とダウンロードをイネーブルにします。

ステップ 2 「CAA 要件の作成」

「Windows Update 要件の設定」

「AV および AS Definition Update 要件の設定」

「Launch Programs 要件の設定」

「カスタム チェック、規則、および要件の設定」

ステップ 3 「規則への要件のマップ」

ステップ 4 「ロールへの要件の適用」

ステップ 5 「要件の検証」

ステップ 6 「Optional および Audit 要件の設定」

ステップ 7 「CAA ユーザ ダイアログ」

ステップ 8 「Agent のトラブルシューティング」


 

CAA 要件の作成

CAA システムの要件を実装するには、次の要素を同時に設定して対応付けます。

要件

規則(AV/AS 規則、pr_ rule、またはカスタム規則)

チェック(pc_ check またはカスタム チェック) ― カスタム規則を作成する場合にのみ必要

ユーザ ロールおよびオペレーティング システム

要件は、ネットワーク アクセスを実現するためにユーザがシステムで実行しなければならない(あるいは、実行してはならない)機能について、ビジネスレベルの判断を行う場合に使用されます。要件のメカニズムは、ユーザ ロールでクライアントが満たさなければならない 1 つまたは複数の規則に、クライアントが違反した場合のユーザの対処法をマップします。New Requirement を作成する場合、いくつかの異なる要件タイプから 1 つ(たとえば、AV Definition Update)を選択し、クライアントが要件に違反した場合に、ユーザに表示する CAA ダイアログのオプションと対処法の説明を設定します。

規則は、特定の OS で要件が満たされているかどうかを評価するために CAA で使用される単位です。規則には AV/AS 規則、シスコの設定済み規則(pr_rule)、または特定のチェックや一連のチェックで構成されるカスタム規則があります。規則を要件にマップする必要があります。

チェックは選択された OS に対応する単一のレジストリ、ファイル、サービス、またはアプリケーション チェックです。カスタム ファイルを作成する場合に使用されます。チェックには、シスコの設定済みチェック(pc_ check)または自分で作成するカスタム チェックがあります。

要件を規則に関連付けたら、最後の設定手順として、標準ログイン ユーザ ロールに要件を関連付けます。標準ユーザ ロールへの認証を試行するユーザは、標準ログイン ロールに対応する要件にパスするまで、Temporary ロールに配置されます。

この要件に正常に適合したユーザは、標準ログイン ロールでのネットワーク作業が許可されます。

要件に違反したユーザは、Agent ダイアログに記載された手順を実行して、要件に正常に適合しないかぎり、Temporary ロールのままでセッションをタイムアウトします。

アウトオブバンド ユーザの場合は、要件の認証および適合に成功すると、インバンド ネットワーク(認証 VLAN 上)を離れて、アクセス VLAN 上のアウトオブバンド ネットワークにアクセスできます。

要件を標準ログイン ユーザ ロールにマップするには、「ユーザ ロールの作成」の説明に従って、ロールを作成しておく必要があります。

Windows Update 要件の設定

CAA の [Windows Update] 要件タイプの設定ページを使用すると、管理者は Windows Update 設定をチェックおよび変更したり、CAA ユーザ マシンの Windows Updater(Automatic Updates またはローカル Windows Server Update Services [WSUS] の WSUS Agent)を起動したりできます。

この要件が設定されている場合、このオプションがマシンでディセーブルに設定されている Windows Vista、Windows 2000、または Windows XP クライアントの Automatic Updates をオンにできます。Automatic Updates がすでにユーザ マシン上でイネーブルの場合、管理者はユーザ指定のアップデート オプションに管理者指定のオプションを上書きできます。さらに、管理者指定の Windows Update 設定を一時的にユーザ マシンに適用したり、アップデートが常に実行されるようにユーザ プリファレンスを常時上書きするように設定できます。

[Windows Update] 要件(Optional に設定済み)は、復旧用に CAA に Update ボタンを用意しています。エンド ユーザが Update ボタンをクリックすると、CCA Agent は AU/WSUS Agent を起動して、WSUS サーバからアップデート ソフトウェアを取得するように強制します。WSUS からのソフトウェア ダウンロードには、時間がかかる場合があります。WSUS 復旧用の Optional(デフォルト)の Windows Update 要件の設定をバックグラウンド プロセスで行うことを推奨します。

標準の Windows アップデートとは別に、特定の WSUS アップデートの要件を設定することもできます。詳細については、「Windows Server Update Services 要件の設定」を参照してください。


) • ネットワーク管理者は、自動起動を作動させるローカル WSUS サーバをサポートするために、Automatic Updates Agent が更新されていることを確認する必要があります。詳細については、次の URL を参照してください。

http://www.microsoft.com/windowsserversystem/updateservices/evaluation/faqs.mspx

Windows Update 要件タイプは、Windows Vista、Windows XP、および Windows 2000 に限定されます。Automatic Updates(AU)Options のチェック、AU Options の変更、および AU/WSUS Agent のワンタッチ Update 起動をサポートしています。

Agent は、次の方法で WindowsUpdater を起動します。

Automatic Updates/WSUS Agent を起動するワンタッチ Update

ローカル WSUS サーバからのアップデートの強制(Automatically Download と Install が選択されている場合)

デフォルトで Windows Update 要件が任意に設定されています。

WSUS によって強制されたアップデートは、時間がかかる場合があります。このアップデートは、バックグラウンドで起動し実行されます。

アップデート エラーがある場合は、C:\Windows\Windows Update.log または C:\Windows\WindowsUpdate.log を参照してください。

Windows Server Update Services 操作をサポートするには、クライアント マシンに WUAUENG.dll ファイルのバージョン 5.4.3790.1000(またはより最新のバージョン)がインストールされている必要があります。


 

Windows Update 要件を作成する手順は、次のとおりです。


ステップ 1 「Windows Update 要件の作成」

ステップ 2 「Windows 規則への Windows Update 要件のマップ」

ステップ 3 「ロールへの要件の適用」

ステップ 4 「要件の検証」


 

Windows Update 要件の作成

Windows Update 要件を設定する手順は、次のとおりです。

1. Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement に移動します。

図11-1 新規の Windows Update 要件

 

2. Requirement Type ドロップダウン メニューから、 Windows Update を選択します。

3. ドロップダウン メニューで Enforce Type を選択します。

Mandatory ― 要件を強制します。ユーザにはこの要件が通知され、クライアント システムが要件を満たさないかぎりユーザは次に進んだり、ネットワークにアクセスすることはできません。

Optional ― 要件を強制しません。ユーザには要件が通知されますが、必要に応じて [Next] をクリックし、無視できます。クライアント システムが要件を満たさなくても、ユーザは次に進んだり、ネットワークにアクセスすることができます。

Audit ― サイレント監査。ユーザに通知せずにクライアント システムの要件がサイレントにチェックされ、レポートが生成されます。レポートの結果(成功または失敗)は、ユーザのネットワーク アクセスに影響しません。


) Windows Update プロセスはバックグラウンドで実行されるため、この要件タイプはデフォルトで [do not enforce] に設定され、ユーザ操作が最適化されます。[Automatically download and install option] を選択する場合は、この要件を Optional のままにしておくことを推奨します。WSUS によって強制されたアップデートは時間がかかる場合があり、このアップデートはバックグラウンドで起動されて、実行されます。


4. クライアントでこの要件を実行する Priority を選択します。ハイ プライオリティ(たとえば、1)の場合、他のすべての要件よりこの要件が優先されてシステムでチェックされ、その順序で Agent ダイアログに表示されることを意味します。Mandatory 要件が失敗する場合、その要件が成功するまで Agent は次に進みません。

5. Windows Update Setting ドロップダウンから、次のいずれかのオプションを選択します。

Do not change setting

Notify to download and install

Automatically download and notify to install

Automatically download and install

これらの設定内容は、Windows クライアント(図11-2)の Automatic Updates ダイアログ設定に対応します。

6. Windows Update の実行中または実行後にすべてのクライアント マシンの Automatic Updates に対する管理者指定の設定を強制する場合は、 Permanently override user setting with administrator Windows Update Setting チェックボックスをオンにします。チェックボックスをオンにしない場合、Automatic Updates がクライアントでディセーブルの場合にのみ admin 設定が適用されます。それ以外の場合、Automatic Updates がイネーブルの場合にユーザ設定が適用されます。

7. Requirement Name に、Agent 内でこの要件を識別する一意の名前を入力します。この名前は、CAA ダイアログに表示されます。

8. Description フィールドに、要件の説明のほか、要件を満たさなかったユーザを誘導する方法(ユーザが Update ボタンをクリックして、システムを更新する方法も含む)を入力します。 Windows Update では Agent に Update ボタンが表示されます。

9. 次の 1 つまたは複数のチェックボックスをオンにして、要件の Operating System を設定します。

Windows 2000

Windows XP (All) または 1 つまたは複数の特定の Windows XP オペレーティング システム

Windows Vista (All) または 1 つまたは複数の特定の Windows Vista オペレーティング システム

10. Add Requirement をクリックします。

図11-2 Windows XP の Automatic Updates

 

Windows 規則への Windows Update 要件のマップ

1. Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules の順番に進みます。

図11-3 規則への Windows Update 要件のマッピング

 

 

2. Requirement Name ドロップダウン メニューから、設定した Windows Update 要件を選択します。

3. Operating System ドロップダウン メニューから、 Windows Vista Windows XP 、または Windows 2000 を選択します。1 つの OS の要件/規則のマッピングを設定したら、他の OS の設定を選択したり、適宜にマッピングを更新したりできます。

4. Requirement met if: の次のいずれかのオプションを選択します。

All selected rules succeed (デフォルト)

Any selected rule succeeds

No selected rule succeeds

5. AV Virus/AS Spyware Definition 規則のオプションを無視します。

6. Rules for Selected Operating System リストは、選択した OS(pr_ rule または設定した規則)のシステム内に存在するすべての規則を表示します。この要件でイネーブルにする各規則のチェックボックスをオンにします。この要件に関連付けられている典型的な規則は、次のとおりです。

pr_AutoUpdateCheck_Rule (Win XP (All), 2000)

pr_XP_Hotfixes (Win XP Pro/Home)

pr_2K_Hotfixes (Win 2000)

Device Management > Clean Access > Clean Access Agent > Rules > Rule List の順番に進むとすべての規則が表示されます。

7. Update をクリックして、マッピングを完了します。

8. 「ロールへの要件の適用」および「要件の検証」に進んで、設定を完了します。

Windows Server Update Services 要件の設定

CAA の [Windows Server Update Services] 要件タイプの設定ページを使用すると、管理者は CAA ユーザ マシンで Windows Server Update Service(WSUS)を起動できます。

シスコの設定済みホットフィックス規則ではなく、WSUS 重大度チェックを使用できます。Automatic Updates がすでにユーザ マシン上でイネーブルの場合、管理者はユーザ指定のアップデート オプションに管理者指定のオプションを上書きできます。さらに、管理者指定の Windows Update 設定を一時的にユーザ マシンに適用したり、アップデートが常に実行されるようにユーザ プリファレンスを常時上書きするように設定できます。

[Windows Server Update Services] 要件は、復旧用に CAA に Update ボタンを用意しています。エンド ユーザが Update ボタンをクリックすると、CCA Agent は AU/WSUS Agent を起動して、Microsoft 管理またはローカル/サードパーティ管理の WSUS サーバからアップデート ソフトウェアを取得するように強制します。WSUS からのソフトウェア ダウンロードには、時間がかかる場合があります。WSUS 復旧用の Optional(デフォルト)の Windows Update 要件の設定をバックグラウンド プロセスで行うことを推奨します。

特定の WSUS アップデートとは別に、標準の Windows Update の要件を設定することもできます。詳細については、「Windows Update 要件の設定」を参照してください。


) • ネットワーク管理者は、自動起動機能をサポートするローカル WSUS サーバをサポートするために、Automatic Updates Agent が更新されていることを確認する必要があります。詳細については、次の URL を参照してください。

http://www.microsoft.com/windowsserversystem/updateservices/evaluation/faqs.mspx

[Windows Server Update Services] 要件タイプも、Windows 2000、Windows XP、および Windows Vista に限定されます。シスコベースおよび Windows ベースのクライアント オペレーティング システム検証およびアップデートの重要度によるカスタマイズされたアップデート インストレーション オプションのチェックをサポートしています。

Windows Server Update Services 操作をサポートするには、クライアント マシンに WUAUENG.dll ファイルのバージョン 5.4.3790.1000(またはより最新のバージョン)がインストールされている必要があります。

一部の Microsoft Windows コンポーネント(たとえば、Internet Explorer 7)では、アップデートを正常に行うために admin 権限が必要になります。ユーザがクライアント マシンに admin 権限を持たない場合は、Windows アップデート プロセスが「WU_E_NO_INTERACTIVE_USER」エラーを戻します。そのため、admin 権限を必要とする Windows アップデートを [Optional] にして、アップデートの失敗を最小限に抑えることを推奨します。詳細については、次の URL を参照してください。

http://msdn2.microsoft.com/en-us/library/aa387289.aspx

WSUS によって強制されたアップデートは、時間がかかる場合があります。このアップデートは、バックグラウンドで起動されて、実行されます。

アップデート エラーが発生した場合は、C:\Windows\Windows Update.log または C:\Windows\WindowsUpdate.log を参照してください。


 

Windows Server Update Service 要件を作成する手順は、次のとおりです。


ステップ 1 「Windows Server Update Service 要件の作成」

ステップ 2 「Windows 規則への Windows Server Update Service 要件のマップ」

ステップ 3 「ロールへの要件の適用」

ステップ 4 「要件の検証」


 

Windows Server Update Service 要件の作成

WSUS 要件を設定する手順は、次のとおりです。

1. Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement に移動します。

図11-4 新規の Windows Server Update Service 要件

 

2. Requirement Type ドロップダウン メニューから、 Windows Server Update Services を選択します。

3. ドロップダウン メニューで Enforce Type を選択します。

Mandatory ― 要件を強制します。ユーザにはこの要件が伝えられ、クライアント システムが要件を満たさないかぎりユーザは次に進んだり、ネットワークにアクセスすることはできません。

Optional ― 要件を強制しません。ユーザには要件が伝えられますが、必要に応じて [Next] をクリックし、無視できます。クライアント システムが要件を満たさなくても、ユーザは次に進んだり、ネットワークにアクセスすることができます。

Audit ― サイレント監査。ユーザに通知せずにクライアント システムの要件がサイレントにチェックされ、レポートが生成されます。レポートの結果(成功または失敗)は、ユーザのネットワーク アクセスに影響しません。


) Windows Update プロセスはバックグラウンドで実行されるため、この要件タイプはデフォルトで [do not enforce] に設定され、ユーザ操作が最適化されます。[Automatically download and install option] を選択する場合は、この要件を Optional のままにしておくことを推奨します。WSUS によって強制されたアップデートは時間がかかる場合があり、このアップデートはバックグラウンドで起動されて、実行されます。


4. クライアントでこの要件を実行する Priority を選択します。ハイ プライオリティ(たとえば、1)の場合、他のすべての要件よりこの要件が優先されてシステムでチェックされ、その順序で Agent ダイアログに表示されることを意味します。Mandatory 要件が失敗する場合、その要件が成功するまで Agent は次に進みません。

5. Windows Updates Validation by で、Cisco Clean Access がクライアント マシンで実行されている Windows オペレーティング システムを検証する方法を指定します。

Cisco Rules ― シスコのプリセットの検証基準を使用して、クライアント上の Windows オペレーティング システムが標準の最小セキュリティ ガイドラインを満たすようにします。


) このオプションを選択する場合、「Windows 規則への Windows Update 要件のマップ」の記述のように、既存の Windows 規則にも要件をマップする必要があります。


Severity ― ローカル(管理)またはホスト(Microsoft)Windows 検証サーバを使用して、クライアント上の Windows オペレーティング システムが標準の最小セキュリティ ガイドラインを満たすようにします。


) その下にある Windows Updates Installation Sources 設定で、Severity オプションに一致する検証方法を設定します。


6. Windows Updates to be Installed で、Cisco Clean Access が Windows アップデートを開始する方法を指定します。

Express ― このオプションは、Windows Update アプリケーションの [Express] オプションから入手できる Windows アップデートをインストールします(たとえば、Windows の [Express] オプションは、Critical および Important セキュリティ アップデートだけが含まれる場合と、すべてのサービス パックのアップデートのインストールを要求する場合があります)。

Custom ― この設定と関連するドロップダウン メニューを使用し、関連するドロップダウン メニューから Critical、Medium、または All を選択して、重要度に基づいてアップデートをインストールします。Critical を選択すると、最も重要な Windows アップデートがインストールされます。Medium を選択することは、すべてのアップデート(Microsoft で [low severity] として分類されている場合は除く)がインストールされることを意味します。All を選択することは、重要度に関係なく、現在入手可能なすべての Windows Update がインストールされることを意味します。

7. Upgrade to Latest OS Service Pack をクリックして、ユーザのオペレーティング システムから入手できる最新のサービス パックを自動的にインストールします。


) このオプションは、上部の Medium または All Custom アップデートを指定する場合に自動的にインストール プロセスに含まれます。「省略」することはできません。Critical Custom アップデートを指定した場合、このオプションをイネーブルまたはディセーブルに選択することはできません。

シスコの規則はすべての [Critical] Windows アップデートを強制し、最小の
Windows 2000 Service Pack および Windows XP Service Pack アップデートがクライアント マシンにインストールされているかどうかを確認します。[Critical] Windows Updates to be Installed だけが必要でそのように選択する場合、Windows 2000 Service Pack 4 および Windows XP Service Pack 2 がクライアント マシンに表示されない場合があります。そのため、クライアント マシンは、[Cisco rules] 経由でポスチャ評価を渡しません。[Cisco rules] を使用してクライアント マシンを検証し、[Critical] アップデートのみが必要な場合、この問題に対処するには、Service Pack Updates も要求し、[Cisco rules] のポスチャ評価を使用してクライアントを検証することを推奨します([Cisco rules] ではなく、[Severity] でクライアント マシンを検証するように選択した場合、これは問題にはなりません)。



) 通常、Windows Service Pack アップデートのダウンロードとインストールには時間がかかります。フル サービス パックのインストレーションで Windows オペレーティング システムを更新するようにユーザに要求する前に、Temporary Role ユーザのセッション タイムアウト時間を延長して、インストールとアップデートの長いプロセス時間を調整します( Temporary ロールのセッション タイムアウトの設定を参照)。


8. Windows Updates Installation Sources で、Windows アップデートのソースを指定します。

Windows Servers ― Microsoft 管理のリソースを使用して、Windows オペレーティング システムを更新します。

Managed WSUS Servers ― Windows サーバ管理者またはその他の信頼できるサードパーティ ソースによって管理されているリソースを使用して、Windows オペレーティング システムを更新します。

9. Installation Wizard Interface Setting で、Windows Update のインストール中にユーザに Installation Wizard ユーザ インターフェイスを表示するかどうかを指定します。

Show UI ― Installation Wizard の経過表示が更新プロセス中にユーザに表示されるので、ユーザは更新されているコンポーネントの内容とアップデートが完了した時間を知ることができます(Windows Update 中に Installation Wizard ユーザ インターフェイスを表示するには、ユーザはクライアント マシン上に管理者権限を持っている必要があります)。

No UI ― アップデート プロセスが開始すると、Windows Update がバックグラウンドで行われ、アップデートが完了した場合にだけユーザに通知されます。

10. Requirement Name に、Agent 内でこの要件を識別する一意の名前を入力します。この名前は、CAA ダイアログに表示されます。

11. Description フィールドに、要件の説明のほか、要件を満たさなかったユーザを誘導する方法(ユーザが Update ボタンをクリックして、システムを更新する方法を含む)を入力します。 Windows Update では Agent に Update ボタンが表示されます。

12. 次の 1 つまたは複数のチェックボックスをオンにして、要件の Operating System を設定します。

Windows 2000

Windows XP (All) または 1 つまたは複数の特定の Windows XP オペレーティング システム

Windows Vista (All) または 1 つまたは複数の特定の Windows Vista オペレーティング システム

13. Add Requirement をクリックします。

Windows 規則への Windows Server Update Service 要件のマップ

Cisco Rules で Windows Updates Validation by の Windows Server Update Service 要件を設定した場合は、このセクションの手順を実行します(Windows Server Update Service 要件の作成を参照)。

Severity で Windows Updates Validation by を指定した場合、Windows Server Update Service を既存の Windows Rule にマップする必要はないため、このセクションを省略できます。

Windows 規則に Windows Server Update Service 要件をマップする手順:

1. Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules に移動します。

図11-5 規則への Windows Update 要件の対応付け

 

2. Requirement Name ドロップダウン メニューから、設定した WSUS 要件を選択します。

3. Operating System ドロップダウン メニューから、選択可能な Windows Vista、Windows XP、または Windows 2000 オペレーティング システムのオプションから 1 つを選択します。1 つの OS の要件と規則のマッピングを設定したら、他の OS の設定を選択したり、適宜にマッピングを更新したりできます。

4. Requirement met if: の次のいずれかのオプションを選択します。

All selected rules succeed (デフォルト)

Any selected rule succeeds

No selected rule succeeds

5. AV Virus/AS Spyware Definition 規則のオプションを無視します。

6. Rules for Selected Operating System リストは、選択した OS(pr_ rule または設定した規則)のシステム内に存在するすべての規則を表示します。この要件でイネーブルにする各規則のチェックボックスをオンにします。この要件に関連付けられている一般的な規則は、次のとおりです。

pr_AutoUpdateCheck_Rule (Win XP [All], 2000)

pr_XP_Hotfixes (Win XP Pro/Home)

pr_2K_Hotfixes (Win 2000)

すべての規則が Device Management > Clean Access > Clean Access Agent > Rules > Rule List に表示されます。

7. Update をクリックして、マッピングを完了します。

「ロールへの要件の適用」および「要件の検証」に進んで、設定を完了します。

AV および AS Definition Update 要件の設定

AV Definition Update および AS Definition Update 要件タイプは、クライアント上にあるサポート対象 AV/AS 製品の定義ファイルの更新に使用できます。クライアントが AV/AS 要件に違反した場合、CAA はクライアントにインストールされた AV/AS ソフトウェアと直接通信します。ユーザが Agent ダイアログ の Update ボタンをクリックすると、定義ファイルは自動的に更新されます。

AV 規則には AV ベンダーに関するロジックが多数組み込まれていて、AV Definition Update 要件が対応付けられています。AS 規則にはほとんどの AS ベンダーに関するロジックが組み込まれていて、AS Definition Update 要件が対応付けられています。AV または AS Definition Update 要件の場合、チェックを設定する必要はありません。次のように対応付けます。

AV Definition Update 要件と AV 規則およびユーザ ロールや OS

AS Definition Update 要件と AS 規則およびユーザ ロールや OS

さらに、AV/AS 要件に違反した場合にユーザに表示する Clean Access Agent ダイアログの説明を設定します。


) 可能であれば、クライアントの AV ソフトウェアをチェックする場合に、AV Definition Update 要件に対応付けられた AV 規則を使用することを推奨します。サポート対象外の AV 製品の場合、または AV 規則を介して AV 製品/バージョンを使用できない場合、管理者は常に AV ベンダーに関するシスコ提供の pc_ checks および pr_rules を使用したり、Device Management > Clean Access > Clean Access Agent を通して(New Check、New Rule、および New File/Link/Local Check Requirement を使用して)独自のカスタム チェック、規則、および要件を作成することができます(カスタム チェック、規則、および要件の設定を参照)。
Clean Access は AV ベンダーがサポートするインストール方式およびメカニズムと連係して機能します。AV ベンダーが AV 製品の基本メカニズム突然変更した場合、Clean Access チームはできるだけ早く Supported AV/AS Product List または CAA をアップグレードして、新しい AV 製品の変更をサポートします。その間に、管理者は目的の AV 製品に「カスタム」規則(pc_checks/pr_ 規則など)を使用して対処し、「Any selected rule succeeds」の要件を設定することができます。


図11-6 に、クライアントが AV Definition Update 要件に違反した場合に表示される CAA ダイアログを示します。

図11-6 必要な AV Definition Update(ユーザ ダイアログ)

 

AV 規則および AS 規則

AV 規則および AS 規則は、Supported AV/AS Product List 内のベンダーおよび製品のリストに対応付けられた設定済みの規則タイプです。このタイプの規則を含むチェックを設定する必要はありません。

AV 規則には 2 つの基本タイプがあります。

Installation AV Rules ― 選択された AV ソフトウェアがクライアント OS に対応するようにインストールされているかどうかを調べます。

Virus Definition AV Rules ― クライアントのウイルス定義ファイルが最新であるかどうかを調べます。Virus Definition AV Rules を AV Definition Update 要件に対応付けると、要件に違反したユーザが Agent の Update ボタンをクリックして、更新を自動実行できるようになります。

AS 規則には 2 つの基本タイプがあります。

Installation AS Rules ― 選択された AS ソフトウェアがクライアント OS に対応するようにインストールされているかどうかを調べます。

Spyware Definition AS Rules ― クライアントの AS 定義ファイルが最新であるかどうかを調べます。Spyware Definition AS Rules を AS Definition Update 要件に対応付けると、要件に違反したユーザが Agent の Update ボタンをクリックして、更新を自動実行できるようになります。

通常、 AV Rules AV Definition Update 要件に、 AS Rules AS Definition Update 要件に対応付けられます。

AV Definition Update 要件を作成する手順は、次のとおりです。


ステップ 1 「AV/AS サポート情報の確認」

ステップ 2 「AV 規則の作成」

ステップ 3 「AV Definition Update 要件の作成」

ステップ 4 「規則への要件のマップ」

ステップ 5 「ロールへの要件の適用」

ステップ 6 「要件の検証」


 

AS Definition Update 要件を作成する手順は、次のとおりです。


ステップ 1 「AV/AS サポート情報の確認」

ステップ 2 「AS 規則の作成」

ステップ 3 「AS Definition Update 要件の作成」

ステップ 4 「規則への要件のマップ」

ステップ 5 「ロールへの要件の適用」

ステップ 6 「要件の検証」


 


) AV または AS 規則/要件を別の方法で設定する方が便利な場合があります。次の例を参考にしてください。

特定のベンダーの一部の製品バージョンでは、Agent による製品の自動更新をサポートしていない場合があります。この場合は、インストールされた AV/AS 製品のインターフェイスを通して、AV/AS 定義ファイルを更新するようにユーザに指示する説明を設定できます(AV または AS Definition Update 要件の Description フィールドを使用)。

AV または AS 規則に別の要件タイプ(Link Distribution や Local Check など)を対応付けて、Agent ボタンおよびユーザの対処法を「Update」から「Go to Link」に変更したり、アクション ボタンをディセーブルにして説明のみを表示することができます。この方法により、ユーザが実行するアクションを柔軟に設定できます。

異なる Enforce Type も設定できます。クライアント向けのレポートを生成したり、ユーザが要件を満たす期間を延長し、その期間はユーザがネットワークからブロックされないようにできます。詳細は、「Optional および Audit 要件の設定」を参照してください。


 

AV/AS サポート情報の確認

Cisco NAC Appliance を使用すると、複数のバージョンの CAA をネットワークで使用できます。Agent に新しいアップデートを適用すると、リリース時点での最新の AV/AS 製品のサポートが追加されます。最適な方法(Def Date または Def Version)が選択され、入手可能な AV/AS 製品および Agent のバージョンに基づいて AV/AS 定義チェックを実行します。 AV/AS Support Info ページには、CAM にダウンロードされた最新の Supported AV/AS Product List と Agent の互換性が詳細に表示されています。また、AV/AS 製品ごとの定義ファイルの最新バージョンや日付、および製品サポートに必要な Agent のベースライン バージョンが表示されています。クライアントの AV/AS 情報と、 AV/AS Support Info ページを比較して、クライアントの定義ファイルが最新であるかを確認できます。ネットワークで複数のバージョンの Agent が稼働している場合、このページを使用すると、特定の製品をサポートするため実行しなければならないバージョンを判別することができます。

Agent サポートの詳細の表示手順:

1. Device Management > Clean Access > Clean Access Agent > Rules > AV/AS Support Info に移動します。

2. Category ドロップダウン メニューで Antivirus図11-7)または Anti-Spyware図11-8)を選択します。

図11-7 AV/AS Support Info -- AV ベンダーの例

 

図11-8 AV/AS Support Info -- AS ベンダーの例

 

3. ドロップダウン メニューで、対応するベンダー( Antivirus Vendor または Anti-Spyware Vendor )を選択します。

4. AS 製品の場合、サポートされているのは Windows Vista/XP/2K オペレーティング システムのみです。製品の詳細については、 Minimum Agent Version Required to Support AS Products テーブルで確認してください。


) AS 定義の日付/バージョンの定期更新は、Cisco Updates から実行できます。更新サービスが使用可能になるまで、システムは定義ファイルを AS Spyware Definition 規則(Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules)の現在のシステム日付よりも x 日間古い日付に設定します。


5. AV 製品の場合は、 Operating System ドロップダウン メニューで Windows Vista/XP/2K または Windows 9x/ME を選択して、クライアント システムのサポート情報を表示します。この操作を行うと、次のテーブルにデータが読み込まれます。

Minimum Agent Version Required to Support AV Products は、各 AV 製品のサポートに必要な最小の Agent バージョンを表示します。たとえば、4.1.1.0 Agent は Aluria Security Center AntiVirus 1.x を必要とするロールにログインすることはできますが、これよりも前の Agent バージョンの場合は、このチェックが失敗します。特定のバージョンの Agent が Def Date と Def Version の両方のチェックをサポートする場合、Def Version チェックが使用されます。

Latest Virus Definition Version/Date for Selected Vendor は、AV 製品の最新バージョンと日付の情報を表示します。最新クライアントの AV ソフトウェアに、同じ値が表示されます。


) Agent はバージョン情報を CAM に送信します。CAM が最初に AV チェックに使用するのは、常にウイルス定義のバージョンです。バージョンを使用できない場合、CAM はウイルス定義の日付を使用します。



ヒント New AV Rule フォームで AV ベンダーを選択した場合も、最新の定義ファイル バージョンを表示できます。


AV 規則の作成

1. 最新バージョンの Supported AV/AS Product List が存在することを確認してください(を参照)。

2. Device Management > Clean Access > Clean Access Agent > Rules > New AV Rule に移動します。

図11-9 New AV Rule

 

3. Rule Name を入力します。名前内には数字および下線を使用できますが、スペースは使用できません。

4. ドロップダウン メニューで Antivirus Vendor を選択します。この操作を行うと、ページ下部にある Checks for Selected Operating Systems テーブルに、(選択された Operating System に対応する)このベンダーのサポート対象製品および製品情報が読み込まれます。

5. Type ドロップダウン メニューで、 Installation または Virus Definition を選択します。このようにすると、下部のテーブル内の、対応する Installation または Virus Definition カラムのチェックボックスがイネーブルになります。

6. ドロップダウン メニューで、 Operating System (Windows Vista/XP/2K または Windows ME/98)を選択します。下部のテーブルに、このクライアント OS でサポートされている製品バージョンが表示されます。

7. オプションの Rule Description に入力します。

8. Checks for Selected Operating Systems テーブルで、対応する Installation または Virus Definition カラム内のチェックボックスをクリックして、クライアント上で検索する製品バージョンを選択します。ANY をクリックすると、この AV ベンダーのすべての製品およびバージョンが検索されます。 Installation は製品がインストールされているかどうかを調べます。 Virus Definition は、指定された製品のウイルス定義ファイルが、クライアント上で最新かどうかを調べます。

9. Add Rule をクリックします。新しい AV 規則が Rule List の下部に、指定した名前で追加されます。

AV Definition Update 要件の作成

次の手順は、対応する AV 規則を使用して特定の AV 製品およびバージョンのクライアント システムを検索する、新しい AV Definition Update 要件を作成する方法を示します。クライアントの AV 定義ファイルが最新でない場合、ユーザは CAA の Update ボタンをクリックして、Agent 独自の更新メカニズムを既存の AV ソフトウェアによって起動することができます。実際のメカニズムは、AV 製品ごとに異なります(ライブ アップデートやコマンド ライン パラメータなど)。

1. Clean Access Agent タブで、 Requirements サブメニュー リンクをクリックしてから、 New Requirement を選択します。

図11-10 New Requirement

 

2. Requirement Type で、 AV Definition Update を選択します。

3. ドロップダウン メニューで Enforce Type を選択します。

Mandatory ― 要件を強制します。ユーザにはこの要件が伝えられ、クライアント システムが要件を満たさないかぎりユーザは次に進んだり、ネットワークにアクセスすることはできません。

Optional ― 要件を強制しません。ユーザには要件が伝えられますが、必要に応じて [Next] をクリックし、無視できます。クライアント システムが要件を満たさなくても、ユーザは次に進んだり、ネットワークにアクセスすることができます。

Audit ― サイレント監査。ユーザに通知せずにクライアント システムの要件がサイレントにチェックされ、レポートが生成されます。レポートの結果(成功または失敗)は、ユーザのネットワーク アクセスに影響しません。

4. クライアントでこの要件を実行する Priority を選択します。ハイ プライオリティ(たとえば、1)の場合、他のすべての要件よりこの要件が優先されてシステムでチェックされ、その順序で Agent ダイアログに表示されることを意味します。Mandatory 要件が失敗する場合、その要件が成功するまで Agent は次に進みません。

5. ドロップダウン メニューで Antivirus Product Name を選択するか、 ANY を選択します。 Products テーブルに、クライアント OS ごとにサポートされているウイルス定義製品のバージョンがすべて表示されます。

6. Requirement Name に、Agent 内でこの AV ウイルス定義ファイル要件を識別する一意の名前を入力します。この名前は、CAA ダイアログに表示されます。

7. Description フィールドに、要件の説明、および要件に違反したユーザの指針となる手順を入力します。AV Definition Update 要件の場合は、 Update ボタンをクリックしてシステムを更新するようにユーザに指示する説明を追加する必要があります。次の点に注意してください。

AV Definition Update では Agent に Update ボタンが表示されます。

AS Definition Update では Agent に Update ボタンが表示されます。

Windows Update では Agent に Update ボタンが表示されます。

8. 少なくとも 1 つのクライアント Operating System に対応するチェックボックスをクリックします(少なくとも 1 つをオンにする必要があります)。

9. Add Requirement をクリックして、Requirement List に要件を追加します。

AS 規則の作成

1. 最新バージョンの Supported AV/AS Product List が存在することを確認してください(を参照)。

2. Device Management > Clean Access > Clean Access Agent > Rules > New AS Rule に移動します。

図11-11 New AS Rule

 

3. Rule Name を入力します。名前内には数字および下線を使用できますが、スペースは使用できません。

4. ドロップダウン メニューで Anti Spyware Vendor を選択するか、または ANY を選択して、サポートされている AS ベンダーまたは製品をすべて選択します。この操作を行うと、ページ下部にある Checks for Selected Operating Systems テーブルに、(選択された Operating System に対応する)このベンダーのサポート対象製品および製品情報が読み込まれます。

5. Type ドロップダウン メニューで、 Installation または Spyware Definition を選択します。このようにすると、その下のテーブル内の、対応する Installation または Spyware Definition カラムのチェックボックスがイネーブルになります。

6. Operating System フィールドには、デフォルトで Windows Vista/XP/2K が表示されます。

7. オプションの Rule Description に入力します。

8. Checks for Selected Operating Systems テーブルで、対応する Installation または Spyware Definition カラム内のチェックボックスをクリックして、クライアント上で検索する製品バージョンを選択します。ANY をクリックすると、この AS ベンダーのすべての製品およびバージョンが検索されます。 Installation は製品がインストールされているかどうかを調べます。 Spyware Definition は指定された製品のスパイウェア定義ファイルが、クライアント上で最新かどうかを調べます。

9. Add Rule をクリックします。新しい AS 規則が Rule List の下部に、指定した名前で追加されます。

AS Definition Update 要件の作成

1. Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement に移動します。

図11-12 新しい AS Definition Update 要件

 

2. Requirement Type で、 AS Definition Update を選択します。

3. ドロップダウン メニューで Enforce Type を選択します。

Mandatory ― 要件を強制します。

Optional ― 要件を強制しません。

Audit ― サイレント監査。

4. クライアントでこの要件を実行する Priority を選択します。

5. ドロップダウン メニューで Anti-Spyware Vendor Name を選択するか、 ANY を選択します。 Products テーブルに、クライアント OS ごとに現在サポートされているスパイウェア定義製品のバージョンがすべて表示されます。

6. Requirement Name に、Agent 内でこの AS 定義ファイル要件を識別する一意の名前を入力します。この名前は、CAA ダイアログに表示されます。

7. Description フィールドに、要件の説明、および要件に違反したユーザの指針となる手順を入力します。AS Definition Update 要件の場合は、 Update ボタンをクリックしてシステムを更新するようにユーザに指示する説明を追加する必要があります。次の点に注意してください。

File Distribution では Agent に Download ボタンが表示されます。

Link Distribution では Agent に Go To Link ボタンが表示されます。

Local Check では Agent に Download ボタン(ディセーブル)が表示されます。

AV Definition Update では Agent に Update ボタンが表示されます。

AS Definition Update では Agent に Update ボタンが表示されます。

Windows Update では Agent に Update ボタンが表示されます。

8. 少なくとも 1 つのクライアント Operating System に対応するチェックボックスをクリックします(少なくとも 1 つをオンにする必要があります)。

9. Add Requirement をクリックして、Requirement List に要件を追加します。

Launch Programs 要件の設定

Cisco Clean Access には、 Launch Programs 要件タイプがあります。この要件タイプでは、管理者は CAA から認定された復旧プログラムを起動できます。管理者はチェックと規則の条件を作成できます。失敗した場合、管理者はマシンを修正するための復旧プログラムを起動するように設定できます。複数のプログラムが許可されており、管理者が指定した順序で起動します。

CAA は、装置のユーザ権限に基づいて 2 つの方法でプログラムを起動します。

ユーザがクライアント マシンに admin 権限を持たない場合は、直接プログラムが起動するので、アプリケーションのデジタル署名と検証が必要ありません。

ユーザが管理権限を持たない場合、Clean Access スタブをインストールして、ターゲットの実行ファイルを起動する必要があります。この場合、Clean Access スタブは、プログラムを起動する前に信頼できる認証局によってプログラムが署名されていることを確認します。

プログラムに必要な Registry Key が Cisco CAA および Cisco Clean Access スタブで信頼されるように読み込むのは、管理者の責任です。


) この機能を使用するには、CAA のバージョン 4.1.0.0 以降が必要です。この機能は、Windows Vista、Windows 2000、および Windows XP マシンにのみ適用されます。


1. Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement に移動します。

図11-13 新規の Launch Program 要件

 

2. Requirement Type で、 Launch Programs を選択します。

3. ドロップダウン メニューで Enforce Type を選択します。

Mandatory ― 要件を強制します。ユーザにはこの要件が伝えられ、クライアント システムが要件を満たさないかぎりユーザは次に進んだり、ネットワークにアクセスすることはできません。

Optional ― 要件を強制しません。ユーザには要件が伝えられますが、必要に応じて [Next] をクリックし、無視できます。クライアント システムが要件を満たさなくても、ユーザは次に進んだり、ネットワークにアクセスすることができます。

Audit ― サイレント監査。ユーザに通知せずにクライアント システムの要件がサイレントにチェックされ、レポートが生成されます。レポートの結果(成功または失敗)は、ユーザのネットワーク アクセスに影響しません。

4. クライアントでこの要件を実行する Priority を選択します。ハイ プライオリティ(たとえば、1)の場合、他のすべての要件よりこの要件が優先されてシステムでチェックされ、その順序で Agent ダイアログに表示されることを意味します。Mandatory 要件が失敗する場合、その要件が成功するまで Agent は次に進みません。

5. 次のように起動するようにプログラムを設定します。

Program Name で、プログラムを起動するルート ロケーション( SYSTEM_DRIVE
SYSTEM_ROOT
SYSTEM_32 SYSTEM_PROGRAMS 、または None )をドロップダウンから選択し、隣接しているテキスト フィールドにプログラム実行ファイルの名前を入力します。

さらに特定のパスまたはプログラムのパラメータが必要な場合は、 Program Parameters テキスト フィールドに入力します。

Add Program をクリックします。これにより、 Program Name Program Parameters がプログラムのサブリストに追加され、要件で起動されます。

さらに追加するプログラムを設定するか、 Delete チェックボックスをオンにして、リストからプログラムを削除します。

6. 追加するプログラムまたはプログラム リストの設定が終了したら、 Requirement Name を入力します。

7. ユーザに表示する Description を入力します。

8. この要件が適用される Windows の Operating System のチェックボックスをオンにします。

9. Add Requirement をクリックします。


) 詳細は、「Launch Programs の例」を参照してください。


カスタム チェック、規則、および要件の設定

チェックは、クライアント システムを調べる場合に使用する条件ステートメントです。最も単純な場合、1 つの要件は、1 つのチェックで構成される 1 つの規則になります。条件ステートメントの結果が true の場合、システムは CAA 要件に適合し、対処が不要であるとみなされます。

チェックを作成するには、まず要件の識別機能を検索します。この機能(レジストリ キーやプロセス名など)によって、クライアントが要件を満たしているかどうかが示されなければなりません。このようなインジケータを見つけるために、要件を満たしているシステムを調べることを推奨します。必要に応じて、ソフトウェア付属のマニュアルを参照して、Clean Access チェックに使用する識別機能を判別します。要件に使用するインジケータを判別したら、次の手順を使用して、チェックを作成します。

カスタム要件

カスタム要件を作成すると、ユーザが規則条件を満たすためのメカニズムに規則を対応付けることができます。このメカニズムには、インストール ファイル、外部リソースへのリンク、単なる命令などがあります。規則チェックが満たされない場合(たとえば、必要なソフトウェアがクライアント システム上に 見つからない 場合)は、設定に応じて、ユーザに警告を表示したり、システムを修復するようにユーザに要求することができます。図11-14 に示すように、ブール演算子、「&」(and)、「|」(or)、および「!」(not)を使用して、1 つの規則内で複数のチェックを連結できます。1 つの要件に複数の規則を使用する場合は、クライアントが要件に適合しているとみなすための条件を、「選択されたいずれかの規則を満たす」、「すべての規則を満たす」、「どの規則も満たさない」の中から指定することができます。

図11-14 カスタム チェック、規則、および要件

 

シスコの規則

規則は、1 つ以上のチェックで構成される条件ステートメントです。1 つの規則内で複数のチェックを論理演算子で連結し、クライアント システムの複数の機能をテストできる ブール ステートメントを形成することができます。

シスコの設定済み規則(「pr_」)

Cisco NAC Appliance は、CAM Web コンソールの Updates ページ( Device Management > Clean Access > Updates )経由で CAM にダウンロードされる設定済み規則とチェックのセットを提供します。

設定済みの規則には名前に [pr] のプレフィクスがあり(pr_XP_Hotfixes など)、テンプレートとして使用する場合にコピーできますが、編集したり、削除することはできません。[pr_lick] 規則の Edit ボタンをクリックして、その規則を定義する規則式を参照できます。設定済みの規則の規則式は、設定済みのチェック(たとえば、[pc_Hotfix835732])およびブール演算子で構成されます。設定済み規則の規則式は、Cisco Updates から更新されます。たとえば、Windows XP、pr_XP_Hotfixes 規則用にリリースされている新規の Critical Windows OS ホットフィックスは、対応するホットフィックス チェックで更新されます。

設定済みの規則は、 Device Management > Clean Access > Clean Access Agent > Rules > Rule List に表示されます。


) シスコの設定済み規則は、Critical Windows OS ホットフィックスのみに対してサポートを提供することを目的としています。


カスタム チェック

チェックは、ファイル、レジストリ キー、サービス、アプリケーションなど、クライアント システムの機能を調べる条件ステートメントです。 表11-1 に、使用可能なカスタム チェックのタイプとテストの内容について表示します。

 

表11-1 チェック

チェックのカテゴリ
チェック タイプ

レジストリ チェック

レジストリ キーの有無

レジストリ キー値

ファイル チェック

ファイルの有無

変更日または作成日

ファイル バージョン

サービス チェック

稼働しているサービスの有無

アプリケーション チェック

稼働しているアプリケーションの有無

シスコの設定済みチェック(「pc_」)

設定済みのチェックには名前に [pc] のプレフィクスがあり(pc_Hotfix828035 など)、 Device Management > Clean Access > Clean Access Agent > Rules > Check List に表示されます。

CSA をチェックするための設定済み規則の使用

シスコの設定済み規則を使用して、Cisco Security Agent(CSA)がクライアント(Cisco Updates 規則セットのバージョン 14663 以降)にすでにインストールされ、実行されているかどうかをチェックする CAA 要件を作成できます。次の内容を実行します。

1. 新規の Link Distribution または File Distribution 要件を作成します(Windows Vista/XP/2000 の場合)。

2. 次の規則のいずれか、または両方に要件を関連付けます(Windows Vista/XP/2000 の場合)。

pr_CSA_Agent_Version_5_0

pr_CSA_Agent_Service_Running

3. 適用するユーザ ロールに要件を関連付けます。


) 設定済みまたはカスタム規則を使用して、カスタム要件を作成するための詳細については、次のセクションを参照してください。


チェックおよび規則のコピー

設定済みの規則およびチェックは編集できませんが、テンプレートとして使用できます。編集不可能なチェックまたは規則を変更するには、対応する Copy ボタンをクリックして、まずコピーを作成します。チェックのコピーを Check List の下部に copy_of_ checkname 形式で追加します。規則のコピーを Rules List の下部に、copy_of_ rulename の形式で追加します。対応する Edit ボタンをクリックして、Edit フォームを起動し、チェックまたは規則を変更します。編集されたチェックおよび規則は、以下の説明に従って、設定したり、要件や規則に対応付けることができます。

設定の概要

カスタム要件の作成手順は、次のとおりです。


ステップ 1 「カスタム チェックの作成」

ステップ 2 「カスタム規則の作成」

ステップ 3 「規則の検証」

ステップ 4 「カスタム 要件の作成」

ステップ 5 「規則への要件のマップ」

ステップ 6 「ロールへの要件の適用」

ステップ 7 「要件の検証」


 

カスタム チェックの作成

1. Clean Access Agent タブで、 Rules サブメニューをクリックし、 New Check フォームを開きます。

図11-15 New Check

 

すべてのカスタム チェックに対して、ステップ 2. 7. に従います。 レジストリ チェック タイプ ファイル チェック タイプ サービス チェック タイプ 、または アプリケーション チェック タイプ で各チェック タイプの仕様を参照してから、ステップ c を実行します。

2. Check Category (Registry Check、File Check、Service Check、または Application Check)を選択します。

3. Check Name にわかりやすい名前を入力します。このチェックから作成された規則はチェックをこの名前で参照するため、チェックにはわかりやすい一意の名前を付けてください。名前は大文字と小文字を区別します。スペースや特殊文字を含まない 255 文字以下の文字列を指定する必要があります。

4. オプションの Check Description に入力します。

5. 次の 1 つまたは複数のチェックボックスをオンにして、要件の Operating System を設定します。

Windows All

Windows 2000

Windows ME

Windows 98

Windows XP (All) または 1 つまたは複数の特定の Windows XP オペレーティング システム

Windows Vista (All) または 1 つまたは複数の特定の Windows Vista オペレーティング システム

6. 必要に応じて、「 Automatically create rule based on this check 」を選択します。この場合、追加されたチェックがこの規則に自動的に読み込まれ、「checkname-rule」と名前が付けられます。

7. Category に対応する Check Type を選択し、次のように特定のフォーム フィールドに入力します。パラメータ、演算子、および(チェック タイプが値比較の場合)ステートメントの値およびデータ タイプを指定し、 Add Check をクリックして評価ステートメントを作成します。条件ステートメントが False に評価された場合は、必要なソフトウェアが存在しないとみなされています。

レジストリ チェック タイプ

Registry Key ― レジストリ内に特定のキーが存在するかどうかを調べます。

Registry Value (Default) ― 名前のない(デフォルト)レジストリ キーが存在するか、または特定の値、バージョン、または変更日が設定されているかを調べます。

Registry Value ― 名前付きのレジストリ キーが存在するか、または特定の値、バージョン、または変更日が設定されているかを調べます。

図11-16 レジストリ チェック タイプ

 

a. Registry Key フィールドで、クライアント レジストリのエリアを選択します。

HKLM ― HKEY_LOCAL_MACHINE

HKCC ― HKEY_CURRENT_CONFIG

HKCU ― HKEY_CURRENT_USER

HKU ― HKEY_USERS

HKCR ― HKEY_CLASSES_ROOT

検索するパスを入力します。

例:HKLM \SOFTWARE\Symantec\Norton AntiVirus\version

b. 特定の Registry Value を検索する場合は、 Value Name を入力します。

c. 複数の Registry Value を検索する場合は、 Value Data Type を入力します。

1. [Number] Value Data Type 注: REG_DWORD は Number と同等)で、ドロップダウンから Operators (equals[等しい]、greater than[より大きい]、less than[未満]、does not equal[等しくない]、greater than or equal to[以上]、less than or equal to[以下])の 1 つを選択します。

2. [String] Value Data Type で、ドロップダウンから Operators (equals[等しい]、equals (ignore case)[等しい、大文字と小文字を区別しない]、does not equal[等しくない]、starts with[で始まる]、does not start with[で始まらない]、ends with[で終わる]、does not end with[で終わらない]、contains[を含む]、does not contain[を含まない])の 1 つを選択します。

3. [Version] Value Data Type で、ドロップダウンから Operators (earlier than[より前]、later than[より後]、same as[に等しい])の 1 つを選択します。

4. [Date] Value Data Type で、ドロップダウンから Operators (earlier than[より前]、later than[より後]、same as[に等しい])の 1 つを選択します。

d. [Date] Value Data Type を指定する場合は、2 つの値のいずれかも選択して、チェックを行います。これにより、現在の日付より x 日多いまたは少ない単位として [older than] または [newer than] を指定することができます。

- mm/dd/yyyy hh:MM:ss 形式でクライアント マシンの日付を入力します。

- ドロップダウンから CAM date + 、または - を選択して、日数を入力します。

e. Registry Value を検索する場合は、 Value Data を入力します。


) [String] Value Data Type では、ストリングの最大の長さは、256 文字です。


ファイル チェック タイプ

File Existence ― システムにファイルが存在するかどうかを調べます。

File Date ― 特定の変更日または作成日を持つファイルがシステムに存在するかどうかを調べます。

File Version ― 特定のバージョンのファイルがシステムに存在するかどうかを調べます。

図11-17 ファイル チェック タイプ

 

a. File Path で、次のように選択します。

SYSTEM_DRIVE ― C:\ ドライブを検索します。

SYSTEM_ROOT ― Windows 98 システムのルート パスを検索します。

SYSTEM_32 ― C:\WINDOWS\SYSTEM32 を検索します。

SYSTEM_PROGRAMS ― C:\Program Files を検索します。

b. Operator で、次のように選択します。

exists または does not exist ― File Existence チェック

earlier than , later than , same as ― File Date または File Version チェック

c. File Date チェック タイプでは、次の 2 つの値のいずれかも選択して、 File Date をチェックします。これにより、現在の日付より x 日多いまたは少ない単位として [older than] または [newer than] を指定することができます。

- mm/dd/yyyy hh:MM:ss 形式でクライアント マシンの日付を入力します。または、

- ドロップダウンから CAM date + 、または - を選択して、日数を入力します。

d. File Date チェック タイプでは、 File Date Type を選択します。

Creation date

Modification date

サービス チェック タイプ

Service Status ― システムで現在稼働しているサービスがあるかどうか

図11-18 サービス チェック タイプ

 

a. Service Name を入力します。

b. Operator running または not running )を選択します。

アプリケーション チェック タイプ

Application Status ― システムで現在稼働しているアプリケーションがあるかどうか

図11-19 アプリケーション チェック タイプ

 

a. Application Name を入力します。

b. Operator running または not running )を選択します。

c. 終了したら Add Check をクリックします。

カスタム規則の作成

規則は複数のチェックおよび演算子で構成された式です。特定の OS の脆弱性を評価するための単位として、CAA で使用されます。規則式の結果によって、CAA 要件との適合性が評価されます。1 つの規則を 1 つのチェックで構成したり、複数のチェックをブール演算子で連結することができます。 表11-2 に演算子およびその評価順を示します。

 

表11-2 規則の演算子

プライオリティ
演算子
説明

1

()

評価プライオリティ用のカッコ

2

!

not

3

&

and

3

|

or

プライオリティが等しい演算子は、左から右に評価されます。たとえば、規則は次のように定義できます。

adawareLogRecent & (NorAVProcessIsActive | SymAVProcessIsActive)
 

規則を満たすためには、adawareLogRecent チェック、および NorAVProcessIsActive チェックと SymAVProcessIsActive チェックのいずれかを満たす必要があります。カッコがない場合は、次の式と同じになります。

(adawareLogRecent & NorAVProcessIsActive) | SymAVProcessIsActive
 

この場合、規則を満たすためには、SymAVProcessIsActive、または最初の 2 つのチェックの両方が True である必要があります。

カスタム規則の作成

1. Clean Access Agent タブで、 Rules サブメニュー リンクをクリックしてから、 New Rule をクリックします。

図11-20 New Rule

 

2. Rule Name に一意の規則名を入力します。

3. Rule Description に入力します。

4. 規則を適用する Operating System を選択します。アップデートをダウンロードした場合、この OS に対応する設定済みチェックが、下部の Checks for Selected Operating System リストに表示されます。

5. チェックおよび演算子を連結して、 Rule Expression を作成します。リストを使用してチェックの名前を選択し、 Rule Expression テキスト フィールドにコピー アンド ペーストします。チェックが複数ある場合は、()(評価プライオリティ)、!(not)、&(and)、 | (or)の演算子を使用します。

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

adawareLogRecent & (NorAVProcessIsActive | SymAVProcessIsActive)
 

1 つのチェックをテストする単純な規則の場合は、チェック名を入力します。

SymAVProcessIsActive
 

6. Add Rule をクリックします。

コンソールによって規則が検証され、形式が正しい場合は、 Rule List に表示されます。このリストから、規則を削除、変更、またはコピーする(規則をコピーして新しい規則を作成する)ことができます。

規則の検証

CAM は作成された規則および要件を自動的に検証します。規則が無効な場合(特に、ターゲット OS に関連する規則が無効な場合)は、チェックと規則の間に互換性がありません。これらのエラーは、特定の OS に対応するチェックおよび規則を複数作成したあとで、特定のチェックに対応する OS プロパティを変更した場合に発生することがあります。この場合は、このチェックを使用する規則、および以前に設定した OS に引き続き適用可能な規則は、無効になります。規則を検証すると、このようなエラーや、その他のエラーが検出されます。

Device Management > Clean Access > Clean Access Agent > Rules > Rule List Validity カラムでは、規則が有効の場合はブルーのチェックマーク、規則が無効の場合はレッドの [X] が表示されます。マウスでこのアイコンを強調表示して、このフォームでどのチェックが規則を無効にしているかを確認してください。

Invalid rule [rulename], Invalid check [checkname] in rule expression.

図11-21 規則リスト

 

無効な規則の訂正手順:

1. Device Management > Clean Access > Clean Access Agent > Rules > Rule List に移動します。

2. 無効な規則に対応する Edit ボタンをクリックします。

3. 無効な Rule Expression を訂正します。チェックが削除されたために規則が無効になった場合は、有効なチェックに規則を対応付けます。

4. 正しい Operating System が選択されているか確認します。

5. Requirement met if: 式が正しく設定されていることを確認します。

6. Save Rule をクリックします。

7. この規則に基づくすべての要件が、「要件の検証」の説明に従って、訂正されているかを確認します。

カスタム 要件の作成

要件は、OS に指定された一連の規則を、CAA ダイアログを介してユーザにプッシュされるファイル、配信リンク、または説明に対応付けるメカニズムです。要件では、インストール ファイル、またはソフトウェアをダウンロードできるリンクを指定できます。ローカル チェックが特定のインストール ファイルに対応付けられていない場合、要件は規則を情報メッセージ(たとえば、ソフトウェアを削除したり、ウイルス チェックを実行するようにユーザに指示するメッセージ)に対応付けることができます。新しい要件は、設定プロセス中にいつでも作成できます。ただし、要件を有効にするには、OS の規則およびユーザ ロールの両方に要件を対応付けておく必要があります。

File Distribution /Link Distribution / Local Check 要件の作成

1. Clean Access Agent タブで、 Requirements サブメニュー リンクをクリックしてから、 New Requirement を選択します。

図11-22 New Requirement(File Distribution)

 

2. Requirement Type を選択します。

File Distribution ― CAA によるユーザ ダウンロードでインストール パッケージを使用できるようにして、必要なソフトウェアを直接配布します。この場合、ユーザがダウンロードするファイルは、 File to Upload フィールドを使用して CAM に格納されます。Agent でこのファイルをダウンロードする場合、HTTP アクセスを CAM にのみ許可するトラフィック ポリシーを Temporary ロール用に作成する必要があります。「デフォルト ロールのトラフィック ポリシーの追加」を参照してください。

Link Distribution ― ソフトウェアが使用可能な別の Web ページ(ソフトウェア ダウンロード ページなど)にユーザを転送します。リンクへの HTTP(および HTTPS の両方またはいずれか一方)はアクセスを許可するように Temporary ロールが設定されているか確認します。

Local Check ― インストール可能なソフトウェアに対応付けられていないチェックを作成して、Windows Update Service [Automatic Updates] がイネーブルであるかどうかの確認や、システムに存在してはならないソフトウェアの検索などを実行する場合に使用します。

AV Definition Update ― AV 規則を作成する場合に使用します。詳細は、「AV および AS Definition Update 要件の設定」を参照してください。

AS Definition Update ― AS 規則を作成する場合に使用します。詳細は、「AV および AS Definition Update 要件の設定」を参照してください。

Windows Update ― クライアントの Windows Update オプションの設定に使用します。詳細は、「Windows Update 要件の設定」を参照してください。

Launch Programs ― 要件に違反した場合に、クライアントの復旧プログラムを起動する場合に使用します。詳細は、「Launch Programs 要件の設定」を参照してください。

3. ドロップダウン メニューで Enforce Type を選択します。

Mandatory ― 要件を強制します。

Optional ― 要件を強制しません。「Optional および Audit 要件の設定」を参照してください。

Audit ― サイレント監査。

4. 要件の Priority を指定します。値が最小(「1」など)の要件のプライオリティが最大になり、最初に実行されます。要件に失敗した場合、この要件に設定された対処法の説明がユーザにプッシュされ、その他の要件はテストされません。したがって、失敗する可能性が最も高い要件のプライオリティを最大にすることによって、処理時間を最短にすることができます。

5. Version フィールドでは、さまざまなバージョンの要件を追跡できます。これは特に、必要なソフトウェアに対するアップデートが複数存在する場合に便利です。番号(1、2、3)、小数(1.0)、または文字など、必要な任意のバージョン設定方式を使用できます。

6. Requirement Type として File Distribution を選択した場合は、 File to Upload フィールドの横にある Browse をクリックして、必要なソフトウェアのインストール ファイル(.exe)が格納されたフォルダに移動します。

7. Requirement Type として Link Distribution を選択した場合は、 File Link URL フィールドに、インストール ファイルまたはパッチ ファイルを取得できる Web ページの URL を入力します。

8. Requirement Name に、システム要件を識別する一意の名前を入力します。この名前は、CAA ダイアログに表示されます。

9. Description フィールドに、要件の説明、およびユーザに役立つ手順を入力します。次の点に注意してください。

File Distribution では Agent に Download ボタンが表示されます。

Link Distribution では Agent に Go To Link ボタンが表示されます。

Local Check では Agent に Download ボタン(ディセーブル)が表示されます。

AV Definition Update では Agent に Update ボタンが表示されます。

AS Definition Update では Agent に Update ボタンが表示されます。

Windows Update では Agent に Update ボタンが表示されます。

Launch Programs では Agent に Launch ボタンが表示されます。

10. 要件を適用する Operating System を選択します(少なくとも 1 つ選択する必要があります)。

11. Add Requirement をクリックして、ダウンロード要件の設定を保存します。

12. Requirement List に要件が表示されます。

図11-23 に、CAA の要件設定フィールドの表示例を示します。

図11-23 オプションの Link Distribution 要件の例

 

規則への要件のマップ

要件を作成し、対処法へのリンクおよび手順を指定したら、特定の規則または一連の規則に要件をマップします。要件と規則のマッピングは、クライアント システムが要件を満たすかどうかを調べる規則セットと、クライアント システムを適合させるために必要なユーザ対処法(Agent ボタン、手順、リンク)をマップします。

1. Clean Access Agent タブで、 Requirements サブメニューをクリックしてから、 Requirement-Rules フォームを開きます。

図11-24 要件と規則のマッピング

 

2. Requirement Name メニューで、マップする要件を選択します。

3. Operating System メニューで、要件に対応した OS を確認します。 Rules for Selected Operating System リストに、選択された OS で使用可能なすべての規則が読み込まれます。

4. AV Virus Definition 規則(背景がイエロー)および AS Spyware Definition 規則(背景がブルー)の場合は、クライアントの定義ファイルの日付が、CAM が Updates から入手可能なものよりも数日間古い日付になるように、CAM を設定することができます(最新の製品ファイル日付については、 Rules > AV-AS Support Info を参照)。このように設定すると、新しいウイルス/スパイウェア定義ファイルが製品ベンダーからリリースされない場合も、クライアントが要件をパスできるように、要件の柔軟性を高めることができます。

次のいずれかのチェックボックスをクリックします。

For AV Virus Definition rules, allow definition file to be x days older than:

For AS Spyware Definition rules, allow definition file to be x days older than:

テキスト ボックスに数値を入力します。デフォルトは「 0 」です。この場合、定義日をファイル/システム日付よりも古い日付に設定できません。

次のいずれかを選択します。

Latest file date ― クライアント定義ファイルを、CAMの最新のウイルス/スパイウェア定義日よりも指定日数だけ古い日付にすることができます。

Current system date ― クライアント定義ファイルを、最後に Update が実行された時点の CAM のシステム日よりも指定日数だけ古い日付にすることができます。


) AS Spyware Definition 規則の場合、Cisco Update サービスを使用してスパイウェア定義ファイルの日付/バージョンを定期的に更新するまで、この機能は適用されます(定義ファイルを現在のシステム日付よりも X 日間古くすることができます)。

特定の要件にこの機能を設定した場合、Agent は AV/AS 製品の定義日を検索してから、日付がこの要件を満たすかどうかを検証します。Agent が定義日を検出できない場合(この製品で定義日の検出がサポートされていない場合など)、この機能は無視され、Agent はクライアントに最新の定義バージョンがあるかどうかを調べます。


5. ページをスクロールダウンして、要件に対応付ける各規則の横にある Select チェックボックスをオンにします。規則はプライオリティ順に適用されます( 表11-2 を参照)。

図11-25 要件にマップする規則の選択

 

6. Requirements met if で、次のいずれかのオプションを選択します。

All selected rules succeed ― クライアントが要件に適合しているとみなすための条件が、すべての規則を満たすことである場合

Any selected rule succeeds ― クライアントが要件に適合しているとみなすための条件が、選択した規則を 1 つ以上満たすことである場合

No selected rule succeeds ― クライアントが要件に適合しているとみなすための条件が、選択した規則をすべて満たさないことである場合

クライアントが要件に適合しない場合は、要件に対応付けられたソフトウェアをインストールするか、または指示された手順を実行する必要があります。

7. Update をクリックします。

ロールへの要件の適用

要件を作成し、対処法を設定し、規則を対応付けたら、要件をユーザ ロールに対応付ける必要があります。この最終手順では、システム内のユーザ グループに要件を適用します。


) 標準ログイン ユーザ ロールが作成されていることを確認してください( ユーザ ロールの作成を参照)。


1. Clean Access Agent タブで、 Role-Requirements サブメニュー リンクをクリックします。

図11-26 ロールと要件のマッピング

 

 

2. Role Type メニューで、設定するロールのタイプを選択します。通常は、 Normal Login Role を選択します。

3. User Role メニューで、ロールの名前を選択します。

4. ロール内でユーザに適用する各要件に対応した Select チェックボックスをクリックします。

5. Update をクリックします。

6. 終了する前に、ロール内のユーザが CAA を使用する必要があるか確認してください。「CAA 要件の作成」を参照してください。

要件の検証

CAM は作成された要件および規則を自動的に検証します。 Device Management > Clean Access > Clean Access Agent > Requirements > Requirement List Validity カラムは、規則が有効の場合はブルーのチェックマーク、規則が無効の場合はレッドの [X] を表示します。マウスでこのアイコンを強調表示して、このフォームでどの規則とチェックが要件を無効にしているかを確認してください。

Invalid rule [rulename] in package [requirementname] (Rule verification error: Invalid check [checkname] in rule expression)
 

要件を訂正、検証してから、使用する必要があります。一般的に、オペレーティング システムが一致しない場合に要件/規則が無効になります。

無効な要件の訂正手順:

1. Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules に移動します。

2. 無効な規則またはチェックを訂正します(規則の検証を参照)。

3. ドロップダウン メニューで無効な Requirement Name を選択します。

4. Operating System を選択します。

5. Requirement met if: 式が正しく設定されていることを確認します。

6. 要件に対して選択された規則が有効であること(Validity カラム内にブルーのチェックマークが付いていること)を確認します。

図11-27 要件リスト

 

Optional および Audit 要件の設定

New Requirement または Edit Requirement フォームの Enforce Type ドロップダウン メニューだけを使用して、 Mandatory Optional 、または Audit 要件を作成できます。オプション要件を使用すると、この要件に違反した場合に、ネットワークからクライアントをブロックしなくても、CAA ユーザの管理レポートを表示することができます。オプション要件に違反したユーザは Temporary ロールに配置され、Agent ダイアログの要件名の前に [Optional] が付加されます。ただし、この場合も、 Next をクリックして、次の要件に進むか、その他の要件が設定されていない場合はネットワーク作業を継続できます。

ユーザが要件を満たす期間を延長し、その期間はネットワークからユーザがブロックされないようにする場合は、特定の日付で要件を満たすように指示する命令をオプション要件に設定します。あとで、指定された日に要件を適用して、要件を必須にすることができます。

ユーザに通知せずにクライアント システムの要件をサイレントにチェックし、レポートを生成するには、ユーザのネットワーク アクセスに影響せずに、結果(成功または失敗)だけを報告する監査のみの要件を設定できます。

Optional および Audit 要件の作成手順:

1. Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement に移動します。

図11-28 Optional および Audit 要件

 

2. ドロップダウン メニューで Requirement Type を選択します。

3. Enforce Type ドロップダウン メニューから Optional (強制なし)または Audit (サイレント評価)を選択します。

Optional 要件では、ユーザには要件が伝えられますが、必要に応じて [Next] をクリックし、無視できます。クライアント システムが要件を満たさなくても、ユーザは次に進んだり、ネットワークにアクセスすることができます。 Audit 要件では、システムは監査レポートを生成しますが、クライアント マシンにユーザ ダイアログが表示されず、ユーザのネットワーク アクセスは影響されません。

4. クライアントでこの要件を実行する Priority を選択します。ハイ プライオリティ(たとえば、1)の場合、他のすべての要件よりこの要件が優先されてシステムでチェックされ、その順序で Agent ダイアログに表示されることを意味します。Mandatory 要件が失敗する場合、その要件が成功するまで Agent は次に進みません。

5. 要件タイプに対応する各フィールドを設定します。

6. Requirement Name にオプション要件の名前を入力します。

7. Description フィールドに説明を入力し、この要件がオプション要件であること、および Agent ダイアログの Next ボタンをクリックしてネットワーク作業を継続できることをユーザに通知します。次の点に注意してください。

File Distribution では Agent に Download ボタンが表示されます。

Link Distribution では Agent に Go To Link ボタンが表示されます。

Local Check では Agent に Download ボタン(ディセーブル)が表示されます。

AV Definition Update では Agent に Update ボタンが表示されます。

AS Definition Update では Agent に Update ボタンが表示されます。

8. Operating System で、該当するチェックボックスをクリックします。

9. Add Requirement をクリックします。

必須要件と同じ方法で、オプション要件を規則およびロールに対応付ける必要があります。設定を完了する手順については、以下を参照してください。

「規則への要件のマップ」

「ロールへの要件の適用」

図11-29 オプション要件の Agent ダイアログ

 

Launch Programs の例

次に、Launch Programs を使用して、認定された(署名付き)プログラムを起動する例を示します。CA 権限を使用してプログラムに署名する場合は、この例にある専用アプリケーションの署名の実行方法に関連する手順を省略できます。

ユーザがクライアント マシンに admin 権限を持っている場合、実行可能なすべてのプログラムを使用できます。

ユーザが admin 権限を持っていない場合、Agent Stub からターゲットの実行ファイルを起動します。実行ファイルには、次の内容が含まれています。

1. 特定のフィールド値を使用した証明書によって署名された有効なデジタル署名

2. (任意)特定の項目値を使用したファイルのバージョン情報

証明書の値およびファイルのバージョン情報は、レジストリで設定することもできます。

コードまたはプログラム署名はプログラムにデジタル署名を添付するプロセスなので、起動時に「信頼できるもの」としてみなすことができます。NAC Appliance が署名されたプログラムを起動する場合、「Launcher」は実行する前に署名が信頼できるソースからのものであること(すなわち、CA 証明書が信頼できるストアにあるかどうか)を確認します。署名がないアプリケーションを起動することはセキュリティ上危険なので、アプリケーションの署名が必要です。誰もが起動しようとしているプログラムにトロイの木馬やウイルスを仕掛けて、危害を加えることができるためです。

Thawte および Verisign の Certificate Authority(CA; 認証局)は、署名サービスを提供しています。

独自にプログラムに署名する場合、次の内容が必要です。

CA サーバ(公開または秘密)

CA サーバによって発行された証明書

秘密鍵、CA サーバの公開鍵(上記の証明書用)

署名が必要な .exe、.dll、.scr、.wsh

署名ツール(signcode.exe/signtool.exe など)


) 用例およびツール

http://www.pantaray.com/signcode.html

http://www.cryptguard.com/documentation_resources_tools.shtml


 

要件の追加


ステップ 1 Launch Programs タイプの New Requirement を作成します。

ステップ 2 Optional、Mandatory、または Audit の中から Requirement を選びます。

ステップ 3 認定されたプログラムを起動するルート ロケーションを指定します。

System_Root = C:\Windows

System_32 = C:\Windows\System32

System_Programs = C:\Program Files

図11-30 ルート ロケーションの選択

 

ステップ 4 より詳細なパスとプログラム パラメータを追加できます。

図11-31 プログラム パラメータの指定

 

ステップ 5 Add Program をクリックして、Program Name リストにプログラムを追加します。

図11-32 プログラムの追加

 

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


 

アプリケーション署名の設定


ステップ 1 .exe ファイルの署名に使用される証明書と秘密鍵を取得します。Private CA(たとえば、MS CA サーバ)または Public CA(Verisign/Thawte など)から取得できます。その他のファイルは必要なツールです。

図11-33 証明書の取得

 

ステップ 2 cert2spc.exe ツールを使用して、SPC ファイル(別名 Software Publishing Certificate)を作成します。

C:\inetsdk\test>cert2spc prem1.cer prem1.spc
Succeeded
 

ステップ 3 これにより、次のような prem1.spc ファイルが作成されます。

図11-34 SPC の作成

 

ステップ 4 signcode.exe を実行します。

C:\inetsdk\test>signcode

図11-35 signcode. exe の実行

 

ステップ 5 署名が必要な .EXE を参照して、選択します(この例では、tftpd.exe)。

図11-36 署名する実行ファイルの選択

 

ステップ 6 [Custom] オプションを選択します。

図11-37 Custom オプションの選択

 

ステップ 7 [Select from File] をクリックして、作成した prem1.spc ファイルを選択します。

図11-38 SPC ファイルの選択

 

ステップ 8 [Browse] をクリックして、秘密鍵の prem1.pvk ファイルを選択します。

図11-39 秘密鍵の参照

 

ステップ 9 秘密鍵の使用に必要なパスワードがある場合は、パスワードを入力します。

図11-40 秘密鍵へのパスワードの入力

 

ステップ 10 署名に使用するハッシュ アルゴリズムを選択します。

図11-41 ハッシュ アルゴリズムの選択

 

ステップ 11 次のように画面に表示されるデフォルト値をそのまま使用します。

図11-42 デフォルト値の使用

 

ステップ 12 Finish をクリックします。

図11-43 Finish のクリック

 

ステップ 13 再び秘密鍵のプロンプトが表示される場合は、再入力します。次のメッセージが表示されます。

図11-44 秘密鍵の再入力(必要な場合)

 

ステップ 14 ファイルを右クリックし、[Properties] を選択して、EXE が署名されていることを確認します。デジタル署名のタブと Certificate CN 名で確認します。

図11-45 署名された実行ファイルの確認

 

ステップ 15 次に、NAC Appliance のカスタム チェックと規則を作成して、TFTPD32.exe アプリケーションが実行されているかどうかをチェックします。

図11-46 チェックの作成

 

ステップ 16 最後に、この規則を使用する要件を次のように作成します。

図11-47 要件の作成

 


 

署名されたプログラムの起動(ユーザ ビュー)


ステップ 1 Agent にログインします。NAC Appliance は TFTPD32.exe が実行されていないことを検出します。ユーザは隔離され、復旧することが求められます。

ステップ 2 Launch をクリックすると、TFTPD32.exe が起動します。

ステップ 3 Next をクリックして、ネットワークにログインします。

図11-48 署名されたプログラムの起動(ユーザ ビュー)

 


 

CAA レポートの表示

CAA の Reports ページ( Device Management > Clean Access > Clean Access Agent > Reports > Report List )には、CAA のアクティビティに関する詳細が表示されます。この情報にはユーザ アクセスの試行回数、およびシステム チェック結果が含まれます。

背景がオレンジの Report List エントリは、システム チェックに失敗したクライアントを示します。

Reports ページを使用すると、管理者は CAA レポートの記録と検索を実行して、情報収集を進めることができます。Reports ページには、次のオプション内容を表示するための検索基準を拡張する [Advanced/Simple] トグル オプションがあります。

AV/AS Software:
AV/AS Software ドロップダウン メニューを使用すると、次の場合のクライアント レポートを検索および表示できます。

AntiVirus Software Installed

AntiSpyware Software Installed

Unknown AV/AS Software Installed

Requirement および Success/Failure:
Requirement ドロップダウンは、システムに設定されているすべての CAA 要件を表示します。Success/Failure ドロップダウン オプションを使用すると、選択した要件の成功または失敗したクライアント レポートを検索および表示できます。

Simple または拡張した Advanced 検索オプションを選択したあとに Show ボタンをクリックすると、基準に一致するすべてのエントリの概要と各クライアントの詳細な管理者レポートが表示されます。

図11-49 CAA 管理者レポート

 

View ボタンをクリックすると、各ユーザ レポートが表示されます(図11-50 を参照)。

図11-50 CAA ユーザ レポートの例

 

CAA レポートには、ユーザ、オペレーティング システム、Agent バージョン、およびドメイン情報のほか、ユーザ ロールに適用可能な要件(Mandatory および Optional の両方)が表示されます。ユーザが満たしている要件はグリーンで、満たしていない要件はレッドで表示されます。要件を構成している各チェックは、ステータス(Passed、Failed、または Not executed)を基準として表示されます。これにより、要件に違反した場合に、違反したチェックを正確に表示することができます。

Not Executed チェックは、別の OS に適用されたなどの理由により、適用されなかったチェックです。 Failed チェックの原因は、「OR」演算であることがあります。レポートを削除するには、 Delete ボタンをクリックします。これにより、フィルタリング基準に基づいて現在選択されているレポート エントリがすべて削除されます。

レポート数の制限

ログ内のレポート数を制限するには、 Device Management > Clean Access > Clean Access Agent > Reports > Report Setting を使用します。最大レポート数には 100 ~ 200000(デフォルトは 30000)を指定します。

CAA レポートは独自のテーブルに格納され、一般的なイベント ログから分離されます。

CAA ユーザ ダイアログ

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

「Windows Agent ダイアログ」

「Mac OS X Agent のダイアログ(認証のみ)」

「RADIUS のチャレンジ/レスポンス方式 Agent ダイアログ」

「Agent のローカライズされた言語テンプレート」

Windows Agent ダイアログ

ここでは、ネットワークに Cisco NAC Appliance がインストールされており、CAA が必要で、ユーザ ロール用に設定されている場合のユーザ操作を示します。


) VPN コンセントレータの背後の Single Sign-On(SSO)用に設定された CAA の詳細については、『Cisco NAC Appliance - Clean Access Server Installation and Administration Guide』Release 4.1(1) を参照してください。


1. ユーザが最初に Web ブラウザを開くと、Web ログイン ページにリダイレクトされます(図11-51)。

図11-51 ログイン ページ

 

2. ユーザは Web ログイン ページにログインすると、CAA インストール ファイルのワンタイム ダウンロードを実行できる Clean Access Agent Download ページにリダイレクトされます(図11-52)。

図11-52 Clean Access Agent Download ページ

 

3. Download Clean Access Agent ボタンをクリックします(ボタンに、ダウンロードされている Agent のバージョンが表示されます)。


Device Management > Clean Access > General Setup > Agent Login で [Allow restricted
network access in case user cannot use Clean Access Agent
] オプションが選択されている場合、Get Restricted Network Access ボタンと関連するテキストが Download Clean Access Agent ページに表示されます。詳細は、を参照してください。


4. クライアント システムのダウンロード フォルダに CCAAgent_Setup.exe ファイルを 保存 してから、CCAAgent_Setup.exe ファイルを 実行 します。


) CAS 証明書がクライアント側で信頼されない場合は、Agent インストレーションを次に進める前に表示される Security Alert ダイアログで証明書を受け入れる必要があります。


5. Welcome to the InstallShield Wizard for Clean Access Agent ダイアログが表示されます(図11-53)。

図11-53 Clean Access Agent InstallShield ウィザード

 

6. セットアップ ウィザードに、ユーザに簡単なインストール手順のプロンプトが表示され、ユーザに CAA を C:\Program Files\Cisco Systems\Cisco Clean Access\Clean Access Agent にインストールし、クライアントにデスクトップ ショートカットを追加するように促します(図11-54)。

図11-54 デスクトップ ショートカット

 

7. InstallShield Wizard が完了し、ユーザが Finish をクリックすると、CAA ログイン ダイアログがポップアップし(図11-55)、システム トレイに CAA タスクバー アイコンが表示されます。

図11-55 CAA のログイン ダイアログ

 

8. 証明書を入力してネットワークにログインします。Web ログイン ページと同様に、複数の認証プロバイダーが設定されている場合は、 Provider リストから 1 つを選択できます。


) セッションベースの Remember Me チェックボックスをオンにすると、ユーザがアプリケーションを終了またはアップグレードしたり、マシンをリブートしない場合、ログイン/ログアウトを何回実行しても User Name および Password フィールドに、直前に入力した値が読み込まれます。マシンを共有している場合は、Remember Me チェックボックスをオフにして、マシン上の複数のユーザが個々のユーザ名とパスワードを常に入力するようにします。

Cisco Clean Access がユーザ認証で RADIUS サーバを使用しており、追加の証明書を使用してユーザを認証するようにサーバが設定されている場合、「Windows RADIUS チャレンジ/レスポンス方式ユーザ ログイン セッション ダイアログの例」のように、1 つまたは複数の追加のチャレンジおよびレスポンス方式ダイアログが表示される場合があります。


9. ユーザはシステム トレイの CAA アイコンを右クリックして、Agent のタスクバー メニューを起動できます(図11-56)。

図11-56 CAA のタスクバー メニュー

 

タスクバー メニュー オプションの内容は、次のとおりです。

Login/Logout ― このトグルは、ユーザのログイン ステータスを反映します。 Login は、ユーザが CAS の背後に存在し、ログインしていない場合に表示されます。 Logout は、ユーザがすでに Cisco NAC Appliance にログインしている場合に表示されます。次の場合は、 Login オプションがディセーブル(グレー表示)になることに注意してください。

CAA が CAS を検出できない場合

アウトオブバンド配置において、CAS を介してすでにログインしている Agent ユーザが、アクセス VLAN に移動する場合

マルチホップ L3 配置において、SSO がイネーブル化されていて、ユーザが VPN コンセントレータを介してすでに認証されている場合(したがって、すでに Cisco NAC Appliance に自動的にログインしている場合)

MAC アドレスベースの認証がこのユーザのマシンに設定されており、ユーザ ログインは必要ない場合

Popup Login Window ― このオプションは Agent が最初からインストールされている場合にデフォルトで設定されており、ユーザが CAS の背後に存在し、ログインしていないことを検出した場合に Agent ログイン ダイアログが自動的にポップアップします。

Properties Properties を選択すると Agent Properties and Information ダイアログが起動し、L3 配置のクライアント マシンおよび Discovery Host にインストールされたすべての AV および AS 製品が表示されます(図11-57)。

図11-57 Properties

 

About ― Agent のバージョンを表示します(図11-58)。

図11-58 About

 

Exit ― アプリケーションを終了し、タスクバーの Agent アイコンを削除し、ユーザを自動的にログオフします。


) • Agent を終了するか、またはタスクバー アイコンが稼働していない場合は、デスクトップのショートカット(図11-57)をクリックして Agent を起動し、タスクバー アイコンを表示します。

タスクバー メニューで [ Popup Login Window ] がディセーブルの場合、ユーザは常にシステム トレイから Agent アイコンを右クリックして、 Login図11-56)を選択して、ログイン ダイアログを起動できます。


 


Auto-Upgrade for Already-Installed Agents: Agent がすでにインストールされている場合、アップグレード通知をディセーブルにしていないかぎり、ログインするたびに自動アップグレードのプロンプトがユーザに表示されます。オプションでマシンのシャットダウン時に強制的にログアウトすることもできます(デフォルトでは、マシン シャットダウン時もユーザはログインしたままです)。自動アップグレードは必須またはオプションに設定できます。自動アップグレードがイネーブルの状態で、新しいバージョンの Agent を CAM から使用できる場合、既存の Agent ユーザにはログイン時に次のいずれかのアップグレード プロンプトが表示されます(図11-59 または図11-60)。

図11-59 自動アップグレード プロンプトの例(必須)

 

図11-60 自動アップグレード プロンプトの例(任意)

 

10. OK または Yes をクリックすると、Agent を最新バージョンにアップグレードするセットアップ ウィザードが起動されます(図11-53)。Agent がアップグレードし、ユーザがログインすると、要件のチェックが続行されます。


 

11. ユーザが証明書を送信すると、CAA はユーザ ロール用に設定された要件をクライアント システムが満たすかどうかを自動的にチェックします。ネットワーク スキャンも設定されている場合は、図11-61 のダイアログも表示されます。

図11-61 Agent スキャニング ダイアログ

 

12. 要求されたソフトウェアが存在しない場合は、 You have temporary access! ダイアログが表示されます(図11-62)。ダイアログで指定されたセッション タイムアウト中は、ユーザに CAA Temporary ロールが割り当てられます。Temporary ロール セッション タイムアウトはデフォルトで 4 分に設定されており、ユーザが Web リソースにアクセスして、必要なソフトウェアのインストール パッケージをダウンロードできる十分な時間が設定されている必要があります。

図11-62 Temporary アクセス -- 要件に違反した場合

 

13. Continue をクリックすると、AV またはカスタム要求に関する Agent ダイアログが表示されます。このダイアログでは、存在しないソフトウェアが識別され、要件タイプに設定された説明、アクション ボタン、またはリンクが表示されます。

14. ユーザを次のステップに誘導するために要件の Description フィールドに設定した内容が、
Description
テキストに表示されます。実行する AV または AS アップデートの説明、アクセスする Web リソース、CAM を介して配布しているインストール ファイル、または拡張が必要な要件のその他の項目を指定します。

AV Definition Update 要件(図11-63)の場合は、 Update ボタンをクリックして、システムのクライアント AV ソフトウェアを更新します。

図11-63 AV Definition Update 要件の例

 

CAA は、AV/AS ソフトウェアが更新されると成功したことを示す確認メッセージを表示します(図11-64)。

図11-64 AV Definition Update が成功したことを示す確認メッセージ

 


) Agent はクライアントにインストールされている AV/AS ソフトウェアのアップデート メカニズムから受信する応答に基づいて、成功したことを示す確認メッセージを表示します。Agent は AV/AS クライアント ソフトウェアとアップデート サーバ間のアップデート相互作用を制御しません。


AS Definition Update 要件(図11-65)の場合は、 Update ボタンをクリックして、クライアント システムの AS ソフトウェアの定義ファイルを更新します。

図11-65 AS Definition Update 要件の例

 

Windows Update 要件(図11-66)の場合、ユーザは Update ボタンをクリックして、要件に [Automatically Download and Install] が設定されている場合に Windows Update を設定し、クライアント システムのアップデートを強制します。

図11-66 Windows Update 要件の例

 

Windows Server Update Service 要件(図11-67)の場合、 Update ボタンをクリックして、Windows Server Update Service を設定し、クライアント システムのアップデートを強制します。

図11-67 Windows Server Update Service 要件の例

 

Launch Program 要件(図11-68)の場合、 Launch ボタンをクリックして、要件が満たされない場合に復旧するために、認定されたプログラムを自動起動します。

図11-68 Launch Programs 要件の例

 

File Distribution 要件(図11-69)の場合、ボタンをクリックすると、 Go To Link でなく Download が表示されます。Download をクリックすると、 Save file to ダイアログが表示されます。インストール ファイルをローカル フォルダに保存し、そこから実行可能ファイルを実行する必要があります。

図11-69 File Distribution 要件の例

 

Link Distribution 要件(図11-70)の場合は、 Go To Link をクリックして、必要なソフトウェア インストール ファイルの Web サイトにアクセスできます。ブラウザが開き、Location フィールドで指定された URL が表示されます。

図11-70 Link Distribution 要件の例

 

15. この段階で Cancel をクリックすると、ログイン プロセスが停止します。

16. 要件ごとに、必要な処理(Update、Go To Link、Download)が完了したら、 Next をクリックして次に進む必要があります。Agent はシステムを再スキャンして、要件が満たされているか確認します。満たされている場合、Agent はロールに設定された次の要件に進みます。

17. Network Policy ページがロールに対応するように設定されている場合、要件が満たされていれば、次のダイアログが表示されます(図11-71)。(CAM または外部サーバにアップロードされた)「ネットワーク使用ポリシー」HTML ページを表示するには、 Network Usage Terms & Conditions リンクをクリックします。正常にログインするには、 Accept ボタンをクリックする必要があります。

図11-71 ネットワーク ポリシー ダイアログ

 

このダイアログの設定の詳細については、「Agent ユーザ用の Network Policy ページ(AUP)の設定」を参照してください。

18. すべての要件が満たされている場合(およびネットワーク ポリシーが設定されている場合はそれを受け入れた場合)、ユーザは Temporary ロールから標準ログイン ロールに転送され、ログイン成功ダイアログが表示されます(図11-72)。ユーザは標準ログイン ロールで許可されたネットワークに自由にアクセスできます。


) 要求をオプション化する「Do not enforce requirement」オプションがオンの場合に、Agent 内でオプション要件に対応する Next をクリックすると、その他の要件がすべて満たされていれば、次の要件ダイアログまたはログイン成功ダイアログが表示されます。



) 管理者は指定した秒数のあとに Login および Logout 成功ダイアログが自動的に閉じるように設定したり、どちらのダイアログも表示されないように設定したりできます。詳細は、を参照してください。


図11-72 ログイン成功

 

19. ネットワークをログオフするには、システム トレイ内の CAA アイコンを右クリックして、 Logout を選択します。ログアウト画面が表示されます(図11-73)。管理者がユーザをネットワークから削除する場合、 Popup Login Window が設定されている場合には、 Login ダイアログが代わりに再表示されます。


) 管理者は Login および Logout 成功ダイアログが指定した秒数のあとに自動的に閉じるように設定したり、どちらのダイアログも表示されないように設定したりできます。詳細は、を参照してください。


図11-73 ログアウト成功

 

20. 要件を満たしているユーザは、自身のコンピュータまたは CAA 要件に変更がないかぎり、次のログイン時にこれらの CAA チェックにパスします。

21. 要求されたソフトウェア インストールでコンピュータの再起動が必要な場合は、ネットワークをログアウトしてから、再起動する必要があります。そうしないと、ユーザはセッションがタイムアウトするまで Temporary ロールにとどまります。セッション タイムアウトおよびハートビート チェックを設定すると、ネットワークのログアウトに失敗したユーザを手動で切断できます。

Mac OS X Agent のダイアログ(認証のみ)

Cisco Clean Access には、Mac OS X マシンで認証を実行する Agent があります。Agent は、Mac OS 10.2 ~ 10.4 をサポートするユニバーサル バイナリの形式をとっています。Mac OS X CAA は、VPN 配置による SSO をサポートしていますが、Active Directory による SSO はサポートしていません。


) CAM Web コンソールでは、Device Management > Clean Access > Clean Access Agent > Distribution の Mac OS X CAA の配布オプションを表示できます。詳細は、「Distribution ページ」を参照してください。


詳細は、「Mac OS/CAS 通信の SSL 要件」を参照してください。

図11-74 Distribution - CAM Web コンソール

 

Mac OS Agent ユーザ シーケンスは、次のとおりです。

1. ユーザは Login ページにリダイレクトされます(図11-75)。

図11-75 ログイン ページ -- Mac OS X

 

2. ユーザは Download Clean Access Agent ページに誘導されます(図11-76)。

図11-76 Agent のダウンロード -- Mac OS X

 

3. [Download] ボタンをクリックすると、CCAAgent_Mac OSX.tar.gz.tar ファイルがデスクトップにダウンロードされ(図11-77)、解凍されます。

図11-77 デスクトップへの CAA セットアップ実行ファイルのダウンロード

 

4. CCAAgent.pkg ファイルをダブルクリックすると、CAA の Mac OS インストーラが起動します(図11-78)。

図11-78 CCAAgent.pkg をダブルクリックし Clean Access Agent Installer を起動

 

5. Continue ボタンをクリックして、インストーラの Read Me および Select Destination 画面に進みます(図11-79)。

図11-79 インストレーションの実行

 

6. Upgrade ボタンをクリックして、インストレーションを実行します(図11-80)。終了したら、 Close をクリックします。

図11-80 インストレーションの実行(続き)

 


) Agent がマシンに一度もインストールされていない場合、Installation 画面(図11-80)に [Install] ボタンが表示されます。一度でも Agent がインストールされている場合は、現在システムに Agent が存在していなくても、インストーラが起動すると、[Upgrade] ボタンが表示されます。


7. インストール後、CAA ログイン ダイアログが表示されます。Agent アイコンは、ツール メニュー(図11-81)から使用できるようになります。Agent アイコンを右クリックすると、メニューの選択肢が表示されます。

Login/Logout (ログイン ステータスに応じて切り替わります)


) Cisco Clean Access がユーザ認証で RADIUS サーバを使用しており、追加の証明書を使用してユーザを認証するようにサーバが設定されている場合、「Mac OS X RADIUS チャレンジ/レスポンス方式ユーザ ログイン セッション ダイアログの例」のように、ユーザに 1 つまたは複数の追加のチャレンジ/レスポンス方式ダイアログが表示される場合があります。


Auto Popup Login Window (デフォルトでイネーブル)

About (Agent のバージョン画面を表示)

Quit (Agent アプリケーションを終了する)

図11-81 ツール メニューから使用できる Agent ログイン ポップアップおよびデスクトップ アイコン

 

8. Agent ログイン ステータスは、ヒント ポップアップおよびメニューの Agent アイコンの色によって示されます。

グリーン図11-82)は、次の内容を示します。

CAS が検出されている

ログイン ステータスは [Logged In]

CAS ステータスは、Fallback([Allow All])で、ユーザ ステータスは [Bypass]

Agent は [Allow/Role] で MAC アドレスによってフィルタリングされ、ユーザ ステータスは [Logged-In]

図11-82 Agent ログイン ステータス -- グリーン(Logged In)

 

グレー図11-83)は、CAS が検出されていないことを示します。

図11-83 Agent ログイン ステータス -- グレー(CAS が検出されていない)

 

オレンジ図11-84)は、次の内容を示します。

CAS が検出されている

ログイン ステータスは、まだログインしていない状態

CAS ステータスは Fallback([Block All])で、ユーザ ステータスは [Blocked]

Agent は [Deny] で MAC アドレスによってフィルタリングされ、ユーザ ステータスは [Blocked]

Agent は [Check] で MAC アドレスによってフィルタリングされ、ユーザ ステータスは現在サポートされていない

図11-84 Agent ログイン ステータス -- オレンジ(CAS が検出され、Agent がログインしていない)

 

9. CAA アプリケーションは、 Macintosh HD > Library > Application Support > Cisco Systems > CCAAgent でインストールします(図11-85)。

図11-85 CAA -- アプリケーション インストレーションのロケーション

 

10. CAA の event.log デバッグ ファイルと setting.plist システム プリファレンス ファイルは、 <username> > Library > Application Support > Cisco Systems > CCAAgent でインストールします(図11-86)。

図11-86 CAA -- Event.log および Setting.plist ファイルのロケーション

 

11. setting.plist ファイル(図11-87)には、次の内容が含まれます。

Agent event.log 用に選択された LogLevel

Remember Me が Login 画面でチェックされるかどうか

AutoPopup Login Window が Menu でチェックされるかどうか

図11-87 CAA -- Setting.plist ファイルの内容

 

RADIUS のチャレンジ/レスポンス方式 Agent ダイアログ

CAM を RADIUS サーバを使用してリモート ユーザを検証するように設定すると、エンド ユーザ CAA ログイン セッションは、標準のユーザ ID とパスワードに加えて他のダイアログ セッションでは使用できない特別な認証チャレンジ/レスポンス方式ダイアログを組み合わせる場合があります。この追加の相互作用は RADIUS サーバ自身のユーザ認証プロファイルに起因し、CAM の追加の設定は必要とされません。たとえば、RADIUS サーバのプロファイル設定では、標準のユーザ ID とパスワードに加えて、トークン生成の PIN または他のユーザ指定の証明書を検証するような追加の認証チャレンジを組み合わせている場合があります。この場合、1 つまたは複数の追加のログイン ダイアログ画面がログイン セッションの一部として表示される可能性があります。

次の 2 つのセクションでは、Windows と Mac OS X Agent ユーザ認証用のダイアログのやりとりの例を紹介します。

Windows RADIUS チャレンジ/レスポンス方式ユーザ ログイン セッション ダイアログの例

1. リモート ユーザは通常どおりにログインし、ユーザ名とパスワードを入力します(図11-88 を参照)。

図11-88 CAA のログイン ダイアログ

 

2. 関連付けられた RADIUS サーバが追加の証明書でユーザを認証するように設定されている場合、図11-89 に表示されたパスワードの更新シナリオと同じような追加のチャレンジ/レスポンス方式ダイアログが 1 つまたは複数ユーザに表示されます。ユーザは、追加の証明書を追加して、認証と接続を実行する必要があります。

図11-89 追加の Windows RADIUS チャレンジ/レスポンス方式セッション ダイアログ

 

3. 追加のチャレンジ/レスポンス方式ダイアログが検証されると、RADIUS サーバは、ユーザが正常に認証され、リモート アクセスを許可する必要があることを CAM に通知します。

図11-90 Windows RADIUS チャレンジ/レスポンス方式認証が成功した場合

 

Mac OS X RADIUS チャレンジ/レスポンス方式ユーザ ログイン セッション ダイアログの例

1. リモート ユーザは通常どおりにログインし、ユーザ名とパスワードを Agent ログイン ダイアログに入力します(図11-91 を参照)。

図11-91 Mac OS X ログイン ダイアログ

 

2. 関連付けられた RADIUS サーバが追加の証明書でユーザを認証するように設定されている場合、図11-92 に表示されたパスワードの更新シナリオと同じような追加のチャレンジ/レスポンス方式ダイアログが 1 つまたは複数ユーザに表示されます。ユーザは、追加の証明書を追加して、認証と接続を実行する必要があります。

図11-92 追加の Mac OS X RADIUS チャレンジ/レスポンス方式ダイアログ

 

3. 追加のチャレンジ/レスポンス方式ダイアログが検証されると、RADIUS サーバは、ユーザが正常に認証され、リモート アクセスを許可する必要があることを CAM に通知します。

図11-93 Mac OS X RADIUS チャレンジおよびレスポンス方式認証が成功した場合

 

Agent のローカライズされた言語テンプレート

CAA は言語テンプレートを使用して、複数のヨーロッパ言語をサポートしています。英語に加えて、バージョン 4.1.0.0 の CAA はドイツ語、イタリア語、フィンランド語、チェコ語、ノルウェー語、スペイン語、デンマーク語、フランス語、ロシア語、スウェーデン語、トルコ語、セルビア語、およびカタロニア語をサポートしています。

Agent は、ローカル コンピュータの Locale 設定に基づいた正しいテンプレートを選択します。ローカライズされた Agent を使用するには、ユーザは Control Panel > Regional and Language Options で対応する言語に Windows ロケール設定を変更する必要があります。たとえば、フランス語で Agent を使用するには、Windows ロケールをフランス語に設定する必要があります。

さらに、Agent エラー メッセージの警告と Properties データはすべて、サポート対象の言語テンプレートに基づいています。Windows の英語版はすべての文字を正確に表示できないので、たとえば、ロシア語の Agent をロシア語版 Windows で使用するといったように、Windows のローカライズ版でローカライズされた Agent を使用することを推奨します。管理者向けの要件と説明の名前は、CAM に設定されたとおりになります。CAM では、適切な言語の文字を使用して、要件と説明の名前を設定できます。


) テキストベースのすべてのメッセージはサポート対象の言語で表示されますが、実際のチェックと規則の名前は CAM に設定されたとおりになります。



) Agent テンプレートのサポートは、Agent インストーラまたは AV/AS 製品の異なるクライアント OS に対するサポートとは異なります。Agent 言語テンプレートは、Agent のインストール後に表示される内容だけを制御します。


1. Agent は Control Panel > Regional and Language Options で設定されたクライアント PC(図11-94)の Windows ロケール設定に基づいて正しいテンプレートを選択します。

図11-94 ロケールに基づいた Agent の言語テンプレート

 

2. CAM に設定された要件は、言語テンプレートに表示されます(図11-95)。


) テキストベースのすべてのメッセージはサポート対象の言語で表示されますが、実際のチェック、規則、および要件の名前は CAM に設定されたとおりになります。CAM では、適切な言語の文字を使用して、チェック、規則、および要件の名前を設定できます。


図11-95 Agent 要件のダイアログ(ローカライズ済み)

 

3. エラー、メッセージ、警告、および Properties データはすべて、サポート対象の言語テンプレートに基づいています(図11-96)。

図11-96 言語テンプレートのメッセージおよびプロパティ

 


) Agent テンプレートのサポートは、Agent インストーラ パッケージまたは AV/AS 製品が別の OS でサポートされるものではありません。言語テンプレートは、Agent のインストール後に表示される内容だけを制御します。


Agent のトラブルシューティング

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

クライアントが接続およびログインできない

Agent がポップアップしない、ログインがディセーブル

クライアントが接続できない(トラフィック ポリシー関連の問題)

AV/AS 規則のトラブルシューティング

Windows Script 5.6 の既知の問題

MS Update Scanning Tool の既知の問題(KB873333)

クライアントが接続およびログインできない

次のログイン時のクライアント エラーは、CAM/CAS 証明書関連の問題(すなわち、CAS が CAM の証明書を信頼しない、またはその逆)があることを示します。

ユーザの証明書を入力したあと、Web ログインを試みているユーザに、ログイン ページが継続して表示され、リダイレクトされない

Agent ログインを試みているユーザに「Clean Access Server could not establish a secure connection to the Clean Access Manager at <IPaddress or domain>」のエラーが表示される

これらの問題を解決するには、「証明書に関する問題のトラブルシューティング」を参照してください。

Agent がポップアップしない、ログインがディセーブル

L2 または L3 配置において、Agent で [Popup Login Window] をイネーブルにしていると CAA がクライアントでポップアップし、Agent が CAS の背後にあることを検出します。Agent がポップアップしない場合は、CAS に到達できないことを示します。

L2 配置のトラブルシューティング:

1. クライアント マシンが正しい IP アドレスを取得できるようにします。コマンド ツール(Start > Run > cmd)を開き、 ipfconfig または ipconfig /all を入力して、クライアント IP アドレス情報をチェックします。

2. 必要な場合、 ipconfig /release を入力してから、 ipconfig /renew を入力して、クライアントの DHCP リース時間をリセットします。

L3 配置のトラブルシューティング:

1. Device Management > Clean Access > Clean Access Agent > Installation | Discovery Host で、Discovery Host フィールドに CAM の IP アドレスが設定されているかどうかをチェックします。このフィールドは、信頼できる側の装置のアドレスである必要があり、CAS のアドレスにすることはできません。

2. クライアントの Agent をアンインストールします。

3. Discovery Host フィールドを CAM の IP アドレスに変更して、 Update をクリックします。

4. CAS をリブートします。

5. クライントに Agent を再ダウンロードおよび再インストールします。


) Agent の Login オプションは、次の場合に必ずディセーブルになります(グレー表示)。

OOB(アウトオブバンド)配置において、Agent ユーザは CAS 経由ですでにログインしていて、クライアント ポートが Access VLAN 上にある場合

マルチホップ L3 配置において、Single Sign-On(SSO)がイネーブル化されていて、ユーザが VPN コンセントレータを介してすでに認証されている場合(したがって、すでに Cisco NAC Appliance に自動的にログインしている場合)

MAC アドレスベースの認証がこのユーザのマシンに設定されており、ユーザ ログインが必要ない場合


 

クライアントが接続できない(トラフィック ポリシー関連の問題)

次のエラーは、DNS、プロキシまたはネットワーク トラフィック ポリシー関連の問題である場合があります。

ユーザは Agent 経由でログインできるが、ログイン後に Web ページおよびインターネットにアクセスできない。

ユーザが URL に https://<CAS_IP_address> を入力せずに、Web ログイン ページにアクセスすることができない。

これらの問題をトラブルシューティングするには:

Device Management > CCA Servers > Manage <CAS_IP> > Network > DNS で、CAS の DNS Servers 設定を確認および変更、またはいずれか一方を行います。

DHCP サーバとして CAS をイネーブルにしている場合、 Device Management > CCA Servers > Manage <CAS_IP> > Network > DHCP > Subnet List > List | Edit で、Subnet List の DNS Servers フィールドを確認および変更、またはいずれか一方を行います。

ログイン後に復旧サイトに到達できない場合は、 User Management > User Roles > Traffic Control > Host で、Temporary ロールのデフォルトのホスト ポリシー(Allowed Hosts)がイネーブルであることを確認します。

プロキシ サーバを使用している場合、プロキシ サーバへの HTTP トラフィックを許可しているトラフィックが Temporary ロールでイネーブルにされていることを確認します。ブラウザでプロキシが正しく設定されていることを確認します(IE から Tools > Internet Options > Connections > LAN Settings | Proxy server に進みます)。

詳細は、「ホストベースのポリシーに関するトラブルシューティング」を参照してください。

AV/AS 規則のトラブルシューティング

CAA の管理者レポートを表示するには、 Device Management > Clean Access > Clean Access Agent > Reports に進みます。クライアントから情報を表示するには、Agent タスクバー アイコンを右クリックして、 Properties を選択します。

AV/AS 規則のトラブルシューティングを行う場合は、次の情報が必要です。

1. CAS、CAM、および CAA のバージョン

2. クライアント OS バージョン(たとえば、Windows XP SP2)

3. AV/AS ベンダー製品の名前およびバージョン

4. 障害の内容 ― AV/AS インストール チェックであるか、または AV/AS 更新チェックであるか。および、エラー メッセージの内容。

5. 障害のあるクライアント マシンの AV/AS 定義日/バージョンの現在値

6. CAM で検索されている AV/AS 定義日/バージョンの対応する値( Device Management > Clean Access > Clean Access Agent > Rules > AV/AS Support Info を参照)。

Windows Script 5.6 の既知の問題

CAA を適切に機能させるには、Windows Script 5.6 が必要です。Windows 2000 以前のほとんどの OS には、Windows Script 5.1 コンポーネントが付属しています。Windows Updates を実行すると、新しい 5.6 コンポーネントが自動的にインストールされます。Windows インストーラ コンポーネント 2.0 および 3.0 にも Windows Script 5.6 は必要です。ただし、Windows Update を実行しない Windows 98、ME、または 2000 のフレッシュ インストールが存在する PC マシンには、Windows Script 5.6 コンポーネントがありません。Microsoft はこのコンポーネントをマージ モジュール/再配布可能コンポーネントとして提供していないため、Cisco NAC Appliance はこのコンポーネントを再配布できません。

この場合、管理者は MSDN Web サイトにアクセスして、このコンポーネントを入手し、Windows Script 5.6 にアップグレードする必要があります。便利なように、MSDN からコンポーネントへのリンクを次に示します。

Win 98、ME、NT 4.0:

ファイル名:scr56en.exe

URL:
http://www.microsoft.com/downloads/details.aspx?familyid=0A8A18F6-249C-4A72-BFCF-FC6AF26DC390&displaylang=en

Win 2000、XP:

ファイル名:scripten.exe

URL:
http://www.microsoft.com/downloads/details.aspx?familyid=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en

MSDN でこれらのリンクが変更された場合は、上記のファイル名を検索するか、「Windows Script 5.6」という語句を検索します。

MS Update Scanning Tool の既知の問題(KB873333)

背景

KB873333 は、SP1 および SP2 に対応した Windows XP Professional および Windows XP Home Edition に必要な重要なアップデートです。リモート コードを実行できる OS の脆弱性が、これによって修正されます。ただし、このホットフィックスにはバグがあり、SP2 Edition(Home/Pro)では問題が発生します。SP2 に KB873333 を組み込まれている場合は、Double Byte Character Sets(DBCS)の表示問題が発生するため、このバグには別のフィックス(KB894391)が必要でした。ただし、DBCS 表示問題を解決するだけで、KB894391 は KB873333 の代わりにはなりません。

原則として、ユーザ マシンに KB873333 が組み込まれていない場合は、KB894391 はインストールされず、アップデートにも表示されません。ただし、KB873333 がインストールされているかどうかに関係なく、MS Update Scanning Tool ツールでは KB894391 が表示されます。また、アップデートを指示して KB894391 をインストールした場合、MS Update Scanning Tool では KB873333 がインストール済みであると表示されないため、脆弱性が解消されません。このようになるのは、表示されたアップデート リストからインストールするときに、ユーザが KB873333 をインストールしないで KB894391 のみを選択した場合、または KB873333 を先にインストールしないで、KB894391 を手動でインストールした場合です。この場合、次にアップデートを実行するときに、必要なアップデートとして KB873333 が表示されなくなります。KB873333 がインストールされておらず、マシンが脆弱なままであっても、KB894391 がインストールされていれば、MS Update Scanning Tool(MS Baseline Analyzer を含む)は KB873333 がインストールされていると想定するためです。

対処法

この脆弱性があるために、シスコでは Clean Access の規則セットから KB87333 のアップデート チェックを削除する予定はありません。ユーザは手動で KB873333 をダウンロードおよびインストールして、マシンを保護する必要があります。そのためには、次のいずれかの方法を使用します。

方法 1(シスコが推奨する方法)

次の手順に従って、CAM Web コンソールで、KB873333 を検索する新しいリンク要件を作成します。

1. KB873333 の有無を調べる規則を作成します。この規則を作成するには、Web コンソールの Rules セクションに移動し、New Rule をクリックします。規則に名前(「KB873333_Rule」など)を付け、このページに表示されたチェック リストから規則式に、KB873333 チェックの正確な名前をコピーアンドペーストします(使用可能なチェック リストが、新しい規則作成セクションの下に表示されます)。「Add Rule」をクリックして、規則を保存します。

2. Microsoft の Web サイトから KB873333 の実行可能アップデートをダウンロードして、使用可能な Web サーバに配置します。

3. CCA のリンク要件を作成し、ステップ 2. の URL を入力します。

4. ステップ 1. で作成した規則を選択して、この要件の要件/規則を作成します。

5. 最後に Role-Requirements セクションに移動して、作成した要件に、この要件を適用するロールを対応付けます。


) Requirements ページで、KB873333 要件が Windows Hotfixes 要件の上にあることを確認します。


方法 2

関連するマシンから KB894391 をアンインストールします。再起動してから、Windows Update ページを再表示します。Windows Update に両方のアップデートが表示されます。クライアント マシンに KB873333 および KB894391 をインストールします。この方法の場合は、管理者がユーザを教育するか、または各ユーザ マシンでこのタスクを手動で実行する必要があります。