Por defecto, una aplicación App Engine acepta conexiones no cifradas y no seguras. Esto expone los datos a accesos no autorizados, posibles robos y manipulaciones.

Por defecto, un desencadenador HTTP permite que una función en la nube se ejecute únicamente en respuesta a solicitudes HTTPS. Al permitir las solicitudes HTTP no seguras se exponen los datos a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que define un desencadenador HTTP que no aplica puntos finales HTTPS configurando https_trigger_security_level en SECURE_OPTIONAL.

resource "google_cloudfunctions_function" "demo_function" {
...
  trigger_http = true
  https_trigger_security_level = "SECURE_OPTIONAL"
...
}

De manera predeterminada, una instancia de Cloud SQL acepta 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 no requiere una instancia de base de datos para aplicar SSL en todas las conexiones configurando require_ssl en false.

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

Por defecto, un servicio Edge Cache acepta 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 no requiere que los clientes usen TLS para la comunicación configurando require_tls en false.

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

El protocolo Seguridad de la capa de transporte (TLS) y el protocolo Capa de sockets seguros (SSL) ofrecen un mecanismo de protección para garantizar la autenticidad, la confidencialidad y la integridad de los datos transmitidos entre un cliente y el servidor web. Los protocolos TLS y SSL han sufrido varias revisiones que dan como resultado actualizaciones periódicas de versión. Cada nueva revisión aborda las deficiencias de seguridad halladas en la versión previa. El uso de versiones de los protocolos TLS/SSL inseguras debilita la protección de los datos y podría permitir a un atacante poner en peligro, robar o modificar información confidencial.

Los protocolos TLS/SSL débiles se caracterizan por alguna o todas las propiedades siguientes:

- No protegen ante los ataques "man-in-the-middle"
- Se usa la misma clave para autenticación y cifrado
- Débil control de autenticación de mensajes
- No protegen ante el cierre de conexión TCP

La presencia de estas propiedades puede permitir que un atacante intercepte, modifique o manipule datos confidenciales.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform define una política SSL que permite que el equilibrador de carga del proxy permita el uso de conjuntos de cifrado SSL débiles configurando profile en COMPATIBLE.

resource "google_compute_ssl_policy" "policy-demo" {
...
  profile = "COMPATIBLE"
...
}

Ejemplo 2: El siguiente ejemplo de configuración de Terraform define una política SSL personalizada, que permite específicamente que el equilibrador de carga del proxy permita el uso de un conjunto de cifrado SSL débil denominado TLS_RSA_WITH_AES_128_CBC_SHA.

resource "google_compute_ssl_policy" "policy-demo" {
...
  profile = "CUSTOM"
  min_tls_version = "TLS_1_2"
  custom_features = ["TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256", "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_128_CBC_SHA"]
...
}

La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

Los valores de configuración que socavan las capacidades de registro incluyen, entre otros:
- deshabilitar deliberadamente el registro de auditoría
- excluir acciones de usuarios, grupos o procesos específicos del registro
- proteger inadecuadamente la integridad del registro
- no habilitar el registro de auditoría opcional
- reducir la frecuencia de muestreo del registro

La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

Los valores de configuración que socavan las capacidades de registro incluyen, entre otros:
- deshabilitar deliberadamente el registro de auditoría
- excluir acciones de usuarios, grupos o procesos específicos del registro
- proteger inadecuadamente la integridad del registro
- no habilitar el registro de auditoría opcional
- reducir la frecuencia de muestreo del registro

Una configuración de Terraform crea un depósito de almacenamiento en la nube sin habilitar los registros de uso y almacenamiento. Estos registros contienen datos valiosos para el monitoreo de la red, análisis forense, análisis de seguridad en tiempo real y optimización de gastos.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que crea un depósito de almacenamiento en la nube sin habilitar el uso y el registro de almacenamiento porque falta el argumento log_bucket.

resource "google_storage_bucket" "bucket-demo" {
    name     = "name-demo"
    location = "US"
}

De forma predeterminada, un clúster de Google Kubernetes Engine (GKE) escribe registros en Stackdriver Kubernetes Engine Logging Service. La configuración de Terraform configura un clúster de GKE y deshabilita explícitamente el servicio de registro. Los registros contienen datos valiosos que se utilizan para identificar incidentes de seguridad, supervisar infracciones de directivas y ayudar con los controles de no repudio.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que inhabilita el servicio de registro de un clúster de GKE configurando logging_service en none.

resource "google_container_cluster" "cluster-demo" {
    name            = "name-demo"
    location        = "us-central1-a"
    logging_service = "none"
    ...
}

De manera predeterminada, un clúster de Google Kubernetes Engine (GKE) envía métricas desde pods al servicio de monitoreo de Stackdriver Kubernetes Engine. El script de Terraform configura un clúster de GKE y deshabilita explícitamente el servicio de monitoreo. La ausencia de métricas socava la detección adecuada y la pronta respuesta a los eventos de seguridad.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que deshabilita el servicio de monitoreo de un clúster de GKE al establecer monitoring_service en none.

resource "google_container_cluster" "cluster-demo" {
    name               = "name-demo"
    location           = "us-central1-a"
    monitoring_service = "none"
    ...
}

La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

Los valores de configuración que socavan las capacidades de registro incluyen, entre otros:
- deshabilitar deliberadamente el registro de auditoría
- excluir acciones de usuarios, grupos o procesos específicos del registro
- proteger inadecuadamente la integridad del registro
- no habilitar el registro de auditoría opcional
- reducir la frecuencia de muestreo del registro

La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

Los valores de configuración que socavan las capacidades de registro incluyen, entre otros:
- deshabilitar deliberadamente el registro de auditoría
- excluir acciones de usuarios, grupos o procesos específicos del registro
- proteger inadecuadamente la integridad del registro
- no habilitar el registro de auditoría opcional
- reducir la frecuencia de muestreo del registro

La configuración de Terraform establece una subred de máquina virtual sin especificar opciones de registro. Estos registros contienen datos valiosos para el monitoreo de la red, análisis forense, análisis de seguridad en tiempo real y optimización de gastos.

La mala gestión de los permisos aumenta el riesgo de acceso no autorizado o modificación de los datos y socava la disponibilidad del servicio.

Una cuenta de servicio es una cuenta especial de Google utilizada por una aplicación o una VM en lugar de una persona, que utiliza permisos confidenciales para ejecutar procesos automatizados o realizar solicitudes de API en nombre de los usuarios finales. Debe administrarse, controlarse y auditarse cuidadosamente para que se pueda confiar en él. Asignar un rol de cuenta de servicio a un usuario de IAM, que normalmente representa a una persona, debilita el control de seguridad.

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.

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 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

Un mapa de URL es un conjunto de reglas para enrutar las solicitudes HTTP(S) entrantes a servicios de back-end específicos. Por defecto, un mapa de URL acepta 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 mapa de URL que permite a los clientes usar HTTP para la comunicación configurando https_redirect en false.

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

DNSSEC evita la falsificación de DNS al proporcionar la capacidad de usar firmas digitales para la validación de respuestas de DNS. Sin embargo, cualquier algoritmo de firma DNSSEC que use SHA-1 es susceptible de un riesgo de ataque cada vez mayor. SHA-1 ya no se considera un algoritmo hash seguro cuando se usa con firmas digitales.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que habilita DNSSEC con el algoritmo de firma inseguro rsasha1.

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    default_key_specs {
      algorithm = "rsasha1"
      ...
    }
  }
...
}

GKE admite dos modos de red de clúster: basado en rutas y nativo de VPC. Los clústeres nativos de VPC usan rangos de direcciones IP de alias para enrutar el tráfico de un pod en un nodo a otro pod. Esto permite políticas precisas basadas en IP y reglas de firewall para pods. Por el contrario, un nodo completo es el nivel de control de granularidad más fino en clústeres basados en rutas.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform no habilita un clúster nativo de VPC configurando networking_mode en ROUTES.

resource "google_container_cluster" "cluster_demo" {
...
  networking_mode = "ROUTES"
..
}