ランディング ゾーンのデプロイ プロセスは、ステージで構成されます。各ステージで、terraform.tfvars ファイルに特定の変数を追加する必要があります。ステージが完了すると、Terraform は最初のステージで作成された Cloud Storage バケットに STAGE_NAME-tfvar.auto.tfvars.json ファイルを書き込みます。後続のステージでは、Google Cloud CLI を使用して、ステージ固有のサービス アカウントを代行するファイルとプロバイダ ファイルを新しいステージ フォルダにコピーします。
テナントの数に応じて、新しい環境のデプロイには約 1 時間かかります。
前提条件
Stellar Engine をデプロイする前に、次のタスクを完了します。
Google Cloudを設定する
Google Cloudを設定する手順は次のとおりです。
Google Cloud 組織を選択します。新しい組織を作成した場合は、Google 管理コンソールに少なくとも 1 回ログインします。
複数の管理者を構成して職務分離を実装します。テスト環境では、1 人のユーザーがすべてのリソースの管理者ロールを持つことがあります。ただし、本番環境では複数の管理者が必要です。詳細については、組織リソースを設定するをご覧ください。
すべての特権アカウントで 2 段階認証を有効にします。
Cloud Shell を無効にする。Cloud Shell は IL4 環境または IL5 環境ではサポートされていません。Google Workspace 管理者が無効にする必要があります。
プロジェクトがない場合は、ブートストラップ プロジェクトを作成します。
ブートストラップ プロジェクトで次のタスクを完了します。
課金を有効にします。手順については、プロジェクトの課金ステータスを確認するをご覧ください。
Cloud Monitoring API を有効にします。
API を有効にするために必要なロール
API を有効にするには、
serviceusage.services.enable権限が必要です。プロジェクトを作成した場合は、オーナーロール(roles/owner)を介してこの権限がすでに付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール(roles/serviceusage.serviceUsageAdmin)を介してこの権限を取得できます。ロールを付与する方法をご覧ください。
ユーザー アカウントが特権管理者であることを確認します。
組織にデータ分類スキームがない場合は、作成します。
ロールを割り当てる
Stellar Engine をデプロイするユーザー アカウントに、次の Identity and Access Management ロールを割り当てます。
-
組織に次のロールが付与されていることを確認します。アクセスの透明性管理者、Assured Workloads 管理者、請求先アカウント管理者、ロギング管理者、組織管理者、組織ポリシー管理者、組織ロール管理者、オーナー、プロジェクト作成者、サービス アカウント管理者、サービス アカウント トークン作成者、タグ管理者
ロールを確認する
-
Google Cloud コンソールで、[IAM] ページに移動します。
IAM に移動 - 組織を選択します。
-
[プリンシパル] 列で、自分または自分が所属するグループの行をすべて確認します。所属するグループについては、管理者にお問い合わせください。
- 自分のメールアドレスを含む行の [ロール] 列で、ロールのリストに必要なロールが含まれているかどうか確認します。
ロールを付与する
-
Google Cloud コンソールで、[IAM] ページに移動します。
IAM に移動 - 組織を選択します。
- [ アクセスを許可] をクリックします。
-
[新しいプリンシパル] フィールドに、ユーザー ID を入力します。 これは通常、Google アカウントのメールアドレスです。
- [ロールを選択] をクリックし、ロールを検索します。
- 追加のロールを付与するには、 [別のロールを追加] をクリックして各ロールを追加します。
- [保存] をクリックします。
-
新しい組織で開始する場合は、fast/stages-aw/0-bootstrap フォルダにある次のスクリプトを実行して、ロールを適用できます。
./setIAM.sh EMAIL_ADDRESS ORGANIZATION_ID
次のように置き換えます。
EMAIL_ADDRESS: ユーザー アカウントのメールアドレス。ORGANIZATION_ID: 組織の ID。
このスクリプトは、請求先アカウント管理者と特権管理者を除くすべてのロールを追加します。
グループを追加してサービスを構成する
-
gcp-billing-admins@DOMAINgcp-developers@DOMAINgcp-devops@DOMAINgcp-hybrid-connectivity-admins@DOMAINgcp-logging-monitoring-admins@DOMAINgcp-logging-monitoring-viewers@DOMAINgcp-organization-admins@DOMAINgcp-vpc-network-admins@DOMAINgcp-security-admins@DOMAIN
DOMAINは、実際の FQDN に置き換えます。プロンプトが表示されたら、ID プロバイダの手順をスキップします。
Google はデフォルトのグループ名を変更する場合があります。グループが設定ガイドにない場合は、手動で作成できます。
Assured Workloads、BigQuery、Cloud Billing、Cloud Logging、Cloud KMS、IAM、Pub/Sub、Resource Manager、Service Account Credentials、Service Usage、組織ポリシー サービス API を有効にします。
API を有効にするために必要なロール
API を有効にするには、
serviceusage.services.enable権限が必要です。プロジェクトを作成した場合は、オーナーロール(roles/owner)を介してこの権限がすでに付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール(roles/serviceusage.serviceUsageAdmin)を介してこの権限を取得できます。ロールを付与する方法をご覧ください。割り当てが 13 個のプロジェクト未満の場合は、Google Cloud Platform/API プロジェクト: 請求割り当ての増加をリクエストするに移動して、13 個のプロジェクトをリクエストします。詳細については、割り当ての表示と管理をご覧ください。
fast/stages-aw/0-bootstrap/enableServices.sh スクリプトを使用してサービスを有効にすることもできます。
ローカル環境を設定する
ローカル環境を構成するには、次の手順を行います。
- Stellar Engine GitHub リポジトリのクローンを作成します。
- Google Cloud SDK をインストールする。
- ローカルの Terraform を 1.8.1 以降のバージョンに更新します。
- jq バイナリをインストールします。
認証を行い、ブートストラップ プロジェクトをアクティブなプロジェクトとして設定します。
gcloud auth login gcloud config set project BOOTSTRAP_PROJECT_ID gcloud auth application-default login
モジュールを変更する
ほとんどの場合、リポジトリは変更せずに使用できます。モジュールを変更する必要がある場合は、モジュール全体をコピーし、命名規則 <module-se> を使用して、Cloud Foundation ファブリック リポジトリから定期的な更新がプルされたときにマージの競合が発生しないようにします。
ステージ 0: ブートストラップを実行する
ステージ 0 では、ネットワークの既存の部分を Terraform の状態に合わせます。ステージ 0 では、初期の IaC ブートストラップ サービス アカウントとプロジェクトが作成されます。ステージ 0 は、ユーザーが最初に持っているプロジェクトから新しいコア プロジェクトに移行し、Terraform 状態を移行するように設計されています。
ディレクトリを
fast/stages-aw/0-bootstrapに変更します。terraform.tfvars.sampleファイルをコピーします。cp terraform.tfvars.sample terraform.tfvarsproviders.tf.tmpファイルを0-bootstrap-providers.tfファイルにコピーします。cp providers.tf.tmp 0-bootstrap-providers.tffast/stages-aw/0-bootstrap/terraform.tfvarsの情報を更新します。billing_account = { id = "BILLING_ACCOUNT_ID" } regions = { primary = "REGION" } organization = { domain = "DOMAIN" id = "ORGANIZATION_ID" customer_id = "CUSTOMER_ID" } outputs_location = "~/fast-config" prefix = "PREFIX" log_sinks = { audit-logs = { filter = "logName:\"/logs/cloudaudit.googleapis.com%2Factivity\" OR logName:\"/logs/cloudaudit.googleapis.com%2Fsystem_event\" OR protoPayload.metadata.@type=\"type.googleapis.com/google.cloud.audit.TransparencyLog\"" type = "logging" } vpc-sc = { filter = "protoPayload.metadata.@type=\"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata\"" type = "logging" } workspace-audit-logs = { filter = "logName:\"/logs/cloudaudit.googleapis.com%2Fdata_access\" and protoPayload.serviceName:\"login.googleapis.com\"" type = "logging" } empty-audit-logs = { filter = "" type = "logging" } } org_policies_config = { constraints = { "ALLOWED_POLICY_MEMBER_DOMAINS" = [] } } fast_features = { envs = true } assured_workloads = { regime = "COMPLIANCE_REGIME" location = "LOCATION" } bootstrap_project = "BOOTSTRAP_PROJECT_ID" alert_email = "ALERT_EMAIL"次のように置き換えます。
BILLING_ACCOUNT_ID: 環境のデプロイに使用する請求先アカウント。請求先アカウントの情報を確認するには、 Google Cloud コンソールをご覧ください。REGION: リソースをデプロイするプライマリ リージョン。IL5 と FedRAMP のデフォルトはus-east4です。リソースをデプロイするセカンダリ リージョンを追加するには、
secondary=secondaryを追加します。DOMAIN: 完全修飾ドメイン名(FQDN)。FQDN を表示するには、gcloud organizations listを実行します。ORGANIZATION:Google Cloud 組織の組織 ID。組織 ID を表示するには、gcloud organizations listを実行します。CUSTOMER_ID: Google Workspace ディレクトリの顧客 ID。ID を表示するには、gcloud organizations listを実行します。PREFIX: デプロイされるプロジェクトとリソースの名前に付加する接頭辞。プロジェクト名はグローバルに一意である必要があり、接頭辞は 6 文字以内で指定する必要があります。プロジェクト名が一意でない場合、409 エラーが発生します。ALLOWED_POLICY_MEMBER_DOMAINS: 必要に応じて、追加のお客様 ID で更新します。詳細については、ドメイン制限付き共有で ID を制限するをご覧ください。COMPLIANCE_REGIME: この環境のコンプライアンス体制。IL4、IL5、FEDRAMP_HIGH、COMPLIANCE_REGIME_UNSPECIFIEDのいずれか。Assured Workloads を使用しない場合は、この値をCOMPLIANCE_REGIME_UNSPECIFIEDに設定します。LOCATION: リソースをデプロイする米国のリージョン。NAM9などのデュアル リージョンや大陸はサポートされていません。BOOTSTRAP_PROJECT_ID: Google Cloudを設定するで作成したブートストラップ プロジェクト ID。ALERT_EMAIL: ロギング アラート通知の送信先メールアドレス。
terraform initを実行します。terraform applyを実行します。terraform apply -var bootstrap_user=$(gcloud config list --format 'value(core.account)')プロンプトが表示されたら、「
yes」と入力します。新しいプロジェクトに切り替えます。
gcloud config set project PREFIX-prod-iac-core-0新しいローカル Terraform プロバイダ ファイルをコピーします。
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/0-bootstrap-providers.tf ./状態をローカルからリモートに移行します。
terraform init --migrate-stateプロンプトが表示されたら、「
yes」と入力します。./import.shを実行します。terraform applyをもう一度実行します。プロンプトが表示されたら、「yes」と入力します。
ステージ 1: リソース管理を実行する
ステージ 1 では、後続のステージで使用されるさまざまなフォルダ、プロジェクト、サービス アカウントが組織レベルで作成されます。環境を作成するには、fast/stages-aw/1-resman の terraform.tfvars ファイルを更新して、tenants 変数を含める必要があります。各テナント(特定の連邦機関や内部開発グループなど)には、ワークロードを実行するための専用の分離された境界が割り当てられます。各テナントは、ステージ 0 とステージ 2 で作成された一元化されたセキュリティ制御、ネットワーク境界、ポリシー ガードレール、監査ログシンクを継承します。
外部請求先アカウントを使用している場合は、外部請求先アカウントを使用する場合の課金を設定するをご覧ください。
ディレクトリを
fast/stages-aw/1-resmanに変更します。terraform.tfvars.sampleファイルをコピーします。cp terraform.tfvars.sample terraform.tfvarsterraform.tfvarsを次のように更新します。tenants = { ten-1 = { admin_principal = "group:gcp-devops@DOMAIN" descriptive_name = "TENANT_ONE_NAME" locations = { gcs = "REGION" kms = "REGION" } }, ten-2 = { admin_principal = "group:gcp-devops@DOMAIN" descriptive_name = "TENANT_TWO_NAME" locations = { gcs = "REGION" kms = "REGION" } } } fast_features = { envs = true } envs_folders = { Prod = { admin = "gcp-organization-admins@DOMAIN" }, Int = { admin = "gcp-organization-admins@DOMAIN" }, Test = { admin = "gcp-organization-admins@DOMAIN" } }次のように置き換えます。
DOMAIN: プライマリ完全修飾ドメイン名(FQDN)。FQDN を表示するには、gcloud organizations listを実行します。TENANT_ONE_NAME: デプロイされる最初のテナント プロジェクトの名前。最大 6 文字を使用します。REGION: リソースをデプロイするプライマリ リージョン。IL5 と FedRAMP のデフォルトはus-east4です。TENANT_TWO_NAME: デプロイされる 2 番目のテナント プロジェクトの名前。最大 6 文字を使用します。
必要な数のテナント定義を追加します。
Cloud Storage から
tfvarsファイルをコピーします。gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/1-resman-providers.tf ./ && gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-globals.auto.tfvars.json ./ && gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./terraform initを実行します。terraform applyを実行します。プロンプトが表示されたら、「yes」と入力します。
ステージ 2: ネットワークの作成を実行する
ステージ 2 には、FedRAMP High 用と IL4 または IL5 用の 2 つのネットワーキング オプションがあります。
FedRAMP High のネットワークを構成する
外部請求先アカウントを使用している場合は、外部請求先アカウントを使用する場合の課金を設定するをご覧ください。
ディレクトリを
fast/stages-aw/2-networking-a-fedramp-highに変更します。Cloud Storage バケットからプロバイダとグローバルの tfvars ファイルをコピーします。
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/2-networking-providers.tf ./ && \ gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-globals.auto.tfvars.json ./ && \ gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./ && \ gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./terraform.tfvars.sampleファイルをコピーします。cp terraform.tfvars.sample terraform.tfvarsterraform.tfvarsファイルで、カスタム サブネット、プロキシ サブネット、ファイアウォール ルール、名前付き CIDR、DNS レスポンス ポリシー ルールを更新します。terraform initを実行します。terraform applyを実行します。プロンプトが表示されたら、「yes」と入力します。
IL4 または IL5 のネットワーキングを構成する
このステップでは、Palo Alto VM シリーズの次世代ファイアウォール(NGFW)のペアをネットワーク アカウントにデプロイします。NGFW は BYOL(Bring Your Own License)デプロイ イメージを使用します。Palo Alto コンソールを使用して VM コードをアップロードし、登録する必要があります。その他の手順については、2-networking-b-il5-ngfw ステージ フォルダの README をご覧ください。
外部請求先アカウントを使用している場合は、外部請求先アカウントを使用する場合の課金を設定するをご覧ください。
ディレクトリを
fast/stages-aw/2-networking-b-il5-ngfwに変更します。Cloud Storage バケットからプロバイダとグローバルの tfvars ファイルをコピーします。
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/2-networking-providers.tf ./ && \ gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-globals.auto.tfvars.json ./ && \ gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./ && \ gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./terraform.tfvars.sampleファイルをコピーします。cp terraform.tfvars.sample terraform.tfvarsterraform.tfvarsファイルで、カスタム サブネット(mgmt を含む)、プロキシ サブネット、ファイアウォール ルール、名前付き CIDR、DNS レスポンス ポリシー ルールを更新します。terraform initを実行します。terraform applyを実行します。プロンプトが表示されたら、「yes」と入力します。サービス アカウントまたは Cloud Key Management Service が存在しないというエラーが表示された場合は、コンソールで
PREFIX-net-vdss-hostストレージ アカウントの [設定] をクリックします。サービス アカウントが生成されます。
ステージ 3: セキュリティと監査のアカウント構成を実行する
ステージ 3 では、セキュリティ プロジェクトと監査プロジェクトを構成します。セキュリティ プロジェクト(prod-sec-core-0)には Cloud KMS が含まれており、Secret Manager を含めることもできます。IL5 では、Compute Engine、Google Kubernetes Engine(GKE)、Cloud Storage、Cloud SQL で CMEK がデフォルトで有効になっています。次の組織のポリシーの制約が適用されます。
gcp.restrictNonCmekServices:denied_values: "compute.googleapis.com"denied_values: "container.googleapis.com"denied_values: "storage.googleapis.com"denied_values: "sqladmin.googleapis.com"
gcp.restrictCmekCryptoKeyProjects:gcp.restrictCmekCryptoKeyProjectsには、CMEK を使用できるプロジェクトのリストが含まれます。
prod-sec-core-0 プロジェクトでは、次の項目が構成されています。
- Cloud KMS 制限付き管理者は、他のサービスに復号権限を付与できるように、制限付き管理者ロールが付与されます。
- 異なるロケーションに Cloud KMS キーリングがプロビジョニングされます。キーリングのロケーションは、サービスのロケーションと一致している必要があります。たとえば、マルチリージョン キーリングを単一リージョンのストレージ バケットで使用することはできません。
監査プロジェクトには、監査ログ用のロギング バケットが含まれています。
セキュリティ管理者はセキュリティ プロジェクトを担当し、監査担当者は監査プロジェクトを担当します。
外部請求先アカウントを使用している場合は、外部請求先アカウントを使用する場合の課金を設定するをご覧ください。
ディレクトリを
fast/stages-aw/3-securityに変更します。Cloud Storage バケットから構成ファイルをコピーします。
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/3-security-providers.tf ./ && gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-globals.auto.tfvars.json ./ && gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./ && gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./terraform initを実行します。terraform applyを実行します。プロンプトが表示されたら、「yes」と入力します。サービス アカウントで問題が発生した場合は、
terraform applyを再実行します。./sa_lockdown.shを実行して、デプロイ中に使用したサービス アカウントを無効にします。
外部の請求先アカウントを使用する場合の課金を構成する
外部の請求先アカウントを使用している場合は、次のサービス アカウントに請求先アカウント管理者のロールを追加する必要があります。
PREFIX-prod-resman-0@PREFIX-prod-iac-core-0.iam.gserviceaccount.com: このアカウントはステージ 0 で作成されます。PREFIX-prod-resman-net-0@PREFIX-prod-iac-core-0.iam.gserviceaccount.com: このサービス アカウントはステージ 1 で作成されます。PREFIX-security-0@PREFIX-prod-iac-core-0.iam.gserviceaccount.com: このサービス アカウントはステージ 2 で作成されます。
これらのサービス アカウントにロールを追加するには、Cloud 請求先アカウントの [権限] パネルにアクセスすると[権限] パネルでロールとプリンシパルを更新するの手順を完了します。
テナント プロジェクトを変更する
既存の Stellar Engine デプロイにテナント プロジェクトを追加または削除する手順は次のとおりです。
認証してアクティブなプロジェクトを設定します。
gcloud auth login gcloud config set project PREFIX-prod-iac-core-0 gcloud auth application-default loginステージのサービス アカウントを有効にします。
ディレクトリを
fast/stages-aw/3-securityに変更します。./sa_lockdown.sh --enableを実行します。
ステージ 1 を適用する:
ディレクトリを
fast/stages-aw/1-resmanに変更します。terraform.tfvarsの情報を新しい要件に合わせて更新します。terraform initを実行します。terraform applyを実行します。プロンプトが表示されたら、「yes」と入力します。
ステージ 2 を適用する:
次のいずれかのネットワーク フォルダにディレクトリを変更します。
Cloud Storage バケットから
1-resmantfvars ファイルをコピーします。
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./terraform initを実行します。terraform applyを実行します。プロンプトが表示されたら、「yes」と入力します。
ステージのサービス アカウントを無効にします。
ディレクトリを
fast/stages-aw/3-securityに変更します。./sa_lockdown.shを実行します。
トラブルシューティング
このセクションでは、一般的なエラーとその解決策について説明します。
ステージ 1 で BigQuery を使用できないエラーが発生する
Assured Workloads で bigquery.googleapis.com を使用できないというエラーが表示された場合は、次の操作を行います。
コンソールで、[Assured Workloads] ページに移動します。
該当する場合は、
StellarEngine-COMPLIANCE_REGIMEフォルダと Networking フォルダを選択します。[利用可能なアップデートを確認] をクリックします。
[許可されたサービス] に移動します。
[サービスを許可] をクリックして、BigQuery API を追加します。
プロンプトが表示されたら、[はい] をクリックして選択を確定します。
2 分ほど待ってから、
terraform applyを再実行します。terraform apply -var bootstrap_user=$(gcloud config list --format 'value(core.account)')プロンプトが表示されたら、「
yes」と入力します。
ブートストラップ プロジェクトが請求先アカウントにアクセスできなくなる
ブートストラップ プロジェクトが請求先アカウントにアクセスできなくなった場合は、ブートストラップ プロジェクトの課金を再度有効にします。
Cloud KMS 鍵のエラー
ビルドプロセス中にキーエラーが発生した場合は、キーを手動で有効にする必要がある場合があります。手順については、鍵バージョンを有効にするをご覧ください。
これらのエラーが発生した場合は、1 分ほど待ってから terraform apply を再実行します。
Windows パソコンでシンボリック リンクが機能しない
Windows パソコンでは、シンボリック リンクが機能しない場合があります。特定のファイル(特にステージ 2 の psc.tf と log-metric-alerts.tf)を手動でコピーする必要がある場合があります。
課金または割り当てに関する問題
課金または割り当てに関する問題が発生した場合は、割り当てプロジェクトが設定されていることを確認します。設定するには、次のコマンドを実行します。
gcloud auth application-default set-quota-project PREFIX-prod-iac-core-0
必要に応じて、別のプロジェクトを使用できます。
次のステップ
追加のセキュリティ構成については、Gemini のセキュリティ標準をご覧ください。
Google Security Operations などの SIEM ソリューションを統合して、リソースをモニタリングします。SIEM を別の Google Cloud プロジェクトと、データ収集元とは別の VPC に分割します。