はじめに
はじめまして、システム基盤チームでSREをしている森と申します。
今回は、本番DBにアクセスすることなく、開発や運用に必要なデータを適切に参照できる「動的データマスキング基盤」について紹介します。
背景
これまで開発者は、お客さまからの問い合わせ対応や障害の原因調査の際に、本番環境のDBから機密情報をマスキングした専用DB（以下、マスクDB）を利用してデータを確認していました。
しかし、この運用には、マスクDBが日次でしか作成されないという課題がありました。そのため、最新データが必要な問題が発生した際には、所定の社内手続きを経て本番DBの内容を確認する必要があり、お客さまへの回答や障害復旧に時間を要することがありました。
そこでSREチームでは、RedshiftのゼロETL統合と動的データマスキング機能を採用することで、開発者が機密情報をマスクした状態でリアルタイムにデータ参照できる仕組みを実現しました。
対象読者
- 開発者の本番DB参照における運用課題を抱えている方
- AWSソリューションによる動的データマスキングの実現を検討している方
技術選定について
本題へ入る前にRedshiftで動的データマスキング基盤を構築した理由について説明します。
マスキング処理をしなくても特定のカラムだけ表示させたいならVIEW[1]でも問題ないのではといった意見もあるかもしれません。
もちろん本番DB内でVIEWを作成して特定カラムだけ表示させるという方法でも機密情報を表示させないということは可能です。ただ、本番DBに対してSELECT文を実行することによる負荷上昇の懸念がありましたので、この方法は見送りました。
概要
まずは今回活用したRedshiftについて説明します。
ゼロETL統合
ゼロETL統合とは、Amazon Auroraに書き込まれたデータをETLパイプラインなしでRedshiftに連携する機能です。ユーザーはETLの運用が不要になり、ほぼリアルタイムでのデータ分析が可能になります。
AWSブログより引用[2]
動的データマスキング
動的データマスキングは、Redshift内のデータを変更することなく、マスキングポリシーの設定に応じてデータの表示を動的にマスキングする機能です。
AWS資料より引用[3]
Query Editor
動的データマスキングとは直接関係ありませんが、便利な機能としてQuery Editor v2[4]も紹介しておきます。
Query EditorはWebベースによるSQLクライアントアプリで、ユーザー管理や認証をIdentity Centerの認証に委ねられ、監査ログの管理も容易なので誰が利用したかの監査も追いやすいです。
開発者は、Redshiftに連携されたデータを閲覧する際にQuery Editorを使用します。フェデレーテッドユーザーとして接続するため、新たにパスワードを設定する必要がない点も利便性の1つです。
これらの機能を活用して本番DBの最新データを開発者に提供できる仕組みを構築しました。
構成図
構成図は以下のとおりです。
導入については他社のブログ記事を参考にしました。
マスキングポリシーの設定では、各テーブルのカラムごとにポリシーをアタッチするクエリを発行し、機密情報が含まれるカラムのみをマスキング対象としています。
例として、お客さまの電話番号カラムにマスキングポリシーをアタッチした状態でRedshiftのQueryエディタからデータを参照すると、以下のようにマスキングされます。
ATTACH MASKING POLICY "ポリシー名" ON "スキーマ名"."テーブル名" ("PhoneNumber") TO PUBLIC;
運用開始に向けた準備
動的データマスキング基盤の構築完了後、開発者への説明が必要でした。
SREチームでは毎月「インフラ勉強会」と題した開発者向けの発表会を実施していたため、構築完了のタイミングで勉強会にて発表しました。この発表会にてSREチームで取り組んだことや開発者へ共有したいことなどを定期的に行なっており、過去の様子も録画しているので開発者への共有はスムーズに進められました。
工夫点
実装にあたり苦労したことやそれに向けて解決した工夫点も紹介します。
弊社はTerraformを使ってインフラ管理をしており、Redshiftへの連携もTerraformで設定していました。ただ新規テーブルをRedshiftへ連携する場合、Terraformでは連携テーブルの管理ができなかったためAWS SDKでModifyIntegration API[5]を直接実行してRedshiftへ対象テーブルを渡すようにしています。
他にもAuroraとRedshiftのインテグレーション状態をCloudWatchで監視し、同期失敗を検知したら再同期するStep Functionsを起動させることで人の手による運用作業を減らすようにしています。
自動復旧Step Functions
課題点
工夫して実装したことで改善されたこともある一方で、新たな課題も発生しました。動的データマスキングのソース元となっているAuroraのアップグレードを目的としてブルーグリーンデプロイを実施しようとしたところ、スイッチオーバーに失敗したことがありました。
これはドキュメントにも記載されていますが、ゼロETL統合したAuroraではブルーグリーンデプロイメントによる環境の切り替え作業ができない制限があるためです。
クラスターがブルー/グリーンデプロイのソースである場合、ブルー環境とグリーン環境の切り替え中に既存のゼロETL統合を置くことはできません。最初に統合を削除してから切り替えて、再作成する必要があります。
今のところはアップグレード前にインテグレーションを削除して、完了後再同期するようにして対応しております。
また、新規テーブルの追加作業は開発者から必要なテーブル情報を受け取った後にSREチームがAWS SDKを使用して実行しています。今後の課題としてはGitHub Actionsなどを用いた自動化が挙げられます。
最後に
RedshiftのゼロETL統合と動的データマスキングを活用することで、セキュリティ強度を維持したまま、開発者が最新のデータを参照できるようになり、お客さまからの問い合わせや障害原因の調査スピード向上を実現できました。
今後は、マスキング対象テーブルの追加の効率化など、仕組み自体の運用改善に取り組んでいこうと思います。
参考文献
プロフィール
森 祐太朗
システム基盤グループ システム基盤チーム所属
新卒の会社で金融機関のシステム運用を経験。その後複数の転職を経てウェルスナビ株式会社にSREとして入社。現在は資産運用サービスや新規プロダクトのインフラ環境構築を中心にサービス運用改善、監視運用、IaC開発などを担当しています。
-
https://aws.amazon.com/jp/blogs/news/getting-started-guide-for-near-real-time-operational-analytics-using-amazon-aurora-zero-etl-integration-with-amazon-redshift/ ↩︎
-
https://pages.awscloud.com/rs/112-TZM-766/images/20241107-ANALYTICS-2-AWS.pdf ↩︎
-
https://docs.aws.amazon.com/ja_jp/glue/latest/webapi/API_ModifyIntegration.html ↩︎
Discussion