このドキュメントでは、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 というアクセスレベルが例としてあげられます。アクセス ポリシーの一部として複数のアクセスレベルを指定できます。
ベーシック アクセスレベルは、リクエストのテストに使用される条件のコレクションで構成されます。 条件は、デバイスタイプ、IP アドレス、ユーザー ID など、テストする属性のグループとして定義できます。属性は、条件を判断するために、AND 演算（すべてが true であること）または NOR 演算（true を含めないこと）として組み合わせて、条件が満たされているかどうかを判断できます。
カスタム アクセスレベルは、Common Expression Language のサブセットを使用して作成されます。基本アクセスレベルに使用されるリクエスト コンテキストに加えて、カスタム アクセスレベルを使用して、サードパーティ サービスからのデータに基づいてリクエストを許可することもできます。詳細については、カスタム アクセスレベルをご覧ください。
!(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 アドレスなど、指定された範囲の IP アドレスへのアクセスのみを許可するアクセスレベルを作成する方法については、企業ネットワーク アクセスのアクセスレベルの作成をご覧ください。
次の IP 範囲は、Access Context Manager によってプライベート範囲として扱われます。
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 と組み合わせて使用されます。 たとえば、このシナリオを使用して、Cloud Functions の関数が VPC Service Controls で保護されたデータにアクセスできるようにします。
ID のみのアクセスレベルの作成と管理は gcloud コマンドライン ツールで行うことができますが、 Google Cloud コンソールでは行えません。
基本アクセスレベルの作成を開始するには、Access Context Manager のアクセスレベルを作成するをご覧ください。
リクエストのコンテキストに基づいてアクセスを許可するアクセスレベルの作成方法については、カスタム アクセスレベルを作成するをご覧ください。条件の組み合わせ
単一のアクセスレベルに複数の条件を含めることが可能です。条件は AND または OR 演算子を使用して評価できます。アクセスレベルを作成または更新するときにモードを指定できます。
AND のケースは、より厳格なデフォルトのオプションです。このオプションでは、すべての条件が満たされた場合にのみアクセスレベルが付与されます。たとえば、企業ネットワーク内と最新バージョンのオペレーティング システムを実行しているデバイスからのリクエストがあるとします。
OR は制限の厳しくないオプションです。このオプションでは、多くの条件のうち 1 つだけが true である必要があります。これは、ユーザー ID を処理する場合に役立つことがあります。たとえば、特定のエンティティ（サービス アカウントなど）を通常の要件から除外する場合です。
ネスト条件
ある条件が別の条件に依存するように、条件をネストできます。 たとえば、「Medium」と「High」の 2 つのアクセスレベルがある場合、「High」の要件を「Medium」に設定し、他の条件を追加できます。
ネスト条件はアクセスレベルの管理をより便利にすることが可能です。たとえば、最も許容度の高いアクセスレベルに最低限のオペレーティング システム バージョンが含まれ、それに応じて制限レベルを設定します。将来、最小バージョンを更新する場合は、ポリシー内のすべてのアクセスレベルではなく、1 つの条件のみを更新する必要があります。
アクセスレベルをネストする場合は、次の制限事項に注意してください。
循環依存関係がない: 循環依存関係は許可されません。アクセスレベルは、直接（たとえば、
Level_AにLevel_Bが必要で、Level_BにLevel_Aが必要、またはアクセスレベルがそれ自体を参照する）または推移的（たとえば、Level_AにLevel_Bが必要で、Level_BにLevel_Cが必要、Level_CにLevel_Aが必要）にループ内で相互に参照することはできません。循環依存関係を導入するアクセスレベルを作成または更新しようとすると、呼び出しは失敗し、INVALID_ARGUMENTエラーが発生します。条件あたりの最大依存関係数: ベーシック アクセスレベルでは、1 つの条件の
requiredAccessLevelsリストで最大 15 個の他のアクセスレベルを参照できます。ネストの深さ: Access Context Manager は、ネストされたアクセスレベルを再帰的に展開するのではなく、依存関係の順序で評価するため、ネストされたアクセスレベルのチェーンには、アクセス ポリシーあたりのアクセスレベルの上限を超える個別の最大深度の上限はありません。参照されるすべてのアクセスレベルは、同じアクセス ポリシーに属している必要があります。