Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Publicly accessible resources are susceptible to distributed denial of service (DDoS) attacks and expose data to unauthorized access, tampering, and potential theft.

Publicly accessible resources are susceptible to distributed denial of service (DDoS) attacks and expose data to unauthorized access, tampering, and potential theft.

Publicly accessible resources are susceptible to distributed denial of service (DDoS) attacks and expose data to unauthorized access, tampering, and potential theft.

By default, a Compute Engine instance is not a Confidential VM. A Confidential VM uses hardware-based cryptography for data-in-use protection and to support remote attestations. Non-exportable dedicated per-VM instance keys keep VM memory encrypted, thereby protecting VM confidentiality and integrity against cloud provider access via the higher-privileged hypervisor.

Example 1: The following example shows a Terraform configuration that disables Confidential VM by setting enable_confidential_compute to false.

resource "google_compute_instance" "default" {
  ...
  confidential_instance_config {
    enable_confidential_compute = false
  }
  ...
}

By default, Edge Cache services accept unencrypted and unsecured connections. These connections expose data to unauthorized access, potential theft, and tampering.

Example 1: The following example shows a Terraform configuration that defines an Edge Cache Service that allows clients to use HTTP for communication by setting https_redirect to false.

resource "google_network_services_edge_cache_service" "srv_demo" {
...
  routing {
...
    path_matcher {
...
      route_rule {
...
        url_redirect {
          https_redirect = false
        }
      }
    }
  }
}

By default, an App Engine application accepts unencrypted and unsecured connections. These connections expose data to unauthorized access, potential theft, and tampering.

By default, a Cloud SQL instance accepts unencrypted and unsecured connections. These connections expose data to unauthorized access, potential theft, and tampering.

Example 1: The following example shows a Terraform configuration that does not require a database instance to enforce SSL for all connections by setting require_ssl to false.

resource "google_sql_database_instance" "database_instance_demo" {
  ...
  settings {
    ip_configuration {
      require_ssl = false
      ...
    }
    ...
  }
}

By default, an Edge Cache service accepts unencrypted and unsecured connections. These connections expose data to unauthorized access, potential theft, and tampering.

Example 1: The following example shows a Terraform configuration that defines an Edge Cache service that does not require clients to use TLS for communication by setting require_tls to false.

resource "google_network_services_edge_cache_service" "srv_demo" {
...
  require_tls = false
...
}

A URL map is a set of rules to route incoming HTTP(S) requests to specific backend services. By default, a URL map accepts unencrypted and unsecured connections. These connections expose data to unauthorized access, potential theft, and tampering.

Example 1: The following example shows a Terraform configuration that defines a URL map that allows clients to use HTTP for communication by setting https_redirect to false.

resource "google_compute_url_map" "urlmap" {
...
  default_url_redirect {
...
    https_redirect = false
...
  }
...
}

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions that result in periodic version updates. Each new revision addresses security weaknesses discovered in the previous version. Use of an insecure version of TLS/SSL weakens the strength of the data protection and might allow an attacker to compromise, steal, or modify sensitive information.

Insecure versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing

The presence of these properties might enable an attacker to intercept, modify, or tamper with sensitive data.

Every cloud service security feature has a unique ability to prevent or mitigate a known threat. Any feature disabled by intent or mistake offers no protection.

Disabling any Shield VM option allows an attacker to bypass implemented security restrictions for a guest operating system on a Compute Engine instance. Recommended Shield VM options (and their corresponding Terraform configuration identifiers) are as follows:

- Integrity Monitoring (enable_integrity_monitoring)
- Secure Boot (enable_secure_boot)
- Virtual Trusted Platform Module (enable_vtpm)

Example 1: The following Terraform configuration sets enable_integrity_monitoring to false in the shielded_instance_config block. Not all recommended Shield VM options are enabled.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  shielded_instance_config {
    enable_integrity_monitoring = false
    enable_secure_boot = true
    enable_vtpm = true
  }
  ...
}

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.