はじめに
皆さんこんにちは。今週で5月が終わってしまいますね。今回は2024年11月に対応されたAWS DMSのデータマスキング機能を実際に試してみたので、その使用感をまとめていきたいと思います。まずは、データマスキングの目的について簡単に紹介していきましょう。
なぜデータマスキングをしなければならないか
データマスキングの目的は個人情報や機密情報を保護しながら、安全に開発・テスト。パフォーマンスチューニングなどを行う必要があります。特に本番環境に保存されている氏名・住所・電話番号・クレジットカード情報などのセンシティブなデータはローカル開発環境やStaging環境にそのまま持ち出すことはNGです。実際のデータを使用せずに、本番環境と同等の環境をStaging環境で構築し、テストや検証を行えるようにすることが求められます。
Using data masking to hide sensitive information
- https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html
- https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Masking.html
- Data Masking: Digits Mask (数字のマスキング化)
- Data Masking: Digits Randomize (数字のランダム化)
- Data Masking: Hashing Mask (ハッシュ化)
AWS DMSではデータマスキングの変換ルールを使って、テーブルの特定カラムの機密データをマスクできます。マスクされたデータはターゲット側に保存され、元のデータはそのまま運用できます。
準備
- Aurora MySQL クラスタA(ソース)
- Aurora MySQL クラスタB(ターゲット)
クラスタAにはあらかじめ、以下のテストデータを作成しておきました。このusersテーブルのname、emailカラムを今回クラスタBに対してマスキングを反映されるような流れとなります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
USE test; CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com'), ('Bob', 'bob@example.com'), ('Charlie', 'charlie@example.com'), ('Dave', 'dave@example.com'), ('Eve', 'eve@example.com'); |
レプリケーションサブネットグループの作成
まずはレプリケーションインスタンスに紐づけるサブネットグループを作成しましょう。デフォルトのサブネットグループを指定すると以下のように謎の文字列があるからレプリケーションインスタンスが作成できないよとエラーが出ますが、AWSのバグなのかは不明。
The parameter ReplicationSubnetGroupDescription must not contain non-printable control characters.
レプリケーションインスタンスの作成
レプリケーションインスタンスではエンジンバージョンを最新の3.6.1を選択します。ちなみにレプリケーションインスタンスは中間インスタンスで、EC2のマネージドみたいなものですね。
エンドポイントの作成
- Aurora クラスタA(ソース)
- ソースエンドポイントを選択
- RDS DBインスタンスの選択 > クラスタAを指定
- エンドポイント識別子やリソースネームを選択
- ターゲットエンジンはAmazon Aurora MySQL
- エンドポイントデータベースへのアクセスは一旦手動で提供するを選択
- Aurora クラスタB(ターゲット)
- ターゲットエンドポイントを選択
- RDS DBインスタンスの選択 > クラスタBを指定
- エンドポイント識別子やリソースネームを選択
- ターゲットエンジンはAmazon Aurora MySQL
- エンドポイントデータベースへのアクセスは一旦手動で提供するを選択
上記DBの接続先を設定しましょう。テストで接続できることを確認したら完了です。
データ移行タスクを作成
- タスク設定
ターゲットテーブル準備モードはターゲット上のテーブルを削除を選択してください。切り捨ての場合はデータ損失の可能性があるのと、動作的には既存のターゲットテーブルとメタデータは残しますが、移行前に全ての既存データが削除されてしまいます。
- テーブルマッピング
新しい選択ルールの追加では対象となるテーブルやカラムを指定し、どのようなマスキング処理を行うかを設定できます。今回は設定項目が多いため、JSON形式で設定しました。nameカラムとemailカラムにはハッシュマスキングを指定しています。設定を保存した後、タスクを開始または再起動することで、マスキング処理が反映されます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
{ "rules": [ { "rule-type": "selection", "rule-id": "xxxx", "rule-name": "xxxx", "object-locator": { "schema-name": "test", "table-name": "users" }, "rule-action": "include", "filters": [] }, { "rule-type": "transformation", "rule-id": "xxxx", "rule-name": "mask_name", "rule-target": "column", "object-locator": { "schema-name": "test", "table-name": "users", "column-name": "name" }, "rule-action": "data-masking-hash-mask" }, { "rule-type": "transformation", "rule-id": "xxxx", "rule-name": "mask_email", "rule-target": "column", "object-locator": { "schema-name": "test", "table-name": "users", "column-name": "email" }, "rule-action": "data-masking-hash-mask" } ] } |
動作確認
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
mysql> show databases; +--------------------+ | Database | +--------------------+ | awsdms_control | | information_schema | | mysql | | performance_schema | | sys | | test | +--------------------+ 6 rows in set (0.00 sec) mysql> use test; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> select * from users; +----+------------------------------------------------------------------+------------------------------------------------------------------+---------------------+ | id | name | email | created_at | +----+------------------------------------------------------------------+------------------------------------------------------------------+---------------------+ | 1 | 3BC51062973C458D5A6F2D8D64A023246354AD7E064B1E4E009EC8A0699A3043 | FF8D9819FC0E12BF0D24892E45987E249A28DCE836A85CAD60E28EAAA8C6D976 | 2025-05-26 06:42:00 | | 2 | CD9FB1E148CCD8442E5AA74904CC73BF6FB54D1D54D333BD596AA9BB4BB4E961 | 5FF860BF1190596C7188AB851DB691F0F3169C453936E9E1EBA2F9A47F7A0018 | 2025-05-26 06:42:00 | | 3 | 6E81B1255AD51BB201A2B8AFA9B66653297AE0217F833B14B39B5231228BF968 | ADD7232B65BB559F896CBCFA9A600170A7CA381A0366789DCF59AD986BDF4A98 | 2025-05-26 06:42:00 | | 4 | 809A721743350C0C49A7B444AD3AEAF1341FDD48D1BF510E08B008EDAB72DC70 | 7B34211350FF567970974E1E2B98D319A601969E74FD1A957BC889B8332D00EB | 2025-05-26 06:42:00 | | 5 | B9BAE658D96579857EFE22DEE62673A31355446DDC6AD270EC046AA8C717081C | D0574C4966D2C326193622FEEBC64991C5B59807AE68FA8255B26C79F4BF917A | 2025-05-26 06:42:00 | +----+------------------------------------------------------------------+------------------------------------------------------------------+---------------------+ 5 rows in set (0.01 sec) |
実際にAurora MySQLのクラスタBで確認してみると、nameカラムとemailカラムがしっかりとマスキングされていることが確認できました。実行時間はデータ量が少ないのでなんとも言えないですが、比例すると思うので、UPDATEと変わらない気がします。
まとめ
設定項目が多いため、IaC管理は必須ですね。以前ではLambdaや独自スクリプトを用いてマスキング処理を行うケースが一般的だと思いますが、AWS DMSで手軽にマスキングができるようになったのは大きなメリットです。
しかし、現時点ではマスキング方式がハッシュと数字のランダムに限られているため、テストがしにくいところがデメリットですね。今後のアップデートに期待です！
AWS DMS初めて触ったけども、Terraform化すればよかった。
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/dms_replication_instance
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/dms_endpoint
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/dms_replication_task
0件のコメント