概要

Access Context Manager を使用すると、Google Cloud 組織管理者は、Google Cloud のプロジェクトとリソースに対するきめ細かい属性ベースのアクセス制御を定義できます。

管理者はまずアクセス ポリシーを定義します。これは、アクセスレベルとサービス境界用の組織全体のコンテナです。

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

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

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

Access Context Manager を使用する理由

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

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

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

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

アクセス ポリシー

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

Access Context Manager は組織全体の機能です。割り当てを目的としてプロジェクトのコンテキストでアクセス ポリシーを作成しますが、そのプロジェクトだけでなく組織内の任意の場所でポリシーを使用できます。

アクセスポリシーは etag を使用してバージョン管理されます。これにより、アクセスレベルの変更などのアクセス ポリシーへの変更を、特定のバージョンのポリシーの対象にできます。アクセス ポリシーが複数のソースによって変更されている場合、Access Context Manager gcloud コマンドと API 呼び出し用の etag フィールドを使用すると、変更が予期せず上書きされたり、意図しない競合が発生したりすることがなくなります。

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

アクセスレベル

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

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

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

Access Context Manager では、ベーシックとカスタムの 2 種類のアクセスレベルを定義できます。

基本アクセスレベルは、リクエストのテストに使用される条件のコレクションです。条件は、デバイスタイプ、IP アドレス、ユーザー ID など、テストする属性のグループです。アクセスレベル属性は、リクエストに関するコンテキスト情報を表します。

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

IP アドレス

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

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

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

デバイスの種類

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

特定のデバイスにアクセスレベルを付与する方法の詳細については、ユーザー デバイス用のアクセスレベルの作成をご覧ください。

ユーザー ID

特定のエンティティにアクセスレベルを付与する場合があります。 この場合、発信者の ID によって、条件が満たされているかどうかを判断します。

このシナリオは、多くの場合、サービス アカウントおよびVPC Service Controlsと組み合わせて使用されます。たとえば、Cloud Function が VPC Service Controls で保護されたデータにアクセスできるようにします。

ID のみのアクセスレベルは、gcloud コマンドライン ツールでのみ作成して管理できます。Google Cloud Console は使用できません。

ネットワークのアクセスレベルに ID を含めるには、ID とアクセスレベルを使用する方法が記載されています。

条件の組み合わせ

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

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

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

ネスト条件

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

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

詳細