Se uma instância do Compute Engine for criada sem uma especificação de conta de serviço gerenciada pelo usuário, o Google Cloud atribuirá uma conta de serviço padrão à instância. Os direitos de acesso da conta de serviço padrão geralmente estão além do que a instância precisa para operar. Isso viola o princípio do privilégio mínimo.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que cria uma instância do Compute Engine sem uma especificação de conta de serviço gerenciada pelo usuário. O bloco service_account está ausente.

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

A falha em bloquear o tráfego de rede indesejado expande a superfície de ataque de um serviço de nuvem.

Por padrão, o encaminhamento de IP está desabilitado em uma instância do Compute Engine. O encaminhamento de IP permite enviar e receber pacotes com IPs de origem ou destino não correspondentes. Um invasor pode explorar isso roteando pacotes por meio da instância do Compute Engine para ignorar o controle de acesso à rede.

Exemplo 1: A configuração do Terraform a seguir habilita o encaminhamento de IP definindo can_ip_forward como true.

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

Por padrão, uma instância do Compute Engine não é uma VM Confidencial. Uma VM Confidencial usa criptografia baseada em hardware para proteção de dados em uso e para dar suporte a atestados remotos. As chaves de instância por VM dedicadas não exportáveis mantêm a memória da VM criptografada, protegendo assim a confidencialidade e a integridade da VM contra o acesso do provedor de nuvem por meio do hipervisor com privilégios mais altos.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que desabilita a VM Confidencial definindo enable_confidential_compute como false.

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

Por padrão, o Google Cloud Compute Engine criptografa todos os dados em repouso. Uma chave de criptografia fornecida pelo cliente (CSEK), se especificada, criptografa as chaves de criptografia de dados. O Google não armazena nenhuma CSEK em uma instância do Compute Engine e não pode acessar os dados protegidos a menos que a CSEK correta seja fornecida.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que define um disco permanente para uma instância do Compute Engine. O bloco disk_encryption_key está ausente, portanto, não há CSEK para proteger as chaves de criptografia de dados.

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

Por padrão, você pode usar chaves SSH armazenadas nos metadados do projeto para acessar todas as instâncias do Compute Engine em um projeto. Isso expande muito a superfície de ataque acessível a qualquer chave SSH comprometida e viola o princípio de privilégio mínimo.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que permite logins SSH em todo o projeto definindo block-project-ssh-keys como false no argumento metadata.

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

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.

Por padrão, a porta serial de uma instância do Compute Engine está desativada para acesso ao console. Habilitar o acesso ao console serial pode permitir que invasores se conectem à instância do Compute Engine de qualquer endereço IP, pois a porta serial não é compatível com restrições de acesso baseadas em IP.

Exemplo 1: A configuração do Terraform a seguir permite acesso ao console serial interativo definindo serial-port-enable como true no argumento metadata.

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

Cada recurso de segurança de serviço em nuvem tem uma capacidade única de prevenir ou atenuar uma ameaça conhecida. Qualquer recurso desabilitado por intenção ou erro não oferece proteção.

A desabilitação de qualquer opção de VM Protegida permite que um invasor ignore as restrições de segurança implementadas para um sistema operacional convidado em uma instância do Compute Engine. As opções de VM Protegida recomendadas (e seus identificadores de configuração do Terraform correspondentes) são as seguintes:

- Monitoramento de Integridade (enable_integrity_monitoring)
- Inicialização Segura (enable_secure_boot)
- Módulo de Plataforma Confiável Virtual (enable_vtpm)

Exemplo 1: A configuração do Terraform a seguir define enable_integrity_monitoring como false no bloco shielded_instance_config. Nem todas as opções de VM Protegida recomendadas estão habilitadas.

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

Por padrão, os serviços do Edge Cache aceitam 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 permite que os clientes usem HTTP para comunicação definindo https_redirect como false.

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

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

O plano de controle do GKE toma decisões globais sobre um cluster e, por padrão, muitos de seus endpoints de API são acessíveis publicamente. Adicionar redes autorizadas usando uma lista de permissões pode fornecer proteção em nível de rede para acesso ao plano de controle.

Exemplo 1: O exemplo de configuração do Terraform a seguir configura um cluster público sem definir nenhuma rede autorizada no bloco master_authorized_networks_config. Como resultado, os endpoints da API do plano de controle do GKE podem ser acessados publicamente.

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

Por padrão, a autenticação baseada em certificado é desabilitada em novos clusters que executam o GKE versão 1.12 e posterior. Com a autenticação baseada em certificado, um usuário apresenta um certificado que o servidor da API do Kubernetes verifica com a autoridade de certificação especificada. No entanto, não há como revogar o certificado quando o usuário sai ou perde as credenciais. Isso torna a autenticação baseada em certificado inadequada para usuários finais.

Exemplo 1: O exemplo de configuração do Terraform a seguir habilita a autenticação baseada em certificado de cliente do GKE definindo issue_client_certificate como true no bloco master_auth.

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

Um servidor da API Kubernetes, a entidade de gerenciamento central de um cluster, aceita a autenticação HTTP básica para autenticar usuários. A autenticação básica HTTP está obsoleta e suscetível a ataques de força bruta e expõe as credenciais de usuário para invasores em um ambiente mal configurado.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que habilita a autenticação básica HTTP em um cluster do GKE definindo username e password como valores não vazios no bloco master_auth.

resource "google_container_cluster" "container_cluster_demo" {
...
  master_auth {
    username = "foo"
    password = "bar"
  }
...
}

Por padrão, o Controle de Acesso Baseado em Atributos (ABAC) está desabilitado em novos clusters que executam o GKE versão 1.8 e posterior. O ABAC pode conceder estaticamente a um usuário específico ou a um grupo acesso a um recurso, além daqueles fornecidos pelo Controle de Acesso Baseado em Função (RBAC) ou Identity and Access Management (IAM). Isso complica a administração de autorizações e prejudica o controle de acesso centralizado.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que habilita a autorização do ABAC herdada em um cluster do GKE definindo enable_legacy_abac como true.

resource "google_container_cluster" "container_cluster_demo" {
...
  enable_legacy_abac = true
...
}

Cada recurso de segurança de serviço em nuvem é projetado para prevenir ou atenuar uma ameaça conhecida. Quando desabilitado por intenção ou negligência, não oferece proteção.

Por padrão, se um nó do GKE relatar repetidamente um status não íntegro durante um determinado período, o GKE iniciará um processo de reparo para esse nó. Desabilitar o reparo automático de nós evita substituições oportunas e automatizadas de nós não íntegros nos quais as cargas de trabalho de missão crítica podem ser executadas.

Exemplo 1: A configuração do Terraform a seguir desabilita o reparo automático de um pool de nós definindo auto_repair como false no bloco management.

resource "google_container_node_pool" "node-pool-demo" {
...
  management {
    auto_repair = false
    ...
  }
...
}

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.

Os nós privados do GKE não têm endereços IP externos. Os pods executados nesses nós não podem se comunicar além do perímetro do cluster. A desabilitação de um endpoint público protege o cluster do GKE limitando seu gerenciamento a endereços IP privados internos. A falha em impor um endpoint privado e nós privados expõe o cluster ao público.

Exemplo 1: A configuração do Terraform a seguir permite que qualquer endereço IP público acesse os nós do cluster e o plano de controle porque enable_private_nodes e enable_private_endpoint estão definidos como false.

resource "google_container_cluster" "cluster-demo" {
...
  private_cluster_config {
    enable_private_endpoint = false
    enable_private_nodes = false
  }
...
}

Por padrão, os nós do GKE são executados com o Container-Optimized OS (COS). COS é uma imagem do sistema operacional otimizada para executar nós do GKE em instâncias do Google Compute Engine. A desativação do padrão renuncia aos benefícios de segurança e eficiência aprimoradas.

Exemplo 1: O exemplo de configuração do Terraform a seguir configura um pool de nós do GKE que não executam COS porque image_type está definido como uma imagem não COS no bloco node_config.

resource "google_container_node_pool" "node_pool_demo" {
  ...
  node_config {
    image_type = "UBUNTU"
    ...
  }
  ...
}

Por padrão, o GKE atualiza automaticamente os nós do Kubernetes para versões estáveis mais recentes. As atualizações automáticas, que garantem a correção oportuna de vulnerabilidades de software conhecidas, são desabilitadas.

Exemplo 1: O exemplo de configuração do Terraform a seguir desabilita as atualizações automáticas de nós do Kubernetes definindo auto_upgrade como false no bloco management.

resource "google_container_node_pool" "node_pool_demo" {
...
  management {
    auto_upgrade = false
    ...
  }
...
}

Por padrão, um novo projeto do Google Cloud começa com uma rede em todo o projeto. A rede padrão é pré-preenchida com regras de firewall que permitem comunicação irrestrita entre instâncias do Compute Engine no mesmo projeto e expõem ao público as portas sensíveis à segurança de todas as instâncias. As portas afetadas incluem TCP 22 (SSH) e TCP 3389 (RDP). Qualquer instância não protegida suficientemente está suscetível a acesso não autorizado.

Exemplo 1: O exemplo de configuração do Terraform a seguir habilita a criação automática de uma rede em todo o projeto definindo auto_create_network como true.

resource "google_project" "project-demo" {
...
  auto_create_network = true
...
}

A configuração do Terraform define o escopo de acesso de uma conta de serviço como cloud-platform, que permite acesso à maioria das APIs do Google Cloud. Isso expande muito a superfície de ataque acessível a qualquer instância comprometida do Compute Engine e viola o princípio de privilégio mínimo.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que define o escopo de acesso (scopes) da conta de serviço como cloud-platform.

resource "google_compute_instance" "compute-instance-demo" {
    name         = "name-demo"
    machine_type = "e2-micro"
    ...
    service_account {
        email  = "foobar.service.account@example.com"
        scopes = ["cloud-platform"]
    }
}

Por padrão, o domínio de 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.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que não contém um bloco ssl_settings para o domínio chamado example.com. Como resultado, o domínio personalizado para o aplicativo do App Engine não é compatível com HTTPS.

resource "google_app_engine_domain_mapping" "domain_mapping" {
  domain_name = "example.com"
}