DNSSEC evita la falsificación de DNS al proporcionar la capacidad de usar firmas digitales para la validación de respuestas de DNS. La DNSSEC de un dominio DNS en la nube no está habilitada.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que deshabilita la DNSSEC en un dominio DNS en la nube configurando state en off en el bloque dnssec_config.

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    state = "off"
    ...
  }
...
}

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

Otorgar a allUsers o allAuthenticatedUsers una función CryptoKey de Cloud KMS le brinda a cualquier persona acceso a datos confidenciales.

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

Las copias de seguridad de la base de datos son fundamentales para ofrecer protección contra la pérdida o corrupción de los datos. Las copias de seguridad automáticas de una instancia de base de datos de Cloud SQL deben configurarse y habilitarse explícitamente.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que deshabilita las configuraciones de copia de seguridad de la instancia de la base de datos configurando enabled en false.

resource "google_sql_database_instance" "database_instance_demo" {
  ...
  settings {
    backup_configuration {
      enabled = false
      ...
    }
  }
}

Si no se bloquea el tráfico de red no deseado, se amplía la superficie de ataque de un servicio en la nube. Los servicios abiertos a la interacción con el público están sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

De forma predeterminada, Terraform implementa una instancia de Google Cloud SQL Database que solo acepta conexiones de direcciones IP privadas. La configuración opcional de Redes autorizadas define rangos aceptables de direcciones IP públicas.

Ejemplo 1: La siguiente configuración de Terraform establece value como 0.0.0.0/0 en el bloque authorized_networks. Un bloque CIDR de /0 acepta conexiones desde cualquier dirección IP entre 0.0.0.0 y 255.255.255.255.

resource "google_sql_database_instance" "db-demo" {
  ...
  settings {
  ...
    ip_configuration {
    ...
      authorized_networks {
        name  = "any ip"
        value = "0.0.0.0/0"
      }
    ...
    }
    ...
  }
  ...
}

Al otorgar a allUsers o allAuthenticatedUsers una función de almacenamiento en la nube, cualquier persona puede acceder a datos confidenciales.

La mala gestión de los permisos aumenta el riesgo de acceso no autorizado o modificación de datos restringidos.

Para definir el permiso de usuario para acceder a depósitos y objetos en depósitos, Google Cloud Storage ofrece dos sistemas: Listas de control de acceso (ACL) y gestión de acceso e identidad (IAM). IAM se puede usar en todo Google Cloud, mientras que solo Cloud Storage admite ACL. Habilitar el acceso uniforme a nivel de depósito evita que las ACL otorguen permisos. Esto garantiza que IAM sea el único sistema para administrar todo el control de acceso a los recursos de Google Cloud.

Ejemplo 1: La siguiente configuración de Terraform permite el uso de ACL junto con IAM para otorgar acceso al depósito de almacenamiento configurando uniform_bucket_level_access como false.

resource "google_storage_bucket" "bucket-demo" {
...
  uniform_bucket_level_access = false
...
}

El control de acceso basado en IAM reduce los errores humanos y promueve la eficiencia. Habilitar el inicio de sesión del sistema operativo permite el uso de roles de IAM para automatizar la administración del ciclo de vida de las cuentas de Linux para acceder a todas las instancias de Compute Engine en el mismo proyecto u organización.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que deshabilita el uso de roles de IAM para administrar el acceso SSH configurando enable-oslogin en false en el argumento metadata.

resource "google_compute_instance" "compute-instance-demo" {
  ...
  metadata = {
    enable-oslogin = false
    ...
  }
  ...
}

Si se crea una instancia de Compute Engine sin una especificación de cuenta de servicio administrada por el usuario, Google Cloud asigna una cuenta de servicio predeterminada a la instancia. Los derechos de acceso de la cuenta de servicio predeterminada a menudo van más allá de lo que la instancia necesita para operar. Esto viola el principio de privilegio mínimo.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que crea una instancia de Compute Engine sin una especificación de cuenta de servicio administrada por el usuario. Falta el bloque service_account.

resource "google_compute_instance" "instance-demo" {
    name = "name-demo"
    machine_type = "e2-micro"
    boot_disk {
    ...
    }
    network_interface {
    ...
    }
}

Si no se bloquea el tráfico de red no deseado, se amplía la superficie de ataque de un servicio en la nube.

De manera predeterminada, el reenvío de IP está deshabilitado en una instancia de Compute Engine. El reenvío de IP permite enviar y recibir paquetes con direcciones IP de origen o destino que no coinciden. Un atacante puede explotar esto enrutando paquetes a través de la instancia de Compute Engine para eludir el control de acceso a la red.

Ejemplo 1: La siguiente configuración de Terraform habilita el reenvío de IP configurando can_ip_forward como true.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  can_ip_forward = true
  ...
}

Por defecto, una instancia de Compute Engine no es una máquina virtual confidencial. Una máquina virtual confidencial utiliza criptografía basada en hardware para la protección de datos en uso y para admitir certificaciones remotas. Las claves de instancia por máquina virtual dedicadas no exportables mantienen la memoria de la máquina virtual encriptada, y protegen así la confidencialidad e integridad de la máquina virtual contra el acceso del proveedor de la nube a través del hipervisor con privilegios más altos.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que deshabilita la máquina virtual confidencial configurando enable_confidential_compute en false.

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

De forma predeterminada, Google Cloud Compute Engine cifra todos los datos en reposo. Una clave de cifrado proporcionada por el cliente (CSEK), si se especifica, cifra las claves de cifrado de datos. Google no almacena ninguna CSEK en una instancia de Compute Engine y no puede acceder a los datos protegidos a menos que se proporcione la CSEK correcta.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que define un disco persistente para una instancia de Compute Engine. Falta el bloque disk_encryption_key, por lo que no hay CSEK para proteger las claves de cifrado de datos.

resource "google_compute_disk" "compute-disk-demo" {
    name  = "test-disk"
    type  = "pd-ssd"
}

De manera predeterminada, puede usar las claves SSH almacenadas en los metadatos del proyecto para acceder a todas las instancias de Compute Engine en un proyecto. Esto amplía en gran medida la superficie de ataque accesible a cualquier clave SSH comprometida y viola el principio de privilegio mínimo.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que permite inicios de sesión SSH en todo el proyecto configurando block-project-ssh-keys en false en el argumento metadata.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  metadata = {
    block-project-ssh-keys = false
    ...
  }
  ...
}

Si no se bloquea el tráfico de red no deseado, se amplía la superficie de ataque de un servicio en la nube. Los servicios abiertos a la interacción con el público están sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

De forma predeterminada, el puerto serie de una instancia de Compute Engine está deshabilitado para el acceso a la consola. Habilitar el acceso a la consola en serie puede permitir que los atacantes se conecten a la instancia de Compute Engine desde cualquier dirección IP porque el puerto en serie no admite restricciones de acceso basadas en IP.

Ejemplo 1: La siguiente configuración de Terraform permite el acceso a la consola en serie interactiva configurando serial-port-enable como true en el argumento metadata.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  metadata = {
    serial-port-enable = true
    ...
  }
  ...
}

Cada característica de seguridad del servicio en la nube tiene una capacidad única para prevenir o mitigar una amenaza conocida. Cualquier característica deshabilitada por intención o error no ofrece protección.

Deshabilitar cualquier opción de Shield VM permite a un atacante eludir las restricciones de seguridad implementadas para un sistema operativo invitado en una instancia de Compute Engine. Las opciones de Shield VM recomendadas (y sus correspondientes identificadores de configuración de Terraform) son las siguientes:

- Monitoreo de integridad (enable_integrity_monitoring)
- Arranque seguro (enable_secure_boot)
- Módulo de plataforma virtual de confianza (enable_vtpm)

Ejemplo 1: La siguiente configuración de Terraform establece enable_integrity_monitoring como false en el bloque shielded_instance_config. No todas las opciones de Shield VM recomendadas están habilitadas.

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

Por defecto, los servicios Edge Cache aceptan conexiones no cifradas y no seguras. Esto expone los datos a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que define un servicio Edge Cache que permite a los clientes usar HTTP para la comunicación configurando https_redirect en false.

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

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

El plano de control de GKE toma decisiones globales sobre un clúster y, de forma predeterminada, muchos de sus puntos finales de API son de acceso público. Agregar redes autorizadas mediante una lista de permitidos puede brindar protección a la red para el acceso al plano de control.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform establece un clúster público sin definir ninguna red autorizada en el bloque master_authorized_networks_config. Como resultado, los puntos finales de la API del plano de control de GKE son de acceso público.

resource "google_container_cluster" "cluster_demo" {
  name = "name-demo"
}

De forma predeterminada, la autenticación basada en certificados está deshabilitada en los nuevos clústeres que ejecutan GKE en la versión 1.12 y posteriores. Con la autenticación basada en certificados, un usuario presenta un certificado que el servidor API de Kubernetes verifica con la autoridad de certificación especificada. Sin embargo, no hay forma de revocar el certificado cuando el usuario abandona o pierde las credenciales. Esto hace que la autenticación basada en certificados no sea adecuada para los usuarios finales.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform habilita la autenticación basada en certificados de clientes de GKE configurando issue_client_certificate en true en el bloque master_auth.

resource "google_container_cluster" "container_cluster_demo" {
...
  master_auth {
    client_certificate_config {
      issue_client_certificate = true
      ...
    }
    ...
  }
...
}