Active Directory監査：目標、通常の監査システムの欠点、およびそれらを克服する方法

親愛なるハブロビテス、

MVPであるドンジョーンズの本の断片をご紹介します。MVPは、タイトルを付けられた専門家であり、米国で非常に人気のある著者であり、ロシア語に翻訳されています。



認証、承認、監査の3つの「A」Active Directoryセキュリティ（AD）があります。 この投稿では、AD監査専用のDon Jonesの著書Active Directory Troubleshooting、Auditing、and Best Practicesの翻訳を引用します。

スタッフ監査ツールの目的

監査の目的は非常に簡単です。だれでも行うことをすべて追跡することです。 ADのコンテキストでは、これは、グループメンバーシップの変更やユーザーアカウントのロック解除など、すべての特権の使用を追跡する必要があることを意味します。 また、ログインの成功や失敗などのユーザーアクションを記録する必要があることも意味します。 もっと詳しく見てみましょう。Windowsの場合、監査にはファイルとフォルダーへのアクセス、およびファイルのアクセス許可の変更も含まれます。



監査目標は、オペレーティングシステムの監査アーキテクチャの一部として達成された目標とは異なる場合があります。 Windowsで使用されている監査システム（ファイルシステムアーキテクチャのコピーであるADを含む）は、Windows NTが登場した90年代前半から私たちに届いたことを思い出してください。 同時に、Microsoftは、Exchange、SQL Server、SharePoint、およびその他のビジネスプラットフォームを実行する数千のファイルサーバー、数百のドメインコントローラー、および数千の他のサーバーを持つ組織があることを想像できませんでした。 以下では、標準のWindows監査ツールは、大規模なインフラストラクチャや中規模企業でも必ずしもスケーラブルではないことを検討します。 ITインフラストラクチャのすべてのイベントを監査システムでキャプチャしたい場合がありますが、これによりパフォーマンス、管理、さらにはロジスティクスの問題が発生する可能性があります。 したがって、ITインフラストラクチャで発生するすべてを監査し、通常の手段で達成できることを確認することが目標であると想定しましょう。

スタッフ監査システム

アクセス許可はアクセス制御リスト（DACL）に適用されます。 各DACLは、1つ以上のアクセス制御要素（ACE）で構成されます。 このような各要素には、ユーザーまたはグループに関連する特定の許可セットの許可または禁止が含まれています。 DACLはモデル3 Aの「承認」の一部です。ADはユーザーを認証し、一意のセキュリティ識別子（SID）を含むセキュリティトークンを提供します。 このSIDは、アクセス制御リスト（DACL）のACEと比較され、これらのリソースにアクセスするときに持っている権限を判断します。

監査も同様に機能します。 オブジェクトアクセス制御リスト（SACL）は、1つ以上のエントリで構成されます。 各エントリは、ユーザーまたはグループによって実行される特定のアクティビティの特定のアクションを示します。 SACLはファイルやディレクトリオブジェクトなどの特定のリソースにバインドされ、特定のアクションがリソースで実行されるとログに記録されます。 デフォルトでは、タイプ「成功」および/または「失敗」のアクションをログに記録することができます。 これは、誰かが許可を正常に使用したとき、または許可しようとしたときに拒否されたときに、ジャーナルに記録することを選択できることを意味します。 図1は、ADのSACL構成を示しています。 ご覧のとおり、このリソース（ユニットドメインコントローラー）は、「Everyone」グループのメンバーの成功したアクションのいくつかのタイプが記録されるように構成されています。 つまり、誰かがこれらのアクションを正常に実行すると、ジャーナルエントリが作成されます。





図1：ADのSACL。



監査の対象となるアクションは、使用するリソースによって異なります。 たとえば、図2はファイルシステムのSACLを示しており、さまざまな種類のアクションが利用できることがわかります。





図2：SACLファイルシステム。



ここでは、たとえば、フォルダの作成、属性の読み取り、ファイルの削除など、監査の対象を選択できます。 したがって、各リソースは独自のSACLを持つことができます。 実際には、ほとんどの人がかなり高い階層レベルでSACLを割り当て、それによってこれらの設定が継承を通じて下位レベルのオブジェクトに伝播できるようにします。 したがって、SACLは比較的少数の場所で管理されます。 ただし、サーバーとメインシステムごとに少なくとも1つ設定する必要があります。 これはどういう意味ですか：各サーバーには、少なくとも各論理ドライブのルートにあるオブジェクト用の独自のアクセス制御リストが必要です。ADルートなどには個別のリストが必要です。

他の製品はこのスキームに該当する場合があります。 そして、彼らは落ちないかもしれません。 たとえば、Exchange Serverは監査に同様の構造を使用しますが、SQL ServerとSharePointは使用しません。 ただし、ここではADのみを検討しています。

監査が実行されるように構成されているアクションが実行されると、Windowsは監査レコードを生成します。 このようなエントリはすべて、セキュリティイベントログに格納されます（図3を参照）。このようなログの問題は、すべてのイベントがそこに到達することです。 すべてのイベントを1か所に保存しておくのは良いことのように思えますが、問題は、そこから個別のレコードを抽出する必要がある場合に問題になることです。 繰り返しになりますが、これはMicrosoftがActive Directory監査システムについてかなり狭い視野を持っているという事実によるものです。





図 3：セキュリティイベントログ。



各Windowsサーバーには、ドメインコントローラーを含む独自のセキュリティイベントログがあります。 ADのオブジェクトのアクセス制御リストはどのドメインコントローラーでも構成でき、その後残りにレプリケートできますが、このアクションを処理するドメインコントローラーのみがそれに関するログエントリを作成します。 その結果、監査ポリシーは中央で構成されますが、監査ログは非常に分散しています。

図4.は、これらの監査レコードの外観を示しています。 多くの場合、未加工のセキュリティ識別子やその他の非自明な情報が含まれています。 この例は、ネイティブKerberosプロトコルを使用して処理された成功したドメイン接続を示しています。 この例では、ユーザー名とドメインは空白ですが、通常は入力されています。





図4：監査レコードの例。



時間が経つにつれて、Microsoftは、非常に多くの情報を含む1つのジャーナルのみの存在に関連する問題を解決し始めました。 Windows VistaおよびWindows Server 2008では、並列イベントログアーキテクチャが導入され、各製品またはテクノロジの独自のログを管理するプロセスが容易になりました。 常に可能でした-アプリケーション、システム、およびセキュリティログは、たとえばディレクトリサービスログで補足されました。 しかし、この新しいアーキテクチャは、いくつかの理由により全体論的になりました。 図5は、古いマガジンと新しいマガジンを示しています。





図5：新旧の雑誌



アクセス制御の差分アクセスリスト（DACL）とは異なり、オブジェクトアクセス制御リスト（SACL）はオペレーティングシステムによってすぐには使用されません。 SACLは、どのアクティビティが監査されるかを単に示します。 イベントがログに記録されるように、監査システム自体も有効にする必要があります。 図6は、これがGPOで通常構成されている場所を示しています。

ほとんどの組織は、すべてのドメインコントローラーまたはドメイン内のすべてのサーバーに適用するなど、上位レベルのGPOで監査を構成します。 指定されたGPOは、ログインイベント/接続、アカウント管理アクション、ADへのアクセスなどの監査の有効化を含む監査ポリシーの設定を指します。 目的の監査イベントを生成するには、SACLリソースなどの監査ポリシーを構成する必要があります。





図 6：GPOで監査を構成します。



ここで注意する必要があります。 結果を考慮せずに、すべてのイベントの監査を含めたいとは思わない。 ドメインコントローラーは毎分数千の接続イベントを生成できます（たとえば、全員が午前中にコンピューターにログオンしたときなど）。非常に多くのイベントを作成するには処理能力が必要です。 これらすべてのイベントの監査が本当に必要な場合は、負荷に対処するためにドメインコントローラーのサイズを増やす必要があります。 ファイルサーバーについても同じことを行う必要があります。ファイルへの正常なアクセスに関するすべてのイベントがログに記録される場合は、負荷に対処するために計算能力を高める必要があります。

非常に多くのイベントを作成すると、イベントログが非常に深刻に「詰まる」可能性があります。 図7に示すように、監査ポリシーを適切に計画されたイベントログポリシーと組み合わせ、イベントログのサイズ、ロールバックアクション、およびその他の設定を組み合わせて、システムの負荷の一貫性を確保する必要があります。





図7：GPOでのイベントログの構成。



いっぱいになったときに上書きされると落ち着くことができるアプリケーションログとは異なり、重要な情報が失われる可能性があるため、セキュリティログでこれを許可することはできません。 したがって、適切なログサイズを設定し、ログの負荷に応じて定期的にログをアーカイブおよびクリアするためのルーチンを設定する必要があります。

通常、通常のWindowsイベントログが批判されるのは、非常に分散しているということです。 たとえば、管理者は1つのドメインコントローラーのグループメンバーシップを変更し、2番目のドメインコントローラーに接続してこのグループのアカウントを使用し、3番目のコントローラーに接続してこのグループメンバーシップをリセットできます。 3つのイベントはすべて3つの異なるセキュリティイベントログに記録されるため、これらのイベント間の関係を確立するプロセスが複雑になります。

MicrosoftがWindows Server 2008でこの問題に対して提案したソリューションは、イベントログの転送でした。 図8は、個々のサーバーが中央サーバーにイベントを転送する方法を示しています。中央サーバーは、独自のログにすべてのイベントを収集します。





図 8：イベントログの転送。



前述のように、この機能はグループポリシーで設定できるため、一元管理されます。 このアプローチにはまだ重大な欠点があります。これについてはさらに説明します。

これが標準監査システムの構築方法です。 ここで、組織がこのシステムをどのように使用するか、および高度な機能が必要な場所について説明しましょう。

変更を監査するための一般的なビジネス目標

90年代とは異なり、Windows NTが開発されたとき、今日のほとんどの企業は特定のセキュリティポリシーの対象となっています。 多くの場合、セキュリティポリシーが規制要件と立法行為への準拠も意味する場合。 これらの要件には、ITインフラストラクチャで発生するすべての成功したアクティビティと失敗したアクティビティを監査し、大量のトラフィックを生成する義務が含まれる場合があります。

また、アクションが監査レコードに記録されているユーザー（管理者を含む）がイベントログからエントリを削除できないことも重要です。 また、組織は、イベントログエントリの検索、フィルタリング、およびレポートを可能にしたいと考えています。 たとえば、監査人は、AD監査ポリシー構成の変更に対応する監査レコードを確認し、これらのイベントを承認済みのアクションと関連付けたいと考えていました。 これにより、ADには、合意され文書化された変更のみがあることがわかります。 また、組織は社内の監査ツールを使用して問題を解決する必要があります。 ITインフラストラクチャで何か問題が発生した場合、「何が変わったのか」という質問に対する答えがあれば、問題をすばやく解決できます。監査ログは、この質問に対する答えをすばやく効率的に見つけるのに役立ちます。 それでは、通常の監査ツールの欠点は何ですか？

通常の監査ツールの欠点

残念ながら、フルタイムの監査システムはそれ自体があまりよく証明されていません。 結局のところ、これはマイクロソフトのせいではありません。結局のところ、彼らの仕事はビジネスニーズを予測することではなく、特定のビジネスニーズを満たすソフトウェアを他の企業が開発できるプラットフォームを提供することです。 それは彼らがしたことです。 フルタイム監査システムは、追加のプログラムを購入する余裕がほとんどない小規模な組織に適した基本的なソリューションです。

目標1-すべてのイベントの監査-Windowsを使用して明確に実行できますが、ログのサイズとサーバーのパフォーマンスを考慮する必要があります。 イベントログの通常のアーキテクチャは透過的ではないため、これを確認したいので、1時間あたり何万ものイベントを記録するとサーバーに確実に影響します。

目標2-ジャーナルに変更を加える機能-システムのボトルネック。 残念ながら、管理者がログを消去する可能性を排除することはほぼ不可能です。 これを行うには、特権を微調整したり、雑誌を操作するための特別なアカウントを作成したりしますが、多くの組織にとっては困難で非現実的です。

あなたがこれをしたとしましょう。 目標は3です。レポート、アラート、フィルタリングイベントの集中生成です。 イベントログの転送は、それが発生しても、リアルタイムで実行されないため、大幅な遅延が発生する可能性があります。 ただし、イベントログをリダイレクトした場合でも、すべての情報は1つの場所に分類され、プリミティブなイベントビューアーを使用してそこから取り出すことができます。 図9に、標準ツールのフィルタリング機能を示します。もちろん、これらはプリミティブです。





図9：確立されたイベントログフィルタリングツール。



図に示すように、イベントタイプまたはイベントの説明内の特別なテキスト、およびその他の基準でフィルタリングできます。 しかし、さまざまな関連イベント間の関係を確立する可能性はありません。

問題を解決するためのこれらのイベントの使用に関しては、幸運を祈ります！ もちろんこれは可能ですが、通常は次のようになります。「ログを調べ、イベントの識別子の意味を確認し、これが実際の問題に関連しているかどうかを判断します。」 通常のイベントビューアーが「過去4時間のADのすべての変更」という質問に答えるのは十分に困難です。 これらの変更に関連するイベントはジャーナルに表示されますが、それらを記録する監査ポリシーが設定されていますが、イベントログは変更の管理や監査のタスクを実行することを目的としていません。 これは、この用語の意味の変更の監査ではなく、誰かが変更を加えたという事実の監査です。

図10に示すように、AD Windows Server 2008は各変更の「前」と「後」の値を記録し始めたため、変更の監査により適しています。 ただし、この機能はADではあまり一般的ではなく、大きなログで必要なイベントを見つけることには依然として問題があります。





図10：Windows Server 2008の改善されたイベントビュー。



ほとんどのインフラストラクチャでは、効果的な監査ポリシーはサードパーティのソリューションの使用を意味します。

サードパーティの機能

サードパーティの監査ツールにはいくつかの利点があります。

まず、中央リポジトリのさまざまなサーバーログから情報をより適切に（そしてより速く）収集します。 多くの場合、この集中リポジトリはSQLサーバーデータベースですが、個々のツールはリアルタイムイベントをsyslogサーバーなどの外部ログメカニズムに送信できます（図11を参照）。





図11：syslogサーバーへのイベントの転送



肝心なのは、Windowsからのイベントを取得して、できるだけ早く別のシステムに移動し、イベントログとは異なる方法で保護することです。 この場合のデータベースは、保護でき、複雑なクエリでアクセスできるため、非常に人気のある選択肢です。 そしてもちろん、彼らの助けを借りて、レポートを生成できます。 そのため、ほとんどのActive Directory監査ソリューションは、SQL Serverデータベースでイベントを収集し、SQL Server Reporting Servicesによるレポート機能を活用します。

サードパーティのソリューションは、APIを使用して、フルタイムのイベントログに加えて（またはその代わりに）監査情報を収集することもできます。 多くの場合、これらのAPIは、値の前後を含むより詳細な情報を提供します。 , API .

, , , , .