Google Cloudのセキュリティを強化する重要組織ポリシー10選
はじめに
クラウドコンピューティングの普及に伴ってサイバー攻撃や内部不正、設定ミス等によるセキュリティインシデントが頻発する中、組織の機密情報を保護するための対策が急務となっています。
Google Cloudが提供する「組織ポリシー」は、このようなセキュリティリスクに包括的に対処するための強力なツールです。組織全体に適用されるセキュリティルールを定義し、リソースの作成やシステム構成を厳格に管理することで、セキュリティのガードレールを確立します。
組織ポリシーを効果的に活用することで、セキュリティインシデントの発生を未然に防ぎ、組織の貴重な機密情報を保護することが可能となります。
本記事では、組織ポリシーの基本概念からセキュリティ強化に効果的な具体的なポリシー、設定時の注意点を交えてご紹介します。
Google Cloudにおける組織ポリシーとは
組織ポリシーは、Google Cloudにおける各リソースの利用方法を組織全体で統一的に管理する為の機能です。
組織に紐づけられたGoogle Cloudでは以下のように組織、フォルダ、プロジェクト、リソースと階層構造を取る事が一般的ですが、組織ポリシーを最上位の組織レベルで設定する事でその配下にある全てのフォルダ、プロジェクト、リソースにポリシーを継承され一貫した管理が可能になります。
Active Directory(AD)を利用した事のある方であれば、組織単位（OU）やグループポリシーをクラウド環境向けに拡張したもの、と考えるとイメージしやすいかもしれません。
以下は、組織配下のリソース階層の一例です。
組織ポリシーは、組織レベルだけでなく、フォルダやプロジェクト単位でも設定可能です。親のポリシーやGoogleのデフォルト値を継承、置き換え、結合することで、利用部門やプロダクト、環境に応じて柔軟に調整する事ができます。
これにより、管理部門は一定のルールを設け、利用者の誤操作によるリスクを低減し、セキュリティ体制を強化できます。
以下は、ポリシーの継承のイメージです。
IAMポリシーとの違い
組織ポリシーと似たような概念として、IAMポリシーが挙げられます。いずれもリソース管理の文脈で登場する概念ですが、どのような管理を行っているかという点で相違点が見られます。
IAMポリシーは、サービスアカウントやユーザー、グループといったID情報に対し、どのリソースに対する権限を付与するかを示すものです。これに対し組織ポリシーは、リソースの構成そのものを制限することに重きをおいています。
IAMポリシーの場合は、リソースへのアクセシビリティを、組織ポリシーはリソースの構成そのものを対象とする違いを覚えておきましょう。
組織ポリシー設定のメリット
組織ポリシーの設定によって、組織のリソース管理を一元管理して業務効率化につながるというメリットがあります。チームが違うからといって、異なるポリシーが適用される心配から解放できるでしょう。
組織ポリシーは、企業のコンプライアンス強化の観点からも評価されている仕組みです。コンプライアンス違反のリスクを顧みず、迅速にアクションへ移行できる柔軟性を確保するのにも貢献するでしょう。
組織ポリシーの表示・編集方法
組織ポリシーを表示するには、まずGoogle Cloudコンソールを展開し[組織のポリシー]ページへ移行しましょう。
続いてプロジェクト選択ツールを選択の上、表示したい組織ポリシーのプロジェクトやフォルダを選択します。[組織のポリシー]ページには[ポリシーの詳細]ページがあるので、ここから制約の適用状況を確認の上、[ポリシーの管理]をクリックしましょう。ここからポリシーの編集が可能です。
セキュリティを強化する重要組織ポリシー10選
組織ポリシーには様々種類があり、記事執筆時点で約130種類のポリシーが定義されています。（参考：組織ポリシーの制約）
本記事では、その中からセキュリティ強化やコンプライアンス順守の観点で特に重要度が高いポリシーを厳選してご紹介します。
1. 共有先のドメインを制限
| 表示名 | Domain restricted sharing |
| ID | iam.allowedPolicyMemberDomains |
概要
Google WorkspaceまたはCloud Identityにおける「顧客ID」を用いて、許可された組織に属しているアカウントやプリンシパルのみを IAM ポリシーへ追加可能なよう制限します。
顧客IDはGoogle Workspace上で確認できます。（参考：顧客IDの確認）
メリット
| 意図しない権限付与の防止 | Gmailを含む個人利用のGoogleアカウントや組織外部のユーザーへアクセス権限を付与する事が出来なくなるため、意図しない組織外のアカウントへの権限付与や設定ミスによるデータ漏洩のリスクを軽減できます。 |
| 組織内アカウントの一元管理 | Google Workspace上で管理されたアカウント、Googleグループのみが追加可能になるため、IdP管理者の意図しない組織外のアカウントへアクセス権が付与される事を抑止できます。 |
注意点
| 組織外部との連携 | 協力会社等、組織外部との連携が必要な場合は許可する顧客IDの追加や組織内アカウントの発行、または組織内のグループへの組織外アカウントの登録が必要となります。 |
| 初期設定時の考慮 | Google社製品を含む一部サービスや外部のデータ連携ツール等の初期設定では、一時的に制限を無効化する必要がある場合があります。（参考：既知の問題のトラブルシューティング） |
2. サービス アカウント キーの作成を無効化
| 表示名 | Disable service account key creation |
| ID | iam.disableServiceAccountKeyCreation |
概要
サービスアカウントにおける キーファイル（JSON または PKCS#12（P12））の作成を禁止します。
万が一にも認証情報が漏洩してしまうと組織内外への多大な損害を被る可能性がありますので、システム構成上、やむを得ない場合を除き使用しない事が推奨されます。
メリット
| 漏洩リスクの軽減 | 不要なキーファイルの作成を禁止する事で漏洩リスクを大幅に軽減できます。 |
| 代替認証方法の利用促進 | Workload Identity連携等、よりセキュアな認証への移行を推進できます。 |
注意点
| 既存のキーファイルへの影響 | ポリシーの設定前に作成された外部キーファイルは引き続き利用できますが、セキュリティ上の観点から不要なキーファイルを削除する事を推奨します。 |
| 代替認証方式の検討 | キーファイルの作成が禁止される為、外部サービスとの連携等でサービスアカウントを使用する場合は、Workload Identity 連携など代替の認証方式を検討する必要があります。 また非対応の連携先では例外的にキーファイルを作成する必要があります。 |
3. サービス アカウント キー アップロードの無効化
| 表示名 | Disable Service Account Key Upload |
| ID | iam.disableServiceAccountKeyUpload |
概要
外部で作成されたキーファイルをサービスアカウントへアップロードする事を禁止します。前述のキーファイルの作成の無効化と併せて設定することを推奨します。
メリット
| 漏洩リスクの軽減 | キーファイルのアップロードを禁止する事で、脆弱なキーファイルの持ち込みや同一のキーファイルの再利用が禁止されます。これにより、漏洩のリスクを軽減し、キーファイルの作成が必要な場合もより安全なキーファイルの利用を促進できます。 |
注意点
| 既存のキーファイルへの影響 | ポリシーの設定前にアップロードされた外部キーファイルは引き続き利用できますがセキュリティ上の観点から不要なキーファイルを削除する事を推奨します。 |
| 代替認証方式の検討 | キーファイルのアップロードが禁止される為、外部サービスとの連携等でサービスアカウントを使用する場合は、Workload Identity 連携など代替の認証方式を検討する必要があります。 |
4. Audit Loggingの除外を無効にする
| 表示名 | Disable Audit Logging exemption |
| ID | iam.disableAuditLoggingExemption |
概要
監査ログ記録の対象外となるユーザーの追加を禁止する事で監査ログの取得漏れを防止します。
ログの性質上、監査ログは全て保管されている事が望ましい為、特定の信頼されたユーザーの監査ログが大量に出力されておりストレージ容量を削減する為に出力を抑止する必要がある等、特別な理由がない限り除外設定は不要です。
メリット
| 監査ログの完全性 | 不必要な設定による取得漏れを抑止することで、監査ログが必要となった際にログが記録されていなかったという事態を防止できます。 監査ログの適切な取得は、各種法規制や業界標準への準拠において重要な要素となります。 |
注意点
| 既存の除外設定 | ポリシーの設定前に対象外として設定されていたプリンシパルは、そのまま対象外として扱われます。 必要に応じて、個別に設定を見直す必要があります。 |
| ストレージ容量への影響 | 監査ログの取得範囲が広がることで、ストレージ容量の使用量が増加する可能性があります。 適切なログ管理とライフサイクルポリシーの設定が重要となります。 |
5. Google Cloud – リソース ロケーションの制限
| 表示名 | Google Cloud Platform – Resource Location Restriction |
| ID | gcp.resourceLocations |
概要
Google Cloud上でリソースの作成が可なリージョンを制限します。
設定値はアジア内のすべてのロケーションを示すin:asia-locationsや、東京内のすべてのロケーションを示す、in:asia-northeast1-locations、またはasia-northeast1-a等特定のゾーンで指定する事ができます。（参考：ロケーションタイプ）
メリット
| 法規制への対応 | データの保存場所を適切に管理することで、GDPRなどのデータ保存場所に関する規制への準拠に役立ちます。 |
| レイテンシーの最適化 | よりユーザーに近いロケーションにリソースを配置することで、サービスの応答速度を向上させ、ユーザーエクスペリエンスを向上できます。 |
| コスト最適化 | リソースの使用状況を特定のリージョンに制限することで、リージョンによる価格差等による不要なコストの発生を抑えることができます。 |
注意点
| サービスの利用制限 | 一部の Google Cloudサービスは、特定のロケーションでのみ利用可能です。制約を設定する際は、予め必要なサービスが利用可能なロケーションを確認する必要があります。 |
6. 公開アクセスの防止を適用する
| 表示名 | Enforce Public Access Prevention |
| ID | storage.publicAccessPrevention |
概要
Cloud Storage上のデータが一般に公開されないようにします。このポリシーを有効にすると、既存のバケットとオブジェクトに対する公開アクセスが取り消されるため、設定の際には十分な注意が必要です。
メリット
| 設定ミスによる情報漏洩の防止 | Cloud Storageの設定不備等、意図しない公開アクセスによるデータ漏洩のリスクを最小限に抑えることができます。 |
注意点
| 既存の公開設定への影響 | ポリシーを有効化すると、設定済みの公開設定が削除されます。意図的にファイルを公開しているプロジェクトでは本設定の対象外とする、または代替手段（署名付き URL等 ）を検討する必要があります。 |
参考：Cloud Storage の組織ポリシーに関する制約、適用した場合の動作
7. VMインスタンスに対して許可されている外部IPを定義する
| 表示名 | Define allowed external IPs for VM instances |
| ID | compute.vmExternalIpAccess |
概要
このポリシーを設定することで、許可されていない仮想マシンへ外部IPアドレスを割り当てる事を制限し、不正アクセスや攻撃のリスクを軽減する事ができます。
メリット
| 外部からのアクセスの防止 | ファイアウォールの設定ミス等によるサーバへの不要なアクセスを排除する事ができます。 |
| コスト削減 | 不要な外部IPの割り当てを防ぎます。また未使用の静的IPを保持していた等、意図しない費用の発生を防止できます。 |
注意点
| 外部公開が必要なサービス | 外部IPを持たない為、別途、ロードバランサー等が必要となります。外部IPの割り当てが必須の場合は専用の公開用のプロジェクトを作成するなどの対応が必要です。 |
| 代替アクセス方法の検討 | サーバへのログインはクラウドコンソール、またはCloud IAP（Identity-Aware Proxy）や Cloud VPN などの代替アクセス方法を検討する必要があります。 単純なリモートログイン用途であればIAPデスクトップを用いる等すれば利便性を損なわず、セキュアにアクセスする事が可能です。 |
参考：IAP Desktop
8. Cloud SQLインスタンスに対するパブリックIPのアクセスを制限する
| 表示名 | Restrict Public IP access on Cloud SQL instances |
| ID | sql.restrictPublicIp |
概要
Cloud SQLインスタンスへ パブリックIPを付与する事を禁止し、インターネットからDBへの直接アクセスを無効化します。
メリット
| 外部からのアクセスの防止 | ファイアウォールの設定ミス等によるサーバへの不要なアクセスを制限する事ができます。 |
注意点
| 外部からのアクセスが必要な場合への影響 | 外部からのCloud SQLインスタンスへの接続が必要な場合は、VPNやCloud IAPなどの代替手段を検討する必要があります。 また、BigQueryとの連携等、一部のケースでパブリックIPが必須の場合もあります。 |
9. デフォルトのサービス アカウントに対するIAMロールの自動付与の無効化
| 表示名 | Disable Automatic IAM Grants for Default Service Accounts |
| ID | iam.automaticIamGrantsForDefaultServiceAccounts |
概要
このポリシーを設定すると、デフォルトのApp Engineサービス アカウントとCompute Engineサービス アカウントを作成する際に自動的に付与される編集者権限の割り当てを無効化します。
メリット
| 権限の最適化 | デフォルトのサービスアカウントの権限は過剰であり、用途に応じた最小限の権限を持つサービスアカウントを個別に作成して使用する事が推奨されます。 また、サービスアカウントへの権限付与を明示的に行う必要がある為、不要な権限の付与を防ぎ、より厳密な管理が可能となります。 |
注意点
| 外部ツールへの影響 | デフォルトのサービスアカウントを無効化または削除を行うと、デフォルトのサービスアカウントを指定するTerraform等、一部のツールやサービスが機能しなくなる事もあります。 そのため、アカウントとしては権限がない状態としておく必要があります。 |
10. OSログインが必須
| 表示名 | Require OS Login |
| ID | compute.requireOsLogin |
概要
新たに作成されたVMインスタンスでOSログイン機能が自動的に有効になります。
OSログイン機能を利用しない場合、ユーザーの操作環境により一貫性のないユーザー名が混在してしまう事がありますが機能を有効化するとGoogleアカウントでの認証となり2段階認証とも併用できる為、セキュリティレベルの向上が見込めます。
メリット
| Googleアカウントによるサーバログイン | SSH鍵の管理が不要となりますのでキーファイルの漏洩によるリスクが軽減できます。また、2段階認証との併用や強制が容易に可能となります。 |
| 監査時の作業効率化 | Googleアカウントでの認証となる為、作業証跡を追跡する際にユーザーの特定が容易となります。 |
注意点
| サポートOS | OS Loginは主にLinux向けの機能となり、Windowsでは非対応となります。 |
| 組織外部との連携 | 協力会社等、組織外のGoogleアカウントからログインする必要がある場合は別途、組織レベルのIAMで「Compute OS ログインの外部ユーザー」の許可設定が必要となります。 |
参考： 組織外のユーザーにインスタンスへのアクセスを許可する
プリセットで適用済みの制約
これから初めて組織ポリシーを設定するユーザーは、初めから設定されているポリシーもあるので、そちらも合わせて確認しておきましょう。適用済みのポリシーは、いずれも組織リソース作成の際に生じる脆弱性を回避する上で役立つため、安心して運用を開始できます。
初めから適用される主な制約としては、
- constraints/iam.disableServiceAccountKeyCreation：アカウント認証情報の漏えいリスク低減
- constraints/iam.disableServiceAccountKeyUpload：アカウント認証情報の漏えいリスク低減
- constraints/compute.restrictProtocolForwardingCreationForTypes：外部トラフィックからターゲットインスタンスを保護
といったものです。適用済み制約を踏まえた、組織ポリシーの編集を心がけると良いでしょう。
まとめ
本記事では、Google Cloudのセキュリティを強化するための重要な組織ポリシーをご紹介しました。これらのポリシーを適切に設定・運用することで、セキュリティリスクを大幅に軽減し、組織の情報資産を保護することができます。
特に、今回ご紹介した10個のポリシーは、組織のセキュリティ体制を強化する上で特に効果的なものです。外部からのアクセス制限、サービスアカウントの管理、データの保存場所の制御など、様々な側面からセキュリティ対策を講じることができます。
しかし組織ポリシーは、その強力さゆえにその設定には注意が必要です。ポリシーの適用前に、既存の環境や運用への影響を十分に評価し、段階的な導入を検討することが重要です。また、組織のセキュリティ要件に合わせて適切なポリシーを選択し、定期的な見直しを行うことで、常に最新のセキュリティ対策を維持することができます。
本記事が、GCPのセキュリティ強化に取り組む皆様にとって、少しでもお役に立てれば幸いです。組織ポリシーを活用して、安全かつ効率的なクラウド環境を構築しましょう。
この記事をシェア
