GCP - Basic Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Google Cloudは、伝統的なファイルシステムの概念に似たリソース階層を使用しています。これにより、ポリシーや権限の特定のアタッチポイントを持つ論理的な親/子ワークフローが提供されます。
高レベルでは、次のようになります：
仮想マシン（Compute Instanceと呼ばれる）はリソースです。リソースはプロジェクト内に存在し、他のCompute Instance、ストレージバケットなどと一緒に存在する可能性があります。
組織なしでプロジェクトを移行することが可能です。必要な権限はroles/resourcemanager.projectCreatorとroles/resourcemanager.projectMoverです。プロジェクトが他の組織内にある場合、最初にその組織から移動するためにGCPサポートに連絡する必要があります。詳細についてはこちらを確認してください。
組織のクラウドリソースに対する中央集権的な管理を可能にします：
組織のリソースの使用方法に制限を設定するための中央集権的な管理。
開発チームがコンプライアンスの境界内に留まるためのガードレールを定義し、確立する。
プロジェクトオーナーとそのチームがコンプライアンスを破る心配なく迅速に移動できるように支援します。
これらのポリシーは、組織全体、フォルダー、またはプロジェクトに影響を与えるように作成できます。ターゲットリソース階層ノードの子孫は組織ポリシーを継承します。
組織ポリシーを定義するために、特定のGoogle CloudサービスまたはGoogle Cloudサービスのグループに対する制限の特定のタイプである制約を選択します。その制約を希望する制限で構成します。
ドメインに基づいてリソース共有を制限する。
アイデンティティおよびアクセス管理サービスアカウントの使用を制限する。
新しく作成されたリソースの物理的な場所を制限する。
サービスアカウントの作成を無効にする。
組織のリソースに対する細かい制御を提供する多くの制約があります。詳細については、 すべての組織ポリシーサービス制約のリストを参照してください。
これらはAWSのIAMポリシーのように、各ロールには一連の権限が含まれています。
しかし、AWSとは異なり、ロールの中央リポジトリはありません。その代わりに、リソースはYプリンシパルにXアクセスロールを付与し、リソースへのアクセス権を持つ者を知る唯一の方法は、そのリソースに対してget-iam-policyメソッドを使用することです**。
これは問題になる可能性があります。なぜなら、プリンシパルがどの権限を持っているかを知る唯一の方法は、すべてのリソースに対して誰に権限を与えているかを尋ねることだからです。ユーザーはすべてのリソースから権限を取得する権限を持っていない可能性があります。
IAMには3種類のロールがあります：
基本/プリミティブロール、これはIAM導入前に存在したオーナー、エディター、およびビューアロールを含みます。
事前定義されたロール、特定のサービスに対する細かいアクセスを提供し、Google Cloudによって管理されます。事前定義されたロールは多数あり、それらが持つ権限をすべて こちらで確認できます。
カスタムロール、ユーザーが指定した権限のリストに基づいて細かいアクセスを提供します。
GCPには数千の権限があります。ロールが権限を持っているかどうかを確認するには、こちらで権限を検索し、どのロールがそれを持っているかを確認できます。
また、こちらで事前定義されたロールを検索 各製品によって提供されます。 一部のロールはユーザーに付与できず、サービスアカウントにのみ付与できることに注意してください。 さらに、権限は関連するサービスに付与されている場合にのみ有効になります。
また、カスタムロールが ここで特定の権限を使用できるかどうかを確認してください。
GCP - IAM, Principals & Org Policies EnumGCPコンソールにはユーザーやグループの管理はなく、それはGoogle Workspaceで行われます。ただし、Google Workspaceで異なるアイデンティティプロバイダーを同期することは可能です。
Workspacesのユーザーとグループには https://admin.google.comでアクセスできます。
MFAはWorkspacesユーザーに強制できますが、攻撃者はトークンを使用してGCPにCLI経由でアクセスでき、MFAによって保護されません（ユーザーが生成するためにログインしたときにのみMFAによって保護されます：gcloud auth login）。
組織が作成されると、いくつかのグループが作成されることが強く推奨されます。これらのいずれかを管理している場合、組織全体または重要な部分が侵害される可能性があります：
グループ
機能
gcp-organization-admins
(チェックリストに必要なグループまたは個人アカウント)
組織に属するリソースの管理。 このロールは慎重に割り当ててください; 組織管理者はすべてのGoogle Cloudリソースにアクセスできます。 代わりに、この機能は非常に特権的であるため、グループを作成するのではなく、個別のアカウントを使用することを検討してください。
gcp-network-admins
(チェックリストに必要)
ネットワーク、サブネット、ファイアウォールルール、およびCloud Router、Cloud VPN、クラウドロードバランサーなどのネットワークデバイスの作成。
gcp-billing-admins
(チェックリストに必要)
請求アカウントの設定と使用状況の監視。
gcp-developers
(チェックリストに必要)
アプリケーションの設計、コーディング、およびテスト。
gcp-devops
継続的インテグレーションとデリバリー、監視、システムプロビジョニングをサポートするエンドツーエンドのパイプラインの作成または管理。
gcp-logging-admins
gcp-logging-viewers
gcp-monitor-admins
gcp-billing-viewer
(もはやデフォルトではない)
プロジェクトの支出を監視します。典型的なメンバーは財務チームの一部です。
gcp-platform-viewer
(もはやデフォルトではない)
Google Cloud組織全体のリソース情報を確認します。
gcp-security-reviewer
(もはやデフォルトではない)
クラウドセキュリティのレビュー。
gcp-network-viewer
(もはやデフォルトではない)
ネットワーク構成のレビュー。
grp-gcp-audit-viewer
(もはやデフォルトではない)
監査ログの表示。
gcp-scc-admin
(もはやデフォルトではない)
セキュリティコマンドセンターの管理。
gcp-secrets-admin
(もはやデフォルトではない)
Secret Managerでのシークレットの管理。
強力なパスワードを強制する
8文字から100文字の間
再利用しない
有効期限なし
他のプロバイダーを通じてWorkspaceにアクセスしている場合、これらの要件は適用されません。
これらは、リソースが添付され、GCPと簡単に相互作用するためにアクセスできるプリンシパルです。たとえば、VMに添付されたサービスアカウントの認証トークンにメタデータでアクセスすることが可能です。
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によって定義されたように、https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iamを使用してGCPでterraformを使用する場合、リソースに対するプリンシパルのアクセスを付与する方法はいくつかあります：
メンバーシップ：プリンシパルを役割のメンバーとして設定し、役割やプリンシパルに対する制限なしで行います。ユーザーを役割のメンバーとして設定し、同じ役割のメンバーとしてグループを設定し、さらにそれらのプリンシパル（ユーザーとグループ）を他の役割のメンバーとして設定できます。
バインディング：複数のプリンシパルを役割にバインドできます。これらのプリンシパルは他の役割にバインドされたり、メンバーであったりすることができます。ただし、役割にバインドされていないプリンシパルがバインドされた役割のメンバーとして設定されると、次回バインディングが適用されると、メンバーシップは消えます。
ポリシー：ポリシーは権威あるものであり、役割とプリンシパルを示し、その後、これらのプリンシパルはさらに役割を持つことができず、これらの役割はさらにプリンシパルを持つことができません。そのポリシーが変更されない限り（他のポリシー、バインディング、またはメンバーシップでも）。したがって、ポリシーで役割またはプリンシパルが指定されると、そのすべての特権はそのポリシーによって制限されます。明らかに、プリンシパルにポリシーを変更するオプションや特権昇格の権限（新しいプリンシパルを作成し、新しい役割にバインドするなど）が与えられた場合、これを回避できます。
AWSハッキングを学び、練習する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、練習する：HackTricks Training GCP Red Team Expert (GRTE)
