GCP VPC Service Controlsの「深淵」を覗く：境界防御とパフォーマンスの究極的トレードオフ
VPC Service Controls (VPC-SC) は、単なる「境界を作るためのツール」ではない。それはGoogleの巨大なバックボーンネットワークという、地球規模の巨大なスイッチング・ファブリックの上で、パケット単位の制御を強いる「論理的要塞」だ。
インフラアーキテクトがこの境界を設計する際、多くの技術者は「セキュリティ」という名の下にパフォーマンスを犠牲にしがちである。しかし、真のSREは知っているはずだ。セキュリティ設定の不備が引き起こす再送の嵐や、不適切なアクセスレベル評価によるRTT（Round Trip Time）の肥大化こそが、システムのUXを蝕む最大の脆弱性であることを。
今回は、VPC-SCのアクセスレベル評価とイングレス/エグレスルールを、カーネルレベルの挙動とネットワークエンジニアリングの視点から解剖する。
—
1. Access Levelsの評価：論理的評価の裏側にあるコスト
VPC-SCのアクセスレベルは、単なる条件分岐ではない。APIリクエストが投げられた瞬間、GoogleのIAM/Access Context Managerは、リクエストに含まれるコンテキスト（IP、デバイス、リージョン等）を評価する。
ここで注意すべきは、評価の「遅延」だ。複雑なIPレンジや多数の属性を条件に含めると、認証ゲートウェイでの評価コストが増大する。特にTLSハンドシェイクが絡む場合、この「評価時間」がTLSのClientHelloからServerHelloまでの待機時間に僅かながら積み重なる。
設計の鉄則：極小の条件式を目指す
IPレンジによる制限を行う際、CIDRの集約は必須だ。数千行のサブネットを羅列すれば、ルックアップの計算量は増大する。
# セキュリティポリシーのYAML定義例
# CIDRは極力集約し、評価パスを最短にする
accessLevels:
- name: accessPolicies/12345/accessLevels/CorporateOffice
title: CorporateOffice
basic:
conditions:
- ipSubnetworks:
- 10.0.0.0/8 # 拠点からの通信を広域でまとめ、評価ノードを減らす
- members:
- serviceAccount:secure-app@project-id.iam.gserviceaccount.com—
2. イングレス/エグレスルールの「境界」をパケット視点で捉える
VPC-SC境界におけるイングレスルール（ingressPolicies）とエグレスルール（egressPolicies）は、ファイアウォールの「パケットフィルタリング」とは根本的に異なる。これらは「APIメソッドの呼び出し」を制御するレイヤー7に近いものだ。
パケットの断片化とMTUの最適化
VPC-SCの境界を跨ぐ際、HTTP/2やgRPCのヘッダー圧縮（HPACK/QPACK）が効いている場合、境界での評価によってパケットが意図せずバッファリングされることがある。特に、大規模なバイナリ転送を行う場合、パケットサイズが MTU を超えてフラグメンテーションが発生すると、評価ロジックが不安定になるケースがある。
これを防ぐには、TCPのMSS（Maximum Segment Size）を調整し、ヘッダー分を考慮した 1460 以下のサイズでパケットを流すことが肝要だ。
# GCEインスタンス側のNICでMSSを制限し、境界通過時のフラグメンテーションを防ぐ
# 境界を跨ぐ通信が多いサーバーでは、TCPスタックのチューニングが必須
sudo ip route change default via 10.128.0.1 dev eth0 mss 1400—
3. パフォーマンスを殺さないための「トランスポートセキュリティ」最適化
VPC-SCの境界内での通信であっても、TLS 1.3 の採用は絶対条件だ。TLS 1.3は1-RTTでハンドシェイクを完了させるため、境界評価のオーバーヘッドを最小化できる。
さらに、TCP Fast Open (TFO) を活用し、初期ハンドシェイクのRTTを削減することを検討すべきだ。ただし、VPC-SCが境界でAPIを検査する際、TFOのパケットが「未確認のデータ」として破棄されるケースがあるため、検証は必須となる。
—
4. 実践：VPC-SCのエグレス・トラフィックの最適化
特定のCloud Storageバケットに対して安全な境界を維持しつつ、エグレスルールを設定する際は、以下のように destination を厳格に絞る。
{
"egressPolicies": [
{
"egressTo": {
"operations": [
{
"serviceName": "storage.googleapis.com",
"methodSelectors": [{ "method": "google.storage.objects.get" }]
}
],
"resources": ["projects/123456789/buckets/my-secure-bucket"]
}
}
]
}この設定の肝は、methodSelectors を用いて、許可するオペレーションを最小限に抑えることだ。全権限（*）を許可すると、Googleのバックボーン内で発生する評価処理が重くなり、結果としてAPIレスポンスのレイテンシを劣化させる。
—
結論：物理的な「速さ」を論理的な「精密さ」で制御する
VPC-SCは、単なるセキュリティ境界ではなく、Google Cloudという巨大な分散システムにおける「制御プレーン」の一部である。IPレンジの設計、メソッドの選別、そしてトランスポート層のパラメータ最適化。これらすべてが噛み合ったとき、初めて堅牢かつ高速なアーキテクチャが完成する。
トラブルシューティングに際しては、単にログを眺めるのではなく、tcpdump を用いて境界をまたぐ通信のTCPフラグを確認し、どのタイミングで評価による遅延（あるいは拒否）が発生しているかを追いかけてほしい。
クラウドのネットワークとは、結局のところ「物理的な制約」と「論理的な要請」のせめぎ合いである。その境界線上に立つ技術者こそが、現代のインフラアーキテクトに求められる姿なのだ。
コメント