どのように取るのか、そしてどう見るのか：「内部統制」に振り回されない賢いログ活用とは（1/2 ページ）

ネットワーク機器やサーバなどが出力するログをどのようにまとめ、活用すべきか、より具体的な部分を説明していこう。

[二木真明，ITmedia]

本記事の関連コンテンツは、オンライン・ムック「『内部統制』に振り回されない賢いログ活用とは」でご覧になれます。

　前回の記事では、何のためにログを取るのかという目的の部分について説明した。それを踏まえた上で、ログの取得方法についてもう少し具体的な話をしていこう。

　実際のところ、情報システムにおけるログの取り方と保存方法のオプションはあまり多くない。一般に取得されるログは、ユーザーや機器の認証にかかわるもの、接続やアクセス、操作などの履歴、システム上のエラー、アラームや稼働履歴などが中心だ。

図3●社内システムにおけるログ管理（クリックすると拡大）

ネットワーク機器や非Windows OSの場合

　ネットワーク機器やWindows以外のOSにおいては、こうしたログは、一般に「syslog」とよばれる機構を介して、最終的にファイルに保存される（関連記事1、関連記事2）。syslogは、ネットワーク上でログを転送する仕組みなので、管理者は任意のサーバにログを集めることができる。

　このことは、重要な意味を持つ。もし、ログが取得対象となるサーバ自身に保存されている場合、その障害などによってログが失われる可能性があるからだ。この場合、たとえば障害解析といった目的においても支障が出る。

　さらに、そのシステムの管理者は自由にログファイルにアクセスできる。このため、悪意ある管理者によってログが改ざん、消去されることもあり得る点にも注意が必要だ。

　そのため、syslogを出力先にすることができるログは、できる限り、管理者が異なる他のサーバに転送して保存、管理する。こうすることで、ログを障害や管理者の悪意から保全できる。これは一種の権限分離であり、内部統制の観点から見ても重要なポイントだ。

　ただ、少々注意も必要だ。syslogは通常の実装では、通信プロトコルとしてUDPを使用する。従って、たとえばネットワークが混雑しているような場合に、ログを紛失してしまう可能性がある点に留意しなければならない。最近では「syslog-ng」のような、TCPを使用した転送が可能なものがあるので、できるだけそちらを使った方がよい。

　また、転送先でのログの改ざんなどへの対策としては、ファイルの保存単位（たとえば、1日単位とか、一定の容量の単位）ごとに、ハッシュ値を取得して保存しておく方法が考えられるだろう。使用するハッシュアルゴリズムについては、以前はMD5やSHA1（160ビット）が主流だった。だが最近、これらのアルゴリズムの安全性に疑義が生じていることから、SHA2ファミリー（SHA 224、256、384、512など）を使用した方がよいだろう。LinuxなどのOSではすでに、これらのためのツールが用意されている。

　ハッシュは小さいデータなので、たとえばログのローテーション（ファイル保存単位の切り出し）の際に計算し、メールなどで複数の相手先に転送、保存しておいてもよい。これによって、ログサーバ管理者による改ざんも検出することができる。このような処理は、簡単なスクリプトで実現できる。

Windows系システムの場合

　Windowsでは、OS関連のログは一般に「イベントログ」とよばれる形式で出力される。現在のところ、Vista以外のWindows OSでは、一般にこれを転送、集中管理する手段は提供されていない。従ってこれらを集中管理するためには、市販されているツールを使って、イベントログをsyslogなどに転送する仕組みを作る必要がなる。

　また、市販のログサーバ製品のなかには、こうした異なる形式のログを一括して収集管理できるものもある。予算が許せば、また規模によっては、こうした製品を使って一元管理するのも1つの方法だろう。このような製品には、一般にログ検索やレポート作成などの機能も含まれているので、内部統制上も都合がいい。

図4●社内システムが生成する主要なログの収集手段

　市販のパッケージソフトや特殊なログ取得用ソフト、たとえばファイルアクセスログ取得ソフトのようなツールの中には、テキストファイルやデータベースなどに直接ログを出力するものも多い。このようなケースでは集中管理はいくぶん困難になる。だがたとえば、ファイルならばその保存場所をネットワークドライブに指定し、他のサーバとは異なる管理権限で保存するような運用方法も考えられる。

　ただ、出力先がデータベースとなる場合はかなり難しい。とりわけローカルマシン上で独自のデータベースを作ってログをはき出すようなアプリケーションでは、ログ転送の手段がないのが実情だ。汎用のDBMSを使った製品ならば、手間をいとわなければ、データベースからログを読み出して、syslogなどへ転送するプログラムを自作することも可能だ（もちろんパッケージベンダーからそのような保証を得ることはまずできないだろうが……）。

　いずれにせよ、アプリケーションパッケージを選ぶ際は、ログをどのように管理しているかというのも注意しておきたい点の1つである。