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