許容可能なリソース構成を適用し、リスクの高い構成を防ぐポリシー制約を定義することをおすすめします。このブループリントでは、組織のポリシーの制約と Infrastructure as Code（IaC）の検証を組み合わせてパイプラインで使用します。これらの制御によって、ポリシー ガイドラインを満たしていないリソースの作成を防ぐことができます。ワークロードの設計と構築の早い段階でこれらの制御を適用することで、後で修復作業が発生する状況を回避できます。
組織のポリシーの制約
組織のポリシーサービスにより、十分な権限が付与された IAM ロールを持つユーザーであっても Google Cloud 組織内で特定のリソース構成を作成できないように制約を適用します。
このブループリントでは組織ノードにポリシーを適用し、組織内のすべてのフォルダとプロジェクトにこれらの制御が継承されるようにします。この一連のポリシーは、意図的にポリシーの例外を許可しない限り、公共のインターネットへの VM の公開やストレージ バケットへの公開アクセスの付与など、特定のリスクの高い構成を防ぐように設計されています。
次の表に、ブループリントに実装されている組織のポリシーの制約を示します。
| 組織のポリシーの制約 | 説明 |
|---|---|
| Compute Engine VM 上のネストされた仮想化が正しく構成されていないと、VM のモニタリング ツールやその他のセキュリティ ツールを回避されてしまう可能性があります。この制約により、ネストされた仮想化が作成されないようにします。 |
|
|
| 外部 IPv6 サブネットが正しく構成されていないと、不正なインターネット アクセスにさらされる可能性があります。この制約により、外部 IPv6 サブネットの作成が防止されます。 |
| メタデータ内で SSH 認証鍵を設定するデフォルトの動作では、鍵が漏洩することで VM への不正なリモート アクセスが許可されてしまう可能性があります。この制約により、メタデータ ベースの SSH 認証鍵ではなく、OS Login の使用が強制されます。 |
|
外部 IP アドレスの VM プロトコル転送では、転送が正しく構成されていないと、不正なインターネット下り（外向き）トラフィックが発生する可能性があります。この制約により、内部アドレスに対してのみ VM プロトコル転送が許可されます。 |
|
共有 VPC ホスト プロジェクトを削除すると、ネットワーキング リソースを使用するすべてのサービス プロジェクトが中断される可能性があります。この制約により、共有 VPC ホスト プロジェクトのプロジェクト リーエンの削除を防ぐことで、これらのプロジェクトの偶発的または悪意のある削除を防げます。 |
|
グローバル（プロジェクト全体）の内部 DNS の以前の設定は、サービスの可用性が低下するため推奨されません。この制約により、以前の設定を使用できなくなります。 |
| Compute Engine API を有効にしたすべての新しいプロジェクトでは、デフォルトの VPC ネットワークと制限の緩すぎるデフォルトの VPC ファイアウォール ルールが作成されます。この制約により、デフォルトのネットワークとデフォルトの VPC ファイアウォール ルールの作成がスキップされます。 |
| デフォルトでは、VM は外部 IPv4 アドレスを使用して作成されますが、これは不正なインターネット アクセスにつながる可能性があります。この制約により、VM が使用できる外部 IP アドレスの空の許可リストが構成され、他の IP アドレスはすべて拒否されます。 |
|
デフォルトでは、ドメインに関する通知を他の任意のドメインに送信するために重要な連絡先を構成できます。この制約により、承認されたドメイン内のメールアドレスのみを重要な連絡先の受信者として設定できるようになります。 |
| デフォルトでは、許可ポリシーは管理対象外のアカウントや外部組織に属するアカウントを含む、任意の Google アカウントに付与できます。この制約により、組織内の許可ポリシーはお客様のドメインの管理対象アカウントにのみ付与できるようになります。必要に応じて、追加のドメインを許可できます。 |
|
デフォルトでは、デフォルトのサービス アカウントには制限の緩すぎるロールが自動的に付与されます。この制約により、デフォルトのサービス アカウントに IAM ロールが自動的に付与されなくなります。 |
|
サービス アカウント キーはリスクの高い永続的な認証情報であり、ほとんどの場合はサービス アカウント キーよりも安全な代替手段を使用できます。この制約により、サービス アカウント キーを作成できなくなります。 |
|
サービス アカウントの鍵マテリアルをアップロードすると、鍵マテリアルが漏洩した場合にリスクが高まる可能性があります。この制約により、サービス アカウント キーをアップロードできなくなります。 |
|
Cloud SQL Auth Proxy を使用せずに承認済みネットワークを使用するようにインスタンスが構成されている場合、Cloud SQL インスタンスは未認証のインターネット アクセスにさらされる可能性があります。このポリシーにより、データベース アクセス用の承認済みネットワークの構成が禁止され、代わりに Cloud SQL Auth Proxy の使用が強制されます。 |
| Cloud SQL インスタンスがパブリック IP アドレスを使用して作成されている場合、そのインスタンスは未認証のインターネット アクセスにさらされる可能性があります。この制約により、Cloud SQL インスタンスでパブリック IP アドレスを使用できなくなります。 |
| デフォルトでは、Cloud Storage 内のオブジェクトには IAM ではなく以前のアクセス制御リスト（ACL）を使用してアクセスできます。そのため、構成が正しくないと、アクセス制御が一貫していなかったり、誤って公開されたりする可能性があります。以前の ACL アクセスは |
|
Cloud Storage バケットは、正しく構成されていないと、未認証のインターネット アクセスにさらされる可能性があります。この制約により、 |
これらのポリシーは、ほとんどのお客様とほとんどのシナリオに推奨される出発点ですが、特定のワークロード タイプに対応するために組織のポリシーの制約を変更しなくてはならない場合もあります。たとえば、Cloud CDN のバックエンドとして Cloud Storage バケットを使用して公開リソースをホストするワークロードは storage.publicAccessPrevention によってブロックされます。また、認証を必要としない一般向けの Cloud Run アプリは iam.allowedPolicyMemberDomains によってブロックされます。このような場合は、フォルダレベルまたはプロジェクト レベルで組織のポリシーを変更して、限定的な例外を許可します。また、ポリシーの例外または適用を許可するタグを定義し、そのタグをプロジェクトとフォルダに適用することで、組織のポリシーに条件付きで制約を追加することもできます。
その他の制約について詳しくは、使用可能な制約とカスタム制約をご覧ください。
Infrastructure as Code のデプロイ前の検証
このブループリントは、GitOps アプローチを使用してインフラストラクチャを管理します。つまり、インフラストラクチャの変更はすべて、バージョン管理された Infrastructure as Code（IaC）で実装されており、デプロイ前に検証できます。
パイプラインでデプロイできる許容可能なリソース構成は、ブループリントに適用されているポリシーによって定義されます。GitHub リポジトリに送信されたコードがポリシー チェックに合格していないと、リソースはデプロイされません。
パイプラインの使用方法と、CI / CD 自動化による制御の適用方法については、デプロイ方法をご覧ください。
次のステップ
- デプロイ方法（このシリーズの次のドキュメント）を読む