Google Cloud Platform (GCP) is a suite of cloud computing services offered by Google. This guide explains the essential security best practices for your Google Cloud infrastructure that can be applied if you are planning to build on or migrate to GCP or if you are already using GCP in development or production.
Following industry guidelines for cloud safety is crucial for protecting data, applications, infrastructure, business continuity, compliance, and more. Banks and retail businesses have unique security requirements, which makes understanding your security objectives essential to help determine the appropriate protective measures.
Summary of GCP security best practices
Cloud security should be considered a shared responsibility between cloud providers such as Google Cloud and the customer, as described by the shared responsibility model. The table below lists some essential security-related best practices.
| Best practice | Description |
|---|---|
| Adopt the principle of least privilege access | The principle of least privilege access states that someone should only be granted the minimum permissions that are essential to perform their roles and responsibilities. |
| Implement strict security controls at all layers. | Strict security controls should be enforced at the infrastructure, networking, and application layers. |
| Implement a resource hierarchy | Organizational resources should be isolated to enhance security and controls. |
| Enforce security at the resource level | Secure each Google Cloud service at the resource level by implementing strict control access policies and following best practices. |
| Emphasize data security | Data in Google Cloud is already encrypted at rest; make sure that it is also encrypted in transit. |
| Prepare for attacks in advance | Regular security assessments and simulated incident response procedures help prepare for actual incidents. |
| Automate security operations wherever possible | Security operations should be automated to avoid any manual errors being introduced in response to an incident or vulnerability remediation action. |
| Proactively monitor, alert, and log | Proactive observability ensures the mitigation of security incidents before they even occur. |
Adopt the principle of least privilege access
Avoid using basic roles in production because they are overpowered with broader permissions; instead, use predefined or custom roles. You only need to resort to custom roles when the predefined ones are inadequate to fulfill your requirements.
Grant roles at the granular level to restrict the scope as permissions, roles, and policies are inherited by the child level. For example, if you assign the Compute Engine Administrator role to a user at the project level, that user would have the same access to all the compute engine resources in the project.
Restrict controls related to service account impersonation. Only privileged users should have the service account user and service account token creator roles assigned to them because such users are able to access all the resources to which the service account has access.
You can use just-in-time privileged access to grant temporary privileged access for a limited time, such as to troubleshoot a production incident. This can be implemented by deploying a separate app on Google Cloud or through a third-party tool such as Okta.
Finally, use conditional role bindings to revoke access after a specified date and time automatically. Shown below is an example of a conditional role binding that expires at noon on 12/31/23.
{
"bindings": [
{
"members": [
"user:[email protected]"
],
"role": "roles/owner"
},
{
"members": [
"user:[email protected]"
],
"role": "roles/iam.securityReviewer",
"condition": {
"title": "Expires_2023",
"description": "Expires at noon on 2023-12-31",
"expression":
"request.time < timestamp('2023-12-31T12:00:00Z')"
}
}
],
"etag": "BwWKmjvelug=",
"version": 3
}
Implement strict security controls at all layers
Application servers and databases should not have public IP addresses attached to them and should reside inside private subnets. NAT gateways should be used to route internet traffic from private subnets.
We recommend using identity and access management (IAM) along with uniform bucket-level access. Buckets should be kept private unless they need to be made public.
Strict virtual private cloud (VPC) firewall rules should be implemented to restrict access to necessary resources. For example, only the organization’s CIDR range should have access to SSH into the compute engine instances.
This image displays traffic flowing from outside the Google Cloud VPC to the VMs via firewall rules.
Implement a resource hierarchy
One of the main advantages of resource hierarchy is the ability to set access control policies and configuration settings at different levels within the hierarchy. This allows for centralized governance and the enforcement of consistent policies across projects, folders, and organizations.
An organization can be subdivided into multiple folders and subfolders and further isolated into multiple projects. The use of subfolders further enhances the resource hierarchy in GCP, allowing users to create nested levels of organization that enables more granular control over resources.
Applying IAM permissions to groups of users in GCP is more efficient and scalable than doing so for individual users. It simplifies administration, ensures consistency, enhances auditing, and strengthens security by adhering to the principle of least privilege.
For example, consider an engineering department within a company. The company may create a top-level folder for all engineering-related resources. Your GCP organization administrator can create subfolders within this folder representing engineering work for different departments, such as IT, HR, sales and so on. Each subfolder can have its projects for specific development, testing, and production environments. This hierarchical structure allows for easy management and visibility of resources, aligning with the organization’s operational requirements.
When designing the architecture to manage multiple environments, such as dev, test, and prod, it is recommended to isolate your infrastructure using multiple VPCs and subdivide those into multiple subnets to apply strict access control policies.
Centralized control can be achieved while delegating admin responsibilities with the help of Shared VPC.
The image shows a sample organization hierarchy in Google Cloud.
Enforce security at the resource level
Perform routine credential rotations for your GKE control plane to ensure that your SSL certificates, cluster certificate authority, and control plane IP addresses are continually rotated.
For Google Compute Engine (GCE) instances running sensitive workloads, shielded VMs can be used that safeguard your infrastructure from rootkits and bootkits. These VMs are security-hardened to protect you from many malicious and malware attacks.
Keep your GCP resources up to date with the latest security patches either by automatic upgrades or scheduled manual upgrades per your maintenance window. It is recommended to use security-approved virtual machine images and container-optimized images. Also, enhance the security of your container images using binary authorization.
You can utilize VPC Service Controls with Cloud Functions to create a service perimeter at the organization level. Configure organization policies to enforce VPC Service Control checks and restrict developers to deploying only compliant services.
Emphasize data security
You should always discover, classify and protect sensitive data using the Data Loss Prevention service (DLP).
You can encrypt your data using Customer Supplied Encryption Keys (CSEK), which gives you complete control and ownership of your encryption keys. You can use Paladin Cloud to monitor your encryption keys using its strict security policies for GCP.
You can also choose from other available data encryption services, such as KMS, which is a fully managed critical management service. You could even use a hardware security model hosted on the cloud, such as Cloud HSM, where Google Cloud manages the cluster for you.
Prepare for attacks in advance
Protect your cloud infrastructure from various threats, such as DDOS attacks, SQL injection, and cross-site scripting (XSS), using Cloud Armor. Read this article to learn about how Google Cloud Armor blocked the most significant layer 7 DDOS attack.
You should perform regular penetration testing and security assessments on your GCP infrastructure to address vulnerabilities proactively. Security Command Center can be used to identify threats and security vulnerabilities, providing actionable recommendations for remediation.
Alternatively (or in addition), you might consider Paladin Cloud, a free, open-source tool that offers real-time visibility into misconfigurations, automatically rectifying errors based on preset rules to minimize exposure. If you need assistance finding blind spots in your cloud security, schedule a demo with the experts.
You can reduce your cyberattack surface by up to 30% by using Paladin Cloud, since it also helps create a complete inventory of your cyber-assets across multiple GCP accounts.
The image shows an example of an asset discovery heat map from Paladin Cloud to visualize Google Cloud resources, and multi-cloud assets, from a single pane.
Automate security operations wherever possible
Continuous detection and response processes should be implemented using the Security Command Center and Chronicle SIEM. Chronicle also generates alerts that represent anomalies detected in traffic within the organization, which should be prioritized for investigation as they may indicate a possible security breach.
Chronicle security orchestration automation and response (SOAR) helps gather data and security alerts ingested from different sources to let you take appropriate actions with the help of playbooks.
Proactively monitor, alert, and log
All audit activities should be logged properly and stored for long-term retention. The correct duration of storage will be determined by your audit and compliance requirements and storage cost budgets.
Log-based alerts can also be implemented for possible security breaches. For example, an alert should be generated when a log entry contains a particular error message.
Incident response processes should be strictly implemented to outline the steps needed in case of a possible security breach. This should include communication guidelines, recovery strategies, and lessons learned for future improvements.
Identify, prioritize and remediate the most important cloud security risks.
Correlate findings across your existing tools: CSPM + Infrastructure + App Vulnerabilities
Reduce alert fatigue by up to 50% and lower your overall risk profile by up to 25%
Conclusion
As security breaches and threats rise, safeguarding your infrastructure, applications, and resources on the Google Cloud Platform (GCP) becomes more critical. This article discussed GCP security best practices that can serve as building blocks in safeguarding customer applications and data, ensuring uninterrupted service and a smooth end-user experience. A summary of the best practices is:
- Follow the principle of least privilege – only grant users the permissions they require.
- Monitor your Google Cloud environment – use logging and monitoring tools to detect suspicious activity. Asset discovery can be improved by integrating third-party tools, like Paladin Cloud.
- Maintain a security plan – develop security procedures to respond to attacks and, where possible, automatically remediate vulnerabilities.