現場で叩き上げのエンジニア諸君、今日も境界防御の最前線でお疲れ様だ。
「クラウドを使っているから安全」という幻想は、とっくに過去の遺物だ。特にGCPのようなエンタープライズ環境では、IAM（Identity and Access Management）の権限設定ミスや、開発者が不用意に公開したストレージバケットが、組織全体の機密を灰にする引き金になる。
今日は、境界防御の要である「VPC Service Controls (VPC-SC)」について、理論と実戦の狭間を突いた話をしよう。
1. なぜ「IAMだけ」では不十分なのか？
多くのエンジニアが陥る罠は、認証（IAM）を過信することだ。例えば、攻撃者があなたの会社の開発者の端末から有効な認証トークンを盗み出したとする。その場合、IAMの権限が正当なユーザーとして扱われるため、通常のアクセス制御は無力化される。
そこで登場するのがVPC-SCだ。これは、「誰が」アクセスできるかだけでなく、「どのネットワークから」アクセスしているかというコンテキストを強制するものだ。たとえ正しい認証情報を持っていても、許可された境界（サービスペリメータ）外からの操作であれば、Google CloudのAPIレベルで弾き飛ばす。これが、データの持ち出し（Exfiltration）を防ぐ最後の砦となる。
2. 攻撃者が狙う「盲点」：データ流出のPoC的視点
攻撃者はしばしば、悪意あるGCPプロジェクトを立ち上げ、そこからターゲットのCloud Storageバケットへ gsutil cp を試みる。もしVPC-SCが正しく設定されていなければ、適切なIAM権限を持つ認証情報さえあれば、データは静かに吸い出される。
これを防ぐには、「ペリメータの境界」を厳格に定義し、不要な通信をデフォルトで遮断する必要がある。
3. 実践：VPC-SCの設定ファイル（Terraform）
GUIでポチポチ設定するのは、インフラ・コード化（IaC）の時代にはナンセンスだ。以下のTerraform設定は、特定のVPCネットワーク内からのみGoogle Cloud APIへのアクセスを許可する基本的なペリメータ構築の例だ。
# Google Cloud VPC Service Controls のリソース定義
resource "google_access_context_manager_service_perimeter" "service_perimeter" {
parent = "organizations/1234567890" # あなたの組織ID
name = "accessPolicies/1234567890/servicePerimeters/prod_perimeter"
title = "production_perimeter"
status {
# 制限対象とするサービスを指定
restricted_services = [
"storage.googleapis.com",
"bigquery.googleapis.com"
]
# この境界内に含めるプロジェクト
resources = ["projects/9876543210"]
# アクセスレベル（特定のIP範囲のみ許可）
access_levels = [google_access_context_manager_access_level.basic_level.name]
}
}
# 特定のIPアドレス範囲（オフィスやVPNゲートウェイ）のみを許可するレベル
resource "google_access_context_manager_access_level" "basic_level" {
parent = "accessPolicies/1234567890"
name = "accessPolicies/1234567890/accessLevels/office_ip_range"
title = "office_ip_range"
basic {
conditions {
# 許可するソースIP（CIDR形式）
ip_subnetworks = ["203.0.113.0/24"]
}
}
}この設定を適用するだけで、攻撃者がどれほど巧妙に認証情報を盗み出しても、許可されたネットワークの外側からはAPI呼び出しが拒否されるようになる。
4. 運用上の注意点：インシデントハンドリングの極意
VPC-SCを導入すると、最初は必ずと言っていいほど「正常な通信」が遮断される。これを解決するために、まずは dry-run モード で導入すること。
VPC-SCには「監査モード」が存在する。設定をいきなり適用するのではなく、status ではなく spec として定義することで、ポリシー違反をブロックせずにログだけを出すことができる。
# 設定を反映する前に、ログを確認して「誤検知」を潰す
gcloud access-context-manager perimeters update prod_perimeter \
--set-policy-spec=spec.yaml \
--policy=1234567890ログを確認する際は、Cloud Logging で以下のクエリを投げよう。
# ペリメータによる拒否ログを抽出するクエリ
resource.type="audited_resource"
protoPayload.metadata.violationReason="NETWORK_NOT_IN_ALLOWED_NETWORK"最後に：エンジニアとしての矜持
セキュリティは「設定して終わり」のツールではない。日々変わるクラウドの仕様と、それを逆手に取る攻撃者の思考を読み解く、知的な対戦ゲームだ。
VPC-SCは強力だが、万能ではない。暗号化されたデータの機密性（AES-256での暗号化など）と、エンドポイントの保護（EDRの導入）、そして境界防御の三層構造を意識してほしい。
一つ言えるのは、「自分の書いたコードや設定が、いつか必ず突破される」という前提で設計すること。その謙虚さが、最高の結果を生む。君たちのシステムが、明日も堅牢であることを祈っている。
コメント