操作ログとは、Webシステムで誰が、いつ、何をし、どのような結果になったかを後から確認できるように残す記録です。
障害の調査、セキュリティ上の確認、利用状況の分析、監査の補助に使われます。
ただし、取得できる情報をすべて保存すればよいわけではありません。
リクエストや環境変数を無条件に記録すると、パスワードやAPIキーなどの機密情報まで残るおそれがあるためです。
操作ログは、記録する目的と除外する情報を決めたうえで、取得場所、保存先、アクセス権限、保管と削除までを一つの運用として設計します。
操作ログで記録する対象
「操作ログ」は広い呼び方であり、実際には取得場所と目的が異なる複数のログを組み合わせます。
最初に種類を分けると、同じ情報の重複記録や必要項目の漏れを減らしやすくなります。
| 種類 | 記録する内容の例 | 主な用途 |
|---|---|---|
| ユーザー操作ログ | ログイン、データ入力、ファイルのダウンロード | 操作経緯の確認、利用状況の把握 |
| システムイベントログ | エラー、警告、処理の開始と終了 | 障害調査、稼働状況の確認 |
| アクセスログ | アクセス日時、IPアドレス、リクエスト内容 | 通信の確認、不審なアクセスの調査 |
| データベース操作ログ | クエリの実行履歴、トランザクション情報 | データ変更の追跡、処理の調査 |
| クライアント側のエラーログ | ブラウザで発生したエラーと発生箇所 | 画面側でのみ起きる問題の調査 |
環境変数、リクエストヘッダー、リクエストパラメータは、独立したログの種類というより、調査に必要な場合に添える補助情報です。
値をそのまま保存するのではなく、必要性を項目ごとに判断し、機密情報は除外またはマスキングします。
ログ項目は目的から逆算する
操作ログを使える記録にするには、先に「何を調べるためのログか」を決めます。
障害の原因を追うログと、ユーザー操作の証跡を確認するログでは、必要な項目が異なります。
| 項目 | 記録内容 | 設計時の注意 |
|---|---|---|
| 日時 | 操作またはイベントが発生した時刻 | システム内で表記方法を統一する |
| 操作者 | ユーザーIDなどの識別子 | 氏名などを重ねて記録する必要があるか検討する |
| 操作 | ログイン、更新、ダウンロードなど | 同じ操作には同じ名称を使う |
| 対象 | 操作されたデータや機能の識別子 | 必要以上に本文データを複製しない |
| 結果 | 成功、失敗、警告など | 失敗時は調査に必要な範囲で理由も残す |
| 補助情報 | IPアドレス、リクエスト情報、環境情報など | 目的に必要な項目だけを選び、機密情報を除外する |
たとえば、ログイン失敗を調べるなら、発生日時、利用可能なユーザー識別子、操作名、結果が基本になります。
送信されたパスワードを残しても調査の助けにはならず、漏えい時の影響を増やすため、記録対象から外します。
操作ログを取得する三つの場所
アプリケーションで取得する
アプリケーションコードから出力するログは、どの機能で何の処理を行ったかを記録しやすい方法です。
Spring BootやDjangoなどのフレームワークが備えるロギング機能を使い、操作名、識別子、結果を同じ形式で出力します。
action=file_download user_id=<ユーザーID> result=successこの例は項目の並びを示したものです。
実装時は、外部から受け取った値を無条件に連結せず、記録してよい値だけをログ出力処理へ渡します。
Webサーバーやミドルウェアで取得する
ApacheやNginxなどのWebサーバー、TomcatやGunicornなどのアプリケーションサーバーは、アクセスログやエラーログを出力できます。
アプリケーションの処理に入る前後の状況を確認したいときに役立ちます。
ただし、サーバー側のログだけでは「業務上どの操作だったか」までは判別できない場合があります。
アプリケーションログと役割を分け、同じ出来事を追えるように項目名や時刻の表記をそろえます。
ブラウザで取得する
JavaScriptでブラウザ上のエラーを検知し、調査に必要な情報をサーバーへ送信する方法もあります。
画面側でしか発生しない問題を把握できますが、送信項目を絞り、受け取ったログにも適切なアクセス制御を設けます。
三つの保存方法を比較する
保存先は、ログの量だけで決めるものではありません。
検索のしやすさ、複数サーバーからの収集、アクセス権限、アーカイブと削除の運用まで含めて選びます。
| 保存方法 | 向いている状況 | 利点 | 注意点 |
|---|---|---|---|
| ローカルファイル | 構成が小さく、対象サーバーが限られる場合 | 導入しやすく、既存のサーバー機能を使える | サーバーが増えると横断検索や回収が難しくなる |
| データベース | 操作名やユーザーIDなどの項目で検索したい場合 | 項目を決めた検索と集計を行いやすい | ログ用テーブルの容量、権限、アーカイブを管理する必要がある |
| ログ管理システム | 複数のサーバーや大量のログをまとめて扱う場合 | ELKスタックやFluentdなどを使って収集と分析を一元化できる | 導入後の設定、監視、アクセス管理も運用に含める |
データベースへ保存する場合は、ログ専用のテーブルを設けます。
識別子、ユーザーID、操作名、リクエスト情報、マスキング済みの環境情報、操作日時などから、目的に必要なカラムだけを選びます。
リクエスト情報や環境情報をJSON形式で持たせる場合も、JSONなら安全になるわけではありません。
保存前に除外とマスキングを行い、後から不要な項目が混入していないか確認します。
保存後の管理で決めておくこと
- ログレベル：エラー、警告、情報などの使い分けを決め、必要な記録を探しやすくします。
- 出力形式：日時、操作名、結果などの項目名と並びを統一します。
- 機密情報の扱い：パスワードやAPIキーなどは原則として記録せず、必要な項目だけをマスキングします。
- アクセス権限：開発者や運用担当者を含め、誰がどのログを閲覧できるかを定めます。
- 監視：エラーや警告を定期的に確認し、放置されるログを減らします。
- アーカイブと削除：古いログをいつ移動し、いつ削除するかを決め、自動処理の結果も確認します。
ログはセキュリティ調査の材料になりますが、ログを保存するだけで不正アクセスを防げるわけではありません。
アクセス制御や脆弱性対策を含む全体像は、サイト内の「Webシステムの脆弱性を見つける方法」でも確認できます。
業務監査に使う場合も、ログがあることだけで対応が完了するわけではありません。
対象となる要件に合わせて、記録項目、保管期間、不正な改変や不要な閲覧を防ぐ手順を個別に定めます。
導入を進める手順
- 障害調査、操作確認、利用状況の分析など、ログを使う目的を一つずつ書き出します。
- 目的ごとに、記録するイベントと必要な項目を決めます。
- パスワード、APIキー、不要な個人情報など、記録しない項目を先に決めます。
- アプリケーション、サーバー、ブラウザのどこで取得するかを割り当てます。
- 検索方法と運用体制に合う保存先を選び、閲覧権限を設定します。
- 実際の出力を確認し、必要な項目があり、機密情報が含まれていないことをテストします。
- 監視、アーカイブ、削除を定期処理に組み込み、失敗時の確認方法も決めます。
運用前の点検表
- 各ログの利用目的を説明できる
- 操作名、日時、結果などの形式が統一されている
- パスワードやAPIキーが記録されない
- リクエスト情報と環境情報は必要な項目だけに絞られている
- ログの閲覧権限が必要な担当者に限定されている
- アーカイブと削除の手順が決まっている
- 障害時に必要なログを検索できることを確認している
操作ログ設計の結論
操作ログの品質は、記録量の多さでは決まりません。
利用目的に結び付く項目を同じ形式で残し、不要な機密情報を除外し、必要な担当者が検索できる状態を保つことが実務上の要点です。
最初から大規模な仕組みを導入する必要はありません。
対象イベントと保存先を絞って始め、実際の障害調査や運用で不足した項目を見直すと、使われるログへ育てられます。
この記事に関連する株式会社greedenの取り組み
操作ログは、保存先と権限、保守まで含めて設計してこそ運用に役立ちます。
株式会社greedenは、Webシステムの要件整理から設計、開発、リリース後の保守・改善まで一貫して支援します。