Por padrão, um aplicativo do App Engine aceita conexões não criptografadas e não seguras. Essas conexões expõem os dados a acesso não autorizado, possível roubo e adulteração.

Por padrão, um gatilho HTTP permite que uma Função do Cloud seja executada apenas em resposta a solicitações HTTPS. Permitir solicitações HTTP inseguras expõe os dados a acesso não autorizado, possível roubo e adulteração.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que define um gatilho HTTP que não impõe endpoints HTTPS configurando https_trigger_security_level como SECURE_OPTIONAL.

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

Por padrão, uma instância do Cloud SQL aceita conexões não criptografadas e não seguras. Essas conexões expõem os dados a acesso não autorizado, possível roubo e adulteração.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que não exige que uma instância de banco de dados imponha SSL para todas as conexões definindo require_ssl como false.

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

Por padrão, um serviço do Edge Cache aceita conexões não criptografadas e não seguras. Essas conexões expõem os dados a acesso não autorizado, possível roubo e adulteração.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que define um serviço do Edge Cache que não exige que os clientes usem TLS para comunicação configurando require_tls como false.

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

Os protocolos TLS (Transport Layer Security) e SSL (Secure Sockets Layer) fornecem um mecanismo de proteção para garantir a autenticidade, a confidencialidade e a integridade dos dados transmitidos entre um cliente e o servidor web. Tanto o TLS quanto o SSL sofreram revisões, o que resulta em atualizações de versão periódicas. Cada nova revisão resolve as vulnerabilidades de segurança descobertas nas versões anteriores. O uso de uma versão não segura do TLS/SSL enfraquece a proteção dos dados e pode permitir que um invasor comprometa, roube ou modifique informações confidenciais.

Versões inseguras do TLS/SSL podem exibir uma ou mais das propriedades a seguir:

- Nenhuma proteção contra ataques man-in-the-middle
- Mesma chave usada para autenticação e criptografia
- Controle fraco da autenticação de mensagens
- Nenhuma proteção contra o fechamento de conexões TCP

A presença dessas propriedades pode possibilitar que um invasor intercepte, modifique ou adultere dados confidenciais.

Exemplo 1: O exemplo de configuração do Terraform a seguir define uma política SSL que permite que o balanceador de carga de proxy autorize o uso de conjuntos de criptografia SSL fracos definindo profile como COMPATIBLE.

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

Exemplo 2: O exemplo a seguir de configuração do Terraform que define uma política SSL personalizada que permite especificamente que o balanceador de carga do proxy autorize o uso de um conjunto de criptografia SSL fraco chamado 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"]
...
}

A falta de registros de auditoria limita a capacidade de detectar e responder a incidentes relacionados à segurança e impede a investigação forense.

As definições de configuração que prejudicam os recursos de registro incluem, mas não estão limitadas a:
- desativar deliberadamente o log de auditoria
- isentar o log de ações de usuários, grupos ou processos específicos
- proteger inadequadamente a integridade do log
- não habilitar o log de auditoria opcional
- reduzir a taxa de amostragem de log

A falta de registros de auditoria limita a capacidade de detectar e responder a incidentes relacionados à segurança e impede a investigação forense.

As definições de configuração que prejudicam os recursos de registro incluem, mas não estão limitadas a:
- desativar deliberadamente o log de auditoria
- isentar o log de ações de usuários, grupos ou processos específicos
- proteger inadequadamente a integridade do log
- não habilitar o log de auditoria opcional
- reduzir a taxa de amostragem de log

Uma configuração do Terraform cria um Bucket do Cloud Storage sem habilitar os logs de uso e armazenamento. Esses logs contêm dados valiosos para monitoramento de rede, perícia, análise de segurança em tempo real e otimização de despesas.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que cria um Bucket do Cloud Storage sem habilitar o registro em log de uso e armazenamento porque o argumento log_bucket está ausente.

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

Por padrão, um cluster do Google Kubernetes Engine (GKE) grava logs no Stackdriver Kubernetes Engine Logging Service. A configuração do Terraform configura um cluster do GKE e desabilita explicitamente o serviço de registro em log. Os logs contêm dados valiosos usados para identificar incidentes de segurança, monitorar violações de políticas e auxiliar nos controles de não repúdio.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que desabilita o serviço de registro em log de um cluster do GKE definindo logging_service como none.

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

Por padrão, um cluster do Google Kubernetes Engine (GKE) envia métricas de Pods para o Stackdriver Kubernetes Engine Monitoring Service. O script do Terraform configura um cluster do GKE e desabilita explicitamente o serviço de monitoramento. A ausência de métricas prejudica a detecção adequada e a resposta imediata a eventos de segurança.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que desabilita o serviço de monitoramento de um cluster do GKE definindo monitoring_service como none.

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

A falta de registros de auditoria limita a capacidade de detectar e responder a incidentes relacionados à segurança e impede a investigação forense.

As definições de configuração que prejudicam os recursos de registro incluem, mas não estão limitadas a:
- desativar deliberadamente o log de auditoria
- isentar o log de ações de usuários, grupos ou processos específicos
- proteger inadequadamente a integridade do log
- não habilitar o log de auditoria opcional
- reduzir a taxa de amostragem de log

A falta de registros de auditoria limita a capacidade de detectar e responder a incidentes relacionados à segurança e impede a investigação forense.

As definições de configuração que prejudicam os recursos de registro incluem, mas não estão limitadas a:
- desativar deliberadamente o log de auditoria
- isentar o log de ações de usuários, grupos ou processos específicos
- proteger inadequadamente a integridade do log
- não habilitar o log de auditoria opcional
- reduzir a taxa de amostragem de log

A configuração do Terraform configura uma sub-rede de Máquina Virtual sem especificar opções de registro em log. Esses logs contêm dados valiosos para monitoramento de rede, perícia, análise de segurança em tempo real e otimização de despesas.

A má gestão de permissões aumenta o risco de acesso não autorizado ou modificação de dados e prejudica a disponibilidade do serviço.

Uma conta de serviço é uma conta do Google especial usada por um aplicativo ou uma VM em vez de uma pessoa, que usa permissões confidenciais para executar processos automatizados ou fazer solicitações de API em nome de usuários finais. Ela deve ser cuidadosamente gerenciada, controlada e auditada, para que possa ser confiável. A atribuição de uma função de conta de serviço a um usuário do IAM, que normalmente representa uma pessoa, enfraquece o controle de segurança.

A falha em bloquear o tráfego de rede indesejado expande a superfície de ataque de um serviço de nuvem. Os serviços abertos à interação com o público estão sujeitos a varreduras e investigações quase contínuas por entidades mal-intencionadas.

As chaves de criptografia gerenciadas pelo cliente (CMEK) não estão habilitadas para dados em repouso.

Por padrão, o Google Cloud usa Chaves de Criptografia de Dados (DEK) geradas aleatoriamente para criptografar dados em repouso. O recurso CMEK permite que as organizações usem chaves criptográficas de sua escolha para criptografar a DEK. Isso dá às organizações melhor controle e registro de processos de criptografia.

Como tal, a CMEK geralmente faz parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves
- Módulo de segurança de hardware inviolável

As chaves de criptografia gerenciadas pelo cliente (CMEK) não estão habilitadas para dados em repouso.

Por padrão, o Google Cloud usa Chaves de Criptografia de Dados (DEK) geradas aleatoriamente para criptografar dados em repouso. O recurso CMEK permite que as organizações usem chaves criptográficas de sua escolha para criptografar a DEK. Isso dá às organizações melhor controle e registro de processos de criptografia.

Como tal, a CMEK geralmente faz parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves
- Módulo de segurança de hardware inviolável

Um mapa de URL é um conjunto de regras para rotear solicitações HTTP(S) de entrada para serviços de back-end específicos. Por padrão, um mapa de URL aceita conexões não criptografadas e não seguras. Essas conexões expõem os dados a acesso não autorizado, possível roubo e adulteração.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que define um mapa de URL que permite que os clientes usem HTTP para comunicação definindo https_redirect como false.

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

O DNSSEC impede a falsificação de DNS fornecendo a capacidade de usar assinaturas digitais para validação de resposta de DNS. No entanto, qualquer algoritmo de assinatura DNSSEC que use SHA-1 está suscetível a um risco cada vez maior de ataque. O SHA-1 não é mais considerado um algoritmo de hash seguro quando usado com assinaturas digitais.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que habilita o DNSSEC com o algoritmo de assinatura não seguro rsasha1.

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

O GKE oferece suporte a dois modos de rede de cluster: baseado em rotas e nativo de VPC. Os clusters nativos de VPC usam intervalos de endereços IP de alias para rotear o tráfego de um pod em um nó para outro pod. Isso permite políticas precisas baseadas em IP e regras de firewall para pods. Em contraste, um nó inteiro é o melhor nível de granularidade de controle em clusters baseados em rotas.

Exemplo 1: O exemplo de configuração do Terraform a seguir não habilita um cluster nativo de VPC definindo networking_mode como ROUTES.

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