Compliance, Mapped to Your Cloud

Use corporate login credentials instead of consumer accounts, such as Gmail accounts. It is recommended fully-managed corporate Google accounts be used for increased visibility, auditing, and controlling access to Cloud Platform resources. Email accounts based outside of the user's organization, such as consumer accounts, should not be used for business purposes.

User-managed service accounts should not have user-managed keys. Anyone who has access to the keys will be able to access resources through the service account. GCP-managed keys are used by Cloud Platform services such as App Engine and Compute Engine. These keys cannot be downloaded. Google will keep the keys and automatically rotate them on an approximately weekly basis. User-managed keys are created, downloadable, and managed by users. They expire 10 years from creation. For user-managed keys, the user has to take ownership of key management activities such as key storage, distribution, rotation, etc. Even with precautions, keys can be easily leaked by common development malpractices. Therefore, it is recommended to prevent user-managed service account keys.

A service account is a special Google account that belongs to an application or a VM, instead of to an individual end-user. It is recommended not to use admin access for a service account. Service accounts represent service-level security for applications or VMs. Assigning Admin rights to service accounts grants full access to the assigned application or VM. A Service Account with admin privileges can perform critical actions like delete, update, or change settings. Hence, it's recommended that service accounts not have Admin rights.

It is recommended to assign the Service Account User (iam.serviceAccountUser) and Service Account Token Creator (iam.serviceAccountTokenCreator) roles to a user for a specific service account rather than assigning the role to a user at the project level. Granting these roles at the project level gives the user access to all service accounts in the project, including those created in the future. This can result in privilege escalation by indirectly gaining access to resources the service accounts have. Assigning these roles only on a specific service account follows the principle of least privilege.

Service Account keys consist of a key ID (private_key_id) and private key, used to sign programmatic requests made to Google Cloud services via that service account. It is recommended that all service account keys are regularly rotated. Rotating service account keys limits the window of opportunity if the keys are compromised. Keys can be easily misplaced, stolen, or cracked. Therefore, rotating them every 90 days or fewer helps secure access to your data and resources.

It is recommended that the principle of 'Separation of Duties' be enforced when assigning service account–related roles to users. The built-in roles Service Account Admin and Service Account User should not be assigned simultaneously to a single user. Separation of duties helps avoid giving one individual total control over critical components, reducing the risk of malicious actions.

It is recommended that the IAM policy on Cloud KMS cryptokeys should restrict anonymous and/or public access. Granting allUsers or allAuthenticatedUsers permissions on a KMS cryptokey effectively allows public access, which is undesirable if sensitive data is stored using that key. Removing those permissions helps ensure cryptographic material remains private.

Google Cloud Key Management Service stores cryptographic keys in a hierarchy. It is recommended that keys be rotated within a period of 90 days. Setting a rotation period helps ensure that key material changes regularly, reducing the risk window if a key is compromised. Rotating keys forces attackers to obtain and exploit updated keys, which is more difficult.

It is recommended that the principle of 'Separation of Duties' is enforced while assigning KMS related roles. No user should have Cloud KMS Admin and Cloud KMS CryptoKey Encrypter/Decrypter roles concurrently. By separating duties, you prevent a single user from having the ability to both create/manage keys and use them to encrypt/decrypt sensitive data.

API Keys should only be used when other authentication methods are unavailable, and restricted to known hosts, HTTP referrers, or apps. API keys are often visible to clients, so they can easily be discovered or stolen. Restricting keys to specific hosts or apps limits the potential damage if a key is compromised.

In cases where API keys must be used, it is recommended to restrict them to call only the APIs needed by the application. API keys are simple encrypted strings that do not identify the user or application. If stolen, they can be used to call any APIs for which they have permission. Restricting their usage to necessary APIs reduces the attack surface.

It is recommended to rotate API keys every 90 days if they are in use. API keys do not expire on their own. If one is lost or stolen, it remains valid until revoked or regenerated. Rotating them every 90 days reduces the chance that a compromised key can be used indefinitely.

It is recommended to configure Cloud Audit Logging to track admin activities and read/write access for user data. Cloud Audit Logging provides Admin Activity and Data Access logs. Admin Activity logs cannot be disabled, but Data Access logs are disabled by default. Enabling Data Access logs (DATA_READ and DATA_WRITE) for all services ensures comprehensive audit coverage.

It is recommended to create a sink that exports all log entries for potential aggregation or analysis in tools such as a SIEM. Log entries remain in Cloud Logging by default. However, exporting them to external destinations (e.g., Cloud Storage, BigQuery) can preserve them longer, help correlate logs across projects, or integrate with security analysis workflows.

It is recommended to configure data retention policies for buckets used as log sinks and then lock these policies. Locking a bucket’s retention policy prevents policy removal or reduction, ensuring logs cannot be overwritten or deleted until the retention period has elapsed. This is crucial for investigations or compliance.

Monitoring and alerting on project owner role assignments or changes helps detect privilege escalation or misconfiguration. Project owners have the highest privileges, including the ability to manage IAM policies. Alerting on any additions or removals of owner roles ensures unusual changes are detected quickly.

It is recommended to create a log metric filter and alert for changes to audit configurations. Ensuring that audit logging remains enabled is essential for ongoing security and compliance. Monitoring changes to audit configurations detects if someone attempts to disable or alter logging settings.

It is recommended to establish a log metric filter and alarm for creation, deletion, or updating of custom roles. Custom IAM roles can grant granular privileges. Monitoring any changes to these roles helps detect the introduction of over-privileged roles or unintended role modifications.

It is recommended to have a metric filter and alert for changes to VPC firewall rules. Firewall rule changes can open or restrict network traffic. Monitoring these helps detect potential unauthorized network access changes.

It is recommended to establish a log metric filter and alarm for changes to VPC routes. VPC routes direct network traffic. Monitoring route changes helps confirm traffic is not being maliciously redirected or exposing subnets to unwanted paths.

It is recommended to create a metric filter and alert for changes to VPC networks. You can have multiple VPC networks, including peering connections. Monitoring changes ensures you detect creation/deletion or modifications that might impact the security or architecture.

It is recommended to establish a metric filter and alert for changes to Cloud Storage bucket IAM settings. Overly permissive or unauthorized IAM changes may expose sensitive data. Monitoring changes to bucket permissions helps detect these issues sooner.

It is recommended to have a metric filter and alarm for changes to Cloud SQL instance configurations. Monitoring Cloud SQL configuration changes reduces the time needed to detect and fix potentially harmful modifications, such as disabling backups, allowing public IP addresses, or altering authorized networks.

Cloud DNS logging captures queries from name servers within your VPC and records them in Cloud Logging. Monitoring DNS queries can reveal suspicious or malicious domain lookups. This can aid in incident detection and response. Coupled with blocking external DNS or DNS over HTTPS, Cloud DNS logs offer complete visibility.

It is recommended to enable logging for HTTP(S) load balancers to capture traffic logs. Logging provides visibility into HTTP(S) requests, aiding in incident response, troubleshooting, and usage analysis. Adjust the logging sample rate to control data volumes and costs.

It is recommended that the default network be removed from a project. The default network is an auto mode network with preconfigured firewall rules allowing certain access (SSH, RDP, ICMP) from any source. Removing it enforces a more controlled, custom VPC topology that adheres to security best practices.

DNS Security Extensions (DNSSEC) authenticate DNS responses to ensure integrity. Enabling DNSSEC helps mitigate DNS spoofing by digitally signing DNS records. This ensures responses are valid and not maliciously altered.

It is recommended that you not use RSA-SHA1 as the key-signing key. RSA-SHA1 is weaker compared to modern algorithms. Avoiding it reduces exposure to cryptographic attacks.

It is recommended that RSA-SHA1 not be used for the zone-signing key in DNSSEC. Using stronger algorithms (e.g., RSA-SHA256) helps ensure the security of DNS zone data against tampering.

It is recommended that port 22 (SSH) be restricted from the internet. Exposing SSH to the internet can lead to brute force or credential stuffing attacks. Restricting this reduces the external attack surface.

It is recommended that port 3389 (RDP) be restricted from the internet. Exposing RDP to the internet increases risk of brute force and exploit attempts. Restricting it reduces external attack vectors.

VPC Flow Logs capture information about the IP traffic going to and from network interfaces. Enabling flow logs aids in network monitoring, forensics, and real-time security analysis by providing a record of traffic data.

It is recommended that instances not use the automatically created default service account. The default service account has the Editor role on the project, which is overly permissive. Assigning a custom service account with least privilege helps reduce potential damage from compromise.

Ensures that instances do not have the default service account with full API access. Attaching the default service account with full access to all Cloud APIs grants broad permissions. Following least privilege principles protects against abuse if an instance is compromised.

It is recommended to block project-wide SSH keys at the instance level. Project-wide SSH keys apply to all instances. If compromised, they can grant wide access. Blocking them ensures only instance-level SSH keys are allowed, limiting the blast radius.

Enabling OS Login centralizes SSH access control in IAM. OS Login allows management of SSH keys via IAM roles and user accounts, simplifying auditing and revocation while avoiding key sprawl.

It is recommended not to enable 'Connecting to serial ports' on VM instances. Serial console access can allow low-level debugging or administrative control, which poses additional security risk if misused.

It is recommended to disable IP forwarding on instances. IP forwarding allows a VM to receive and send traffic not destined for itself, which can facilitate man-in-the-middle attacks or unauthorized routing.

Critical VM disks should be encrypted with customer-supplied encryption keys (CSEK). CSEK gives you control over the key lifecycle and rotation, ensuring that disk encryption can only be unlocked by your chosen key material.

Shielded VM protects against boot- and firmware-level attacks by verifying the integrity of the bootloader. Enabling Shielded VM helps ensure that instances boot with a known and trusted image, preventing attackers from subverting the OS at a lower level.

It is recommended that compute instances do not have public IP addresses. Public IP addresses expose VMs directly to the internet, expanding the potential attack surface. Instead, use private IPs with secure access methods like VPN or IAP.

Confidential Computing encrypts data in use within the VM. This mitigates attacks that rely on reading memory, such as from the hypervisor or malicious insiders, providing a higher level of data confidentiality.

Cloud Storage buckets should not grant access to allUsers or allAuthenticatedUsers. Granting these permissions publicly exposes the data. Limiting who can read or write objects is critical to preventing sensitive information leaks.

It is recommended to enable uniform bucket-level access for Cloud Storage. Uniform bucket-level access centralizes control of permissions at the bucket level and disables object ACLs, reducing the risk of misconfiguration leading to public data exposure.

The skip_show_database flag restricts information about the databases on the server. With skip_show_database enabled, MySQL does not display all databases, limiting information exposure to users without privileges.

The local_infile flag, when enabled, allows importing local data files. Leaving it on can allow unauthorized reading of files into the database, risking exposure of sensitive data. Turning it off provides additional protection.

The log_error_verbosity parameter controls the verbosity of logged errors. Using DEFAULT or a stricter setting helps identify errors without disclosing excessive information that could be exploited.

The log_connections parameter logs each successful connection. Logging connection attempts facilitates auditing and can help detect unauthorized access attempts.

The log_disconnections parameter logs session terminations. Tracking both connections and disconnections gives full visibility into session activity and duration.

The log_statement parameter determines which SQL statements get logged. Logging statements can reveal malicious queries or mistakes. However, logging every statement can create performance overhead and expose sensitive data, so it must be set thoughtfully.

The log_min_messages parameter determines which message levels are logged. By setting it to WARNING or more restrictive, you ensure that only events needing attention are logged, filtering out less critical messages.

The log_min_error_statement parameter controls which SQL statements that produce errors are logged. Ensuring that errors are logged (and potentially the statements that caused them) helps with troubleshooting and auditing, but avoids excess logging of harmless statements.

The log_min_duration_statement parameter sets the minimum execution time for statements to be logged. A setting of '-1' logs no statements based purely on duration. This avoids cluttering logs with long-running queries if not relevant, but can be adjusted as needed.

It is recommended to enable cloudsql.enable_pgaudit for PostgreSQL instances. PgAudit provides detailed logging capabilities beyond standard PostgreSQL logs, capturing session and/or object-level details for more comprehensive auditing.

The external scripts enabled flag allows running external scripts (e.g., R, Python). Enabling external scripts can pose a security risk by allowing arbitrary code execution within the database environment. Disabling it reduces attack surface.

The cross db ownership chaining flag permits access to objects across databases when the same owner exists. Disabling cross-database ownership chaining prevents privileges in one database from automatically propagating to another, upholding separation.

The user Connections flag sets the max number of simultaneous user connections. Configuring an appropriate upper limit can prevent resource exhaustion while still allowing legitimate connections.

The user options database flag sets global defaults for users. Leaving this at the default ensures no unintended global settings can undermine security, performance, or compliance.

The remote access flag allows execution of stored procedures from remote servers. Disabling remote access restricts cross-server procedure calls, lowering risk of unintended data sharing or remote exploits.

Trace flag 3625 limits detailed error messages to sysadmin. Restricting system error message details prevents non-privileged users from gaining insights that could assist an attack.

Contained database authentication allows a database to store user login information rather than relying on the server-level login. Disabling contained database authentication helps ensure that logins must exist at the server level, providing centralized management and reducing potential attack vectors.

It is recommended to require SSL connections for all incoming connections to Cloud SQL instances. Requiring SSL encrypts data in transit, preventing attackers from intercepting or modifying data between the client and the database server.

Ensures that the server is not implicitly allowing any IP address. Whitelisting 0.0.0.0/0 grants open access from the internet, exposing the database to attacks. Restrict connections to known or private ranges.

It is recommended that Cloud SQL instances not be assigned public IP addresses. Public IP addresses can be targeted by external threats. Restricting access to private IP addresses reduces exposure and relies on secure connectivity (e.g., VPC peering or VPN).

It is recommended to enable automated backups for Cloud SQL instances. Regular backups protect against data loss and allow you to recover data in case of accidents or malicious activity. Lack of backups can lead to irrecoverable loss.

It is recommended that the IAM policy on BigQuery datasets restrict anonymous or public access. Granting allUsers or allAuthenticatedUsers access effectively makes data public. This should be avoided unless intentionally required for open data use cases.

All BigQuery tables should be encrypted with a customer-managed encryption key. CMEK allows you to control cryptographic keys outside of Google's default encryption, enabling you to manage rotation and revocation aligned with your security requirements.

It is recommended to specify a default Customer-Managed Encryption Key (CMEK) for all BigQuery datasets. When a default CMEK is set, all newly-created tables in that dataset are automatically encrypted with that key, ensuring consistent encryption practices.

It is recommended that Dataproc clusters be encrypted with customer-managed encryption keys. Using CMEK for Dataproc ensures that data at rest is encrypted with user-controlled keys, allowing more rigorous key management, rotation, and revocation.