[第5回] QueryPie ACPでDB権限を申請・承認する — DBeaverでの参照まで試した
2026年11月8日
「注文の精算明細を確認したいので、明日までDBの参照権限をもらえますか」
DB運用ではこうした依頼をよく受ける。どのDBが必要か、参照だけでよいか、いつまで使うかを確認して権限を開く。少数ならメッセージで対応できても、人数が増えるほど、誰が何のために権限を得たかの管理が重要になる。
第4回では読み取り専用のSQL制限と権限取り消し後の遮断を確認した。今回は利用者自身の申請と担当者の承認を試し、承認後にDBeaverでテスト注文も参照した。
今回もMac上のQueryPie ACP Community 11.6.7と実習用MySQLを使った。申請者はDemo Developer、承認者はDemo Approverに分けた。
1. 誰が承認するかを先に決める
管理者画面のWorkflow Management → Approval RulesでDBアクセス用の規則Orders Lab - Read Access Approvalを作り、Demo Approverを指定した。
今回は担当者一人の承認で処理する設定にした。Self-Approvalを無効にし、権限を使う人と承認する人を分離した。

保存後、開発者の申請画面に規則と担当者が表示された。毎回依頼先を探さずに申請でき、運用側も事前に決めた手順で一貫して対応しやすい。
2. 必要なDB・権限・利用期限をまとめて申請する
Workflow → Submit Request → DB Access Requestで、注文精算と配送状態を確認するための申請を作った。変更は不要なのでOrders Control LabのRead-Onlyだけを選んだ。
タイトルは「注文精算確認のための参照権限申請」とした。理由には対象テーブル、目的、参照のみであること、必要期間を記載した。

日付が二つある点が目を引いた。Approval Expiration Dateは承認処理の期限、Access Expiration DateはDBアクセスの有効期限。11月8日に承認を受け、11月9日まで使う申請にした。
単に「DB権限をください」ではなく、どこに、どの権限を、いつまで必要とするかを申請にまとめられた。承認側の聞き返す手間も減る。参照業務に合わせて権限と期間を一緒に定められる点がよかった。
3. 提出した申請は承認待ちになる
SubmitでSent RequestsのIn Progressに登録された。詳細には申請者と承認者が並び、その下でDBとRead-Onlyを再確認できた。

申請者も進捗を直接確認できた。過去のメッセージを探さずに、何を申請し誰の承認待ちかが分かる。複数申請がある場合は便利そうだ。
4. 担当者アカウントで確認して承認する
Demo Approverでログインすると、Received Requests To Doに1件あった。開くと申請タイトル、理由、DB、参照権限、アクセス有効期限が表示された。
参照業務に合う内容と確認してApproveを押した。コメント欄には「注文精算確認のための参照権限を承認します。アクセス有効期限は2026-11-09です」と記載した。

処理後はReceived RequestsのDoneへ移り、対象DBがApprovedになった。申請者、承認者、承認権限が同じ申請に残った。

導入担当の視点でよかったのはこの記録だ。後で「なぜこの人にDB権限があるのか」と問われても、業務理由と承認結果を調べられる。権限一覧から用途を推測する場面が減る。
5. 承認された権限でDBeaverから参照する
開発者に戻ってDatabasesのOrders Control Labを開くと、Read-Only (User)、Select、Active、期限2026-11-09 23:59:59が表示された。申請どおりだ。

管理者画面で権限をもう一度手動追加する必要はなかった。承認内容が利用可能な権限に反映され、同じ内容を二度入力せずに済んだ。
DBeaver 26.2.4で既存のOrders Control - QueryPieを使い、Proxy経由で接続して次のSELECTを実行した。
SELECT *FROM orders_control.ordersORDER BY order_id;
4001、4002、4003の状態と金額が正常に返った。開発者の申請、担当者の承認、使い慣れたツールでの確認まで完了した。

権限を付与する過程まで管理できた
実際に使うと、申請機能は運用業務に合っていた。開発者がDB・権限・期間を指定し、担当者は理由を見て承認する。結果は実アクセス権に反映され、完了申請も再確認できる。
今回のように精算確認で一時的な参照が必要な業務に役立ちそうだ。申請時から参照権限と期限を定め、範囲と期間を明確に管理できた。開発者はDBeaverを使い続けられる。
前回のクエリ制御・権限取り消しに、今回の申請・承認が加わった。誰が接続できるかだけでなく、どの業務のために権限を得たかまでQueryPie内で分かることが印象に残った。
![[第4回] QueryPie ACPの読み取り専用権限でUPDATEを実行したら — クエリ遮断、権限取り消し、監査ログまで](/assets/content/acp-lab-notes/read-only-permissions/01.webp)
![[第6回] QueryPie ACPでSQLを承認してデータを変更する — 通常の参照権限を維持し、必要な作業だけ実行](/assets/content/acp-lab-notes/sql-approval/01.webp)