[第32回] 参照理由をSQLと一緒に残す

監査で人とSQLは分かっても、配送問い合わせか処理照合かという目的はSQLだけでは分かりにくい。

実行理由を必須にし、別業務を想定した2件を参照して、何が監査に残るか確認した。

既存の参照権限で始める

DB Route Labの架空注文と開発者のRead-Only・Selectを使った。

Web SQL Editorの事前参照で1件を確認した。追加するのは業務理由だ。

参照時に理由を受け取る設定にする

DB Route LabのAdditional InformationでUser Action Purpose RequiredのSQL Executionを選んだ。

異なる理由を残すため同セッションでの再利用は選ばず、保存後に新接続した。

配送問い合わせの理由を記入する

Run SQLで理由欄が開いた。空のままOKを押すと「Enter a reason.」となり、入力なしでは進めなかった。

いったん取り消し、27002の配送状態と金額を架空問い合わせの回答用に確認すると記載した。

OKでSHIPPED・18,500.00が返った。SQLを書く操作は同じで、理由入力後すぐ結果を見られた。

別の業務には別の理由を残す

同じ接続の27003参照でも再び理由欄が開き、再利用しない設定を確認できた。

架空の処理明細照合のため配送完了状態と金額を確認すると記載した。結果はDELIVERED・32,000.00だった。

同じ注文SELECTでも目的は異なる。その場の理由を残すと後で区別しやすそうだ。

SQLと理由を同じ監査で確認する

Query Auditを人・DB Route Lab・Web Editorで絞ると両方Successで、時刻とDBアカウントもあった。

27002の詳細はQueryにSELECT、Execution Reasonに配送問い合わせの説明が残っていた。

27003には2個目の照合理由があり、同じ人・テーブルでも業務を区別できた。

SQLから理由を推測する必要が減る。人と参照に業務説明が付き、理由を別に集め履歴と照合する手間を減らせる点がよかった。

QueryPie Community 11.6.7のWeb SQL Editorで行い、人・注文・理由は実習用だ。

参考： DB Connections · Web SQL Editor · Query Audit