こんにちは！クラウドインフラの世界へようこそ。第一線でSRE（サイト信頼性エンジニア）をしている筆者です。
日々のインフラ運用、本当にお疲れ様です！「クラウドを使えばシステムが簡単に作れる！」とワクワクして始めたものの、ふと不安になる瞬間ってありませんか？そう、「うちの大切なデータ、うっかり外に漏れてしまわないだろうか……」という恐怖です。
GCP（Google Cloud）には、そんな私たちの不安をきれいに解消してくれる、ものすごく頼もしい門番がいます。それが今回お話しする 「VPC Service Controls（通称：VPC SC）」 です。
「なんだか名前が難しそう……」「パケットとかファイアウォールのお話？」と思われるかもしれませんが、大丈夫です！今回は、小難しいネットワーク用語の代わりに、私たちが普段使っている「郵便配達」の仕組みに例えて、一歩ずつ優しく紐解いていきましょう。
—
1. なぜ「普通の鍵（ファイアウォール）」だけではデータが守れないの？
クラウドのセキュリティといえば、まず思い浮かぶのが「VPCのファイアウォールルール」や「Cloud IAM（アクセス権限）」ですよね。
- VPCファイアウォール: 仮想マシンの「部屋」のドアに鍵をかけるイメージ。
- Cloud IAM: 「この人は入室してよし、あの人はダメ」という「社員証」のイメージ。
これらはとっても重要です。でも、これだけだと「クラウドの大きな弱点」が一つ残ってしまいます。それは何かというと、「API（Googleが提供する窓口）」を通じたデータの持ち出しです。
郵便配達の例えで考えてみましょう
あなたの会社（GCPプロジェクトA）の倉庫には、機密データという名の「宝物」が入っています。
社員証（IAM）を持っているA君が、会社の倉庫に入って宝物をノートに書き写し、それを自分のポケットに入れて、会社の外にある個人用の郵便ポスト（外部のGCPプロジェクトや自分のPC）へ手紙（API経由のデータ送信）としてポーンと投函してしまったら……？
なんと、部屋のドアの鍵（ファイアウォール）も、社員証（IAM）も、「A君は社員証を持っているから倉庫に入っていいよ」と許可しているので、この不正な持ち出しを防げないのです。
「えっ、そんなの困る！」ですよね。そこで登場するのが、VPC Service Controlsです。
—
2. VPC Service Controls（VPC SC）ってなに？
VPC Service Controlsを一言で言うと、「プロジェクトの周りに、絶対に破られない『透明な塀（Perimeter）』を築く仕組み」です。
先ほどの郵便配達の例えに戻りましょう。
VPC SCを導入すると、会社（GCPプロジェクト）の敷地全体に高い塀が作られます。この塀の中にあるデータやサービスは、原則として「塀の外へ持ち出すこと」が一切禁止されます。
たとえ正しい社員証（IAM）を持っているA君であっても、塀の外にある自分の個人ポストに向けて手紙（APIリクエスト）を送ろうとすると、門番がこう言ってガッチリ止めます。
> 「おっと、その宛先は塀の外ですね。社外への持ち出しルールに違反しているので、この手紙は受け付けません！」
これが、VPC Service Controlsによる境界セキュリティとデータ流出防止の仕組みです。ネットワークの物理的な線をいじることなく、Google Cloud全体のAPIの出入り口でガードしてくれる、超優秀なセキュリティの要なんです。
—
3. 実際にVPC SCを設定してみよう！
「理屈はわかったけど、設定って難しそう……」と思っていませんか？
ご安心ください。GCPでは、セキュリティの「塀」を gcloud コマンドやTerraformでスマートに築くことができます。
ここでは、実務でよく使われる gcloud コマンドを使って、実際にセキュリティ境界（Perimeter）を作る手順を見ていきましょう。
ステップ1：アクセス制御の土台となる「アクセスポリシー」を作る
まずは、組織（Organization）全体のルールを束ねる大元の入れ物（アクセスポリシー）を作成します。
# 組織IDを指定して、新しいアクセスポリシーを作成します
gcloud access-context-manager policies create \
--organization=123456789012 \
--title="社内機密データの保護ポリシー"ステップ2：プロジェクトを囲む「塀（Perimeter）」を作る
次に、守りたいGCPプロジェクトを「塀の内側」に指定して、セキュリティ境界を設定します。
# アクセスポリシーIDを指定し、指定したプロジェクトを境界（Perimeter）で囲みます
gcloud access-context-manager perimeters create my_secure_perimeter \
--policy=987654321098 \
--resources=projects/111122223333 \
--restricted-services=storage.googleapis.com,bigquery.googleapis.com \
--title="機密プロジェクトのデータ流出防止境界"ここがポイント！（コードの解説）
--resources: 守りたい対象のGCPプロジェクト番号を指定しています（これが塀の内側になります）。--restricted-services: ここがミソです！今回はCloud StorageとBigQueryを指定しました。つまり、「この2つのサービスを使ったデータの外部持ち出し（ダウンロードや別プロジェクトへのコピー）を厳しく監視・ブロックする」という意味になります。
これで、プロジェクトAのデータは、許可されていない外部の宛先への流出からガッチリ守られました！
—
4. 現場で役立つ！「例外（アクセスレベル）」の考え方
「でもさ、塀を作ったら、正規のパートナー企業や、私たちの自宅からのアクセスも全部遮断されちゃうの？」という疑問が湧きますよね。ご明察です。ガチガチに固めすぎると、今度は仕事ができなくなってしまいます。
そこでVPC Service Controlsには、「アクセスレベル（Access Levels）」という、いわば「VIP用の通用口」を作る機能があります。
例えば、以下のような条件を組み合わせることができます。
- 「会社の特定のIPアドレス（オフィスのグローバルIP）からのアクセスなら通す」
- 「特定の会社支給の端末（エンドポイント）からのアクセスなら通す」
これを設定しておけば、安全なルートからの正当な作業は邪魔せず、悪意ある持ち出しや予期せぬ流出だけをピシャリと防ぐことができます。
—
まとめ：一歩ずつ、セキュアなクラウド環境へ
今回は、GCPのVPC Service Controlsについて、郵便配達の例えを交えながら優しく解説しました。
- 従来の鍵（ファイアウォールやIAM）: 部屋のドアや社員証の管理。API経由のデータ持ち出しまでは防げない。
- VPC Service Controls: プロジェクト全体を囲む「透明な塀」。APIの通信レベルでデータの外向きの流出をガッチリブロックする。
クラウドインフラを扱う上で、セキュリティは決して避けて通れない道ですが、仕組みの本質を一つずつ理解していけば、決して怖いものではありません。
「うちのプロジェクトでも、大切なデータを守るために塀を作ってみようかな」と感じていただけたら嬉しいです。
それでは、次の現場でお会いしましょう！SREチームの筆者でした。
コメント