組織のポリシー設定
Embedded Files
組織のポリシーを用いて実現できる制限の一例は下記になります。これらは、フォルダ構成を決定する上で必要となる観点となります。
利用できるリージョンを制限する
許可される Google Cloud API とサービスを制限する
Cloud IAM ポリシーに追加できる一連のメンバーを制限する
デザイン パターン詳細
リージョンを制限する
リージョンを制限する
解決する課題・使い所
エンタープライズのご利用者様における法制度対応を目的として、 Google Cloud のリソースが配置されるリージョンを国内の東京リージョンと大阪リージョンに限定したいという場合がございます。
使用する API とサービス数、インスタンス数、ユーザー数が多くなり、コンソールで確認する運用コストが増加した場合は、組織のポリシーを用いてリージョンを限定することが効果的になります。
組織のポリシーの制約を用いることで、Google Cloud のシステムレベルでリソースが配置されるリージョンを特定のリージョンに限定することが可能となります。
アーキテクチャ
ここでは、組織ポリシーの適用例を図示します。組織ポリシーが適用される範囲を踏まえ、適切な組織、フォルダ、プロジェクト レベルで設定します。
メンテナンスの容易性の観点から、プロジェクト単位での権限付与よりも、できるだけ上位の組織、フォルダ単位での権限の付与を推奨します。
利点
リソース ロケーションの制限を行うことで、使用可能なリージョンを組織のポリシーのレベルで担保できます。
注意事項
上記の実現方法を検討する際に考慮する必要があるのは、以下のポイントになります。
使用する API とサービスの把握
使用するインスタンスの数
Google Cloud を利用するユーザーの数
使用する API とサービス数、インスタンス数、ユーザー数が少ない場合は、サービス利用開始時やインスタンス等の作成時に国内のリージョンを選択するように心がけ、コンソールを用いて各サービスにて使用しているリージョンを定期的に確認する運用を導入することで、設定と運用の工数を最小化しつつ目的を達成することができます。
API ・サービスを制限する
API ・サービスを制限する
解決する課題・使い所
使用する API とサービスが明確になっており、不要なサービスが誤って利用されることを回避したいという場合があります。
使用する API とサービス数、インスタンス数、ユーザー数が多くなり、コンソールで確認する運用コストが増加した場合は、組織のポリシーを用いて使用する API とサービスを限定することが効果的になります。
組織のポリシーの制約を用いることで、Google Cloud のシステムレベルで、使用する API とサービスを限定することが可能になります。
アーキテクチャ
ここでは、組織ポリシーの適用例を図示します。組織ポリシーが適用される範囲を踏まえ、適切な組織、フォルダ、プロジェクト レベルで設定します。
メンテナンスの容易性の観点から、プロジェクト単位での権限付与よりも、できるだけ上位の組織、フォルダ単位での権限の付与を推奨します。
利点
許可される Google Cloud API とサービスを制限することで、使用する API とサービスを組織のポリシーのレベルで担保できます。
注意事項
上記の実現方法を検討する際に考慮する必要があるのは、以下のポイントになります。
使用する API とサービスの把握
使用するインスタンスの数
Google Cloud を利用するユーザーの数
利用する API とサービス数、インスタンス数、ユーザー数が少ない場合は、不要なサービスを利用しないように心がけ、コンソールを用いて利用 API・サービスを定期的に確認する運用を導入することで、設定と運用の工数を最小化しつつ目的を達成することができます。
Cloud IAM のメンバーを制限する
Cloud IAM のメンバーを制限する
解決する課題・使い所
Cloud IAM ポリシーに追加できるメンバーを制限し、不要なメンバーが登録されることを回避したいという場合があります。
許可または拒否したい Cloud Identity または Google Workspace（旧 G Suite）お客様 ID が多くなり、確認する運用コストが増加した場合は、組織のポリシーを用いて制限することが効果的になります。
組織のポリシーの制約を用いることで、Google Cloud のシステムレベルで、許可または拒否したい Cloud Identity を設定し、不要なメンバーの登録を回避することが可能になります。
アーキテクチャ
ここでは、組織ポリシーの適用例を図示します。組織ポリシーが適用される範囲を踏まえ、適切な組織、フォルダ、プロジェクトレベルで設定します。メンテナンスの容易性の観点から、プロジェクト単位での権限付与よりも、できるだけ上位の組織、フォルダ単位での権限の付与を推奨します。
利点
ID とアクセスの管理を設定することで、予期せぬメンバーが登録されないことを組織のポリシーのレベルで担保できます。
注意事項
上記の実現方法を検討する際に考慮する必要があるのは、以下のポイントになります。
許可または拒否したい Cloud Identity または Google Workspace（旧 G Suite）お客様 ID の把握
許可または拒否したい Cloud Identity または Google Workspace（旧 G Suite）お客様 ID が少ない場合は、不要なメンバーが登録されないように心がけ、コンソールを用いて Cloud IAM ポリシーに追加されたメンバーを定期的に確認する運用を導入することで、設定と運用の工数を最小化しつつ目的を達成することができます。
関係するデザインパターン
適切な組織、フォルダ構成と権限付与
事前定義ロールの使用
IAM Conditions の使用
Page updated
Report abuse