[第27回] DBeaverはそのまま、DB直接接続は閉じる — QueryPie接続経路の整理

権限と記録をQueryPieで管理しても、従来の直接経路は別途整理が必要だ。今後どこへ接続させるかも導入の重要な問題だ。

DBeaverで直接とQueryPie経由の両方から同じ注文を参照し、直接ポートを閉じた。その後もQueryPieへ新規接続して参照でき、監査に残った。

比較用DBと参照権限を用意する

別MySQLに架空注文3件を入れ、DB Route Labとして登録し、route_readerには参照だけを与えた。

Test Connection成功後、ユーザー一覧で認証情報を隠し、Proxyには登録済みアカウントを使う設定にした。

Demo DeveloperにRead-Onlyを付与した。登録と利用許可は別で、管理者が情報を管理し、利用者は許可された接続を選ぶ方式だ。

DBeaverに直接・QueryPie接続を作る

直接はMacの127.0.0.1:13307、QueryPieはProxy Infoの127.0.0.1:40002。どちらもroute_labを指す。

DBeaverのAgentless ProxyへDemo Developerのトークンを入力した。利用者用情報で認証し、実DBは管理者登録のアカウントを使う。

直接参照で27002、SHIPPED、18,500が返った。これを基準にQueryPieでも同じSQLを実行した。

QueryPie経由でも同じSQLを使える

番号・状態・金額は一致し、DBeaverでSQLを実行して表を見る操作も同じだった。

既存ツールを維持し、管理者はQueryPieで権限を管理できる点がよかった。個別DBパスワード配布の代わりにProxy情報を利用できる。

直接接続ポートを閉じる

両接続を切り、DockerでMacへ公開した13307を削除した。データと内部ネットワークを維持してコンテナを再起動した。

ポート閉鎖はDockerのネットワーク設定だ。残すProxyでQueryPieが認証、権限、SQL監査を担う。経路とユーザー権限を併せて整理する構成である。

直接の再接続は「Connection refused (connect failed)」だった。DB認証情報が保存されていても閉じた経路へは接続できなかった。

QueryPieで再接続すると参照と監査が残る

DBeaverでQueryPieへ新規接続すると、27002のSHIPPED、18,500が再び返った。

Query AuditにはSELECT Success、Demo Developer、DB Route Lab、Read-Only、Agentless Proxyが残った。

DB側はroute_readerでもQueryPieはDemo Developerを識別した。27002のSQLと時刻もあり、DBアカウントと申請者を一画面で見られて便利だった。

道具を変えず接続管理をまとめる

利用者の作業が大きく変わらなかったのがよかった。DBeaver参照はそのままで、経路をQueryPieへ整理すると権限と記録をまとめて確認できた。

ネットワークで直接経路を整理し、QueryPieで誰がどの権限かを管理する組み合わせは有用だ。慣れたツールを使いつつ、人を軸に許可と履歴を集約できた。

QueryPie Community 11.6.7、DBeaver 26.2.4、別MySQLで架空注文を使った。

参考： QueryPie Database Proxy · システム構成とネットワークアクセス