機密データを扱うML環境で、従来の手法が破綻した理由

データサイエンティストに機密データを渡しつつ、持ち出しは防ぐ——MLプラットフォーム担当者にとって永遠の課題です。フィンテック企業iBusinessも同じ壁に直面しました。

当初はオンプレミスのエアギャップ環境を提供していました。物理的に隔離されたネットワークでのみデータを扱わせる方式です。しかしリモートワークが標準化すると、この方式は事実上維持不可能となりました。その後はセキュアな仮想デスクトップ（VDI）をデバイス管理ポリシーでロックダウンし、監視員（Proctor）まで配置して統制していました。

問題は3点でした。

  • コスト: 一時的なアクセスであっても常時アクセスであっても、ユーザーごとに専用VDIが必要で、月額$40以上が発生していました。
  • 運用負荷: Jupyter、MLライブラリ、セキュリティパッチをロックダウン環境ごとにメンテナンスするのは膨大な工数でした。
  • スケーラビリティ: DSチームが拡大するほど、コストと複雑性が線形に爆発します。

そこでiBusinessは Amazon SageMaker Studio（フルマネージド型のWebベースML開発環境）へ舵を切り、さらに 3層セキュリティアーキテクチャ を実装することで、データ持ち出し防止と生産性を両立させました。本記事ではその設計を層ごとに分解し、皆さんの環境へどう移植できるかを整理します。

原文はAWS Architecture Blogの根拠資料で確認できます。

Security analyst reviewing three-layer defense architecture diagram for ML data protection on terminal Software Concept Art

3層防御——各レイヤーが何を防ぐのか

要点は「1層で守らず、異なる攻撃面をそれぞれ封鎖する」ことです。iBusinessが実際に構成した構造を層ごとに見ていきます。

Layer 1 — WorkSpaces Secure Browserでアクセス経路そのものをロックする

Amazon WorkSpaces Secure Browserは、マネージド型のChromiumベースブラウザです。ユーザーはローカルPCからこのブラウザ経由でのみ環境へアクセスできます。

主要な設定は以下です。

  • Secure Browserを 専用VPC/サブネット で実行し、アウトバウンドは NAT Gateway を経由させます。
  • データサイエンスアカウント側のIAMポリシーで、NAT GatewayのElastic IPまたはAWSサービス発信リクエストのみを許可 します。
  • ブラウザ側で ファイルのダウンロード/アップロード、クリップボード、印刷をすべて無効化 します。

これにより「ローカルへデータを持ち出す」最も一般的な経路が物理的に塞がれます。

// IAMポリシー例: NAT GatewayのEIPからのリクエストのみ許可
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnlessFromNATGatewayEIP",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "203.0.113.10/32"
        },
        "Bool": {
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

Layer 2 — URL許可リスト + VPCエンドポイントでアカウント間移動を遮断

ブラウザがロックされていても、Web経由でデータを送り出す穴は残ります。iBusinessは URL許可リスト でこれを塞ぎました。

  • 許可: *.aws.amazon.com、特定のSageMaker AIドメイン
  • 遮断: メール、外部ストレージ、その他すべて

次に アカウント間の持ち出し を防ぐため、以下を構成します。

  • AWS Management ConsoleおよびIAM Identity Center用の VPCエンドポイント を作成（インターネット露出なしでVPC内部でルーティング）
  • エンドポイントポリシーで 特定のAWSアカウントのみ許可
  • Route 53プライベートホストゾーン で console.aws.amazon.com、*.console.aws.amazon.com、signon.aws.amazon.com をVPCエンドポイントへリダイレクト
  • Route 53 Resolver DNS Firewall で未承認ドメインのDNSクエリを遮断（DNSベースの持ち出し防止）

ここで重要なのは、これらすべてが「ユーザーに意識させず」に行われる必要がある点です。DS側からは、単にコンソールを開いて作業しているように見えなければなりません。

Layer 3 — SageMaker AI VPCからインターネットを完全に除去する

最後の層は開発環境そのものを隔離します。SageMaker AIはターミナルとIDEアクセスを提供するため、ここが破られると前の2層が無意味になります。

  • SageMaker AI VPCから NAT Gatewayとインターネットルートを完全に削除
  • 必要なAWSサービスへは VPCエンドポイント経由でのみ アクセス
  • エンドポイントポリシーは 組織所有リソースのみに制限（例: 特定のS3バケットへの s3:PutObject のみ許可）
# ネットワーク構成の要約
SageMaker AI VPC
 ├─ Internet Gateway: なし（削除）
 ├─ NAT Gateway: なし（削除）
 ├─ Route Table: インターネットルートなし
 └─ VPC Endpoints: S3, Athena, Lake Formation, CloudWatch, ...

この構造の美点は、「AWSサービスは正常動作、外部インターネットは根本遮断」 という一見矛盾した要件を満たす点にあります。

Cloud architect configuring AWS VPC endpoints and SageMaker AI network isolation in console System Abstract Visual

成果と注意点、そして日本市場での適用文脈

実際の成果

  • VDIユーザーあたり月額 $40+ → $7（約 80%のコスト削減）
  • プロビジョニング 2日SLA → 自動で数分以内にセットアップ
  • デスクトップ運用保守のオーバーヘッドを排除

数字だけ見ると華やかですが、このアーキテクチャは「ただ飯」ではありません。

この技術の限界と注意点

  • 運用複雑性は移転するだけです。 VDI保守の負担が消える代わりに、VPCエンドポイントポリシー・DNS Firewall・Route 53プライベートゾーンを管理する必要があります。初期設計の難易度はかなり高めです。
  • URL許可リストの落とし穴。 AWSドメインを *.aws.amazon.com で開けておくと、そこに含まれるSaaSやドキュメントページ経由で回避経路が生まれる可能性があります。定期的な監査が必須です。
  • 開発者体験（DX）の低下。 ファイル入出力やクリップボードが塞がれると、DSからは「なぜこんなに不便なのか」という声が上がります。Slackにデータスニペットを1つ貼ることもできない環境です。別途コラボレーションチャネル（社内Wiki、社内メッセンジャー連携）を併せて設計する必要があります。
  • DNS Firewallは万能ではありません。 DoH（DNS over HTTPS）のような回避プロトコルまで塞ぐには、別途ポリシーが必要です。
  • 組織規模への依存性。 小規模チームには過剰エンジニアリングになり得ます。ユーザーが10名未満なら、VDIを1台立てる方がコスト効率が良いケースもあります。

日本市場での適用文脈

日本の金融・SI領域では、このアーキテクチャは特に有効です。FISC安全対策基準や金融庁ガイドラインへの対応が求められる組織では、オンプレミスのネットワーク分離をクラウドベースの3層統制で代替する根拠として活用できます。

ただし注意すべきは、日本の規制では依然として「物理的なネットワーク分離」を明記するケースが多い点です。クラウド移行時には、規制解釈を事前に法務・コンプライアンス部門とすり合わせておかないと、アーキテクチャは正しくても監査で指摘される状況が発生します。

もう一点、日本のSI特有の 多重ベンダー環境 ではIAMポリシーが複雑化しがちです。エンドポイントポリシーに「組織所有リソースのみ許可」を設定すると、協力会社アカウントからの正当なアクセスまで遮断される可能性があります。協力会社ごとの例外ポリシーをどう管理するか、事前に設計しておくべきです。

次のステップ学習方向

  1. VPCエンドポイントポリシー（Endpoint Policy） — リソース単位の細かい制御方法を習得してください。
  2. Route 53 Resolver DNS Firewall — ドメインベースの持ち出し防止の実践パターン。
  3. AWS Lake Formation — データ共有そのものを統制する層。本アーキテクチャと組み合わせると相乗効果が大きいです。
  4. IAM条件キー（Condition Keys） — aws:SourceVpce、aws:SourceVpc、aws:ViaAWSService などを自在に扱えることが鍵になります。

Data scientist accessing sensitive ML datasets through locked-down browser with URL allowlisting

まとめ——「防ぐ」より「経路をなくす」が先

この事例の本当の教訓は、特定のAWSサービス組み合わせではありません。データ持ち出し防止とは「遮断機能を後付けする仕事」ではなく「持ち出し経路そのものを設計から除去する仕事」 だという視点です。

  • ローカルへ出る経路（ダウンロード/クリップボード/印刷）→ 除去
  • 外部へ出る経路（URL/DNS）→ 許可リストで絞り込み
  • アカウント間移動経路（VPCエンドポイント）→ ポリシーで封鎖
  • 開発環境のインターネット経路（NAT/IGW）→ 物理的に除去

各層が異なる攻撃面を担当するため、1層が破られても全体は崩れません。これが「多層防御（Defense in Depth）」の実践形です。

自組織へ適用する際は、次の順序をおすすめします。

  1. 現在のデータアクセス統制を監査 してください。どの経路でデータが出ていけるかをリスト化します。
  2. コンプライアンス要件を先に確定 してください。規制が「物理的分離」を求めるのか、「論理的統制」で代替可能かを確認する必要があります。
  3. Layer 3から適用 してください。開発環境の隔離が最もインパクトが大きいです。
  4. DX低下を補償するコラボレーションチャネル を併せて設計してください。これを怠ると、DSがシャドーITを作り始めます。

あわせて読みたい記事

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。