リソース

/

ACP 実習ノート

[第10回] 「必要な列だけを参照してください」— QueryPie Query RulesでSQL利用ルールを適用する

DBアクセス制御

2026年11月8日

「必要な列だけを指定してください」。DB共有チームではよくあるルールだ。注文状態だけ必要でも、習慣的なSELECT *では金額なども取得してしまう。

 

Query Rulesで実習用ordersへのSELECT *を制限し、遮断時の案内文も自分で決めた。

 

設定だけで終わらず、パターンテスト、DBeaver実行、監査ログまで確認した。

 

 

状態確認なのに金額も取得していた

 

環境はQueryPie ACP Community 11.6.7とDBeaver 26.2.4。Demo DeveloperでOrders Control Labへ接続し、架空注文3件を使った。

 

SELECT * FROM orders_control.ordersではorder_id、status、total_amountが返る。状態確認なら前の二列で足りる。

 

画面1. 適用前はSELECT *で番号・状態・金額を取得できた。
画面1. 適用前はSELECT *で番号・状態・金額を取得できた。

 

ルールは単純で、この参照では*の代わりに列名を指定する。金額列へのアクセス自体の禁止ではなく、SQLの書き方を管理する実習だ。

 

 

実習接続用のSQLルールを作る

 

Databases → Policies → Query RulesのCreate Query Ruleで対象をConnectionとし、Orders Control Labだけを選んだ。

 

Match TypeはRegExp、ActionはDeny。SELECT * FROM orders_control.orders形式を検出するパターンを入れた。今回は実際に試したSQL形式を基準に比較した。

 

Error Messageは「Orders Lab policy: SELECT * is restricted. Please specify the required columns.」にした。遮断理由と修正方法が伝わるようにした。

 

 

保存前に二つのSQLを比較する

 

設定内のTest Patternが便利だった。SQLを入力してTestを押すと一致の有無を確認できる。

 

SELECT * FROM orders_control.orders ORDER BY order_id;はPattern matchedとなり、制限したいSQLが該当した。

 

画面2. 全列参照がパターンと一致。同じ画面で動作と案内文も設定した。
画面2. 全列参照がパターンと一致。同じ画面で動作と案内文も設定した。

 

SELECT order_id, status FROM orders_control.orders ORDER BY order_id;はPattern not matched。テスト失敗ではなく、遮断パターンの対象外という意味だ。

 

画面3. 必要列を指定したSQLは遮断パターンと一致しなかった。
画面3. 必要列を指定したSQLは遮断パターンと一致しなかった。

 

遮断対象と許可対象を設定画面で比較でき、意図を確認しやすかった。確認後に保存した。

 

画面4. 有効な規則として登録され、優先度・対象種別・パターン・DENYを確認した。
画面4. 有効な規則として登録され、優先度・対象種別・パターン・DENYを確認した。

 

一覧のTestでも経路PROXY、接続Orders Control Labで試した。DBeaverのコメント付きSQLにも一致し、APPLIED ACTION: DENYと表示された。

 

画面5. 接続と経路を指定したテストで適用規則とDENYを確認した。
画面5. 接続と経路を指定したテストで適用規則とDENYを確認した。

 

 

DBeaverにも指定した案内が出る

 

保存後にDBeaver接続を開き直して全列参照すると、結果ではなくエラー欄に自作の案内が表示された。

 

「SELECT * is restricted. Please specify the required columns.」の前にはquery_rule_id: 1が付き、どの規則かを特定できた。

 

画面6. 全列参照が遮断され、管理者の案内文がDBeaverに表示された。
画面6. 全列参照が遮断され、管理者の案内文がDBeaverに表示された。

 

遮断画面から次に何をすべきか分かる点がよかった。 利用者には必要列の指定を案内し、運用者も同じ文面と規則番号で説明できる。

 

案内どおりorder_idとstatusを指定すると、必要な二列で注文3件が返った。

 

画面7. 列を指定したSQLは成功し、注文番号と状態だけを確認できた。
画面7. 列を指定したSQLは成功し、注文番号と状態だけを確認できた。

 

 

監査にも規則番号と遮断理由が残る

 

Query Auditで16時21分11秒の記録を開くと、Demo Developer、Agentless Proxy、Failure、Preventedだった。

 

詳細には実行SQLとError Messageが残り、DBeaverと同じquery_rule_id: 1と案内を管理者も確認できた。

 

画面8. SQL、規則番号、利用者への遮断メッセージが監査詳細に残った。
画面8. SQL、規則番号、利用者への遮断メッセージが監査詳細に残った。

 

利用者のメッセージと管理者の記録がつながり、単なる失敗より状況を把握しやすかった。どのSQLがどの規則で制限されたかを説明できた。

 

 

チームのルールを実際のDB利用へ反映する

 

小さな規則でも設定から実行結果までつながった。対象を実習DBに絞り、パターンを試し、案内と監査を確認した。

 

特にパターンテストと案内設定が印象的だった。管理者は適用範囲を確認でき、利用者は案内に従って修正し業務を続けられる。

 

チームのDB利用ルールを、実際のSQL実行に反映できること。 Query Rulesはアクセス権とSQLの使い方を併せて管理したい担当者に役立つ。必要列を指定する原則がDBeaverにも適用された。