Google Cloudの「組織のポリシー」と「IAMポリシー」の違いを理解する
はじめに
こんにちは、クラウドエース システム開発部 バックエンドディビジョン所属の廣瀬です。
Google Cloud のアクセス管理に関わる機能の中で「ポリシー」と名前のつく「組織のポリシー」「IAM ポリシー」と呼ばれる機能があります。
名前も似ており、かつ機能内容も近いことから区別がつきにくい機能となっております。
本記事では、こちらのポリシーの機能としての違いと 2 つの機能を用いたリソースのアクセス管理の設計にあたっての考慮事項をまとめていきます。
対象読者
- Google Cloud の「組織のポリシー」「IAM ポリシー」の違いがよくわからないという方
- Google Cloud のリソースのアクセス管理の設計について検討している方
説明すること／説明しないこと
-
説明すること
- 「組織のポリシー」「IAM ポリシー」の各機能の概要説明と違い
- 両ポリシーとリソース階層を使ったアクセス管理の設計の考慮事項
-
説明しないこと
- 具体的な「組織のポリシー」「IAM ポリシー」の使い方
「ポリシー」の機能の違い
「組織のポリシー」と「IAM ポリシー」についての違いを表で表すとこちらの内容となります。
| 特徴 | 組織のポリシー | IAM ポリシー |
|---|---|---|
| 概要 | 組織やフォルダに所属するリソースに対する一律な制約を行う機能 | プリンシパル[1]（個々のユーザーやグループ等）に対するリソースのアクセス権の付与を行う機能 |
| 誰を制限する？ | 組織に所属するすべてのプリンシパル | 指定したプリンシパル |
| どんな制限が設定できる？ | 制約によるリソースの利用の制限 | ロール（リソースを実行するための権限）の付与によるリソースに対するアクセス許可/拒否 |
| ポリシーの適応対象 | 組織、フォルダ、プロジェクト | 組織、フォルダ、プロジェクト、特定のリソース |
| ポリシーの継承 | あり | あり |
| 具体的な使用例 | ・ 組織のすべてのリソースに対して、選択可能なリージョンを東京/大阪リージョンに限定する ・ 特定のフォルダのすべてのプロジェクトに対して、サービスアカウントキーの発行を無効化する |
・ 特定のアカウントに対して、特定のプロジェクトの Compute Engine のインスタンスの作成する権限を与える。 ・ 特定の Google グループに対して、特定のフォルダの Cloud Storage のオブジェクトの閲覧権限を与える。 |
Google Cloud のリソース階層
両ポリシーの機能内容や利便性を理解する前に、Google Cloud のリソース階層について理解することが必要です。
Google Cloud では、企業や団体が複数のプロジェクトを管理するために、「組織」と呼ばれるリソースを作成し、下記の階層を持った構造でリソースを管理することができます。
| 階層 | 説明 | 階層 |
|---|---|---|
| 組織 | 組織は Google Cloud のリソース階層の最上位レベル。組織は一つのみ。 | 高 |
| フォルダ | フォルダは組織内のリソースを整理するための論理的なグルーピング 組織に紐づく形で、フォルダの中にフォルダ、またはプロジェクトを配置することが可能。 |
↓ |
| プロジェクト | プロジェクトは Google Cloud リソースの基本的な単位。 下層のリソースは必ず一つのプロジェクトに紐づく。 |
↓ |
| リソース | Google Cloud のサービス。 Compute Engine や Cloud Storage などの Google Cloud のサービスを指す。 |
低 |
組織のポリシーとは
組織ポリシーとは、組織/フォルダ/プロジェクトに対して制約と呼ばれるルールを設定し、一律なリソースの利用を制限する機能です。
組織のポリシーは、こちらの弊社ブログでも解説していますので、ご確認いただければと思います。
制約
組織のポリシーは制約を定義し、ポリシーを適応します。
制約には、Google 側が事前定義した制約があり、ユーザー側は事前定義された制約を基本的には利用していきます。
例えば、事前定義された制約の中には「リソースサービスの使用を制限する」という制約があり、指定したリソースのみ（例えば Cloud Storage のみ）利用することを可能にする制限を設定することができます。
また、制約はリスト型とブール型の 2 タイプの制約が定義されております。
-
リスト型
- 特定のリソースの利用可否を、指定された「許可値」または「拒否値」を用いて評価
- 例) 制約「Google Cloud Platform - リソースの場所の制限（constraints/gcp.resourceLocations）」を用いて、東京リージョン/大阪リージョンを許可値としてリスト定義した場合、指定したリージョンにのみリソースの作成が可能となる制限を設定できる
-
ブール型
- 特定のリソースの利用可否を、指定された Bool 値（True Or False）を用いて評価
- 例) 制約「サービスアカウントキーの作成を無効にする（constraints/iam.disableServiceAccountKeyCreation）」を用いて、True 値を定義した場合、サービスアカウントキーの発行が不可なる制限を設定できる
事前定義された組織のポリシーは、コンソール上で見ることができますので、ご確認ください。
適応対象
組織のポリシーを適応できるリソースは、組織/フォルダ/プロジェクトとなります。
組織のポリシーの継承
組織のポリシーは、下記の表のルールの下、組織/フォルダ/プロジェクトの階層の上位から下位に対して、ポリシーが継承されます。
| 継承のルール | 設定例 | 設定例の結果 | 図の Resource 番号 |
|---|---|---|---|
| ポリシーは、上位層から継承される | 組織で A のポリシーを設定。 | プロジェクトは、A のポリシーが適応 | - |
| ポリシーは加算されて評価される | 組織で A、プロジェクトで B のポリシーを設定。 | プロジェクトは、A+B のポリシーが適応 | Resource1 |
| 継承された特定のポリシーの拒否可能 | 組織で A と B のポリシーを設定、プロジェクトで A のポリシーの継承を拒否。 | プロジェクトは、B のポリシーのみ適応 | Resource2 |
| ポリシーの継承の禁止が可能 | 組織で A と B のポリシーを設定、プロジェクトでポリシーの継承を禁止。 | プロジェクトには上位層からのポリシーは継承されない | - |
| ポリシーの継承の上書きが可能 | 組織で A と B のポリシーを設定、プロジェクトでポリシーの継承を禁止。 その上で、プロジェクトで C のポリシーを設定。 |
プロジェクトは C のポリシーのみ適応 | Resource3 Resource4 |
| ブール型のポリシーは、拒否のポリシーの方が評価順位は高い | フォルダで A のポリシーを拒否、かつプロジェクトで A のポリシーを許可する。 | プロジェクトは A のポリシーは拒否される | - |
| リスト型のポリシーは加算されて評価される | 組織で、制約「リソースの場所の制限」を用いて、「東京リージョン」を指定、プロジェクトで、大阪リージョンを指定する。 | プロジェクトでは、「東京/大阪リージョン」が指定される | - |
- 組織のポリシーの継承の図（引用：階層の例）
IAM ポリシーとは
IAM ポリシーとは、Identity and Access Management（IAM）で使用されるアクセス制御を定義するポリシーです。（許可ポリシーとも呼ばれます。）
IAM ポリシーを定義し、誰（プリンシパル）がリソースへのアクセスする権限（ロール）を付与されているか定義することにより、リソースへのアクセス制御を管理する機能です。
IAM ポリシーのプリンシパル
組織のポリシーと大きく異なる点として、IAM ポリシーは指定した下記のプリンシパルに対してアクセス権限の付与を指定します。
- Google アカウント
- サービス アカウント
- Google グループ
- Google Workspace/Cloud Identity ドメイン
ロールと権限
Google Cloud のリソースへアクセスするために、各リソースの操作ごと（API ごと）に権限が定義されております。
ただ、操作ごとに定義されているため、権限は非常に多く、一つ一つプリンシパルに付与すると管理が煩雑になります。
そこで、特定の役割を実行できるように、一連の権限を定義しているのがロールとなります。
例えば、Cloud Storage の「Storage オブジェクト作成者」ロールには、Cloud Storage のオブジェクトの作成のため、オブジェクトの表示/作成/削除等の権限が含まれております。
どんな権限があり、どのロールに含まれるかはこちらのリファレンスから確認することができます。
適応対象
組織のポリシーを適応できるリソースは、組織/フォルダ/プロジェクト/特定のリソースとなります。
拒否ポリシー
IAM では、IAM ポリシー（許可ポリシー）の他に、拒否ポリシーを定義できます。
拒否ポリシーを定義することにより、特定のプリンシパルに対して特定の権限を使用できないようにすることが可能です。
例えば、プロジェクトに対して、A さんの Google アカウントに、オーナーロールが付与されていた場合に、プロジェクトの削除権限(resourcemanager.projects.delete)を拒否する拒否ポリシーを定義すると、A さんは他の操作は可能ですが、プロジェクトを削除することができなくなります。
IAM ポリシーの継承
IAM のポリシーも、下記の表のルールの下、組織/フォルダ/プロジェクトの階層の上位から下位に対して、ポリシーが継承されます。
| 継承のルール | 設定例 | 設定例の結果 |
|---|---|---|
| ポリシーは、上位層から継承される | 組織で A のポリシーを設定。 | プロジェクトは、A のポリシーが適応 |
| ポリシーは加算されて評価される | 組織で A、プロジェクトで B のポリシーを設定。 | プロジェクトは、A+B のポリシーが適応 |
| 継承されたポリシーは変更/削除ができない | 組織で A のポリシーを設定。 プロジェクトでは継承された A については変更/削除ができない。 |
プロジェクトは、A のポリシーが適応 |
| 拒否ポリシーは、IAM（許可）ポリシーよりも評価が優先される | - 組織で、〇〇さんに Cloud Storage の「Storage オブジェクト管理者」ロール付与する IAM ポリシーを設定。 - プロジェクトで、〇〇さんに 「オブジェクトの閲覧」権限を拒否する拒否ポリシーを設定。 |
プロジェクトでは、〇〇さんは Cloud Storage のオブジェクトの閲覧操作が不可となる。 他のオブジェクト操作は可能。 |
両ポリシーを使った設計における考慮事項
Google Cloud のリソース階層構造に、実組織の構造を反映させる
-
実組織とリソース階層を同様の構造にすると、「組織のポリシー」「IAM ポリシー」のポリシーの継承により効率的にアクセス制限を管理することが可能です。
-
例）
- 「A 事業部」は国内向けのアプリ開発事業のみのため、組織のポリシーの「リソース ロケーションの制限」を用いて、東京/大阪リージョンのロケーションの制限を設ける。
- 「△△ アプリ」開発チームに対して、チームリーダーのアカウントに「△△ アプリ」フォルダへ「オーナー」ロールを割り当てる IAM ポリシーを設定することにより、チームリーダーへ、「△△ アプリ」直下のリソースのあらゆる権限を割り当てる。
-
IAM ポリシーでは、グループに対してポリシーを定義する方が管理が効率的になります。
- 「A 事業部 △△ アプリチーム」から異動があった場合、「A 事業部 △△ アプリチーム」のグループから、アカウントを移動先のグループへ移動するのみで、必要なロールの移動が可能になります。
ポリシーの優位性を理解する
- 正しいリソースの制限を設けるために、両ポリシーのポリシーの継承のルールを理解することが必要です。
- 組織のポリシーの方が、IAM ポリシーよりも評価の優先順位が高いこと考慮してください。
- 例えば、組織のポリシーで「サービス アカウント キーの作成を無効化」を設定すると、サービスアカウントキーの作成権限を持ったユーザーでも、キーを発行することはできません。
「最小権限の原則」を考慮してポリシーを設定する
-
セキュリティ向上のため、不要なリソースのアクセス権限を持たないように、ポリシーの設定を行うことが必要です。
- Compute Engine で開発するだけのユーザーに、オーナーロールを付与して作業させた場合、アカウントの乗っ取り等で付与したユーザーがあらゆるリソースの不正利用が可能になってしまいます。
-
ただ、制約や権限によるリソース利用の絞り込みは、リソース階層の上位層では緩やかにして、下層のフォルダやプロジェクトで制限の絞り込みを行う方が、管理面では効率的です。
- 下層の特定のプロジェクトのみ、継承されたポリシーを、"組織のポリシーの継承の拒否"や"拒否ポリシー"を用いて制限を変更すると、制限を緩めたプロジェクトを覚えておかなければならず、管理が煩雑になります。
- 下層のリソースで限定的に制限を緩めるのではなく、下層のリソースで権限の絞り込みを行った方が、管理の煩雑さは軽減します。
まとめ
本記事では、Google Cloud で名称、機能ともに似ている「組織のポリシー」と「IAM ポリシー」の違いと、2 つのポリシーを用いたリソースのアクセス管理の設計にあたっての考慮事項をまとめました。
特に両ポリシーを使った設計における考慮事項で記載した内容は、効率的なアクセス管理のために、実践していただきたい内容となりますので、ご参考にしていただければ幸いです。
-
Google Cloud のリソースへアクセスできる ID。Google アカウントやグループのことを指す。 ↩︎
Discussion