gcloud 漏洞列表

JeeSpringCloud 是一款免费开源的 Java 互联网云快速开发平台，JeeSpringCloud 访问 /static/uploadify/uploadFile.jsp 可上传任意文件。 FOFA: header="com.jeespring.session.id" ZoomEye: header:"com.jeespring.session.id"

Ensure that the usage of your Google Cloud API keys is restricted to specific APIs such as Cloud Key Management Service (KMS) API, Cloud Storage API, Cloud Monitoring API, and Cloud Logging API. All Google Cloud API keys that are being used for production applications should use API restrictions.

Ensure that the use of Google Cloud API keys is limited to trusted and reliable hosts, HTTP referrers, or applications. An API key application restriction manages the authorization of websites, IP addresses, or Android/iOS mobile applications that can employ your API key. It is crucial that all API keys used in production employ host and application restrictions. By enforcing these restrictions, you can reduce the impact that a compromised API key can have on your applications.

Ensure that your Google Cloud projects are using the standard authentication flow as the preferred method for authentication, rather than relying on API keys. API keys are simple encrypted strings that can be used when calling certain APIs which don't need to access private user data. API keys should be exclusively employed for active services when alternative authentication methods are not accessible, otherwise deleted.

Ensure that critical service APIs are enabled for your GCP projects to gain access to essential functionalities and services provided by Google Cloud Platform (GCP), manage your project resources efficiently, enhance the security of your cloud environment, and track your usage and billing. The critical service APIs include, but are not limited to, Identity and Access Management (IAM) API, Compute Engine API, Cloud Storage, Google Cloud Pub/Sub API, Cloud Key Management Service (KMS) API, and Cloud Logging API.

To access historical security findings and asset data in Security Command Center, ensure that the Security Command Center API is enabled within your Google Cloud account. If the API is not enabled, certain security features and monitoring capabilities will be unavailable.

Ensure that Cloud Asset Inventory is enabled for all your GCP projects in order to efficiently manage the history and the inventory of your cloud resources. Google Cloud Asset Inventory is a fully managed metadata inventory service that allows you to view, monitor, analyze, and gain insights for your Google Cloud and Anthos assets. Cloud Asset Inventory is disabled by default in each GCP project.

Identify any publicly accessible Artifact Registry repositories within your Google Cloud account and update their IAM policy in order to protect against unauthorized access. To deny access from anonymous and public users, remove the bindings for "allUsers" and "allAuthenticatedUsers" members from the IAM policy associated with your repository.

Ensure that vulnerability scanning for Google Cloud Artifact Registry repositories is enabled in order to find security weaknesses in your container images before deploying them and help prevent security breaches.

Ensure that all your Google Cloud BigQuery datasets are encrypted using Customer-Managed Encryption Keys (CMEKs) in order to have a more granular control over the dataset encryption/decryption process. Datasets not encrypted with CMEKs may expose sensitive data to higher risks.

Ensure that the tables created for your Google Cloud BigQuery datasets are encrypted with Customer-Managed Keys (CMKs) to have more granular control over the data encryption/decryption process. Using CMKs allows you to create, rotate, manage, and destroy your own encryption keys using Google Cloud Key Management Service (Cloud KMS).

Ensure there are no anonymously and/or publicly accessible BigQuery datasets available within your Google Cloud Platform (GCP) account. Google Cloud BigQuery datasets have Identity and Access Management (IAM) policies configured to determine who can have access to these resources. To refuse access from anonymous and public users, remove the bindings for "allUsers" and "allAuthenticatedUsers" members from the IAM policy associated with your datasets.

Ensure that your Cloud CDN backend buckets are referencing existing storage buckets in order to be able to deliver static content efficiently from the nearest edge location to users, reducing latency and improving performance.

Ensure that Cloud CDN origins are configured to authenticate access to the content available at backend (backend buckets or backend services) using signed cookies and signed URLs. Signed cookies and URLs are designed to prevent unauthorized users from bypassing the authentication process and accessing sensitive information.

Ensure that Google Cloud CDN backend service origins are using SSL/TLS certificates to enforce HTTPS in order to manage encrypted traffic. This helps to protect the integrity and confidentiality of the transmitted information.

Ensure that SSL certificates managed with Google Cloud Certificate Manager don't have a validity period greater than 398 days (13 months). This is to enhance security by reducing the risk of certificate compromise and misuse, while aligning with industry standards and support from modern web browsers.

Ensure that your virtual machine disk images are not publicly shared with all other Google Cloud Platform (GCP) accounts in order to avoid exposing sensitive or confidential data. If required, you can share your disk images with specific GCP accounts only, without making them public.

Ensure that your Google Cloud Managed Instance Groups (MIGs) are configured with Autohealing feature. Autohealing allows re-creating virtual machine instances when they become unresponsive. Application-based autohealing improves application availability by relying on a health checking signal that detects application-specific issues such as freezing, crashing, or overloading.

Ensure that each Managed Instance Group is using a load balancer to act as an instance group frontend. Google Cloud Managed Instance Groups (MIGs) are groups of virtual machine (VM) instances that you control as a single entity. MIGs support rich features such as autoscaling and autohealing, load balancing, multiple zone coverage, and stateful workloads.

Ensure that Managed Instance Groups (MIGs) are spread across multiple zones within a Google Cloud region for high availability and fault tolerance. Spreading application load across multiple Google Cloud zones with MIGs is crucial for enhancing the availability, resilience, and performance of your application. When you allocate your MIG instances across multiple zones, you can guarantee the continuous availability and functionality of your application even during failures or outages.

Ensure that the OS Login feature is enabled at the Google Cloud Platform (GCP) project level in order to provide you with centralized and automated SSH key pair management. OS Login ensures that SSH keys are mapped with Google Cloud IAM users, facilitating centralized management of SSH access.

Ensure that persistent disks are not attached to suspended virtual machine (VM) instances in your Google Cloud environment. Persistent disks attached to suspended VMs continue to incur charges even when the VM is not running, leading to unnecessary costs.

Ensure that Google Cloud Compute Engine service restarts automatically your virtual machine instances when they are terminated due to non-user initiated reasons such as maintenance events, hardware, and software failures. The Automatic Restart feature configures the virtual machine restart behavior when an instance crashes or it is terminated by the system.

Ensure that the Confidential Computing security feature is enabled for your Google Cloud virtual machine (VM) instances in order to add protection to your sensitive data in use by keeping it encrypted in memory and using encryption keys that Google doesn't have access to. Confidential Computing is a breakthrough technology which encrypts data while it is being processed. This technology keeps data encrypted in memory, outside the CPU.

Ensure that your Google Compute Engine instances are not configured to use the default service account with the Cloud API access scope set to "Allow full access to all Cloud APIs". The principle of least privilege (POLP), also known as the principle of least authority, is the security concept of giving the user/system/service the minimal set of permissions required to successfully perform its tasks.

Ensure that your Google Compute Engine instances are not configured to use the default Google Cloud service account in order to implement the principle of least privilege (POLP) and secure the access to your cloud resources. The default Compute Engine service account, named <project-number>-compute@developer.gserviceaccount.com, is associated with the Editor role at the project level, which allows read and write access to most Google Cloud Platform (GCP) services.

Ensure that your production Google Compute Engine instances have Deletion Protection feature enabled in order to protect them from being accidentally deleted. With Deletion Protection safety feature enabled, you have the guarantee that your VM instances cannot be accidentally deleted and make sure that your production environment remains safe.

Ensure that the Auto-Delete behavior rule is disabled for the persistent disks attached to your Google Cloud virtual machine (VM) instances in order to protect the VM data from being deleted and meet security and compliance requirements. When Auto-Delete is on, the persistent disks are deleted when the associated VM instance is deleted.

Ensure that the persistent disks attached to your Google Compute Engine instances are encrypted with Customer-Managed Keys (CMKs) in order to have a fine control over your sensitive data encryption and decryption process. You can create and manage your own Customer-Managed Keys (CMKs) with Cloud Key Management Service (Cloud KMS). Cloud KMS provides secure and efficient encryption key management, controlled key rotation, and revocation mechanisms.

Ensure that the disks attached to your production Google Compute Engine instances are encrypted with Customer-Supplied Encryption Keys (CSEKs) in order to have complete control over the data-at-rest encryption and decryption process, and meet strict compliance requirements.

Ensure that the disks attached to your production Google Compute Engine instances are encrypted with Customer-Supplied Encryption Keys (CSEKs) in order to have complete control over the data-at-rest encryption and decryption process. CSEKs allow you to provide your own encryption keys that Google Compute Engine uses to protect the Google-generated keys used to encrypt and decrypt your instance data.

Ensure that IP Forwarding feature is not enabled at the Google Compute Engine instance level for security and compliance reasons, as instances with IP Forwarding enabled act as routers/packet forwarders. Because IP forwarding is rarely required, except when the virtual machine (VM) is used as a network virtual appliance, each Google Cloud VM instance should be reviewed to decide whether IP forwarding is really needed.

Ensure that Google Cloud Compute Engine performs live migration of your virtual machine instances during periodic infrastructure maintenance. The virtual machine maintenance behavior determines whether the VM instances are live migrated or terminated during a maintenance event. To ensure that your Google Cloud VM instances are migrated to new hardware, set "On Host Maintenance" configuration setting to "Migrate".

Ensure that the OS Login feature enabled at the virtual machine instance level is configured with Two-Factor Authentication (2FA) in order to help protect the access to your Google Cloud VM instances. Two-Factor Authentication (also known as Multi-Factor Authentication - MFA) provides an additional layer of security on top of the existing credentials.

Ensure that your Google Cloud Platform (GCP) projects are not using preemptible virtual machine instances for production and business-critical applications. A preemptible virtual machine (VM) is an instance that you can create and run at a much lower price than normal instances but it can be terminated sooner due to system demands.

Ensure that your Google Compute Engine instances are configured to ignore GCP project-wide (shared) public SSH keys and use instance-level SSH keys instead. Project-wide SSH keys can be used to log in to all the VM instances running inside a GCP project. While project-wide SSH keys can ease SSH key management, if compromised, they pose a security risk which can impact all VM instances within the project.

Ensure that your Google Compute Engine instances are not configured to have external IP addresses in order to minimize their exposure to the Internet. To reduce attack surface, Google Cloud virtual machine (VM) instances should not have public IP addresses attached. Instead, VM instances should be configured to run behind load balancers.

Ensure that "Enable connecting to serial ports" configuration setting is disabled for all your production Google Compute Engine instances. The interactive serial console does not support IP-based access restrictions such as IP address whitelists. If enabled, clients can attempt to connect to your instance from any IP address if they know the username, SSH key, project ID, instance name and zone.

Ensure that your Google Cloud Dataproc clusters on Compute Engine are encrypted with Customer-Managed Keys (CMKs) in order to control the cluster data encryption/decryption process. You can create and manage your own Customer-Managed Keys (CMKs) with Cloud Key Management Service (Cloud KMS). Cloud KMS provides secure and efficient encryption key management, controlled key rotation, and revocation mechanisms.

Ensure that your Google Cloud Dataproc clusters are not configured with external IP addresses to minimize exposure to the Internet. When external IP addresses are assigned to Dataproc clusters, the cluster instances are exposed directly to the Internet. This increases the attack surface and risks accidental data exposure if firewall rules are misconfigured.

Ensure that dangling DNS records are removed from your public Cloud DNS zones in order to maintain the integrity and authenticity of your domains/subdomains and to protect against domain hijacking.

Ensure that Domain Name System Security Extensions (DNSSEC) feature is not using the deprecated RSASHA1 algorithm for the Key-Signing Key (KSK) associated with your DNS managed zone file.

Ensure that Domain Name System Security Extensions (DNSSEC) feature is not using the deprecated RSASHA1 algorithm for the Zone-Signing Key (ZSK) associated with your public DNS managed zone.

Ensure that your Google Cloud Filestore instances have Deletion Protection feature enabled in order to protect them from being accidentally deleted. With the Deletion Protection safety feature enabled, your Filestore instances are guaranteed to be protected from accidental deletion, ensuring your data remains safe.

Ensure that on-demand backup and restore functionality is in use for your Google Cloud Filestore instances to ensure data protection, disaster recovery, and regulatory compliance. The backup and restore process does not consume provisioned capacity and has no impact on the performance and availability of your Filestore applications.

Ensure that data stored on your Google Cloud Filestore instances is encrypted at rest with Customer-Managed Encryption Keys (CMEK) instead of Google-managed encryption keys. CMEKs provide greater control over the encryption and decryption process, enabling you to meet stringent compliance requirements.

Ensure that VPC Service Controls are used to configure a security perimeter around your Google Cloud Filestore instances. VPC Service Controls is a powerful security tool that allows you to restrict access to your cloud resources, including Filestore instances, to specific networks and clients. This helps prevent data exfiltration and enhances the security posture of your cloud environment.

Ensure that client access to your Google Cloud Filestore instances is limited to specific (trusted) IP addresses or IP address ranges in order to protect your data against unauthorized access. By default, Filestore instances provide full (root-level read/write) access to all clients within the same Google Cloud project and VPC network.

To minimize cold start latency and enhance performance, ensure that your Google Cloud Functions have a sufficient number of warm instances configured.

Ensure that user-defined labels are being used to tag, collect, and organize Google Cloud functions within your Google Cloud Platform (GCP) projects. User-defined labels are a lightweight and efficient way to group together related or associated cloud resources.

Ensure that your Google Cloud functions are configured to use Serverless VPC Access in order to connect functions directly to your VPC network, allowing access to other VPC resources such as VM instances, MemoryStore instances, or any other cloud resources with an internal IP address. Without Serverless VPC Access, these functions may not be able to communicate efficiently with other resources in the same VPC.

Identify any publicly accessible Google Cloud functions within your GCP account and update their IAM policy to protect against unauthorized users sending requests to invoke these functions. To deny access from anonymous and public users, remove the bindings for allUsers and allAuthenticatedUsers members from your function's IAM policy. The allUsers member represents any user on the Internet, while allAuthenticatedUsers represents any user or service account that can sign into Google Cloud Platform (GCP) with a Google account.

Ensure that Google Cloud functions triggered by Pub/Sub have a Dead-Letter Topic (DLT) configured to handle undeliverable messages. To achieve this, configure your Pub/Sub subscriptions with a maximum number of delivery attempts. If a message cannot be delivered, it will be sent to the designated Dead-Letter Topic (DLT).

To prevent unauthorized access or accidental exposure of sensitive information, ensure that Secrets Manager service is used to store and manage secrets instead of storing them in cleartext within Cloud Functions environment variables.

Ensure that the Auto-Repair feature is enabled for all your GKE cluster nodes to help maintain node health. Google Kubernetes Engine (GKE) triggers a repair action if a node reports consecutive unhealthy status reports for a given time threshold, such as when a node broadcasts a "NotReady" status, fails to broadcast any status, or runs out of disk space.

Ensure that the Auto-Upgrade feature is enabled for all the nodes running within your Google Kubernetes Engine (GKE) clusters. This feature helps you keep your cluster nodes up to date with the latest supported version of Kubernetes, automatically applying security fixes and new functionalities.

Ensure that backups are enabled for your Google Kubernetes Engine (GKE) clusters to protect your workloads and enable disaster recovery capabilities. GKE backups capture both configuration and volume data, allowing selective or comprehensive restoration of workloads, which is valuable for disaster recovery, CI/CD pipelines, workload cloning, and managing upgrades.

Ensure that Binary Authorization is enabled for your Google Kubernetes Engine (GKE) clusters to enforce container image security policies. Binary Authorization enhances security by ensuring only trusted container images can be deployed, reducing the risk of deploying vulnerable or unauthorized software.

Ensure that your Google Kubernetes Engine (GKE) cluster node pools use confidential GKE nodes to encrypt all running workloads. Confidential GKE nodes employ hardware-based memory encryption to safeguard your data and applications from unauthorized access or modification while in use.

Ensure that your Google Kubernetes Engine (GKE) cluster nodes use the Container-Optimized OS (cos_containerd), a managed, optimized, and hardened base OS provided by GKE to limit the host's attack surface. cos_containerd's layered architecture enables advanced GKE features like gVisor and Image Streaming, and offers improved resource efficiency and security.

Ensure that cost allocation is enabled for your Google Kubernetes Engine (GKE) clusters to gain detailed insights into resource usage. This feature allows you to break down resource consumption by Kubernetes namespaces and labels, making it easier to associate costs with specific entities and access detailed cost reports through billing data exported to BigQuery.

Ensure that your Google Kubernetes Engine (GKE) clusters are configured to use user-managed service accounts instead of the default service account managed by Google Cloud. The default service account has broad permissions across your GCP project, which violates the Principle of Least Privilege (POLP).

Ensure that Integrity Monitoring is enabled for your Google Kubernetes Engine (GKE) cluster nodes to monitor and automatically check the runtime boot integrity using Google Cloud Monitoring service. This feature helps verify that the boot loader and other measured components remain untampered.

Ensure that intranode visibility is enabled for your Google Kubernetes Engine (GKE) clusters. This allows you to monitor and troubleshoot network traffic between pods running on the same node, enhancing both visibility and security. When enabled, packets exchanged between Pods are always processed by the VPC network.

Ensure that user-defined labels are being used to tag, collect, and organize GKE clusters within your Google Cloud Platform (GCP) projects. User-defined labels are a lightweight and efficient way to group together related or associated cloud resources. These are unrelated to Kubernetes labels.

Ensure that GKE Metadata Server is enabled for your Google Kubernetes Engine (GKE) cluster nodes to enhance security by restricting workload access to sensitive instance information. The GKE Metadata Server feature requires Workload Identity for improved authentication and authorization.

Ensure that Cloud Monitoring is enabled for your Google Kubernetes Engine (GKE) clusters to collect metrics emitted by your Kubernetes applications and the GKE infrastructure. Cloud Monitoring helps track cluster health, application reliability, and performance metrics.

Ensure that critical alert notifications are enabled for your Google Kubernetes Engine (GKE) clusters to receive important Pub/Sub messages about upgrades, security bulletins, and other relevant information. This helps you stay informed about potential risks and opportunities for optimization.

Ensure that your Google Kubernetes Engine (GKE) clusters are configured to provision all nodes with only internal IP addresses (private nodes). This prevents external clients from accessing the nodes and prevents the nodes from having direct access to the Internet, reducing the attack surface.

Ensure that your Google Kubernetes Engine (GKE) clusters are configured to use private endpoints only for control plane access, effectively disabling external access to the Kubernetes API. This requires configuring the GKE cluster with private nodes, a private master IP range, and IP aliasing.

Ensure that your Google Kubernetes Engine (GKE) clusters are subscribed to either Regular or Stable release channels to automate version management and upgrades. Release channels automatically select cluster versions to provide a balance between new features and stability, while ensuring critical security patches are delivered.

Ensure that your Google Kubernetes Engine (GKE) clusters are configured to use GKE Sandbox with gVisor to provide an additional layer of security isolation for containers. GKE Sandbox uses gVisor, a container runtime sandbox, to help isolate containers and protect the underlying host kernel.

Ensure that encryption of Kubernetes secrets with Customer-Managed Keys (CMKs) is enabled for your Google Kubernetes Engine (GKE) clusters. Application-layer secrets encryption protects your Kubernetes secrets in etcd with an encryption key managed using the Cloud KMS service, providing an additional layer of security for sensitive data.

Ensure that the Secure Boot security feature is enabled for your GKE cluster nodes to protect them against malware and rootkits. Secure Boot helps ensure that the system runs only authentic software by verifying the digital signature of all boot components, and halts the boot process if signature verification fails.

Ensure that Security Posture dashboard is enabled for your Google Kubernetes Engine (GKE) clusters. This feature integrates with other cloud services such as Cloud Logging, Policy Controller, and Binary Authorization to provide visibility into vulnerabilities, misconfigurations, and compliance risks, helping to enhance cluster security and maintain regulatory compliance.

Ensure that your Google Kubernetes Engine (GKE) clusters are configured to use Shielded GKE Nodes to protect against rootkits and bootkits. Shielded GKE Nodes provide verifiable node identity and integrity through the use of Secure Boot, virtual trusted platform module (vTPM)-enabled measured boot, and integrity monitoring.

Ensure that encryption of in-transit data for Pod communications across Google Kubernetes Engine (GKE) cluster nodes is enabled with Customer-Managed Encryption Keys (CMEKs). This feature, which requires GKE Dataplane V2, provides additional encryption on top of the default VM NIC-level encryption using WireGuard.

Ensure that VPC-native traffic routing is enabled for your Google Kubernetes Engine (GKE) clusters. This feature enhances integration with Google Cloud's VPC, improving network performance, scalability, and security through the use of alias IP address ranges.

Ensure that workload vulnerability scanning is enabled for your Google Kubernetes Engine (GKE) clusters to help detect vulnerabilities in container images, ensure compliance with security standards, and protect your clusters from potential threats. When enabled, a vulnerability scanning pod is deployed to each node within your GKE cluster to conduct the scan.

Ensure that Workload Identity Federation is enabled for your Google Kubernetes Engine (GKE) clusters to securely connect to Google Cloud APIs from Kubernetes workloads. Workload Identity Federation enhances security, simplifies access management, and eliminates the need for less secure methods like service account keys.

Ensure that Access Approval is enabled within your Google Cloud Platform (GCP) account to allow your explicit approval whenever Google personnel need to access your GCP projects. Once enabled, you can delegate users within your organization to approve access requests through IAM. Requests will show the requester's name/ID via email or Pub/Sub message for approval.

Ensure that IAM roles with privileged administrative permissions are not assigned to IAM identities (users, groups, and service accounts) to promote least privilege and provide your members (principals) the minimal access required to perform their tasks. When IAM members have administrator privileges (Owner and Editor roles, or roles containing "Admin" or "admin" in their names), they can access, create, and manage cloud resources.

For production and security-critical cloud environments, limit the use of primitive roles such as "Owner", "Editor", and "Viewer" for Cloud IAM members. Instead, grant predefined roles to these IAM members to allow the least-permissive access required to perform their tasks (i.e., Principle of Least Privilege – POLP).

Ensure that the Service Account User and Service Account Token Creator roles are assigned to a user for a specific GCP service account rather than to a user at the GCP project level, in order to implement the principle of least privilege (POLP). The principle of least privilege (also known as the principle of minimal privilege) is the practice of providing every user the minimal amount of access required to perform its tasks. The Service Account User (iam.serviceAccountUser) role allows an IAM user to attach a service account to a long-running job service such as an App Engine App or Dataflow Job, whereas the Service Account Token Creator (iam.serviceAccountTokenCreator) role allows a user to directly impersonate the identity of a service account.

Ensure that IAM users with data decryption permissions should use conditions to enforce strict controls, enhancing data protection and reducing risks of unauthorized decryption. For compliance, the Cloud KMS CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter), Cloud KMS Crypto Operator (roles/cloudkms.cryptoOperator), and Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) roles must have a condition preventing data decryption with any KMS key.

Ensure that your Google Cloud user-managed service accounts are not using privileged (administrator) roles, in order to implement the principle of least privilege and prevent any accidental or intentional modifications that may lead to data leaks and/or data loss. A user-managed service account is an identity that a virtual machine (VM) instance or an application can use to run API requests on your behalf. GCP service accounts can create, modify, or delete resources only if you grant the necessary IAM permissions, at the project or resource level.

Ensure that your Google Cloud Platform (GCP) user-managed service accounts are using GCP-managed keys instead of user-managed keys for authentication. For user-managed key pairs, key management operations such as key storage, key distribution, key revocation, key recovery, and key rotation, as well as key protection against unauthorized access, are your responsibilities.

Ensure that the IAM policy associated with your Google Cloud Key Management Service (KMS) keys restricts anonymous and/or public access. The KMS cryptographic keys are controlled by Cloud IAM policies, which should not include bindings for "allUsers" and "allAuthenticatedUsers" to prevent public internet access.

Ensure that your external Application Load Balancers (ALBs) are configured to use Google-managed SSL certificates instead of self-signed certificates in order to avoid triggering browser warnings and adding distrust for users visiting your site.

Ensure that your web applications are using only approved external load balancers to comply with your organization's security and industry requirements. Using unapproved load balancers could expose your applications to vulnerabilities. The approved load balancers must be defined in the conformity rule settings, in the Trend Cloud One™ – Conformity account console.

Ensure that your Google Cloud HTTP(S) load balancers are configured to log all network traffic. Enabling logging on HTTP(S) load balancers is crucial for diagnosing issues and ensuring transparency in traffic management.

Ensure that the backend services associated with your Google Cloud load balancers are protected with edge security policies provided by the Cloud Armor service in order to shield your backend services from a range of potential attacks. Edge security policies let you control access to your cloud resources at the Google Cloud Platform (GCP) network edge.

This check scans SSL policies of Google Cloud HTTPS and SSL Proxy load balancers to identify insecure cipher suites. It ensures SSL policies use TLS 1.2 with secure profiles and exclude weak ciphers.

Ensure that data access audit logging is enabled for all critical service APIs in your Google Cloud project for security, compliance, and troubleshooting purposes. The critical service APIs that you can enable for your GCP project include but are not limited to Identity and Access Management (IAM) API (iam.googleapis.com), Compute Engine API (compute.googleapis.com), Cloud Storage (storage-component.googleapis.com), Google Cloud Pub/Sub API (pubsub.googleapis.com), Cloud Key Management Service (KMS) API (cloudkms.googleapis.com), and Cloud Logging API (logging.googleapis.com).

Checks if Cloud Logging buckets are configured with a global location scope to ensure centralized log management and consistent access control.

For security, reliability, and compliance purposes, ensure that your Cloud Logging buckets are configured with a data retention period of 365 days or more. A Cloud Logging bucket is a container that stores log data from cloud services such as Compute Engine and App Engine. The retention period represents the number of days to retain log data for a user-defined log bucket and also for the _Default log bucket.

Ensure there is at least one sink used to export copies of all the log entries available within your Google Cloud Platform (GCP) project. A sink is an object created to hold a log query and a destination. You can export logs by creating one or more log sinks that include a log query and an export destination. As Google Cloud Logging service receives new log entries, they are compared against each sink. If a log entry matches a sink object query, then a copy of the log entry is written to the sink's export destination.

Ensure that Google Cloud Logs Router data is encrypted with Customer-Managed Keys (CMKs) to provide full control over your data encryption and decryption process and to help meet compliance requirements. Using Cloud Key Management Service (Cloud KMS), you can create and manage your CMKs, ensuring secure and efficient encryption key management, controlled key rotation, and revocation mechanisms.

Ensure that each Google Cloud Platform (GCP) project has configured an alerting policy that is triggered each time a Virtual Private Cloud (VPC) network change is made. The log filter pattern used to recognize VPC network changes is "resource.type=gce_network AND protoPayload.methodName=beta.compute.networks.insert OR protoPayload.methodName=beta.compute.networks.patch OR protoPayload.methodName=v1.compute.networks.delete OR protoPayload.methodName=v1.compute.networks.removePeering OR protoPayload.methodName=v1.compute.networks.addPeering".

Ensure that IAM roles with administrative permissions are not assigned to IAM identities (users, groups, and service accounts) managing Cloud NAT resources. This helps enforce the Principle of Least Privilege (POLP) by granting members (principals) only the minimum access necessary to complete their tasks.

Ensure that logging is enabled for your Google Cloud NAT gateways in order to log NAT connections and errors for audit and troubleshooting purposes. When logging is enabled, a log entry is generated in two scenarios: when a network connection using NAT is successfully created and when a packet is dropped due to the unavailability of NAT ports.

Ensure that Cloud NAT is enabled for all private VPC subnets that require outbound access. Cloud NAT enables your VMs and container pods to establish outbound connections to the Internet or other Virtual Private Cloud (VPC) networks. It utilizes a Cloud NAT gateway to manage these connections efficiently.

Ensure that your Google Cloud NAT gateways are configured to use static reserved external IPs in order to maintain consistent outbound IP addresses, which are critical for services requiring IP allowlisting, auditing, or compliance.

Ensure that your Google Cloud NAT gateways are mapped only to specific VPC subnets to maintain controlled and secure outbound Internet access, minimize unintended traffic exposure, and optimize resource usage within your network design. This promotes network isolation and ensures adherence to your organization's stringent compliance requirements.

Ensure that your Google Cloud Pub/Sub topics are encrypted using Customer-Managed Encryption Keys (CMEKs) to have full control over the data encryption and decryption process. Customer-Managed Encryption Keys (CMEKs) allow you to create and manage your own encryption keys with Cloud Key Management Service (Cloud KMS).

Ensure that your Google Cloud Pub/Sub subscriptions are configured to allow access only to trusted GCP projects to protect against unauthorized cross-project access. The list with the trusted GCP projects must be defined in the conformity rule settings, in the Trend Cloud One™ – Conformity account console.

Ensure that each Google Cloud Pub/Sub subscription is configured to use a dead-letter topic (DLQ) to capture undeliverable messages. Pub/Sub subscriptions allow for a maximum number of delivery attempts. Messages that cannot be delivered after the maximum attempts are sent to the dead-letter topic, ensuring they can be reviewed and handled appropriately.

Identify any publicly accessible Pub/Sub topics within your Google Cloud account and update their IAM policy to prevent unauthorized access and sensitive data exposure. To achieve this, remove the bindings for "allUsers" and "allAuthenticatedUsers" members from your topic's IAM policy. "allUsers" is a special member identifier representing any user on the internet, including both authenticated and unauthenticated users. Similarly, "allAuthenticatedUsers" represents any user or service account that can sign in to Google Cloud Platform (GCP) with a Google account.

Ensure that all the Google Cloud APIs and services restricted within your organization are defined using the "Restrict allowed Google Cloud APIs and services" organization policy. This constraint policy helps you achieve regulatory compliance by defining the set of cloud services and APIs that cannot be used within your GCP organization.

Ensure that "Define Allowed External IPs for VM Instances" constraint policy is enforced at the GCP organization level in order to enable you to define the set of virtual machine (VM) instances that are allowed to use external IP addresses. This constraint helps you to minimize your instance's exposure to the Internet.

Ensure that "Disable Automatic IAM Grants for Default Service Accounts" policy is enforced for your Google Cloud Platform (GCP) organizations and projects in order to deactivate the automatic IAM role grant for default service accounts. When a default service account is created, it is automatically granted the Editor role ("roles/editor") on your project.

Ensure that "Skip Default Network Creation" constraint policy is enforced for your Google Cloud Platform (GCP) organizations in order to follow security best practices and meet networking requirements. Once enabled, this constraint skips the creation of the default Virtual Private Cloud (VPC) network and related resources during Google Cloud project creation.

Ensure that "Google Cloud Platform - Detailed Audit Logging Mode" policy is enforced at the organization level in order to enable Detailed Audit Logging feature for the supported Cloud Storage resources available within your GCP organization. When Detailed Audit Logging is enforced, both the request and response are included in Cloud Audit logs.

Ensure that "Disable Guest Attributes of Compute Engine Metadata" organization policy is enforced in order to disable Compute Engine API access to the guest attributes configured for the virtual machines instances that belong to your project, folder, or organization. Guest attributes are a specific type of custom metadata that your cloud applications can write to while running on your virtual machine (VM) instance.

Ensure that the virtual machine (VM) instances allowed to use IP forwarding, that belong to your project, folder, or organization, are defined using the "Restrict VM IP Forwarding" policy. This constraint policy helps you improve security and achieve regulatory compliance by explicitly defining the resource name of the VM instances allowed to use IP forwarding.

Ensure that only compliant load balancer types can be used to create Google Cloud load balancers for the GCP projects and folders within your organization. The list of allowed load balancer types can only include values from the following list: INTERNAL_TCP_UDP, INTERNAL_HTTP_HTTPS, EXTERNAL_NETWORK_TCP_UDP, EXTERNAL_TCP_PROXY, EXTERNAL_SSL_PROXY, EXTERNAL_HTTP_HTTPS.

Ensure that "Require OS Login" constraint policy is enforced at the GCP organization level in order to enable OS Login feature on all newly created Google Cloud projects within your organization. The OS Login provides you with centralized and automated SSH key pair management.

Ensure that the locations where location-based cloud resources can be created within your GCP organization are defined using the "Google Cloud Platform - Resource Location Restriction" organization policy. This constraint policy helps you achieve regulatory compliance by explicitly defining the locations allowed to deploy Google Cloud resources for your organization. You can specify multi-regions such as "asia" and "europe" and individual regions such as "us-east1" or "europe-west2" as allowed locations.

Ensure that the creation of Cloud IAM service accounts is prevented within your Google Cloud organization through the "Disable Service Account Creation" organization policy. This allows you to easily centralize the management of your service accounts while not restricting the other permissions that your developers and administrators have on the projects within the organization.

Ensure that the creation of user-managed service account keys is disabled within your Google Cloud project, folder, or the entire organization through the "Disable Service Account Key Creation" organization policy. This allows you to control the use of unmanaged long-term credentials for your Cloud IAM service accounts. When this resource constraint is enabled, user-managed keys cannot be created for service accounts in projects/folders/organizations affected by the constraint.

Ensure that user-managed service account key upload is disabled within your Google Cloud project, folder, or the entire organization, through the "Disable Service Account Key Upload" organization policy. This allows you to control the upload process of unmanaged long-term credentials for your Cloud IAM service accounts. By default, users can upload keys to service accounts based on their Cloud IAM roles and permissions.

Ensure that the set of shared VPC subnetworks that eligible Google Cloud resources can use, are defined using the "Restrict Shared VPC Subnetworks" constraint policy. The allowed list of VPC subnetworks must be specified in the following form: projects/<project-id>/regions/<subnetwork-region>/subnetworks/<subnetwork-name>. You can also define the list of allowed subnetworks in a project, folder, or organization.

Ensure that "Restrict Authorized Networks on Cloud SQL instances" policy is enforced for your Google Cloud Platform (GCP) organization to deny IAM members to add authorized networks in order to provide access to your security-critical SQL database instances. By default, authorized networks can be added to any Cloud SQL database instance.

Ensure that the use of Google-managed encryption keys for Cloud SQL database instances is disabled at the GCP organization level in order to enforce the use of Customer-Managed Keys (CMKs) and have full control over SQL database encryption/decryption process. Note: This organization policy is not retroactive, therefore any existing database instances using Google-managed encryption are not impacted unless they are updated or refreshed.

Ensure that "Restrict Public IP access on Cloud SQL instances" policy is enforced for your Google Cloud organizations. Due to strict security and compliance regulations, you can't allow GCP members to configure security-critical database instances with public IPs. For highly sensitive workloads, the access to the SQL database instances can be made only through private IP addresses or Google Cloud SQL Proxy.

Ensure that only images from trusted Google Cloud Platform (GCP) projects are allowed as the source for boot disks for new virtual machine instances. By enforcing the "Define Trusted Image Projects" policy at the GCP organization level, you can restrict access to disk images so that project members can create boot disks only from images that contain approved software meeting strict security requirements.

Ensure that "Enforce uniform bucket-level access" policy is enabled for your Google Cloud Platform (GCP) organization in order to enforce uniform bucket-level access for all Google Cloud Storage buckets available in your organization. Enforcing uniform bucket-level access disables Access Control Lists (ACLs) for all Cloud Storage resources (buckets and objects) so that access is granted exclusively through Cloud IAM service.

Ensure that the VPC networks that are allowed to be peered with the networks created for your project, folder, or organization, are defined using the "Restrict VPC Peering Usage" constraint policy. This constraint helps you achieve regulatory compliance by explicitly defining the resource name of each Virtual Private Cloud (VPC) network allowed for VPC peering.

Ensure that only trusted IPv4 addresses can be configured as VPN peer IPs within your Google Cloud organization. By enforcing the "Restrict VPN Peer IPs" constraint policy, you can control the IP addresses that can be configured as VPN peer IPs within your Google Cloud organization in order to meet security and compliance requirements.

Ensure that "Disable Workload Identity Cluster Creation" policy is enforced at the GCP organization level in order to require that any new Google Kubernetes Engine (GKE) clusters have the Workload Identity feature disabled at the time of their creation. This constraint policy is useful when you want to tightly control service account access in your organization by disabling Workload Identity in addition to service account creation and service account key creation.

Ensure that user-defined labels are being used to tag, collect, and organize Cloud Run services within your Google Cloud Platform (GCP) projects. User-defined labels are a lightweight and efficient way to group together related or associated cloud resources.

Ensure that the local_infile database flag is disabled for your Google Cloud MySQL database instances in order to follow data security best practices. The local_infile flag allows loading data from a local file to a database table, which could pose a security risk if misused.

Ensure that the Point-in-Time Recovery (PITR) feature is enabled for all MySQL database instances deployed within your Google Cloud Platform (GCP) account. This feature allows you to recover data from a specific point in time at a minimal cost. Automated backups and binary logging must be enabled for your MySQL database instances to use PITR.

Ensure that the "slow_query_log" database flag is enabled for your Google Cloud MySQL database instances in order to simplify the task of finding inefficient or time-consuming SQL queries for your MySQL databases. By default, the "slow_query_log" database flag is not enabled for Google Cloud MySQL instances.

Ensure that the "log_error_verbosity" database flag configured for your Google Cloud PostgreSQL database instances is set to DEFAULT or to a stricter value. The "log_error_verbosity" flag determines the level of detail recorded in the server log for logged messages. Valid values are TERSE, DEFAULT, and VERBOSE, with TERSE being the most restrictive and VERBOSE providing the most detail.

Ensure that the log_executor_stats database flag is turned off for your Google Cloud PostgreSQL database instances in order to avoid performance issues caused by excessive logging. The log_executor_stats flag enables a crude profiling method for logging PostgreSQL executor performance statistics. The PostgreSQL executor is responsible for executing the plan handed over by the PostgreSQL planner/optimizer. The task of the PostgreSQL planner/optimizer is to create an optimal execution plan.

Ensure that the log_min_duration_statement database flag is set to -1 (i.e., disabled) for all your Google Cloud PostgreSQL database instances. The log_min_duration_statement flag controls the minimum execution time of a statement for it to be logged. Setting it to any value other than -1 can result in excessive logging and potential performance issues.

Ensure that the "log_min_error_statement" database flag configured for your Google Cloud PostgreSQL database instances has the appropriate severity level in accordance with your organization's logging policy. The "log_min_error_statement" flag defines the minimum severity level for error statements to be logged. Valid levels include DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC.

Ensure that the "log_min_messages" database flag configured for your Google Cloud PostgreSQL database instances has the appropriate severity level in accordance with your organization's logging policy. The "log_min_messages" flag defines the minimum severity level for messages to be logged. Valid levels include DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC.

Ensure that the "log_parser_stats" database flag is turned off for your Google Cloud PostgreSQL database instances in order to avoid performance issues caused by excessive logging. The PostgreSQL planner (PostgreSQL optimizer) is responsible for parsing and verifying the syntax of each query received by the database server. If the syntax is correct, a parse tree is built up; otherwise, an error is generated. The "log_parser_stats" flag controls the inclusion of parser performance statistics within PostgreSQL logs for each query made to the database.

Ensure that the log_planner_stats database flag is disabled for your Google Cloud PostgreSQL database instances in order to avoid performance issues caused by excessive logging. The log_planner_stats flag controls the inclusion of PostgreSQL planner performance statistics in the PostgreSQL logs for each query.

Ensure that the "log_statement" database flag configured for your Google Cloud PostgreSQL database instances has the appropriate value (logging level) in accordance with your organization's logging policy. The "log_statement" flag controls which SQL statements are logged, with valid values being: none, ddl, mod, and all.

Ensure that the "log_statement_stats" database flag is disabled for your Google Cloud PostgreSQL database instances in order to avoid performance issues caused by excessive logging. The "log_statement_stats" configuration flag controls the inclusion of end-to-end performance statistics within PostgreSQL logs for each SQL query.

Ensure that the "log_hostname" database flag is enabled for your Google Cloud PostgreSQL database instances in order to assist with incident response and tracking usage in an environment utilizing dynamic IP addresses. There is a potential cost to server performance caused by hostname logging.

Ensure that the "log_temp_files" database flag is set to 0 (enabled) for all your Google Cloud PostgreSQL database instances. PostgreSQL database engine can create temporary files for actions such as sorting, hashing, and temporary query results when these operations exceed the amount of memory specified for the "work_mem" setting. Setting "log_temp_files" flag to 0 causes all temporary file information to be logged, while positive configuration values log only files whose size is greater than or equal to the specified number of kilobytes.

Ensure that the Automatic Storage Increase feature is enabled for your production Google Cloud SQL database instances. This feature prevents database servers from running out of storage space and becoming read-only, disrupting normal operations. When a database instance runs out of available space, it can drop existing connections and cause downtime, potentially violating the Google Cloud SQL Service Level Agreement (SLA).

Ensure that an optimal limit is configured for the Automatic Storage Increase feature within your Cloud SQL database instance settings to avoid unexpected charges on your Google Cloud bill. Having no limit or an excessively high limit for this feature can lead to unplanned costs.

Ensure that automated (scheduled) backups are created for all Cloud SQL database instances available within your Google Cloud Platform (GCP) account, in order to protect against data deletion and/or data corruption.

Ensure that your Google Cloud SQL database instances are encrypted with Customer-Managed Keys (CMKs) in order to have a fine control over your data encryption and decryption process. You can create and manage your own Customer-Managed Keys (CMKs) with Cloud Key Management Service (Cloud KMS). Cloud KMS provides secure and efficient encryption key management, controlled key rotation, and revocation mechanisms.

Ensure that the "contained database authentication" database flag is disabled for your Google Cloud SQL Server database instances. This flag, when enabled, allows databases to contain their authentication and can potentially lead to security vulnerabilities.

Ensure that the "cross db ownership chaining" database flag is disabled for your Google Cloud SQL Server database instances. This flag, when enabled, can potentially introduce security risks by allowing cross-database access without explicit permissions.

Ensure that your Google Cloud SQL database instances are configured to use private IP addresses instead of public IPs to protect against potential security risks and unauthorized access.

Ensure that the external scripts enabled database flag is turned off for your Google Cloud SQL Server database instances in order to disable the execution of scripts with certain remote language extensions.

Ensure that all your production and mission-critical Google Cloud SQL database instances are configured for High Availability (HA) and automatic failover support. Configuring HA ensures database reliability and minimizes downtime in the event of an outage.

Ensure that the "log_checkpoints" database flag is enabled for your Google Cloud PostgreSQL database instances. The "log_checkpoints" flag allows checkpoints and restart points to be logged and included within the PostgreSQL server log.

Ensure that the "log_connections" database flag is enabled for your Google Cloud PostgreSQL database instances. The "log_connections" flag causes each attempted connection to the database instance to be logged, including successful client authentication requests. This flag helps with monitoring and auditing database access. Only PostgreSQL database administrators can change this parameter at session start, and it cannot be changed after the session starts.

Ensure that the "log_lock_waits" database flag is enabled for all your Google Cloud PostgreSQL database instances to improve database performance monitoring and troubleshooting.

Ensure that the "cloudsql.enable_pgaudit" and "pgaudit.log" database flags are enabled for your Google Cloud PostgreSQL server instances to enable database auditing. These configurations are crucial for compliance with government, financial, and ISO certifications.

Ensure that your Google Cloud SQL database instances are configured to accept connections only from trusted networks and IP addresses. Publicly accessible instances may expose sensitive data to unauthorized access.

Ensure that the "remote access" database flag is turned off for your Google Cloud SQL Server database instances. This prevents the execution of stored procedures from local or remote servers on which your SQL Server instances are running, improving security and compliance.

Ensure that the "skip_show_database" database flag is enabled for your Google Cloud MySQL database instances in order to prevent users from using the SHOW DATABASES statement if they don't have this privilege.

Enforce all incoming connections to your Cloud SQL database instances to use SSL/TLS only. If the SSL/TLS protocol is not enforced for all Cloud SQL connections, clients without a valid certificate are allowed to connect to the database, leading to potential security vulnerabilities.

Ensure that all incoming connections to your Cloud SQL database instances are encrypted with SSL/TLS to protect against eavesdropping and unauthorized access. The SSL enforcement mode must be set to "ENCRYPTED_ONLY" to enforce secure connections.

Ensure that the 3625 trace flag is turned off for all your Google Cloud SQL Server database instances to follow security best practices. Trace flag 3625 controls the format of certain error messages, which may reveal sensitive information if enabled.

Ensure that all retention policies attached to your Google Cloud log sink buckets are configured with the Bucket Lock feature. This prevents logging data from being overwritten or deleted and ensures compliance with data retention policies by locking the retention configuration.

Ensure that the IAM policy associated with your Google Cloud Storage buckets does not grant privileged, administrative permissions. This promotes the Principle of Least Privilege (POLP) by providing principals only the minimal access required to perform their tasks.

Ensure that website index (main) page suffix and error (404 not found) page are defined for your Google Cloud Storage buckets with static website configuration. Specifying these configurations ensures proper functionality and user experience for websites hosted on Cloud Storage buckets.

Ensure that Data Access audit logs are enabled for your Google Cloud Storage buckets and objects to track read, write, and admin operations. Data Access audit logs provide insights into resource usage and help ensure security, compliance, and effective troubleshooting.

Ensure that the objects stored within your Google Cloud Storage buckets have a sufficient data retention period configured to meet security and compliance requirements. Retention policies prevent the deletion or modification of objects for a specified duration.

Ensure that your Google Cloud Storage buckets are configured with lifecycle management rules to optimize object management and reduce storage costs. Lifecycle management rules help automate actions such as downgrading or deleting older objects based on user-defined conditions.

Ensure that your Google Cloud Storage data is encrypted at rest using Customer-Managed Keys (CMKs) to maintain full control over your data encryption and decryption processes. CMKs can be managed with the Cloud Key Management Service (Cloud KMS).

Ensure that your Cloud Storage buckets are configured with object versioning to protect your object data from being overwritten or accidentally deleted. Object versioning allows multiple variants of an object to be stored in the same bucket, enabling data recovery and restoration.

Ensure that the Public Access Prevention feature is enabled for your Google Cloud Storage buckets to restrict public access and protect sensitive data from accidental or malicious exposure.

Ensure that the IAM policy associated with your Google Cloud Storage buckets is restricting anonymous and/or public access. The IAM policy should not include bindings for "allUsers" or "allAuthenticatedUsers" to prevent unauthorized access to sensitive data.

Ensure that Cross-Origin Resource Sharing (CORS) configuration set for your Google Cloud Storage buckets only allows trusted origins to prevent unauthorized data access from web applications. The trusted, authorized origins must be configured according to your organization's policy.

Ensure that usage and storage logs are enabled for your Google Cloud Storage buckets to monitor activity, track costs, detect suspicious behavior, and ensure compliance with security and audit requirements.

Ensure that uniform bucket-level access is enabled for all your Google Cloud Storage buckets. This ensures that object access is controlled entirely through bucket-level IAM permissions, providing a consistent and secure way to manage access to bucket data.

Ensure that VPC Service Controls are used to configure a security perimeter around your Google Cloud Storage buckets to prevent data exfiltration and enhance the security posture of your cloud environment.

Ensure that automatic upgrades for Vertex AI Workbench notebook instances are enabled to get the latest features, performance improvements, and security updates without manual intervention. Once auto-upgrades are enabled, Vertex AI Workbench will check, during a recurring time period that you specify, whether your notebook instances can be upgraded, and if so, the service will upgrade your instances.

Ensure that your Google Cloud Vertex AI notebook instances are not created within the default Virtual Private Cloud (VPC) network. The default VPC comes with predefined, over-permissive firewall rules that are not included in audit logging. While suitable for quick starts, complex production AI applications with multi-tier architectures may require private network segments or customization.

Ensure that external IP addresses are not assigned to your Google Cloud Vertex AI notebook instances, in order to help prevent data exfiltration, maintain network isolation, and meet stringent compliance requirements. Vertex AI notebook instances with an assigned external IP address can communicate with the public internet or resources in other VPC networks, which may violate security policies.

Ensure that the Idle Shutdown feature is enabled for your Google Cloud Vertex AI notebook instances to optimize costs. Inactive notebook instances continue to incur charges, and Idle Shutdown automatically stops them after a period of inactivity (i.e., no running commands or UI connections), reducing unneeded spending. Vertex AI stops charging for CPUs/GPUs once the notebook instance is shut down.

Ensure that the Integrity Monitoring feature is enabled for your Google Cloud Vertex AI notebook instances to automatically check and monitor the runtime boot integrity of your shielded notebook instances using Google Cloud Monitoring. The feature requires Virtual Trusted Platform Module (vTPM) and helps ensure that the boot loader on your instances remains untampered.

Ensure that Cloud Monitoring is enabled for your Vertex AI notebook instances in order to gain visibility into their health and performance. Cloud Monitoring reports system and application metrics such as disk, CPU, network, and processes. This allows you to identify issues like resource bottlenecks or errors proactively. To enable the monitoring feature, you must install the Cloud Monitoring agent when you create your notebook instance.

Ensure that root access to your Google Cloud Vertex AI notebook instances is disabled in order to reduce the risk of accidental or malicious system damage by limiting administrative privileges within the instances. Disabling root access minimizes the risk of unauthorized modifications and helps maintain a more controlled and secure AI environment.

Ensure that the Secure Boot security feature is enabled for your Vertex AI notebook instances in order to protect them against malware and rootkits. Secure Boot helps ensure that the system runs only authentic software by verifying the digital signature of all boot components, and halts the boot process if the signature verification fails. Secure Boot is disabled by default because of the third-party unsigned kernel modules that can't be loaded when the feature is enabled.

Ensure that the Virtual Trusted Platform Module (vTPM) feature is enabled for your Vertex AI notebook instances in order to protect them against persistent and advanced attacks. vTPM safeguards the guest VM's boot process by validating its integrity before and during startup. Additionally, it provides secure generation and protection for encryption keys.

Ensure that your Google Cloud Platform (GCP) projects are not using legacy networks. Legacy networks are no longer recommended for production environments as they do not support advanced networking features. It is strongly advised to use Virtual Private Cloud (VPC) networks instead.

Ensure that your Google Cloud Platform (GCP) projects are not using the default Virtual Private Cloud (VPC) network. Using the default VPC network does not adhere to security best practices and may not meet specific networking requirements.

Ensure that Cloud DNS logging is enabled for all your Virtual Private Cloud (VPC) networks using DNS server policies. Cloud DNS logging records DNS queries resolved by name servers for VPC networks, as well as queries to public DNS zones from external entities.

Ensure that VPC Flow Logs is enabled for every subnet created within your production Virtual Private Cloud (VPC) network. Flow Logs capture information about the IP traffic (accepted, rejected, or all traffic) to and from the network interfaces within your VPC subnets.

Ensure that Virtual Private Cloud (VPC) firewall logging is not configured to include logging metadata to reduce log file size and optimize cloud storage costs. Including metadata in firewall logs can lead to unnecessary storage costs without significant benefits.

Enable Virtual Private Cloud (VPC) firewall rule logging for each firewall rule whose connections you need to log. Firewall rule logging provides valuable insights into the source and destination of traffic, protocols, ports, and actions taken by the rules.

Ensure that Google Cloud VPC network firewall rules do not allow unrestricted access (0.0.0.0/0) on TCP and UDP port 53. Restrict DNS traffic to trusted IP addresses or ranges to reduce the attack surface and enhance security.

Ensure that Virtual Private Cloud (VPC) firewall rules do not allow unrestricted access (0.0.0.0/0) on TCP ports 20 and 21. Restrict FTP traffic to trusted IP addresses or IP ranges to reduce the attack surface and enhance security.

Ensure that your Google Cloud VPC network firewall rules do not allow unrestricted access (0.0.0.0/0) using ICMP. Restrict ICMP-based access to trusted IP addresses or IP ranges to implement the principle of least privilege (POLP) and reduce the attack surface.

Ensure that your Virtual Private Cloud (VPC) firewall rules do not allow unrestricted access (0.0.0.0/0) to any uncommon ports to protect against brute force attacks targeting virtual machine instances associated with these firewall rules. Uncommon ports are TCP/UDP ports not included in the common service ports category.

Ensure that Google Cloud VPC network firewall rules do not allow unrestricted access (0.0.0.0/0 on TCP port 3306). Restrict MySQL traffic to trusted IP addresses or IP ranges to reduce the attack surface and enhance security.

Ensure that Google Cloud VPC network firewall rules do not allow unrestricted access (0.0.0.0/0 on TCP port 1521). Restrict Oracle Database traffic to trusted IP addresses or IP ranges to reduce the attack surface and enhance security.

Check your Google Cloud VPC network firewall for any egress rules that allow unrestricted access (0.0.0.0/0) to any TCP/UDP ports. Restrict outbound traffic to only those IP addresses and/or IP ranges that require it in order to implement the principle of least privilege and reduce the attack surface.