[第47回] 遮断されたSQL実行を通知で受け取る

権限外SQLの遮断の次に、担当者が監査を開かなくても試行を知れるか気になった。

AlertsでRead-OnlyのUPDATE遮断を通知し監査と比較した。止めるだけでなく担当へ伝えるところまでつながった。

通知先をつなぐ

GeneralのChannelsでHTTPを作り、Macの簡単な受信先を登録した。下の受信画面は実送信内容を見せるための実習UIだ。

Body Templateは初期値の {{message}}を使い、Alertsの文面を送る構成にした。

今回DBの遮断SQLだけを通知する

Alertsの種別は Prevented SQL Executionとし、対象は既存の DB Privilege Account Lab 一つに絞った。このDBの権限外操作に集中できる。

変数で人・接続・時刻・SQL種別・原文を入れ、発生時に値を埋める。受信者が状況を把握できる情報を選んだ。

参照は成功し変更は止まる

テスト利用者はRead-Onlyのみ。41001はREADY、25,000ウォンと正常に返った。

同接続でEP47_BLOCKEDへUPDATEすると、 No permission to execute UPDATE statementと出て、参照権限による変更はQueryPieが遮断した。

再参照も元データもREADYのままで、必要参照は続き未許可変更は反映されなかった。

その遮断SQLが通知で届く

受信は1件で、正常参照二回の間のUPDATEだった。利用者・接続・実DBアカウント・UPDATE原文が含まれた。

実行も受信も13:28:31だった。テスト送信はせず、実際のSQL遮断による通知だ。

単なるエラー通知より人とSQLがあるため、誰がどこで何を試したか素早く把握できる点が有用だった。

送信結果と監査を確認する

Alerts詳細のLogsに応答ok、状態 Successと13:28:31があり、設定だけでなく実送信を確認できた。

Query Auditも同時刻の開発者・Read-Onlyで、前後SELECTはSuccess、UPDATEはFailure・Preventedだった。

詳細には通知と同じSQLとUPDATE権限不足が残り、受信した作業を監査でも追えた。

参照許可、変更遮断、試行通知までつながった。全監査を常時見ず必要事象を受け取れ、制御と運用確認の負担軽減を併せる機能と感じた。