このコンテンツの最終更新日は 2023 年 12 月で、作成時点の状況を表しています。お客様の保護の継続的な改善のために、Google のセキュリティ ポリシーとシステムは変更される場合があります。
このドキュメントでは、Google Cloud に基本的なリソース一式をデプロイするためのベスト プラクティスについて説明します。クラウドの基盤とは、企業がビジネスニーズに合わせて Google Cloud を導入するためのリソース、構成、機能のベースラインのことです。適切に設計された基盤により、Google Cloud 環境内のすべてのワークロードで、共有サービスに対する一貫したガバナンス、セキュリティ管理、スケール、可視性、アクセスが可能になります。このドキュメントで説明するコントロールとガバナンスをデプロイしたら、Google Cloud にワークロードをデプロイできます。
エンタープライズ基盤ブループリント（旧セキュリティ基盤ブループリント）は、Google Cloud 上でエンタープライズ向けの環境設計を担当するアーキテクト、セキュリティ担当者、プラットフォーム エンジニアリング チームを対象としています。このブループリントは次の内容で構成されています。
- デプロイ可能な Terraform アセットを含む terraform-example-foundation GitHub リポジトリ。
- ブループリント（このドキュメント）で実装するアーキテクチャ、設計、コントロールを説明するガイド。
このガイドは、次の 2 つの用途に使用できます。
- Google のベスト プラクティスに基づく完全な基盤を構築する。このガイドのすべての推奨事項を出発点としてデプロイし、ビジネス固有の要件に合わせて環境をカスタマイズできます。
- Google Cloud の既存の環境を確認する。Google が推奨するベスト プラクティスに照らして設計の特定のコンポーネントを比較できます。
サポートされるユースケース
エンタープライズ基盤ブループリントは、Google Cloud であらゆるタイプのワークロードを可能にするリソースと構成のベースライン レイヤを実現します。既存のコンピューティング ワークロードを Google Cloud に移行する場合、コンテナ化されたウェブ アプリケーションの構築する場合、ビッグデータと ML ワークロードを作成する場合のいずれにおいても、エンタープライズ基盤ブループリントを使用することで、エンタープライズ ワークロードを大規模にサポートする環境を構築できます。
エンタープライズ基盤ブループリントをデプロイすると、ワークロードを直接デプロイするか、追加のブループリントをデプロイすることで、追加機能を必要とする複雑なワークロードをサポートできます。
多層防御セキュリティ モデル
Google Cloud サービスは、基盤となる Google インフラストラクチャのセキュリティ設計から恩恵を受けています。Google Cloud 上に構築するシステムへのセキュリティを設計するのはお客様の責任です。エンタープライズ基盤ブループリントは、Google Cloud サービスとワークロードに多層防御のセキュリティ モデルを実装するうえで役立ちます。
次の図では、アーキテクチャ制御、ポリシー制御、検出制御を組み合わせた Google Cloud 組織の多層防御セキュリティ モデルを示します。
この図には、次のコントロールが示されています。
- ポリシー制御は、許容可能なリソース構成を適用し、危険な構成を防ぐプログラム上の制約です。このブループリントでは、パイプラインの Infrastructure as Code（IaC）検証などのポリシー制御と組織のポリシー制約を組み合わせて使用します。
- アーキテクチャ制御は、ネットワークやリソース階層などの Google Cloud リソースの構成です。このブループリントのアーキテクチャは、セキュリティのベスト プラクティスに基づいています。
- 検出制御では、組織内の異常な動作や悪意のある動作を検出できます。このブループリントは、Security Command Center などのプラットフォーム機能を使用し、既存の検出制御やセキュリティ オペレーション センター（SOC）などのワークフローと統合して、カスタム検出制御を実施する機能を実現します。
主要な判断項目
このセクションでは、ブループリントのアーキテクチャに関する判断項目について概要を説明します。
この図は、Google Cloud サービスが主要なアーキテクチャ上の判断にどのように影響を与えているかを示しています。
- Cloud Build: インフラストラクチャのリソースは GitOps モデルを使用して管理されます。宣言型 IaC は Terraform で記述され、レビューと承認のためにバージョン管理システムで管理されます。リソースは、継続的インテグレーション / 継続的デプロイ（CI / CD）の自動化ツールである Cloud Build を使用してデプロイされます。パイプラインは Policy as Code チェックも実施して、リソースが期待する構成を満たしていることをデプロイ前に検証します。
- Cloud Identity: ユーザーとグループ メンバーシップは、既存の ID プロバイダから同期されます。ユーザー アカウントのライフサイクル管理とシングル サインオン（SSO）の制御は、ID プロバイダの既存の制御とプロセスに依存します。
- Identity and Access Management（IAM）: 許可ポリシー（旧 IAM ポリシー）はリソースへのアクセス権を許可するものであり、職務に基づいてグループに適用されます。ユーザーは適切なグループに追加され、基盤リソースに対する閲覧権限が付与されます。基盤リソースに対する変更は,、すべて特権サービス アカウント ID を使用する CI / CD パイプラインを介してデプロイされます。
- Resource Manager: すべてのリソースは、プロジェクトが環境別に整理されているフォルダのリソース階層を使用して 1 つの組織で管理されます。プロジェクトには、費用の帰属などの管理を行うためにメタデータでラベル付けされます。
- ネットワーキング: ネットワーク トポロジでは共有 VPC が使用されており、別々の環境に存在して複数のリージョンやゾーンにまたがっているワークロードにネットワーク リソースを提供し、一元管理します。オンプレミス ホスト、VPC ネットワーク内の Google Cloud リソース、Google Cloud サービスの間のネットワーク パスはすべてプライベートです。デフォルトでは、公共のインターネットとの間のインバウンド トラフィックやアウトバウンド トラフィックは許可されません。
- Cloud Logging: 集約ログシンクは、セキュリティと監査に関連するログを一元化されたプロジェクトに収集して長期的な保持、分析、外部システムへのエクスポートを実現するように構成されます。
- Cloud Monitoring: Monitoring のスコープ対象プロジェクトは、複数のプロジェクトのアプリケーション パフォーマンス指標を 1 か所で表示するように構成されます。
- 組織のポリシー サービス: 組織のポリシーの制約は、さまざまなリスクの高い構成を防止するように構成されます。
- Secret Manager: コンプライアンス要件を満たすために、機密性の高いアプリケーション シークレットの使用について管理と監査を担当するチーム用に、一元化されたプロジェクトが作成されます。
- Cloud Key Management Service（Cloud KMS）: コンプライアンス要件を満たすために、暗号鍵の管理と監査を担当するチーム用に、一元化されたプロジェクトが作成されます。
- Security Command Center: 脅威の検出とモニタリングの機能は、Security Command Center の組み込みセキュリティ管理と、セキュリティ イベントの検出と対応を可能にするカスタム ソリューションを組み合わせて実現されます。
これらの主要な判断項目に代わる選択肢については、別の方法をご覧ください。
次のステップ
- 認証と認可（このシリーズの次のドキュメント）を読む。
認証と認可
このセクションでは、Cloud Identity を使用して、従業員が Google Cloud サービスにアクセスするために使用する ID を管理する方法について説明します。
信頼できる情報源としての外部 ID プロバイダ
Cloud Identity アカウントを既存の ID プロバイダと連携することをおすすめします。連携により、既存のアカウント管理プロセスを Google Cloud やその他の Google サービスに適用できます。
既存の ID プロバイダがない場合は、Cloud Identity で直接ユーザー アカウントを作成できます。
次の図は、ID 連携とシングル サインオン（SSO）の概要を示しています。ID プロバイダの例として、オンプレミス環境にある Microsoft Active Directory を使用しています。
この図は、次のベスト プラクティスを示しています。
- ユーザー ID は、オンプレミス環境にあり Cloud Identity と連携している Active Directory ドメインで管理されます。Active Directory は、Google Cloud Directory Sync を使用して Cloud Identity に ID をプロビジョニングします。
- Google サービスにログインしようとするユーザーは、SAML によるシングル サインオンのための外部 ID プロバイダにリダイレクトされ、既存の認証情報を使用して認証を受けます。パスワードは Cloud Identity と同期されません。
次の表に、ID プロバイダの設定ガイダンスへのリンクを示します。
| ID プロバイダ | ガイダンス |
|---|---|
| Active Directory | |
| Microsoft Entra ID（旧 Azure AD） | |
| 他の外部 ID プロバイダ（Ping、Okta など） |
Titan セキュリティ キーなどのフィッシング耐性のあるメカニズムを使用して、ご利用の ID プロバイダで多要素認証を適用することを強くおすすめします。
このブループリントの Terraform コードでは Cloud Identity の推奨設定は自動化されていません。Terraform コードのデプロイに加えて構成する必要がある推奨のセキュリティ設定については、Cloud Identity の管理機能をご覧ください。
アクセス制御用のグループ
プリンシパルは、リソースへのアクセス権を付与できる ID です。プリンシパルの例としては、ユーザー用の Google アカウント、Google グループ、Google Workspace アカウント、Cloud Identity ドメイン、サービス アカウントが挙げられます。一部のサービスでは、Google アカウントで認証するすべてのユーザー、またはインターネット上のすべてのユーザーにアクセス権を付与することもできます。プリンシパルが Google Cloud サービスとやり取りするには、Identity and Access Management（IAM）でロールを付与する必要があります。
IAM ロールを大規模に管理するには、職務とアクセス要件に基づいてユーザーをグループに割り当ててから、そのグループに IAM ロールを付与することをおすすめします。既存 ID プロバイダのグループ作成とメンバー管理のためのプロセスを使用して、グループにユーザーを追加する必要があります。
IAM ロールを個々のユーザーに付与することはおすすめしません。個々の割り当てによってロールの管理と監査が複雑になる可能性があるためです。
このブループリントでは、基盤リソースへの閲覧専用アクセス権のグループとロールを構成します。基盤パイプラインを使用してブループリントのすべてのリソースをデプロイすること、およびパイプライン外の基盤リソースを変更するロールをユーザーに付与しないことをおすすめします。
次の表は、基盤リソースを表示するために、ブループリントによって構成されるグループを示したものです。
| 名前 | 説明 | ロール | スコープ |
|---|---|---|---|
grp-gcp-org-admin@example.com |
組織レベルで IAM ロールを付与できる高度な権限を持つ管理者。他のロールにもアクセスできます。この権限は、日常的な使用にはおすすめしません。 | 組織管理者 | 組織 |
grp-gcp-billing-admin@example.com |
Cloud 請求先アカウントを変更できる高度な権限を持つ管理者。この権限は、日常的な使用にはおすすめしません。 | 請求先アカウント管理者 | 組織 |
grp-gcp-billing-viewer@example.com |
すべてのプロジェクトの費用の確認と分析を担当するチーム。 | 請求先アカウント閲覧者 | 組織 |
| BigQuery ユーザー | 課金プロジェクト | ||
grp-gcp-audit-viewer@example.com |
セキュリティ関連のログの監査を担当するチーム。 | ロギング プロジェクト | |
grp-gcp-monitoring-users@example.com |
アプリケーションのパフォーマンス指標のモニタリングを担当するチーム。 | モニタリング閲覧者 | モニタリング プロジェクト |
grp-gcp-security-reviewer@example.com |
クラウド セキュリティの審査を担当するチーム。 | セキュリティ審査担当者 | 組織 |
grp-gcp-network-viewer@example.com |
ネットワーク構成の表示と維持管理を担当するチーム。 | Compute ネットワーク閲覧者 | 組織 |
grp-gcp-scc-admin@example.com |
Security Command Center の構成を担当するチーム。 | セキュリティ センター管理編集者 | 組織 |
grp-gcp-secrets-admin@example.com |
アプリケーションで使用される認証情報とその他のシークレットの管理、保存、監査を担当するチーム。 | Secret Manager 管理者 | シークレット プロジェクト |
grp-gcp-kms-admin@example.com |
コンプライアンス要件を満たすために暗号鍵管理の強制適用を担当するチーム。 | Cloud KMS 閲覧者 | kms プロジェクト |
基盤上に独自のワークロードを構築する場合は、追加のグループを作成し、各ワークロードのアクセス要件に基づいて IAM ロールを付与します。
基本ロール（オーナー、編集者、閲覧者など）ではなく、事前定義ロールを使用することを強くおすすめします。基本ロールは制限が過度に緩いため、セキュリティ リスクが生じるおそれがあります。オーナーと編集者のロールは権限昇格とラテラル ムーブメントを引き起こす可能性があり、閲覧者のロールにはすべてのデータを読み取る権限が含まれます。IAM ロールのベスト プラクティスについては、IAM を安全に使用するをご覧ください。
特権管理者アカウント
特権管理者アカウントを持つ Cloud Identity ユーザーは、組織の SSO 設定を迂回し、Cloud Identity に対して直接認証を行います。この例外は設計上のものであり、SSO の構成ミスや停止が発生した場合でも、特権管理者が Cloud Identity コンソールにアクセスできます。ただし、特権管理者アカウントの保護強化を検討する必要があります。
特権管理者アカウントを保護するため、Cloud Identity のセキュリティ キーで常に 2 段階認証プロセスを適用することをおすすめします。詳しくは、管理者アカウントのセキュリティに関するおすすめの方法をご覧ください。
一般ユーザー向けアカウントの問題
Google Cloud にオンボーディングする前に Cloud Identity または Google Workspace を使用しなかった場合は、組織の従業員がすでに一般ユーザー向けアカウントを使用している可能性があります。このアカウントは、Google マーケティング プラットフォームや YouTube などの他の Google サービスにアクセスするための企業メール ID と関連付けられています。一般ユーザー向けアカウントは、作成者が完全に所有、管理するアカウントです。これらのアカウントは組織の管理対象外であり、個人データと企業データの両方が含まれている可能性があるため、これらのアカウントを他の企業アカウントと統合する方法を決定する必要があります。
Google Cloud へのオンボーディングの一環として、既存の一般ユーザー向けユーザー アカウントを統合することをおすすめします。まだすべてのユーザー アカウントで Google Workspace を使用していない場合は、新しい一般ユーザー向けアカウントの作成をブロックすることをおすすめします。
Cloud Identity の管理機能
Cloud Identity には、ブループリントの Terraform コードでは自動化されないさまざまな管理機能があります。基盤を構築するプロセスの早い段階で、これらのベスト プラクティスの各セキュリティ管理機能を適用することをおすすめします。
| 管理機能 | 説明 |
|---|---|
| 2 段階認証プロセスを導入する | ユーザー アカウントは、フィッシング、ソーシャル エンジニアリング、パスワード スプレー、その他のさまざまな脅威によって侵害されることがあります。2 段階認証プロセスは、これらの脅威を軽減するのに役立ちます。 Titan セキュリティ キーやフィッシング耐性のある FIDO U2F（CTAP1）標準に遵守したその他のキーなどのフィッシング耐性のあるメカニズムを採用して、組織内のすべてのユーザー アカウントに 2 段階認証プロセスを適用することをおすすめします。 |
| Google Cloud サービスのセッション継続時間を設定する | デベロッパーのワークステーション上の永続的な OAuth トークンは、漏洩した場合にセキュリティ リスクとなるおそれがあります。セキュリティ キーを使用した 16 時間ごとの認証を要求する再認証ポリシーを設定することをおすすめします。 |
| Google サービスのセッション継続時間を設定する | （Google Workspace をご利用のお客様のみ） 他の Google サービス間で永続的なウェブ セッションを公開すると、セキュリティ上のリスクが生じることがあります。ウェブ セッションの最大継続時間を適用し、SSO プロバイダのセッション継続時間の設定に合わせることをおすすめします。 |
| Cloud Identity のデータを Google Cloud サービスと共有する | Google Workspace または Cloud Identity の管理アクティビティ監査ログは通常、Google Cloud 環境のログとは別に管理コンソールで管理および表示されます。これらのログには、ユーザーのログイン イベントなど、Google Cloud 環境に関連する情報が含まれています。 すべてのソースからのログを一元管理するために、Cloud Identity 監査ログを Google Cloud 環境と共有することをおすすめします。 |
| SSO 後の検証を設定する | このブループリントでは、外部 ID プロバイダで SSO を設定することを想定しています。 Google のログインリスク分析に基づいて、追加の制御レイヤを有効にすることをおすすめします。この設定を適用すると、あるユーザーのログインが疑わしいと Google が判断した場合に、リスクがあるものとして、ログイン時に追加の本人確認が表示されることがあります。 |
| 一般ユーザー向けアカウントの問題を解消する | ドメインの有効なメールアドレスを持っているものの、Google アカウントを持っていないユーザーは、管理対象外の一般ユーザー向けアカウントを申請できます。これらのアカウントには企業データが含まれている場合がありますが、アカウント ライフサイクル管理プロセスでは管理されません。 すべてのユーザー アカウントが管理対象アカウントであることを確認することをおすすめします。 |
| 特権管理者アカウントの復元を無効にする | 特権管理者アカウントの自己復元は、すべての新規ユーザーに対してデフォルトで無効になっています（既存のユーザーの場合、この設定がオンになっている場合があります）。この設定をオフにすると、スマートフォン、メールの不正使用、ソーシャル エンジニアリング攻撃によって、攻撃者が環境に対する特権管理者権限を取得することになるリスクを軽減できます。 特権管理者がアカウントにアクセスできなくなった場合に組織内の別の特権管理者に連絡できる内部プロセスを計画し、すべての特権管理者がサポートによる復元のプロセスに精通していることを確認します。 |
| ユーザーのパスワード要件を適用、監視する | ほとんどの場合、ユーザー パスワードは外部 ID プロバイダを介して管理されますが、特権管理者アカウントは SSO を迂回するため、Cloud Identity へのログインにはパスワードを使用する必要があります。パスワードを使用して Cloud Identity にログインするユーザー（特に特権管理者アカウント）について、パスワードの再利用を無効にし、パスワードの安全度をモニタリングします。 |
| グループを使用するための組織全体のポリシーを設定する | デフォルトでは、外部ユーザー アカウントを Cloud Identity のグループに追加できます。グループ オーナーが外部メンバーを追加できないように、共有設定を構成することをおすすめします。 この制限は、特権管理者アカウント、またはグループ管理者権限を持つ他の代理管理者には適用されないことに注意してください。ID プロバイダからの連携は管理者権限で実行されるため、グループ共有設定はこのグループ同期には適用されません。ID プロバイダと同期メカニズムの管理機能を確認して、ドメイン以外のメンバーがグループに追加されないようにするか、グループ制限を適用することをおすすめします。 |
次のステップ
- 組織構造に関するドキュメント（このシリーズの次のドキュメント）を読む。
組織構造
Google Cloud でリソースを管理するためのルートノードは組織です。Google Cloud の組織は、リソースの所有構造と、組織のポリシーとアクセス制御の接点を提供するリソース階層を提供します。リソース階層は、フォルダ、プロジェクト、リソースで構成され、組織内の Google Cloud サービスの構造と使用を定義します。
階層の下位にあるリソースは、IAM 許可ポリシーや組織のポリシーなどのポリシーを継承します。すべてのアクセス権は、リソースに許可ポリシーを直接適用するか、リソースがリソース階層の上位レベルから許可ポリシーを継承するまで、デフォルトで拒否されます。
次の図は、ブループリントによってデプロイされるフォルダとプロジェクトを示したものです。
以降のセクションでは、この図に記載されているフォルダとプロジェクトについて説明します。
フォルダ
このブループリントでは、フォルダを使用し、環境に基づいてプロジェクトをグループ化します。この論理グループを使用して、フォルダレベルで許可ポリシーや組織のポリシーなどの構成が適用され、フォルダ内のすべてのリソースがポリシーを継承します。このブループリントに含まれているフォルダは、次の表に示すとおりです。
| フォルダ | 説明 |
|---|---|
bootstrap |
基盤コンポーネントのデプロイに使用するプロジェクトが含まれています。 |
common |
すべての環境で共有されるリソースを持つプロジェクトが含まれています。 |
production |
本番環境リソースが置かれたプロジェクトが含まれています。 |
nonproduction |
本番環境のコピーが含まれており、ワークロードを本番環境にプロモートする前にテストできます。 |
development |
開発に使用するクラウド リソースが含まれています。 |
networking |
すべての環境で共有されるネットワーキング リソースが含まれています。 |
プロジェクト
このブループリントでは、プロジェクトを使用して、個々のリソースがその機能とアクセス制御の目的で設定された境界に基づいてグループ化されます。このブループリントが含まれているプロジェクトを、次の表に示します。
| フォルダ | プロジェクト | 説明 |
|---|---|---|
bootstrap |
prj-b-cicd |
組織の基盤コンポーネントの構築に使用されるデプロイ パイプラインが含まれています。詳細については、デプロイ手法をご覧ください。 |
prj-b-seed |
インフラストラクチャの Terraform の状態と、パイプラインの実行に必要な Terraform サービス アカウントが含まれています。詳細については、デプロイ手法をご覧ください。 | |
common |
prj-c-secrets |
組織レベルのシークレットが含まれています。詳細については、Secret Manager でアプリケーションの認証情報を保存するをご覧ください。 |
prj-c-logging |
監査ログの集約されたログソースが含まれています。詳細については、セキュリティと監査のための一元的なロギングをご覧ください。 | |
prj-c-scc |
Security Command Center のアラートやその他のカスタム セキュリティ モニタリングの構成に役立つリソースが含まれています。詳細については、Security Command Center を使用した脅威のモニタリングをご覧ください。 | |
prj-c-billing-logs |
組織の課金データのエクスポートを含む BigQuery データセットが含まれます。詳細については、内部コストセンター間で費用を割り当てるをご覧ください。 | |
prj-c-infra-pipeline |
ワークロードで使用されるリソース（VM やデータベースなど）をデプロイするためのインフラストラクチャ パイプラインが含まれています。詳細については、パイプライン レイヤをご覧ください。 | |
prj-c-kms |
組織レベルの暗号鍵が含まれています。詳細については、暗号鍵を管理するをご覧ください。 | |
networking |
prj-net-{env}-shared-base |
VPC Service Controls を必要としないワークロード用の、共有 VPC ネットワークのホスト プロジェクトが含まれています。詳細については、ネットワーク トポロジをご覧ください。 |
prj-net-{env}-shared-restricted |
VPC Service Controls を必要とするワークロード用の、共有 VPC ネットワークのホスト プロジェクトが含まれています。詳細については、ネットワーク トポロジをご覧ください。 | |
prj-net-interconnect |
オンプレミス環境と Google Cloud 間の接続を提供する Cloud Interconnect 接続が含まれています。詳細については、ハイブリッド接続をご覧ください。 | |
prj-net-dns-hub |
オンプレミス DNS システムと Cloud DNS 間における通信の中間点用のリソースが含まれています。詳細については、一元化された DNS の設定をご覧ください。 | |
環境フォルダ（production,
non-production、development） |
prj-{env}-monitoring |
その環境にあるプロジェクトの指標を集計するスコープ対象プロジェクトが含まれています。詳細については、ログベースの指標とパフォーマンス指標に関するアラートをご覧ください。 |
prj-{env}-secrets |
フォルダレベルのシークレットが含まれています。詳細については、Secret Manager でアプリケーションの認証情報を保存および監査するをご覧ください。 | |
prj-{env}-kms |
フォルダレベルの暗号鍵が含まれています。詳細については、暗号鍵を管理するをご覧ください。 | |
| アプリケーション プロジェクト | アプリケーションのリソースを作成するさまざまなプロジェクトが含まれています。詳細については、プロジェクトのデプロイ パターンとパイプライン レイヤをご覧ください。 |
リソース所有権のガバナンス
ガバナンスと費用の割り当てを容易にするために、プロジェクトには一貫したラベルを付けることをおすすめします。次の表に、ブループリントのガバナンスのために各プロジェクトに追加されるプロジェクト ラベルを示します。
| ラベル | 説明 |
|---|---|
application |
プロジェクトに関連付けられているアプリケーションまたはワークロードの、人が読める形式の名前。 |
businesscode |
プロジェクトを所有するビジネス ユニットを示す短いコード。コード shared は、ビジネス ユニットに明示的に関連付けられていない共通のプロジェクトに使用されます。 |
billingcode |
チャージバックの情報を提供するために使用されるコード。 |
primarycontact |
プロジェクトを担当する主担当者のユーザー名。プロジェクト ラベルにはアンパサンド（@）などの特殊文字を含めることができないため、後半の @example.com を除いたユーザー名が設定されます。 |
secondarycontact |
プロジェクトを担当する副担当者のユーザー名。プロジェクト ラベルには @ などの特殊文字を含めることができないため、後半の @example.com を除いたユーザー名のみを設定します。 |
environment |
環境のタイプを識別する値（bootstrap、common、production、non-production,development、network. など）。 |
envcode |
環境のタイプを識別する値（短縮形: b、c、p、n、d、net）。 |
vpc |
このプロジェクトでの使用が予定される VPC ネットワークの ID。 |
Google は、アカウントの停止やプロダクト利用規約の更新などの重要な通知を送信することがあります。このブループリントでは、重要な連絡先を使用して、デプロイ時に構成したグループにこうした通知が送信されます。重要な連絡先は組織ノードで構成され、組織内のすべてのプロジェクトに継承されます。これらのグループを確認して、メールが確実にモニタリングされるようにすることをおすすめします。
重要な連絡先は、プロジェクト ラベルで構成される primarycontact フィールドおよび secondarycontact フィールドとは異なる目的で使用されます。プロジェクト ラベルの連絡先は、内部のガバナンスを目的としています。たとえば、ワークロード プロジェクトでコンプライアンス違反のリソースを特定してオーナーに連絡する必要がある場合は、primarycontact フィールドを使用してそのワークロードの担当者または担当チームを見つけることができます。
次のステップ
- ネットワーキング（このシリーズの次のドキュメント）を読む。
ネットワーキング
ネットワーキングは、リソースが Google Cloud 組織内で、およびクラウド環境とオンプレミス環境の間で通信するために不可欠です。このセクションでは、VPC ネットワーク、IP アドレス空間、DNS、ファイアウォール ポリシー、オンプレミス環境への接続に関するブループリントの構造について説明します。
ネットワーク トポロジ
ブループリント リポジトリには、ネットワーク トポロジ向けに次のオプションが用意されています。
- 環境ごとに個別の共有 VPC ネットワークを使用し、複数の環境間での直接のネットワーク トラフィックを許可しない。
- ハブ ネットワークを追加して Google Cloud の各環境を接続するハブ アンド スポーク モデルを使用し、複数の環境間でのネットワーク トラフィックをネットワーク仮想アプライアンス（NVA）で制御する。
複数の環境間でネットワークを直接接続しない場合は、デュアル共有 VPC ネットワーク トポロジを選択します。環境内のすべてのサーバーへのダイレクト ネットワーク パスを必要とする既存のツールを使用する場合など、NVA によってフィルタされる環境間のネットワーク接続を許可するには、ハブ アンド スポーク ネットワーク トポロジを選択します。
共有 VPC では責任を明確に分離できるため、どちらのトポロジでも共有 VPC を主要なネットワーク構成として使用します。ネットワーク管理者は、一元管理されたホスト プロジェクトでネットワーク リソースを管理します。ワークロード チームは、独自のアプリケーション リソースをデプロイして、ホスト プロジェクトに接続されたサービス プロジェクトでネットワーク リソースを消費します。
どちらのトポロジにも、各 VPC ネットワークのベース バージョンと制限付きバージョンが含まれています。ベース VPC ネットワークはセンシティブ データを含まないリソースに使用し、制限付き VPC ネットワークは VPC Service Controls を必要とするセンシティブ データを含むリソースに使用します。VPC Service Controls を実装する方法について詳しくは、VPC Service Controls でリソースを保護するをご覧ください。
デュアル共有 VPC ネットワーク トポロジ
Google Cloud 上の開発環境、非本番環境、本番環境のネットワークを隔離する必要がある場合は、デュアル共有 VPC ネットワーク トポロジをおすすめします。このトポロジでは、環境ごとに個別の共有 VPC ネットワークを使用します。各環境はさらにベース共有 VPC ネットワークと制限付き共有 VPC ネットワークに分割されます。
次の図は、デュアル共有 VPC ネットワーク トポロジを示しています。
この図は、デュアル共有 VPC トポロジの次の重要なコンセプトを表しています。
- 各環境（本番環境、非本番環境、開発環境）には、ベース ネットワーク用および制限付きネットワーク用にそれぞれ 1 つずつの共有 VPC ネットワークがあります。この図には本番環境のみが示されていますが、環境ごとに同じパターンが繰り返されます。
- 各共有 VPC ネットワークには 2 つのサブネットがあり、各サブネットは異なるリージョンにあります。
- オンプレミス リソースとの接続は、各共有 VPC ネットワークの Dedicated Interconnect インスタンスに対応する 4 つの VLAN アタッチメント経由で有効になりますが、これには 4 つの Cloud Router サービス（冗長性を確保するために各リージョンに 2 つ）が使用されます。詳細については、オンプレミス環境と Google Cloud 間のハイブリッド接続をご覧ください。
設計上、このトポロジではネットワーク トラフィックが複数の環境間で直接流れることはありません。ネットワーク トラフィックが複数の環境間で直接流れるようにする必要がある場合は、そのネットワーク パスを許可するために追加の手順を実施する必要があります。たとえば、ある VPC ネットワークから別の VPC ネットワークにサービスを公開する Private Service Connect エンドポイントを構成できます。あるいは、ある Google Cloud 環境からオンプレミス環境にトラフィックが流れ、その後で別の Google Cloud 環境に流れるようにオンプレミス ネットワークを構成することもできます。
ハブ アンド スポーク ネットワーク トポロジ
複数の環境のリソースへのダイレクト ネットワーク パスを必要とするリソースを Google Cloud にデプロイする場合は、ハブ アンド スポーク ネットワーク トポロジをおすすめします。
ハブ アンド スポーク トポロジではデュアル共有 VPC トポロジに含まれるいくつかのコンセプトを使用しますが、ハブ ネットワークを追加するためにトポロジを変更します。次の図は、ハブ アンド スポーク トポロジを示しています。
この図は、ハブ アンド スポーク ネットワーク トポロジの次の重要なコンセプトを表しています。
- このモデルはハブ ネットワークを追加し、開発環境、非本番環境、本番環境の各ネットワーク（スポーク）は VPC ネットワーク ピアリングを介してハブ ネットワークに接続されます。また、割り当て上限の超過が予想される場合は、代わりに HA VPN ゲートウェイを使用できます。
- オンプレミス ネットワークへの接続は、ハブ ネットワーク経由でのみ許可されます。すべてのスポーク ネットワークはハブ ネットワーク内の共有リソースと通信でき、このパスを使用してオンプレミス ネットワークに接続できます。
- ハブ ネットワークには、内部ネットワーク ロードバランサ インスタンスの背後に冗長構成でデプロイされた各リージョンの NVA が含まれています。この NVA は、スポーク ネットワーク間のトラフィックの通信を許可または拒否するゲートウェイとして機能します。
- ハブ ネットワークは、他のすべてのネットワークへの接続を必要とするツールもホストします。たとえば、一般的な環境の構成管理用のツールを VM インスタンスにデプロイできます。
- ハブ アンド スポーク モデルは、各ネットワークのベース バージョンと制限付きバージョンで複製されます。
スポーク間のトラフィックを有効にするため、ブループリントはネットワーク間のゲートウェイとして機能するハブ共有 VPC ネットワークに NVA をデプロイします。ルートは、カスタムルート交換によってハブからスポーク VPC ネットワークへ交換されます。このシナリオでは VPC ネットワーク ピアリングは推移的ではなく、スポーク VPC ネットワークは相互に直接データを交換できないため、スポーク間の接続は NVA を介してルーティングする必要があります。スポーク間のトラフィックを選択的に許可するよう、仮想アプライアンスを構成する必要があります。
NVA を使用してスポーク間のトラフィックを制御する方法について詳しくは、Google Cloud 上の一元管理されたネットワーク アプライアンスをご覧ください。
プロジェクトのデプロイ パターン
ワークロードの新しいプロジェクトを作成するときは、このプロジェクトのリソースを既存のネットワークに接続する方法を決定する必要があります。次の表では、ブループリントで使用されるプロジェクトをデプロイするパターンについて説明します。
| パターン | 説明 | 使用例 |
|---|---|---|
| 共有のベース プロジェクト | これらのプロジェクトは、ベース共有 VPC ホスト プロジェクトに対するサービス プロジェクトとして構成されます。 プロジェクト内のリソースに次の条件がある場合は、このパターンを使用します。
|
example_base_shared_vpc_project.tf |
| 共有の制限付きプロジェクト | これらのプロジェクトは、制限付き共有 VPC ホスト プロジェクトに対するサービス プロジェクトとして構成されます。 プロジェクト内のリソースに次の条件がある場合は、このパターンを使用します。
|
example_restricted_shared_vpc_project.tf |
| フローティング プロジェクト | フローティング プロジェクトは、トポロジ内の他の VPC ネットワークには接続されていません。 プロジェクト内のリソースに次の条件がある場合は、このパターンを使用します。
フローティング プロジェクトの VPC ネットワークをメインの VPC ネットワーク トポロジと切り離したまま、ネットワーク間に限られた数のエンドポイントを公開するといったシナリオが考えられます。その場合は、Private Service Connect を使用してサービスを公開し、ネットワーク全体を公開することなく、VPC ネットワーク間で個々のエンドポイントへのネットワーク アクセスを共有します。 |
example_floating_project.tf |
| ピアリング プロジェクト | ピアリング プロジェクトは独自の VPC ネットワークを作成し、トポロジ内の他の VPC ネットワークにピアリングします。 プロジェクト内のリソースに次の条件がある場合は、このパターンを使用します。
ピアリング プロジェクトを作成する場合は、競合しない IP アドレス範囲を割り振り、ピアリング グループの割り当てを計画する必要があります。 |
example_peering_project.tf |
IP アドレスの割り振り
このセクションでは、ブループリント アーキテクチャで IP アドレスの範囲を割り振る方法について説明します。既存のハイブリッド環境で使用できる IP アドレスに基づいて、使用する特定の IP アドレス範囲の変更が必要になる場合があります。
次の表は、ブループリントに割り振られる IP アドレス空間の内訳を示しています。ハブ環境は、ハブ アンド スポーク トポロジにのみ適用されます。
| 用途 | VPC タイプ | リージョン | ハブ環境 | 開発環境 | 非本番環境 | 本番環境 |
|---|---|---|---|---|---|---|
| プライマリ サブネット範囲 | ベース | リージョン 1 | 10.0.0.0/18 | 10.0.64.0/18 | 10.0.128.0/18 | 10.0.192.0/18 |
| リージョン 2 | 10.1.0.0/18 | 10.1.64.0/18 | 10.1.128.0/18 | 10.1.192.0/18 | ||
| 未割り当て | 10.{2-7}.0.0/18 | 10.{2-7}.64.0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
| 制限付き | リージョン 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 | |
| リージョン 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | ||
| 未割り当て | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | ||
| プライベート サービス アクセス | ベース | グローバル | 10.16.0.0/21 | 10.16.8.0/21 | 10.16.16.0/21 | 10.16.24.0/21 |
| 制限付き | グローバル | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 | |
| Private Service Connect エンドポイント | ベース | グローバル | 10.17.0.1/32 | 10.17.0.2/32 | 10.17.0.3/32 | 10.17.0.4/32 |
| 制限付き | グローバル | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 | |
| プロキシ専用サブネット | ベース | リージョン 1 | 10.18.0.0/23 | 10.18.2.0/23 | 10.18.4.0/23 | 10.18.6.0/23 |
| リージョン 2 | 10.19.0.0/23 | 10.19.2.0/23 | 10.19.4.0/23 | 10.19.6.0/23 | ||
| 未割り当て | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
| 制限付き | リージョン 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 | |
| リージョン 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | ||
| 未割り当て | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | ||
| セカンダリ サブネット範囲 | ベース | リージョン 1 | 100.64.0.0/18 | 100.64.64.0/18 | 100.64.128.0/18 | 100.64.192.0/18 |
| リージョン 2 | 100.65.0.0/18 | 100.65.64.0/18 | 100.65.128.0/18 | 100.65.192.0/18 | ||
| 未割り当て | 100.{66-71}.0.0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
| 制限付き | リージョン 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 | |
| リージョン 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | ||
| 未割り当て | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
上記の表は、IP アドレス範囲の割り振りに関する次のコンセプトを表しています。
- IP アドレスの割り振りは、ベース共有 VPC、制限付き共有 VPC、リージョン、環境の組み合わせごとに範囲が細分化されています。
- 一部のリソースはグローバルであり、リージョンごとの細分化を必要としません。
- デフォルトでは、リージョン リソースの場合、ブループリントは 2 つのリージョンにデプロイされます。さらに、未使用の IP アドレス範囲があるため、6 つのリージョンに拡張できます。
- ハブ ネットワークはハブ アンド スポーク ネットワーク トポロジでのみ使用されますが、開発環境、非本番環境、本番環境は両方のネットワーク トポロジで使用されます。
次の表は、各タイプの IP アドレス範囲がどのように使用されるかを示しています。
| 用途 | 説明 |
|---|---|
| プライマリ サブネット範囲 | VPC ネットワークにデプロイするリソース（仮想マシン インスタンスなど）は、これらの範囲の内部 IP アドレスを使用します。 |
| プライベート サービス アクセス | Cloud SQL などの一部の Google Cloud サービスでは、プライベート サービス アクセス用のサブネット範囲を事前に割り振る必要があります。ブループリントは共有 VPC ネットワークごとに /21 範囲をグローバルに予約し、プライベート サービス アクセスを必要とするサービスに IP アドレスを割り振ります。プライベート サービス アクセスを使用するサービスを作成する場合は、予約された /21 範囲から /24 リージョン サブネットを割り振ります。 |
| Private Service Connect | このブループリントは VPC ネットワークごとに Private Service Connect エンドポイントをプロビジョニングして、Google Cloud APIs と通信します。このエンドポイントを使用すると、VPC ネットワーク内のリソースはインターネットへのアウトバウンド トラフィックや一般公開されているインターネット範囲に依存することなく、Google Cloud APIs にアクセスできるようになります。 |
| プロキシベースのロードバランサ | 一部のタイプのアプリケーション ロードバランサでは、プロキシ専用サブネットを事前に割り振る必要があります。ブループリントでは、この範囲を必要とするアプリケーション ロードバランサはデプロイされませんが、範囲を事前に割り振ることで、特定のロードバランサ リソースを有効にするため新しいサブネット範囲をリクエストする必要がある場合に、ワークロードに対する負担を軽減できます。 |
| セカンダリ サブネット範囲 | コンテナベースのワークロードなどの一部のユースケースでは、セカンダリ範囲が必要です。このブループリントは、RFC 6598 IP アドレス空間からの範囲をセカンダリ範囲に割り振ります。 |
一元管理の DNS 設定
Google Cloud とオンプレミス環境間の DNS 解決には、2 つの権威 DNS システムを使用するハイブリッド アプローチをおすすめします。このアプローチでは、Cloud DNS が Google Cloud 環境の権威 DNS 解決を処理し、既存のオンプレミス DNS サーバーがオンプレミス リソースの権威 DNS 解決を処理します。オンプレミス環境と Google Cloud 環境では、リクエストの転送を通じて環境間の DNS ルックアップが行われます。
次の図は、このブループリントで使用される複数の VPC ネットワークにまたがる DNS トポロジを示しています。
この図は、ブループリントによってデプロイされる DNS 設計の次のコンポーネントを表しています。
- 共通フォルダ内の DNS ハブ プロジェクトは、オンプレミス環境と Google Cloud 環境間の DNS 交換の中心となります。DNS 転送には、ネットワーク トポロジですでに構成されているものと同じ Dedicated Interconnect インスタンスと Cloud Router を使用します。
- デュアル共有 VPC トポロジの場合、DNS ハブは本番環境のベース共有 VPC ネットワークを使用します。
- ハブ アンド スポーク トポロジの場合、DNS ハブはハブのベース共有 VPC ネットワークを使用します。
- 各共有 VPC ネットワーク内のサーバーは、各共有 VPC ホスト プロジェクトの Cloud DNS と DNS ハブの間で構成された DNS 転送を通じて他の共有 VPC ネットワークからの DNS レコードを解決できます。
- オンプレミス サーバーは、オンプレミス サーバーからのクエリを許可する DNS サーバー ポリシーを使用して Google Cloud 環境の DNS レコードを解決できます。このブループリントは、DNS ハブ内の受信サーバー ポリシーを構成して IP アドレスを割り振り、オンプレミス DNS サーバーはこれらのアドレスにリクエストを転送します。Google Cloud へのすべての DNS リクエストは、まず DNS ハブに到達し、次に DNS ピアからのレコードが解決されます。
- Google Cloud のサーバーは、オンプレミス サーバーにクエリを送信する転送ゾーンを使用して、オンプレミス環境の DNS レコードを解決できます。オンプレミス環境へのすべての DNS リクエストは、DNS ハブから送信されます。DNS リクエストの送信元は 35.199.192.0/19 です。
ファイアウォール ポリシー
Google Cloud には、複数のタイプのファイアウォール ポリシーがあります。階層型ファイアウォール ポリシーは組織レベルまたはフォルダレベルで適用され、階層内のすべてのリソースにわたってファイアウォール ポリシールールを一貫して継承します。また、VPC ネットワークごとにネットワーク ファイアウォール ポリシーを構成できます。このブループリントは、これらのファイアウォール ポリシーを組み合わせて、階層型ファイアウォール ポリシーを使用してすべての環境に共通の設定を適用し、ネットワーク ファイアウォール ポリシーを使用して個々の VPC ネットワークごとにより具体的な設定を適用します。
このブループリントは、以前の VPC ファイアウォール ルールを使用しません。ファイアウォール ポリシーのみを使用し、以前の VPC ファイアウォール ルールと併用しないことをおすすめします。
階層型ファイアウォール ポリシー
このブループリントは、単一の階層型ファイアウォール ポリシーを定義し、そのポリシーを本番環境、非本番環境、開発環境、ブートストラップ、共通の各フォルダにアタッチします。この階層型ファイアウォール ポリシーにはすべての環境に幅広く適用する必要があるルールが含まれており、きめ細かいルールの評価は個々の環境のネットワーク ファイアウォール ポリシーに委任されます。
次の表は、ブループリントによってデプロイされる階層型ファイアウォール ポリシールールを示しています。
| ルールの説明 | トラフィックの方向 | フィルタ（IPv4 範囲） | プロトコルとポート | アクション |
|---|---|---|---|---|
| RFC 1918 からのインバウンド トラフィックの評価を階層の下位レベルに委任します。 | Ingress |
192.168.0.0/16、10.0.0.0/8、172.16.0.0/12 |
all |
Go to next |
| RFC 1918 へのアウトバウンド トラフィックの評価を階層の下位レベルに委任します。 | Egress |
192.168.0.0/16、10.0.0.0/8、172.16.0.0/12 |
all |
Go to next |
| TCP 転送用の IAP | Ingress |
35.235.240.0/20 |
tcp:22,3390 |
Allow |
| Windows Server の有効化 | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| Cloud Load Balancing のヘルスチェック | Ingress |
130.211.0.0/22、35.191.0.0/16、209.85.152.0/22、209.85.204.0/22 |
tcp:80,443 |
Allow |
ネットワーク ファイアウォール ポリシー
このブループリントは、ネットワークごとにネットワーク ファイアウォール ポリシーを構成します。各ネットワーク ファイアウォール ポリシーには、Google Cloud サービスへのアクセスを許可し、他のすべての IP アドレスへの下り（外向き）トラフィックを拒否する最低限のルールセットがあります。
ハブ アンド スポーク モデルでは、ネットワーク ファイアウォール ポリシーにスポーク間の通信を許可する追加のルールが含まれています。ネットワーク ファイアウォール ポリシーは、あるスポークからハブまたは別のスポークへのアウトバウンド トラフィックを許可し、ハブ ネットワーク内の NVA からのインバウンド トラフィックを許可します。
次の表は、ブループリントの各 VPC ネットワークにデプロイされるグローバル ネットワーク ファイアウォール ポリシーのルールを示しています。
| ルールの説明 | トラフィックの方向 | フィルタ | プロトコルとポート |
|---|---|---|---|
| Google Cloud APIs へのアウトバウンド トラフィックを許可します。 | Egress |
個々のネットワークごとに構成される Private Service Connect エンドポイント。Google Cloud APIs へのプライベート アクセスをご覧ください。 | tcp:443 |
| 他のルールと一致しないアウトバウンド トラフィックを拒否します。 | Egress |
すべて | all |
あるスポークから別のスポークへのアウトバウンド トラフィックを許可します（ハブ アンド スポーク モデルのみ）。 |
Egress |
ハブ アンド スポーク トポロジで使用するすべての IP アドレスの合計。スポーク VPC から送信されるトラフィックは、まずハブ ネットワーク内の NVA にルーティングされます。 | all |
ハブ ネットワーク内の NVA からスポークへのインバウンド トラフィックを許可します（ハブ アンド スポーク モデルのみ）。 |
Ingress |
ハブ ネットワーク内の NVA から送信されるトラフィック。 | all |
このブループリントを初めてデプロイするときは、VPC ネットワーク内の VM インスタンスは Google Cloud サービスと通信できますが、同じ VPC ネットワーク内の他のインフラストラクチャ リソースとは通信できません。VM インスタンスの通信を許可するには、ネットワーク ファイアウォール ポリシーとタグに、VM インスタンスの通信を明示的に許可するルールを追加する必要があります。タグは VM インスタンスに追加され、それらのタグに対してトラフィックが評価されます。タグには IAM コントロールが備わっているため、タグを一元的に定義して、その使用を他のチームに委任することもできます。
次の図は、カスタムタグとネットワーク ファイアウォール ポリシールールを追加して、ワークロードが VPC ネットワーク内で通信できるようにする方法の例を示しています。
この図は、この例の次のコンセプトを表しています。
- ネットワーク ファイアウォール ポリシーには、すべての送信元からのアウトバウンド トラフィックを優先値 65530 で拒否する Rule 1 が含まれています。
- ネットワーク ファイアウォール ポリシーには、
service=frontendタグを持つインスタンスからservice=backendタグを持つインスタンスへのインバウンド トラフィックを優先値 999 で許可する Rule 2 が含まれています。 - トラフィックが Rule 2 で許可されているタグと一致するため、instance-2 VM は instance-1 からのトラフィックを受信できます。優先値に基づいて、Rule 1 が評価される前に Rule 2 と照合されるからです。
- instance-3 VM はトラフィックを受信できません。そのトラフィックと一致するファイアウォール ポリシールールは Rule 1 のみであるため、instance-1 からのアウトバウンド トラフィックは拒否されます。
Google Cloud APIs へのプライベート アクセス
VPC ネットワークまたはオンプレミス環境のリソースが Google Cloud サービスにアクセスできるようにするには、パブリック API エンドポイントへのアウトバウンド インターネット トラフィックではなく、プライベート接続をおすすめします。このブループリントは、すべてのサブネットで限定公開の Google アクセスを構成し、Private Service Connect を使用して内部エンドポイントを作成し、Google Cloud サービスと通信します。これらのコントロールを組み合わせることで、インターネットのアウトバウンド トラフィックや一般公開されたインターネット範囲を使用することなく、Google Cloud サービスへのプライベート パスを許可できます。
このブループリントは、どのネットワークでどのサービスにアクセスできるかを区別するために、API バンドルを使用して Private Service Connect エンドポイントを構成します。ベース ネットワークは all-apis バンドルを使用して、すべての Google サービスにアクセスできます。制限付きネットワークは vpcsc バンドルを使用して、VPC Service Controls をサポートする限定されたサービスのセットにアクセスできます。
オンプレミス環境内のホストからアクセスする場合は、次の表に示すようにエンドポイントごとにカスタム FQDN の規則を使用することをおすすめします。このブループリントは、異なる API バンドルのセットにアクセスするように構成された VPC ネットワークごとに一意の Private Service Connect エンドポイントを使用します。したがって、正しい API エンドポイントを使用してオンプレミス環境から VPC ネットワークにサービス トラフィックをルーティングする方法を検討する必要があります。また、VPC Service Controls を使用している場合は、Google Cloud サービスへのトラフィックが目的の境界内のエンドポイントに到達できるようにする必要があります。これらのエンドポイントへのアクセスを許可するよう DNS、ファイアウォール、ルーターのオンプレミスの制御を構成し、適切なエンドポイントを使用するようオンプレミス ホストを構成します。詳細については、エンドポイントから Google API にアクセスするをご覧ください。
次の表は、ネットワークごとに作成される Private Service Connect エンドポイントを示しています。
| VPC | 環境 | API バンドル | Private Service Connect エンドポイントの IP アドレス | カスタム FQDN | ||||
|---|---|---|---|---|---|---|---|---|
| ベース | 共通 | all-apis |
10.17.0.1/32 | c.private.googleapis.com |
||||
| 開発 | all-apis |
10.17.0.2/32 | d.private.googleapis.com |
|||||
| 非本番 | all-apis |
10.17.0.3/32 | n.private.googleapis.com |
|||||
| 本番 | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
| 制限付き | 共通 | vpcsc |
10.17.0.5/32 | c.restricted.googleapis.com |
||||
| 開発 | vpcsc |
10.17.0.6/32 | d.restricted.googleapis.com |
|||||
| 非本番 | vpcsc |
10.17.0.7/32 | n.restricted.googleapis.com |
|||||
| 本番 | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
|||||
Google Cloud サービスのトラフィックで正しいエンドポイントへの DNS ルックアップが行われるようにするため、このブループリントは VPC ネットワークごとにプライベート DNS ゾーンを構成します。次の表は、これらのプライベート DNS ゾーンを示しています。
| プライベート ゾーン名 | DNS 名 | レコードタイプ | データ |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
private.googleapis.com.（ベース ネットワークの場合）または restricted.googleapis.com.（制限付きネットワークの場合） |
private.googleapis.com（ベース ネットワークの場合）または restricted.googleapis.com（制限付きネットワークの場合） |
A |
該当する VPC ネットワークの Private Service Connect エンドポイントの IP アドレス。 | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
該当する VPC ネットワークの Private Service Connect エンドポイントの IP アドレス。 | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
該当する VPC ネットワークの Private Service Connect エンドポイントの IP アドレス。 |
このブループリントには、これらの Private Service Connect エンドポイントが一貫して使用されるようにする追加の構成があります。各共有 VPC ネットワークでは、次のルールも適用されます。
- すべてのソースから TCP:443 上の Private Service Connect エンドポイントの IP アドレスへのアウトバウンド トラフィックを許可するネットワーク ファイアウォール ポリシールール。
- 0.0.0.0/0 へのアウトバウンド トラフィックを拒否するネットワーク ファイアウォール ポリシールール。これには、Google Cloud サービスへのアクセスに使用されるデフォルト ドメインが含まれます。
インターネット接続
このブループリントでは、VPC ネットワークとインターネット間のインバウンドまたはアウトバウンドのトラフィックは許可されません。インターネット接続が必要なワークロードの場合は、必要なアクセスパスを設計するために追加の手順を踏む必要があります。
インターネットへのアウトバウンド トラフィックを必要とするワークロードの場合は、Cloud NAT 経由でアウトバウンド トラフィックを管理して未承諾のインバウンド接続なしでアウトバウンド トラフィックを許可することをおすすめします。または、より細やかな制御のため Secure Web Proxy 経由で信頼できるウェブサービスへのアウトバウンド トラフィックのみを許可することをおすすめします。
インターネットからのインバウンド トラフィックを必要とするワークロードの場合は、DDoS 対策と WAF 対策を活用できるように、Cloud Load Balancing と Google Cloud Armor を使用してワークロードを設計することをおすすめします。
VM 上の外部 IP アドレスを使用して、インターネットと VM 間の直接接続を許可するワークロードを設計することはおすすめしません。
オンプレミス環境と Google Cloud 間のハイブリッド接続
オンプレミス環境と Google Cloud 間の接続を確立するため、Dedicated Interconnect を使用してセキュリティと信頼性を最大化することをおすすめします。Dedicated Interconnect 接続は、オンプレミス ネットワークと Google Cloud 間の直接リンクです。
次の図は、オンプレミス環境と Google Virtual Private Cloud ネットワーク間のハイブリッド接続を示しています。
この図は、Dedicated Interconnect で 99.99% の可用性を実現するパターンを構成する次のコンポーネントを表しています。
- ある大都市圏（メトロ）に 2 つ、別の大都市圏に 2 つの接続で構成された 4 つの Dedicated Interconnect 接続。
- 接続は 2 つのペアに分割され、各ペアは別々のオンプレミス データセンターに接続されます。
- VLAN アタッチメントは、共有 VPC トポロジにアタッチされている Cloud Router に各 Dedicated Interconnect インスタンスを接続するために使用されます。これらの VLAN アタッチメントは、
prj-c-interconnectプロジェクトでホストされています。 - 各共有 VPC ネットワークには 4 つの Cloud Router（リージョンごとに 2 つ）があり、動的ルーティング モードは
globalに設定されています。これにより、すべての Cloud Router はリージョンに関係なくすべてのサブネットを通知できます。
グローバル動的ルーティングを使用すると、Cloud Router は VPC ネットワーク内のすべてのサブネットへのルートをアドバタイズします。Cloud Router は、ローカル サブネット（Cloud Router のリージョン内にあるサブネット）と比較して優先度が低いリモート サブネット（Cloud Router のリージョン外のサブネット）にルートをアドバタイズします。必要に応じて、Cloud Router の BGP セッションを構成するときに、アドバタイズされたプレフィックスと優先度を変更できます。
Google Cloud からオンプレミス環境へのトラフィックは、クラウド リソースに最も近い Cloud Router を使用します。単一リージョン内では、オンプレミス ネットワークへの複数のルートに同じ Multi-Exit Discriminator（MED）値があり、Google Cloud は等価コスト マルチパス（ECMP）ルーティングを使用して、考えられるすべてのルート間でアウトバウンド トラフィックを分散します。
オンプレミス構成の変更
オンプレミス環境と Google Cloud 間の接続を構成するには、オンプレミス環境で追加の変更を構成する必要があります。このブループリントの Terraform コードにより Google Cloud リソースが自動的に構成されますが、オンプレミス ネットワーク リソースは変更されません。
オンプレミス環境から Google Cloud へのハイブリッド接続のコンポーネントの一部は、ブループリントによって自動的に有効になります。これには次のようなものがあります。
- Cloud DNS は、DNS 設定で説明されているように、すべての共有 VPC ネットワーク間で 1 つのハブに DNS 転送されるように構成されます。Cloud DNS サーバー ポリシーは、インバウンド フォワーダーの IP アドレスを使用して構成されます。
- Cloud Router は、すべてのサブネットのルートと、Private Service Connect エンドポイントで使用される IP アドレスのカスタムルートをエクスポートするように構成されています。
ハイブリッド接続を有効にするには、次の追加手順を行う必要があります。
- Dedicated Interconnect 接続を注文します。
- IP アドレス空間の割り振りで定義された内部 IP アドレス空間へのアウトバウンド トラフィックを許可するよう、オンプレミス ルーターとファイアウォールを構成します。
- ブループリントによってすでに構成されたインバウンド フォワーダーの IP アドレスに Google Cloud にバインドされた DNS ルックアップを転送するよう、オンプレミス DNS サーバーを構成します。
- Cloud DNS 転送ゾーン（35.199.192.0/19）からの DNS クエリを受け入れるよう、オンプレミスの DNS サーバー、ファイアウォール、ルーターを構成します。
- Cloud APIs へのプライベート アクセスで定義された IP アドレスを使用してオンプレミス ホストから Google Cloud サービスへのクエリに応答するよう、オンプレミス DNS サーバーを構成します。
- Dedicated Interconnect 接続を介した転送データの暗号化では、Cloud Interconnect の MACsec を構成するか、IPsec 暗号化用に Cloud Interconnect を介した HA VPN を構成します。
詳細については、オンプレミス ホストの限定公開の Google アクセスを構成するをご覧ください。
次のステップ
- 検出制御（このシリーズの次のドキュメント）を確認する。
検出制御
脅威の検出とモニタリングの機能は、Security Command Center の組み込みのセキュリティ管理と、セキュリティ イベントの検出と対応を可能にするカスタム ソリューションを組み合わせて実現されます。
セキュリティと監査のための一元的なロギング
このブループリントでは、1 つのプロジェクトに集約されたログを使用して、Google Cloud リソースに対する変更を追跡し分析するロギング機能が構成されます。
次の図に、ブループリントが複数のプロジェクトにある複数のソースから一元化されたログシンクにログを集約する仕組みを示します。
この図では以下のことが示されています。
- ログシンクは組織ノードに構成され、リソース階層におけるすべてのプロジェクトのログを集約します。
- フィルタに一致するログを別の保存先に送信して分析できるように、複数のログシンクが構成されています。
prj-c-loggingプロジェクトには、ログの保存と分析のためのすべてのリソースが含まれています。- 必要に応じて、ログを SIEM にエクスポートするための追加ツールを構成できます。
このブループリントでは、さまざまなログソースを使用し、それらのログをログシンク フィルタで指定することで、ログを一元化した宛先にエクスポートできるようにしています。各ログソースの説明は次の表に示すとおりです。
ログソース |
説明 |
|---|---|
管理アクティビティ監査ログを構成、無効化、除外することはできません。 |
|
システム イベント監査ログを構成、無効化、除外することはできません。 |
|
ポリシー拒否監査ログを構成、無効化することはできませんが、除外フィルタを使用して必要に応じて除外できます。 |
|
データアクセス ログの量と費用が大きくなる可能性があるため、デフォルトでは、ブループリントでデータアクセス ログは有効化されていません。 データアクセス ログを有効にする必要があるかどうかを判断するには、ワークロードで機密データを扱う場所を評価し、センシティブ データを使用するそれぞれのサービスと環境にデータアクセス ログを有効にする要件があるかどうかを検討します。 |
|
このブループリントでは、すべてのサブネットで VPC フローログを有効にします。また、費用を削減するために、ログの 50% をサンプリングするようにログのサンプリングを構成します。 追加のサブネットを作成する場合は、サブネットごとに VPC フローログを有効にする必要があります。 |
|
このブループリントでは、すべてのファイアウォール ポリシー ルールでファイアウォール ルールのロギングを有効にします。 ワークロード用に追加のファイアウォール ポリシー ルールを作成する場合は、新しいルールごとにファイアウォール ルールのロギングを有効にする必要があります。 |
|
このブループリントでは、マネージド ゾーンの Cloud DNS ログを有効にします。 追加のマネージド ゾーンを作成する場合は、それらの DNS ログを有効にする必要があります。 |
|
このブループリントでは自動化されない 1 回限りの有効化ステップを行う必要があります。詳細については、Google Cloud サービスとデータを共有するをご覧ください。 |
|
このブループリントでは自動化されない 1 回限りの有効化ステップを行う必要があります。詳細については、アクセスの透明性を有効にするをご覧ください。 |
次の表に、ログシンクと、ブループリントのサポートされる宛先でのログシンクの使用方法を示します。
シンク |
宛先 |
目的 |
|---|---|---|
|
ログは Cloud Logging バケットに転送される（ログ分析とリンクされた BigQuery データセットを有効にする） |
ログを積極的に分析する。コンソールのログ エクスプローラを使用してアドホック調査を実行することや、リンク済み BigQuery データセットを使用して SQL クエリ、レポート、ビューを作成することが可能です。 |
|
コンプライアンス、監査、インシデント追跡を目的としてログを長期保存する。 必要に応じて、データ保持を義務付けるコンプライアンス要件がある場合は、バケットロックを別途構成することをおすすめします。 |
|
|
ログを外部プラットフォーム（既存の SIEM など）にエクスポートする。 このためには、次のような仕組みなど、SIEM と統合するための追加の作業が必要です。
|
追加のログタイプの有効化とログシンク フィルタの作成に関するガイダンスについては、ログスコープ ツールをご覧ください。
Security Command Center による脅威のモニタリング
組織を対象に Security Command Center Premium を有効にして、Google Cloud リソースの脅威、脆弱性、構成ミスを自動的に検出することをおすすめします。Security Command Center は、次のような複数のソースからセキュリティに関する検出結果を作成します。
- Security Health Analytics: Google Cloud リソース全体で一般的な脆弱性と構成ミスを検出します。
- 攻撃パスの発生可能性: Security Command Center の他のソースによって検出された脆弱性や構成ミスに基づいて、攻撃者がどのように高価値リソースを悪用するかをシミュレートしたパスを示します。
- Event Threat Detection: 検出ロジックと独自の脅威インテリジェンスをログに適用し、ほぼリアルタイムで脅威を特定します。
- Container Threat Detection: 一般的なコンテナ ランタイム攻撃を検出します。
- Virtual Machine Threat Detection: 仮想マシンで実行中の悪意を持っている可能性があるアプリケーションを検出します。
- Web Security Scanner: Compute Engine、App Engine、Google Kubernetes Engine 上のウェブ公開アプリケーションで OWASP トップ 10 の脆弱性をスキャンします。
Security Command Center が対処する脆弱性と脅威の詳細については、Security Command Center のソースをご覧ください。
Security Command Center は、ブループリントをデプロイした後に有効にする必要があります。手順については、組織で Security Command Center を有効にするをご覧ください。
Security Command Center を有効にした後は、脅威の優先順位づけや対応を行うために、Security Command Center によって生成された検出結果を既存のツールやプロセスにエクスポートすることをおすすめします。ブループリントでは、このインテグレーションに使用する Pub/Sub トピックを含む prj-c-scc プロジェクトを作成します。検出結果は、既存のツールに応じて、次のいずれかの方法でエクスポートします。
- コンソールを使用して Security Command Center でセキュリティの検出結果を直接管理する場合は、Security Command Center 用にフォルダレベルとプロジェクト レベルのロールを構成して、チームが担当するプロジェクトのセキュリティの検出結果のみを表示および管理できるようにします。
Chronicle を SIEM として使用する場合は、Chronicle に Google Cloud データを取り込みます。
SIEM や SOAR ツールを Security Command Center と統合して使用する場合は、Cortex XSOAR、Elastic Stack、ServiceNow、Splunk、または QRadar とデータを共有します。
Pub/Sub から検出結果を取り込める外部ツールを使用する場合は、Pub/Sub への継続的エクスポートを構成し、Pub/Sub トピックから検出結果を取り込むように既存のツールを構成します。
ログベースの指標とパフォーマンス指標に関するアラート
基盤上でワークロードのデプロイを開始したら、Cloud Monitoring を使用してパフォーマンス指標を測定することをおすすめします。
このブループリントでは、環境ごとに prj-p-monitoring などのモニタリング プロジェクトが作成されます。このプロジェクトは、複数のプロジェクトにわたって集約されたパフォーマンス指標を収集するスコーピング プロジェクトとして構成されます。このブループリントでは、ログベースの指標と、Cloud Storage バケットに適用される IAM ポリシーに変更があった場合にメール通知を生成するアラート ポリシーを備えた例がデプロイされます。これにより、Terraform の状態を含む prj-b-seed プロジェクトのバケットなど、機密性の高いリソースに対する不審なアクティビティをモニタリングできます。
より一般的には、Cloud Monitoring を使用してワークロード アプリケーションのパフォーマンス指標と健全性を測定することもできます。組織内のアプリケーションのサポートとモニタリングの運用責任に応じて、チームごとに、より詳細なモニタリング プロジェクトを作成できます。こうしたモニタリング プロジェクトを使用してパフォーマンス指標を表示し、アプリケーションの状態を示すダッシュボードを作成して、期待される SLO が満たされていない場合にアラートをトリガーします。
次の図に、Cloud Monitoring がパフォーマンス指標を集計する仕組みの概要を示します。
ワークロードの信頼性と可用性を効果的にモニタリングする方法については、サイト信頼性エンジニアリングの書籍（特に Google による分散システムのモニタリングに関する章）をご覧ください。
自動ログ分析のカスタム ソリューション
たとえば、ログに対するカスタムクエリに基づいて、セキュリティ イベントのアラートを作成するという要件があるとします。このような場合、カスタムクエリを使用することで、Google Cloud 上のログを分析し、調査に値するイベントのみをエクスポートすることで、SIEM の機能を補うことができます（特に、すべてのクラウドログを SIEM にエクスポートする容量がない場合）。
このブループリントは、リンクされた BigQuery データセットを使用してクエリできるログの一元化されたソースを設定することで、このようなログ分析を可能にします。この機能を自動化するには、bq-log-alerting のコードサンプルを実装して基盤の機能を拡張する必要があります。このサンプルコードを使用すると、ログソースを定期的にクエリして、カスタムの検出結果を Security Command Center に送信できます。
次の図に自動ログ分析のフローの概略を示します。
この図では、自動ログ分析の以下のコンセプトが示されています。
- さまざまなソースから生成されたログは、ログ分析およびリンクされた BigQuery データセットを使用して、一元化されたログバケットに集約されます。
- BigQuery ビューは、モニタリングするセキュリティ イベントのログをクエリするように構成されます。
- Cloud Scheduler は、15 分ごとにイベントを Pub/Sub トピックに push し、Cloud Functions をトリガーします。
- Cloud Functions は、ビューの新しいイベントのクエリを実行します。イベントを見つけると、カスタム検出結果として Security Command Center に push します。
- Security Command Center は、新しい検出結果に関する通知を別の Pub/Sub トピックにパブリッシュします。
- SIEM などの外部ツールは、Pub/Sub トピックをサブスクライブして新しい検出結果を取り込みます。
サンプルには、疑わしいと思われる動作をクエリするためのユースケースが複数あります。たとえば、指定した特権管理者や他の高い権限を持つアカウントのリストからのログイン、ロギング設定の変更、ネットワーク ルートの変更などです。ユースケースは、要件に合わせて新しいクエリビューを作成することで拡張できます。独自のクエリを作成するか、Google Cloud ログの分析に役立つ SQL クエリのライブラリのセキュリティ ログ分析を参照してください。
アセットの変更に対応するカスタム ソリューション
リアルタイムでイベントに応答するには、Cloud Asset Inventory を使用してアセットの変更をモニタリングすることをおすすめします。このカスタム ソリューションでは、リソースの変更に関する Pub/Sub への通知をリアルタイムでトリガーするようにアセット フィードが構成されます。その後、Cloud Functions によってカスタムコードが実行され、変更を許可すべきかどうか基づいてユーザー独自のビジネス ロジックが適用されます。
ブループリントには、このカスタム ガバナンス ソリューションの例が含まれており、組織管理者、オーナー、編集者など、機密性の高いロールを追加する IAM の変更をモニタリングします。このソリューションを図で表すと、次のようになります。
上記の図では、以下のコンセプトが示されています。
- 許可ポリシーが変更されます。
- Cloud Asset Inventory フィードが、許可ポリシーの変更に関するリアルタイムの通知を Pub/Sub に送信します。
- Pub/Sub が関数をトリガーします。
- Cloud Functions が、カスタムコードを実行してポリシーを適用します。サンプル関数には、変更によって組織管理者、オーナー、編集者のロールが許可ポリシーに追加されたかどうかを評価するロジックがあります。変更によって追加された場合、関数はカスタム セキュリティの検出結果を作成し、Security Command Center に送信します。
- 必要に応じて、このモデルを使用して修復作業を自動化できます。Cloud Functions で追加のビジネス ロジックを作成すると、許可ポリシーを以前の状態に戻すことなど、検出結果に応じて自動的にアクションが実行されます。
さらに、このサンプル ソリューションで使用されているインフラストラクチャとロジックを拡張して、ビジネスにとって重要な他のイベントに対するカスタム レスポンスを追加することもできます。
次のステップ
- 予防制御（このシリーズの次のドキュメント）を確認する。
許容可能なリソース構成に関する予防制御
許容可能なリソース構成を適用し、リスクの高い構成を防ぐポリシー制約を定義することをおすすめします。このブループリントでは、組織のポリシーの制約と 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 自動化による制御の適用方法については、デプロイ方法をご覧ください。
次のステップ
- デプロイ方法（このシリーズの次のドキュメント）を読む
デプロイ方法
基盤のデプロイは、宣言型インフラストラクチャを使用して、一貫性のある制御可能な方法で行うことをおすすめします。このアプローチでは、許容可能なリソース構成に関するポリシー制御をパイプラインに適用することで、一貫したガバナンスを実現できます。このブループリントは GitOps フローを使用してデプロイされます。このとき、Terraform によって Infrastructure as Code（IaC）が定義され、バージョン管理とコードの承認のために Git リポジトリが使用され、デプロイ パイプラインの CI / CD 自動化には Cloud Build が使用されます。このコンセプトの概要については、Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するをご覧ください。
以降のセクションでは、デプロイ パイプラインを使用して組織内のリソースを管理する方法について説明します。
パイプライン レイヤ
環境内のさまざまなレイヤを管理するチームと技術スタックを分離するには、スタックの各レイヤを受け持つさまざまなパイプライン、およびさまざまなペルソナを使用するモデルをおすすめします。
次の図は、基盤パイプライン、インフラストラクチャ パイプライン、アプリケーション パイプラインを分離するための推奨モデルを示しています。
この図は、このモデルの各パイプライン レイヤを示しています。
- 基盤パイプラインは、プラットフォーム全体で使用される基盤リソースをデプロイします。複数のビジネス ユニットとワークロードによって使用される基盤リソースを、1 つの中央チームで管理することをおすすめします。
- インフラストラクチャ パイプラインは、VM インスタンスやデータベースなど、ワークロードで使用されるプロジェクトとインフラストラクチャをデプロイします。このブループリントでは、ビジネス ユニットごとに個別のインフラストラクチャ パイプラインが設定されますが、複数のチームで 1 つのインフラストラクチャ パイプラインを使用することもできます。
- アプリケーション パイプラインは、コンテナやイメージなど、各ワークロードのアーティファクトをデプロイします。複数のアプリケーション チームが、それぞれ個別のアプリケーション パイプラインを持つこともできます。
以降のセクションでは、各パイプライン レイヤの使用方法について説明します。
基盤パイプライン
基盤パイプラインは基盤リソースをデプロイします。また、ワークロードが使用するインフラストラクチャをデプロイするための、インフラストラクチャ パイプラインも構成します。
基盤パイプラインを作成するには、まず terraform-example-foundation を独自の Git リポジトリにクローニングまたはフォークします。0-bootstrap README ファイルの手順に沿って、ブートストラップ フォルダとリソースを構成します。
| ステージ | 説明 |
|---|---|
Google Cloud 組織をブートストラップします。このステップでは、後続ステージのブループリント コード用の CI / CD パイプラインも構成します。
|
0-bootstrap ステージで基盤パイプラインを作成すると、以下のステージで、基盤パイプライン上にリソースがデプロイされます。各ステージの README の手順を確認し、各ステージを順番に実装してください。
| ステージ | 説明 |
|---|---|
組織のポリシーを使用して、最上位の共有フォルダ、共有サービスのプロジェクト、組織レベルのロギング、ベースライン セキュリティを設定します。 |
|
作成した Google Cloud 組織内で開発環境、非本番環境、本番環境を設定します。 |
|
または |
選択したトポロジでの共有 VPC と、関連するネットワーク リソースを設定します。 |
インフラストラクチャ パイプライン
インフラストラクチャ パイプラインは、ワークロードで使用されるプロジェクトとインフラストラクチャ（VM インスタンスやデータベースなど）をデプロイします。基盤パイプラインにより、複数のインフラストラクチャ パイプラインがデプロイされます。基盤パイプラインとインフラストラクチャ パイプラインをこのように分離することで、プラットフォーム全体のリソースと、ワークロード固有のリソースとを分離できます。
次の図は、個別のチームが使用する複数のインフラストラクチャ パイプラインを、ブループリントで構成する方法を示したものです。
この図は、以下の主要なコンセプトを示しています。
- 各インフラストラクチャ パイプラインは、基盤リソースとは別にインフラストラクチャ リソースを管理するために使用されます。
- 各ビジネス ユニットには独自のインフラストラクチャ パイプラインがあり、
commonフォルダ内の専用プロジェクトでそれぞれ管理されます。 - 各インフラストラクチャ パイプラインには、そのビジネス ユニットに関連付けられたプロジェクトにのみリソースをデプロイできる権限を持つサービス アカウントがあります。この戦略では、基盤パイプラインに使用される特権サービス アカウントと、各インフラストラクチャ パイプラインで使用される特権サービス アカウントとの間に、職掌分散を確立できます。
複数のインフラストラクチャ パイプラインを使用するこのアプローチは、インフラストラクチャを個別に管理するスキルと意欲を持つ、複数の事業体が組織内に存在する場合におすすめします。特に、実施したいパイプライン検証ポリシーの種類などの要件が異なる場合には最適です。また、単一のチームが一貫した検証ポリシーを使用して、単一のインフラストラクチャ パイプラインを管理することもできます。
terraform-example-foundation では、ステージ 4 でインフラストラクチャ パイプラインを構成し、ステージ 5 では、そのパイプラインを使用してインフラストラクチャ リソースをデプロイする例を示します。
| ステージ | 説明 |
|---|---|
フォルダ構造、プロジェクト、インフラストラクチャ パイプラインを設定します。 |
|
|
インフラストラクチャ パイプラインを例として使用し、Compute Engine インスタンスでワークロード プロジェクトをデプロイします。 |
アプリケーション パイプライン
アプリケーション パイプラインは、アプリケーションのビジネス ロジックを実行するイメージや Kubernetes コンテナなど、個々のワークロード用のアプリケーション アーティファクトをデプロイする役割を担います。これらのアーティファクトは、インフラストラクチャ パイプラインによってデプロイされたインフラストラクチャ リソース上にデプロイされます。
エンタープライズ基盤のブループリントは、基盤パイプラインとインフラストラクチャ パイプラインを構成しますが、アプリケーション パイプラインはデプロイしません。アプリケーション パイプラインの例については、エンタープライズ アプリケーションのブループリントをご覧ください。
Cloud Build を使用したパイプラインの自動化
このブループリントは、Cloud Build を使用して CI / CD プロセスを自動化します。次の表は、terraform-example-foundation リポジトリによってデプロイされる基盤パイプラインとインフラストラクチャ パイプラインに組み込まれる管理機能を示したものです。他の CI / CD 自動化ツールを使用して独自のパイプラインを開発する場合も、同様の制御を適用することをおすすめします。
| 管理機能 | 説明 |
|---|---|
ビルド構成を分離して、デプロイ前にコードを検証する |
このブループリントは、パイプライン全体で 2 つの Cloud Build ビルド構成ファイルを使用します。ステージに関連付けられた各リポジトリには、これらのビルド構成ファイルに関連付けられた 2 つの Cloud Build トリガーがあります。コードがリポジトリ ブランチに push されると、ビルド構成ファイルがトリガーされ、まず |
Terraform ポリシー チェック | このブループリントには、Google Cloud CLI のポリシー検証によって適用される、一連の Open Policy Agent 制約が含まれます。これらの制約は、パイプラインによってデプロイできる、許容可能なリソース構成を定義します。最初のビルド構成のポリシーを遵守していないビルドの場合、2 番目のビルド構成ではリソースがデプロイされません。 ブループリントに適用されているポリシーは、GitHub の |
最小権限の原則 | 基盤パイプラインは、ステージごとに異なるサービス アカウントを持ちます。各アカウントには、そのステージで最小限の IAM ロールのみを付与する許可ポリシーが適用されています。各 Cloud Build トリガーは、そのステージの特定のサービス アカウントとして実行されます。異なるアカウントを使い分けることで、あるリポジトリを変更すると、別のリポジトリで管理されているリソースが影響を受ける可能性があるというリスクを軽減できます。各サービス アカウントに適用される特定の IAM ロールについては、ブートストラップ ステージの |
Cloud Build プライベート プール | このブループリントは、Cloud Build のプライベート プールを使用します。プライベート・プールを使用すると、公開リポジトリへのアクセス制限や、VPC Service Controls 境界内での Cloud Build の実行など、必要に応じて追加の管理機能を適用できます。 |
Cloud Build カスタム ビルダー | このブループリントは、独自のカスタム ビルダーを作成して Terraform を実行します。詳細については、 |
デプロイの承認 | 必要に応じて、Cloud Build に手動承認ステージを追加できます。この承認により、ビルドがトリガーされた後（ただし、ビルドの実行前）にチェック ポイントが追加され、特権ユーザーがビルドを手動で承認できるようになります。 |
ブランチ戦略
Git システムにコードを送信し、基盤パイプラインを通じてリソースをデプロイする場合は、永続ブランチ戦略をおすすめします。次の図は、永続ブランチ戦略を示したものです。
この図は、対応する Google Cloud 環境を反映する、Git の 3 つの永続ブランチ（開発環境、非本番環境、本番環境）を示しています。また、Google Cloud 環境にデプロイされたリソースに対応していない、エフェメラルな機能ブランチもいくつか存在します。
Git システムには、永続ブランチに統合されるすべてのコードに承認済みの pull リクエスト（PR）が含められるように、PR プロセスを適用することをおすすめします。
この永続ブランチ戦略でコードを開発する大まかな手順は次のとおりです。
- 新機能を開発する場合やバグの修正に取り組んでいる場合は、開発ブランチに基づいて新しいブランチを作成します。ブランチ名には、変更の種類、チケット番号などの識別子、人が読める形式の説明を含めた命名規則を使用します（例:
feature/123456-org-policies）。 - 機能ブランチの作業が完了したら、開発ブランチをターゲットとする PR を開きます。
- PR を送信すると、PR は基盤パイプラインをトリガーして
terraform planとterraform validateを実行し、変更をステージングして検証します。 - コードの変更を検証したら、機能またはバグの修正を開発ブランチに統合します。
- 統合プロセスにより、基盤パイプラインがトリガーされます。これにより
terraform applyが実行され、開発ブランチの最新の変更が開発環境にデプロイされます。 - ユースケースに関連する手動確認、機能テスト、またはエンドツーエンド テストを使用して、開発環境の変更を確認します。次に、非本番環境ブランチをターゲットとする PR を開いて、非本番環境への変更を昇格し、変更を統合します。
- リソースを本番環境にデプロイするには、ステップ 6 と同じプロセスを繰り返します。デプロイされたリソースを確認して検証し、本番環境ブランチへの PR を開いて統合します。
次のステップ
- オペレーションのベスト プラクティス（このシリーズの次のドキュメント）を確認する。
オペレーションのベスト プラクティス
このセクションでは、追加のワークロードを Google Cloud 環境にデプロイして運用する際に考慮すべきオペレーションについて説明します。このセクションは、クラウド環境におけるすべてのオペレーションを網羅するものではありませんが、アーキテクチャの推奨事項、およびブループリントによってデプロイするリソースに関連する決定事項を紹介します。
基盤のリソースを更新する
ブループリントは基盤環境の独自の開始点として使用できますが、基盤の要件は、時間の経過とともに増大する可能性があります。最初のデプロイ以降に、構成設定を調整したり、すべてのワークロードで使用される新しい共有サービスを構築したりする場合も考えられます。
基盤リソースを変更する場合は、基盤パイプラインを使用してすべての変更を行うことをおすすめします。コードの記述と統合の流れや、デプロイ パイプラインのトリガーの流れの概要については、ブランチ戦略をご覧ください。
新しいワークロード プロジェクトの属性を決定する
自動化パイプラインのプロジェクト ファクトリ モジュールを使用して新しいプロジェクトを作成する場合は、さまざまな属性を構成する必要があります。新しいワークロードのプロジェクトを設計して作成するプロセスでは、次のことを決定する必要があります。
- 有効にする Google Cloud APIs
- 使用する共有 VPC、または新しい VPC ネットワークを作成するかどうか
- パイプラインによって作成される最初の
project-service-accountに対して作成する IAM ロール - 適用するプロジェクト ラベル
- プロジェクトのデプロイ先となるフォルダ
- 使用する請求先アカウント
- プロジェクトを VPC Service Controls の境界に追加するかどうか
- プロジェクトの予算と請求アラートしきい値を構成するかどうか
各プロジェクトの構成可能な属性の詳細については、自動化パイプラインのプロジェクト ファクトリの入力変数をご覧ください。
権限を大規模に管理する
基盤上にワークロード プロジェクトをデプロイする場合は、対象となるデベロッパー、およびプロジェクトのユーザーに対し、アクセス権をどのように付与するかを検討する必要があります。既存の ID プロバイダが管理するグループにユーザーを追加し、グループを Cloud Identity と同期してから、グループに IAM ロールを適用することをおすすめします。また、最小権限の原則を常に念頭に置いてください。
また、IAM Recommender を使用して、権限が過剰なロールを付与する許可ポリシーを特定することをおすすめします。推奨事項を定期的に確認するプロセス、または推奨事項をデプロイ パイプラインに自動的に適用するプロセスを設計します。
ネットワーキング チームとアプリケーション チームの間で変更を調整する
ブループリントによってデプロイされるネットワーク トポロジでは、ネットワーク リソースの管理を担当するチームと、ワークロード インフラストラクチャ リソースのデプロイを担当するチームが別々に存在していることを前提としています。ワークロード チームはインフラストラクチャをデプロイするため、ワークロードのコンポーネント間で目的のアクセスパスを許可するファイアウォール ルールを作成する必要があります。しかし、このチームには、ネットワーク ファイアウォール ポリシーを自分たちで変更する権限はありません。
アプリケーションのデプロイに必要となる、一元化されたネットワーキング リソースに対する変更を調整するために、各チームがどのように連携するかを計画しましょう。たとえば、ワークロード チームがアプリケーション用のタグをリクエストするプロセスを設計します。これに対し、ネットワーキング チームはタグを作成してネットワーク ファイアウォール ポリシーにルールを追加し、タグを持つリソース間でのトラフィックのフローを許可し、タグを使用するための IAM ロールをワークロード チームに委任します。
Active Assist ポートフォリオで環境を最適化する
Google Cloud には、IAM Recommender のほか、環境の最適化方法に関する推奨事項を作成する Active Assist サービス ポートフォリオが用意されています。たとえば、ファイアウォール インサイトや放置されたプロジェクトの Recommender は、セキュリティ ポスチャーの強化に役立つ実用的な推奨事項を提供します。
推奨事項を定期的に確認するプロセス、または推奨事項をデプロイ パイプラインに自動的に適用するプロセスを設計します。中央チームが管理する推奨事項とワークロード オーナーが責任を持つ推奨事項を決定し、それぞれの推奨事項にアクセスできるよう、必要な IAM ロールを適用します。
組織のポリシーに例外を付与する
このブループリントで適用される組織のポリシーの制約セットは、大半のシナリオにおいて、ほとんどのユーザーに推奨されます。しかし、広範囲に適用する組織のポリシーに対して、限定的な例外を必要とする正当なユースケースが生じる場合もあります。
たとえば、このブループリントは iam.disableServiceAccountKeyCreation の制約を適用します。サービス アカウント キーの漏洩は重大な悪影響を及ぼす可能性があるため、この制約は重要なセキュリティ管理策です。したがって、ほとんどのシナリオでは、サービス アカウント キーよりも安全な代替手段を使用して認証を行う必要があります。しかし、認証にサービス アカウント キーしか使用できないユースケースもあります。Google Cloud サービスへのアクセスを必要とし、Workload Identity 連携を使用できないオンプレミス サーバーなどです。このようなシナリオでは、サービス アカウント キーを管理するためのベスト プラクティスなどの補完的な対策が追加されている限り、ポリシーの例外を許可するような判断が必要となります。
したがって、ワークロードのポリシーの例外をリクエストするプロセスを設計する必要があります。また、例外の付与を担当する意思決定者は、ユースケースを検証し、補完的なセキュリティ対策を追加するべきかどうかを相談できる十分な知識を有している必要があります。ワークロードに例外を付与する場合は、組織のポリシーの制約をできるだけ絞り込んで変更します。また、ポリシーの例外または適用を許可するタグを定義し、そのタグをプロジェクトとフォルダに適用することで、組織のポリシーに条件付きで制約を追加することもできます。
VPC Service Controls でリソースを保護する
このブループリントを使用することで、ベース ネットワークと制限付きネットワークを分離し、VPC Service Controls 用の環境を準備できます。ただし、デフォルトでは、Terraform コードは VPC Service Controls を有効化しません。有効化することで、中断を生じさせるプロセスになる可能性があるためです。
境界では、境界外からのトラフィック（コンソール、デベロッパー ワークステーション、リソースのデプロイに使用される基盤パイプラインなど）に対し、制限付きの Google Cloud サービスへのアクセスが拒否されます。VPC Service Controls を使用する場合は、目的のアクセスパスを許可する例外を境界に対して設計する必要があります。
VPC Service Controls の境界は、Google Cloud 組織と外部ソースとの間で、データの引き出しが生じるのを制御することを意図しています。個々のプロジェクトやリソースに対するきめ細かなアクセス制御のために、許可ポリシーの置き換えや複製を行うものではありません。境界を設計して構築する場合は、管理オーバーヘッドを低減するため、統一された共通の境界を使用することをおすすめします。
Google Cloud 組織内のサービス トラフィックをきめ細かく制御するために、複数の境界を設計する必要がある場合は、より複雑な境界構造で対処すべき脅威と、目的のオペレーションに必要となる境界間のアクセスパスを明確に定義することをおすすめします。
VPC Service Controls を導入する場合は、次の点を評価します。
- VPC Service Controls を必要とするユースケース。
必要な Google Cloud サービスが VPC Service Controls をサポートしているかどうか。
自動化パイプラインが中断された場合に、境界を修正するためのブレークグラス アクセスを構成する方法。
VPC Service Controls を有効にするためのベスト プラクティスを使用して境界を設計し、実装する方法。
境界を有効にしたら、新しいプロジェクトを適切な境界に一貫して追加するプロセスと、現在の境界の設定では拒否される新しいユースケースが生じた場合の例外を設計するプロセスを設計しておくことをおすすめします。
組織ごとに組織全体の変更をテストする
変更を本番環境にデプロイする際は、必ず事前にテストすることをおすすめします。ワークロード リソースの場合、開発環境、非本番環境、本番環境を個別に用意して使用することで、このアプローチを実践しやすくなります。ただし、組織には、テストを円滑に行うための個別の環境を用意できないリソースもあります。
組織レベルでの変更や、本番環境に影響を与える可能性があるその他の変更（ID プロバイダと Cloud Identity 間の設定など）については、テスト用に個別の組織を作成することを検討してください。
仮想マシンへのリモート アクセスを制御する
基盤パイプライン、インフラストラクチャ パイプライン、アプリケーション パイプラインを使用して、不変のインフラストラクチャをデプロイすることが推奨されます。したがって、制限付きまたは例外的なユースケースでは、SSH または RDP 経由での仮想マシンへの直接アクセス権のみをデベロッパーに付与することをおすすめします。
リモート アクセスが必要なシナリオでは、可能であれば OS Login を使用してユーザー アクセスを管理することをおすすめします。このアプローチでは、マネージド Google Cloud サービスを使用して、アクセス制御、アカウント ライフサイクル管理、2 段階認証プロセス、監査ログを適用します。ただし、メタデータの SSH 認証鍵または RDP 認証情報を介したアクセスを許可する必要がある場合、認証情報のライフサイクルを管理し、その認証情報を Google Cloud の外部に安全に保管することは、お客様の責任となります。
いずれのシナリオでも、VM への SSH または RDP アクセス権を持つユーザーは権限昇格のリスクを伴うため、この点を念頭に置いてアクセスモデルを設計する必要があります。ユーザーは、関連するサービス アカウントの権限を使用して、その VM 上でコードを実行することも、メタデータ サーバーに対してクエリを実行して、API リクエストの認証に使用されるアクセス トークンを表示することもできます。このような場合、ユーザーにサービス アカウントの権限を使用させるつもりがなくても、このアクセス権が権限昇格となる可能性があります。
予算アラートを計画して過剰な支出を抑制する
このブループリントでは、Google Cloud Architecture Framework: 費用の最適化で紹介した、次のような費用管理のベスト プラクティスが実装されます。
エンタープライズ基盤のすべてのプロジェクトで単一の請求先アカウントを使用します。
各プロジェクトに
billingcodeメタデータ ラベルを割り当てます。これは、コストセンター間でコストを割り当てるために使用されます。予算とアラートのしきい値を設定します。
予算を計画して請求アラートを設定することは、お客様の責任となります。このブループリントは、予測支出額が予算の 120% に達すると予想される場合、ワークロード プロジェクトの予算アラートを作成します。このアプローチにより、中央チームは多大な費用超過のインシデントを特定して軽減できます。明確な原因なしに支出が大幅に増加した場合は、セキュリティ インシデントの兆候である可能性があります。このような場合は、コスト管理とセキュリティの両方の観点から調査する必要があります。
ユースケースに応じて、プロジェクトごとにきめ細かく予算を設定するのではなく、環境フォルダ全体の費用、または特定のコストセンターに関連するすべてのプロジェクトの費用に基づいて予算を設定できます。また、日常的なモニタリングのために、より詳細なアラートしきい値を設定すると考えられるワークロード オーナーに対し、予算とアラート設定を委任することもおすすめします。
ワークロードの予算の予測など、FinOps 機能の構築に関するガイダンスについては、Google Cloud で FinOps を使ってみるをご覧ください。
内部コストセンター間で費用を割り当てる
コンソールを使用すると、請求レポートを表示して、複数の項目で費用を表示して予測できます。事前構築済みのレポートに加えて、請求データを prj-c-billing-logs プロジェクトの BigQuery データセットにエクスポートすることをおすすめします。エクスポートされた請求レコードを使用すると、billingcode などのプロジェクト ラベルのメタデータに基づいて、内部コストセンターなどのカスタム ディメンションに費用を割り当てることができます。
次の SQL クエリは、billingcode プロジェクト ラベルでグループ化されたすべてのプロジェクトの費用を把握するためのサンプルクエリです。
#standardSQL
SELECT
(SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
service.description AS description,
SUM(cost) AS charges,
SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC
このエクスポートを設定する方法については、Cloud Billing データを BigQuery にエクスポートするをご覧ください。
コストセンター間で内部の会計処理またはチャージバックが必要となる場合、このクエリから取得したデータを内部プロセスに組み込むのはお客様の責任となります。
検知制御による検出結果を既存の SIEM に取り込む
基盤リソースは、監査ログとセキュリティ検出結果の集約先を設定するのに役立ちますが、これらのシグナルの消費方法と使用方法を決定するのはお客様の責任となります。
すべてのクラウド環境とオンプレミス環境のログを既存の SIEM に集約する必要がある場合は、prj-c-logging プロジェクトからのログ、および Security Command Center からの検出結果を、既存のツールやプロセスにどのように取り込むかを決定します。1 つのチームが環境全体のセキュリティをモニタリングする場合であれば、すべてのログと検出結果に対する単一のエクスポートを作成できます。職責の異なる複数のチームが必要とするログと検出結果に応じてフィルタリングする必要がある場合は、複数のエクスポートを作成できます。
また、ログの量が膨大で費用がかかりすぎる場合は、Google Cloud のログと検出結果を Google Cloud 内のみで保持するようにし、重複を避ける必要があります。このシナリオでは、既存のチームが、Google Cloud 内のログと検出結果を直接処理できるための適切なアクセス権を持ち、そのトレーニングを受けていることを確認してください。
- 監査ログについては、一元化されたログバケット内のログのサブセットに対するアクセス権を各チームに付与するようにログビューを設計します。複数のバケットにログを複製する方法では、ログストレージの費用が増大してしまいます。
- セキュリティ検出結果の場合は、Security Command Center にフォルダレベルとプロジェクト レベルのロールを付与し、どのチームも、自身が担当するプロジェクトのセキュリティ検出結果だけをコンソールで直接表示および管理できるようにします。
制御ライブラリの継続的な開発
このブループリントは、脅威を検出して防止する基本的な制御が出発点となります。これらの制御を確認し、要件に応じて必要な制御を追加することをおすすめします。次の表は、ガバナンス ポリシーを適用するメカニズムと、追加要件に合わせてポリシーを拡張する方法をまとめたものです。
| ブループリントによって適用されるポリシー制御 | 制御を拡張するためのガイダンス |
|---|---|
Security Command Center は、複数のセキュリティ ソースから脆弱性と脅威を検出します。 |
Security Health Analytics のカスタム モジュールと Event Threat Detection のカスタム モジュールを定義します。 |
組織のポリシー サービスは、推奨される一連の組織ポリシー制約を Google Cloud サービスに適用します。 |
|
Open Policy Agent（OPA）ポリシーは、デプロイ前に基盤パイプラインのコードを検証し、適切な設定かどうかを確認します。 |
GoogleCloudPlatform/policy-library のガイダンスに基づいて追加の制約を作成します。 |
ログベースの指標とパフォーマンス指標に関するアラートは、ログベースの指標を設定して、IAM ポリシー、および一部の機密リソースの設定に変更が加えられた場合にアラートを表示します。 |
環境で発生すべきではないログイベントについて、追加のログベースの指標とアラート ポリシーを設計します。 |
自動ログ分析用のカスタム ソリューションは、不審なアクティビティがないかログを定期的にクエリし、Security Command Center の検出結果を作成します。 |
セキュリティ ログ分析を参照として使用し、モニタリングするセキュリティ イベントに対する検出結果を作成するための追加のクエリを作成します。 |
アセットの変更に対応するカスタム ソリューションは、Security Command Center の検出結果を作成し、修復アクションを自動化できます。 |
追加の Cloud Asset Inventory フィードを作成して、特定のアセットタイプの変更をモニタリングし、カスタム ロジックを使用して、ポリシー違反に対応する Cloud Functions を追加します。 |
これらの制御は、お客様の要件と Google Cloud での成熟度が変化するにつれて進化する可能性があります。
Cloud Key Management Service で暗号鍵を管理する
Google Cloud では、お客様のすべてのコンテンツに対して保存データの暗号化がデフォルトで提供されますが、保存データの暗号鍵をさらに制御できるように、Cloud Key Management Service（Cloud KMS）が用意されています。デフォルトの暗号化で十分なのか、それとも Cloud KMS を使用して独自に鍵を管理しなければならないコンプライアンス要件があるのかどうかを評価することをおすすめします。詳細については、保存データの暗号化に関するコンプライアンス要件を満たす方法を決定するをご覧ください。
このブループリントでは、暗号鍵を一元管理するために、共通フォルダ内に prj-c-kms プロジェクトを用意し、各環境フォルダ内に prj-{env}-kms プロジェクトを用意しています。このアプローチにより、中央チームは規制要件とコンプライアンス要件を満たすために、ワークロード プロジェクトのリソースに使用される暗号鍵を監査、管理できます。
運用モデルによっては、一元化された単一の Cloud KMS プロジェクト インスタンスを単一チームの管理下に置くことが望ましい場合もあれば、各環境で暗号鍵を個別に管理することが望ましい場合もあり、暗号鍵の説明責任を適切なチームに委任できるように、複数の分散インスタンスを設置することが望ましい場合もあります。運用モデルに合わせて、必要に応じて Terraform コードサンプルを変更してください。
必要に応じて、特定のリソースタイプでは常に CMEK 鍵を要求し、信頼できるプロジェクトの許可リストにある CMEK 鍵のみを使用できるように、顧客管理の暗号鍵（CMEK）の組織のポリシーを適用できます。
Secret Manager でアプリケーションの認証情報を保存、監査する
API キー、パスワード、プライベート証明書など、機密性の高いシークレットはソースコード リポジトリに commit しないことをおすすめします。代わりに、シークレットを Secret Manager に commit し、シークレットへのアクセスを必要とするユーザーまたはサービス アカウントに Secret Manager のシークレット アクセサーの IAM ロールを付与します。IAM ロールは、プロジェクト内のすべてのシークレットではなく、個々のシークレットに付与することをおすすめします。
可能であれば、CI / CD パイプライン内で本番環境のシークレットを自動生成し、ブレークグラスの状況以外で人間のユーザーがアクセスできないように管理します。このシナリオでは、どのユーザーやグループに対しても、これらのシークレットを表示する IAM ロールを付与しないように注意してください。
このブループリントでは、共通フォルダ内に 1 つの prj-c-secrets プロジェクトを用意し、各環境フォルダ内に prj-{env}-secrets プロジェクトを用意して、シークレットを一元管理しています。このアプローチでは、各アプリケーションで使用されるシークレットを中央チームが監査、管理し、規制とコンプライアンスの要件を満たすことができます。
運用モデルによっては、1 つの Secret Manager インスタンスを 1 つのチームに集中管理させる方法、各環境で個別にシークレットを管理する方法、あるいは複数の Secret Manager インスタンスを分散して設置し、各ワークロード チームがそれぞれのシークレットを管理できるようにする方法が適している場合もあります。運用モデルに合わせて、必要に応じて Terraform コードサンプルを変更してください。
高い権限を持つアカウントへのブレークグラス アクセスを計画する
基盤リソースへの変更は、基盤パイプラインによってデプロイされる、バージョン管理された IaC を通じて管理されることが推奨されますが、例外的または緊急のシナリオでは、特権アクセスによって環境を直接変更する必要が生じることもあります。緊急時や、自動化プロセスが中断した場合に備えて、環境に対する高度な特権アクセスを持つブレークグラス アカウント（ファイアコール アカウントや緊急アカウントとも呼ばれます）を計画しておくことをおすすめします。
次の表に、ブレークグラス アカウントの用途例を示します。
| ブレークグラスの目的 | 説明 |
|---|---|
特権管理者 | ID 連携や多要素認証（MFA）に関連する問題を修正する場合など、Cloud Identity で使用される特権管理者ロールへの緊急アクセス権。 |
組織管理者 |
組織管理者ロールへの緊急アクセス権。これにより、組織内の他の任意の IAM ロールにアクセス権を付与できます。 |
基盤パイプライン管理者 | 基礎パイプラインの自動化が中断した場合に、Google Cloud 上の CICD プロジェクトと外部 Git リポジトリのリソースを修正するための緊急アクセス権。 |
運用または SRE |
運用チームや SRE チームが、サービスの停止やインシデントに対応するために必要な特権アクセス。これには、VM の再起動やデータの復元などのタスクが含まれます。 |
ブレークグラス アクセスを許可するメカニズムは、既存のツールと手順によって異なりますが、たとえば次のようなメカニズムが考えられます。
- 高い権限を持つ IAM ロールを事前定義しておいたグループに、既存の特権アクセス管理ツールを使用してユーザーを一時的に追加するか、高い権限を持つアカウントの認証情報を使用します。
- 管理者専用のアカウントを事前にプロビジョニングしておきます。たとえば、Dana というデベロッパーがいたとします。日常的に使用する dana@example.com という ID とは別に、ブレークグラス アクセス用の admin-dana@example.com という ID を用意しておくことができます。
- デベロッパーが上位の特権ロールに自己昇格できるようにする、ジャストインタイム特権アクセスなどのアプリケーションを使用します。
どのようなメカニズムを使用する場合であっても、以下の質問に運用上どのように対処するかを検討してください。
- ブレークグラス アクセスのスコープと粒度をどのように設計するか。たとえば、それぞれのブレークグラス メカニズムが干渉し合わないように、ビジネス ユニットごとに異なるメカニズムを設計します。
- 不正行為をどのように防止するメカニズムか。承認は必要か。たとえば、オペレーションを分割して、1 人のユーザーが認証情報を保持し、もう 1 人のユーザーが MFA トークンを保持するようにします。
- ブレークグラス アクセスの監査とアラートをどのように実施するか。たとえば、事前定義したブレークグラス アカウントの使用中に、セキュリティの検出結果が生成されるように、Event Threat Detection のカスタム モジュールを設定できます。
- インシデント解決後に、ブレークグラス アクセスを削除して通常のオペレーションを再開するにはどうすればよいか。
一般的な権限昇格タスクと変更のロールバックについては、ユーザーが自身の ID を権限昇格することなくオペレーションを実行できる、自動ワークフローを設計することをおすすめします。このアプローチは、人為的ミスを減らし、セキュリティを強化するのに役立ちます。
定期的な介入が必要なシステムでは、修正を自動化することが最適なソリューションとなる場合があります。ゼロタッチの本番環境アプローチを採用し、自動化、安全なプロキシ、または監査されたブレークグラスを使用して、すべての本番環境の変更を自動実行することをおすすめします。Google では、Google の SRE アプローチの導入を検討しているお客様向けに SRE 関連の書籍を提供しています。
次のステップ
- ブループリントをデプロイする（このシリーズの次のドキュメント）を読む。
ブループリントをデプロイする
このセクションでは、ブループリントのデプロイに使用できるプロセス、その命名規則、ブループリントの推奨事項に代わる方法について説明します。
タスクのまとめ
このブループリントのベスト プラクティスと推奨事項に沿って独自のエンタープライズ基盤をデプロイするには、このセクションにまとめられた大まかなタスクを実施してください。デプロイするには、前提条件のセットアップ手順、GitHub の terraform-example-foundation による自動デプロイ、最初の基盤デプロイの完了後に手動で構成する必要がある追加の手順を組み合わせる必要があります。
| プロセス | ステップ |
|---|---|
基盤パイプライン リソースをデプロイする前の前提条件 |
基盤パイプラインをデプロイする前に、以下の手順を完了します。
既存のオンプレミス環境に接続するには、以下の準備を行います。
|
GitHub から terraform-example-foundation をデプロイする手順 |
各ステージの README に沿って、GitHub から terraform-example-foundation をデプロイします。
|
IaC のデプロイ後の追加手順 |
Terraform コードをデプロイしたら、次の操作を完了します。
|
機密性の高いワークロードを扱うお客様向けのその他の管理機能
Google Cloud には、セキュリティとコンプライアンスの要件に向けた便利な追加の管理機能が用意されています。ただし、一部の管理機能には追加の費用や運用上のトレードオフが伴うため、すべてのお客様にとって必ずしも適切であるとは限りません。このような管理機能には、特定の要件に合わせてカスタマイズされた入力情報も必要です。この操作は、すべてのお客様向けのデフォルト値を使用してブループリントで完全に自動化することはできません。
このセクションでは、基盤に一元的に適用できるセキュリティ管理について説明します。このセクションは、特定のワークロードに適用できるすべてのセキュリティ管理を網羅するものではありません。Google のセキュリティ プロダクトとソリューションの詳細については、Google Cloud セキュリティ ベスト プラクティス センターをご覧ください。
コンプライアンス要件、リスク許容度、データの機密性に基づいて、次の各管理機能が基盤に適しているかどうかを評価します。
| 管理機能 | 説明 |
|---|---|
VPC Service Controls では、信頼できる境界の外部にある Google マネージド サービスへのアクセスを禁止して、信頼できない場所からのデータへのアクセスをブロックし、データ漏洩のリスクを軽減するセキュリティ ポリシーを定義できます。ただし、計画的なアクセス パターンを許可する例外を定義するまで、VPC Service Controls により既存のサービスが中断される可能性があります。 情報漏洩のリスクを軽減する価値が、VPC Service Controls の導入に伴う複雑さと運用オーバーヘッドの増加に見合うかどうかを評価します。ブループリントは、VPC Service Controls を構成する制限付きネットワークとオプションの変数を作成しますが、境界を設計して有効にする追加の手順を踏むまで、境界は有効になりません。 |
|
規制要件によっては、クラウド リソースを承認された地理的位置にのみデプロイする必要があります。この組織のポリシーの制約により、定義したロケーションのリストにのみリソースをデプロイできるようになります。 |
|
Assured Workloads は、特定の規制制度への対応に役立つ追加のコンプライアンス管理を提供します。ブループリントのデプロイ パイプラインには、これを有効にするオプションの変数が用意されています。 |
|
特定のセンシティブ データまたはリソースへのすべてのアクセスをログに記録することが要件となる場合があります。 データアクセス ログを必要とするセンシティブ データをワークロードが処理する場所を評価し、センシティブ データを扱うサービスや環境ごとにログを有効にします。 |
|
Access Approval により、Cloud カスタマーケアやエンジニアリングがお客様のデータにアクセスする必要がある場合は常に、お客様の明示的な承認が必要になります。 Access Approval のリクエストを確認するために必要な運用プロセスを評価して、サポート インシデントの解決で遅延が発生しないようにします。 |
|
Key Access Justifications を使用すると、自動化されたオペレーションまたはカスタマーケアによるお客様のコンテンツへのアクセスなどの目的で、Google がお客様の暗号鍵にアクセスできるかどうかをプログラムで制御できます。 Key Access Justifications に関連する費用と運用オーバーヘッドのほか、その Cloud External Key Manager（Cloud EKM）との依存関係を評価します。 |
|
Cloud Shell はオンライン開発環境です。お客様環境の外部にある Google が管理するサーバーでホストされているため、お客様独自のデベロッパー ワークステーションに実装された管理機能の対象にはなりません。 デベロッパーがクラウド リソースへのアクセスに使用できるワークステーションを厳密に制御する場合は、Cloud Shell を無効にします。お客様独自の環境で構成可能なワークステーションのオプションとして Cloud Workstations を評価することもできます。 |
|
Google Cloud では、グループ メンバー、信頼できる IP アドレス範囲、デバイスの確認などのアクセスレベルの属性に基づいて、Google Cloud コンソールへのアクセスを制限できます。一部の属性では、BeyondCorp Enterprise への追加サブスクリプションが必要です。 大規模なゼロトラスト デプロイの一環として、コンソールなどのウェブベースのアプリケーションへのユーザー アクセスに関して信頼できるアクセス パターンを評価します。 |
命名規則
Google Cloud リソースには、標準化された命名規則を使用することをおすすめします。次の表は、ブループリントのリソース名に推奨される規則を示しています。
| リソース | 命名規則 |
|---|---|
フォルダ |
例: |
プロジェクト ID |
例: |
VPC ネットワーク |
例: |
サブネット |
例: |
ファイアウォール ポリシー |
例:
|
Cloud Router |
例: |
Cloud Interconnect 接続 |
例: |
Cloud Interconnect VLAN アタッチメント |
例: |
グループ |
ここで、 例: |
カスタムロール |
ここで、 例: |
サービス アカウント |
各要素の意味は次のとおりです。
例: |
Storage バケット |
各要素の意味は次のとおりです。
例: |
デフォルトの推奨事項に代わる方法
ブループリントで推奨されているベスト プラクティスは、すべてのお客様に当てはまるとは限りません。推奨事項は、特定の要件に合わせてカスタマイズできます。次の表は、既存の技術スタックと業務の進め方に応じて必要となる可能性のある一般的なバリエーションの一部を示しています。
| 決定分野 | 代替策 |
|---|---|
組織: このブループリントでは、すべてのリソースのルートノードとして単一の組織を使用します。 |
Google Cloud ランディング ゾーンのリソース階層を決定するでは、次のような複数の組織を選択するシナリオが紹介されています。
|
フォルダ構造: このブループリントはシンプルなフォルダ構造を持ち、ワークロードは最上位のレイヤで |
Google Cloud ランディング ゾーンのリソース階層を決定するでは、リソースの管理方法とポリシーの継承方法に基づいてフォルダを構造化する次のような別の方法が紹介されています。
|
組織のポリシー: このブループリントでは、すべての組織のポリシーの制約が組織ノードで適用されます。 |
セキュリティ ポリシーや業務の進め方は、ビジネスの部門ごとに異なる場合もあります。そのようなシナリオでは、組織のポリシーの制約をリソース階層の下位ノードで適用します。組織のポリシーの制約の一覧で、要件を満たす制約をご確認ください。 |
デプロイ パイプライン ツール: このブループリントは、Cloud Build を使用して自動化パイプラインを実行します。 |
デプロイ パイプラインには、Terraform Enterprise、GitLab Runners、GitHub Actions、Jenkins などの他のプロダクトを使用する場合もあります。ブループリントには、各プロダクトの代替案が含まれています。 |
デプロイ用のコード リポジトリ: このブループリントは、限定公開のマネージド Git リポジトリとして Cloud Source Repositories を使用します。 |
コード リポジトリの管理には、GitLab、GitHub、Bitbucket など、任意のバージョン管理システムを使用することもできます。 オンプレミス環境でホストされている限定公開リポジトリを使用する場合は、リポジトリから Google Cloud 環境へのプライベート ネットワーク パスを構成します。 |
ID プロバイダ: このブループリントは、オンプレミスの Active Directory を前提として、Google Cloud Directory Sync を使用して ID を Cloud Identity と連携させます。 |
すでに Google Workspace を使用している場合は、Google Workspace で管理されている Google ID を使用することもできます。 既存の ID プロバイダがない場合は、Cloud Identity でユーザー ID を直接作成して管理できます。 Okta、Ping、Azure Entra ID などの既存の ID プロバイダがある場合は、既存の ID プロバイダでユーザー アカウントを管理して Cloud Identity と同期できます。 データ主権またはコンプライアンスの要件により Cloud Identity を使用できない場合や、Google 広告または Google マーケティング プラットフォームなどの他の Google サービスで管理対象の Google ユーザー ID が必要ない場合は、Workforce Identity 連携の方が適している可能性があります。このシナリオでは、サポート対象のサービスの制限事項にご注意ください。 |
複数のリージョン: このブループリントは、リージョン リソースを 2 つの異なる Google Cloud リージョンにデプロイし、高可用性と障害復旧の要件を考慮したワークロード設計を可能にします。 |
エンドユーザーが複数の地域に分散している場合は、レイテンシの影響を受けにくいエンドユーザーに近いリソースを作成するために、Google Cloud リージョンを追加で構成することもできます。 データ主権の制約がある場合、または単一のリージョンで可用性のニーズを満たすことができる場合は、1 つの Google Cloud リージョンのみを構成することもできます。 |
IP アドレスの割り振り: このブループリントは、一連の IP アドレス範囲を提供します。 |
既存のハイブリッド環境で使用できる IP アドレスに基づいて、使用する特定の IP アドレス範囲の変更が必要になる場合があります。IP アドレス範囲を変更する場合は、必要となる範囲の数とサイズのガイダンスとしてブループリントを使用し、Google Cloud の有効な IP アドレス範囲をご確認ください。 |
ハイブリッド ネットワーキング: このブループリントは、帯域幅と可用性を最大化するために、複数の物理サイトと Google Cloud リージョンの間で Dedicated Interconnect を使用します。 |
費用、帯域幅、信頼性の要件によっては、Partner Interconnect または Cloud VPN を構成することもできます。 Dedicated Interconnect の完了前にプライベート接続でリソースのデプロイを開始する必要がある場合は、Cloud VPN から始めて、後から Dedicated Interconnect を使用するように変更することもできます。 既存のオンプレミス環境がない場合は、ハイブリッド ネットワーキングがまったく必要ない可能性もあります。 |
VPC Service Controls の境界: このブループリントでは、制限付き VPC ネットワークに関連付けられたすべてのサービス プロジェクトを含む単一の境界が推奨されています。ベース VPC ネットワークに関連付けられたプロジェクトは、境界内には含まれません。 |
ユースケースによっては、組織に複数の境界を必要とする場合や、VPC Service Controls をまったく使用しない場合もあります。 詳細については、Google API を使用してデータの引き出しを抑制する方法を決定するをご覧ください。 |
Secret Manager: このブループリントは、組織全体のシークレット用の |
組織全体で機密性の高いシークレットの管理と監査を担当する単一のチームがある場合は、シークレットへのアクセスの管理に単一のプロジェクトのみを使用することをおすすめします。 各ワークロード チームが独自のシークレットを管理できるようにする場合は、一元化されたプロジェクトを使用してシークレットへのアクセスを管理するのではなく、各チームがワークロード プロジェクトで独自の Secret Manager インスタンスを使用できるようにすることもできます。 |
Cloud KMS: このブループリントは、組織全体の鍵用の |
組織全体で暗号鍵の管理と監査を担当する単一のチームがある場合は、鍵へのアクセスの管理に単一のプロジェクトのみを使用することをおすすめします。一元化されたアプローチは、PCI 鍵管理者などのコンプライアンス要件を満たすのに役立ちます。 ワークロード チームが独自の鍵を管理できるようにする場合は、一元化されたプロジェクトを使用して鍵へのアクセスを管理するのではなく、各チームがワークロード プロジェクトで独自の Cloud KMS インスタンスを使用できるようにすることもできます。 |
集約されたログシンク: このブループリントは、組織ノードに一連のログシンクを構成して、中央のセキュリティ チームが組織全体の監査ログを確認できるようにします。 |
ビジネスの部門ごとに監査を担当する複数のチームがあり、各チームがそれぞれの業務で別々のログを必要とすることもあります。このような場合は、適切なフォルダとプロジェクトで複数の集約されたシンクを設計し、各チームが必要なログのみを受け取るようにフィルタを作成するか、共通のログバケットに対してきめ細かくアクセス制御できるログビューを設計します。 |
モニタリング スコープ対象プロジェクト: このブループリントは、環境ごとに単一のモニタリング スコープ対象プロジェクトを構成します。 |
各チームが管理するきめ細かいスコープ対象プロジェクトを構成し、それぞれのチームが管理するアプリケーションを含む一連のプロジェクトにスコープを設定することもできます。 |
インフラストラクチャ パイプラインの粒度: このブループリントは、各ビジネス ユニットが個別のインフラストラクチャ パイプラインを持ち、ワークロード プロジェクトを管理するモデルを使用します。 |
すべてのプロジェクトとインフラストラクチャのデプロイを担当する中央チームがある場合は、中央チームが管理する単一のインフラストラクチャ パイプラインを選択することもできます。この中央チームは、ワークロード チームからの pull リクエストを受け入れて、プロジェクトを作成する前に確認して承認することができます。また、チケット制システムに応じて、チーム自体が pull リクエストを作成することもできます。 個々のワークロード チームが独自のパイプラインをカスタマイズできる場合で、パイプラインに対する詳細な権限が付与されたサービス アカウントを設計する場合は、より粒度の細かいパイプラインを選択することもできます。 |
SIEM エクスポート: ブループリントは、すべてのセキュリティ検出結果を Security Command Center で管理します。 |
セキュリティ検出結果は、Security Command Center から Chronicle や既存の SIEM などのツールにエクスポートすることもできますが、チームがコンソールを使用してセキュリティ検出結果を表示および管理することもできます。また、スコープと責任が異なる固有のフィルタをチームごとに使用して、複数のエクスポートを構成することもできます。 |
オンプレミスからの Google Cloud サービスの DNS ルックアップ: このブループリントは、共有 VPC ごとに一意の Private Service Connect エンドポイントを構成します。これにより、複数の VPC Service Controls の境界を使用した設計が可能になります。 |
複数の VPC Service Controls の境界を必要としない場合は、オンプレミス環境から Private Service Connect エンドポイントに対して、この粒度でルーティングを行う必要がない場合もあります。 環境ごとにオンプレミス ホストを Private Service Connect エンドポイントにマッピングする代わりに、適切な API バンドルを含む単一の Private Service Connect エンドポイントを使用するか、 |
次のステップ
- GitHub の Terraform のサンプル基盤を使用してブループリントを実装する。
- Google Cloud アーキテクチャ フレームワークで、設計原則のベスト プラクティスについて詳しく学ぶ。
ブループリントのライブラリを確認して、次のような一般的なエンタープライズ ワークロードの設計と構築を迅速に進める。
基盤環境上にデプロイする関連ソリューションを確認する。
デモンストレーション環境へのアクセスについては、security-foundations-blueprint-support@google.com までお問い合わせください。