Redshiftで本番データ参照をよりセキュアに運用してみた

>100 Views

November 27, 25

#wealthnavi #aws #sre

スライド概要

2025年11月27日に開催した「聞いてくれよ、うちのAWSセキュリティ事情〜五反田JPビルの集い〜」で使用した資料です
イベント詳細：https://codmon.connpass.com/event/371471/

ウェルスナビ株式会社技術広報チーム

@WN_Tech-PR

スライド一覧

ウェルスナビ株式会社技術広報チームの公式アカウントです。

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

Java21とSpring Boot3.2を採用して新規事業を開発した話

ウェルスナビ株式会社技術広報チーム 30.8K

ECSで満足していたのに、なぜEKSへ？：事例で学ぶ設計と運用の勘所

wealthnavi cloudnativedays eks ecs

ウェルスナビ株式会社技術広報チーム 29.9K

リアルな過去からたどり着いた事業成長を牽引するエンジニアの在り方

ウェルスナビ株式会社技術広報チーム 29.5K

監視SaaSが使えなくなった話

ウェルスナビ株式会社技術広報チーム 18.9K

WealthNavi Tech Talk vol.1_2023.11.14

tech talk

ウェルスナビ株式会社技術広報チーム 13.9K

Copilot Code Reviewを試してみた

wealthnavi ios ai

ウェルスナビ株式会社技術広報チーム 13.4K

各ページのテキスト

Redshiftで本番データ参照をよりセキュアに運用してみた 2025.11.27 聞いてくれよ、うちのAWSセキュリティ事情〜五反⽥JPビルの集い〜森祐太朗 1

1. 背景‧課題 2. 概要 a. Redshiftを使った動的データマスキング基盤 3. 気をつけたこと a. Redshiftのユーザー管理 b. Redshiftのコスト最適化 c. 注意点 4. まとめ 3

Redshiftを使った動的データマスキング基盤ゼロETL統合について ● ● ETLパイプラインなしで、数秒以内にAurora → Redshift にデータ連携 Auroraへの負荷影響は最小限（拡張バイナリログを有効化時）動的データマスキングされたものを参照開発者ゼロETL （レプリケーション） Redshift 新マスク済DB Aurora 連携設定の管理本番DB SRE © WealthNavi Inc. All Rights Reserved. 8

10.

11.

Redshiftのユーザー管理 IAM Identity Centerを利⽤することでユーザー管理が不要に監査テーブルを突き合わせれば、誰が何のクエリを実行したかの確認も可能 sys_connection_log 開発者 Redshift Query Editor v2 監査テーブルを突き合わせ Redshift sys_query_history ユーザー連携 IAM Identity Center © WealthNavi Inc. All Rights Reserved. Entra ID 11

12.

Redshiftのコスト最適化（1/2） Redshift ServerlessのRPUについて ● Redshiftノードは「インスタンス」もしくは「Serverless」を選択可能 ○ 当社は運⽤コストを減らすため、Serverlessを選択した ● Redshift SeverlessはRPUの値によって利⽤料⾦が変わる ○ ○ RPUは開発者が投げるクエリに加え、レプリケーションでも消費される⼤量データ書き込みによるコストスパイクを避けるためRPUを固定化した RPU消費パターン1 開発者のクエリ開発者 © WealthNavi Inc. All Rights Reserved. RPU消費パターン2 レプリケーション Redshift Aurora 12

13.

Redshiftのコスト最適化（2/2）レプリケーション失敗時の⾃動復旧を実装 ● ● Auroraで大量データ更新が発生した際にレプリケーションが停止してしまう RPU不足が原因の場合、再同期するだけで復旧可能なため、処理を自動化した大量のデータ更新 ECS エラーメトリクス 1. replication停止 Aurora Redshift CloudWatch Alarm Step Functions EventBridge バッチジョブ 2. replicationエラーが発生したテーブルの同期再開 © WealthNavi Inc. All Rights Reserved. 13

14.

注意点1 連携テーブルのフィルタ条件の上限件数が99件起こったこと ○ 当初は参照データ範囲やRPU消費を最⼩にするため、テーブル単位で指定 ○ Redshiftを利⽤する開発者が増え、連携テーブルが増えたことで、フィルタ条件の上限件数（99件）の存在に気付く対応⽅針 ○ テーブル単位の指定をやめ、preﬁx指定（+*）に変更 ■ スキーマレベルの指定も可能 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/zero-etl.filtering.html#zero-etl.filtering-format © WealthNavi Inc. All Rights Reserved. 14

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/zero-etl.filtering.html#zero-etl.filtering-format

15.

注意点2 ゼロETL 利⽤中は Aurora のブルー/グリーンデプロイ機能が使えない起こったこと ○ Auroraクラスタのアップグレード検証時、スイッチオーバーボタンを押したタイミングでエラーメッセージが出⼒された対応⽅針 ○ アップグレード作業前に連携を解除 → 作業完了後に再連携させる ■ Redshiftのデータベース再作成が必要 ■ マスキングポリシーの再作成‧割当が必要 ● ⼀連の流れをスクリプトで⾃動化 ■ 再連携は初回連携と同程度の時間がかかる https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/zero-etl.html#zero-etl.reqs-lims-general © WealthNavi Inc. All Rights Reserved. 15

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/zero-etl.html#zero-etl.reqs-lims-general

16.

17.

まとめ課題本番DBにのみ存在する最新データが必要になるケースにおいて、依頼を受けたSREがクエリを投げる運⽤が、調査の遅延や DB負荷リスクを⽣んでいた動的データマスキング機能により開発者自身で素早く安全に調査可能に binlogレプリケーションなので負荷は最小限 Redshiftを活⽤することで解決できた先日公開したテックブログもご覧ください https://zenn.dev/wn_engineering/articles/dynamic-data-masking-database © WealthNavi Inc. All Rights Reserved. 17

https://zenn.dev/wn_engineering/articles/dynamic-data-masking-database

18.

重要な注意事項 ● 本資料は、断定的判断を提供するものではなく、情報を提供することのみを⽬的としており、いかなる種類の商品も勧誘するものではありません。最終的な決定は、お客様⾃⾝で判断するものとし、当社はこれに⼀切関与せず、また、⼀切の責任を負いません。 ● 本資料には将来の出来事に関する予想が含まれている場合がありますが、それらは予想であり、また、本資料の内容の正確性、信頼性、完全性、適時性等を⼀切保証するものではありません。本資料に基づいて被ったいかなる損害についても、当社は⼀切の責任を負いません。また、当社は、新しい情報や将来の出来事その他の情報について、更新⼜は訂正する義務を負いません。 ● 本資料を利⽤することによりお客様に⽣じた直接的損害、間接的損害、派⽣的損害その他いかなる損害についても、当社は⼀切の責任を負いません。商号等：ウェルスナビ株式会社金融商品取引業者関東財務局長（金商）第2884号加入協会：日本証券業協会一般社団法人日本投資顧問業協会 © WealthNavi Inc. All Rights Reserved.

19.

20.

https://recruit.wealthnavi.com/

21.