【入門編】 GCP VPC Service Controlsによるデータ流出防止 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやクラウドのセキュリティを担当していると、毎日ドキッとするようなニュースを目にしませんか？「またどこかでデータが流出したらしい…」なんて聞くと、自分の管理しているシステムは大丈夫だろうかと冷や汗が流れますよね。

特に、Google Cloud（GCP）のような便利なクラウドを使っていると、「ちょっとした設定ミスで、社内の大切なデータが世界中に丸見えになってしまった！」なんて事故が本当に起こり得るんです。

今回は、そんなクラウドのデータ流出を防ぐための強力な盾、「GCP VPC Service Controls（VPC SC）」について、難しい専門用語をできるだけ省いて、身近な防犯の例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、一緒に安全な仕組みを学んでいきましょう！

—

1. クラウドのデータ流出って、どうやって起きるの？

まずは、攻撃者がどうやってクラウドからデータを盗み出そうとしているのか、その手口を少しだけ覗いてみましょう。

皆さんは、会社の金庫室を想像してみてください。頑丈な扉（ファイアウォール）があって、関係者しか入れないようになっていますよね。でも、もしその金庫室の中に「誰でも自由に使える合鍵」が落ちていたり、うっかり窓が開けっぱなしになっていたりしたらどうでしょう？

クラウドの世界でもこれと全く同じことが起きます。
例えば、開発メンバーの一人が、自宅のカフェの無料Wi-Fiから社内のGoogle Cloud環境（Cloud Storageなど）にアクセスしたとします。その際、もしアカウントのパスワードが盗まれていたらどうなるでしょうか？
攻撃者は、その盗んだパスワードを使って、あなたの会社の正当な従業員になりすまし、クラウドの玄関から堂々と入ってきて、大切な顧客データを自分のパソコンに「ダウンロード（持ち出し）」してしまうのです。

ファイアウォールというのは、いわば「建物の外から中へ入る通信」を見張るもの。しかし、すでに正規の権限（あるいは盗まれたパスワード）を持っている人が、データを外へ持ち出す動きまでは、通常のファイアウォールだけでは止められないことが多いのが現実なんですね。

—

2. 自宅の「宅配ボックス」で例えるVPC Service Controlsの仕組み

ここで登場するのが、今回の主役である VPC Service Controls（VPC SC） です。
これって一体どんな仕組みなのか、私たちの身近な「一戸建ての防犯」に例えてみましょう。

皆さんの家には、郵便受けや宅配ボックスがありますよね。
通常、家の中（プライベートな空間）と外（インターネットという危険な世界）の間には、玄関のドアがあります。しかし、クラウドサービス（Google CloudのBigQueryやCloud Storageなど）は、インターネットという「外の道路」に直接面しているようなものなんです。つまり、玄関の鍵を閉め忘れたら誰でも中に入れてしまいます。

そこで、VPC Service Controls を使うとどうなるか？
Google Cloudという広大な土地の中に、「見えない頑丈なガラス張りのフェンス（セキュリティ境界）」をポコッと建てることができます。

このフェンスの中にあるデータ（お宝）は、例え外から「この家の合鍵（パスワード）を持っています！」という人が現れたとしても、「会社が指定した安全なネットワーク（会社のオフィスや、許可された特定のVPN）の中からじゃないと、中のデータに触らせません！外の道路からの持ち出しは一切禁止！」というルールを強制できるのです。

今までのセキュリティ： 「誰がアクセスしたか（パスワードや鍵）」だけで判断していた。だから鍵が盗まれるとアウトだった。
VPC Service Controlsのセキュリティ： 「誰が」に加えて、「どこから（どの安全な場所から）アクセスしているか」という境界線（エリア）でガチッと縛る。だから、仮にパスワードが盗まれても、外の怪しい場所からのデータ持ち出しはガッツリ阻止できる！

これが、VPC Service Controlsの正体です。すごく心強い味方だと思いませんか？

—

3. 実践！VPC Service Controlsを設定してみよう

「理屈は分かったけれど、実際にどうやって設定するの？難しそう…」と思うかもしれませんが、安心してください。基本的な考え方はシンプルです。

今回は、社内の大切なデータが眠るバケット（Cloud Storage）を、この「見えないフェンス」で囲む手順を、設定ファイルのサンプルを交えながら見ていきましょう。

GCPでは、こうした境界の設定を accessContextManager という仕組みを使って定義します。実務ではYAMLファイルなどの設定や、Google Cloudのコンソール画面、あるいはTerraformなどのツールを使って構築します。

以下は、VPC Service Controlsの「アクセスポリシー」と「サービス境界（Perimeter）」を定義するイメージのYAML設定例です。

# VPC Service Controls の境界（Perimeter）を定義する設定ファイル例
# この設定によって、特定のプロジェクト間や、許可されたネットワーク以外からの
# データ持ち出しをブロックする「見えないフェンス」を作ります。

apiVersion: accesscontextmanager.v1
kind: ServicePerimeter
metadata:
  # アクセスポリシーのIDを指定します（実際の環境に合わせて変更してください）
  name: accessPolicies/123456789012/servicePerimeters/secure_data_perimeter
spec:
  status:
    # このフェンス（境界）の中に含めるGoogle Cloudプロジェクトのリスト
    resources:
      - projects/987654321098 # 社内の機密データを扱うメインのプロジェクト

    # フェンスの中のデータにアクセスすることを許可する「サービス」の指定
    # 今回はGoogle Cloud Storage（データの保存場所）を指定します
    restrictedServices:
      - storage.googleapis.com

    # 【重要】例外的にアクセスを許可するネットワーク（アクセスレベル）の指定
    # 例：会社の社内ネットワークのIPアドレス範囲など
    accessLevels:
      - accessPolicies/123456789012/accessLevels/company_office_ip_only

この設定のポイント

1. resources: ここに登録されたプロジェクト（お宝がある部屋）が、丸ごとフェンスで囲まれます。
2. restrictedServices: どのサービスに対する不正な持ち出しを防ぎたいかを指定します。今回は代表的なストレージサービスである storage.googleapis.com を守っています。
3. accessLevels: 「ここからのアクセスなら例外的に通すよ」という安全地帯のルールを紐づけます。このルールに合致しない場所（例えば、見知らぬ海外のIPアドレスや、自宅の野良Wi-Fiなど）からのデータダウンロードや外部転送は、容赦なくエラー（アクセス拒否）になります。

—

4. 現場でありがちな落とし穴と、優しく乗り越えるコツ

さて、いざこの強力なVPC Service Controlsを導入しようとすると、現場のエンジニアからこんな悲鳴が上がることがよくあります。

> 「先生！フェンスを張ったら、社内のシステム連携バッチまでエラーで止まっちゃいました！」

そうなんです。セキュリティをガチガチに固めると、今まで当たり前に動いていた社内の正規のシステムや、連携している別のクラウドサービスまで「おっと、外からの怪しい動きだな！」と勘違いしてブロックしてしまうことがあるんですね。これを「セキュリティーの厳しすぎによる業務停止（可用性の低下）」と呼びます。

この問題をスマートに解決するための、現場の泥臭いコツをご紹介します。

ドライラン（Dry Run）モードを活用しよう

いきなり本番環境でフェンスを閉め切るのではなく、まずは「ドライラン・モード（監視モード）」という機能を使います。
これは、文字通り「フェンスは透明なままにしておき、もし本当にフェンスを閉めたら、どの通信がブロックされるのかをログに記録してテストする」という優しい機能です。

Google Cloudのログ保管場所（Cloud Logging）を確認すると、以下のようなログが溜まります。

{
  "insertId": "abc123xyz",
  "jsonPayload": {
    "type": "VPC_SERVICE_CONTROLS_VIOLATION",
    "violationReason": "SERVICE_NOT_ALLOWED_FROM_UNSUPPORTED_LOCATION",
    "request": {
      "methodName": "google.storage.v1.Storage.GetObject",
      "principal": "service-account@my-project.iam.gserviceaccount.com"
    }
  },
  "severity": "WARNING"
}

このログを眺めて、「あ、この社内システムのアカウントは、例外的に通してあげる必要があるな」と確認しながら、先ほどの accessLevels や例外設定（トランスミッションルール）を丁寧に調整していくのです。

一気にすべてを完璧にやろうとせず、「テストして、ログを見て、ルールを整えて、最後にカギをカチッと掛ける」。このステップを踏むことが、システムを壊さずにセキュリティを高める一番の近道になります。

—

さいごに

今回は、GCP VPC Service Controlsについて、身近な防犯や家の鍵に例えながら解説してきました。

セキュリティの対策と聞くと、「なんだか難しそう」「自分の書いたコードやインフラ設定のせいでシステムが止まったらどうしよう」と不安になるかもしれません。でも、仕組みの本質はとてもシンプルです。

「どこから・誰が・何に触ろうとしているのか」という境界をしっかり引くこと。
いきなりすべてを塞ぐのではなく、ドライランでテストしながら優しく導入すること。

この2つを意識するだけで、あなたのクラウド環境の安全性は劇的に向上します。データ流出という最悪のシナリオを防ぐために、今日からできる一歩として、ぜひVPC Service Controlsのコンセプトを頭の片隅に置いてみてくださいね。

あなたの開発ライフとインフラ運用が、安全でワクワクするものになりますように！