[第8回] 誰が顧客情報を参照したのか — QueryPie監査ログでDB利用履歴をたどる

第7回では顧客の電話とメールをマスキングした。開発者には伏せた連絡先を表示し、原文が必要な担当者だけを例外にした。

次は配送問い合わせの後で「4002番は誰が参照しましたか」と確認された場面を考えた。管理者はどこで何を探せばよいのだろう。

QueryPie ACPの監査ログを調べた。開発者はDBeaverで配送待ち一覧を、顧客担当者はWeb SQL Editorで特定注文の連絡先を参照した。その上で、 異なるツールで行った作業が管理画面にどう残るかを 確認した。

普段どおりの注文参照から始める

Orders Control Labと架空の注文・連絡先を使った。QueryPie ACP Community 11.6.7で二人とも読み取り専用だ。

開発者としてDBeaverで番号と状態をstatus = 'PENDING'で検索すると、4001と4003が返った。

顧客担当のDemo ApproverはWeb SQL Editorを使い、注文と連絡先をJOINしてWHERE o.order_id = 4002で1件を取得した。第7回の原文確認例外が適用されている。

開発者も4002の連絡先を参照したが、電話とメールは隠れたままだった。配送待ち一覧、担当者の連絡先参照、開発者のマスキング参照という三つの記録を作った。

日付とDB接続で記録を探す

Audit → Databases → Query Auditで当日の記録を選び、Connection NameをOrders Control Labにした。

直前の操作が時刻、成否、ユーザー名・メール、接続名、権限とともに並んだ。二人の記録が同じ一覧に集まり、各画面を行き来せずに済んだ。

次にNameでDemo Developerを検索した。開発者の記録だけに絞られ、DBeaverの実行時刻から配送待ち参照を見つけられた。

DBeaverのSQLを管理者画面で確認する

15時48分39秒の記録を開くと、Demo Developer、Success、Read-Only、Executed From: Agentless Proxyと表示された。

下部にはorders_control.ordersへのSQLがあり、WHERE status = 'PENDING'とDBeaverのApplicationNameコメントも残っていた。

接続者が分かるだけでなく、もう一歩踏み込めた。 どのテーブルをどの条件で参照したか、実行SQLを根拠に説明できる。 開発者はDBeaverで作業し、管理者はQueryPieで記録を探せた。

4002番を確認した担当者も探す

名前をDemo Approverに変え、15時48分31秒の記録を開くと、担当者名、Success、Web Editorと表示された。

SQLにはordersとcustomer_contactsのJOIN、電話・メール列、WHERE o.order_id = 4002があり、探していた注文の参照だと確認できた。

注目したのはユーザーの区別だ。DB Userはどちらもcontrol_writerでも、QueryPieではDemo DeveloperとDemo Approverに分かれて残る。DBアカウントだけより作業者を把握しやすい。

これで具体的に回答できた。担当者はWebで4002の連絡先を、開発者はDBeaverで配送待ち一覧と同注文の連絡先を参照した。各時刻とSQLを記録で確認できた。

個人情報の保護はマスキングログで確認する

SQLが見つかったので、開発者の連絡先にマスキングが適用されたかも調べた。Databases → Policies → Data Maskingで既存ポリシーのLogsを開いた。

15時49分1秒の開発者参照がData Maskedで、phoneとemailは各1行だった。DBeaverの結果確認と同じ時間帯だ。

Query Auditで誰が何を実行したかを、マスキングログで列の保護適用を確認した。ユーザーと時刻を照合すると、業務と保護結果を一緒に説明しやすかった。

導入後の運用まで考える

アクセス制御の検討では遮断や承認に目が向きがちだ。実際に使うと、正常に行われた業務を後で調べられることも運用担当に役立つと感じた。

別途作業報告を集めて照合する必要はなかった。日付・接続を選び、ユーザー検索でSQLを確認した。DBeaverとWebの作業を同じ監査画面で見られた。

必要な人にDB利用を許可し、利用後は記録を根拠に作業内容を説明できること。 今回はその利点が明確だった。権限やマスキングが監査記録とともに残り、導入後の運用も具体的に想像できた。