準拠状況のレポート: クライアント アクセスを制御するための第一歩

NAP と IPsec を使用して、DirectAccess を通じてクライアント アクセスを制御することで、監査と準拠状況のレポートを強化することができます。

Dan Griffin および Lee Walker

セキュリティで保護されたアクセスの確立は、企業がクラウドに進出するための必然的な第一歩です。準拠状況、レポート、およびリモート接続に関するポリシーを今設定することで、チームが円滑かつ安全にクラウド内で作業する方法の土台を作ることができます。ネットワーク アクセス保護 (NAP) を DirectAccess などの IPsec 接続テクノロジと併用すると、監査と準拠状況のレポートが強化されるため、役に立ちます。

新しい DirectAccess または IPsec の展開用に監査とレポートのソリューションを作成する際、必要なデータを特定および収集するのは困難な場合があります。この記事では、架空の企業が DirectAccess と NAP のソリューションを作成し、接続していたユーザー、ユーザーがいつ接続していたか、およびクライアント コンピューターがポリシーに準拠していたかを特定するためのレポート データを提供する方法の例を示します。

準拠の問題

移動する従業員がますます多くなるにつれて、DirectAccess などの柔軟なリモート アクセス テクノロジを採用する組織は増えています。DirectAccess を使用すると、ユーザーは、承認されたコンピューターでインターネットに接続した場合はいつでも、自動的にリモート ネットワークに接続されます。リモート クライアントは最新のセキュリティ更新プログラムが適用されていない場合があり、マルウェアに感染している可能性があるので、多くの組織は、正常なクライアントのみがセキュリティで保護されたリソースにアクセスするようにするため、IPsec と共に NAP も展開します。

金融サービス、医療、政治などの業界では、承認された正常なクライアントのみがクラウド ベースや組織内のネットワーク リソースにアクセスすることを確認することは、データの整合性にとってきわめて重要です。こうした業界では、多くの場合、承認されていない相手 (マルウェアや不明なサードパーティ製のアプリケーションを含む) による、銀行の口座番号、名前、医療記録などの個人を特定できる情報 (PII) へのアクセスが行われていないことを確認するよう、内部の法令遵守ポリシーや米国連邦法で義務付けられています。

ユーザーがより簡単に仕事のリソースにリモート アクセスする方法を求めるのに応じて、こうした機密性の高い業界の IT 管理者も、正常なクライアントのみが企業ネットワークにアクセスするように徹底する必要があります。残念ながら、NAP と DirectAccess のログを基にした意義のあるレポートの作成には、課題があります。

解決策は、シームレスなリモート クライアント アクセスのための DirectAccess インフラストラクチャを構築し、NAP と IPsec を使用してイントラネット リソースをセキュリティで保護し、レポートを通じてポリシーを監視することです。TechNet には、NAP と DirectAccess を実装する方法についての役立つ情報はある程度ありますが、クライアントの正常性についての効果的なログ記録とレポートに関するガイダンスはほとんどありません。この記事では、架空の企業 (Woodgrove National Bank) について考察し、コンサルタントが、単純なコードと SQL クエリを使用して、指定された期間中に接続したクライアント、およびこうしたクライアントが NAP に準拠していたかどうかを示す、人間が判読可能なレポートを作成した方法について説明します。

DirectAccess 上に NAP を設定する

DirectAccess を使用するには、接続するクライアントが、互換性のあるバージョンの Windows (Windows 7 Ultimate または Windows 7 Enterprise) を実行している必要があります。こうしたクライアントは、Windows Server 2008 R2 を実行している DirectAccess サーバーに接続します。DirectAccess の展開には、1 台または複数の DirectAccess サーバーを含めることができます (トラフィックの多いネットワークでの負荷分散に役立つように、少なくとも 2 台のサーバーを使用することをお勧めします)。また、展開には、ネットワーク ロケーション サーバー (クライアントがインターネットとイントラネットのどちらに接続しているかを特定するため) および 1 つまたは複数の証明書失効リスト (CRL) 配布ポイント (アクセスが許可されなくなるクライアントの追跡に使用されます) も含める必要があります。DirectAccess の展開を設計する方法については、TechNet の「DirectAccess 設計ガイド (英語)」を参照してください。

DirectAccess 上に NAP を追加する場合、NAP の IPsec 強制方法を実装する必要があります。IPsec を使用すると、NAP に準拠しているクライアントには、正常性証明書が与えられます。準拠していないコンピューターは、準拠しているコンピューターと通信することができません。NAP を設計および展開する方法については、TechNet の「DirectAccess とネットワーク アクセス保護 (NAP) の併用を計画する (英語)」を参照してください。IPsec を強制方法として使用する場合の NAP の設計方法については、TechNet の「IPsec 強制の設計 (英語)」を参照してください。

NAP IPsec 強制シナリオが DirectAccess とその IPsec 接続ポリシーのコンテキスト内でどのように機能するかを考えるのは興味深いことです。第 1 に、DirectAccess では認証と機密性に IPsec が使用されるので、DirectAccess の展開での NAP 強制シナリオは IPsec である必要があります。第 2 に、IPsec の AuthIP コンポーネントを使用すると、ポリシー内で 2 つの異なる認証要件を構成して、両方の要件が満たされなければ接続が成功しないようにすることができます。AuthIP 認証オプションが両方構成される場合、通常、1 番目はコンピューターの資格情報で 2 番目はユーザーの資格情報です。ただし、厳密に言うと、コンピューターの資格情報を 2 つ構成することも可能です。

NAP は AuthIP ポリシーのどの部分に適合するのでしょうか。NAP/IPsec 強制シナリオでは、正常なコンピューターに、正常性オブジェクト識別子 (OID) の入った証明書が与えられます。AuthIP ポリシー エンジンには、この正常性 OID を要求するためのオプションがあります。そのため、正常なコンピューターのみが、1 番目の AuthIP 認証要件を満たし、DirectAccess サーバーへの IPsec 接続を確立することができます。

最後に、ユーザーの資格情報が 2 番目の AuthIP 認証オプションの目的です。厳密に言うと、DirectAccess では、ユーザーの資格情報は必須ではありません。つまり、クライアントは、コンピューターの資格情報のみを使用して DirectAccess エンドポイントからの認証を受けることもできます。セキュリティに敏感な IT スタッフは、強力な認証なしで完全なリモート ネットワーク アクセスを与えることに不安を感じるでしょう。したがって、最低でも、2 番目の認証に Kerberos を要求するように AuthIP ポリシーを構成する必要があります。より望ましいのは、Woodgrove National Bank のシナリオのように、ユーザーの資格情報の証明書を要求することです (リモートの固定パスワード攻撃のリスクが軽減されるため)。

このシナリオでは、Woodgrove National Bank のネットワーク セキュリティと法令遵守の部門が、指定された期間中に企業ネットワークに接続したユーザー、およびこうしたクライアントが NAP に準拠していたかどうかを示すレポートを要求しました。これらの部門は、その期間中に顧客データが漏えいした可能性があると考えています。Woodgrove National Bank のコンサルタントである私たちは、DirectAccess と NAP に関する事後レポートを可能にする方法を特定し、その情報を人間が判読可能なレポートにまとめる必要があります。

適切なポリシー構成

この架空のシナリオでは、Woodgrove National Bank は、NAP システム正常性 OID とクライアント認証 OID の入ったクライアント証明書が IPsec ポリシーで要求されるように DirectAccess を構成しました。Woodgrove は、NAP を (単なる報告モードではなく) 強制モードで使用しています。つまり、正常でないクライアントが正常なクライアントと通信することはできないということです。

また、Woodgrove は、証明書ベースの 2 つの資格情報 (クライアント コンピューターの資格情報とユーザーの資格情報) を使用するように DirectAccess の IPsec ポリシーを構成しました。Woodgrove は、PKI への投資をより適切に利用し、リモート アクセスで固定パスワードが使用されないようにし、証明書の自動登録を利用するために、前述のとおり、2 つの証明書を使用する構成を選択しました。

この話の残りの部分は、皆さんが DirectAccess、NAP、および IPsec 強制モードがどのように機能するかについての実用的な知識をお持ちであることを前提としています。これらのテクノロジの詳細については、以下のリソースを参照してください。

• DirectAccess の概要 (英語)
• ネットワーク アクセス保護の概要 (英語)
• NAP IPsec 強制とは

以下のレポート ソリューションでは、DirectAccess サーバーの IPsec の組み込みの監査機能、およびネットワーク ポリシー サーバー (NPS) の正常性登録機関 (HRA) 機能の監査機能を利用します。こうした監査機能によってシステム イベント ログとセキュリティ イベント ログにイベントが生成されるので、私たちはこのようなイベントを抽出してレポートします。このアプローチの策定中に、私たちは、HRA イベントは既定で生成されるのに対して、IPsec イベントは明示的に有効にしなければならない可能性があることに気付きました。IPsec イベントを有効にするには、コマンド プロンプト ウィンドウで次のコマンドを使用します。

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Main Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Quick Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Extended Mode" /success:enable /failure:enable

DirectAccess 正常性レポート

Woodgrove National Bank の NAP と DirectAccess のイベントを処理するために、私たちは、マイクロソフトの Web サイトから Log Parser 2.2 をダウンロードしてインストールしました。Log Parser は、このような (新しいイベント ソースを調査して適切なスキーマを作り上げる必要がある) プロジェクトに不可欠なツールです。手短に言うと、Log Parser では、Windows イベント ログ (.evtx)、CSV、SQL などのさまざまなデータ形式からデータをインポートしたり、こうしたさまざまなデータ形式にデータをエクスポートしたりすることができます。

次は、必要なイベントをキャプチャします。たとえば、次のようなイベントです。

• DirectAccess サーバーのセキュリティ ログの中の、IPsec セキュリティ アソシエーション関連のイベント
• HRA サーバーのセキュリティ ログとシステム ログの中の、正常性登録機関関連のイベント (これは、NAP を使用している場合にのみ当てはまります)

こうしたイベントを収集するための理想的な方法は、自動化され、なおかつ一元化された方法です。選択肢の 1 つは、Windows のイベント転送機能です。大規模な運用展開では、Microsoft System Center の方が一般的でしょう。今回は、運用サーバーに新たな依存関係を持ち込みたくなかったので、イベントの収集には単純なスクリプトを使用しました。

このアプローチを使用する場合、課題は 2 つあります。第 1 に、目的は複数のデータ ソースを相互に関連付けることなので、すべてのソースからデータをほぼ同時に収集することが重要です。第 2 に、このアプローチではログのスナップショットを作成しているだけで、トラフィックの多いイベント ログはすぐにロールオーバーされるので、(特にスナップショットの期間の最初や最後では) 相互に関連するイベントの一部が抜けてしまうことは避けられません。これによってこの実験的手法が無効になるわけではありませんが、クエリを調整するのはより困難になります。

(DirectAccess サーバーの 1 つでの) IPsec メイン モード セキュリティ アソシエーションごとに、(HRA サーバーの 1 つで) NAP 正常性トラフィックが確認されることが予想されます。NAP 報告モードでは、クライアント コンピューターは NAP に準拠していた可能性もそうでなかった可能性もあります。NAP 強制モードでは、クライアント コンピューターは NAP に準拠していたと考えられます。そうでなければ、DirectAccess サーバーからの認証を受けセキュリティ アソシエーション (SA) を確立するための有効な証明書を保持してはいないはずだからです。すべての DirectAccess サーバーと HRA サーバーで午後 3 時に同時に 1 回限りのログ キャプチャを行うとします。メイン モード セキュリティ アソシエーション (MM SA) イベントは確認できても、正常性イベントは確認できない可能性があります。

さらに可能性が高いのは、IPsec クイック モード セキュリティ アソシエーション (QM SA) と IPsec 拡張モード セキュリティ アソシエーション (EM SA) イベントは確認できても、MM SA イベントや正常性イベントは確認できないことです。前者は、後者の 1 時間以上も後に発生する場合があります。また、ログのロールオーバーの頻度はほぼ確実にサーバーごとに異なるので、DirectAccess サーバーでは午後 2 時からイベントが確認されるのに対して、HRA でイベントが確認されるのは早くても午後 2 時 30 分からであるという可能性があります。こうした理由から、運用時には一元化されたイベント収集方法を使用することが重要であることを繰り返し述べておきます。

データを生成する

データを生成するために、DirectAccess サーバーと HRA サーバーでスクリプトを実行しました。また、スクリプトがタスク スケジューラによって自動的に実行されるように構成しました。DirectAccess サーバーとすべての HRA でスクリプトが同時に 1 回実行されるように構成しました。

DirectAccess サーバーでデータを収集する

次のスクリプトを使用して、DirectAccess サーバーでイベントをキャプチャしました (図 1 参照)。

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\DA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12549 OR EventCategory=12547 OR EventCategory=12550" -o:CSV

注: このスクリプトでは、LogParser.exe (およびそれに従属する LogParser.dll) のローカル コピーを使用しています。利便性を考え、スクリプトを簡単にサーバーからサーバーにコピーできるように、このように参照を使用しました。

図 1 タスク スケジューラによって自動的に実行されるスクリプトを使用して DirectAccess サーバーからキャプチャされたイベントの詳細

HRA サーバーでデータを収集する

HRA サーバーでイベントをキャプチャするために、次のスクリプトを使用しました。

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12552" -o:CSV

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_System_Events_%COMPUTERNAME%.csv FROM System WHERE SourceName='HRA'" -o:CSV

注: HRA 用のスクリプトの中に出てくるイベント カテゴリ 12552 は、ネットワーク ポリシー サーバー サービスを表します。

データをインポートする

スクリプトが実行された後で、出力された CSV ファイルを、SQL Server 2008 を実行している別のコンピューター上に集めました。次のスクリプトを使用して、CSV データを SQL にインポートしました。

LogParser.exe "SELECT * INTO DaSasTable FROM DA_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSecurityEventsTable  FROM HRA_Security_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSystemEventsTable  FROM HRA_System_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023

注:

• SQL ホスト コンピューターの名前は dev1 です。データベースの名前は NapDa で、このデータベースは SQL Management Studio の既定値を使用して作成されています。
• このスクリプトの実行前には、DaSasTable、HraSecurityEventsTable、HraSystemEventsTable という 3 つのテーブルはまだ存在しませんでした。-createTable:ON という Log Parser のコマンド ライン オプションでは、入力データ (この場合はイベント ログの CSV ファイル) に基づいて適切なスキーマを使用してこれらのテーブルを自動的に作成するように Log Parser に指定しています。
• このシナリオでは、-maxStrFieldLen:1023 という設定が重要です。この設定を行わない場合、Log Parser では、varchar フィールドの既定の長さである 255 がさまざまなイベント ログ文字列フィールドに使用されます。しかし、イベント ログの CSV 形式には、これより長いデータ文字列もあるので (特に Strings フィールド。図 2 参照)、このような文字列が切り詰められないことが重要です。実験によると、既定値を 1023 にすれば十分なようです。

図 2 は、Log Parser での CSV イベント ログのインポートによって作成されたスキーマを示しています。

図 2 Log Parser での CSV イベント ログのインポートに使用されたスキーマ

データを準備する

DirectAccess 正常性レポートを作成する際、必要なデータの抽出に関して主な課題となるのは、イベント ログの CSV 形式がデータ文字列をベースとしていることです。GUI のコンテキストでは、データは各データ フィールドの意味を説明する固定文字列にまとめられます。データ文字列には、ユーザー名、コンピューター名、ポリシー グループ名、IP アドレスなど、DirectAccess 正常性レポートに役立つ内容はすべて含まれます。

データ文字列は連結されて 1 つの CSV フィールドにまとめられ、最終的には 1 つの SQL 列 (これも文字列です) にまとめられます。各文字列間の区切りには、"|" 記号が使用されます。データを SQL にインポートする前またはインポートした直後に文字列を分割するという方法もありますが、私たちは、SQL にインポートされた後に文字列を解析し、必要な少数の特定のデータ項目を抽出して、別々の SQL テーブルにこうした項目のデータを設定することにしました。

T-SQL で文字列パターン マッチングを使用してこの作業を行うのは困難です。私たちは、この方法の代わりに、以前の MSDN マガジンの記事「正規表現によるパターン マッチングとデータ抽出の簡略化」で紹介されているアプローチを使用しました。そのアプローチとは、正規表現ベースのパターン マッチング専用に C# を使用して SQL 用のユーザー定義関数を実装するというものです。

私たちは、Visual Studio 2008 を使用して、この記事で紹介されていた手順をほぼそのまま実行しました。ただし、この記事の他に、Visual Studio で最初の SQL と CLR の統合が機能するようにする方法に関するドキュメントも参考にしました。また、正規表現 (RegEx) は本質的に複雑なので、正規表現に関するドキュメントも参考になりました。その中でも特に、グループ化に関するセクションが参考になりました。MSDN マガジンの記事に出てきたサンプル コードでは、グループ化のアプローチが使用されているためです。

次のコード サンプルは、SELECT ステートメントに RegEx 機能を公開する SQL ユーザー定義関数のソース コードを示しています。関数の名前は以前の MSDN マガジンの記事と同じで、RegexGroup です。入力値が NULL かどうかチェックできるように、関数本体の最初の 2 行で、この関数に 1 つ変更を加えました。(ここで説明されている) SQL ヘルパー テーブル列のいくつかには NULL 値が格納されているため、この 2 行を追加する前は、数多くの例外が発生していました。

usingSystem;

usingSystem.Data;

usingSystem.Data.SqlClient;

usingSystem.Data.SqlTypes;

usingMicrosoft.SqlServer.Server;

usingSystem.Text.RegularExpressions;

publicpartialclassUserDefinedFunctions

{

    [Microsoft.SqlServer.Server.SqlFunction]

publicstaticSqlChars RegexGroup(

SqlChars input, SqlString pattern, SqlString name)

{

if (true == input.IsNull)

returnSqlChars.Null;

Regex regex = newRegex(pattern.Value, Options);

Match match = regex.Match(newstring(input.Value));

returnmatch.Success ?

newSqlChars(match.Groups[name.Value].Value) : SqlChars.Null;

}

};

以下の SQL コマンドでは、RegEx を使用して最初のデータ セットから抽出された文字列で構成された、2 つのヘルパー テーブルを作成し、このテーブルにデータを設定します。

/* Create the User-Computer-Address mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE UserComputerAndAddr
(
[RowN] int null,
[UserName] varchar(1023) null,
[ComputerName] varchar(1023) null,
[Address] varchar(1023) null
)

/* Populate the User-Computer-Address table */
/* This step should only be performed once per data set */
INSERT INTO UserComputerAndAddr(RowN, UserName, ComputerName, Address)
SELECT RowNumber,
    dbo.RegexGroup([Strings],N'(?<un>[0-9a-zA-Z]+)@redmond.corp.microsoft.com',N'un'),
    dbo.RegexGroup([Strings],N'(?<machine>[0-9a-zA-Z\-]+)(?<!CO1RED-TPM-01)\$@redmond.corp.microsoft.com',N'machine'),
    dbo.RegexGroup([Strings],N'(?<ipv6addr>[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4})',N'ipv6addr')
FROM [NapDa].[dbo].[DaSasTable]

/* Create the Computer-Health mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE ComputerHealth
(
[RowN] int null,
[TimeGenerated] datetime null,
[EventType] int null,
[ComputerName] varchar(1023) null
)

/* Populate the Computer-Health mapping table */
/* This step should only be performed once per data set */
INSERT INTO ComputerHealth(RowN, TimeGenerated, EventType, ComputerName)
SELECT RowNumber,
    TimeGenerated,
    EventType,
    dbo.RegexGroup([Strings],N'REDMOND\\(?<machine>[0-9a-zA-Z\-]+)\$',N'machine')
FROM [NapDa].[dbo].[HraSystemEventsTable]

最初の SELECT ステートメント、および前述の手法で実装された RegexGroup 関数がこのステートメントでどのように使用されているかをよく確認することで、文字列パターンの概要を理解することができます。図 3 は、定義した 3 つの RegEx パターンの詳細を示しています。

図 3 SQL コマンドを使用して定義された 3 つの RegEx パターン

こうした正規表現を組み合わせると、DaSasTable の各行から抽出したユーザー、コンピューター、およびアドレスの情報 (つまり、DirectAccess コンピューターからエクスポートされた IPsec SA イベント) で構成されたテーブルの作成に役立ちます。

UserComputerAndAddr テーブルが作成され、このテーブルにデータが設定されたら、HraSystemEventsTable テーブルの各行のコンピューター名をイベントの種類にマップする 2 つ目のテーブルが作成されます。コンピューター名のパターンを調べると、このログと DirectAccess ログではコンピューター名の形式が異なることがわかります。今回は、REDMOND\dan-dev-1 のような文字列を探しています。図 4 は、EventType フィールドに格納されている可能性のあるイベントの種類の詳細を示しています。

図 4 EventType フィールドに格納されている可能性のあるイベントの種類

この展開の正常性レポートでは、イベントの種類は 0 のみであることが予想されます。NAP が強制モードで使用されているためです。後で示すように、正常な IPsec セキュリティ アソシエーションに基づくフィルター処理も行っています。準拠していないクライアントは、有効な IPsec 証明書を取得して SA を確立することはできなかったはずです。一方、NAP を報告モードで展開した場合は、準拠していないコンピューターも接続していたことがレポートされるでしょう。ネットワークに接続している準拠しているコンピューターと準拠していないコンピューターの比率は、レポートする必要のある重要な統計値です。

注: RegEx の結果の格納にテーブルを使用する場合は、永続的な SQL テーブルを使用することをお勧めします。(次の手順のデモのように) 一時テーブルを使用すると、RegEx クエリの実行速度が遅くなります。

レポートを作成する

正規表現の解析が完了し、ヘルパー テーブルが作成されたので、今度は、正常性レポート自体の作成に取り組むことができます。データが準備できてしまえば、レポート クエリを記述するのは比較的簡単です。

このサンプル レポートの目的は、2010 年 5 月 5 日の午後 3 時から午後 4 時の間に DirectAccess 接続を確立したすべてのユーザーを一覧表示することです。このレポートでは、ユーザー名の他にコンピューター名と正常性状態も一覧表示します。

このようなユーザーを特定するために、まずは、この期間内の成功した (イベントの種類が 8 の) QM SA (イベント カテゴリ 12549) を照会します。IPsec は 2 番目の要素 (ユーザーの資格情報) を使用する認証を要求するように構成されているので、このシナリオでは QM SA イベントが役立ちます。このレポート アプローチを使用することにしたのは、QM SA は、持続期間が比較的短いため (この場合は 1 時間で、非アクティブ タイムアウトは 5 分)、アクセスの監査に役立つからです。それに対して、MM SA ではコンピューターの資格情報しか使用されず、MM SA は既定で 8 時間持続します (ただし、監査が DirectAccess の展開において重要な要素である場合は、MM の有効期間を短縮することをお勧めします)。

残念ながら、QM イベントにはユーザー名もコンピューター名も含まれず、IP アドレスのみが含まれます。IP アドレスをコンピューター名およびユーザー名にマップするには、SQL クエリでいくつかの SELECT ステートメントを使用します。次のクエリ内の最初の SELECT ステートメントは、その期間内に新しい QM SA に出てくるアドレスの一覧を返します。2 つ目の SELECT ステートメントでは、こうしたアドレスを、ログの他の部分でそのアドレスに関連付けられているユーザー名およびコンピューター名にマップします (このユーザー/コンピューター/アドレスの関連付けは、EM SA イベント内で行われています。EM SA イベントには 3 つの値がすべて含まれているので、EM SA イベントはこの作業にとって非常に重要です。IPsec の 2 番目の認証を要求しない場合、この種のレポートを行うことはできません)。

/* The following steps build the report, based on the three imported tables

* plus the two helpers above. These steps can be run any number of times as

* you refine your query.

*/

/* Create a temporary table to populate as the final report */

CREATE TABLE #SaHealthReport
(

[UserName] varchar(1023) null,

[ComputerName] varchar(1023) null,

[HealthEventType] int null

)

/* Run a query to find all IPsec Quick Mode Security Associations established

* within a given period. Populate a temporary table with the client IPv6

* addresses. */

SELECT DISTINCT[Address] INTO #TempAddresses

FROM [NapDa].[dbo].[DaSasTable] JOIN [NapDa].[dbo].[UserComputerAndAddr]

      ON RowN = RowNumber

WHERE [EventType]=8 AND

      [EventCategory]=12549 AND

      ([TimeGenerated] BETWEEN'2010-05-10 15:00:00.000' AND '2010-05-10 16:00:00.000')

/* Map the QM SA addresses to user and computer names and insert those into

* the final report. */

INSERT INTO #SaHealthReport(UserName,ComputerName)

SELECT UserComputerAndAddr.UserName,UserComputerAndAddr.ComputerName

FROM [NapDa].[dbo].[UserComputerAndAddr] JOIN #TempAddresses

      ON #TempAddresses.Address = UserComputerAndAddr.Address

WHERE (UserComputerAndAddr.UserName IS NOT NULL) AND (UserComputerAndAddr.ComputerName IS NOT NULL)

/* Populate the health column of the report. */

UPDATE #SaHealthReport

SET HealthEventType = ComputerHealth.EventType

FROM #SaHealthReport JOIN [NapDa].[dbo].[ComputerHealth]

      ON #SaHealthReport.ComputerName = ComputerHealth.ComputerName

/* Display all rows and columns of the report. */

SELECT DISTINCT *

FROM #SaHealthReport

ここまでは、コンピューターとユーザーの ID 情報はすべて DirectAccess サーバーから取得したものでしたが、SaHealthReport レポート テーブルにデータを設定する作業の最後の手順は、HRA 正常性情報をこうしたコンピューターとユーザーの ID 情報と関連付けることです。こうした ID 情報に HRA サーバーの情報を加えると、ネットワークにリモート接続しているコンピューターが (非準拠であることによって) リスクをもたらしているかどうかを特定できる強力な手段が提供されます。上記の SQL クエリの UPDATE ステートメントをご覧ください。DirectAccess データと HRA データの関連付けは、クライアント コンピューター名を使用することによって実現されています。

図 5 は、完成した正常性レポートで返される可能性のあるサンプル データを示しています。

図 5 完成した正常性レポートのサンプル

いくつかのカスタム スクリプトと LogParser ツールを使用することで、IPsec (DirectAccess を含む) と NAP の展開で比較的簡単にレポートを行うことができます。このアプローチは、企業が、社内であれクラウド内であれ、基幹業務サービスを公開するための、セキュリティで保護されたフレームワークの作成を開始する際に役立ちます。

Dan Griffin は、シアトルを拠点とするソフトウェア セキュリティ コンサルタントです。Dan には、www.jwsecure.com (英語) を通じて連絡を取ることができます。

Lee Walker は、マイクロソフトの社内 IT 部門でテクノロジ アーキテクトを務めており、IPv6、IPsec、NAP、DirectAccess などのテクノロジを専門としています。連絡先は lee.walker@microsoft.com (英語のみ) です。

関連コンテンツ

• Cable Guy: DirectAccess とシン エッジ ネットワーク
• セキュリティ ウォッチ: ID に関する考察 (第 1 部)
• セキュリティ ウォッチ: ID に関する考察 (第 2 部)