皆さん、こんにちは！
クラウドのインフラやセキュリティの世界へようこそ。これからGoogle Cloud（GCP）を使った開発やインフラ管理に挑む方も多いと思います。「安全なシステムを作ろう！」と意気込んでいるところですよね。
今回は、セキュリティの世界でも特に重要で、かつ現場のエンジニアたちが「これさえ押さえておけば大事故を防げる！」と太鼓判を押す「GCP VPC Service Controls」について、一緒に優しく紐解いていきたいと思います。
小難しいセキュリティ用語が出てきても安心してくださいね。身近な防犯の仕組みに例えながら、一歩ずつマスターしていきましょう！
—
1. なぜ「クラウドのデータ流出」は起きてしまうのか？
クラウドサービス（GCPなど）は、いつでもどこからでもインターネット経由でアクセスできるのが便利なところですよね。でも、この「どこからでもアクセスできる」という利便性は、裏を返すと「世界中のどこからでも（攻撃者も含めて）あなたのデータに触れる可能性がある」というリスクを抱えていることになります。
ここで、よくあるセキュリティ対策の誤解を見てみましょう。
従来の「鍵」のイメージ（IDとパスワード）
- やり方: 正しい「合鍵（パスワードやAPIキー）」を持っている人だけが家（クラウド）に入れるようにする。
- 弱点: もしその合鍵がうっかり社外の人に盗まれたり、開発者のミスで公開GitHubに晒されたりしたらどうなるでしょうか？ 泥棒は「正当な合鍵」を持っているため、警備員（Google Cloud）も「どうぞお入りください」と通してしまいます。
結果として、データベースから大量の顧客情報がごっそりダウンロードされてしまう……これが、昨今よくニュースになるクラウドからのデータ流出事件のメカニズムです。鍵を持っている人を信用しすぎた結果の悲劇ですね。
—
2. 身近な防犯で例える「VPC Service Controls」の仕組み
ここで登場するのが、今回の主役である VPC Service Controls（VPC SC） です。
これを分かりやすく例えるなら、「高級マンションの敷地（セキュリティ境界）」のようなものです。
- マンションの敷地（VPC Service Controlsの境界）: ここは安全地帯です。この敷地の外へ、会社の重要なお宝（データを持ち出すこと）を持ち出すことは、原則として固く禁じられています。
- 住民（GCPのプロジェクトやリソース）: 敷地の中に住んでいる人たちは、お互いに自由に荷物をやり取りできます。
- 宅配業者や引っ越し屋さん（外部からのアクセス）: たとえ正しい合鍵（強力なアクセストークン）を持っていたとしても、「敷地の外の怪しいカフェ（許可されていないネットワーク）」から「お宝を持ち出そう」とした瞬間、門番がガッチリと通行を阻止します。
つまり、VPC Service Controlsとは、「合鍵を持っているかどうか」だけでなく、「今、どこからアクセスしていて、どこへデータを持ち出そうとしているか（場所のコンテキスト）」を厳しく見張る、超優秀な門番なわけです。
—
3. 実践！VPC Service Controlsを設定してみよう
「理屈は分かったけれど、実際にどう設定するの？」という声が聞こえてきそうですね。
それでは、実務で使える設定の一例を覗いてみましょう。GCPでは、これを「アクセス制御ポリシー（Access Policy）」や「サービスペリメータ（Service Perimeter）」という設定で形にします。
今回は、コマンドラインツール（gcloud）を使って、特定のプロジェクトを安全な「境界」で囲む設定をコード例で見ていきましょう。
ステップ1：アクセスレベル（どこからならOKか）の定義
まずは、「どのIPアドレスやネットワークからのアクセスを許可するか」という条件をYAMLファイルで定義します。
# access_level.yaml
# 社内の安全なオフィスや、特定のVPNゲートウェイのIPアドレスだけを許可する設定です
title: "社内ネットワークからのアクセス許可"
basic:
conditions:
- ipSubnetworks:
- "203.0.113.0/24" # ここに会社のグローバルIPアドレスなどを指定しますこのファイルを読み込ませて、GCPに「この場所からのアクセスを信頼する」と教え込みます。
ステップ2：サービスペリメータ（境界）の作成
次に、肝心の「データの持ち出しを禁止する城壁（境界）」を作ります。
# 境界（Service Perimeter）を作成するコマンド例
gcloud access-context-manager perimeters create secure_perimeter_demo \
--title="機密データを守るための境界" \
--resources="projects/123456789012" \
--restricted-services="storage.googleapis.com" \
--access-levels="access_levels/office_network_access" \
--asi【コードの解説とポイント】
--resources: 守りたいGCPプロジェクトの番号（プロジェクト番号）を指定します。この中にあるリソースが城壁の中に守られます。--restricted-services: ここが重要です！今回はGoogle Cloud Storage（storage.googleapis.com）を指定しています。つまり、「この境界の外へ、Cloud Storage内のデータを勝手にコピー・ダウンロードさせない」というルールを強制します。--access-levels: 先ほど作った「安全な場所（IP）」の条件を指定しています。
もし、開発者のPC（社外のカフェなど）から、この保護されたCloud Storageに対してファイルをダウンロードしようとすると、GCPは容赦なく以下のようなエラーを返します。
> Access denied by VPC Service Controls （VPCサービスコントロールによってアクセスが拒否されました）
「おっと、そこからの持ち出しは許可されていないよ！」と、門番がピシャリと止めてくれるわけですね。
—
4. 現場のエンジニアがハマる「落とし穴」と対策
さて、ここまで聞くと「VPC Service Controlsって最強じゃん！全部のプロジェクトに入れちゃおう！」と思うかもしれません。ですが、現場のプロとして、少しだけ注意点もお伝えしておきますね。
ありがちなトラブル：自分たちのシステムが動かなくなる
VPC SCを導入すると、今まで普通に動いていたバッチ処理や、別のプロジェクトにあるCI/CDパイプライン（Cloud Buildなど）からStorageへのアクセスが、「外部からの不正な持ち出し」と誤認されて突然エラーになることがあります。
対策：ドライラン（お試しモード）を活用する
いきなり本番環境でガチガチの城壁を作ると、システムが全停止して大パニックになります。そのため、現場では必ず「ドライランモード（--asi や違反ログのモニタリング）」から始めます。
1. 最初は「ブロックはせずに、違反している操作がないかログ（Cloud Logging）だけを観察する」モードで数日間運用する。
2. ログを見て、「あ、この社内システムからのアクセスも弾かれているな」という箇所を丁寧に「例外（アクセスの許可）」として追加していく。
3. 安全が確認できたら、本格的なブロック（エンफोर्सメント）に切り替える。
この「泥臭い確認作業」こそが、インフラ・セキュリティエンジニアの腕の見せ所です！
—
まとめ
今回は、GCP VPC Service Controlsの概念と、データ流出を防ぐ仕組みについてお話ししました。
- 合鍵（パスワード）だけでは、今のクラウドセキュリティは守れない。
- 「どこからアクセスし、どこへデータを持ち出そうとしているか」という境界（ペリメータ）が大切。
- 最初はドライラン（お試しモード）を使って、システムを壊さないように慎重に導入しよう。
セキュリティは「難しそう」と感じるかもしれませんが、一つひとつの機能を「身近な防犯」に置き換えて考えていくと、とてもロジカルで面白い世界です。
皆さんも、ご自身のプロジェクトで大切なデータを守るために、ぜひVPC Service Controlsの導入にチャレンジしてみてくださいね。一歩ずつ、安全なクラウドライフを築いていきましょう！
コメント