こんにちは！クラウドインフラの世界へようこそ。SREとして日々さまざまなシステムの裏側を支えていると、「セキュリティをガチガチに固めたいけれど、便利なクラウドサービスもスムーズに使いたい！」という現場の熱い要望にたくさん出会います。
Google Cloud（GCP）の世界には、社外や外部のネットワークからの不正アクセスを防ぎつつ、安全な通信だけを通してくれる「VPC Service Controls（以下、VPC-SC）」という強力なセキュリティの城壁があります。
今回は、このVPC-SCの城壁に備え付けられた「門（アクセスレベル）」と「特別な通路（イングレス・エグレスルール）」について、難しい専門用語の裏側にある「現実世界の仕組み」に例えながら、一歩ずつ優しく紐解いていきましょう！
—
1. VPC-SCの城壁と「アクセスレベル」ってなに？
まずは、VPC-SCがどんなものかイメージしてみましょう。
GCPのプロジェクトを「大切な宝物が眠るお城」だと想像してください。Cloud StorageやBigQueryといった便利なサービスは、お城の中にある宝物庫のようなものです。
通常、インターネットという広大な世界から、この宝物庫へは鍵（API）さえあればアクセスできてしまいます。「社外のカフェからうっかり会社のデータを覗かれてしまった……」なんてことが起きないようにするため、お城の周りに高い城壁を築き、外部からの侵入をガッツリ遮断するのがVPC-SCの役割です。
でも、これではお城の中で働く正社員（社内システムや特定の開発者）まで宝物庫に入れなくなってしまいますよね。そこで必要になるのが、「アクセスレベル（Access Levels）」という名の「身分証チェックゲート」です。
郵便配達や宅配便に例えてみよう
アクセスレベルの仕組みは、高セキュリティなオフィスビルやマンションの受付に似ています。
ビルに入る際、受付の人がこうチェックしますよね。
- 「あなたは許可された会社の社員証（特定のIPアドレス）を持っていますか？」
- 「会社が貸し出した安全な管理端末（デバイスポリシー）を使っていますか？」
これと同じことを、GCPのAPIリクエストが飛んできた瞬間に判定するのがアクセスレベルの仕事なんです。
—
2. アクセスレベルの評価条件を覗いてみよう
アクセスレベルで設定できる主な条件には、大きく分けて「IPサブネットベース」と「デバイスポリシーベース」の2つがあります。
① IPサブネットによる判定
「この会社から、あるいはこのオフィスの固定IPからアクセスしてきた通信だけを許可する」という、一番古典的かつ確実な方法です。
② デバイスポリシーによる判定
「IPアドレスだけだと、社内の誰かのPCがウイルスに感染しているかもしれない……」そんな不安を解消するのがデバイスポリシーです。
「OSの画面ロックが有効になっているか」「社用管理端末としてMDM（モバイルデバイス管理）に登録されている暗号化されたPCか」といった端末の健康状態までチェックして門をくぐらせます。
実際にこれらを定義するYAML設定ファイルのサンプルを見てみましょう！
# 許可されたIPアドレスとデバイスの条件を定義するアクセスレベルの設定例
title: "accessLevels/office_and_secure_device_policy"
basic:
conditions:
- ipSubnetworks:
- "203.0.113.0/24" # 本社の安全なグローバルIPレンジからのアクセスを許可
devicePolicy:
requireScreenLock: true # 画面ロックの設定が必須
osConstraints:
- osType: DESKTOP_CHROME_OS # 指定されたOSのみ許可
minimumVersion: "110.0.0.0"このように、「どこから（IP）」そして「どんな状態の端末で（デバイス）」という2つの関門をクリアして初めて、お城のなかの宝物庫への扉が開く仕組みになっています。
—
3. 城壁の穴埋め？「イングレス・エグレスルール」の正体
さて、城壁（VPC-SC）を築いて安全第一にすると、今度は新しい悩みが出てきます。
「外にある別の信頼できるシステムから、どうしてもこのお城の中のBigQueryにデータを送りたい！」
「逆に、お城の中から外の外部APIサーバーにどうしても通信しにいきたい！」
要するに、「城壁の外と中を行き来したい時」ですね。
完全にシャットアウトしてしまうとシステムが動かなくなってしまうので、ここに「例外的に通してよい専用のトンネル」を作る必要があります。それが、イングレス（Ingress）ルールとエグレス（Egress）ルールです。
これも身近な例で考えてみましょう。
- イングレス（Ingress）ルール ＝ 「外から中への搬入通路」
- 例：外部の運送業者が、事前に届け出た荷物（特定のAPIリクエスト）だけを、お城の中の指定された倉庫に運び込むための通用口です。
- エグレス（Egress）ルール ＝ 「中から外への搬出通路」
- 例：お城の中で集計したデータを、外にある外部パートナーのサーバーへ安全に送り出すための専用道路です。
イングレスルールの設定例をみてみよう
それでは、実務でよく使うイングレスルールの定義を覗いてみましょう。
「外の特定のプロジェクト（例えば、データ分析用の別プロジェクト）から、我が家のCloud Storageへのアクセスを特別に許可する」という設定です。
# イングレスルールの設定例（外から中への通信を許可）
ingressFrom:
sources:
- resource: "projects/123456789012" # 信頼する外部のGoogle Cloudプロジェクトを指定
identityType: ANY_IDENTITY # すべてのユーザーまたは特定のサービスアカウント
ingressTo:
operations:
- serviceName: "storage.googleapis.com" # 許可するGCPサービス（ここではCloud Storage）
methodSelectors:
- method: "google.storage.v1.Storage.GetObject" # ファイルのダウンロード操作だけを許可
resources:
- "projects/987654321098" # 守られているターゲットのプロジェクトこの設定では、外のプロジェクト（123456789012）からの通信であっても、Cloud Storageの「ファイルの読み込み（GetObject）」という操作だけに絞って、門をくぐらせることを許可しています。「入れるけれど、できることはこれだけですよ」という、非常に細かい制御ができるのがポイントです。
—
4. 現場でありがちな落とし穴とSREの知見
ここまで読んで、「なんだ、ルールをガチガチに書けばバッチリだな！」と思われたかもしれません。しかし、現場のSREからお伝えしたいリアルな注意点がいくつかあります。
1. 「全部許可（*）」のワナに気をつける
設定を急ぐあまり、methodSelectors や ipSubnetworks に *（すべて許可）を指定したくなる衝動に駆られますが、これはセキュリティの穴を自ら開けるようなものです。必要最小限の権限（最小権限の原則）を意識し、特定のメソッドや特定のIPレンジだけを記述するようにしましょう。
2. 監査ログ（Cloud Logging）を友達にする
VPC-SCでブロックされた通信は、Google Cloudの監査ログにバッチリ記録されます。「あれ？急にシステムが動かなくなったぞ？」という時は、慌てずにログを確認し、どのアクセスレベルやルールに弾かれたのかを突き止めるのがトラブルシューティングの第一歩です。
—
まとめ
今回は、GCP VPC Service Controlsの「アクセスレベル」と「イングレス/エグレスルール」について、現実世界のセキュリティゲートや宅配便に例えながら解説しました。
- アクセスレベルは、通信の「場所（IP）」や「端末の状態（デバイスポリシー）」をチェックする身分証ゲート。
- イングレス/エグレスルールは、城壁の外と中を安全に行き来させるための「特別な搬入・搬出ルート」。
難しそうに見えるクラウドのネットワークセキュリティも、私たちが普段暮らしている現実世界の仕組みと照らし合わせてみると、すんなり頭に入ってきますよね。
インフラやネットワークの基礎を固めることは、安定してビクともしない堅牢なシステムを作るための大きな第一歩です。この記事が、あなたのクラウドライフをより楽しく、安心なものにする手助けになれば嬉しいです。
それでは、また次の技術でお会いしましょう！SREチームでした！
コメント