[第4回] QueryPie ACPの読み取り専用権限でUPDATEを実行したら — クエリ遮断、権限取り消し、監査ログまで

前回はQueryPieにDBを登録し、DBeaverで注文を参照した。接続情報の手入力とMulti AgentからDBeaverを開く方法を試した。

参照できることは確認したので、今度は逆を試したい。読み取り専用の開発者がUPDATEするとどうなるか。管理者が権限を取り消すと、開いている接続も使えなくなるのか。

テスト注文1件への変更、アクセス権の取り消し、管理者の監査画面確認まで行った。環境はQueryPie ACP Community 11.6.7、MySQL 8.0.42、DBeaver 26.2.4。データはすべて実習用だ。

1. MySQLでは変更できるアカウントを用意する

前回のorders_readerはMySQL側でもSELECTだけだった。そのアカウントでUPDATEが失敗しても、結果だけではQueryPieとMySQLのどちらが遮断したか判断しにくい。

そこでorders_controlを別に作り、ordersに架空注文を3件入れた。control_writerにはこのテーブルのSELECTとUPDATEだけを許可した。前回のorders_demoのデータと権限は維持した。

対象は4001番、金額49,000ウォン、初期状態PENDINGの注文。同じSHIPPEDへの変更を、直接接続とQueryPie接続でそれぞれ実行する。

QueryPieにはOrders Control Labを追加した。接続先orders-db:3306、DB名orders_control、アカウントcontrol_writerだ。Test Connectionで確認し、ユーザー一覧で認証情報を隠す設定も有効にした。

DBアカウントは変更できるが、開発者には参照だけを許可する。Databases → DB Access Control → Access ControlでDemo Developerを選び、Orders Control LabにRead-Onlyを付与した。

設定を分けると違いが明確になる。MySQLアカウント自体の権限と、そのアカウントを使う人にQueryPieが許可する操作は別の概念だ。今回はその違いを実際のSQLで確かめる。

2. 直接接続ではUPDATEが実行できた

まずDBeaverからcontrol_writerで直接接続した。Macの127.0.0.1:13306に実習用MySQLを公開している。接続名はorders_controlとした。

接続中のDBアカウントと注文状態を併せて参照した。

SELECT CURRENT_USER() AS db_account, order_id, status, total_amountFROM orders_control.ordersWHERE order_id = 4001;

続いて注文状態を変更した。

UPDATE orders_control.ordersSET status = 'SHIPPED'WHERE order_id = 4001;

変更は成功し、DBでも4001番がSHIPPEDになった。このアカウントにはUPDATE権限がある。次の比較のためPENDINGへ戻した。

3. QueryPie経由では同じUPDATEが遮断された

次はdemo-devの権限でQueryPie Proxyへ接続した。第3回のAgentless Proxy方式だ。Proxy Usageと登録済みDBアカウントの利用を設定し、開発者のProxy Infoからトークンを発行した。

割り当てられたProxyは127.0.0.1:40001。DBeaverには元DBのパスワードではなくトークンを指定した。直接接続と区別するためOrders Control - QueryPieと名付けた。

先ほどのSELECTは成功した。CURRENT_USER()も同じcontrol_writer@%で、QueryPieが登録済みDBアカウントを使っていると分かった。

続いて先ほど成功したUPDATEをそのまま実行した。今回は結果が違った。

SQL Error [1317] [ERROR]: [ENGINE] No permission to execute UPDATE statement. Please check your privileges.

UPDATE権限がないというメッセージだ。MySQLアカウントは変更可能でも、QueryPieで開発者に与えたのはRead-Only。先に直接接続で成功を確認したため、DB側の権限不足とは区別できた。

エラーだけで終わらず再参照すると4001番はPENDINGのままだった。接続番号も記録し、この接続を開いたまま権限を取り消すことにした。

4. 接続中に権限を取り消すとどうなるか

会社ではアカウント作成と同じくらい権限取り消しも発生する。プロジェクト終了や担当変更時には整理が必要だ。では、DBeaverを開いて接続中の人はどうなるのか。

DBeaverをそのままにして管理者画面へ戻り、Demo Developerの一覧でOrders Control Labだけを選んでRevoke、確認でOKを押した。権限一覧からその接続が消えた。

開いていたDBeaverのSQLエディターで同じSELECTを実行すると、注文ではなくCommunications link failureが出た。

切断して再接続も試したが、Cannot obtain sessionで拒否された。取り消しは既存接続にも新規接続にも適用された。

印象的だったのは、権限の取り消しだけで既存接続まで制御できたことだ。別途セッション終了を押す必要はなかった。プロジェクト終了や担当変更時に、利用者がDBeaverを閉じるのを待たずに整理できるのは便利そうだ。

今回の検証では既存接続と再接続の両方に取り消しが適用された。許可から不要なアクセスの回収まで一か所で処理できることを、QueryPieの利点と感じた。

5. DBeaverで実行したSQLが監査画面に残った

最後にAudit → Databases → Query Auditで実行時刻を合わせると、Demo Developerの成功SELECTと失敗UPDATEの両方が見つかった。

UPDATEはResultがFailure、PreventedもPreventedだった。行を開いて詳細を確認した。

詳細にはDemo Developer、Orders Control Lab、Read-OnlyとSelect、DBアカウントcontrol_writer、Client Name DBeaverがあった。実際のUPDATE本文と「No permission to execute UPDATE statement. Please check your privileges.」も確認できた。

DBには共通のcontrol_writerで接続しても、QueryPieでは作業者をDemo Developerとして識別できた。共通DBアカウントの環境で個人別にどこまで追えるか、導入検討時に同じように確かめるとよさそうだ。

参照成功も残っていたが、DBeaverがテーブル情報のために自動実行したSQLも並んでいた。必要な業務記録を探すには、ユーザー・時刻・接続名で絞る方法に慣れる必要がある。

6. 権限設定の次に確認したいこと

確認結果は次のとおりだ。

確認した操作 / 実際の結果

設定でRead-Onlyを選ぶことと、実際のツールで変更が止まるのを見ることは違った。DBeaverを使い続けながら、参照はできて変更はできない差を確認できた。

直接UPDATEが成功した点も忘れたくない。DBへの直接経路と元の認証情報が残れば、その経路にはQueryPieユーザー権限が適用されない。導入時はDBの接続元制限と元アカウント管理も必要だ。

読み取り専用だけで情報流出を防げるわけではない。見えるデータと量、コピーやエクスポートの可否は別途確認が必要だ。今回は参照、UPDATE、取り消しに範囲を絞った。

導入検討では設定を見るだけでなく、開発チームのツールで試したい。禁止SQLが止まるか、取り消し後の既存接続はどうなるか、その操作を監査画面で再確認できるかまで続けて確かめる方法だ。

次は必要な権限を申請して受け取る

今回は管理者が直接付与・取り消しを行った。実際の会社では毎回個別連絡するより、利用者が申請し担当者が承認する手順が必要だろう。

次回は開発者のDB申請から管理者の承認までを追う。必要期間だけ権限を与える方法と、承認後のユーザー画面の変化も確認したい。