このドキュメントでは、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 のサブセットを使用して作成されます。基本アクセスレベルに使用されるリクエスト コンテキストに加えて、カスタム アクセスレベルを使用して、サードパーティ サービスからのデータに基づいてリクエストを許可することもできます。詳細については、 カスタム アクセスレベルをご覧ください。
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 アドレスなど、指定された 範囲の 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 ファンクションが VPC Service Controls によって保護されているデータにアクセスできるようにします。
ID のみのアクセスレベルの作成と管理は gcloud コマンドライン ツールで行うことができますが、
コンソールでは行えません。 Google Cloud
基本アクセスレベルの作成を開始するには、 Access Context Manager のアクセスレベルを作成するをご覧ください。
リクエストのコンテキストに基づいてアクセスを許可するアクセスレベルの作成方法については、カスタム アクセスレベルを作成するをご覧ください。条件の組み合わせ
単一のアクセスレベルに複数の条件を含めることが可能です。条件は AND または OR 演算子を使用して評価できます。アクセスレベルを作成または更新するときにモードを指定できます。
AND の場合は、より厳密な（デフォルトの）オプションです。すべての条件が満たされた場合にのみアクセスレベルを付与します。たとえば、企業ネットワーク内と 最新バージョンのオペレーティング システムを実行しているデバイスからのリクエストがあるとします。
OR は制限の厳しくないオプションです。満たす必要があるのは多くの条件のうちの 1 つのみです。これは、ユーザー ID を処理するときに役立つことがあります。たとえば、通常の要件から特定のエンティティ（サービス アカウントなど）を除外する場合などです。
ネスト条件
ある条件が別の条件に依存するように、条件をネストできます。 たとえば、「中」と「高」の信頼性という 2 つのアクセスレベルがある場合、「高」の要件を「中」にその他の条件を追加するように設定できます。
ネスト条件はアクセスレベルの管理をより便利にすることが可能です。たとえば、最も許容度の高いアクセスレベルに最低限のオペレーティング システム バージョンが含まれ、それに応じて制限レベルを設定します。将来、最小バージョンを更新する場合は、ポリシー内のすべてのアクセスレベルではなく、単一の条件を更新する必要があるだけです。