[第9回] 注文参照は許可し、精算情報は保護する — QueryPieのテーブルアクセス制限

DB接続が許可されても、すべてのデータが必要とは限らない。注文状態を確認する開発者に精算金額や内部メモまで必要ではないからだ。

その区別をQueryPie ACPで試した。同じDBに注文・精算テーブルを置き、開発者は注文を引き続き参照できるが精算にはアクセスできない設定にした。

普段の参照を維持しながら、保護するテーブルだけを制限できるだろうか。 DBeaverで適用前後に同じSQLを実行した。

まず精算情報を参照できる状態を確認する

QueryPie ACP Community 11.6.7のOrders Control Labで、ordersの隣にsettlement_detailsを作った。架空の精算番号、注文番号、金額、内部メモを3件投入した。実際の顧客・会社の精算資料は使っていない。

Demo DeveloperがQueryPie経由のDBeaverで接続した。登録済みDBアカウントには両テーブルの参照権限を用意した。

設定前は9001〜9003の3件と金額・メモが返った。これを適用後との比較基準にした。

精算テーブルを保護するポリシーを作る

Databases → Policies → Data AccessのCreate PolicyでOrders Lab - Settlement Accessを作り、Orders Control Labを指定した。

Add Rule Listでorders_controlとsettlement_detailsを選択した。テーブル全体を保護するためColumn Nameは指定せず、Allowed Usersにも例外は追加しなかった。

保存後の一覧にDBとテーブルが表示された。ordersは対象に含めていない。何を制限するかが一覧で分かり、設定を確認しやすかった。

同じSQLでも精算参照が遮断された

DBeaverで同じ精算SQLを実行すると、データではなくアクセス権の確認を求めるメッセージが出た。

「You don't have permission to access the table 'orders_control.settlement_details'」と対象も表示された。適用前に見えた精算情報は取得できなくなった。

DBeaverの接続情報もDB側SELECTも変えていない。追加したData Access規則がQueryPie経由の参照に適用された。

接続権限があっても業務に不要なテーブルまでは読めないよう範囲を絞れた。接続許可後の権限設計を具体的に確認できた。

注文参照はそのまま続けられた

遮断確認後、同じDBeaver接続でordersの番号と状態を参照すると、4001・4003はPENDING、4002はDELIVEREDと正常に返った。

ここが今回いちばんよかった点だ。 開発者は注文状態の確認を続けながら、精算だけを別に保護できた。利用者はDBeaverを維持し、管理者はQueryPieで保護対象を選ぶ。

部門間で同じDBを使う場面が浮かんだ。接続許可に加えて見られるテーブルを決めれば、業務別のデータ範囲を細かく管理できそうだ。

遮断された参照も記録される

ポリシーのLogsにはAccess Deniedがあり、Demo Developer、settlement_details、実行時刻が表示された。

Query Detailsを開くと接続、テーブル、ユーザーに加えてDBeaverの実行SQLもあり、Rowsは0だった。

「なぜ参照できないのか」という問い合わせにも根拠を示せる。ユーザーと時刻、SQLの対象テーブルを確認して適用結果を説明できそうだ。

接続を許可した後もデータ範囲を定められる

小さな設定で違いが明確に出た。適用前は注文も精算も参照でき、適用後は精算だけが遮断され、注文は利用できた。

第7回は連絡先の一部を隠し、今回はテーブル自体を制限した。データと業務の性質に合わせて保護方式を変えられる点がよかった。

必要な業務を続け、見る必要のないデータを保護する。 Data Accessではその区別を管理者画面で設定し、利用者のツールで結果を見て、履歴まで確認できた。業務に合わせてDB権限を分けたい担当者に紹介したい機能だ。