特集 : Windows Server 2008

Windows Server 2008 における監査と規制遵守

Rob Campbell、Joel Yoker

概要:

• 高まりつつある規制遵守の重要性
• 環境内の変化について理解する
• セキュリティ イベントの監査に関する課題
• 監査の技術的な側面

情報技術の世界では、絶え間なく変化が起こっています。一般的な IT 組織にとって、環境内で起こっている変化について理解しなければならないという重圧はますます高まっています。IT 環境の複雑さと規模が拡大するにつれ、

管理上の誤りや不慮のデータ漏洩による影響は大きくなっています。現代社会では、そのようなことに対する説明責任が要求されるため、組織は法律に従って、それぞれが管理している情報を保護しなければなりません。

この結果、環境内の変更を監査することが重要な業務になりました。その理由は、監査を行うことで、現在の高度に分散された大規模な IT 環境内の変更について理解し、それらを管理することができるためです。この記事では、ほとんどの組織が直面する一般的な課題、IT の規制遵守と法規制の現状、Windows® での監査に関する基本的な知識、および Windows Server® 2008 と Microsoft® System Center Operations Manager 2007 の監査コレクション サービス (ACS) の機能を利用して包括的な監査戦略を構築する方法について説明します。

監査に関する課題

ニュースの見出しをざっと見ても、データの漏洩が日常的な問題になっていることがわかります。多くの場合、このような事件の責任を負った組織には、法的措置、金銭的損失、および広報活動上の問題が課せられます。データの漏洩に関する問題の影響を軽減するための鍵となるのは、どのような変更が発生したかを説明したり、問題をすばやく特定したりできることです。

たとえば、ある顧客ベースに格納されている個人情報 (PII) を組織で管理しているとします。管理対象のシステムに格納されている情報を保護する方法はいくつかありますが、それらの方法を使用しても、システムは攻撃される可能性があります。適切に監査を行うことで、どのシステムが攻撃を受けたか、およびどのデータが失われた可能性があるかを把握できます。監査を実施しなかった場合、データの損失による影響ははるかに大きくなる可能性があります。この主な理由は、攻撃の規模を見積もる手段がないためです。

ではなぜ、まだ監査を実施していない組織が存在するのでしょうか。実は、ほとんどの組織では、監査の技術的な側面が完全には理解されていません。上層部の経営者はバックアップや復元などの概念は理解しています。しかし、環境内の変更を監査する作業に固有の複雑さを経営者に伝えることは困難です。このため、多くの場合、監査に関する問題は、重大な事件が起こらなければ明らかになりません。たとえば、基本的な監査を実施していても、計画不足が原因で、ある特定の変更を監査するようにシステムが構成されていなければ、その情報は収集されません。

また、監査対象のセキュリティ イベントに関して、IT プロフェッショナルが対応しなければならない課題がいくつかあります。1 つは、現在の大規模なコンピューティング環境ではシステムが分散しているということです。常にいずれかのシステムで変更が発生している可能性があるため、情報の収集や集約は非常に困難です。これは、関連付けというまた別の課題につながります。多くの場合、発生したイベントが実際に何を意味するかを知るには、単一および複数のシステムで発生するイベント間の関係を読み解く必要があります。

また、通常は監査範囲が従来の組織の境界を超えてしまうことも問題となります。さまざまな組織やチームがさまざまな理由から存在しますが、これらの橋渡しをすることが容易ではない場合があります。多くの組織には、ディレクトリ サービス チーム、メッセージング インフラストラクチャ チーム、およびデスクトップ チームが存在しますが、通常はこれらすべての領域をたった 1 つのセキュリティ チームが担当しています。さらに、一部の事業所に組織のセキュリティ担当者が物理的に配置されていない場合があります。たとえば、ブランチ オフィスでは、多くの場合、セキュリティ イベント ログの管理も含めてすべての作業をたった 1 人または数人でこなしています。

また、イベントの量自体も問題です。監査対象のセキュリティ イベントは、イベントに記録される他の種類のイベントと比較して、かなり頻繁に発生します。収集されるイベントの数の多さから考えても、ログを効率的に保全および確認することは困難です。また、現行の法律や法案ではこのような情報を保全する必要性が規定されているため、現在のコンピューティング インフラストラクチャにおいて、この負荷が軽減されることはありません。

これまでの情報へのアクセスの監査についてまとめると、変更を把握 "しようと思った"、セキュリティを確保 "しようとした" という状態であったと言えます。しかし現在は、情報を紛失したり適切な保護対策を実施していない場合、組織と組織の責任者である上層部の経営者に法的な責任が課されるため、IT 管理者は各自の環境に該当する可能性のある法規制について知っておくことが不可欠です。世界的な企業では、国ごとに情報とその保護に関する法規制があるため、問題はさらに複雑です。既存の規制遵守に関する法規制の一部と、それらの規制が IT 組織に要求する対応を図 1 に示します。

Figure 1 IT プロフェッショナルの業務に関連する法規制

このような法的な重圧を考慮すると、IT プロフェッショナルはどのようなことを行う必要があるでしょうか。IT 管理者および技術者は、組織内外に提示できる明確で簡潔な対応策をまとめる必要があります。たとえば、適切な監査戦略を構築する必要があり、そのためには事前対策や投資も必要になります。ここで重要なのは、監査の設計は後からの思い付きになってはいけないということですが、残念ながらこのようなことはよく起こっています。

通常、このような IT に関する課題を解決するには、人、プロセス、およびテクノロジを組み合わせる必要があります。監査の場合、重要なのはプロセスです。したがって、まず基礎を徹底的に学んで、規制遵守に関する組織のニーズと要件を満たすことができるようにします。ではここからは、Windows での監査に関する基本的な知識についていくつか説明した後、Windows Server 2008 と Windows Vista® における変更について説明します。

セキュリティ イベントを監査する

監査対象のイベントは、すべて Windows のセキュリティ イベント ログに記録されます。通常、これらのイベントの内容はすぐに対応できるようなものではなく、基本的には情報の提供を目的としています。各イベントには、発生したアクセスの種類に応じて、簡潔に "成功の監査" または "失敗の監査" と記録されます。これは、色によって問題を特定できるアプリケーション イベント ログやシステム イベント ログとは異なります (ヒント : エラーを確認するには、赤のイベントを参照します)。

セキュリティ イベント ログは、他のイベント ログとは異なり監査対象のイベントが多いため、イベントの内容が目に付かないことが多く、また前述のとおり、セキュリティに関するデータの関連付けも非常に困難になる場合があります。単一のシステムから単純な方法でデータが漏洩した場合でも、問題の解決は困難です。漏洩したデータへのアクセスに使用されたアカウントを特定するには、セキュリティ イベント ログを分析する必要があります。管理者はこのアカウントを見つけるために、ログの内容を細かく確認します。残念ながら、現在の攻撃は非常に高度であり、さまざまな手段や場所を使用して行われることが多いため、被害者がこのような攻撃を分析することは非常に困難です。

これを踏まえて、Windows のセキュリティ イベント ログに情報を記録することを可能にする重要な要素である、監査ポリシーとシステム アクセス制御リスト (SACL) について理解することは重要です。監査ポリシーは、グループ ポリシーまたはローカル セキュリティ ポリシーを通じてローカル コンピュータを構成できる設定であり、アクセスの種類ごとに成功イベントと失敗イベントの収集方法を定義します。以下に示す監査ポリシーの主要なカテゴリは、長年にわたって Windows で使用されています (Windows Server 2008 で提供される "詳細な監査ポリシー" には、さらに多くのカテゴリが含まれています)。

• アカウント ログオン イベントの監査
• アカウント管理の監査
• ディレクトリ サービスのアクセスの監査
• ログオン イベントの監査
• オブジェクト アクセスの監査
• ポリシーの変更の監査
• 特権使用の監査
• プロセス追跡の監査
• システム イベントの監査

通常、監査ポリシーとそれに関連するカテゴリを定義する必要があることは、ほとんどの IT 組織でよく理解されていますが、監査ポリシーはソリューションの一部に過ぎません。SACL も包括的な監査計画の実装において重要な役割を果たします。ディレクトリ サービスのアクセスの監査とオブジェクト アクセスの監査という 2 つの監査ポリシーのカテゴリは、完全に SACL に依存してセキュリティ イベント ログに情報を返します。では、SACL とは厳密に言うとどのようなものなのでしょうか。

各オブジェクト (ファイル、レジストリ、またはディレクトリ サービス) には、1 つまたは複数のアクセス制御エントリ (ACE) が設定されたアクセス制御リスト (ACL) が含まれています。ACL には、随意アクセス制御リスト (DACL) と SACL の 2 種類があります (SACL は、セキュリティ保護されたオブジェクトへのアクセスの試行をログに記録するための設定を定義します)。SACL の各 ACE では、セキュリティ イベント ログに記録されるトラスティに応じて、アクセスの種類が指定されます。ACE は、特定のオブジェクトへのアクセスの成功と失敗のいずれかまたは両方をログに記録するかどうかを定義します。図 2 は、あるオブジェクトに SACL を使用して、特定のアクセスに関するイベントを生成する際の設定を示しています。

図 2** オブジェクトに対する SACL の使用 **(画像を拡大するには、ここをクリックします)

監査ポリシーと SACL の関係を理解することは非常に重要です。この理由は、環境内の変更に関する "正しい" 監査対象のイベントをキャプチャするために、これらを構成する必要があるためです。前述のとおり、ディレクトリ サービスのアクセスの監査とオブジェクト アクセスの監査という監査ポリシーによって行われる操作は、それぞれのカテゴリに該当する監査結果を生成してセキュリティ イベント ログに記録することのみですが、オブジェクトの SACL に監査用の ACE が構成されていなければイベントは生成されません。これらが構成されると、セキュリティ イベントが Windows ローカル セキュリティ機関 (LSA) によって生成され、セキュリティ イベント ログに書き込まれます。

イベントは 2 つの領域から構成されています。1 つはイベント識別子 (イベント ID) ごとに事前に定義された静的な情報であるヘッダー、もう 1 つはイベントごとに異なる説明を提供する動的な情報である本文です。図 3 は、Windows Server 2008 のセキュリティ イベントで、この 2 つの領域がどのように表示されるかを示しています。これらのイベントの構成要素について理解することは、あらゆる監査プロジェクトの分析フェーズで重要になります。また、どのように ACS などのツールに情報が返されるかという点でも興味深い部分です。

図 3** 監査対象イベントのヘッダーと本文 **(画像を拡大するには、ここをクリックします)

Windows Eventing 6.0

問題を把握することはできましたが、組織がこれらの課題に取り組む際に Windows Server 2008 はどのように役立つのでしょうか。Windows Server 2008 は、セキュリティ イベントを管理するための環境を大幅に改善する Windows Eventing 6.0 イベント サブシステムという新機能が初めて搭載されたサーバー リリースです。ここでは Windows Server 2008 を中心に取り上げますが、この新機能の 95% は Windows Vista にも搭載されています。

Windows Eventing 6.0 で最初に気が付くことの 1 つは、新しくなったユーザー インターフェイスです。Microsoft 管理コンソール (MMC) 用の新しいイベント ビューア スナップインでは、非常に便利な概要ページ、柔軟性の高いカスタム ビュー、および大幅に強化された説明テキストが提供されます。エンド ユーザーやシステム管理者はこれらのインターフェイスを使用して、イベントに関する情報を参照したり、イベント ログの重要なオプションをイベント ビューアから直接構成できます。

セキュリティに関するイベント ログ内のデータに影響を与えることが多かった重要な問題として、データの保存が挙げられます。これまでのイベント ログ サブシステム (すべてのログを含む) では、スケーラビリティが制限されていました。つまり、この制限を超えると、サブシステム全体でイベントのログ記録が停止されました。Windows Eventing 6.0 ではこの問題が解消されており、利用可能なディスク領域による制限のみが課せられます。ただし、フィルタ処理を行う際に個々のログ エントリを確認する必要があるため、イベント ログに大量のエントリが記録された場合は、分析作業が面倒になる可能性があります。したがって、ログのサイズは管理しやすい規模に抑えておく必要があるでしょう。

このため、当然 IT 管理者は、イベント ログのアーカイブに関する計画を多数のシステムに対して作成する必要があります。Windows Eventing 6.0 では、ローカル サーバー レベルでこの作業を行う際に役立つ、[イベントを上書きしないでログをアーカイブする] というオプションが提供されます。Windows の以前のバージョンでは、AutoBackupLogFiles レジストリ値を直接変更しなければ、このオプションは設定できませんでした。これにより、ローカルのログをアーカイブするためのメカニズムは提供されますが、これらのファイルを長期にわたって管理するためのソリューションは提供されず、複数のシステムを対象とした集約に関する問題も解決されません。このような問題を解決するための完全なソリューションは、監査コレクション サービスによって提供されます。これについては後ほど説明します。

新しいインターフェイスの紹介は、ほんのさわりです。Windows Eventing 6.0 の真価は、新しい Windows イベント ログ サービスと、基盤となる XML ベースのエンジンにあります。これらのコンポーネントこそが、強化されたスケーラビリティ、アクセシビリティ、および管理オプションを提供します。イベントは、柔軟性の高い XML 形式で格納されるようになりました。このため、カスタム ソリューションを作成してイベントをネイティブに参照できます。

Windows Eventing 6.0 では、管理作業を特定のイベントに関連付ける機能も提供されます。この機能は、Windows イベント コレクタ サービスとタスク スケジューラを統合してタスク ベースのイベント処理を提供することによって実現されています。これにより、今まで時間ベースでしかイベントをトリガできなかったタスク スケジューラにとって新しいパラダイムが提供されます。[タスクをこのイベントに添付] (Windows Server 2008 のイベント ビューアに表示されたイベントのコンテキスト メニューから使用できます) をクリックして起動できるウィザードを使用すると、特定のイベントがログに記録されたときに、プログラムの起動、電子メールの送信、またはメッセージの表示を簡単に行うことができます。これは、特定のセキュリティ イベントに分離できる特定の操作が環境内で発生したかどうかを識別する際に非常に役立つ場合があります。たとえば、ドメイン コントローラで、スキーマの更新を許可するかどうかを制御するレジストリ キーの変更を監査している場合、特定のセキュリティ管理者に電子メールを送信してこのレジストリ キーが変更されたことを通知するタスクを作成できます。

多数のイベント エントリを収集して格納できるようになっただけでなく、どのイベントをイベント ログに記録するかをより細かく制御できるようになりました。これは、詳細な監査ポリシー (GAP) という新機能によって実現されます。Windows の以前のバージョンでは、大まかな 9 種類の監査カテゴリしか提供されなかったため、過剰な数のイベントが記録されることがよくありました。これらの大まかなカテゴリを 50 種類のより細かいサブカテゴリで制御できるようになりました。各サブカテゴリは、それぞれ関連するイベントのサブセットを表しています。

これにより、重要でない情報をフィルタ処理によってイベント ログから除外できます。ただし、カテゴリ レベルではその情報を引き続き参照できます。たとえば、特定のシステム上でレジストリの変更のみを監視し、ファイル システムの変更は監視しなかった場合、これまではオブジェクト アクセスの監査カテゴリで成功または失敗を報告することしかできませんでした。GAP を使用すると、ファイル システム、証明書サービス、ファイル共有などのサブカテゴリに対してフィルタ処理を実行し、レジストリ サブカテゴリのイベントのみを報告することができます。Windows Server 2008 システムで GAP サブカテゴリを使用するには、昇格したコマンド プロンプトで auditpol コマンドを実行する必要があります。使用できる GAP サブカテゴリの一覧を表示するには、次のコマンドを入力します。

auditpol /list /subcategory:*

システム上で構成されている GAP サブカテゴリの一覧を表示するには、次のコマンドを入力します。

auditpol /get /category:*

GAP は標準のグループ ポリシー ユーザー インターフェイスから構成することはできないため、auditpol.exe を使用して管理する必要があることに注意してください。Windows Server 2008 システムと Windows Vista システムでグループ ポリシーを使用して GAP の設定を展開する方法については、サポート技術情報の記事 (support.microsoft.com/kb/921469) を参照してください。

Windows Server 2008 では、各特性の変更前の値と変更後の値をセキュリティ イベント ログにキャプチャできます。Windows の以前のバージョンの監査サブシステムでは、変更された Active Directory® オブジェクトの属性またはレジストリの値のみがログに記録され、その属性の変更前と変更後の値は記録されませんでした。この新機能は、Active Directory ドメイン サービス、Active Directory ライトウェイト ディレクトリ サービス、および Windows レジストリで提供されます。"レジストリ" または "Directory Service Changes" (ディレクトリ サービスの変更) サブカテゴリで成功の監査または失敗の監査を有効にし、関連する SACL を設定すると、これらのオブジェクトが操作されたときに、詳細なイベントがイベント ログに記録されます。この動作を有効にするには、次の auditpol コマンドを使用します。

auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service     
    Changes" /success:enable

レジストリの変更は、図 4 のようにイベント ID 4657 として記録されます。

図 4** レジストリの変更前と変更後の情報 **(画像を拡大するには、ここをクリックします)

この機能は、Active Directory オブジェクトの変更を追跡する場合に特に役立ちます。ディレクトリ サービスの変更は、図 5 のようにイベント ID 5136 が割り当てられた一組のイベントとして記録されます。各イベントの本文には、ディレクトリ サービスのオブジェクト、属性、および操作が記述されています。既にデータが設定されている属性が変更された場合は、"Value Deleted" (値が削除されました) と "Value Added" (値が追加されました) という 2 つの操作が記録されます。値が設定されていない属性の場合は、その属性にデータが書き込まれた時点で "Value Added" (値が追加されました) という操作のみが記録されます。たとえば、telephoneNumber などのユーザー オブジェクトの属性に対する変更操作が実行され、この操作が成功した場合、Active Directory は、詳細なイベント ログ エントリにこの属性の変更前と変更後の値を記録します。

図 5** ディレクトリ サービスの変更前と変更後のイベント **(画像を拡大するには、ここをクリックします)

新しいオブジェクトが作成された場合、オブジェクトの作成時に設定された属性値がログに記録されます。オブジェクトがドメイン内で移動された場合、移動前と移動後の場所が (識別名として) ログに記録されます。この変更前と変更後の情報を記録する機能は、適切な監査ポリシーの設定を実装すれば、既定で有効になります。社員の ID 番号の変更など、機密情報として扱う属性がある場合は、簡単にスキーマを変更することで、その属性を明示的に除外できます。スキーマ内の属性の searchFlags プロパティを 0x100 (値は 256 -NEVER_AUDIT_VALUE) に変更すると (図 6 参照)、この属性が変更されてもディレクトリ サービスの変更に関するイベントは記録されません。

図 6** ディレクトリ サービスの変更に関するイベントの記録対象から除外された属性 **(画像を拡大するには、ここをクリックします)

また、Windows Eventing 6.0 で提供されるすばらしい新機能の 1 つに、イベント サブスクリプションがあります。前述のとおり、イベント ログにアクセスして内容を確認することは、重要なシステム管理作業の 1 つです。この新しいイベント サブスクリプション機能を使用すると、システム間で直接イベントを転送できます。イベント サブスクリプションは、イベントを収集するイベント コレクタと、特定のホストにイベントを転送するように構成されたイベント ソースから構成されています。イベントを使用する機能は Windows イベント コレクタ サービス (Windows Eventing 6.0 の新機能) によって提供され、サブスクライバ機能は Windows イベント ログ サービスに組み込まれています。コレクタは、さまざまなイベント ソース (Windows Server 2008 システムまたは Windows Vista システム) からイベントを収集するように構成できます。

イベント ソースから収集されたすべてのデータは、専用のイベント ログである "転送されたイベント" (ForwardedEvents.evtx) に記録され、コレクタのイベント ログ サービスによって管理されます。エンドポイントは両方とも (コレクタとソース) 構成する必要がありますが、この作業は自動化できます (ソースで winrm quickconfig –q、コレクタで wecutil qc /q を実行します)。このイベント サブスクリプション機能は、企業向けに設計された機能ではなく、外部データベースにイベントを送信するためのシステムを置き換えることを目的として設計された機能でもありません。

この機能を活用できる例としては、小規模な Web ファームが挙げられます。たとえば、特定の Web サイトに関連付けられた少数のシステム (Web サーバーと SQL サーバーが含まれています) があるとします。新しいイベント サブスクリプション機能を使用すると、これらのシステムのセキュリティ イベント ログに記録された情報を 1 つのシステム上に統合できます。さらに規模の大きい環境の場合、通常はイベント ログを統合するためのより高度なツールセットが必要になります。

監査コレクション サービス

Windows Server 2008 で提供されるすべての新機能を考慮すると、セキュリティ イベント ログに記録された情報を長期にわたって管理し、それらの情報をアーカイブするために最も必要なのは、監査情報を格納するための一元的なデータベースです。監査コレクション サービスは、System Center Operations Manager 2007 の中核となる機能の 1 つです。このサービスは、セキュリティ イベントに関するデータの転送、収集、保存、および分析メカニズムを提供します。セキュリティ イベントは、ほぼリアルタイムで収集され、一元管理された SQL リポジトリに格納されます。また、ACS を使用すると、実際の監査対象のシステムに物理的にアクセスする必要がなくなるため、最小限の特権を使用して情報にアクセスし、それらを監査できます。では、ACS のしくみについて説明しましょう。

ACS は 3 つの主要コンポーネントから構成されます。1 つ目のフォワーダは、イベント ログのデータをクライアントから ACS インフラストラクチャに転送する Operations Manager エージェントの一部です。フォワーダはデータを 2 つ目のコンポーネントであるコレクタに転送します。コレクタはサーバー側のリスナです。ACS のフォワーダは、TCP ポート 51909 を使用して、関連付けられているコレクタに接続し、そのコネクタとの間でセキュリティが確保された通信を行います。イベント ログのデータは、転送される前に XML に正規化されます。つまり、余分な情報が削除されます。イベントの情報は、イベント固有のヘッダーと本文の情報に基づいて、マップされているフィールドにまとめられます。コレクタに届いた情報は、3 つ目のコンポーネントである ACS データベースに送信されます。これが長期間にわたってセキュリティ イベントの情報を保存するためのリポジトリになります。一度格納された情報は、SQL クエリを使用して直接検索したり、SQL Server® Reporting Services を使用して HTML 形式で表示したりできます。ACS では、3 つの既定のビューが提供されます (図 7 参照)。

Figure 7 ACS のビュー

パフォーマンスという観点から見ると、1 つの ACS コレクタが処理できるイベントの最大数は 1 秒あたり 100,000 個、連続して処理できるイベントの最大数は 1 秒あたり 2,500 個です。また、計画という観点から見ると、既定の監査ポリシーの設定に基づいて、1 つの ACS コレクタで最大 150 台のドメイン コントローラ、3,000 台のメンバ サーバー、または 20,000 台のワークステーションをサポートできます。実際の環境に近いシナリオで行ったテストの結果としては、約 150 台のドメイン コントローラを使用した場合で、1 秒あたり最大 140 個のイベント、ピーク時は平均で 1 時間あたり 500,000 個のイベントが発生しました。わずか 14 日間 (ACS の保存に関する設定の既定値) で、150 GB を超えるセキュリティ イベントのデータが SQL Server データベースに格納されました。より多くのイベントを監査するように監査ポリシーとそのポリシーに関連付けられている SACL を構成した場合は、さらに多くのデータ (1 時間あたり、1 日あたり、および全体) が生成されます。

ここでの重要なポイントは、通常の大規模な企業環境でこれほどの量のデータが生成された場合、人間がすべてのイベントを確認することはほぼ不可能であるということです。しかし、この数字に怖気づいてはいけません。環境内で発生している変更について理解するには、大量のデータを分析することが不可欠です。

そのときこそ、ACS の出番です。SQL Server Reporting Services と ACS を使用すると、通常はセキュリティ イベント ログ内に埋もれてしまう問題を、アプリケーション イベント ログの色分けされたイベントと同じように、簡単に識別できるようになります。ACS には一連の既定のレポートが含まれていますが、これらのレポートは各環境のニーズに合わせて簡単に拡張できます。

次のようなシナリオを考えてみましょう。環境内に存在する外部の信頼の機密性を把握するために、Active Directory の信頼の作成に関する詳細なレポートを作成するよう経営陣から依頼されたとします。調査を行ったところ、信頼を作成すると、Active Directory の特定のドメイン名前付けコンテキスト内の cn=System コンテナに trustedDomain オブジェクトが作成されることがわかりました。信頼されたドメインのオブジェクトが正常に作成されたかどうかを監査するようにこのコンテナの SACL を編集すると、このようなオブジェクトが作成されるたびに、セキュリティ イベントをキャプチャできるようになりました。このイベントは、信頼の作成が実行された DC のセキュリティ イベント ログにイベント 566 として記録されます。次のような単純な SQL クエリを使用すると、ACS からこの情報を取得できます。

select * from AdtServer.dvAll 
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc

この情報をレポートにまとめるには、SQL Server 2005 Reporting Services に含まれている Visual Studio® 2005 のバージョンを使用します。このバージョンは、特にレポートの作成を目的として設計されています。ウィザードを完了することで、図 8 のようなレポートを簡単に作成できます。また、セキュリティ イベント ログに記録される環境内の変更に関する情報は、同じように見栄えの良いレポートにまとめることができます。

図 8** ACS レポートの例 **(画像を拡大するには、ここをクリックします)

監査計画を作成する

監査に関する問題だけでなく、監査の法的および技術的な側面も理解できたため、次は IT 管理者が組織の "監査計画" の作成にどのように取り組むべきかを考えてみましょう。ほとんどの作業と同じように、包括的な監査ポリシーを作成する作業も複数の手順から構成されます。最初の手順は、監査対象を決定することです。これを行うには、環境を分析し、監査結果を生成するイベントと変更の種類を決定します。たとえば、アカウントのロックアウト、機密性の高いグループの変更、信頼の作成などの単純なものや、環境内で使用しているアプリケーションの構成要素の変更などの複雑なものがあります。ここで重要なことは、"何" を監査するかを決定する際に、経営陣も話し合いに参加する必要があるということです。この作業の内容は文書化し、大きな問題が起きた後だけでなく、定期的に見直すようにします。

2 番目の手順は、特定の変更の監査に関する情報をどのようにセキュリティ イベントとして返すかを決定することです。監査に関する情報は、暗号化されていて簡単には理解できない場合があります。監査計画を実装する前に、セキュリティ イベントとさまざまな操作との間の関連付けを行い、各セキュリティ イベントが意味している状態を理解できるようにする必要があります。問題が発生して初めてイベントと操作の関係を理解するということがないようにしてください。

3 番目の手順は、監査ポリシーと SACL を実装して、監査計画を展開することです。前述のとおり、ディレクトリ、ファイル システム、およびレジストリの監査ポリシーの設定 (セキュリティ イベントの生成を可能にします) と SACL (関連付けられている操作の監査結果の生成を可能にします) を定義して、各領域で発生した変更を把握する必要があります。

これらの手順が完了したら、最後の 4 番目の手順として、収集、トリガ、および分析手段を実装します。組織の規模とニーズによっては、Windows Server 2008 に組み込まれている機能だけで対応できる場合もあれば、System Center Operations Manager の監査コレクション サービス機能などの高度なソリューションを使用して対応することが必要になる場合もあります。ほとんどの組織は、SACL を定義せずに監査ポリシーのみを設定するという間違いを犯しがちです。最後の手順は、レポートを作成して組織内の関係者がデータを共有するためのテクノロジ ソリューションを実装することです。前述のとおり、ほとんどの組織にはセキュリティの担当者や部署が既に存在するため、監査計画は既存の組織構成を活かして作成する必要があります。この最後の手順で重要なことは、情報を収集した後、それらの情報を、環境内の変更について理解する必要がある関係者全員にわかりやすい形で提供することです。

ほとんどの IT 組織は、包括的な監査計画を必要とするような重大な出来事が実際に起こらない限り、そのような計画の作成を検討しようともしません。Windows Server 2008 では、これまでのプラットフォームと比較して、セキュリティ イベントに関するデータの収集および分析メカニズムが強化されています。ACS などの高度な収集およびレポート テクノロジを使用すると、これまでイベントの量の多さと分散した構成が原因であいまいになっていた問題が浮き彫りになるため、このような問題につながる変更をすばやく特定できます。

IT に関するその他の多くの問題と同じように、プロセスは最大の課題です。IT 管理者は、発生する問題を予測するために、常に新たな構成と分析を行う必要があります。したがって、各環境の要件と Windows プラットフォームの機能について理解を深めることで、課題に真正面から取り組むことができるようになります。皆さんの健闘を祈っています。

Rob Campbell、Joel Yoker Rob Campbell は、マイクロソフトの連邦政府チームのシニア テクニカル スペシャリスト、Joel Yoker は同チームのシニア コンサルタントです。米国連邦政府の顧客向けにセキュリティ ソリューションを開発して展開することを専門としています。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.