Access Context Manager の概要

このドキュメントでは、Access Context Manager サービスとその機能の概要について説明します。 Google Cloud 組織管理者は、Access Context Manager を使用して、 Google Cloudのプロジェクトとリソースに対してきめ細かい属性ベースのアクセス制御を定義できます。管理者はまずアクセス ポリシーを定義します。これは、アクセスレベルとサービス境界用の組織全体のコンテナです。

アクセスレベルは、リクエストに対応するための要件を示します。以下に例を示します。

  • デバイスの種類とオペレーティング システム
  • IP アドレス
  • ユーザー ID

サービス境界は、境界内のデータを自由に交換できるリソースのサンドボックスを定義しますが、境界外にデータをエクスポートすることは許可されていません。Access Context Manager は、ポリシーの適用を行いません。Access Context Manager は、特定のルールやコンテキストを定義するように設計されています。ポリシーは、VPC Service Controls など、さまざまなポイントにまたがって構成され、適用されます。こうしたサービスの詳細については、それぞれのユーザーガイドをご覧ください。

Access Context Manager ポリシーは、次の Chrome Enterprise Premium ソリューション コンポーネント間で構成して適用できます。

利点

多くの企業は、内部リソースを保護するために、ファイアウォールなどの境界セキュリティ モデルに依存しています。境界セキュリティ モデルは、単一の入り口と出口で厳重に保護されています。壁の外側にあるものはすべて危険と見なされます。中のものはすべて信頼されています。

特定のユーザーとサービスの周囲に正確な境界がある場合は、ファイアウォールと境界セキュリティモデルが適切に機能します。ただし、従業員がモバイルである場合、ユーザーが自分のデバイスを持ち込み（BYOD）、クラウドベースのサービスを利用するので、デバイスの種類が増えます。このシナリオでは、境界モデルで考慮されていない攻撃ベクトルが追加されます。このため、境界線はもはや企業の物理的な場所だけではなくなり、内部にあるものは安全と見なすことはできません。

Access Context Manager を使用すると、特権ネットワークのサイズを縮小し、エンドポイントがネットワークに基づいて周囲の権限を持たないモデルに移行できます。代わりに、必要に応じてリクエストのコンテキスト（デバイスの種類、ユーザー ID など）に基づいてアクセスを許可し、必要に応じて企業ネットワーク アクセスを確認できるようにします。

Access Context Manager は、Google における BeyondCorp の取り組みに不可欠な要素です。詳細については、BeyondCorp をご覧ください。

アクセス ポリシー

アクセス ポリシーは、アクセスレベルやサービス境界など、すべての Access Context Manager リソースのコンテナです。

組織のコンテキストでアクセス ポリシーを作成し、組織レベルのアクセス ポリシーを組織内の任意の場所で使用できます。アクセス ポリシーの管理を委任するには、スコープ アクセス ポリシーを作成し、ポリシーのスコープをフォルダレベルまたはプロジェクト レベルで設定します。スコープ指定されたポリシーが割り当てられている委任管理者は、スコープ アクセス ポリシーのみを管理し、組織レベルのアクセス ポリシーは管理できません。

アクセスポリシーは etag を使用してバージョン管理されます。 etag を使用すると、特定のバージョンのポリシーを対象にして、アクセス ポリシーの変更（アクセスレベルの変更など）ができます。複数のソースがアクセス ポリシーを変更する場合、gcloud コマンドライン ツールと API 呼び出しに etag フィールドを使用すると、意図しない上書きや競合を防ぐことができます。

アクセス ポリシーを作成する方法については、アクセス ポリシーを作成するをご覧ください。

アクセスレベル

アクセスレベルは、リクエストのコンテキスト情報に基づいてリソースへのアクセスを許可するために使用されます。アクセスレベルを使用すると、信頼の階層を整理できます。たとえば、High_Level というアクセスレベルを作成して、高い権限を持つユーザーの少人数のグループからのリクエストを許可できます。リクエストを許可する IP 範囲など、信頼できるより一般的なグループを特定することもできます。その場合、Medium_Level というアクセスレベルを作成して、これらのリクエストを許可します。

アクセスレベルを定義すると、執行サービスはそれらを使用して、リクエストを受け入れるかどうかを決定できます。たとえば、多くのリソースは Medium_Trust で利用可能ですが、より機密性の高い特定のリソースには High_Trust レベルが必要であると指定できます。こうした確認は、標準の IAM ポリシーに加えて適用されます。

アクセスレベルはカスタマイズ可能です。High_Trust と Medium_Trust というアクセスレベルが例としてあげられます。アクセス ポリシーの一部として複数のアクセスレベルを指定できます。

Access Context Manager では、次の 2 つの方法でアクセスレベルを定義できます。

  • ベーシック アクセスレベルは、リクエストのテストに使用される条件のコレクションで構成されます。 条件は、デバイスタイプ、IP アドレス、ユーザー ID など、テストする属性のグループとして定義できます。属性は、条件を判断するために、AND 演算（すべてが true であること）または NOR 演算（true を含めないこと）として組み合わせて、条件が満たされているかどうかを判断できます。

  • カスタム アクセスレベルは、Common Expression Language のサブセットを使用して作成されます。基本アクセスレベルに使用されるリクエスト コンテキストに加えて、カスタム アクセスレベルを使用して、サードパーティ サービスからのデータに基づいてリクエストを許可することもできます。詳細については、カスタム アクセスレベルをご覧ください。

アクセスレベルをネストする場合や、すべてのロジックを組み合わせる場合は、ブール演算子 AND（&&）と OR（||）のオペランドのいずれかが結果を一意に決定する場合、他のオペランドが評価される場合とされない場合があることに注意してください。また、その評価でランタイム エラーが発生した場合は無視されます。たとえば、次の式では、origin.region_code の評価は失敗しますが、levels.ip_check の評価は成功します。チェックの少なくとも 1 つが成功したため、OR で結合された全体的な条件が true になり、アクセスは GRANTED になります。 
!(origin.region_code in ['RU', 'BY', 'UA']) -> FAILED  // levels.regions_check

inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED  // levels.ip_check

!(origin.region_code in ['RU', 'BY', 'UA']) || inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED

levels.regions_check || levels.ip_check -> GRANTED

IP アドレス

元リクエストの IP アドレスに基づいてアクセスレベルを付与できます。許可する IP アドレスの範囲は、クラスレス ドメイン間ルーティング（CIDR）ブロックの形式で指定されます。これにより、許可される IP アドレスをきめ細かく制御できます。

単一のアクセスレベルに複数の IP 範囲を含めることが可能です。

単一の企業ネットワーク内のアドレスなど、指定された範囲の IP アドレスへのアクセスのみを許可するアクセスレベルを作成する方法については、企業ネットワーク アクセス用のアクセスレベルの作成をご覧ください。

Access Context Manager では、次の IP 範囲がプライベート範囲として扱われます。

  • 10.0.0.0/8（RFC 1918）
  • 172.16.0.0/12（RFC 1918）
  • 192.168.0.0/16（RFC 1918）
  • 100.64.0.0/10（RFC 6598 共有アドレス空間）
  • fc00::/7（IPv6 一意のローカル アドレス RFC 4193）

デバイスの種類

Access Context Manager は、エンドポイントの確認を使用して、オペレーティング システム、デバイスタイプ、バージョンなどのユーザー デバイスに関する情報を収集します。このデータに基づいてアクセスレベルを付与できます。たとえば、会社に展開されている最新バージョンのプライマリ オペレーティング システムを実行しているデバイスに、より寛容なアクセスレベルを付与することができます。

このようなデバイス属性に基づいてアクセスレベルを付与する方法については、デバイスタイプによってアクセスを制限するをご覧ください。

ユーザー ID

特定のエンティティにアクセスレベルを付与する場合があります。このようなシナリオでは、呼び出し元の ID によって、条件が満たされているかどうかを判断します。このシナリオは、多くの場合、サービス アカウントと VPC Service Controls と組み合わせて使用されます。

ID のみのアクセスレベルの作成と管理は gcloud コマンドライン ツールで行うことができますが、 Google Cloud コンソールでは行えません。

基本アクセスレベルの作成を開始するには、Access Context Manager のアクセスレベルを作成するをご覧ください。

リクエストのコンテキストに基づいてアクセスを許可するアクセスレベルの作成方法については、カスタム アクセスレベルを作成するをご覧ください。

条件の組み合わせ

単一のアクセスレベルに複数の条件を含めることが可能です。条件は AND または OR 演算子を使用して評価できます。アクセスレベルを作成または更新するときにモードを指定できます。

AND の場合は、より厳密な（デフォルトの）オプションです。このオプションでは、すべての条件が満たされた場合にのみアクセスレベルが付与されます。たとえば、企業ネットワーク内と最新バージョンのオペレーティング システムを実行しているデバイスからのリクエストがあるとします。

OR は制限の厳しくないオプションです。満たす必要があるのは多くの条件のうちの 1 つのみです。これは、ユーザー ID を処理するときに役立つことがあります。たとえば、通常の要件から特定のエンティティ（サービス アカウントなど）を除外する場合などです。

ネスト条件

ある条件が別の条件に依存するように、条件をネストできます。 たとえば、「中」と「高」の信頼性という 2 つのアクセスレベルがある場合、「高」の要件を「中」にその他の条件を追加するように設定できます。

ネスト条件はアクセスレベルの管理をより便利にすることが可能です。たとえば、最も許容度の高いアクセスレベルに最低限のオペレーティング システム バージョンが含まれ、それに応じて制限レベルを設定します。将来、最小バージョンを更新する場合は、ポリシー内のすべてのアクセスレベルではなく、単一の条件を更新するだけで済みます。

詳細