This principle in the security pillar of theGoogle Cloud Well-Architected Framework provides recommendations to incorporate robust security features, controls, andpractices into the design of your cloud applications, services, and platforms.From ideation to operations, security is more effective when it's embedded as anintegral part of every stage of your design process.

Principle overview

As explained inAn Overview of Google's Commitment to Secure by Design,secure by default andsecure by design are often used interchangeably, butthey represent distinct approaches to building secure systems. Both approachesaim to minimize vulnerabilities and enhance security, but they differ in scopeand implementation:

• Secure by default: focuses on ensuring that a system's defaultsettings are set to a secure mode, minimizing the need for users oradministrators to take actions to secure the system. This approach aims toprovide a baseline level of security for all users.
• Secure by design: emphasizes proactively incorporating securityconsiderations throughout a system's development lifecycle. This approachis about anticipating potential threats and vulnerabilities early andmaking design choices that mitigate risks. This approach involves usingsecure coding practices, conducting security reviews, and embeddingsecurity throughout the design process. The secure-by-design approach is anoverarching philosophy that guides the development process and helps to ensurethat security isn't an afterthought but is an integral part of a system's design.

Recommendations

To implement the secure by design principle for your cloud workloads, considerthe recommendations in the following sections:

• Choose system components that help to secure your workloads
• Build a layered security approach
• Use hardened and attested infrastructure and services
• Encrypt data at rest and in transit

Choose system components that help to secure your workloads

This recommendation is relevant to all of thefocus areas.

A fundamental decision for effective security is the selection of robust systemcomponents—including both hardware and software components—that constituteyour platform, solution, or service. To reduce the security attack surface andlimit potential damage, you must also carefully consider the deployment patternsof these components and their configurations.

In your application code, we recommend that you use straightforward, safe, andreliable libraries, abstractions, and application frameworks in order to eliminateclasses of vulnerabilities. To scan for vulnerabilities in software libraries,you can use third-party tools. You can also useAssured Open Source Software,which helps to reduce risks to your software supply chain by using open sourcesoftware (OSS) packages that Google uses and secures.

Your infrastructure must use networking, storage, and compute options thatsupport safe operation and align with your security requirements and riskacceptance levels. Infrastructure security is important for both internet-facingand internal workloads.

For information about other Google solutions that support this recommendation,seeImplement shift-left security.

Build a layered security approach

This recommendation is relevant to the followingfocus areas:

• AI and ML security
• Infrastructure security
• Identity and access management
• Data security

We recommend that you implement security at each layer of your application andinfrastructure stack by applying a defense-in-depth approach.

Use the security features in each component of your platform. To limit accessand identify the boundaries of the potential impact (that is, theblast radius)in the event of a security incident, do the following:

• Simplify your system's design to accommodate flexibility where possible.
• Document the security requirements of each component.
• Incorporate a robust secured mechanism to address resiliency and recoveryrequirements.

When you design the security layers, perform a risk assessment to determine thesecurity features that you need in order to meet internal security requirementsand external regulatory requirements. We recommend that you use anindustry-standard risk assessment framework that applies to cloud environmentsand that is relevant to your regulatory requirements. For example, the CloudSecurity Alliance (CSA) provides theCloud Controls Matrix (CCM).Your risk assessment provides you with a catalog of risks and correspondingsecurity controls to mitigate them.

When you perform the risk assessment, remember that you have a sharedresponsibility arrangement with your cloud provider. Therefore, your risks in acloud environment differ from your risks in an on-premises environment. Forexample, in an on-premises environment, you need to mitigate vulnerabilities toyour hardware stack. In contrast, in a cloud environment, the cloud providerbears these risks. Also, remember that the boundaries of shared responsibilitiesdiffer between IaaS, PaaS, and SaaS services for each cloud provider.

After you identify potential risks, you must design and create a mitigationplan that uses technical, administrative, and operational controls, as well ascontractual protections and third-party attestations. In addition, a threatmodeling method, such as theOWASP application threat modeling method,helps you to identify potential gaps and suggest actions to address the gaps.

Use hardened and attested infrastructure and services

This recommendation is relevant to all of thefocus areas.

A mature security program mitigates new vulnerabilities as described insecurity bulletins. The security program should also provide remediation to fixvulnerabilities in existing deployments and secure your VM and containerimages. You can use hardening guides that are specific to the OS and applicationof your images, as well as benchmarks like the one provided by theCenter of Internet Security (CIS).

If you use custom images for your Compute Engine VMs, you need to patch theimages yourself. Alternatively, you can use Google-providedcurated OS images,which are patched regularly. To run containers on Compute Engine VMs, useGoogle-curatedContainer-optimized OS images.Google regularly patches and updates these images.

If you use GKE, we recommend that you enablenode auto-upgrades so that Google updates your cluster nodes with the latest patches. Googlemanages GKE control planes, which are automatically updatedand patched. To further reduce the attack surface of your containers, you canusedistroless images.Distroless images are ideal for security-sensitive applications, microservices,and situations where minimizing the image size and attack surface isparamount.

For sensitive workloads, useShielded VM,which prevents malicious code from being loaded during the VM boot cycle.Shielded VM instances provide boot security, monitor integrity, and usetheVirtual Trusted Platform Module (vTPM).

To help secure SSH access,OS Login lets your employees connect to your VMs by usingIdentity and Access Management (IAM) permissions as the source of truth instead of relying on SSH keys. Therefore, you don't needto manage SSH keys throughout your organization. OS Login ties anadministrator's access to their employee lifecycle, so when employees changeroles or leave your organization, their access is revoked with their account. OSLogin also supportsGoogle two-factor authentication,which adds an extra layer of security against account takeover attacks.

In GKE, application instances run within Dockercontainers. To enable a defined risk profile and to restrict employees frommaking changes to containers, ensure that your containers are stateless andimmutable. The immutability principle means that your employees don't modify thecontainer or access it interactively. If the container must be changed, youbuild a new image and redeploy that image. Enable SSH access to the underlyingcontainers only in specific debugging scenarios.

To help globally secure configurations across your environment, you can useorganization policies to set constraints or guardrails on resources that affect the behavior of yourcloud assets. For example, you can define the following organization policiesand apply them either globally across a Google Cloud organization orselectively at the level of a folder or project:

• Disable external IP address allocation to VMs.
• Restrict resource creation to specific geographical locations.
• Disable the creation of Service Accounts or their keys.

Encrypt data at rest and in transit

This recommendation is relevant to the followingfocus areas:

• Infrastructure security
• Data security

Data encryption is a foundational control to protect sensitive information, andit's a key part ofdata governance.An effective data protection strategy includes access control, data segmentationand geographical residency, auditing,and encryption implementation that'sbased on a careful assessment of requirements.

By default, Google Cloudencrypts customer data that's stored at rest,with no action required from you. In addition to default encryption,Google Cloud provides options for envelope encryption and encryption keymanagement. You must identify the solutions that best fit your requirements forkey generation, storage, and rotation, whether you're choosing the keys for yourstorage, for compute, or for big data workloads. For example,Customer-managed encryption keys (CMEKs) can be created inCloud Key Management Service (Cloud KMS).The CMEKs can be either software-based orHSM-protected to meet your regulatory or compliance requirements, such as the need to rotateencryption keys regularly. Cloud KMS Autokey lets you automate theprovisioning and assignment of CMEKs. In addition, you can bring your own keysthat are sourced from a third-party key management system by usingCloud External Key Manager (Cloud EKM).

We strongly recommend that data be encrypted in-transit.Google encrypts and authenticates data in transit at one or more network layers when data moves outside physical boundaries thataren't controlled by Google or on behalf of Google. All VM-to-VM traffic withina VPC network and between peered VPC networks is encrypted. You can useMACsec for encryption of traffic over Cloud Interconnect connections. IPsec providesencryption for traffic overCloud VPN connections. You can protect application-to-application traffic in the cloud byusing security features likeTLS and mTLS configurations in Apigee andCloud Service Mesh for containerized applications.

By default, Google Cloud encrypts data at rest and data in transit acrossthe network. However, data isn't encrypted by default while it's in use inmemory. If your organization handles confidential data, you need to mitigate anythreats that undermine the confidentiality and integrity of either theapplication or the data in system memory. To mitigate these threats, you can useConfidential Computing, which provides a trusted execution environment for yourcompute workloads. For more information, seeConfidential VM overview.