定期的な見直し

定期的な見直し

　定期的な見直しの一環として、筆者らが実施する監査や検査を利用してもらうことがあります。

　監査となると、担当者にとってはげんなりとしたり、もしくは指摘されることに対して不安を持ったりするのですが、法律や内規からの逸脱がなければ、決して「特定の人」を責める行為ではありません。

　この思想は、内部での見直しにおいても同じです。

　弱点を発見した時、捜すべき犯人は、「個人」ではなく「仕組み」です。例えば設定のミスが発見された場合、「誰が」ではなく、どのような仕組みがその弱点を生んだのかを分析することが重要です。

　後から作られた脆弱性が発生する原因としては、以下の例があげられます。

・変更作業実施「前」に作業内容が責任者によって検証されていない
・変更作業が単独で行われ、誰も作業内容をフォローしていない
・変更作業の記録がなく、最新の設定状況が誰にも把握できていない
・変更作業実施「後」に作業内容が責任者によって検証されていない
・そもそも、設定に関する基準がない

　監査を実施すると、ネットワーク構成図は当初の構築時のまま、設定を変更した記録もなく、また設定のバージョン管理も行われていない、という例に行き当たることがあります。

　このような場合、大抵、劣化リスクによって、システム内に後から作られた大きな弱点が発見されます。もし、後から作られた脆弱性が発生する原因の例に自分の組織が当てはまるとしたら、いつの日か、大きなカタストロフィーが発生するかもしれません。

ログの分析

　そして、システム管理者にとって、悩みの種となっているのが「ログの分析」です。

　「ログを収集、蓄積し、分析をするように言われたものの、あまりのログの多さに手がつかない」「ログの分析ツールを導入したはいいが、分析結果が活用されていない、活用できていない」「日々の運用が大変で、すべてのログを取得するだけでログの分析ができていない」などというような例は枚挙にいとまがありません。

　きちんと分析管理できない結果として、ログがハードディスクの肥やしになってしまっている例や、ログの取得すらあきらめている例もあります。

　よって、ログを取得／分析することによって、結果として何を得たいのかを整理することが重要です。

　次ページでログごとの取得、分析、レビューの担当者割り当て、それぞれのログの分析効果について紹介します。