リソース

/

ACP 実習ノート

[第7回] DB参照は許可し、個人情報を隠す — QueryPieデータマスキング実習

DBアクセス制御

2026年11月8日

第6回では参照権限を維持し、承認済みSQLで必要なデータを変更した。今回は参照時に見える情報に注目した。

 

配送状態を確かめるためにDBを開くと、電話番号やメールまで見えてしまったらどうだろう。処理状況の確認に連絡先全体は必須ではないが、注文参照自体を止めるわけにもいかない。

 

そこでQueryPie ACPのデータマスキングで、 注文番号と配送状態は見せたまま、電話番号とメールだけを隠すことを目標にした。顧客への連絡が必要な担当者には原文を見せる例外も設定した。

 

 

注文を参照すると連絡先まで見えた

 

実習の注文3件に架空連絡先を追加した。名前はDemo Customer A・B・C、メールはexample.testを使用。この記事の名前と連絡先はすべてテストデータだ。

 

環境は従来どおりMac上のQueryPie ACP Community 11.6.7とMySQL。開発者は読み取り専用でQueryPie経由のDBeaver接続を使った。

 

注文と顧客連絡先をJOINし、番号、配送状態、名前、電話、メールをまとめて参照した。設定前は連絡先がすべて原文で表示された。

 

画面1. QueryPie経由のDBeaverで注文3件と架空連絡先を参照した。
画面1. QueryPie経由のDBeaverで注文3件と架空連絡先を参照した。

 

読み取り専用は変更を防ぐが、結果に何を見せるかは別に定める必要がある。今回はマスキングポリシーで設定する。

 

 

電話番号とメールだけをマスキングする

 

Databases → Policies → Data MaskingでOrders Lab - Contact Maskingを作り、Orders Control Labを対象にした。

 

Add Rule Listでorders_controlのcustomer_contactsを指定し、最初にphone列へ標準のphoneパターンを設定した。

 

画面2. phone列に標準のphoneマスキングパターンを指定した。
画面2. phone列に標準のphoneマスキングパターンを指定した。

 

email列も同様にemail1で追加した。まず両列のマスキングを確認するためAllowed Usersは空にした。

 

画面3. email列にemail1パターンを適用した。
画面3. email列にemail1パターンを適用した。

 

保存後は二つの規則が一つのポリシーに並び、DB・列・パターンを一画面で確認できた。今回のように対象が明確なら、電話とメールだけを選んで設定できる。

 

画面4. 連絡先テーブルのphoneとemailにそれぞれ規則を登録した。
画面4. 連絡先テーブルのphoneとemailにそれぞれ規則を登録した。

 

 

DBeaverで同じSQLを再実行する

 

DBeaverへ戻り、接続もSQLも変えずに同じ参照を再実行した。

 

電話番号は010-****-1001のようになり、メールも一部が伏せられた。注文番号、配送状態、顧客名は変わらず、同じ3件が返った。

 

画面5. 同じSQLでも連絡先にマスキングが適用され、注文番号と配送状態は確認できた。
画面5. 同じSQLでも連絡先にマスキングが適用され、注文番号と配送状態は確認できた。

 

便利だったのは、慣れたDBeaverのまま状況確認を続けられたことだ。SQLに文字列を隠す関数も足していない。管理者のQueryPieポリシーが参照結果に反映された。

 

必要な注文情報を確認しながら、不要に連絡先全体を見る場面を減らせた。 導入の視点では、既存DBツールを維持したまま個人情報保護ポリシーを適用できる点が目を引いた。

 

 

誰の参照にマスキングが適用されたかも残る

 

結果確認後に管理者のLogsを開くと、直前の参照がData Maskedと記録されていた。

 

ログにはDemo Developer、Orders Control Lab、customer_contacts、phone・emailが表示され、各列3行と実行時刻が残っていた。

 

画面6. マスキングログでユーザー、列、処理行数、時刻を確認した。
画面6. マスキングログでユーザー、列、処理行数、時刻を確認した。

 

設定するだけでなく、実際のユーザー参照に適用されたと確認できた。運用側が適用状況や履歴を調べるのに役立ちそうだ。

 

 

顧客へ連絡する担当者には原文を許可する

 

すべての業務で連絡先を隠せるわけではない。配送問題で顧客へ連絡する担当者には電話・メールの原文が必要だ。

 

今回はDemo Approverを連絡先確認担当にし、Orders Control Labの参照権限を付与した。電話とメールの両規則でAllowed Usersへ追加した。

 

画面7. 原文が必要な担当者だけをAllowed Usersへ追加。メールの規則も同じ担当者にした。
画面7. 原文が必要な担当者だけをAllowed Usersへ追加。メールの規則も同じ担当者にした。

 

そのアカウントでWeb SQL Editorから同じSQLを実行すると、電話とメールが原文で表示された。DB管理者権限や変更権限を与えずに確認業務ができた。

 

画面8. 許可された担当者のWeb SQL Editorでは、同じ3件の連絡先原文を確認できた。
画面8. 許可された担当者のWeb SQL Editorでは、同じ3件の連絡先原文を確認できた。

 

例外追加後に開発者のDBeaverでも再参照した。こちらは引き続きマスキングされ、一人を許可しても他のユーザーまで解除されるわけではなかった。

 

元DBも別途確認すると電話・メールは投入時のままだった。保存値を伏せ字へ変更せず、ユーザーに返す結果へ適用されていた。

 

 

導入検討の視点でよかった点

 

今回、DB権限をさらに細かく考えられた。同じ注文を見ても、配送状態を確認する開発者と顧客へ連絡する担当者では必要な情報が異なる。

 

列別マスキングとユーザー例外で、その違いをポリシー化しやすかった。開発者はDBeaverを使い続け、連絡担当は許可された原文を確認する。管理者は規則と履歴を一か所で管理できた。

 

アクセス権、SQL遮断、承認に続き、今回は接続後に実際に見える情報まで試した。 DB利用を可能にしながら、業務に必要な範囲へ情報の露出を抑えられることが今回のマスキング実習で最も印象的だった。

 

参考: QueryPie公式ドキュメント — Data Masking