ブループリントをデプロイする

Last reviewed 2023-12-20 UTC

このセクションでは、ブループリントのデプロイに使用できるプロセス、その命名規則、ブループリントの推奨事項に代わる方法について説明します。

タスクのまとめ

このブループリントのベスト プラクティスと推奨事項に沿って独自のエンタープライズ基盤をデプロイするには、このセクションにまとめられた大まかなタスクを実施してください。デプロイするには、前提条件のセットアップ手順、GitHub の terraform-example-foundation による自動デプロイ、最初の基盤デプロイの完了後に手動で構成する必要がある追加の手順を組み合わせる必要があります。

プロセス ステップ

基盤パイプライン リソースをデプロイする前の前提条件

基盤パイプラインをデプロイする前に、以下の手順を完了します。

既存のオンプレミス環境に接続するには、以下の準備を行います。

GitHub から terraform-example-foundation をデプロイする手順

各ステージの README に沿って、GitHub から terraform-example-foundation をデプロイします。

  • 0-bootstrap をステージングして、基盤パイプラインを作成します。

    セルフサービスの請求先アカウントを使用している場合は、次のステージに進む前にプロジェクト割り当てを追加リクエストする必要があります。

  • 1-org をステージングして、組織レベルのリソースを構成します。
  • 2-environments をステージングして、環境を作成します。
  • 3-networks-dual-svpc または or 3-networks-hub-and-spoke をステージングして、任意のトポロジにネットワーク リソースを作成します。
  • 4-projects をステージングして、インフラストラクチャ パイプラインを作成します。
  • 必要に応じて 5-app-infra をステージングして、インフラストラクチャ パイプラインの使用例をデプロイします。

IaC のデプロイ後の追加手順

Terraform コードをデプロイしたら、次の操作を完了します。

機密性の高いワークロードを扱うお客様向けのその他の管理機能

Google Cloud には、セキュリティとコンプライアンスの要件に向けた便利な追加の管理機能が用意されています。ただし、一部の管理機能には追加の費用や運用上のトレードオフが伴うため、すべてのお客様にとって必ずしも適切であるとは限りません。このような管理機能には、特定の要件に合わせてカスタマイズされた入力情報も必要です。この操作は、すべてのお客様向けのデフォルト値を使用してブループリントで完全に自動化することはできません。

このセクションでは、基盤に一元的に適用できるセキュリティ管理について説明します。このセクションは、特定のワークロードに適用できるすべてのセキュリティ管理を網羅するものではありません。Google のセキュリティ プロダクトとソリューションの詳細については、Google Cloud セキュリティ ベスト プラクティス センターをご覧ください。

コンプライアンス要件、リスク許容度、データの機密性に基づいて、次の各管理機能が基盤に適しているかどうかを評価します。

管理機能 説明

VPC Service Controls でリソースを保護する

VPC Service Controls では、信頼できる境界の外部にある Google マネージド サービスへのアクセスを禁止して、信頼できない場所からのデータへのアクセスをブロックし、データ漏洩のリスクを軽減するセキュリティ ポリシーを定義できます。ただし、計画的なアクセス パターンを許可する例外を定義するまで、VPC Service Controls により既存のサービスが中断される可能性があります。

情報漏洩のリスクを軽減する価値が、VPC Service Controls の導入に伴う複雑さと運用オーバーヘッドの増加に見合うかどうかを評価します。ブループリントは、VPC Service Controls を構成する制限付きネットワークとオプションの変数を作成しますが、境界を設計して有効にする追加の手順を踏むまで、境界は有効になりません。

リソース ロケーションを制限する

規制要件によっては、クラウド リソースを承認された地理的位置にのみデプロイする必要があります。この組織のポリシーの制約により、定義したロケーションのリストにのみリソースをデプロイできるようになります。

Assured Workloads を有効にする

Assured Workloads は、特定の規制制度への対応に役立つ追加のコンプライアンス管理を提供します。ブループリントのデプロイ パイプラインには、これを有効にするオプションの変数が用意されています。

データアクセス ログを有効にする

特定のセンシティブ データまたはリソースへのすべてのアクセスをログに記録することが要件となる場合があります。

データアクセス ログを必要とするセンシティブ データをワークロードが処理する場所を評価し、センシティブ データを扱うサービスや環境ごとにログを有効にします。

Access Approval を有効にする

Access Approval により、Cloud カスタマーケアやエンジニアリングがお客様のデータにアクセスする必要がある場合は常に、お客様の明示的な承認が必要になります。

Access Approval のリクエストを確認するために必要な運用プロセスを評価して、サポート インシデントの解決で遅延が発生しないようにします。

Key Access Justifications を有効にする

Key Access Justifications を使用すると、自動化されたオペレーションまたはカスタマーケアによるお客様のコンテンツへのアクセスなどの目的で、Google がお客様の暗号鍵にアクセスできるかどうかをプログラムで制御できます。

Key Access Justifications に関連する費用と運用オーバーヘッドのほか、その Cloud External Key Manager（Cloud EKM）との依存関係を評価します。

Cloud Shell を無効にする

Cloud Shell はオンライン開発環境です。お客様環境の外部にある Google が管理するサーバーでホストされているため、お客様独自のデベロッパー ワークステーションに実装された管理機能の対象にはなりません。

デベロッパーがクラウド リソースへのアクセスに使用できるワークステーションを厳密に制御する場合は、Cloud Shell を無効にします。お客様独自の環境で構成可能なワークステーションのオプションとして Cloud Workstations を評価することもできます。

Google Cloud コンソールへのアクセスを制限する

Google Cloud では、グループ メンバー、信頼できる IP アドレス範囲、デバイスの確認などのアクセスレベルの属性に基づいて、Google Cloud コンソールへのアクセスを制限できます。一部の属性では、Chrome Enterprise Premium への追加サブスクリプションが必要です。

大規模なゼロトラスト デプロイの一環として、コンソールなどのウェブベースのアプリケーションへのユーザー アクセスに関して信頼できるアクセス パターンを評価します。

命名規則

Google Cloud リソースには、標準化された命名規則を使用することをおすすめします。次の表は、ブループリントのリソース名に推奨される規則を示しています。

リソース 命名規則

フォルダ

fldr-environment

environment は、Google Cloud 組織内のフォルダレベルのリソースの説明です。たとえば、bootstrap、common、production、nonproduction、development、network のいずれかにします。

例: fldr-production

プロジェクト ID

prj-environmentcode-description-randomid

  • environmentcode は、環境フィールドの短縮形（b、c、p、n、d、net のいずれか）にします。共有 VPC ホスト プロジェクトでは、関連付けられた環境の environmentcode を使用します。interconnect プロジェクトなど、複数の環境間で共有されるネットワーク リソースのプロジェクトでは、net 環境コードを使用します。
  • description は、プロジェクトに関する追加情報です。人が読める短い略称を使用できます。
  • randomid は、グローバルに一意である必要があるリソース名の競合を防ぎ、攻撃者によるリソース名の推測を回避するランダム化されたサフィックスです。ブループリントは、ランダムな 4 文字の英数字の識別子を自動的に追加します。

例: prj-c-logging-a1b2

VPC ネットワーク

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode は、環境フィールドの短縮形（b、c、p、n、d、net のいずれか）にします。
  • vpctype は、shared、float、peer のいずれかにします。
  • vpcconfig は、ネットワークが VPC Service Controls で使用されるかどうかに応じて、base または restricted のいずれかにします。

例: vpc-p-shared-base

サブネット

sn-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode は、環境フィールドの短縮形（b、c、p、n、d、net のいずれか）にします。
  • vpctype は、shared、float、peer のいずれかにします。
  • vpcconfig は、ネットワークが VPC Service Controls で使用されるかどうかに応じて、base または restricted のいずれかにします。
  • region は、リソースが配置されている有効な Google Cloud リージョンにします。文字数制限を超えないように、ハイフンを削除し、一部のリージョンと方角には省略形を使用することをおすすめします。たとえば、au（オーストラリア）、na（北米）、sa（中南米）、eu（ヨーロッパ）、se（東南）、ne（北東）のいずれかにします。
  • description は、サブネットに関する追加情報です。人が理解できる略語を使用できます。

例: sn-p-shared-restricted-uswest1

ファイアウォール ポリシー

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype は、hierarchical または network にします。
  • scope は、global またはリソースが配置されている Google Cloud リージョンにします。文字数制限を超えないように、ハイフンを削除し、一部のリージョンと方角には省略形を使用することをおすすめします。たとえば、au（オーストラリア）、na（北米）、sa（中南米）、eu（ヨーロッパ）、se（東南）、ne（北東）のいずれかにします。
  • environmentcode は、ポリシー リソースを所有する環境フィールドの短縮形（b、c、p、n、d、net のいずれか）にします。
  • description は、階層型ファイアウォール ポリシーに関する追加情報です。人が理解できる略語を使用できます。

例:

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Cloud Router

cr-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode は、環境フィールドの短縮形（b、c、p、n、d、net のいずれか）にします。
  • vpctype は、shared、float、peer のいずれかにします。
  • vpcconfig は、ネットワークが VPC Service Controls で使用されるかどうかに応じて、base または restricted のいずれかにします。
  • region は、リソースが配置されている有効な Google Cloud リージョンにします。文字数制限を超えないように、ハイフンを削除し、一部のリージョンと方角には省略形を使用することをおすすめします。たとえば、au（オーストラリア）、na（北米）、sa（中南米）、eu（ヨーロッパ）、se（東南）、ne（北東）のいずれかにします。
  • description は、Cloud Router に関する追加情報です。人が理解できる略語を使用できます。

例: cr-p-shared-base-useast1-cr1

Cloud Interconnect 接続

ic-dc-colo

  • dc は、Cloud Interconnect が接続されているデータセンターの名前にします。
  • colo は、オンプレミス データセンターからの Cloud Interconnect がピアリングされるコロケーション施設名にします。

例: ic-mydatacenter-lgazone1

Cloud Interconnect VLAN アタッチメント

vl-dc-colo-environmentcode-vpctype-vpcconfig-region{-description}

  • dc は、Cloud Interconnect が接続されているデータセンターの名前にします。
  • colo は、オンプレミス データセンターからの Cloud Interconnect がピアリングされるコロケーション施設名にします。
  • environmentcode は、環境フィールドの短縮形（b、c、p、n、d、net のいずれか）にします。
  • vpctype は、shared、float、peer のいずれかにします。
  • vpcconfig は、ネットワークが VPC Service Controls で使用されるかどうかに応じて、base または restricted のいずれかにします。
  • region は、リソースが配置されている有効な Google Cloud リージョンにします。文字数制限を超えないように、ハイフンを削除し、一部のリージョンと方角には省略形を使用することをおすすめします。たとえば、au（オーストラリア）、na（北米）、sa（中南米）、eu（ヨーロッパ）、se（東南）、ne（北東）のいずれかにします。
  • description は、VLAN に関する追加情報です。人が理解できる略語を使用できます。

例: vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1

グループ

grp-gcp-description@example.com

ここで、description はグループに関する追加情報です。人が理解できる略語を使用できます。

例: grp-gcp-billingadmin@example.com

カスタムロール

rl-description

ここで、description はロールに関する追加情報です。人が理解できる略語を使用できます。

例: rl-customcomputeadmin

サービス アカウント

sa-description@projectid.iam.gserviceaccount.com

各要素の意味は次のとおりです。

  • description は、サービス アカウントに関する追加情報です。人が理解できる略語を使用できます。
  • projectid は、グローバルに一意のプロジェクト ID にします。

例: sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

Storage バケット

bkt-projectid-description

各要素の意味は次のとおりです。

  • projectid は、グローバルに一意のプロジェクト ID にします。
  • description は、Storage バケットに関する追加情報です。人が理解できる略語を使用できます。

例: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

デフォルトの推奨事項に代わる方法

ブループリントで推奨されているベスト プラクティスは、すべてのお客様に当てはまるとは限りません。推奨事項は、特定の要件に合わせてカスタマイズできます。次の表は、既存の技術スタックと業務の進め方に応じて必要となる可能性のある一般的なバリエーションの一部を示しています。

決定分野 代替策

組織: このブループリントでは、すべてのリソースのルートノードとして単一の組織を使用します。

Google Cloud ランディング ゾーンのリソース階層を決定するでは、次のような複数の組織を選択するシナリオが紹介されています。

  • 組織に、今後売り出されたり、完全に独立したエンティティとして運営されたりする可能性のあるサブ会社が含まれている。
  • 既存の組織に接続しないサンドボックス環境でテストする必要がある。

フォルダ構造: このブループリントはシンプルなフォルダ構造を持ち、ワークロードは最上位のレイヤで production, non-production、development フォルダに分割されます。

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: このブループリントは、組織全体のシークレット用の common フォルダに Secret Manager を使用するためのプロジェクトを 1 つデプロイし、環境固有のシークレット用の各環境フォルダそれぞれにプロジェクトを 1 つデプロイします。

組織全体で機密性の高いシークレットの管理と監査を担当する単一のチームがある場合は、シークレットへのアクセスの管理に単一のプロジェクトのみを使用することをおすすめします。

各ワークロード チームが独自のシークレットを管理できるようにする場合は、一元化されたプロジェクトを使用してシークレットへのアクセスを管理するのではなく、各チームがワークロード プロジェクトで独自の Secret Manager インスタンスを使用できるようにすることもできます。

Cloud KMS: このブループリントは、組織全体の鍵用の common フォルダに Cloud KMS を使用するためのプロジェクトをデプロイし、各環境の鍵用の各環境フォルダにプロジェクトをデプロイします。

組織全体で暗号鍵の管理と監査を担当する単一のチームがある場合は、鍵へのアクセスの管理に単一のプロジェクトのみを使用することをおすすめします。一元化されたアプローチは、PCI 鍵管理者などのコンプライアンス要件を満たすのに役立ちます。

ワークロード チームが独自の鍵を管理できるようにする場合は、一元化されたプロジェクトを使用して鍵へのアクセスを管理するのではなく、各チームがワークロード プロジェクトで独自の Cloud KMS インスタンスを使用できるようにすることもできます。

集約されたログシンク: このブループリントは、組織ノードに一連のログシンクを構成して、中央のセキュリティ チームが組織全体の監査ログを確認できるようにします。

ビジネスの部門ごとに監査を担当する複数のチームがあり、各チームがそれぞれの業務で別々のログを必要とすることもあります。このような場合は、適切なフォルダとプロジェクトで複数の集約されたシンクを設計し、各チームが必要なログのみを受け取るようにフィルタを作成するか、共通のログバケットに対してきめ細かくアクセス制御できるログビューを設計します。

インフラストラクチャ パイプラインの粒度: このブループリントは、各ビジネス ユニットが個別のインフラストラクチャ パイプラインを持ち、ワークロード プロジェクトを管理するモデルを使用します。

すべてのプロジェクトとインフラストラクチャのデプロイを担当する中央チームがある場合は、中央チームが管理する単一のインフラストラクチャ パイプラインを選択することもできます。この中央チームは、ワークロード チームからの pull リクエストを受け入れて、プロジェクトを作成する前に確認して承認することができます。また、チケット制システムに応じて、チーム自体が pull リクエストを作成することもできます。

個々のワークロード チームが独自のパイプラインをカスタマイズできる場合で、パイプラインに対する詳細な権限が付与されたサービス アカウントを設計する場合は、より粒度の細かいパイプラインを選択することもできます。

SIEM エクスポート: ブループリントは、すべてのセキュリティ検出結果を Security Command Center で管理します。

セキュリティ検出結果は、Security Command Center から Google Security Operations や既存の SIEM などのツールにエクスポートすることもできますが、チームがコンソールを使用してセキュリティ検出結果を表示および管理することもできます。また、スコープと責任が異なる固有のフィルタをチームごとに使用して、複数のエクスポートを構成することもできます。

オンプレミスからの Google Cloud サービスの DNS ルックアップ: このブループリントは、共有 VPC ごとに一意の Private Service Connect エンドポイントを構成します。これにより、複数の VPC Service Controls の境界を使用した設計が可能になります。

複数の VPC Service Controls の境界を必要としない場合は、オンプレミス環境から Private Service Connect エンドポイントに対して、この粒度でルーティングを行う必要がない場合もあります。

環境ごとにオンプレミス ホストを Private Service Connect エンドポイントにマッピングする代わりに、適切な API バンドルを含む単一の Private Service Connect エンドポイントを使用するか、private.googleapis.com と restricted.googleapis.com の汎用のエンドポイントを使用して設計を簡素化することもできます。

次のステップ