https://techblog.jmdc.co.jp/entry/2026/03/06/110000

はじめに

JMDCでは、患者の診療情報や個人情報など、厳格な管理が求められるデータを扱います。これらのデータをクラウド上で分析・活用する際、セキュリティの確保とコンプライアンスの遵守は最優先事項です。本記事では、SnowflakeとAWS PrivateLinkを組み合わせることで、¹3省2ガイドラインにどのように対応し、いかに安全なデータ基盤を構築できるかという観点で解説します。

Snowflake + AWS PrivateLinkとは

Snowflakeの特徴

Snowflakeは、クラウドネイティブなデータウェアハウスで、医療機関における大量の診療データや検査データの分析に適しています。

AWS PrivateLinkの役割

AWS PrivateLinkは、VPC内のリソースとAWSサービス間を、インターネットを経由することなくプライベートに接続する技術です。SnowflakeはAWS PrivateLinkに対応しており、この組み合わせにより、完全にプライベートなネットワーク経路を確立できます。

※PrivateLinkの利用にはBusiness Criticalエディション以上が必要です。

3省2ガイドライン（第6.0版）対応表

免責事項 本対応表は、Snowflake + AWS PrivateLinkの構成に基づき、各ガイドライン項目に対する技術的な適合性を整理したものです。ガイドラインへの完全な適合を保証するものではありません。 △ の項目は、追加の設定・運用・契約面での整備が必要となります。実際の適合判断については、必ず専門家にご確認ください。

凡例

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

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

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

認証・アクセス制御

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

監査ログ

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

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

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

この構成のメリット

1. インターネットを経由しないプライベート接続

PrivateLinkを使用することで、Snowflakeへの接続がすべてAWSのプライベートネットワーク内で完結します。これにより以下のメリットが得られます。

データ漏洩リスクの大幅な軽減：インターネット上での通信が発生しないため、中間者攻撃などのリスクを大幅に低減できます
コンプライアンス要件への対応：三省ガイドラインで求められる「ネットワークの分離」を実現できます
セキュリティ監査での説明が容易：「パブリックインターネットを経由しない」という明確な設計になります

2. IPホワイトリスト管理の不要化 / 運用の効率化

従来のパブリック接続では、Snowflakeのアカウントレベルでネットワークポリシーを設定し、許可IPアドレスを管理する必要がありました。PrivateLinkを使用すると以下が実現できます。

VPCレベルでのアクセス制御：セキュリティグループやNACLで制御可能
動的なIPアドレス環境でも安全：NAT Gatewayの変更に影響されません
複雑なIPホワイトリスト管理が不要

3. データ主権とローカリティ

医療データは地理的な保管場所が重要です。

リージョン内でのトラフィック完結：データがリージョン外に出ない設計が可能
接続品質の安定化：プライベート接続により、接続品質が安定します

4. ネットワークトラフィックの可視化

VPC Flow LogsやVPCエンドポイントのCloudWatchメトリクスにより、以下が実現できます。

監査証跡の取得が容易：どのIPからいつ通信があったかをAWS側で記録できます。「誰が」（IDレベル）の特定にはCloudTrailやSnowflakeの QUERY_HISTORY との組み合わせが必要です
異常なトラフィックの検知：セキュリティ監視を強化できます

5. コストの考慮

PrivateLink（Interface型エンドポイント）はエンドポイントごとのAZ時間課金とデータ処理量課金が発生します。複数アカウント構成でTransit Gatewayを採用する場合はさらにアタッチメント課金とデータ転送量課金が加算されます。セキュリティ要件とのバランスを踏まえ、構成選択の前にコスト試算を行うことを推奨します。

Terraformでの構築時の注意点

設定全体を記載すると記述が多岐にわたるため、この構成ならではのポイントに絞って解説します。

1. VPCエンドポイントの作成

Snowflakeのアカウント情報をハードコードせず、snowflake_system_get_privatelink_config データソースから service_name を動的に取得することで、環境差分によるエラーを防止できます。

# PrivateLinkのservice_nameをSnowflakeから動的に取得
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  # カスタムDNS設定を使用するためfalse

  tags = {
    Name        = "snowflake-privatelink"
    Environment = "production"
  }
}

private_dns_enabled を false に設定し、Route53プライベートホストゾーンを明示的に作成することで、複数環境からの接続におけるFQDNの競合を回避し、柔軟な名前解決を実現します。また、マルチAZ構成を確保するため、複数のAZにまたがるサブネットを指定してください。

セキュリティグループは443番ポートのインバウンドのみを許可し、送信元はアプリケーションサーバーやデータ連携サーバーのサブネットCIDRに限定することを推奨します。SnowflakeはHTTPSのみを使用するため、ポート80（HTTP）の開放は原則不要です。

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

SnowflakeはアカウントごとのFQDNを持つため、プライベートDNSの設定が必要です。

resource "aws_route53_zone" "snowflake_private" {
  name = "privatelink.snowflakecomputing.com"

  vpc {
    vpc_id = aws_vpc.main.id
  }

  tags = {
    Name = "snowflake-privatelink-zone"
  }
}

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]
}

Snowflakeのアカウント名とリージョンは正確に設定してください。Terraformの dns_entry 属性から取得できるVPCエンドポイントのDNS名は複数エントリが返る場合があるため、適切なものを選択してください。

3. 状態管理とシークレット管理

Snowflakeの管理者認証情報はAWS Secrets ManagerやHashiCorp Vaultに保管し、Terraform変数にプレーンテキストで記述しないようにしてください。Terraform Stateファイルにも認証情報が含まれるため、S3バケットでの暗号化とバージョニングを有効化してください。

また、Snowflake側のネットワークポリシーを設定する際は、誤って自分自身をロックアウトしないよう段階的に適用することを強く推奨します。

複数アカウントからのPrivateLink接続の場合の注意点

1. アーキテクチャパターン

医療機関では、部門ごと・システムごとにAWSアカウントを分離することが一般的です。複数のAWSアカウントからSnowflakeに接続する場合、以下の2つのパターンが考えられます。

パターンA：各アカウントに個別のVPCエンドポイント

アカウント間の完全な分離が実現でき、各アカウントで独立したネットワーク設定が可能です。一方で、各アカウントごとにVPCエンドポイントの作成とSnowflake側での登録作業が必要になります。

パターンB：Transit GatewayまたはVPC Peeringを使用

Snowflake側の設定を1つに集約でき、中央集約管理が容易です。ただし、ネットワーク構成が複雑になること、Transit Gatewayの利用コストが追加で発生することに注意が必要です。

2. Snowflake側の承認プロセス

SnowflakeでPrivateLink接続を使用する際は、VPCエンドポイントIDをSnowflakeに登録する必要があります。この登録プロセスはAWS STSトークンを必要とするため、Terraformでの完全自動化は現時点では非推奨です。以下の手順で進めてください。

Step 1：Snowflakeから接続設定値を取得（Terraform）

セクション1のVPCエンドポイント作成時に snowflake_system_get_privatelink_config データソースを使用することで、service_nameを動的に取得できます。

Step 2：VPCエンドポイントIDをSnowflakeに登録（手動）

Terraform apply後に取得できるVPCエンドポイントIDを使い、SnowflakeコンソールまたはSQLクライアントで以下を実行してください（ACCOUNTADMIN権限が必要です）。

SELECT SYSTEM$REGISTER_PRIVATELINK_ENDPOINT(
  '<vpce-xxxxxxxx>',   -- aws_vpc_endpoint.snowflake.id
  '<aws-account-id>',
  '<sts-token>'        -- AWS STSから取得した一時トークン
);

Step 3：接続テストの実施

各アカウントから接続テストを行い、ネットワーク経路を確認してください。

承認フローとして、新しいVPCエンドポイントを追加する際はSnowflake側でACCOUNTADMIN権限を持つユーザーによる承認が必要です。また、SnowflakeからExternal StageやExternal Functionsなど外部サービスへ接続するアウトバウンド方向のプライベートエンドポイントは、1アカウントあたり最大5つという制限があります。過去7日以内に削除したエンドポイントもこの上限にカウントされる点に注意してください。インバウンド方向（顧客VPC→Snowflake）の上限については公式ドキュメントに明示的な記載はないため、大規模なマルチアカウント構成を検討する場合はSnowflakeサポートへの確認を推奨します。

3. IAMロールとクロスアカウントアクセス

複数アカウントでSnowflakeのExternal Stageを使用する場合、Hub Accountに集約したIAMロールをSnowflakeに引き受けさせる構成が一般的です。Snowflakeが提供するExternal IDを正確に設定し、各ロールには必要最小限の権限のみを付与してください。クロスアカウントアクセスではバケットポリシーとIAMポリシーの両方の設定が必要な点に注意してください。

4. ネットワーク設計の考慮事項

Transit Gateway経由の構成では、ルーティング設定（Spoke AccountのVPCからHub AccountのVPCエンドポイントへのルート）と、Route53 Resolverエンドポイントによるプライベートホストゾーンの名前解決が必要になります。なお、Transit Gateway経由のPrivateLinkエンドポイントに対するセキュリティグループ参照はサポートされていないため、セキュリティグループの制御はCIDR範囲で行ってください。

5. 監査とログ管理

複数アカウント環境では、統合的なログ管理が重要です。すべてのアカウントでCloudTrailを有効化し、VPC Flow Logsとともに中央ログアカウントのS3バケットへ集約することを推奨します。集約先バケットには複数アカウントからの書き込みを許可する適切なバケットポリシーを設定してください。「誰がどのデータにアクセスしたか」はSnowflake側の QUERY_HISTORY ビューで監査できます。