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