CIS Benchmarks for Google Cloud Platform: A Practical Security Hardening Guide

Key Takeaways

• CIS GCP Foundation Benchmark v4.0.0 provides 100+ security controls across IAM, networking, compute, storage, databases, and logging.
• Security Command Center automates compliance scanning with certified detector mappings to CIS benchmarks.
• Common misconfigurations include overly permissive firewall rules, public storage buckets, and default service accounts on compute instances.
• Mapping to compliance frameworks like SOC 2 and ISO 27001 is straightforward since both require the same fundamental controls.
• Start with high-impact controls in IAM and networking before moving to service-specific configurations.

If you're running infrastructure on Google Cloud Platform, you've likely encountered the question: "How do we know our GCP environment is actually secure?" The CIS Benchmarks for GCP provide a concrete answer, offering consensus-driven security guidelines that translate abstract security requirements into specific, actionable configurations.

This guide covers what the CIS GCP Benchmarks are, the key controls you need to implement, common misconfigurations we encounter during audits, and how these controls map to compliance frameworks like SOC 2 and ISO 27001.

What Are CIS Benchmarks for GCP?

The Center for Internet Security (CIS) publishes security configuration guidelines for major cloud platforms, operating systems, and applications. For Google Cloud, the primary document is the CIS Google Cloud Platform Foundation Benchmark, currently at version 4.0.0 (published May 2025).

The benchmark provides prescriptive guidance covering:

• Identity and Access Management (IAM): Service account configuration, role assignments, authentication requirements
• Logging and Monitoring: Audit logging, metric filters, alerting configuration
• Networking: VPC configuration, firewall rules, flow logs
• Virtual Machines: Compute Engine security settings, disk encryption, OS hardening
• Cloud Storage: Bucket access controls, encryption, logging
• Cloud SQL: Database security, encryption, backup configuration
• Kubernetes Engine: GKE-specific security controls (covered in a separate CIS GKE Benchmark)

Each control includes a rationale explaining why it matters, audit procedures to check compliance, and remediation steps to fix issues.

Key CIS Controls by Service Area

Identity and Access Management

IAM misconfigurations represent some of the highest-risk issues in GCP environments. The CIS Benchmark emphasizes several critical controls:

Use corporate login credentials instead of personal accounts. Google Cloud should be accessed through Cloud Identity or Google Workspace accounts managed by your organization, not personal Gmail accounts. This enables centralized user lifecycle management, consistent authentication policies, and proper offboarding when employees leave.

Enforce multi-factor authentication for all non-service accounts. MFA should be mandatory for all human users, ideally using hardware security keys for privileged accounts. This control alone blocks the majority of credential-based attacks.

Avoid granting Service Account User or Service Account Token Creator roles at the project level. These roles allow users to impersonate service accounts, effectively bypassing IAM restrictions. Grant these permissions only at the service account level when absolutely necessary.

Rotate user-managed service account keys every 90 days. Better yet, avoid user-managed keys entirely by using workload identity federation, which eliminates the need for long-lived credentials. If you must use keys, implement automated rotation.

Never grant primitive roles (Owner, Editor, Viewer) in production. These legacy roles are overly broad. Use predefined roles or custom roles that follow the principle of least privilege.

Cloud Storage

Public storage buckets remain one of the most common causes of data breaches in cloud environments:

Ensure buckets are not anonymously or publicly accessible. Check that neither allUsers nor allAuthenticatedUsers have access to your buckets. The allAuthenticatedUsers permission is particularly dangerous because it sounds restrictive but actually grants access to anyone with any Google account.

Enable uniform bucket-level access. This simplifies permission management by disabling per-object ACLs, ensuring all access is controlled through IAM policies. It's easier to audit and reduces the risk of accidentally exposing individual objects.

Configure Cloud Storage access logging. Enable access logs to track who accessed what data and when. This is essential for incident investigation and compliance evidence.

VPC and Networking

Network security controls create defense-in-depth by limiting blast radius and preventing lateral movement:

Restrict SSH and RDP access from the internet. The benchmark explicitly prohibits allowing SSH (port 22) or RDP (port 3389) from 0.0.0.0/0. Use Identity-Aware Proxy (IAP) or bastion hosts instead, which provide authenticated, logged access without exposing management ports to the internet.

Enable VPC Flow Logs for every subnet. Flow logs capture network traffic metadata, enabling you to detect anomalies, investigate incidents, and demonstrate network monitoring for compliance purposes. The performance impact is minimal, and the visibility gained is substantial.

Avoid overly permissive firewall rules. Review rules that allow traffic from any source (0.0.0.0/0) or to any destination. Each firewall rule should have a documented business justification, and rules should be as specific as possible regarding source, destination, and ports.

Configure Private Google Access. This allows VMs without external IP addresses to reach Google APIs and services, enabling you to keep workloads fully private while still accessing GCP services.

Compute Engine

VM security settings protect your compute workloads from various attack vectors:

Enable OS Login at the project level. OS Login integrates with IAM for SSH access management, eliminating the need to manage SSH keys manually and providing centralized access control with audit logging.

Block project-wide SSH keys for individual instances. Even with OS Login enabled, project-wide SSH keys can provide a backdoor. Explicitly block these at the instance level for sensitive workloads.

Enable Shielded VM features. Shielded VMs provide verified boot integrity and protection against bootkits and rootkits. Enable Secure Boot, vTPM, and integrity monitoring for production workloads.

Avoid using default service accounts. The default Compute Engine service account has the Editor role on the project, and when VMs are configured with the cloud-platform access scope, workloads inherit broad read/write access to most Google Cloud services. Create dedicated service accounts with only the permissions each workload requires.

Use customer-managed encryption keys (CMEK) for sensitive workloads. While Google-managed encryption is adequate for many use cases, CMEK provides additional control and meets requirements for organizations that must manage their own keys.

Cloud SQL

Database security requires attention to network access, encryption, and operational controls:

Require SSL/TLS for all connections. Configure Cloud SQL instances to require encrypted connections, preventing data interception and man-in-the-middle attacks.

Avoid assigning public IP addresses to database instances. Keep databases in private networks and access them through Private Service Connect, Cloud SQL Auth Proxy, or VPN connections. If you absolutely need public access, restrict it to specific IP ranges.

Enable automated backups. The CIS Benchmark requires automated backups to be configured for all Cloud SQL instances. This protects against data loss from application errors, malicious activity, or infrastructure failures.

Configure point-in-time recovery. Beyond daily backups, enable binary logging (for MySQL) or continuous archiving (for PostgreSQL) to allow recovery to any point within your retention window.

Logging and Monitoring

Comprehensive logging is essential for security monitoring and incident response:

Configure Cloud Audit Logging across all services. Admin Activity logs are enabled by default, but Data Access logs must be explicitly enabled. Configure these for services processing sensitive data.

Create log sinks for all audit entries. Export logs to Cloud Storage, BigQuery, or Pub/Sub for long-term retention and analysis. This ensures logs survive even if an attacker gains access to modify or delete them within Cloud Logging.

Set up metric filters and alerts for critical events. The CIS Benchmark specifies alerts for:

• Project ownership changes
• Audit configuration changes
• Custom role modifications
• VPC network changes
• Firewall rule changes
• Network route changes
• Cloud Storage IAM permission changes
• SQL instance configuration changes

These alerts provide early warning of potentially malicious configuration changes.

Common GCP Misconfigurations We Find During Audits

Based on our compliance and security work with GCP customers, these issues appear repeatedly:

Overly Permissive Firewall Rules

We frequently find firewall rules allowing SSH from 0.0.0.0/0 that were created during initial setup and never locked down. The same applies to database ports exposed to the internet "temporarily" for development access that became permanent.

The fix: audit all firewall rules allowing traffic from any source. Replace broad rules with specific IP ranges or, better, use IAP for authenticated access.

Default Service Accounts Everywhere

Many organizations deploy Compute Engine instances using the default service account because it's the path of least resistance. This grants Editor-level permissions to workloads that might only need access to a single bucket or API.

The fix: create workload-specific service accounts with custom roles containing only necessary permissions.

VPC Flow Logs Disabled

Flow logs are disabled by default, so environments built without explicit attention to security often lack this visibility. When an incident occurs, investigators have no network traffic data to analyze.

The fix: enable flow logs for all subnets, using a sampling rate appropriate for your traffic volume and cost tolerance.

Public Cloud Storage Buckets

Sometimes intentional (for public assets), sometimes accidental (misconfigured IAM), public buckets appear regularly in our assessments. The dangerous case is when the bucket was meant to be private but someone granted allUsers access without understanding the implications.

The fix: audit all bucket IAM policies for allUsers and allAuthenticatedUsers. Use organization policies to prevent public access at the organization level if you never need public buckets.

Unencrypted Database Connections

Cloud SQL instances allowing unencrypted connections create risk for data interception, particularly if traffic traverses networks you don't fully control.

The fix: enable the "require SSL" setting on all Cloud SQL instances and update connection strings to use SSL.

Using Security Command Center for CIS Compliance

Google Cloud's Security Command Center (SCC) provides automated compliance scanning against CIS Benchmarks. SCC includes Security Health Analytics, which maps detectors to CIS controls and generates findings when configurations don't meet benchmark requirements.

Key capabilities include:

Compliance dashboard: View compliance percentage across your organization, broken down by control and resource.

Daily scans: SCC runs daily compliance checks and updates findings automatically.

Finding remediation: Each finding includes remediation guidance and links to documentation.

Multiple benchmark versions: SCC supports CIS GCP Foundation Benchmark versions v1.0.0 through v2.0.0, with CIS certification on detector mappings. Note that the latest CIS benchmark (v4.0.0) is not yet fully supported in SCC; for comprehensive v4.0.0 compliance scanning, consider supplementing with the official GCP CIS InSpec Profile or third-party tools.

One limitation to note: not all CIS controls can be automated. Some require manual review or organizational processes that can't be detected through API scanning. SCC compliance percentages represent automated checks only.

Mapping CIS Benchmarks to SOC 2 and ISO 27001

If you're pursuing SOC 2 Type 2 or ISO 27001 certification, CIS Benchmark compliance provides strong coverage of the technical controls these frameworks require.

SOC 2 Alignment

The SOC 2 Trust Services Criteria map directly to CIS controls:

ISO 27001 Alignment

ISO 27001 Annex A controls also align with CIS recommendations. The table below references ISO 27001:2022 control categories:

Implementing CIS Benchmarks doesn't automatically make you compliant with either framework, but it addresses the majority of technical controls auditors will examine.

GCP Security Hardening Checklist

Use this checklist to assess your current CIS Benchmark compliance:

IAM

• Corporate identity provider integrated with Cloud Identity
• MFA enforced for all human users
• No primitive roles (Owner/Editor/Viewer) in production
• Service accounts use workload identity or rotated keys
• No Service Account User role at project level

Networking

• No SSH/RDP allowed from 0.0.0.0/0
• VPC Flow Logs enabled on all subnets
• Firewall rules documented and reviewed
• Private Google Access configured
• IAP used for administrative access

Compute

• OS Login enabled at project level
• Shielded VM features enabled
• No default service accounts on instances
• Project-wide SSH keys blocked
• CMEK configured for sensitive workloads

Storage

• No public bucket access
• Uniform bucket-level access enabled
• Access logging configured
• Retention policies set appropriately

Databases

• SSL/TLS required for all connections
• No public IP addresses on instances
• Automated backups enabled
• Point-in-time recovery configured

Logging

• Data Access audit logs enabled
• Log sinks configured for retention
• Metric filters for critical events
• Alerts configured and tested

Bastion helps companies achieve SOC 2, ISO 27001, and other compliance certifications while ensuring their cloud infrastructure is genuinely secure. If you're working on GCP security hardening or preparing for a compliance audit, reach out to us.