[第3回] QueryPie ACPに最初のDBを接続する — 開発者の接続方法はどう変わるか

第2回ではMacにQueryPie ACP Community Editionを導入してログインした。今回はDBを接続し、実際にデータを参照する。

気になったのは開発者側の操作だ。管理者がDBを登録したら、開発者はどこでSQLを実行するのか。Webだけなのか、使い慣れたDBクライアントでも接続できるのか。

テスト用の注文DBを作り、まずQueryPieのWeb画面で参照した。続いてDBeaverにProxy接続情報を直接入力する方法と、PCにMulti Agentを導入して接続する方法も試した。三つの方法ですべて同じ5件の注文が返ることまで確認した。

使用したのはQueryPie ACP Community 11.6.7とMySQL 8.0.42。以下の画面にある顧客・注文はすべて実習用の架空データだ。

1. DBを接続して参照する

まずMySQLコンテナをもう一つ起動した。QueryPie内部のDBと混在しないよう、実習用DBを別に用意した。

DB名はorders_demoとした。customersに顧客4人、ordersに注文12件を入れた。配送待ち注文の検索や状態別件数の集計で、接続と参照を確認するには十分だ。

MySQLにorders_readerを作り、orders_demoへのSELECTだけを許可した。今回は参照のみなのでDBアカウントもその権限に限定した。これは後で設定するQueryPieユーザーの権限とは別だ。

準備ができたので、管理者としてDBを登録し、開発者アカウントに切り替えて接続する。

2. QueryPieにMySQLを登録する

管理者でログインし、Databases → Connection Management → DB ConnectionsでMySQL接続を作成した。入力値は次のとおりだ。

• 接続名：Orders Demo MySQL

• DB種別：MySQL

• Host / Port: orders-db / 3306

• Database Name: orders_demo

• DBアカウント：orders_reader

Hostにはlocalhostではなくorders-dbを指定した。同じDockerネットワーク上なのでコンテナ名で接続できる。ここでlocalhostを指定するとQueryPieコンテナ自身を指してしまう。

社内DBを接続するときも先に確認したい。自分のPCから接続できるかより、QueryPieサーバーからそのDBへ到達できるかが重要だ。

DBアカウントとパスワードを入力し、Test Connectionで成功を確認して保存した。

下部のHide this credential from Connection List pageにもチェックを入れた。ユーザーの接続一覧で元DBの認証情報を隠す設定だ。開発者にパスワードがどう見えるかは、そのアカウントで確認することにした。

3. 開発者には読み取り専用権限を付与する

管理者だけで試すと開発者が実際に見る画面を見落としかねない。General → User Management → UsersでDemo Developer、ログインID demo-devを作成し、管理者ロールはNoneにした。

続いてDatabases → DB Access Control → Access Controlを開き、Demo Developerを選択した。Grant PrivilegeでOrders Demo MySQLへのRead-Onlyを付与した。

DB登録とユーザーへのアクセス権付与は別の作業だった。今回は一人へ直接付与したが、人数が増えればチームのグループ管理がよさそうだ。一時的なアクセスには有効期限も検討したい。

4. 開発者としてログインし、注文を参照する

demo-devでログインし、初回に求められたパスワード変更を済ませた。DatabasesのQueryPie Connectionsを展開するとOrders Demo MySQLが表示された。

接続を選択するとRead-Only (User)、Select権限、Active状態が表示された。ここまで開発者が元のMySQLパスワードを入力する場面はなかった。

ConnectでWeb SQLエディターが開いた。orders_demoから配送待ちの注文を検索した。

SELECT order_id, customer_id, order_date, status, total_amountFROM ordersWHERE status = 'PENDING'ORDER BY order_date, order_idLIMIT 20;

一覧が正常に返ることを確認し、状態別の件数も集計した。

SELECT status, COUNT(*) AS order_countFROM ordersGROUP BY statusORDER BY status;

開発者側の操作はQueryPieにログインし、DBを選び、SQLを実行する程度だった。MySQLのアカウントとパスワードを別途受け取らずに参照できた。

もちろん参照だけで業務は完結しない。このアカウントでは結果のコピー・エクスポートやトランザクション関連の権限は未チェックだった。実運用では必要な機能を許可し、別途検証する必要がある。

5. DBeaverでも接続する

次はDBeaverで同じ注文を参照した。QueryPie Proxyを経由すれば、既存のDBクライアントでもSQLを実行できる。

使ったのはAgentless Proxy。エージェントを別途導入せず、DBクライアントからQueryPie Proxyへ接続する方式だ。

管理者画面でDB接続詳細のProxy Usageを有効にし、Use QueryPie registered accountを選んで保存した。この設定でQueryPieは登録済みDBアカウントを使ってMySQLへ接続する。

開発者画面のProxy Infoには40000番ポートが割り当てられていた。Create Tokenで接続用UsernameとPasswordを発行した。DBeaverには元のMySQLパスワードではなく、このトークンを入力する。

トークンは発行時にしか表示されないため安全に保管した。紛失した場合は既存トークンを破棄して再発行する。以下は値を含まない案内画面だ。

DBeaverを開いてMySQL接続を新規作成した。

• Host: 127.0.0.1

• Port: 40000

• Database: orders_demo

• Username / Password：開発者アカウントで発行したProxyトークン

127.0.0.1はQueryPieとDBeaverが同じMacで動くための指定だ。社内で複数人が接続する場合は各PCから到達できるQueryPie Proxyのアドレスを使い、ファイアウォールでポートが許可されているかも確認する。

Test ConnectionでMySQL 8.0.42への接続を確認した。続いてWebで使った配送待ち注文のクエリをそのまま貼り付けた。

WebとDBeaverのSQLは同じだった。DBeaverではアドレス、ポート、認証情報だけをQueryPie Proxyに合わせた。少なくとも今回のMySQL参照ではDBツールを変えずに使えた。

6. PCにMulti Agentを導入して接続する

接続情報を直接入力するほかに、PCにエージェントを導入する方法もある。今回はQueryPie Multi Agentを導入し、そのDB一覧からDBeaverを開いた。

右上のプロフィールからDownload & Support → Multi-Agentを選択した。Mac・Windows・Linux向けがあり、自分のMacに合うApple Silicon版を取得した。このサーバーが提供するエージェントはv9だった。

取得したdmgを開き、QueryPieMultiAgentをApplicationsへコピーして導入した。

エージェントに登録するのはDBではなくQueryPieのWebアドレスだ。今回はhttp://localhost:8000を登録した。既存ホストがある場合はSettings → Add New Hostから追加できる。複数のQueryPieサーバーを登録できるためMulti Agentという名前だ。

サーバーを選ぶとログイン画面が開いた。Webと同じ開発者アカウントdemo-devでログインした。

管理者が先に行う設定もある。エージェント用Proxyアドレスをサーバーに登録する必要がある。同じMacで動かす今回は公式初期設定ガイドに従って127.0.0.1を登録した。社内サーバーなら社員PCから到達できるIPやドメインを指定する。これは管理者の初期設定であり、開発者が個々のDBで行うものではない。

DatabasesのQueryPie Connectionsを展開するとOrders Demo MySQLが表示され、その下にorders-dbとRead-Only (User)があった。Webで付与した権限をエージェントでも確認できた。

orders-dbを右クリックしてOpen Connection With → DBeaverを選ぶと、DBeaverにOrders Demo MySQL接続が追加された。Webでトークンを発行し、接続情報を一つずつ入力する必要はなかった。

追加された接続を開き、新しいSQLエディターで同じ配送待ちクエリを実行した。今回も1001、1003、1006、1009、1012が返った。

違いは接続準備にあった。エージェントなしではトークンと接続情報を手入力した。Multi Agentではログイン後、DBを選んでDBeaverで開くだけだった。毎日多くのDBに接続するチームなら、両方試して比較する価値がありそうだ。

7. 社内利用に向けてさらに確認すること

実際に接続すると、導入時に誰と何を話すべきかが少し具体的になった。

まずDB登録と権限付与の担当を決める必要がある。今回は一人で役割を切り替えたが、社内では開発者の申請を誰が承認・付与するか決めておかなければならない。異動や退職時の取り消しも同じだ。

実際に使うツールでの検証も必要だ。今回はMySQLとDBeaverで簡単なSELECTを実行した。DataGripや別DBを使うならその組み合わせで試す必要がある。大量参照やトランザクションでも同じ結果になるかは未確認だ。

セキュリティ機能も設定画面だけでは判断できない。Read-Onlyが実際に変更を防ぐか、権限を取り消すと接続済みセッションはどうなるかを試したい。Query AuditはOnだったが、ユーザーとSQLがどう記録されるかは次回確認する。

8. DBへの直接接続経路も確認する

ここで第1回の「侵入後の制御」を思い出した。QueryPie経由では接続できたが、元DBへ直接入れる経路が残っていたらどうだろう。

今回の環境にもその経路が残っている。比較・点検用にMacの127.0.0.1:13306からMySQLへ直接接続できるようにした。DBeaverで使ったQueryPie Proxyは40000番だ。

社内導入ではここも整理したい。接続元を制限し、元のDBアカウントを誰が持つか確認する。接続一覧の認証情報を隠すだけでは、直接アクセスまで遮断されるわけではない。

DBパスワードや開発者PCが侵害されてもQueryPieの制御を通すには、このような接続経路まで管理する必要があると感じた。

次は変更クエリを試す

今回はDB登録、開発者ログイン、WebとDBeaverでの注文参照を行った。DBeaverでは手入力とMulti Agentの両方を試した。使い慣れたツールでSQLを実行しながら、QueryPieで付与された権限でDBを利用できた。

第4回では、読み取り専用で変更しようとしたときのメッセージ、権限取り消し後の接続、記録の場所を確認する。元DBもSELECT限定なので、どちらの層で遮断されるかも切り分ける予定だ。

参考ドキュメント： Database Proxyの有効化 · エージェントなしでのProxy接続 · Multi Agentユーザーガイド · インストール後の初期設定