GCP - Basic Information
リソース階層
Google Cloudは、従来のファイルシステムの概念に似たリソース階層を使用しています。これにより、ポリシーや権限の特定のアタッチポイントを持つ論理的な親/子ワークフローが提供されます。
高レベルでは、次のようになります：
仮想マシン（Compute Instanceと呼ばれる）はリソースです。リソースはプロジェクト内に存在し、他のCompute Instance、ストレージバケットなどと一緒に存在する可能性があります。
プロジェクトの移行
組織なしでプロジェクトを移行することが可能です。必要な権限はroles/resourcemanager.projectCreatorとroles/resourcemanager.projectMoverです。プロジェクトが他の組織内にある場合は、最初にその組織から移動するためにGCPサポートに連絡する必要があります。詳細についてはこちらを確認してください。
組織ポリシー
組織のクラウドリソースに対する中央集権的な管理を可能にします：
組織のリソースの使用方法に制限を設定するための中央集権的な管理。
開発チームがコンプライアンスの境界内に留まるためのガードレールを定義し、確立する。
プロジェクトオーナーとそのチームがコンプライアンスを破る心配なく迅速に移動できるように支援します。
これらのポリシーは、組織全体、フォルダー、またはプロジェクトに影響を与えるように作成できます。ターゲットリソース階層ノードの子孫は組織ポリシーを継承します。
組織ポリシーを定義するために、特定のGoogle CloudサービスまたはGoogle Cloudサービスのグループに対する制限の特定のタイプである制約を選択します。その制約を希望する制限で構成します。
一般的な使用例
ドメインに基づいてリソース共有を制限する。
アイデンティティおよびアクセス管理サービスアカウントの使用を制限する。
新しく作成されたリソースの物理的な場所を制限する。
サービスアカウントの作成を無効にする。
組織のリソースに対する詳細な制御を提供する多くの制約があります。詳細については、 すべての組織ポリシーサービス制約のリストを参照してください。
デフォルトの組織ポリシー
IAMロール
これらはAWSのIAMポリシーのように、各ロールには一連の権限が含まれています。
しかし、AWSとは異なり、ロールの中央リポジトリはありません。その代わりに、リソースはYプリンシパルにXアクセスロールを付与し、リソースへのアクセスを持つ人を知る唯一の方法は、そのリソースに対してget-iam-policyメソッドを使用することです**。
これは問題になる可能性があります。なぜなら、プリンシパルがどの権限を持っているかを知る唯一の方法は、すべてのリソースに対して誰に権限を与えているかを尋ねることだからです。ユーザーはすべてのリソースから権限を取得する権限を持っていない可能性があります。
IAMには3種類のロールがあります：
基本/プリミティブロール、これはIAM導入前に存在したオーナー、エディター、およびビューアロールを含みます。
事前定義されたロール、特定のサービスに対する詳細なアクセスを提供し、Google Cloudによって管理されます。多くの事前定義されたロールがあり、それらが持つ権限をすべて こちらで確認できます。
カスタムロール、ユーザーが指定した権限のリストに基づいて詳細なアクセスを提供します。
GCPには数千の権限があります。ロールが権限を持っているかどうかを確認するには、こちらで権限を検索し、どのロールがそれを持っているかを確認できます。
また、こちらで事前定義されたロールを検索 各製品によって提供されます。 一部のロールはユーザーに付与できず、サービスアカウントにのみ付与できることに注意してください。 さらに、権限は関連するサービスに付与されている場合にのみ有効になります。
また、カスタムロールが ここで特定の権限を使用できるかどうかを確認してください。
GCP - IAM, Principals & Org Policies Enumユーザー
GCPコンソールにはユーザーやグループの管理はなく、Google Workspaceで行われます。ただし、Google Workspaceで異なるアイデンティティプロバイダーを同期することは可能です。
Workspacesのユーザーとグループには https://admin.google.comでアクセスできます。
MFAはWorkspacesユーザーに強制できますが、攻撃者はトークンを使用してGCPにcli経由でアクセスでき、MFAによって保護されません（ユーザーがトークンを生成するためにログインしたときのみMFAによって保護されます：gcloud auth login）。
グループ
組織が作成されると、いくつかのグループが作成されることが強く推奨されます。これらのいずれかを管理している場合、組織全体または重要な部分が侵害される可能性があります：
グループ | 機能 |
| 組織に属するリソースの管理。 このロールは慎重に割り当ててください。組織管理者はすべてのGoogle Cloudリソースにアクセスできます。 代わりに、この機能は非常に特権的であるため、グループを作成するのではなく、個別のアカウントを使用することを検討してください。 |
| ネットワーク、サブネット、ファイアウォールルール、およびCloud Router、Cloud VPN、クラウドロードバランサーなどのネットワークデバイスの作成。 |
| 請求アカウントの設定と使用状況の監視。 |
| アプリケーションの設計、コーディング、およびテスト。 |
| アクセス管理や組織制約ポリシーを含む、組織全体のセキュリティポリシーの確立と管理。 Google Cloudセキュリティ基盤ガイドのGoogle Cloudセキュリティ基盤ガイドを参照して、Google Cloudセキュリティインフラストラクチャの計画に関する詳細情報を確認してください。 |
| 継続的インテグレーションとデリバリー、監視、システムプロビジョニングをサポートするエンドツーエンドのパイプラインの作成または管理。 |
| |
| |
| |
| プロジェクトの支出を監視します。典型的なメンバーは財務チームの一部です。 |
| Google Cloud組織全体のリソース情報を確認します。 |
| クラウドセキュリティのレビュー。 |
| ネットワーク構成のレビュー。 |
| 監査ログの表示。 |
| セキュリティコマンドセンターの管理。 |
| Secret Managerでのシークレットの管理。 |
デフォルトのパスワードポリシー
強力なパスワードを強制する
8文字から100文字の間
再利用しない
有効期限なし
他のプロバイダーを通じてWorkspaceにアクセスしている場合、これらの要件は適用されません。
サービスアカウント
これらは、リソースが添付され、GCPと簡単に対話するためにアクセスできるプリンシパルです。たとえば、VMに添付されたサービスアカウントのauthトークンにメタデータでアクセスすることが可能です。
IAMとアクセススコープの両方を使用する際にいくつかの競合が発生する可能性があります。たとえば、サービスアカウントがcompute.instanceAdminのIAMロールを持っている場合でも、侵害されたインスタンスにはhttps://www.googleapis.com/auth/compute.readonlyのスコープ制限がかかっている可能性があります。これにより、インスタンスに自動的に割り当てられたOAuthトークンを使用して変更を加えることができなくなります。
これはAWSのIAMロールに似ています。しかし、AWSとは異なり、任意のサービスアカウントは任意のサービスに添付できます（ポリシーを介して許可する必要はありません）。
使用を開始すると、実際にGCPによって自動的に生成されるサービスアカウントがいくつかあります。例えば：
しかし、カスタムサービスアカウントを作成してリソースにアタッチすることも可能です。これは次のようになります：
キーとトークン
GCPにサービスアカウントとしてアクセスする主な方法は2つあります：
OAuthトークン経由：これらはメタデータエンドポイントやHTTPリクエストを盗むことで得られるトークンで、アクセススコープによって制限されます。
キー：これらはサービスアカウントとしてリクエストに署名したり、サービスアカウントとしてアクションを実行するためのOAuthトークンを生成したりするための公開鍵と秘密鍵のペアです。これらのキーは制限と管理がより複雑なため危険です。そのため、GCPは生成しないことを推奨しています。
サービスアカウントが作成されるたびに、GCPはユーザーがアクセスできないサービスアカウント用のキーを生成します（ウェブアプリケーションには表示されません）。このスレッドによると、このキーはGCPによって内部的に使用され、メタデータエンドポイントがアクセス可能なOAuthトークンを生成するためのアクセスを提供します。
アクセススコープ
アクセススコープは、GCP APIエンドポイントにアクセスするために生成されたOAuthトークンに添付されます。これらはOAuthトークンの権限を制限します。 これは、トークンがリソースのオーナーに属していても、そのリソースにアクセスするためのトークンスコープがない場合、トークンはその権限を（悪用）するために使用できないことを意味します。
Googleは実際に推奨していますが、アクセススコープは使用せず、IAMに完全に依存することです。ウェブ管理ポータルは実際にこれを強制しますが、カスタムサービスアカウントを使用してプログラム的にインスタンスにアクセススコープを適用することは依然として可能です。
スコープが割り当てられているかどうかは、クエリすることで確認できます：
前述のスコープは、データにアクセスするためにデフォルトで**gcloudを使用して生成されたものです。これは、gcloud**を使用する際に最初にOAuthトークンを作成し、それを使用してエンドポイントに連絡するためです。
これらの中で最も重要なスコープは**cloud-platformであり、基本的にはGCP内の任意のサービスにアクセスできる**ことを意味します。
ここにあるすべての可能なスコープのリストを見つけることができます。
gcloudブラウザ資格情報がある場合、他のスコープでトークンを取得することが可能です。次のようなことを行います：
Terraform IAMポリシー、バインディング、およびメンバーシップ
terraformによって定義されたhttps://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iamを使用してGCPでterraformを使用する場合、リソースに対するプリンシパルのアクセスを付与する方法は異なります：
メンバーシップ：プリンシパルを役割のメンバーとして設定し、役割やプリンシパルに対する制限なしで行います。ユーザーを役割のメンバーとして設定し、同じ役割のメンバーとしてグループを設定し、さらにそれらのプリンシパル（ユーザーとグループ）を他の役割のメンバーとして設定できます。
バインディング：複数のプリンシパルを役割にバインドできます。これらのプリンシパルは他の役割にバインドされたり、メンバーになったりすることができます。ただし、役割にバインドされていないプリンシパルがバインドされた役割のメンバーとして設定されると、次回バインディングが適用されると、メンバーシップは消えます。
ポリシー：ポリシーは権威あるものであり、役割とプリンシパルを示し、その後、これらのプリンシパルはより多くの役割を持つことができず、これらの役割はより多くのプリンシパルを持つことができません。そのポリシーが変更されない限り（他のポリシー、バインディング、またはメンバーシップでも）。したがって、ポリシーで役割またはプリンシパルが指定されると、そのすべての特権はそのポリシーによって制限されます。明らかに、プリンシパルにポリシーを変更するオプションや特権昇格の権限（新しいプリンシパルを作成し、新しい役割にバインドするなど）が与えられた場合、これを回避できます。
参考文献
Last updated
