Access Context Manager

解決する課題

ゼロトラストでは「誰か」だけでなく「どこから・どの端末で・どんな状態でアクセスしているか」という文脈で許可を判断したくなります。Access Context Manager は、この文脈条件を アクセスレベル として一元的に定義し、IAP や VPC Service Controls など複数の制御から共通で参照できるようにします。

• 同じ「社内 IP かつ管理対象端末」という条件を、サービスごとに別々に書きたくない → 条件を一度定義して使い回したい
• ID 認証だけでは、フィッシングで奪われた資格情報を防げない → 端末・場所などの文脈を許可の前提に加えたい
• どの境界・どのアプリにどの文脈条件が効いているかを把握したい → 条件をポリシーとして集中管理したい

主要概念と用語

• アクセスポリシー（Access Policy）: 組織に紐づく入れ物。アクセスレベルなどを束ねる最上位のコンテナ。通常は組織ごとに 1 つの組織レベルポリシーを持つ
• アクセスレベル（Access Level）: 許可の前提となる文脈条件の集合。これを満たすリクエストだけを「条件クリア」と判定する。複数のサービスから名前で参照される
• 基本アクセスレベル（Basic）: IP サブネット・地域（リージョンコード）・必須アクセスレベル・プリンシパル（ID）・端末ポリシーなどの条件を AND/OR で組み合わせて記述する形式
• カスタムアクセスレベル（Custom）: CEL（Common Expression Language）式で柔軟に条件を記述する形式。端末属性などを式で評価する
• 端末ポリシー（Device Policy）: 画面ロック・暗号化ストレージ・OS 種別・管理状態（Endpoint Verification や企業管理）などの端末条件
• アクセスバインディング（GCP アクセスバインディング）: Cloud Identity のグループに対し、Google Cloud コンソールや API 利用時のアクセスレベルを要求する結びつけ
• BeyondCorp Enterprise: アクセスレベルを使った文脈アクセス制御（コンテキストアウェアアクセス）を提供する Google のゼロトラスト製品群。Access Context Manager はその基盤コンポーネント

仕様・制限・クォータ

• Access Context Manager 自体は 条件の定義基盤 であり、単独でリソースを保護するものではない。実際の遮断は VPC Service Controls の境界や IAP の認可、アクセスバインディングなど、アクセスレベルを参照する側が行う
• アクセスポリシーは通常 組織に 1 つの組織レベルポリシーを持ち、その配下にアクセスレベルを作成する。スコープ付きポリシーをフォルダ/プロジェクト単位で持てる場合もある
• 端末条件（管理対象端末・OS・暗号化など）を使うには Endpoint Verification や端末情報の収集が前提になる。高度な文脈制御は BeyondCorp Enterprise の機能として提供される範囲がある
• 1 ポリシーあたりのアクセスレベル数や、アクセスレベルあたりの条件数などに上限がある。具体値は変わり得るため公式のクォータを確認する
• 地域条件はリクエスト元の IP から推定されるリージョンコードに基づくため、VPN やプロキシ経由では意図と異なる判定になり得る

内部の仕組み

アクセスレベルは「条件の定義」であり、評価はそれを参照する制御の中で行われます。

1. 管理者がアクセスポリシー配下に アクセスレベル（基本またはカスタム）を作成し、IP・地域・端末・ID などの条件を記述する
2. VPC Service Controls の境界規則、IAP の設定、アクセスバインディングなどが、その アクセスレベルを名前で参照 する
3. リクエストが来ると、参照側がリクエストの文脈（送信元 IP・推定地域・端末属性・プリンシパルなど）を集め、アクセスレベルの条件と突き合わせる
4. 条件を満たせば「許可の前提クリア」となり、参照側の他の判定（IAM など）と合わせて最終的な許可/拒否が決まる

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

• 条件を一元化して再利用: 「社内 IP かつ管理対象端末」のような頻出条件はアクセスレベルとして定義し、IAP・VPC Service Controls・アクセスバインディングから共通参照する
• 多層防御の文脈レイヤとして使う: IAM で「誰が」を決め、アクセスレベルで「どこから・どの端末で」を重ね、フィッシングで奪われた資格情報だけでは入れないようにする
• 段階的に締める: いきなり厳しい端末条件を必須化せず、まず IP/地域から始め、Endpoint Verification の整備に合わせて端末条件を追加する
• 命名規約を整える: 多数のアクセスレベルが乱立しないよう、用途が分かる名前と説明を付け、重複条件を統合する
• 境界とセットで設計: VPC Service Controls の境界に対する例外（イングレス/エグレス規則）と、入口を緩めるアクセスレベルの関係を意図的に設計する

運用・監視

• アクセスレベルの作成・変更は Cloud Audit Logs で監査し、変更は IaC（Terraform など）で管理してレビュー可能にする
• 正規ユーザーが弾かれる場合は、参照側（IAP / VPC Service Controls）のログで、どのアクセスレベル条件を満たせなかったかを切り分ける
• 端末条件を使う場合は Endpoint Verification の導入率や端末情報の鮮度を点検し、未登録端末で正規利用が止まらないようにする
• 地域・IP 条件はリモートワークや出張、VPN 利用で誤判定が起きやすいため、運用しながら閾値や許可レンジを調整する

コスト

Access Context Manager によるアクセスレベルの定義・参照そのものに直接の課金は基本的にありません。一方で、端末条件を伴う高度な文脈アクセス制御は BeyondCorp Enterprise の機能として提供される範囲があり、上位エディションやサブスクリプションが必要になる場合があります。料金区分は変わり得るため、正確な条件は公式の料金ページで確認してください。

セキュリティ

• 最小到達範囲: ID 認証に加え、IP・地域・端末状態の条件を重ねて到達範囲を絞り、資格情報の単独漏洩に強くする
• 管理対象端末を必須化: 機微なリソースは画面ロック・暗号化・企業管理などの端末ポリシーを満たす端末からのみ許可する
• 境界制御と併用: VPC Service Controls の境界でデータ持ち出しを防ぎつつ、アクセスレベルで信頼できる経路だけを通す
• 変更の監査: アクセスレベルやポリシーの変更は Audit Logs で継続的に確認し、過度に緩い条件が入り込まないよう点検する

関連サービス・比較

Access Context Manager は、文脈条件（アクセスレベル）を供給する基盤であり、それを実際に適用する VPC Service Controls や IAP と役割が分かれます。VPC Service Controls はリソースの周囲にサービス境界を作ってデータ持ち出しを防ぐ制御で、その例外条件としてアクセスレベルを参照します。

ハンズオン / CLI例

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

# 2) 基本アクセスレベルを作成する（社内 IP からのアクセスのみ許可する例）
#    条件は YAML で記述してから --basic-level-spec で読み込む
cat > corp-ip-level.yaml <<'YAML'
- ipSubnetworks:
  - 203.0.113.0/24
  - 198.51.100.0/24
YAML

gcloud access-context-manager levels create corp_ip_only \
  --policy=POLICY_ID \
  --title="Corp IP only" \
  --basic-level-spec=corp-ip-level.yaml

# 3) 作成したアクセスレベルを一覧で確認する
gcloud access-context-manager levels list \
  --policy=POLICY_ID

# 4) このアクセスレベルは VPC Service Controls の境界や IAP から参照して適用する
#    （例: 境界のイングレス/エグレス規則やアクセスバインディングで名前指定する）