このドキュメントでは、 Google Cloudに基本的なリソース一式をデプロイするためのベスト プラクティスについて説明します。クラウドの基盤とは、企業がビジネスニーズに合わせてGoogle Cloud を導入するためのリソース、構成、機能のベースラインのことです。適切に設計された基盤により、環境内のすべてのワークロードで、共有サービスに対する一貫したガバナンス、セキュリティ管理、スケール、可視性、アクセスが可能になります。 Google Cloud このドキュメントで説明するコントロールとガバナンスをデプロイしたら、 Google Cloudにワークロードをデプロイできます。
エンタープライズ基盤ブループリント（旧セキュリティ基盤ブループリント）は、 Google Cloud上でエンタープライズ向けの環境設計を担当するアーキテクト、セキュリティ担当者、プラットフォーム エンジニアリング チームを対象としています。このブループリントは次の内容で構成されています。
Google のベスト プラクティスに基づく完全な基盤を構築する。このガイドのすべての推奨事項を出発点としてデプロイし、ビジネス固有の要件に合わせて環境をカスタマイズできます。
Google Cloudの既存の環境を確認する。Google が推奨するベスト プラクティスに照らして設計の特定のコンポーネントを比較できます。
サポートされるユースケース
エンタープライズ基盤ブループリントは、 Google Cloudであらゆるタイプのワークロードを可能にするリソースと構成のベースライン レイヤを実現します。既存のコンピューティング ワークロードを Google Cloud に移行する場合、コンテナ化されたウェブ アプリケーションの構築する場合、ビッグデータと ML ワークロードを作成する場合のいずれにおいても、エンタープライズ基盤ブループリントを使用することで、エンタープライズ ワークロードを大規模にサポートする環境を構築できます。 Google Cloud
Google Cloud サービスは、基盤となる Google インフラストラクチャのセキュリティ設計から恩恵を受けています。 Google Cloud上に構築するシステムへのセキュリティを設計するのはお客様の責任です。エンタープライズ基盤ブループリントは、サービスとワークロードに多層防御のセキュリティ モデルを実装するうえで役立ちます。 Google Cloud
Cloud Identity: ユーザーとグループ メンバーシップは、既存の ID プロバイダから同期されます。ユーザー アカウントのライフサイクル管理とシングル サインオン（SSO）の制御は、ID プロバイダの既存の制御とプロセスに依存します。
Identity and Access Management（IAM）: 許可ポリシー（旧 IAM ポリシー）はリソースへのアクセス権を許可するものであり、職務に基づいてグループに適用されます。ユーザーは適切なグループに追加され、基盤リソースに対する閲覧権限が付与されます。基盤リソースに対する変更は,、すべて特権サービス アカウント ID を使用する CI / CD パイプラインを介してデプロイされます。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-05-15 UTC。"],[],[],null,["# Enterprise foundations blueprint\n\nThis document describes the best practices that let you deploy a foundational\nset of resources in Google Cloud. A cloud foundation is the baseline of\nresources, configurations, and capabilities that enable companies to adopt\nGoogle Cloud for their business needs. A well-designed foundation enables\nconsistent governance, security controls, scale, visibility, and access to\nshared services across all workloads in your Google Cloud environment. After you\ndeploy the controls and governance that are described in this document, you can\ndeploy workloads to Google Cloud.\n\nThe *enterprise foundations blueprint* (formerly known as the *security\nfoundations blueprint*) is intended for architects, security practitioners, and\nplatform engineering teams who are responsible for designing an enterprise-ready\nenvironment on Google Cloud. This blueprint consists of the following:\n\n- A [terraform-example-foundation GitHub\n repository](https://github.com/terraform-google-modules/terraform-example-foundation) that contains the deployable Terraform assets.\n- A guide that describes the architecture, design, and controls that you implement with the blueprint (this document).\n\nYou can use this guide in one of two ways:\n\n- To create a complete foundation based on Google's best practices. You can deploy all the recommendations from this guide as a starting point, and then customize the environment to address your business' specific requirements.\n- To review an existing environment on Google Cloud. You can compare specific components of your design against Google-recommended best practices.\n\nSupported use cases\n-------------------\n\nThe enterprise foundation blueprint provides a baseline layer of resources and\nconfigurations that help enable all types of workloads on Google Cloud.\nWhether you're migrating existing compute workloads to Google Cloud,\nbuilding containerized web applications, or creating big data and machine\nlearning workloads, the enterprise foundation blueprint helps you build your\nenvironment to support enterprise workloads at scale.\n\nAfter you deploy the enterprise foundation blueprint, you can deploy workloads\ndirectly or deploy additional blueprints to support complex workloads that\nrequire additional capabilities.\n\nA defense-in-depth security model\n---------------------------------\n\nGoogle Cloud services benefit from the underlying\n[Google infrastructure security design](/docs/security/infrastructure/design).\nIt is your responsibility to design security into the systems that you build on\ntop of Google Cloud. The enterprise foundation blueprint helps you to\nimplement a defense-in-depth security model for your Google Cloud services\nand workloads.\n\nThe following diagram shows a defense-in-depth security model for your\nGoogle Cloud organization that combines architecture controls, policy\ncontrols, and detective controls.\n\nThe diagram describes the following controls:\n\n- **Policy controls** are programmatic constraints that enforce acceptable resource configurations and prevent risky configurations. The blueprint uses a combination of policy controls including infrastructure-as-code (IaC) validation in your pipeline and organization policy constraints.\n- **Architecture controls** are the configuration of Google Cloud resources like networks and resource hierarchy. The blueprint architecture is based on security best practices.\n- **Detective controls** let you detect anomalous or malicious behavior within the organization. The blueprint uses platform features such as Security Command Center, integrates with your existing detective controls and workflows such as a security operations center (SOC), and provides capabilities to enforce custom detective controls.\n\nKey decisions\n-------------\n\nThis section summarizes the high-level architectural decisions of the\nblueprint.\n\nThe diagram describes how Google Cloud services contribute to key\narchitectural decisions:\n\n- **Cloud Build:** Infrastructure resources are managed using a GitOps model. Declarative IaC is written in Terraform and managed in a version control system for review and approval, and resources are deployed using Cloud Build as the continuous integration and continuous deployment (CI/CD) automation tool. The pipeline also enforces policy-as-code checks to validate that resources meet expected configurations before deployment.\n- **Cloud Identity:** Users and group membership are synchronized from your existing identity provider. Controls for user account lifecycle management and single sign-on (SSO) rely on the existing controls and processes of your identity provider.\n- **Identity and Access Management (IAM):** Allow policies (formerly known as IAM policies) allow access to resources and are applied to groups based on job function. Users are added to the appropriate groups to receive view-only access to foundation resources. All changes to foundation resources are deployed through the CI/CD pipeline which uses privileged service account identities.\n- **Resource Manager:** All resources are managed under a single organization, with a resource hierarchy of folders that organizes projects by environments. Projects are labeled with metadata for governance including cost attribution.\n- **Networking** : Network topologies use Shared VPC to provide network resources for workloads across multiple [regions](/docs/geography-and-regions#regions_and_zones) and zones, separated by environment, and managed centrally. All network paths between on-premises hosts, Google Cloud resources in the VPC networks, and Google Cloud services are private. No outbound traffic to or inbound traffic from the public internet is permitted by default.\n- **Cloud Logging**: Aggregated log sinks are configured to collect logs relevant for security and auditing into a centralized project for long-term retention, analysis, and export to external systems.\n- **Organization Policy Service:** Organization policy constraints are configured to prevent various high-risk configurations.\n- **Secret Manager:** Centralized projects are created for a team responsible for managing and auditing the use of sensitive application secrets to help meet compliance requirements.\n- **Cloud Key Management Service (Cloud KMS):** Centralized projects are created for a team responsible for managing and auditing encryption keys to help meet compliance requirements.\n- **Security Command Center:** Threat detection and monitoring capabilities are provided using a combination of built-in security controls from Security Command Center and custom solutions that let you detect and respond to security events.\n\nFor alternatives to these key decisions, see\n[alternatives](/architecture/blueprints/security-foundations/summary#alternatives).\n\nWhat's next\n-----------\n\n- Read about [authentication and\n authorization](/architecture/blueprints/security-foundations/authentication-authorization) (next document in this series)."]]