GCP VPC Service Controls：境界線なきクラウドに「物理的な壁」を築く技術
現場でインシデント対応をしていると、よく耳にするセリフがある。「IAM（Identity and Access Management）で権限を絞っているから大丈夫だ」という慢心だ。
しかし、攻撃者はそんな「論理的な境界」を平気で飛び越える。社員のPCがマルウェアに感染し、そのPCに保存されていた強力な権限を持つサービスアカウントキーが流出したら？あるいは、設定ミスでバケットが一般公開されたら？IAMは「誰が」を制御するが、「どこから」を制御しなければ、データの流出は一瞬で終わる。
そこで登場するのが VPC Service Controls (VPC-SC) だ。今回は、Google Cloud環境で「データの持ち出し」を物理的に封じ込める、防御の要塞化について解説する。
—
1. なぜIAMだけでは足りないのか？（攻撃者の視点）
攻撃者は、盗んだ認証情報（Credential）を使って、正規の管理コンソールやAPIを叩く。もし、あなたのデータベースやGCS（Google Cloud Storage）へのアクセスが「認証さえ通れば世界中のどこからでも可能」な状態なら、攻撃者は自宅のPCからでもデータを吸い出せる。
これを防ぐのがVPC-SCによる「サービス境界（Service Perimeter）」だ。この境界線を引くことで、たとえ正規の鍵を持っていても、「許可されたVPCネットワーク内」からでない限り、GCPの各サービスへのリクエストは拒否されるようになる。
—
2. VPC-SCの実装戦略：境界の設定
まずはTerraformを用いた「サービス境界」の定義を見てほしい。これを適用することで、指定したプロジェクト間でのデータの移動すら制限し、データの持ち出しを物理的に不可能にする。
# VPC Service Controls の境界設定サンプル
resource "google_access_context_manager_service_perimeter" "default" {
parent = "organizations/1234567890" # 組織ID
name = "accessPolicies/1234567890/servicePerimeters/default_perimeter"
title = "production_perimeter"
status {
# 境界内に含めるプロジェクト
resources = ["projects/1234567890"]
# 制限対象とするAPI（主要なデータストアを網羅する）
restricted_services = [
"storage.googleapis.com",
"bigquery.googleapis.com",
"cloudsql.googleapis.com"
]
}
}この設定の肝は、restricted_services にある。ここに指定したサービスは、境界の外側からのアクセスに対して「403 Forbidden」を返すようになる。
—
3. 運用時の落とし穴：通信経路の確保
VPC-SCを有効にすると、境界内のVMからGCPのAPIを叩く際も、「インターネット経由」のアクセスは拒否されるようになる。ここで多くのエンジニアがインシデント（通信断）を起こす。
解決策は「限定公開のGoogleアクセス」と「VPC専用のPrivate Google Access」の活用だ。VMには外部IPを付与せず、以下の設定で内部ネットワークのみを通るようにルーティングを強制する。
# VPCのサブネット設定で、限定公開のGoogleアクセスを有効にする（CLI例）
gcloud compute networks subnets update [サブネット名] \
--region=[リージョン] \
--enable-private-ip-google-accessこうすることで、VMはインターネットを経由せず、Googleのバックボーンネットワーク内だけで通信を完結させることができる。
—
4. 開発環境での「泥臭い」デバッグ術
導入初期は、何がブロックされているか把握するために「Dry Runモード」を活用するのが鉄則だ。いきなり強制適用してサービスを止めてしまうのは、SREとして失格と言わざるを得ない。
以下は、拒否されたログをCloud Loggingで抽出するクエリだ。
# 不正なアクセスや境界外からのリクエストを特定するログクエリ
protoPayload.status.code = 7
protoPayload.status.message = "VPC Service Controls: Request is prohibited by organization's policy."もし、特定のツールやCI/CDパイプラインがブロックされているなら、その通信元IPを「Access Level」として許可リスト（Ingress Policy）に追加する。「全開放」ではなく「最小限の許可」が、セキュリティの鉄則だ。
—
5. 最後に：セキュリティは「多層」で戦え
VPC-SCは強力な盾だが、これさえあれば完璧というわけではない。
1. IAMの最小権限の原則を徹底すること。
2. 監査ログ（Cloud Audit Logs）を常時監視し、異常なアクセスを検知すること。
3. 不要なサービス・APIは即座に無効化すること。
「利便性」と「セキュリティ」は、常に綱引きの状態だ。しかし、データを守ることはエンジニアとしての責務である。この記事を読んだ君には、今日から自分の担当するインフラが「守られているか」を再確認してほしい。
設定ミスは即座にインシデントに繋がる。だが、正しく設定されたVPC-SCは、攻撃者が喉元まで迫ったとしても、最後の一線を守り抜く最強の防壁になるはずだ。
堅牢なクラウド構築、健闘を祈る。
コメント