このドキュメントでは、コンテキストアウェア アクセスを使用して Google Cloud リソースを効果的に保護するための推奨されるベスト プラクティスについて説明します。コンテキストアウェア アクセスは、認証の強度、デバイスのポスチャー、ネットワーク ロケーション、地理的位置などの属性に基づいてユーザーのアクセスを制御するセキュリティ アプローチです。このアプローチは、セキュリティ アクセスに基本的なユーザー ID を使用するだけではなく、ゼロトラスト セキュリティ モデルを実装して、全体的なセキュリティ体制を強化するのに役立ちます。さまざまなタイプのアプリとリソースにコンテキストアウェア アクセスを実装する方法については、コンテキストアウェア アクセスを使用してアプリとリソースを保護するをご覧ください。
アプリと Google Cloud リソースを保護するために、さまざまなコンテキスト要因の組み合わせに基づいて、きめ細かいアクセス制御を定義できます。Access Context Manager を使用すると、アクセスレベルとサービス パラメータを含むアクセス ポリシーを定義できます。
このドキュメントは、Identity and Access Management（IAM）と Google Cloud リソースおよびアプリのセキュリティを担当するセキュリティ プロフェッショナルを対象としています。このドキュメントは、Access Context Manager、Google Cloud、IAM 管理について理解していることを前提としています。
コンテキストアウェア アクセスのアプローチ
組織でコンテキストアウェア アクセスを設定する際は、コンテキストアウェア アクセス制御をアプリ、リソース、またはその両方に適用するかどうかを決定する必要があります。この判断を行うには、次のさまざまなタイプのアプリとサービスを区別することが役立ちます。
- 管理アプリ: これらのアプリを使用すると、ユーザーは VM インスタンス、BigQuery データセット、Cloud Storage バケットなどのGoogle Cloud リソースを管理または操作できます。管理アプリの例としては、 Google Cloud コンソール、Google Cloud CLI、Terraform、IAP Desktop などがあります。
- 基幹業務アプリ: これらのアプリには、Google Cloud で実行され、認証と認可に SAML または Identity-Aware Proxy（IAP）を使用するウェブアプリが含まれます。このようなアプリは、内部アプリと呼ばれることもあります。基幹業務アプリの例としては、CRM システム、ダッシュボード、その他のカスタムアプリなどがあります。
- Google Workspace およびその他の Google サービス: これらのサービスは Google が提供していますが、 Google Cloudとは関連していません。
認証と認可の処理方法に基づいて、基幹業務アプリをさらに区別できます。
- SAML: 認証に Google Workspace SAML を使用するアプリ。SaaS アプリは、多くの場合このカテゴリに分類されます。
- IAP: IAP の背後にデプロイしたカスタム ウェブアプリ。
- OAuth: OAuth 2.0 を使用し、1 つ以上の Google Cloud OAuth スコープを使用するカスタム ウェブアプリまたはデスクトップ アプリ。
次のフロー図は、アプリのタイプごとに最適なコンテキストアウェア アクセス アプローチを示しています。
この図は、次のタイプのアプリを示しています。
管理アプリ: 一般的に、管理アプリ自体よりも、管理アプリがアクセスを容易にするGoogle Cloud リソースを保護することの方が重要です。次のようなシナリオを考えます。
- ユーザーがリソースにアクセスできない。このシナリオでは、管理アプリへのアクセス権を持つことはユーザーにとってそれほど価値がない可能性があります。
- ユーザーがリソースにアクセスできるが、管理アプリにアクセスできない。このシナリオでは、ブロックされていない別の管理アプリを見つけて、リソースにアクセスできる可能性があります。
したがって、管理アプリではリソース中心のアプローチを採用します。リソースに適切なコンテキストアウェア アクセス制御を適用する最も効果的な方法は、適切な上り（内向き）ルールを使用して Virtual Private Cloud（VPC）サービス境界を使用することです。アクセス バインディングを使用して VPC サービス境界を補完できます。
OAuth を使用する基幹業務アプリ: これらのアプリでは、アプリ自体へのアクセスと、アプリが使用する可能性のあるリソースを保護することが重要です。コンテキストアウェア アクセスを使用してアプリを保護するには、アクセス バインディングを使用します。
IAP を使用する基幹業務アプリ: IAP は OAuth を使用しますが、アクセス バインディングを使用して、IAP を使用してユーザーを認証するアプリを保護することはできません。代わりに、IAM 条件を使用してこれらのアプリを保護します。
SAML を使用する基幹業務アプリ: OAuth を使用する基幹業務アプリと同様に、アプリ自体へのアクセスと、アプリが使用する可能性のあるリソースへのアクセスを保護することが重要です。これらのアプリを保護するには、Google Workspace コンテキストアウェア アクセスを使用します。
Google Workspace とその他の Google サービス: これらのアプリでは、アプリ自体へのアクセスと、アプリが使用する可能性のあるリソースを保護することが重要です。これらのアプリを保護するには、Google Workspace コンテキストアウェア アクセスを使用します。
アクセスレベルの管理
以降のセクションでは、アクセスレベルを管理する際に推奨される方法について説明します。
再利用可能なアクセスレベルを作成する
アクセスレベルはグローバル リソースであり、 Google Cloud 組織内のリソース全体で使用することを目的としています。したがって、アクセスレベルの総数を制限し、複数のリソースに適用可能な意味のあるアクセスレベルにすることが最善です。次の点を考慮してください。
- 特定のユーザーまたはアプリの名前をアクセスレベルの名前に埋め込まないでください。
- アクセスレベルにリソース固有またはアプリ固有の要件をエンコードしないでください。
Fully Trusted Deviceなど、特定のユーザーまたはデバイスのポスチャーを表明する名前を使用します。
複合アクセスレベルを使用する
メンテナンスのオーバーヘッドを削減し、サブネットワークまたはリージョンが変更されたときに一貫性を確保するには、複数のアクセスレベルで同じ要件を繰り返さないでください。代わりに、アクセスレベルを相互に依存させます。
たとえば、同じ信頼できるリージョンまたは IP サブネットワークを複数のアクセスレベルにリストするのではなく、Trusted location という追加のアクセスレベルを作成します。この Trusted location レベルは、他のアクセスレベルの依存関係として機能します。
アクセスレベルで緊急アクセス ユーザーを除外する
誤ってロックアウトされるのを防ぐため、少なくとも 1 人の緊急アクセス ユーザーをすべてのアクセスレベルから除外することをおすすめします。アクセスレベルを適用するすべてのアプリとリソースに除外が適用されるようにするには、アクセスレベル自体で除外を構成します。
- 通常の要件を定義する条件を 1 つ追加します。
- 緊急アクセス ユーザーを 1 人以上リストする
members要件を含む別の条件を追加します。 - 結合関数を
OR条件に設定して、ユーザーが 2 つの条件のうち 1 つを満たせばよいようにします。
たとえば、次のアクセスレベルでは、3 つのリージョンへのアクセスを制限しますが、ユーザー [email protected] はこの要件から除外されます。
{ "name": "accessPolicies/…", "title": "Example access level", "basic": { "conditions": [ { "members": [ "user:[email protected]" ] }, { "regions": [ "DE", "AU", "SG" ] } ], "combiningFunction": "OR" } } 修正メッセージを設定する
組織内のユーザーは、特定のアプリへのアクセスが許可されるかどうかは、ユーザーの所在地やデバイスなどの要因によって決まることを認識していない可能性があります。ユーザーに情報を伝え、サポート リクエストを減らすために、アクセスを回復するための手順をユーザーに伝えるカスタムの修正メッセージを構成します。
アクセス バインディングの管理
アクセス バインディングを使用すると、1 つ以上の Google Cloud スコープを使用する OAuth アプリのコンテキストアウェア アクセスを構成できます。アクセス バインディングは、基幹業務アプリにコンテキストアウェア アクセスを適用するうえでも効果的な方法です。
以降のセクションでは、アクセス バインディングを使用する際に推奨される方法について説明します。
スコープ設定で単一のアクセス バインディングを使用する
アクセス バインディングを使用する場合は、次の制約事項を考慮する必要があります。
- 各 Cloud Identity グループに設定できるアクセス バインディングは 1 つまでです。
- 複数のアクセス バインディングがユーザーに適用される場合、制限の緩いアクセス バインディングが優先されます。
この 2 つの制約に対応するには、すべてのユーザーに適用される単一のアクセス バインディングを使用します。
- Cloud Identity アカウントまたは Google Workspace アカウントのすべてのユーザーが自動的に含まれるグループを作成します。
- デフォルトのアクセスレベルをグループに関連付けるアクセス バインディングを作成するか、使用します。デフォルトのアクセスレベルは、ほとんどのユーザー、デバイス、アプリに適しているはずです。
- 必要に応じて、スコープ設定（
scopedAccessSettings）を使用して、選択したアプリに弱いアクセスレベルを割り当てます。
厳格なデフォルトのアクセスレベルを使用する
アクセス バインディングでスコープ設定されたアクセス設定とデフォルトのアクセスレベルの両方が指定されている場合、2 つのアクセスレベルは OR セマンティクスを使用して結合されます。この動作には次の影響があります。
- ユーザーは、OAuth アプリにアクセスするために、アクセスレベルのいずれか 1 つを満たせばよい。
- OAuth アプリのスコープ付きアクセス設定を追加すると、有効なアクセス要件を引き下げることができます。
- アクセス バインディングのデフォルトのアクセスレベルよりも厳しいアクセスレベルを使用している場合、スコープ設定は無効になります。
アクセス バインディングのデフォルトのアクセスレベルを選択する場合は、次のことをおすすめします。
- 厳格なアクセスレベルをデフォルトのアクセスレベルとして使用します。
- スコープ設定を使用して、個々の OAuth アプリに低いアクセスレベルを適用します。
デフォルトのアクセスレベルに次の制限の一部またはすべてを追加することを検討してください。
- ブラウザとデバイスの制限: 管理対象の Chrome ブラウザと管理者が承認したデバイスを使用してアプリにアクセスすることをユーザーに要求します。
- 地理的制限: 組織が特定の地域でのみ事業を行っている場合は、地域制限を使用して、それらの地域のみを許可リストに含めます。それ以外の場合は、地域制限を使用して、制裁措置が課せられている地域や、その他の理由で関連性のない地域へのアクセスを制限できます。
- IP ネットワーク制限: 組織内のユーザーが特定のネットワークからのみGoogle Cloud にアクセスする場合や、組織で共通の下り（外向き）プロキシを使用している場合は、IP ネットワーク制限を含めることができます。
証明書ベースの認証を必要とするアクセスレベルをデフォルトのアクセスレベルとして使用しないでください。証明書ベースの認証は、VPC サービス境界の上り（内向き）ルールに最適です。
アプリごとに例外を管理する
デフォルトのアクセスレベルの例外を管理するには、ユーザーまたはグループの例外ではなく、個々のアプリの例外を追加します。
厳格なデフォルトのアクセスレベルは、ほとんどのアプリに適していますが、すべてのアプリに適しているとは限りません。
- 一部のアプリは機密性が低く、デフォルトのアクセスレベルを満たしていないユーザーにもアクセスできるようにする必要があります。たとえば、パートナー、ゲスト、卒業生がアクセスできる必要があるアプリなどです。
- 一部のアプリは、デフォルトのアクセスレベルで適用される制限のいずれかと技術的に互換性がない可能性があります。
個々のアプリをデフォルトのアクセスレベルから除外するには、スコープ設定を使用します。影響を受けるアプリごとに、スコープ設定を追加し、個々のアプリに適したアクセスレベルを割り当てます。
ユーザーまたはグループごとに例外を管理するために、追加のアクセス バインディングを作成しないでください。追加のアクセス バインディングは、次の問題を引き起こす可能性があります。
- 重複するアクセス バインディングが誤って作成される可能性があります。
- 個々のアプリに対してどのコンテキストアウェア アクセスの要件が効果的に適用されているかを判断することが難しくなる可能性があります。
アクセス バインディングの重複を避ける
アクセス バインディングはグループに関連付けられています。ユーザーが複数のグループのメンバーである場合、複数のアクセス バインディングが適用される可能性があります。この場合、これらのアクセス バインディングのコンテキストアウェア アクセス要件は、OR セマンティクスを使用して結合されます。
この動作により、意図しない影響が生じる可能性があります。たとえば、ユーザーが他のグループに参加できる場合、特定のアプリの保護が損なわれる可能性があります。
このような状況を防ぐため、アクセス バインディングが重複しないようにすることをおすすめします。
- アクセス バインディングの数を最小限に抑えます（理想的には 1 つ）。
- 複数のアクセス バインディングが必要な場合は、相互に排他的なグループに割り当てます。
グループを不正な変更から保護する
デフォルトでは、Cloud Identity ではグループ メンバーがグループを脱退できます。この動作はアクセス グループには適切ですが、関連付けられたアクセス バインディングを持つグループでは問題が発生します。ユーザーがアクセス バインディングに関連付けられているグループから離脱すると、アクセス バインディングによって課せられたコンテキストアウェア アクセスの要件の対象外になります。そのため、ユーザーはグループを脱退することで、コンテキストアウェア アクセスの要件を回避できます。
アクセス バインディングを構成するときは、常に適用グループを使用し、ユーザーが適用グループを離脱することを許可しないでください。または、Cloud Identity アカウントまたは Google Workspace アカウントのすべてのユーザーを自動的に含むグループを作成します。
アクセス バインディングを使用している場合に外部ユーザーのアクセスを許可しない
アクセス バインディングは、 Google Cloud 組織が属する Cloud Identity アカウントまたは Google Workspace アカウントのユーザーにのみ影響します。これらのユーザーは、他の Google Cloud 組織のリソースにアクセスしようとすると、自分の Google Cloud 組織のアクセス バインディングの対象になります。ユーザーに対するアクセス バインディングのこの適用は、Cloud Identity の他のコンテキストでの動作とは異なります。
外部の Cloud Identity アカウントまたは Google Workspace アカウントのユーザーが Google Cloud組織のリソースにアクセスできるようにする場合、アクセス バインディングはこれらのユーザーに影響しません。
アクセス バインディングを有効にするには、 Google Cloud 組織内のアプリやリソースへのアクセス権を外部ユーザーに付与しないでください。また、Cloud Identity アカウントまたは Google Workspace アカウントのグループに外部ユーザーを追加しないでください。
セッション継続時間の制御に個別のアクセス バインディングを使用する
コンテキストアウェア アクセス制御に加えて、アクセス バインディングを使用してブラウザ セッションと OAuth トークンの長さを管理することもできます。
アクセス バインディングを使用してコンテキストアウェア アクセスを制御する場合は、アクセス バインディングの重複を避けることをおすすめします。
アクセス バインディングを使用してセッションの長さを制御する場合は、重複するアクセス バインディングを作成しないでください。このようなアクセス バインディングがユーザーに複数適用されている場合、最後に更新されたアクセス バインディングのみが有効になり、意図しない結果が生じる可能性があります。
このような意図しない結果を防ぐには、別のアクセス バインディングを使用してセッションの長さを制御します。
ユーザーがサービス アカウントとして機能することを許可しない
アクセス バインディングは Cloud Identity ユーザーと Google Workspace ユーザーに適用されますが、サービス アカウントには影響しません。ユーザーがサービス アカウントとして認証して操作できるようにすると、コンテキスト認識アクセス制御が損なわれる可能性があります。
ユーザーがサービス アカウントとして動作できる場合、他のリスクも発生します。ユーザーが一時的に権限を昇格できるようにする場合は、Privileged Access Manager を使用することをおすすめします。開発目的以外でサービス アカウントの権限借用を使用しないでください。
サービス アカウントとサービス アカウント キーを保護する方法の詳細については、サービス アカウントの使用に関するベスト プラクティスとサービス アカウント キーの管理に関するベスト プラクティスをご覧ください。
VPC サービス境界の上り（内向き）ルール
上り（内向き）ルールを使用すると、サービス境界の外部から境界内のリソースへのコンテキストアウェア アクセスを許可できます。VPC サービス境界と上り（内向き）ルールは、個々のアプリではなく、 Google Cloud リソースを保護します。したがって、上り（内向き）ルールを含むサービス境界は、 Google Cloud コンソールや gcloud CLI などの管理ツールにコンテキスト認識アクセスを適用する場合に最適です。
VPC サービス境界の詳細とベスト プラクティスについては、VPC Service Controls を有効にするためのベスト プラクティスをご覧ください。
以降のセクションでは、上り（内向き）ルールを使用してコンテキスト認識アクセスを適用する場合の推奨事項について説明します。
IAP TCP 転送を制限付きサービスとして含める
次の理由により、ユーザーが SSH または RDP を使用してサービス境界内の VM インスタンスに接続できるようにすることは危険な場合があります。
- SSH と RDP の使用には Google API へのアクセスが含まれないため、上り（内向き）ルールは接続に適用されません。
- ユーザーが SSH セッションまたは RDP セッションを確立すると、そのセッション内から開始された API アクセスは、サービス境界内から発信されたと見なされます。そのため、上り（内向き）ルールは、そのセッション内から開始された API アクセスには適用されません。
これらのリスクを軽減するには、IAP TCP 転送を介してのみ VM への SSH アクセスと RDP アクセスを許可します。
iaptunnel.googleapis.comサービスを制限付きサービスとして含めます。- IAP TCP 転送を介して SSH ポートと RDP ポートへのアクセスを制限するファイアウォール ルールを構成します。
IAP TCP 転送を使用して、VPC サービス境界の上り（内向き）ルールの構成がすべての SSH アクセスと RDP アクセスの試行に適用されるようにします。
機密性の高いサービス境界に証明書ベースのアクセスを使用する
デフォルトでは、Google アクセス トークンと更新トークンはデバイスにバインドされておらず、盗難やリプレイ攻撃に対して脆弱になる可能性があります。これらのリスクを軽減するために、信頼できる X.509 証明書を所有するデバイスへのアクセスを制限する証明書ベースのアクセス（CBA）を使用できます。
CBA はセキュリティの強化に役立ちますが、このアプローチでは追加のインフラストラクチャ要件も必要になります。
- ユーザーのデバイスには、内部認証局が発行した X.509 証明書が必要です。
- 証明書に関連付けられた鍵は、不正なエクスポートを防ぐ方法で保存する必要があります。
- クライアント アプリは、相互 TLS（mTLS）認証を使用してGoogle Cloud APIs に接続する必要があります。
CBA を使用して、最も機密性の高い VPC サービス境界へのアクセスを保護します。このアプローチでは、セキュリティの強度とインフラストラクチャの要件および全体的な影響を最小限に抑えることができます。
寄稿者
著者: Johannes Passing | クラウド ソリューション アーキテクト
その他の寄稿者: Ido Flatow | クラウド ソリューション アーキテクト