今回は、私が経験したGoogle Cloudセキュリティの洗礼とも言える出来事をご紹介します。
元々セキュリティと運用の効率化を両立させようと、組織をまたいだ監視システムを構築したんですが、そこでVPC Service Controlsという最強の盾に道を塞がれちゃいました...。
ただこの経験は、GCPの裏側のセキュリティ挙動を理解する上で、本当に貴重な学びになりました！
この記事が、同じように組織連携に挑む皆さんの参考になれば嬉しいです！
1. 目指した「最高の監視システム」✨
ある日担当プロジェクトのセキュリティ状況やログを、監視部署に連携することをミッションとして課されました。
そこで、セキュリティ状況やログを監視部門のPub/Subに連携して、情報を集約することにしました。これで監視担当者はアラートを見逃さずに済む！と考えたんです。
理想の設計はこうだった！
情報の流れはシンプル。とにかく情報を監視部署のPub/Subに集める！
| 連携元 (担当PJ・組織) | 情報の種類 | どうやって連携？ |
|---|---|---|
| SCC・Asset Inventory | セキュリティ・リソース情報 | Notification / フィード |
| PJの各種ログ（Audit Log, VPC Flow Logなど） | 監査・ネットワークログ | ログシンク |
「完璧じゃん！」って思ってたんですが、このシンプルな設計こそが、まさか最強のセキュリティ機能に真っ向からぶつかることになろうとは...。
2. VPC SCという「見えない壁」に全ブロックされる！😭
担当システムPJには、めちゃくちゃ厳しいセキュリティ機能であるVPC Service Controlsが適用されていました。
VPC SCは、サービス境界を作って、大切なデータが境界の外に出ないようにガッチリ守る機能です。
ただ問題は、VPC SCから見ると、同じ組織でも、同じ会社の別の部署のPub/Subであっても、境界の外にあれば「外部」として扱われてしまうことなんです！
発生した「全ブロック」の技術的分析
設計した全ての連携が、VPC SCによって「境界違反 (Violation)」として拒否されました。
2.1. データ送信は「外部流出」と判断される
PJ内のログやSCC通知が、境界外にある監視部署のPub/Subへメッセージを送ろうとしたとき。
- VPC SCの判断: 「おい、データが境界外に出ていこうとしているぞ！ ブロック！」
- 学び: ログシンクなどが使うGoogleのサービスエージェントは、境界内から外に出ようとしただけでアウト。組織内でも境界が違えばダメ、というVPC SCの厳格さを痛感しました。
2.2. データ取得は「不正アクセス」と判断される
監視部署のCloud Functionが、担当PJのAsset Inventory APIを呼び出そうとしたとき。
- VPC SCの判断: 「境界の外からのAPIコールだ！ 不正アクセス！ブロック！」
- 学び: 監視部署のサービスアカウントはIAM権限を持っていましたが、VPC SCの壁を前にしては無力。「IAMの許可があってもVPC SCの壁は超えられない」という、セキュリティ機能の絶対的な優先度を知りました。
3. 成長の鍵は「ログ」と「別組織の壁」の認識にあり！🔑
連携が失敗したとき、「IAMの設定かな？」「宛先のURLを間違えた？」と何度も設定を見直しましたが、原因はVPC SCでした。
教訓：ブロックした側のログを徹底的に見よう！
連携エラーの根本原因を探る一番の近道は、ブロックを実行した側のPJの監査ログを徹底的に見ることでした。
-
Audit Logの重要性: VPC SCによるアクセス拒否は、必ずブロックしたPJの監査ログに、
vpcServiceControlsやACCESS_DENIEDといった詳細なエラーとして残ります。
この経験を通じて、表面的なエラーメッセージに惑わされず、セキュリティポリシーのログから根本原因を特定することができました！🙌
組織の壁：境界内に組み込むことができなかった現実
連携エラーの原因がVPC SCだと判明した後、当初は「監視部署のPub/Subを境界内に入れれば解決！」と考えました。
しかし、ここで最大の技術的な制約に直面します。
⚠️ 制約：監視部署が別のGoogle Cloud組織を使っていたため、VPC SCの境界（一つの組織内でのみ定義可能）に組み込むことが技術的に不可能でした。
つまり、直面していた問題は、単なる設定ミスではなく、「組織の壁を越えてセキュアに連携する」という、より大きなセキュリティ設計の課題だったんです。
最終的な解決策：許可ルール（アクセスレベル）での個別対応！
境界内に組み込めない以上、唯一の解決策は、VPC SCの「例外ルール」を設定することでした。
具体的には、アクセスレベルを使って、「監視部署のPub/Subが使うサービスアカウント」や「監視部署のCloud Functionの実行アカウント」からのアクセスを、例外的に境界通過を許可するように設定しました。
この許可ルールによって、ようやくPJからのデータ送信と、監視部署からのAPIアクセスが可能になり、システムが正常に動き始めました！🎉
4. 考察：VPC SC下での組織連携の設計原則
今回の経験から、特に組織をまたいだ連携におけるVPC SCとの付き合い方を明確にしました。
原則1: 組織を跨ぐ連携は「境界外」であることを前提とする
監視部署が別組織の場合、Pub/SubやFunctionは常にVPC SCの境界外のリソースとして扱われます。連携設計の初段階で、境界内組み込みは不可能と判断し、次の原則に進む必要があります。
原則2: 許可ルール（アクセスレベル）による厳格な例外定義が必須
組織を跨ぐ連携を行う場合、許可ルールであるアクセスレベルの設定が唯一の解決策となります。
- セキュリティと利便性のトレードオフ： これは境界に小さな穴を開ける行為です。アクセスレベルには、特定のサービスアカウントや特定のIPアドレス範囲など、可能な限り厳格な条件を設定し、セキュリティリスクを最小限に抑えるべきです。
VPC SCは確かに手強いですが、監査ログを追って原因を特定したことでGoogle Cloudのセキュリティ機能を深く知るためのきっかけになりました!
皆さんも組織を跨ぐ連携に挑む際は、「別組織＝境界外」を念頭に、アクセスレベルの設定を慎重に行ってください！