「監査ログは取得しているが、分析まで手が回らない」「膨大なログのなかから不正を見つけるなんて、現実的に不可能」——データベース監査に取り組む企業から、こうした声をよく聞きます。
法規制やガイドラインへの対応、内部不正への備えとして、監査ログの取得自体は進んできました。ところが、取得したログをどう分析し、どう不正を見つけるかという段階で止まってしまうケースが少なくありません。ログは日々積み上がる一方で、人手でのレビューはとうに限界を超えている、という状況です。
本記事では、監査ログ分析が行き詰まる原因を整理したうえで、分析を自動化する具体的なアプローチと、その導入ステップを解説します。
この記事で分かること
- 監査ログ分析が人手では回らなくなる、構造的な理由
- 分析を自動化する3つのアプローチ（ルールベース検知・ホワイトリスト・ログ突合）
- Insight PISOによる異常検知と、Insight Inspectorによるログ突合の仕組み、そして導入までのステップ
1. 監査ログ分析の課題
まず、なぜ監査ログの分析が難しいのか。理由は3つあります。
ログ量が人手で扱える規模を超えている
データベースの監査ログは、規模によっては1日で数百万件から数千万件に達します。SELECT文まで含めて全アクセスを記録していれば、当然そうなります。この量を前提にすると、「目を通す」という発想そのものが成り立ちません。
手作業レビューには限界がある
現実的な運用として、多くの現場ではサンプリングによる抽出チェックが行われています。しかし、サンプリングは「たまたま抽出されなかった不正」を見逃します。しかも、レビューする担当者には専門知識が求められ、属人化しやすい。担当者が変わった途端に精度が落ちる、という話も珍しくありません。
「取得しているだけ」で終わっている
結果として、監査ログは「何かあったときに調べるための保険」として保管されるだけになりがちです。しかし、監査ログの本来の価値は、不正やその予兆を早期に見つけて、被害が広がる前に手を打てることにあります。取得と保管で止まっているなら、その価値の大半は使われていないことになります。
監査ログの取得方法そのものについては、別記事「データベース監査ログとは？取得方法から活用までわかりやすく解説」で解説しています。
2. 監査ログ分析の自動化アプローチ
では、どう自動化するか。データベース監査においては、次の3つのアプローチが有効です。それぞれ得意な領域が違うので、組み合わせて使うのが基本になります。
① ルールベース検知：既知の不正パターンを捉える
「こういう操作が起きたら不正の可能性が高い」というパターンをあらかじめ定義し、それに合致する操作を検知する方式です。深夜や休日のアクセス、個人情報テーブルからの大量抽出、ログイン失敗の連続、特定端末以外からのアクセスなど、条件を明示できるものはこの方式で拾えます。
わかりやすく、導入もしやすい方式です。一方で、定義したパターンから外れるものは検知できません。閾値を厳しくすればアラートが鳴りすぎ、緩めれば見逃す、という調整の難しさもあります。
② ホワイトリストアプローチ：許可した操作以外を検知する
こちらは逆の考え方です。「これは正常」と認めた操作をリスト化しておき、そこから外れる操作を検知します。
データベースへのアクセスは、業務システムからの定型的なものが大半を占めます。アプリケーションが発行するSQLは決まっており、接続元の端末やプログラムも限られている。だからこそ、正常なパターンを許可リストとして定義しておけば、そこから逸脱した操作を「想定外」として拾い上げられます。
この方式の強みは、未知の操作にも対応できることです。不正のパターンを事前に知っている必要がなく、「許可していない」という一点で検知できます。ルールベースが「悪いものを列挙する」のに対し、ホワイトリストは「良いものを列挙する」わけですね。
運用のポイントは、許可リストの育て方です。最初から完璧なリストは作れないので、警告が出たら内容を確認し、正常な操作であれば許可リストに追加する。この繰り返しでリストを実態に合わせていきます。
なお、近年は「UEBA（User and Entity Behavior Analytics）」という考え方も注目されています。ユーザーやシステムの振る舞いを学習し、通常との違いから異常を検知するアプローチです。将来的な方向性として有望である一方、学習に十分なデータと期間が必要で、検知結果の説明可能性という課題もあります。データベース監査の実務では、まずルールベースとホワイトリストで確実に押さえるところから始めるのが現実的です。
③ ログ突合：申請内容と実際の操作を照合する
3つ目は、他システムのログと突き合わせる方式です。特権ID管理（PAM）の申請・承認記録と、データベースの操作ログを照合すると、「申請どおりに作業が行われたか」「申請にない操作が紛れていないか」が確認できます。
これは単独のログを見ているだけでは絶対に分からない領域です。SQLだけを見れば正常な操作に見えても、そもそも申請がなければ不正の疑いがある。逆に、申請があれば深夜の大量抽出も正当な作業かもしれません。文脈を照らし合わせることで、判断の精度が上がります。
3つのアプローチを整理すると、次のようになります。
| アプローチ | 検知できるもの | 得意な領域 | 運用上の要点 |
| ルールベース検知 | 定義済みの不正パターン | 条件を明示できる操作（時間外・大量抽出等） | 閾値のチューニングが必要 |
| ホワイトリスト | 許可リストから外れた操作 | 定型的なアクセスが大半の環境 | 許可リストの継続的な育成 |
| ログ突合 | 申請にない操作・時間超過 | 特権IDによる保守作業の点検 | PAM等との連携が前提 |
3. Insight PISOの異常検知機能
インサイトテクノロジーが提供するデータベース監査ソフトウェア「Insight PISO」は、監査ログを取得するだけでなく、取得したログをもとに不審な操作を検知する機能を備えています。代表的な検知の観点を挙げます。
通常と異なるアクセスパターンの検知
許可リストに登録された正常なパターンから外れる操作を検知します。業務アプリケーションが発行するSQLは定型的で、接続元の端末やプログラムも限られているため、そこから構造的に外れた操作は、それ自体が確認すべき対象になります。「いつもと違う」を拾い上げる、という考え方です。
大量データ抽出の検知
通常の業務では発生しない規模のデータ取得を検知します。個人情報を含むテーブルから数万件、数十万件を一度に抽出するような操作は、情報持ち出しの典型的なパターンです。処理件数を基準に、逸脱した操作を拾い上げます。
営業時間外アクセスの検知
平日の深夜帯や休日など、通常の業務時間から外れたアクセスを検知します。バッチ処理などの正当な夜間処理は許可リストに登録しておくことで、それ以外の想定外のアクセスだけを浮かび上がらせられます。
新規アクセス元の検知
これまで接続実績のない端末やプログラムからのアクセスを検知します。接続元の端末、OSユーザー、実行プログラムといった情報を見ることで、「いつもと違う経路からの接続」に気づけます。認証情報が盗まれた場合の初期兆候としても有効です。
4. Insight Inspectorで実現する、Insight PISOとiDoperationログ突合による不正検知
前章で挙げた検知は、データベースの操作ログだけを見て判断するものでした。しかし、その操作が「正当な作業だったのか」までは、DBのログ単体では分かりません。そこを担うのが「Insight Inspector」です。Insight Inspectorは、PISOが取得したDB操作ログと、他システムのログを突き合わせて点検するソフトウェアです。ここでは、NTTテクノクロス社の特権アクセス管理ツール「iDoperation」との組み合わせを例に説明します。
iDoperationの作業申請ログとPISOのDB操作ログを突合
iDoperationは、特権IDを「いつ・誰が・何のために」使うのかを申請・承認し、そのIDを一時的に貸し出す仕組みを提供します。一方のInsight PISOは、実際にデータベースで実行されたSQLを記録します。
Insight Inspectorは、この2つを定期的に自動照合します。申請番号、申請者、承認日時、対象アカウントといった申請側の情報と、DBユーザー、OSユーザー、実行時刻、SQL文といった操作側の情報を突き合わせ、対応関係を確認していく仕組みです。
申請外作業の自動検出
突合によって最初に見つかるのが、申請の記録がないDB操作です。特権IDを使った操作が記録されているのに、対応する申請が存在しない——これは、承認プロセスを経ずに作業が行われたことを意味します。手作業の点検では、膨大なSQLログのなかからこれを見つけ出すのは困難ですが、自動突合であれば漏れなく拾えます。
承認されていない操作の可視化
これらの検出結果は、点検レポートとして出力できます。「申請から報告承認まで完了した正常な操作」と「申請の記録がない操作」を切り分けて示せるため、監査対応の証跡としてそのまま活用できます。全件を対象にした点検を自動で回せるので、サンプリングで妥協する必要がなくなる、というのが実務上の大きな違いです。
申請時の作業予定時間を超えるDB操作を検出
もうひとつが、申請自体はあるものの、承認された作業予定時間の範囲外で実行された操作です。「1時間の作業として申請したが、実際には数時間にわたって操作が続いていた」というケースが該当します。申請の枠を超えた作業は、意図的でなくとも統制上の問題になるため、点検対象として押さえておく必要があります。
特権ユーザーの監視そのものについては、別記事「特権ユーザーのアクセス管理｜DBAの操作ログを可視化する方法」で詳しく解説しています。
5. ログ分析自動化の導入ステップ
最後に、監査ログ分析の自動化を実際に進める手順を整理します。
ステップ1：現状の監査ログ取得状況を確認する
出発点は棚卸しです。どのデータベースで、どの操作を、どの粒度で記録できているか。ログの保管期間と保管場所はどうなっているか。分析の前に、そもそも分析対象となるログが揃っているかを確認します。ここで不足が見つかれば、まず取得設計の見直しが先になります。
ステップ2：検知ルールと閾値を設計する
次に、何を「異常」とみなすかを決めます。自社の業務実態に照らして、営業時間の定義、大量抽出とみなす件数、監視対象とする重要テーブルなどを具体化していきます。ホワイトリストを使う場合は、正常な業務アクセスの洗い出しがこの段階の作業になります。
ステップ3：アラート対応フローを整備する
検知しても、その後の対応が決まっていなければ意味がありません。誰がアラートを確認し、どう一次判断し、不正の疑いがある場合は誰にエスカレーションするのか。この流れを事前に決めておきます。あわせて、点検結果をどう記録し、どう報告するかも設計しておくと、監査対応がスムーズになります。
ステップ4：継続的にチューニングする
運用を始めると、必ず「正常なのに検知される」ケースが出てきます。これを放置するとアラートが形骸化するので、内容を確認して許可リストに追加したり、閾値を調整したりして精度を上げていきます。逆に、業務の変化に伴って新たな監視対象が必要になることもあります。作って終わりではなく、育てていく前提で運用設計するのが肝心です。
まとめ
本記事で解説した内容を整理します。
- 監査ログは1日数百万〜数千万件規模になり、手作業レビューやサンプリングでは不正を捉えきれない
- 自動化のアプローチは3つ。既知パターンを捉えるルールベース検知、許可した操作以外を捉えるホワイトリスト、他システムのログと照合するログ突合
- Insight PISOは、通常と異なるアクセスパターン・大量データ抽出・営業時間外アクセス・新規アクセス元という観点で異常を検知できる
- Insight Inspectorが、iDoperationの作業申請ログとInsight PISOのDB操作ログを突合し、申請外作業や申請予定時間を超えた操作を全件点検できる
- 導入は、ログ取得状況の確認 → 検知ルールの設計 → アラート対応フローの整備 → 継続的なチューニングの順で進める
監査ログ分析の自動化をご検討の方へ
「監査ログは取得しているが活用できていない」「申請記録とDB操作ログの突合を自動化したい」「膨大なログから不正の予兆を見つけたい」——インサイトテクノロジーでは、Insight PISO・Insight Inspector・iDoperationによるデータベース監査ログの取得から分析・突合・点検の自動化までを一貫してご支援しています。実際の検知やレポートの動きは、デモでご確認いただけます。
▼ Insight PISOの詳細を見る
https://www.insight-tec.com/products/piso
▼ Insight InspectorおよびiDoperationの詳細を見る
https://www.insight-tec.com/products/piso/inspector
▼ 監査ログの取得・分析・点検についてまず相談する
https://www.insight-tec.com/products/piso/inspector/#f
