証跡管理は、企業における業務プロセスや行動に関し、あらかじめ規定されたルールに則っているかどうかを客観的に示すための証拠となる記録を収集し、モニタリングすることを指します。

ITシステムの場合、様々な形態のログを保管することで証跡の役割を果たすことができますが、OSの種類によって仕様が異なるため注意が必要です。

そこで本記事では、Windows・UNIX/Linuxのシステム別にログ管理・証跡管理の具体的な対策や留意点をご紹介します。

Windowsのログ管理機能と留意点

Windowsシステムのログを集約するイベントログ機能

Windowsシステムには、標準でログ・証跡を管理する仕組みである「イベントログ」という機能があります。
イベントログはOSの動作に伴う発生イベントがすべて記録される形になっており、システム障害等が発生した場合、まずイベントログを調査すると、障害の発生原因のヒントになるようなエラーログが記載されていることがあります。

イベントログの特徴は、ログの緊急度を「重大」「警告」「エラー」等レベルを指定できるようになっており、大量のログから探したいレベルを持つログだけにフィルターを掛けることが可能であることです。 また、OSの動作に関わるログだけでなく、アプリケーションからイベントログを送信することで、ログを集中管理することができます。

これらのことから、Windowsシステムのログを管理する上で、イベントログは欠かせない仕組みと言えます。
そんなイベントログですが、残念ながら万全ではありません。以下のような点について留意する必要があります。

ポイント①イベントログの内容は専門的で一定の知識が必要

イベントログの内容はOSの動作に関わる部分でもあるため、一般的に内容が専門的で一定の知識を持たないとその内容を把握することは困難です。
セキュリティを担保するためにイベントログを蓄積し、何らかのセキュリティ上のインシデント発生の有無を確認しようとしても、ログの内容を把握できる正しい知識を有していないと実際には効果を発揮できません。

ポイント②すべてのイベントが記録される訳ではない

イベントログで記録される内容は、何かのイベントが発生したとき、変更が生じたときなど、イベントドリブンであり、特に変更等が発生しなかった場合にログとして記録されることはありません。
典型的なケースとしては、システムのログを閲覧した、ユーザー情報を閲覧したといった、単に情報を参照しただけの操作ではログとして記録されません。 ログ管理の目的として、こういった内部者の不正操作、不適切な操作の有無をチェックしたいというケースは多いですが、このような場合にはイベントログだけでは要件を満たせないことになります。

ポイント③最大保存サイズとアーカイブ設定

イベントログを普段から活用されていない方はあまりご存じではないかもしれませんが、イベントログの標準の設定では、ログの保存サイズの上限が20MB程度に設定されおり、上限に達すると古いログから消去されるようになっています。

したがって、このままの設定では一定期間が経過するとログは自動的に消去されてしまいます。これを回避するためには、消去される前に別の仕組みにログを移したり、上書きしないでアーカイブする設定に変更するといった対応が必要です。

尚、アーカイブ設定した場合には、ログは削除されず時間の経過とともに増大するため、不要になったログを削除する運用を行わないとディスクの空き容量を圧迫する可能性があります。

Windows標準のイベントログ機能を補完する方法

これらの問題を考えると、Windowsのログをイベントログだけで管理するのは、実質的には難しく、別の仕組みを使って管理することを検討する必要があります。

一般的に利用されるソリューションとしては、ログを様々なサーバーや機器から収集して集中管理する統合ログ管理です。統合ログ管理ソリューションの中には、Windowsイベントログを収集・分析することで、専門知識がなくても発生している問題やリスクを解りやすく提示してくれるものがあります。

また、ログの容量も全体で集約して管理することができるようになりますので、Windowsサーバーごとにログの容量を気にする必要もなくなります。

そういう意味で、ポイントの①と③については解決できる手段となりますが、統合ログツールはログとして取得されていないものを集めることはできませんので、標準のイベントログで必要なログが取得できない場合には、必要なログを取得するサードパーティー製品を併用するといった対応が必要になります。

サードパーティー製品を使うと取得できるようになるログの例としては、ファイル操作（新規作成、変更・閲覧・削除など）、メール送受信、インターネット閲覧、印刷、USBデバイスの挿入といった情報です。

弊社の証跡監査ツールESS RECは、さらに特徴的な機能として、操作中のデスクトップの内容を連続したスナップショット形式で取得し連続的に見ることで、操作そのものを録画データとして保存するといった機能を提供しており、デスクトップ上のGUIを使って行うWindows固有の操作を網羅的かつ視覚的にわかりやすくログ保存することが可能になっています。

UNIX/Linuxのログ管理機能と留意点

UNIX/Linuxシステムのコマンド実行ログを残す方法

UNIX/Linuxシステムには、Syslogというログを管理するための仕組みが存在し、多くのアプリケーションがSyslogに対応しています。

しかし、実は「コマンド実行のログを残すならこれ」といった方法はなく、いくつかの方法の中で目的や取得できる内容によって選択されています。

Scriptコマンドを使用する方法

Scriptコマンドを使ってファイル名を指定すると、それ以降に行われたコマンド実行と実行結果がファイルにテキストとして出力されるというものです。Scriptコマンドをログイン後に自動実行するようなログインシェルを用いれば、ユーザーに意識させずに実行コマンドのログを取得するようなことも可能です。

プロセスアカウンティング機能を使用する方法

システムアカウンティング機能とは、サービスとして実行コマンドのログを取得する方法です。Psacct（一部のLinuxでは名称が異なります）というサービスを実行させておくと、全ユーザーの実行コマンドが記録されます。実行されたコマンドを確認するには、lastcommコマンドを使用します。

SUDOコマンドの実行ログを利用する方法

SUDOコマンドとは、権限を有しないユーザーに対して、特定のコマンドのみ実行を許可する際に使用するコマンドです。SUDOはユーザーごとに許可する操作をコマンド単位で細かく設定可能であることから、コマンド単位での利用制限を行うためによく利用されています。

このSUDOには実行ログを取得する機能が備わっており、標準の設定では、/var/log/secure にSUDOの実行コマンドのログが残る仕様になっています。

コマンドhistoryを利用する方法

シェル上で実行したコマンドの履歴はhistoryコマンドで取得することができます。実行結果をファイル出力すると、その内容をファイルに保存することができます。

UNIX/Linux標準のログ取得機能の留意点

以上のようにUNIX/Linuxには様々な方法でコマンド実行履歴を保管することができますが、実はいずれも部分的に要件は満たせるものの、特に監査・内部統制等を目的とした場合に求められるログの要件に照らし合わせると、いずれの方法もすべての要件を満たしていないというのが現実です。

下表はご紹介した方法をログの要件への対応状況をまとめたものです。

例えばScriptの実行では、コマンドとその引数、実行結果すべてが記録されますが、「誰が」、「いつ」という情報が存在しません。またログは平文のテキストに出力されるため、容易に改ざんすることができてしまいます。

また、プロセスアカウンティング機能は、「いつ」、「誰が」、「どんなコマンドを入力」したのか、記録は網羅されますし、ユーザーが意図的に記録を停止させることも困難です（root権限は除く）。しかし、ユーザーによるコマンドだけでなく、システムが実行したものも記録の対象となるため、ログの量が膨大になり負荷が心配です。また、コマンドの引数や実行結果は記録されません。

一方、ターミナルソフトの機能で操作記録を取得する方法も存在します。 Tera TermはPlug-Inやマクロを実装できるため、ログ取得を自動化するアドインが多く開発されています。

このようなターミナルソフト側で操作ログを取得する方法は、マスターコンソール上の操作が記録できないためマスターコンソールから操作しないことが前提ではありますが、内容は必要かつ十分、またサーバー側に設定が必要なく影響を与えないことも大きなポイントであるため、かなり有効な方法と言えます。しかしログデータは保護されないテキストファイルであり、ログ取得の仕組みが理解できる管理者であれば簡単に改ざん・削除ができてしまいます。

このようにターミナルソフト側で取得する方法は、情報の網羅性の観点では要件を満たしますが、セキュリティ面では要件を満たす方法にはなりえません。

以上のように、UNIX/Linuxシステムに対して、しっかりと監査要件を満たすようなログ取得を行うには、標準で用意されている機能では不十分な点が多く、実際に継続して運用を行うに相当な工夫が必要になってくるため、専用のシステムを利用する方がよさそうです。