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
)。
組織が作成されると、いくつかのグループが作成されることが強く推奨されます。これらのいずれかを管理している場合、組織全体または重要な部分が侵害される可能性があります:
グループ | 機能 |
| 組織に属するリソースの管理。 このロールは慎重に割り当ててください。組織管理者はすべてのGoogle Cloudリソースにアクセスできます。 代わりに、この機能は非常に特権的であるため、グループを作成するのではなく、個別のアカウントを使用することを検討してください。 |
| ネットワーク、サブネット、ファイアウォールルール、およびCloud Router、Cloud VPN、クラウドロードバランサーなどのネットワークデバイスの作成。 |
| 請求アカウントの設定と使用状況の監視。 |
| アプリケーションの設計、コーディング、およびテスト。 |
| アクセス管理や組織制約ポリシーを含む、組織全体のセキュリティポリシーの確立と管理。 Google Cloudセキュリティ基盤ガイドのGoogle Cloudセキュリティ基盤ガイドを参照して、Google Cloudセキュリティインフラストラクチャの計画に関する詳細情報を確認してください。 |
| 継続的インテグレーションとデリバリー、監視、システムプロビジョニングをサポートするエンドツーエンドのパイプラインの作成または管理。 |
| |
| |
| |
| プロジェクトの支出を監視します。典型的なメンバーは財務チームの一部です。 |
| Google Cloud組織全体のリソース情報を確認します。 |
| クラウドセキュリティのレビュー。 |
| ネットワーク構成のレビュー。 |
| 監査ログの表示。 |
| セキュリティコマンドセンターの管理。 |
| 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)