LASSIC Media らしくメディア
監査ログとは｜いつ誰が何をしたかを残す
システムを介したやり取りが広がるほど、「誰がいつ、何をしたか」を後から追いかけられるかどうかが問われる場面が増えてきました。とくに不正操作や情報漏えいの疑いが持ち上がったとき、原因を突き止め、関係部署や監督官庁へ説明できるかは、記録が残っているかどうかで大きく分かれます。
本記事で扱う監査ログは、不正・トラブル・コンプライアンス対応の場面で証跡として残す記録に絞って整理します。アプリケーションの挙動を追うデバッグ用の運用ログや、Fluentdなどのログ収集基盤を構築する話とは、目的が別のテーマです。発注担当者やプロジェクトマネージャーの立場で、何を残し、どう守り、レビューで何を確認すればよいかをかみくだいてまとめました。
「監査ログという言葉は聞いたことがあるが、開発会社に何をどう頼めばよいか分からない」という声は少なくありません。仕組みそのものは特別な技術ではなく、記録すべき対象と守り方を要件として言語化できるかどうかが実務上の分かれ目になります。
この記事のポイント
- 監査ログは、不正操作の検知やトラブル時の原因究明に使う証跡であり、デバッグ用の運用ログとは目的が異なります。
- 記録の基本は「いつ・誰が・どこから・何に・どうしたか」で、成功だけでなく失敗やアクセス拒否も残す対象です。
- 記録した本人でも書き換えられない仕組みと、保管期間の設計が、証跡としての値打ちを左右します。
監査ログとは
監査ログとは、システム上で「いつ・誰が・何を・どうしたか」を時系列で記録し、後から追跡・検証できるようにしておく記録です。
似た言葉に運用ログがありますが、目的は別のものです。運用ログはアプリケーションの挙動を追い、不具合の原因をつかむための記録であるのに対し、監査ログは不正やトラブル、コンプライアンス対応の場面で「何が起きたか」を証跡として示すために残します。IPA(独立行政法人情報処理推進機構)の資料でも、システムへの侵害がどのように進行したかを把握するうえで、ログによる証跡確保が土台になると整理されています。同じ「ログ」という言葉でも、残す目的が違えば必要な項目や守り方も変わってくるのです。
ログ収集基盤(Fluentdなど)を構築する話とも、扱う階層が異なります。収集基盤は「ログをどう集め、どこへ転送するか」という技術的な仕組みであるのに対し、監査ログは「何を、どんな要件で残すか」という設計の話です。基盤側の整備が進んでいても、証跡として必要な項目を記録する設計がなければ、監査ログとしての役割は果たせません。
監査ログという言葉が意識されやすいのは、財務報告に関わるシステムや、個人情報・機密情報を扱うシステムです。社内の情報システムだけでなく、企業向けにサービスを提供するSaaSなどでも、取引先の監査対応やセキュリティ審査で、記録の有無や中身を問われる場面が出てきています。
説明責任という言葉は抽象的に聞こえますが、中身は単純です。何かが起きたときに「システムの中で何が起きていたか」を、推測ではなく記録として示せるかどうか、という一点に尽きます。開発を発注する側から見れば、監査ログは機能要件の一つというより、システムを運用する体制そのものの一部として位置づける方が実態に近いでしょう。
英語圏では監査ログを audit log、または監査証跡という意味で audit trail と呼びます。呼び方は違っても、指しているのは「後から検証できる記録」という同じ考え方です。海外の製品ドキュメントやセキュリティ資料を読む際は、この2つの言葉が監査ログとほぼ同じ意味で使われている点を押さえておくと、内容を読み違えにくくなります。
「アクセスログ」という言葉も近い場面で使われますが、指す範囲は製品や文脈によって幅があります。単に接続の記録だけを指す場合もあれば、操作内容まで含めて監査ログに近い意味で使われる場合もあるため、開発会社と話すときは「アクセスログ」という言葉だけでなく、具体的にどの項目を記録する機能なのかまで確認しておくと、認識のずれを防げます。
監査ログが必要な理由
監査ログを残す理由は、大きく3つの場面に整理できます。
第一に、不正操作の検知と追跡です。権限を持つ担当者による不適切な操作や、外部からの不正アクセスは、操作そのものを止めるだけでは足りません。いつ・誰が・何をしたかを後から追える状態にしておくことが、被害の範囲を見極める手がかりになります。たとえば、退職予定の担当者が顧客データを大量にダウンロードしたという状況では、操作の記録が残っていなければ、何をどこまで持ち出されたのかを確かめるすべがなくなってしまうでしょう。
第二に、トラブル発生時の原因究明です。障害やデータの不整合が起きたとき、直前にどんな操作があったかを時系列でたどれれば、原因の切り分けにかかる時間を抑えられます。「いつからおかしくなったか」を関係者の記憶だけに頼らずに再現できる点が、記録の値打ちでしょう。設定変更や権限付与のような、普段は目立たない操作ほど、記録がなければ後から再現しにくいものです。
第三に、内部統制や各種規制への説明責任です。財務報告に関わるシステムや個人情報を扱うシステムでは、「誰が何を操作できる状態だったか」を後から示せることが、統制の実効性を裏づける材料になります。求められる水準は業種や対象システムによって幅があるため、自社が従う社内規程・業法を確認したうえで、必要な記録範囲を決める工程が欠かせません。監査法人や取引先からログの提示を求められたときに、必要な期間・項目がそろっていない状態は避けたいところです。
記録が残っていないことによる影響は、システムの中だけにとどまりません。不正やインシデントが起きたあとに「何が起きたか説明できない」状態は、顧客や取引先からの信頼にも関わってきます。監査ログの整備を、単なる技術的な作り込みではなく、事業を続けるうえでの備えとして位置づけておくとよいでしょう。
| 観点 | 運用ログ | 監査ログ |
|---|---|---|
| 目的 | アプリの挙動を追い、不具合の原因をつかむこと | 不正やトラブル発生時に、何が起きたかを証跡として示すこと |
| 記録内容 | 処理の進行状況・エラー内容・デバッグ用の内部情報 | いつ・誰が・何に対して・どんな操作をしたか（失敗も含む） |
| 保管期間 | 運用ポリシーに応じて短期間で入れ替えるのが一般的 | 業務内容や規程・規制に応じて長期保管を求められる場合がある |
| 閲覧・改変 | 開発・運用担当者が随時参照する前提 | 閲覧権限を絞り、記録した本人でも書き換えられない運用が前提 |
表の「保管期間」の欄にあるとおり、監査ログは運用ログよりも長く残す前提で設計されることが一般的です。だからこそ、保管にかかるコストや、検索のしやすさといった運用面も、記録項目とあわせて検討する事柄になります。
この2つは、どちらか一方があればよいという関係ではありません。運用ログでシステムを健全に保ちながら、監査ログで「何が起きたか」を別枠で証跡化する。両輪で設計しておくと、トラブル対応と説明責任の両方に備えられます。既存システムの改修を発注する場合も、運用ログしか用意されていないケースは珍しくないため、監査ログの要件を後から追加で持ち込む場面は少なくないでしょう。
監査ログに記録する内容
監査ログの記録項目は、「いつ・誰が・どこから・何に・どうしたか」という5つの要素で整理すると、抜け漏れを防ぎやすくなります。
「いつ」は操作の日時、「誰が」は操作したアカウントや権限、「どこから」は接続元のIPアドレスや端末、「何に」は対象となったデータや機能、「どうしたか」は参照・変更・削除といった操作の種類です。国際的なセキュリティコミュニティOWASPが公開するロギングの指針でも、記録には「いつ・どこで・誰が・何を」の要素を含めることが求められています。5つの要素を表にすると、次のようになります。
| 要素 | 記録する内容 | 具体例 |
|---|---|---|
| いつ | 操作が行われた日時 | タイムスタンプ（年月日・時刻） |
| 誰が | 操作したアカウント・権限 | ログインID、役割・権限区分 |
| どこから | 接続元の情報 | IPアドレス、利用端末、アクセス経路 |
| 何に | 操作の対象 | 対象データ、機能、画面 |
| どうしたか | 操作の種類と結果 | 参照・変更・削除、成功/失敗 |
5つの要素は、それぞれ単独では意味を持ちにくく、組み合わせてはじめて「何が起きたか」を再現できます。「誰が」だけが分かっても「何に」が抜けていれば被害範囲は絞り込めませんし、「いつ」が曖昧では、他の操作との前後関係を確かめられません。記録項目を決める際は、5つの要素をひとまとまりの単位として扱う視点が欠かせないでしょう。
忘れられがちなのが、失敗した操作やアクセス拒否の記録です。成功した不正操作は1件でも、その手前で認証やアクセス制御に何度も失敗しているケースは珍しくありません。OWASPの指針でも、認証の失敗や認可エラーを記録すべき項目に位置づけており、成功した操作だけを残す設計では、不正の兆候となる試行の痕跡を見逃す恐れがあります。ログイン試行の失敗が短時間に連続しているといった状況は、パスワードの総当たり攻撃を疑う手がかりにもなるでしょう。
記録の粒度にも注意が必要です。監査ログに残すのは「誰が何をしたか」という操作の事実であって、入力されたパスワードや個人情報の中身そのものではありません。証跡として必要な範囲を超えて機微な情報まで書き込むと、ログそのものが新たな漏えいリスクの発生源になってしまいます。どの項目まで残すかは、証跡として必要な粒度と、情報を抱え込むリスクを見比べながら決める判断事項です。
記録した内容は、検索・追跡できてはじめて意味を持ちます。膨大な件数のログをためこんでいても、必要なときに該当の記録を絞り込めなければ、原因究明にかかる時間はかえって延びてしまうものです。誰が・いつ・何を、といった項目で検索できる状態にしておくことも、記録項目の設計とあわせて考えたい点になるでしょう。
「誰が」の記録では、共有アカウントの扱いにも注意が必要です。複数人で1つのIDを使い回していると、操作の記録は残っていても、実際に操作した個人までは特定できません。監査ログの値打ちを保つには、アカウントを個人ごとに分け、共有アカウントを極力なくす運用とあわせて考える必要があります。
改ざん防止と保管の設計
監査ログは、記録して終わりではありません。記録した本人を含め、誰にも書き換えられない状態で保つ設計があって、はじめて証跡としての値打ちを持ちます。
IPAの資料では、ログへの干渉を防ぐ対策として、追記型の記憶装置を使う、別のコンピュータへ転送しておく、書き込み権限を最小限に絞る、といった方法が挙げられています。更新や削除ではなく追記のみを許可する運用にしておけば、後から都合よく書き換える余地は小さくなるでしょう。同資料は、重要な情報が含まれるログファイルを暗号化して保管する対策にも触れています。
保管期間の設計も欠かせません。どの程度の期間残すべきかは、業種や扱うデータ、適用される規制によって幅があるため、一律には決まりません。業法や社内規程を確認したうえで、必要な期間を保管できる仕組みを整えることになるでしょう。期間を決めずに運用すると、必要なときに証跡が残っていない、あるいは目的を終えたデータを長く抱え込む、といったどちらの方向にも振れかねません。
見落としやすいのが、監査ログ自体が攻撃の対象になる点です。システムへ侵入した攻撃者が自分の痕跡を消すため、真っ先にログを狙うケースもあります。ログの保管場所や閲覧権限を、業務システム本体とは別の管理下に置く設計が、こうしたリスクへの備えになるでしょう。
改ざんを見抜く仕組みとしては、ログの各記録に前後のつながりを示す値を持たせ、途中の1件でも書き換えられると全体の整合性が崩れる形にしておく方法や、書き込み後は変更できない専用の記憶領域に保存するやり方などが知られています。どこまで作り込むかは、証跡として求められる強度と、実装・運用にかけられる工数のバランスで判断する事柄になるでしょう。
あわせて意識したいのが、監査ログそのものへのアクセス制御です。誰が監査ログを閲覧・出力したかという記録まで残しておけば、証跡そのものの取り扱いにも説明責任を持たせられます。業務システムの管理者権限と、監査ログの閲覧権限を同じ人物に集中させない設計も、内部からの改ざんリスクを抑える手立ての一つです。
保管場所の冗長化も、備えとして検討したい項目です。ログを一箇所にしか置いていないと、その保管先が障害やサイバー攻撃で失われた瞬間、証跡そのものが消えてしまいます。原本とは別の場所にも複製を残しておく設計にしておけば、片方が失われても証跡がすべて失われる事態を避けられるでしょう。
発注・レビューでおさえる点
何を証跡として残すかを要件で決める
すべての操作を無差別に記録すると、量が膨らみ、肝心な記録が埋もれてしまいます。不正やトラブルが起きたときに何を説明できる必要があるかを起点に、記録対象を要件として言語化しておくことが発注時の出発点です。
「どの業務・どの画面の操作を対象にするか」「参照だけを含めるか、変更・削除に絞るか」といった範囲を、開発会社任せにせず自社側でも整理しておくと、要件定義の段階で認識をそろえやすくなります。過去に発生したヒヤリハットや、他社事例で問題になった操作の種類を洗い出しておくと、記録対象を検討する材料になるでしょう。
保管期間と閲覧権限を仕様に落とす
保管期間や、誰が監査ログを閲覧できるかは、実装が進んでから決めると手戻りが生じやすい項目です。要件定義やレビューの段階で、保管期間の目安と、閲覧できる役割を仕様書に落としておくと、後工程での認識違いを防げます。
閲覧権限は、業務システムの操作権限とは別枠で設計するのが望ましいところです。日常業務でシステムを操作する担当者と、監査ログを確認する担当者を分けておくと、記録の独立性を保ちやすくなります。小規模な組織で担当を分けきれない場合も、少なくとも複数人の承認を経なければログへアクセスできない運用にしておくと、独立性に近い状態をつくれます。
委託先まかせにせず規制要件と突き合わせる
業種によっては、個人情報保護に関する規程や、財務報告に関わる内部統制の要件で、記録・保管に関する求めが定められている場合があります。開発会社の標準機能に任せきりにせず、自社が従う規制やガイドラインの要件を先に整理し、設計内容と突き合わせて確認する姿勢が、レビューの質を左右します。
「開発会社が用意した標準のログ機能で足りるか」を鵜呑みにせず、自社の業務要件・規制要件と照らして過不足を確認する工程を、レビューに組み込んでおくとよいでしょう。規制要件は改定されることもあるため、リリース後も一度きりの確認で終わらせず、定期的に見直す機会を設けておくことが望ましいところです。
クラウド・外部サービス利用時は範囲の切れ目を確認する
自社システムの一部を、クラウドサービスや外部のSaaSで構成する場合、監査ログの取得範囲が自社側とサービス提供側のどちらの責任かを、契約・仕様の段階で確認しておく必要があります。境目があいまいなまま進めると、いざというときに「どちら側の記録にも該当の操作が残っていない」という事態になりかねません。
サービス提供者側が用意する監査ログの機能で、自社が求める記録項目・保管期間をまかなえるかどうかも、選定段階で確認しておきたい点です。標準機能で不足する部分があれば、自社側の仕組みで補うのか、契約条件として提供者側に求めるのかを、早い段階で切り分けておくと後工程の手戻りを避けられます。
まとめ
本記事では、発注担当者やプロジェクトマネージャーの立場から、監査ログという言葉が指す範囲と、押さえるべき設計上の論点を整理してきました。運用ログや収集基盤との違いを意識するだけでも、開発会社との会話はかみ合いやすくなるはずです。
ここまで、監査ログの位置づけ、記録すべき内容、改ざん防止と保管の考え方、発注・レビューで確認すべき点を整理してきました。要点を3つに集約すると、次の通りです。目的の異なる運用ログと切り分けて設計すること、記録項目は成功・失敗を含めた5つの要素で押さえること、そして記録した本人でも書き換えられない状態と保管期間を要件段階で仕様に落とすことです。
- 監査ログは、不正やトラブル、コンプライアンス対応の証跡として「いつ・誰が・何をしたか」を残す記録である。デバッグ目的の記録とは、そもそもの出発点が異なる。
- デバッグ用の運用ログや、ログ収集基盤の構築とは、目的も設計の起点も異なる。両者を混同すると、証跡として必要な項目が抜け落ちやすい。
- 記録項目は「いつ・誰が・どこから・何に・どうしたか」で整理し、失敗やアクセス拒否も対象に含める。成功した操作だけでは、不正の兆候を見逃しかねない。
- 改ざん防止(追記のみの運用・書き込み権限の限定)と、保管期間の設計が証跡としての値打ちを決める。ログ自体が攻撃対象になる前提での備えも欠かせない。
- 発注・レビューでは、記録対象・保管期間・閲覧権限・規制要件の4点を仕様として確認する。クラウドや外部サービス利用時は、責任範囲の切れ目も含めて詰めておきたい。
よくある質問
運用ログと監査ログは、同じ仕組みで兼ねられますか。
技術的には同じログ基盤で扱うこともできますが、目的が異なるため、監査ログとして必要な項目や保管の仕組みは別に設計するのが実務的です。運用ログは開発・運用担当者が随時参照する前提であるのに対し、監査ログは閲覧権限を絞り、書き換えられない仕組みとセットで扱う必要があります。
監査ログには、成功した操作だけ記録すればよいですか。
いいえ、失敗した操作やアクセス拒否も記録の対象です。OWASPが公開するロギングの指針でも、認証の失敗やアクセス制御のエラーを記録すべき項目として位置づけています。成功した操作だけを残す設計では、不正の兆候となる試行の痕跡を見逃す恐れがあります。要件定義の段階で、失敗イベントも記録対象に含めることを明記しておくと、実装後の抜け漏れに気づきやすくなるでしょう。
監査ログの保管期間は、どのくらいが目安ですか。
業種や扱うデータ、適用される規制によって異なるため、一律の期間は定まっていません。発注時は、自社が従う社内規程や業法の要件をまず確認し、必要な期間を保管できる設計にしておくことが大切です。
ログを増やすと、システムの負荷は上がりますか。
記録する項目や量が増えるほど、書き込みや保管にかかる負荷は増えます。何を証跡として残す必要があるかを整理してから記録範囲を決めると、負荷と証跡としての値打ちのバランスを取りやすくなります。
監査ログの閲覧権限は、誰に持たせるべきですか。
日常業務でシステムを操作する担当者と同じ権限にせず、別枠で絞り込むのが基本の考え方です。操作した本人が自分の記録を見られたり書き換えられたりする状態では、証跡としての独立性が保てません。閲覧できる役割を限定し、誰が閲覧したかも記録しておくとよいでしょう。情報システム部門と、内部監査やコンプライアンス部門とで役割を分けている企業も少なくありません。
クラウドサービスを使えば、監査ログの対応は不要になりますか。
いいえ、クラウドサービス側で標準の監査ログ機能が用意されていても、自社が必要とする記録項目・保管期間をすべて満たすとは限りません。サービス提供者側の責任範囲と、自社側で補うべき範囲の境目を、契約や仕様の段階で確認しておくことが欠かせません。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、監査ログの要件整理からアクセス制御・改ざん防止の設計、実装、リリース後の運用・保守までを一貫して支援する体制です。要件定義の段階から運用まで、工程を分けずに任せられる点も強みでしょう。窓口を一本化できるため、記録対象や保管期間の見直しが必要になった際も、都度やり取りする相手を増やさずに済みます。監査ログの設計や規制要件との突き合わせでお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
