VPC Service Controls

解決する課題

IAM だけでは、正しい認証情報さえあれば「どこからでも」データへアクセスできてしまいます。VPC Service Controls は、BigQuery や Cloud Storage などのマネージドサービスの周囲に仮想の境界を引き、境界の外からの API アクセスそのものを遮断することで、認証情報の漏えいや内部不正によるデータの持ち出しを防ぎます。

• IAM 権限を持つ認証情報が盗まれた場合でも、境界外から保護データを引き出されたくない
• 悪意ある内部者が、業務データを個人プロジェクトや外部の宛先にコピーするのを止めたい
• 認可されたネットワークや端末からのみ、BigQuery や Cloud Storage にアクセスさせたい
• VPC 内のリソースだけでなく、マネージドサービスの API レベルでデータの境界を引きたい

主要概念と用語

• サービス境界（Service Perimeter）: 保護対象のプロジェクトと Google マネージドサービスを囲う仮想の境界。境界の中と外の通信を制御する基本単位
• 保護対象サービス（Restricted Services）: 境界で守る対象に指定した Google API（例: BigQuery、Cloud Storage、Cloud KMS など）。指定したサービスへの境界外からの呼び出しが拒否される
• イングレス／エグレスルール: 境界をまたぐアクセスを例外的に許可する規則。境界外から中へ入る通信がイングレス、中から外へ出る通信がエグレス
• アクセスレベル（Access Level）: Access Context Manager が提供する、IP 範囲・地域・端末状態などの条件。境界外からのアクセスを条件付きで許可する際に用いる
• 境界ブリッジ（Perimeter Bridge）: 別々の境界に属するプロジェクト同士が、双方向に通信できるようにつなぐ仕組み
• ドライランモード（Dry Run）: 実際には拒否せず、拒否されるはずだったアクセスをログにだけ記録する検証用モード
• VPC アクセス可能サービス（VPC Accessible Services）: 境界内の VPC から到達してよい API を絞り込む設定

仕様・制限・クォータ

• VPC Service Controls は Access Context Manager を基盤とし、組織レベルのアクセスポリシー上にサービス境界を定義する。組織（Organization）リソースが前提となる
• 守れるのは Google マネージドサービスの API であり、対応サービスは順次拡張されている。利用前に対象サービスが保護対象に含まれるかを確認する
• 境界は IAM の置き換えではない。IAM が「誰に権限があるか」を決め、VPC Service Controls は「どこから触れるか」を制御する。両者は併用して多層で守る
• オンプレミスや別 VPC からマネージドサービスへ到達させるには、**Private Google Access（制限付き仮想 IP / restricted.googleapis.com）**と DNS 設定を組み合わせるのが一般的
• 境界数やルール数などにはクォータの上限があるため、境界を細かく分割しすぎる設計には注意する

内部の仕組み

境界は、対象サービスへの API リクエストが境界の内側から来たのか外側から来たのかを評価して許可・拒否を決めます。

1. 保護対象サービス宛ての API 呼び出しに対し、呼び出し元が境界の内側か外側かを判定する
2. 境界外からの呼び出しは原則として拒否される。これにより認証情報が漏れても境界外からは利用できない
3. アクセスレベル（許可 IP・地域・端末状態など）を満たす境界外アクセスは、イングレスルールで例外的に通せる
4. 境界内から境界外の宛先へデータを書き出す通信は、エグレスルールで許可した範囲だけに限定される

設計パターン / ベストプラクティス

• 段階導入: 新規境界は必ずドライランから開始し、拒否ログを精査して例外ルールを整備してから強制適用する
• 境界は粗めに: プロジェクトごとに細分化するより、信頼境界が同じプロジェクト群をまとめて 1 つの境界にし、必要な連携だけ境界ブリッジでつなぐ
• アクセスレベルで入口を限定: 社内 IP・管理対象端末・特定地域などのアクセスレベルを定義し、境界外からの正規アクセスはこれを満たす場合のみ許可する
• エグレスを明示: 境界内から外部プロジェクトやサービスへデータを出す経路は、エグレスルールで宛先を限定して持ち出し面を絞る
• オンプレ連携は制限付き VIP: ハイブリッド構成では Private Google Access の制限付き仮想 IP と DNS を整え、境界対象 API のみへ到達させる

運用・監視

• ドライランの違反ログを定期的に確認し、想定外に拒否されている正規アクセスや、逆に通っている不審なアクセスを把握する
• Cloud Audit Logs で境界による拒否イベントを監査し、誰がどのサービスへ境界外からアクセスを試みたかを追跡する
• アクセス不可の切り分けは、**IAM 権限 → サービス境界（イングレス／エグレス）→ アクセスレベル → ネットワーク経路（Private Google Access・DNS）**の順で確認すると整理しやすい
• 新しいサービスを使い始めるときは、それが境界の保護対象に追加されているか、追加が必要かを点検する

コスト

VPC Service Controls および Access Context Manager の機能自体には、原則として追加の利用料金はかかりません。コストの中心は、境界を引いた先で利用する BigQuery・Cloud Storage・ネットワークなどの通常料金です。

セキュリティ

• 多層防御: IAM で最小権限を付け、その上に境界を重ねて「権限があっても境界外なら拒否」を実現する
• 認証情報漏えい対策: 鍵やトークンが流出しても、境界外からは保護対象データへ到達できないため、被害を封じ込めやすい
• 持ち出し制御: エグレスルールで境界外への書き出し先を限定し、内部不正によるデータ持ち出しの経路を狭める
• 入口の条件化: アクセスレベルで IP・地域・端末状態を条件にし、認可された環境からのみ境界へ入れるようにする
• 継続監査: ドライランログと Audit Logs で、許可・拒否を継続的に観測する

関連サービス・比較

VPC Service Controls はしばしば IAM と対比されます。IAM が「誰にどの操作を許すか」という認可を担うのに対し、VPC Service Controls は「どこからアクセスできるか」という境界を担い、両者を重ねて多層で守ります。

ハンズオン / CLI例

# 1) アクセスポリシー（組織レベル）の ID を確認する
gcloud access-context-manager policies list \
  --organization=123456789012

# 2) BigQuery と Cloud Storage を保護対象にしたサービス境界を作成する
#    まずはドライランで影響を確認するのが安全
gcloud access-context-manager perimeters dry-run create my-perimeter \
  --policy=POLICY_ID \
  --title="my-perimeter" \
  --resources=projects/PROJECT_NUMBER \
  --restricted-services=bigquery.googleapis.com,storage.googleapis.com

# 3) ドライランの違反ログを精査し問題なければ強制適用へ昇格する
gcloud access-context-manager perimeters dry-run enforce my-perimeter \
  --policy=POLICY_ID