[第13回] 精算情報が必要なとき — QueryPieの制限データアクセス承認

第9回では注文を参照可能にし、精算テーブルを制限した。普段状態だけを見る開発者に精算情報まで開く必要はなかった。

では注文金額と精算の照合が必要になったらどうか。今回はQueryPieの Restricted Data Access Requestで制限テーブルへのアクセスを申請した。期間と理由を記載して承認後、DBeaverで同じSQLを再実行した。

承認前に拒否された精算参照は成功し、注文も引き続き参照できた。今回はその画面と結果をまとめる。データはすべて前回までの架空データだ。

1. 精算テーブルは引き続き参照できない

開発者のDBeaverでsettlement_detailsから4002番の精算番号、注文番号、金額を検索した。

テーブルへのアクセス権がないと表示され、既存のData Accessが制限していた。

今回は制限を維持したまま承認を受けたい。精算確認のたびに共通ポリシーを変更せず対応できるかを確かめる。

2. 精算アクセスの承認担当を決める

Approval RulesでOrders Lab - Settlement Review Approvalを作り、Restricted Data Access Requestを指定した。

Demo Approverを指定し、開発者の申請を担当者が確認する。自己承認は無効にした。

DB接続の申請と、接続済みDB内の制限データ申請は別の業務だ。QueryPieでは対象に合う申請種別と規則を分けて構成できた。

3. 必要なテーブルと時間を指定する

開発者がRestricted Data Access Requestを開き、「注文4002の金額照合のための精算参照」とした。

Orders Control Labのorders_control、settlement_detailsを指定した。11月8日17〜18時の1時間とし、精算金額の照合が理由と記載した。

申請対象はsettlement_detailsテーブルだ。4002番は業務対象であり、実際の参照時のWHERE条件として指定した。

「少し開けて」と個別に頼む代わりに、対象・期間・理由を一つの申請に残して待つ流れが明確だった。

4. 担当者が確認して承認する

Demo ApproverのReceived Requestsで申請者、テーブル、時間、理由を確認して承認した。

照合のため17〜18時の利用を許可するとコメントした。処理後はDoneにApprovedで表示された。

例外権限にも根拠が残る。誰が何の業務で精算を必要としたかを承認内容とともに調べられる。

5. 同じDBeaverで精算金額を参照できた

承認後、開発者のDBeaverの同じ接続で、失敗していたSQLを再実行した。

精算番号9002、注文4002、架空金額87,000が返った。共通制限の削除もDB接続権限の変更も行っていない。

ordersも参照し、4002の状態と金額が正常に返った。慣れたツールで精算確認と通常の注文確認を続けられた。

6. 制限データも業務に合わせて承認できる

第9回の制限を実際の業務につなげた。普段は保護し、必要時は対象と期間を指定して申請する運用ができた。

特によかったのは、 アクセス制限と例外承認を併せて管理できることだ。利用者は必要データを申請し、担当者は理由と範囲を確認して許可できる。

承認された開発者はDBeaverで作業を続けた。保護規則を維持しながら必要アクセスに対応する運用を説明しやすい機能だ。