Google Cloudを利用していく上で、必ずセキュリティは意識する必要があります。
不必要な外部IPを設定させたくない、日本国外のリージョンを利用させたくないといった観点は、運用上またはセキュリティ上でてくると思われます。
Google Cloudでは組織のポリシーを利用することで、上記対応を実現できます。
今回は組織のポリシーのユースケースや実際の利用方法を踏まえて紹介していきます。
また組織のポリシーは弊社の過去ブログでも紹介していますので、ぜひご確認ください!
組織のポリシーの概要は公式ドキュメントでも記載されています。
内容を要約すると、次の通りとなります。
組織のポリシーは 組織レベルで設定可能な特定ルールに基づいたセキュリティ設定 となります。
組織に設定した場合、フォルダ及びプロジェクトにも同じ設定を反映させることもできます。
では組織のポリシーのメリット・デメリットを考えてみましょう。
組織のポリシーのユースケースは以下の通りとなります。
こちらはあくまでも一例となりますので、他にも利用可能なユースケースはございます。
組織のポリシーには、フラグ型設定とリスト型設定の2つがあります。
フラグ型設定は名前の通り、設定時にTrue/Falseを定義する、つまりポリシーを適用するか適用しないかのみ定義する設定です。
フラグ型設定を利用した場合、組織全体、フォルダ配下全体に設定適用が実施されます。
リスト型設定は、カスタム定義を用いることで、xxxのみを許可/拒否するといった複雑な設定を実施することができます。
例えば、Cloud SchedulerのキックをPub/Subのみ受け付けるといった形で定義します。
ポリシー自体がリスト型定義かフラグ型定義かは、公式ドキュメントに記載されていますので詳細はこちらをご確認ください。
組織のポリシーの設定を実施する際、組織に対して組織ポリシー管理者の権限付与が必要となります。
またCLIベースでの組織のポリシー適用を実施する際、プロジェクトに対してOrganization Policy APIの設定有効化が必要となります。GUIベースで作業される場合は設定する必要がございません。
今回はコマンドベース及び定義ファイルベースでの設定方法の共有となりますので、本記事を参考に実施する場合は定義設定をお願いいたします。
コマンドベースの場合は下記コマンドにて設定を実施します。下記コマンドは、組織全体に対して組織のポリシーを有効化するコマンドとなります。
gcloud resource-manager org-policies enable-enforce [組織のポリシーID] --organization=[組織ID]
組織IDの部分は、 --folder=[フォルダID] や --project=[プロジェクトID]に変更することで、フォルダやプロジェクトに設定可能となります。
組織のポリシーIDは、constraints/配下に定義されているIDとなります。下記画像であれば、iam.allowServiceAccountCredentialLifetimeExtensionが組織IDとして定義されます
では実際に設定してみましょう。
今回は例として、サービスアカウントキー作成を無効化する、サービス アカウント キーの作成を無効化(constraints/iam.disableServiceAccountKeyCreation)ルールを有効化してみます。
## オプション部分は適宜修正してください
$ gcloud resource-manager org-policies enable-enforce iam.disableServiceAccountKeyCreation --project=[プロジェクトID]
booleanPolicy:
enforced: true
constraint: constraints/iam.disableServiceAccountKeyCreation
etag: CNPEr6gGEODO4YID
updateTime: '2023-09-21T06:27:31.811100Z'
こちらで反映が完了しました。実際の画面を見てみましょう。
プロジェクトを選択し、[IAMと管理] → [組織のポリシー] を選択。検索欄にて「Disable service account key creation」を入力して詳細ルールを確認します。
下記画像のように、ステータス 適用済み と出力されていれば成功です
次はリスト型のポリシー設定です。
リスト型のポリシーはGUI上でも設定できますが、定義ファイルを指定することで設定も可能となります。
今回は、ロケーションベースで作成できるGoogle Cloudリソースの制限を行う「リソース ロケーションの制限(gcp.resourceLocations)」を定義してみます。
定義ファイルは下記の通りとなります。ブール型と同じく、プロジェクトに対して適用を実施します。
今回はasia-northeast1とasia-northeast2のロケーションを許可する設定を実施し、定義ファイルはyamlベースで作成します。
name: projects/[プロジェクトID]/policies/gcp.resourceLocations
spec:
rules:
- values:
allowedValues:
- in:asia-northeast1-locations
- in:asia-northeast2-locations
$ gcloud org-policies set-policy resourceLocationsPolicy.yaml
Created policy [projects/[プロジェクトID]/policies/gcp.resourceLocations].
name: projects/[プロジェクトNo]/policies/gcp.resourceLocations
spec:
etag: CKqo4acGEMDn39kd27
rules:
- values:
allowedValues:
- in:asia-northeast1-locations
- in:asia-northeast2-locations
updateTime: '2023-09-06T10:27:54.709080Z'
下記画像のとおりになっているはずです。これで、作成可能なリソースがasia-northeast1とasia-northeast2の日本国内リージョンのみとなりました。
ただし、こちらのポリシー設定を実施してもグローバルリソースは作成可能となりますので注意が必要となります(Cloud Loggingのログバケット等のサービスが該当します)。
組織のポリシーを適用することで、Google Cloud上のセキュリティを簡単に向上させることができます。
また今回試してみた通り、リソース作成可能なリージョン制限、サービスアカウントキーの無効化等プロジェクト運用をしていく上で必要な項目を簡単に制御することができます。
ぜひ組織のポリシーを利用してみてください。
Google Cloud、Google Workspaceに関する お問い合わせはこちら
XIMIX(サイミクス)は商標登録出願中です