Snowflake + AWS PrivateLinkで作るセキュアな医療データ基盤

参考になった

レビュー投稿日の情報になります

株式会社JMDC / 南栄治郎

メンバー / インフラエンジニア

最終更新日2026/06/19投稿日2026/06/23

利用プラン	ツールの利用規模	事業形態
Business Critical	501名〜1,000名	B to B

利用プラン	Business Critical
ツールの利用規模	501名〜1,000名
事業形態	B to B

アーキテクチャ

アーキテクチャの意図・工夫

データ活用層（複数のAWSアカウント上のコンテナ（バックエンド）・BIツール（Tableau））と、データ管理層（Snowflake）、データ提供層（JMDCが保有する被保険者データ）の3層で構成しています。各レイヤー間の通信はすべてAWS PrivateLinkで接続しており、インターネットを経由しないプライベートな連携を実現しています。

導入の背景・解決したかった問題

導入背景

JMDCでは匿名加工された患者の診療情報や個人情報など、厳格な管理が求められるデータをクラウド上で分析・活用しています。これらのデータを扱う上で、セキュリティの確保とコンプライアンスの遵守は最優先事項となっています。

一方で、既存のデータウェアハウス（Vertica）においては、パフォーマンスとコストのトレードオフや運用負荷の増大といった課題が顕在化しており、コスト改善と運用効率化が求められていました。こうした背景から、セキュリティ要件を満たしつつコスト・運用面の課題を解消する新たなデータウェアハウス（DWH）として、Snowflakeへの移行を検討しました。その際、3省2ガイドライン^[*1]に沿った構成を採用することで、顧客からのセキュリティ監査に対して根拠のある説明ができる体制を整えることも、移行を推進する重要な要因となりました。

ツール導入前の課題

プライベート接続環境・VPNの構築と管理コスト： セキュリティ要件によるネットワーク分離が必要なため、インターネットを経由しないプライベート接続環境の構築が必要であった。また、運用用のVPN環境も別途必要になり、VPNユーザーの管理コストも追加で発生していた
コストと性能のトレードオフ： AWS上のEC2で稼働させているVerticaの料金はパフォーマンスとトレードオフの関係にあり、実運用ではパフォーマンス優先の設定を余儀なくされるため、コストを柔軟に調整することが難しかった
データ容量の上限管理： 保存可能なデータ量がライセンスによって決まる仕様のため、上限に近づくたびに容量の見直しや調整作業が発生し、運用負荷につながっていた
ログの分散管理： ログが複数箇所に分散して管理される構成のため、問題発生時の調査に時間がかかり、トラブルシューティングのコストが高かった

どのような状態を目指していたか

社内のセキュリティ方針として求められる「ネットワーク分離」を実現しつつ、VPN等の追加インフラなしで運用できる環境を構築すること（この構成は3省2ガイドラインの要件とも合致する）
性能を妥協せず、データ処理の負荷に応じた柔軟なコストコントロールができること
データ容量の上限を意識せず、インフラのキャパシティプランニングから解放されること
アクセスログやクエリログが一元管理され、一連の監査証跡を容易に追跡できること

[*1]:医療情報システムの安全管理に関するガイドライン第6.0版（厚生労働省）、および総務省・経産省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」第2.0版

比較した軸

軸	内容
ガイドライン適合性	3省2ガイドラインの要件を技術的に満たせるか
運用負荷	IPホワイトリスト管理やVPN管理などの運用コストを削減できるか
コスト・拡張性	パフォーマンスとコストのバランスが取りやすく、容量制限がないか
ログ・監査	通信経路の可視化・監査証跡の取得が一元的に可能か

選定理由

JMDCでは3省2ガイドラインへの技術的適合とセキュリティ確保を最優先としながら、既存DWHの運用課題（コスト・容量・VPN管理・ログ分散）を解消できるツールへの移行を検討していました。一般的なDWHや既存環境のアーキテクチャと比較した際、Snowflakeの 「ストレージとコンピューティングの完全分離」および「AWS PrivateLinkへのネイティブ対応」　が、すべての課題を同時に解決できる唯一の選択肢でした。

課題	既存環境・一般的な構成	Snowflake導入で解決できる点
ガイドラインへの技術的適合のためのネットワーク分離	インターネットを経由しないプライベート接続環境の構築	AWS PrivateLinkによるネットワーク分離により、インターネットを経由しない接続を実現
監査証跡確保のためのログ一元管理	DWH、ネットワーク、中継サーバー等にログが分散する	アクセスログ・クエリログを一元管理でき、監査証跡の取得も容易
ガイドラインへの技術的適合のための認証・アクセス制御	VPN環境を別途構築	Snowflake RBACとネットワークポリシーによるアクセス制御の一元管理が可能
コストと性能のトレードオフ	性能維持のために常時高コスト、または変更にタイムラグがある	ウェアハウスサイズの動的変更・自動停止により、負荷に応じた柔軟なコスト調整が可能
データ容量の上限管理	ライセンスや事前のプロビジョニングによる容量制限がある	ストレージが独立しておりライセンスなどによる制限がない。使用量に応じた純粋な従量課金で運用できる

導入の成果

改善したかった課題はどれくらい解決されたか

3省2ガイドラインの主要要件に対する技術的な適合状況は以下のとおりです。

凡例： ◎ 対応可能　△ 部分対応（追加措置あり）　- 対象外（または運用でカバー）

ネットワーク・通信の安全管理

要件	対応	主なコンポーネント
通信の暗号化（TLS）	◎	PrivateLink（HTTPS固定）
インターネット経由の通信の排除	◎	VPCエンドポイント（Interface型）
ネットワーク分離	◎	VPC・セキュリティグループ・マルチアカウント構成
通信経路の可視化・監視	◎	VPC Flow Logs・CloudWatch
ゼロトラストに基づくアクセス制御	△	セキュリティグループ（IDベース認証はSnowflake側で別途設定が必要）

監査ログ

要件	対応	主なコンポーネント
アクセスログの取得・保管	◎	VPC Flow Logs・CloudTrail（中央ログアカウントへ集約）
データアクセス履歴の監査	◎	Snowflake `QUERY_HISTORY` ビュー
ログの改ざん防止	△	S3バージョニング（Object Lock の追加設定を推奨）
ログの定期レビュー体制	-	運用ルールの策定が別途必要

認証・アクセス制御

要件	対応	主なコンポーネント
最小権限の原則	◎	IAMロール・Snowflake RBACポリシー
不正アクセスの防止	◎	VPCエンドポイント＋セキュリティグループ
IPアドレスによるアクセス制御	◎	セキュリティグループ・Snowflake Network Policy
二要素認証	◎	Snowflake MFA設定

データ保護・クラウド責任分界

要件	対応	主なコンポーネント
地理的データ保管場所の管理	◎	Snowflakeのリージョン選択によるリージョン固定のVPCエンドポイント
シークレット・State管理	◎	AWS Secrets Manager・S3暗号化＋バージョニング
保存データの暗号化	◎	Snowflakeはデフォルト暗号化済み、S3はSSE-KMS（カスタマー管理キー）ので暗号化済み
クラウド事業者との責任分界の明確化	△	責任分担表の作成・契約整備が別途必要
バックアップ・復旧計画	-	Snowflake Time Travel/Fail-safeで別途対応
外部委託先のセキュリティ評価	-	AWS・SnowflakeのISO27001/SOC2取得状況の確認が必要

⚠️ 免責事項 本対応表はSnowflake + AWS PrivateLinkの構成に基づく技術的な適合性の整理です。ガイドラインへの完全な適合を保証するものではありません。△ の項目については、追加の運用規程整備および契約対応により適合を実現しています。実際の適合判断については専門家にご確認ください

どのような成果が得られたか

強固なセキュリティとコンプライアンスの確立： インターネットを経由しないプライベート接続を実現し、データ漏洩リスクを大幅に低減。リージョン内でトラフィックが完結する設計により、データ主権に関するコンプライアンス説明が容易になりました。
インフラ運用コストの劇的な削減： 閉域接続のために必要だったVPN環境や、複雑なIPホワイトリスト管理から完全に脱却。NACLやセキュリティグループによるAWSネイティブなアクセス制御に一本化できました。
容量制限からの解放とコスト最適化： ライセンスによるデータ容量上限を気にする必要がなくなり、ストレージと計算リソースの分離によって、処理負荷に応じた柔軟なコスト調整（無駄な課金の抑制）が可能になりました。
確実な監査証跡の確立： VPC Flow LogsとSnowflakeの QUERY_HISTORY を組み合わせることで、「どのIPから・誰が・何にアクセスしたか」を一元的に、かつ迅速に調査できる体制を構築しました。

導入に向けた社内への説明

上長・チームへの説明

上長への説明では、Snowflakeが既存のVerticaと比較してもパフォーマンス面で問題なく、ストレージとコンピューティングの分離によりコストのバランスがとりやすいDWHであることを説明しました。

また、チームへの説明では、PrivateLinkの導入に手動手順が残るため、Terraform管理の範囲と手動手順の境界について合意を取りました。

活用方法

JMDCで提供している分析サービスのデータ基盤として利用しています。具体的には以下の用途で活用しています。

健保様向けレポートの集計・加工処理
BIツール（Tableau）へのデータソースとしての接続
複数のAWSアカウント上のバックエンドサービスからのデータ参照

よく使う機能

機能	概要
AWS PrivateLink統合	VPCエンドポイントを経由した閉域接続を実現。インターネットを経由しないため、セキュリティ監査での説明が明快
QUERY_HISTORYビュー	誰が・いつ・何のクエリを実行したかをSQL一本で確認できる。データアクセスの監査証跡として活用
ウェアハウスの動的サイズ変更・自動停止	負荷に応じてオンデマンドでスケールアップ／ダウンが可能。アイドル時は自動停止し、無駄な課金を抑制
Snowflakeネットワークポリシー	接続を許可するIPアドレス範囲をSnowflake側でも制限できる。VPCエンドポイントのセキュリティグループと合わせて多層防御を構成
RBAC（ロールベースアクセス制御）	ロール・データベース・スキーマ単位で細かく権限を付与できる。最小権限の原則に基づいたアクセス管理を実現

構築・設定のポイント（Terraform抜粋）

PrivateLinkエンドポイントの作成

snowflake_system_get_privatelink_config データソースから service_name を動的取得することで、環境差分によるエラーを防止できます。

data "snowflake_system_get_privatelink_config" "main" {}

resource "aws_vpc_endpoint" "snowflake" {
  vpc_id              = aws_vpc.main.id
  service_name        = data.snowflake_system_get_privatelink_config.main.aws_vpce_id
  vpc_endpoint_type   = "Interface"
  subnet_ids          = [aws_subnet.private_a.id, aws_subnet.private_b.id]
  security_group_ids  = [aws_security_group.snowflake_endpoint.id]
  private_dns_enabled = false
}

Route53プライベートホストゾーンの設定

Route53プライベートホストゾーンを明示的に作成することで、複数環境からの接続におけるFQDNの競合を回避できます。

 resource "aws_route53_zone" "snowflake_private" {
   name = "privatelink.snowflakecomputing.com"
   vpc { vpc_id = aws_vpc.main.id }
 }

 resource "aws_route53_record" "snowflake_account" {
   zone_id = aws_route53_zone.snowflake_private.zone_id
   name    = "${var.snowflake_account_name}.${var.snowflake_region}.privatelink.snowflakecomputing.com"
   type    = "CNAME"
   ttl     = 300
   records = [aws_vpc_endpoint.snowflake.dns_entry[0].dns_name]
 }

監査・ログ確認

VPC Flow Logs + CloudWatch Logs Insights で通信経路を可視化
Snowflake QUERY_HISTORY ビューでデータアクセス履歴を監査
CloudTrailを全アカウントで有効化し、中央ログアカウントのS3へ集約

ツールの良い点

ストレージとコンピューティングの完全分離：データ量と処理負荷を独立してスケールできるため、性能を妥協せずにコストを最適化しやすい
AWS PrivateLinkへのネイティブ対応：追加のミドルウェアなしにVPCエンドポイント経由の閉域接続を実現できる
豊富な監査機能：QUERY_HISTORYなどのシステムビューが標準で用意されており、データアクセス履歴をSQLで手軽に確認できる
従量課金・容量無制限のストレージ：事前のプロビジョニングが不要で、使用量に応じた純粋な従量課金で運用できる
ネットワークポリシーによるIPアクセス制御：Snowflake側でも接続元IPを制限でき、インフラ側のアクセス制御と組み合わせた多層防御を構成しやすい

ツールの課題点

PrivateLinkはBusiness Criticalエディション以上が必要：閉域接続に不可欠な機能だが、利用できるエディションが限られるためライセンスコストが上昇する
PrivateLink導入に手動手順が残る：Snowflake側でVPCエンドポイントIDを登録する承認プロセスがあり、完全なIaC化が難しい
アウトバウンド方向のプライベートエンドポイントに上限あり：External Stageなど外部連携用のエンドポイントは1アカウントあたり最大5つの制限がある（過去7日以内に削除したエンドポイントもカウントされる）

株式会社JMDC / 南栄治郎

メンバー / インフラエンジニア