@ Wise-Hawk.com

Blog -マイクロソフトに一喜一憂する日常-

イベントログの最大サイズ

|

あまりに有名な話ではあるんですが、なぜかここ最近よく聞かれる"イベント ログの仕様"の話。
# ご存知の方が大半かとは思いますが、備忘録の意味をこめて

【KB: イベント ログ ファイルが設定したサイズまで拡張されない】
http://support.microsoft.com/kb/183097/ja

【KB: イベント ログが最大ログ サイズに達する前に、イベントの出力が停止する】
http://support.microsoft.com/kb/312571/ja

上記2つのKBはどちらも同じことを言っていまして、一言でまとめると「イベント ログ サイズの実質的な上限は300MB程度(約 200 ~ 600 MB と幅はある)に限定される」ということです。
設定上はそれ以上(*イベントカテゴリごとに4GB)も可能ですが、実質的な限界に達すると、ログが記録されなくなったり、上書きオプションに基づいて古いものから上書きされていってしまいます。

原因は下記Webページの説明が分かりやすいと思います。

【脅威とその対策 : Windows Server 2003 と Windows XP のセキュリティ設定】
http://www.microsoft.com/japan/technet/security/topics/serversecurity/tcg/tcgch06.mspx

大変興味深い文章ですのでぜひ一読していただきたいのですが、メモリマップファイルの仕様により現行OSでは回避不可能であることが分かります。

---
なぜ今になってこの仕様に絡む問い合わせが増えているかを確認してみると、やはり情報漏えい対策全般という話が多いようです。つまり、ファイルサーバーやクライアントOS上でのファイルアクセス監査ログや、ドメインコントローラ上のログオン/ログオフの証跡ログを取得したいという要件が実運用レベルで増えてきており、それに対応しようとして発覚するというパターンが大半かなと。

実際 私が初めて知ったのも、アクセス監査ログを収集するという要件を受けて検証していて、なぜか指定した最大サイズに達する前にログ落などが発生していた原因を究明するためでした。思えば今から2年も昔か…トシトッタナァ(ノ_・。) 

---
で、根本的な解決策は無いわけですが、300MBという制限の範囲内での運用であれば、回避策はいくつか考えられます。
たとえば、

  • KB312571にあるように、自動ログローテーションが行われるようにレジストリを変更する
  • 日次等のバッチ処理として、イベントログのファイルへの書き出しとクリアを行う
という感じです。

1つ目の選択肢は、(たとえば100MBに最大ログサイズを設定しておくと、100MBに達するたびに)自動的にEVT形式のログ(Logname-YYYY-MM-DD-HH-MM-SSS-mmm.evt)が保存されます。設定は簡単ですし無駄はありませんが、いざイベントログを確認しなければいけないときに微妙なタイミングでローテーションが発生していて確認しにくいといった問題や、何かしらの対応を打たないと永遠とイベントログのアーカイブでHDDを圧迫していく問題があります。

2つ目の方は指定期間ごとにイベントログファイル(アーカイブ)を生成できますので、何かあったときの閲覧は比較的楽かもしれません。ただし、万が一バッチが流れる前にログサイズの上限に達すると、その間のログが欠けてしまうというリスクが残ります。特にファイルアクセス監査なんかを設定している環境では、イベントログが一日と持たないケースも多々ありますので…

どちらの方法を選択するかは好みの問題かもしれませんが、ログが継続低に保管されているかどうかという事実そのものが重要視されることが多い今日ですので、適切な対策を対取りましょう。

以上、長文でした。

 
copyright(c) 2001- Wise-Hawk.com All rights reserved.