大企業のITサービスを管理し、Active Directoryに複数のドメインと数千のユーザーがいる状況を想像してください。 少なくとも数人のシステム管理者があなたに従属し、それぞれが職務を遂行します。 突然、いずれかの部門の従業員は、古いパスワードの有効期限が切れると新しいパスワードを思い付かないと不満を言います。システムは新しく作成されたパスワードを受け入れません。 各部門のパスワードポリシーをざっと見てみると、 パスワードの長さと複雑さが変更されていることがわかります。 原因を調べるには、イベントログを参照し、パスワードポリシーがいつ誰によって変更されたかに関する情報がないことを理解します。ログは既に上書きされています。 誰がポリシーを変更したかは謎のままです。
また、別の例を示します。管理者は、ユーザーの1人が問題なく自分のマシンにソフトウェアをインストールできることを突然発見します 。 そして、これは、ユーザーがメンバーであるOUのグループポリシーでは、そのようなインストールが禁止されていたという事実にもかかわらずです。 繰り返しますが、そのようなインストールを誰がいつ有効にしたかについての情報は、イベントログで検索する必要があり、情報のないデータの「ノイズ」を通り抜けます。
このすべてが明確な結論につながります会社のITサービスは、グループポリシーで行われている変更に注意を払う必要があります。 情報セキュリティシステムの穴の形成を防ぐためにこれを行う必要があります（「怠慢なユーザーがそこに置くソフトウェアは何ですか？」）、そしてビジネスの継続性を確保します（200人が同時にマシンにログインできない場合。パスワード）。
実際にのみ、 誰もグループポリシーの変更を制御することはほとんどありません 。 そして、問題が発生した場合、または疑わしいアクティビティが検出された場合のみ、イベントログの分析と同僚へのインタビューから問題の原因の検索が開始されます。
ただし、問題の原因を突き止めるだけでなく、その出現を防ぐことも重要です。 グループポリシーの場合、パスワードポリシーが変更されたことを管理者が知りたいと思っていることは間違いありません。
このようなインシデントを迅速に調査して防止するには、グループポリシーで発生する変更に注意する必要があります。 通常の方法でこの問題の解決を試みることができます。
たとえば、イベントログを手動で表示します。 ただし、事前に監査を設定し、ジャーナル内のデータの上書きを考慮した場合でも、ジャーナルイベントの表示は、ユーザーからの苦情が届いた後にのみ行われます。 そして、それは犯人を見つけるのに役立つだけで、問題を防ぐことはできません。
Windows Server 2008 R2では、変更の追跡（および問題の防止）のプロセスが少し簡単になりました。 より便利なイベントビューアー（イベントビューアー）と共に、特定のイベントの電子メールアラートを構成できるようになりました。これにより、エンドユーザーに到達する前に状況を修正できるため、一歩先を行くことができます。
ただし、Windows Server 2008 R2の標準監査機能が拡張されても、いくつかの悪化要因が同時に発生します。 どのイベントを選択しますか？ 同じ番号のイベントに異なるオブジェクトに関する情報が含まれている可能性がある場合（たとえば、グループポリシーの変更とActive Directoryの他のオブジェクトの両方に対してイベント4662が生成される場合）にコンテンツをすばやくフィルタリングするにはどうすればよいですか？ イベントには、特定のグループポリシーの名前ではなくGUIDのみが含まれます。これにより、必要なイベントを受け取った後、GUID'a認識手順も強制的に実行されます。 しかし、そのようなイベントが多数ある場合はどうでしょうか？
上記の例からわかるように、 標準の監査システムは理想からはほど遠い ものです。また、変更ごとに「前」と「後」の値を表示することにも注意する価値があります 。 それらは単に存在しません。 グループポリシーの場合、管理者はコンテンツを念頭に置くか、ポリシーを定期的にエクスポートしてから、ポリシーの違いを手動で比較する必要があります。
もちろん、フルタイムの監査システムを使用すると、行われている変更をある程度制御できますが、それでも次の欠点は回避できません。
- 出来事の変化に関する情報の分析はかなり面倒であり、知覚のために特定の知識が必要であり、これらの問題にあまり精通していない人々（たとえば、経営者）に元の形で提示することはできません
- セキュリティログは各ドメインコントローラーで手動で分析する必要があります
- データ統合なし
- ログの書き換え-イベントの損失の可能性
- 変更の事実のみが記録され、正確に変更されたものに関する明確な情報はありません
その他多数...
部分的に上記の問題により、さまざまなログ処理方法（ログ分析を可能にするスクリプトおよびユーティリティから、特殊なSIEMソリューションまで）を解決できます。 ただし、記載されているすべての問題を解決できるわけではありません。 たとえば、各変更の「前」と「後」の値は表示されません。その結果、管理者は手動でグループポリシーの現在の設定でアーカイブを作成し、最新の状態に保つ必要があります。
常勤監査システムの欠点とITインフラストラクチャ管理の必要性の高まりは、監査の変更のためのサードパーティの専門ソリューションの出現につながります。 上記の通常のシステムの欠点に基づいて、 グループポリシーを監査する決定の基礎となる特性を決定します 。
- 「変更前」および「変更後」の形式でのオブジェクトの変更された値の表示、
- 特定の期間（たとえば、12時間または数日ごと）に発生した変更に関するレポートの自動生成、
- データをフィルタリングし、個々のポリシーの変更に関する情報を受信する機能、
- 提供された情報の義務的な可視性（誰が、何を、どこで、いつ変更したか）、
- 監査データを専用のリポジトリ（SQLデータベース、ファイルサーバー上のアーカイブ、または両方の場所に一度に）に保存する機能、
- グループポリシーのバックアップと復元。
この記事では、これらのソリューションの1つであるグループポリシーの変更を監査するプログラムNetWrix Group Policy Change Reporterについて検討します。 まず、製品の仕組みを説明します。
- データ収集中、製品はグループポリシーの現在のステータスのスナップショットを取得し、監査が実行されるすべてのドメインコントローラーのセキュリティログから情報を収集します。
- データを収集した後、指定された保管場所（たとえば、専用のファイルサーバー）に追加され、分析されます。検出された変更はデータベース（製品に接続されている場合）にアップロードされ、指定されたアドレスにレポート形式で送信されますメール
- データ収集の初期化は、タスクスケジューラに基づいています。タスクスケジューラでは、スケジュールされたタスクが作成され（製品構成中に自動的に）、データ収集が開始されます。
- デフォルトでは、レポートは1日1回（午前3時）送信され、過去24時間の変更に関する情報が含まれています。 ただし、レポートを送信する頻度と時間は簡単に変更できます。 また、レポートの送信はいつでも手動で開始できます。
作業プログラム：
製品の結果を検討します。つまり、この記事の冒頭で説明したシナリオを再現します。N社の本社（本社）の部門に適用されるポリシーを編集します。
- 最小パスワード長を7文字から14文字に変更します
- 45日から20日までの最大パスワードを下げる
- パスワードの複雑さを有効にする（パスワードの複雑さの要件を満たす）
- ユーザーにソフトウェアをインストールさせます
そのため、データ収集が完了し、次のコンテンツのレポートを受け取りました 。
詳細
レポートには、当社による変更が視覚的に表示されます。 この例では、管理者のジョン・スミスが誤ってパスワードの最大有効期間を45日間から20日間に短縮したため、一部のユーザーは25日前にパスワードを期限切れにし、さらに最小パスワード長が7文字増加しました-ユーザーを待っている状況を想像してください？
ジョンスミスは、午後8時13分の就業日の終了後にこれらの変更を行い、レポートは3泊で生成されました。 したがって、管理者は午前中に変更を認識し、問題になる前に修正することができました。
ご覧のとおり、レポートには各変更の「前」と「後」の値が含まれています。 これは、変更の重要性を評価するのに非常に便利です。
レポート自体の構造は、次の原則に基づいています。
- 変更の種類（変更の種類）
- 変更されたとき
- 誰が変わった
- 変更が発生した場所、つまり どのドメインコントローラ（変更箇所）
- 変更されたグループポリシーオブジェクトと行われた変更（グループポリシーオブジェクト）
より明確にするために、さまざまな種類の変更（追加、削除、変更）に異なる色のマークを付けます。これは非常に便利で、レポート内の重要な種類の変更（削除など）を強調表示しやすくします。
この例では、レポート送信スケジュールは1日に1回送信するように設定され、レポートは夜間に自動的に生成されましたが、スケジュールされたレポートを待たない場合は、必要なドメインの[ 実行 ]ボタンをクリックして手動で送信を開始できます：
SQL Reporting Services （高度なレポート）に基づくレポートのライブラリには 、別の項目に注意する必要があります 。
ライブラリは、特定の監査の目標と目的のために設計されたレポートのサブカテゴリに分割されています。 たとえば、グループポリシーで発生したすべての変更を数か月にわたって引き上げる必要がある場合、指定された期間に行われたすべての変更を反映するAll Group Policy Changesのレポートを使用できます。 すべてのレポートでは、表示された情報をフィルタリングすることもできます。たとえば、以下のレポートでは、管理者ユーザーが行ったすべての変更を表示しました。
特定のポリシー設定の変更に関心がある場合、 管理用テンプレートの変更の一部であるポリシー設定の変更など、適切なレポートを使用できます。
ライブラリに含まれるレポートごとに、指定されたスケジュールに従って指定された電子メールアドレスにレポートが自動的に配信されるサブスクリプションを構成できることに注意してください。
それとは別に、 監査データの保存についても説明する必要があります 。 標準ツールとは異なり、データストレージは2つのレベルで構成されています。 検出された変更はSQLサーバーデータベースに保存されます-これはデータストレージの最初のレベルです。 第2レベルのストレージはグループポリシーと関連データのスナップショットを保存するために使用されますが、データはファイルストレージに保存されます。 ストレージデータをいつでも使用して（特定の期間の）変更を生成し、SQLサーバーデータベースに変更をアップロードできます（たとえば、新しいSQLサーバーへの移行の場合）。
データ保持期間は、会社の内部目標によってのみ制限されます。 したがって、過去に行われた変更に関する情報を迅速に取得して分析することができます。 たとえば、過去1年間のパスワードポリシーの変更に関する遡及情報を取得します。 個々の業界の情報セキュリティ規制では、このようなレポートが多数必要です。
また、製品がグループポリシーのバックアップを自動的に作成することも追加する価値があります。 バックアップは後で、変更をロールバックしてポリシーを復元するために使用できます。
結果：
グループポリシーの変更に遅れないようにする必要があります。 問題の迅速な解決により、会社の業務のダウンタイムを回避し、情報セキュリティ侵害の可能性のあるインシデントを回避します。 これにより、NetWrix Group Policy Change Reporterが役立ちます。
PSこのプログラムは、基本的な無料版と完全版で利用できます。 それらの違いを理解し、当社のWebサイトからプログラムをダウンロードできます 。