会員情報DBを安全に利用するためにマスキングする

この記事はナイル Advent Calendar 2021 2日目の記事です。

はじめに

サービスを運営していると本番で発生したバグの調査や機能開発時の動作確認などの際に本番データを使って行えるとなにかと作業がはかどります。
ですが、ユーザーの個人情報やセンシティブなデータをそのまま持ってきて、社内のメンバーが比較的カジュアルにアクセス出来る環境に反映することはセキュリティ的に非常にリスキーであり避けなければなりません。
そこで、本番データのセンシティブな部分をマスキングすることで、実際の本番に近いデータで調査・動作確認が出来るようにします。

マスキングにあたっての要件

• 個人が特定できない程度に非特定化加工する
• （個人ではなく）ユーザーを特定できるようにしたい
• プロダクトの動作画面上で表示される情報からユーザーの当たりが付けられるくらいにはしたい

具体的方法

メールアドレス
原型は残さず、ユーザー特定がしやすいようにユーザーIDを含める形に加工する

ユーザー名
本名が入っているユーザーも居るので最初の1文字目以降は全てマスキングする

ユーザーアイコン画像path
個人の肖像画像が登録されている場合があるのでダミー画像のpathに差し替える

マスキングについて

環境

Aurora MySQL(5.6)

実装方針

今回はSQLだけで実現したいのでMySQLの文字列関数を使います。
MySQL :: MySQL 5.6 リファレンスマニュアル :: 12.5 文字列関数

マスキング対象データ

本番DBをそのまま掲載できないので、今回はちょっとアレンジを加えた架空の会員情報テーブルを使います。
登録データは個人情報テストデータジェネレーターを利用させていただきました。

マスキングするSQL

実際の会員情報テーブルをマスキングするSQLはもっと複雑ですが、エッセンスだけ抽出するとこのような形です。

UPDATE users
SET name = CONCAT(LEFT(name,1), REPEAT('X', CHAR_LENGTH(name) - 1)),
    mail = CONCAT('develop+user_',id,'@example.com'),
    icon_path = '/profile/default.jpg';

マスキング結果

nameの２文字目以降がすべてXでマスキングされています。
mailのメールアドレスがdevelop+user_{ユーザーID}@example.comの体系になっていてメールアドレスからどのユーザーであるかわかるようになっています。¹
icon_pathは単純にデフォルトアイコン画像default.jpgに差し替えただけ。

おわりに

今回は本番データを使って調査・検証する際に個人情報のみマスキングして手っ取り早く安全性を確保する方法を提示しました。
これが必要な際に毎回手作業でやるのも手間なので、シェルスクリプトを作っておいて実行するだけでダンプとマスキングが実行されるようにしておくと便利かと思います。

一方で、個人情報データそのものに起因するバグやお問い合わせの調査をする場合はやはり本番データを参照する必要があります。その際は本番データを参照できる権限を持った限られたメンバーのみで対応するなどでセキュリティ性を担保するように気をつけましょう。

1. Gmailの業務ごとにメールアドレスを作成する機能を活用して[e-mail]のようなメーリングリストを作ればどのユーザー宛にメールを送信してもそこで受信できるのでテスト時に重宝します。 ↩