Como corrigir as descobertas da análise de integridade de segurança

>

Esta página fornece uma lista de guias de referência e técnicas para corrigir descobertas do Security Health Analytics usando o Security Command Center.

Você precisa de papéis adequados do gerenciamento de identidade e acesso (IAM, na sigla em inglês) para visualizar ou editar descobertas, além de acessar ou modificar recursos do Google Cloud. Se você encontrar erros de acesso no painel do Security Command Center, peça ajuda ao administrador e consulte Controle de acesso para saber mais sobre os papéis. Para resolver erros de recursos, leia a documentação dos produtos afetados.

Reversão do Security Health Analytics

Nesta seção, você verá instruções de correção para todas as descobertas do Security Health Analytics.

ADMIN_SERVICE_ACCOUNT

Uma conta de serviço na organização tem privilégios de administrador, proprietário ou editor atribuídos a ela. Esses papéis têm permissões amplas e não podem ser atribuídos a contas de serviço. Para saber mais sobre as contas de serviço e os papéis disponíveis, consulte Contas de serviço.

Para corrigir essa descoberta:

  1. Acessar a página de política de IAM.
    Acessar a política de IAM
  2. Para cada membro identificado na descoberta:
    1. Clique em Editar ao lado do membro.
    2. Para remover permissões, clique em Excluir ao lado do papel ofensivo.
    3. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

API_KEY_APIS_UNRESTRICTED

Há chaves de API muito usadas.

As chaves de API sem restrições não são seguras porque podem ser recuperadas em dispositivos em que a chave está armazenada ou podem ser vistas publicamente, por exemplo, em um navegador. De acordo com o princípio do menor privilégio, configure chaves de API para chamar apenas as APIs exigidas pelo aplicativo. Para mais informações, consulte Como usar chaves de API.

Para corrigir essa descoberta:

  1. Acesse a página das chaves de API.
    Acessar as chaves de API
  2. Para cada chave de API:
    1. Clique em Editar .
    2. Em Restrições da API, clique em Restringir chave.
    3. Na lista suspensa Selecionar APIs, escolha as APIs que terão permissão.
    4. Clique em Save. As configurações podem levar até cinco minutos para entrar em vigor.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

API_KEY_APPS_UNRESTRICTED

Há chaves de API sendo usadas de forma irrestrito, permitindo o uso de qualquer app não confiável.

As chaves de API sem restrições não são seguras porque podem ser recuperadas em dispositivos em que a chave está armazenada ou podem ser vistas publicamente, por exemplo, em um navegador. De acordo com o princípio do menor privilégio, restrinja o uso da chave de API para hosts confiáveis, referenciadores HTTP e aplicativos. Para mais informações, consulte Como adicionar restrições de aplicativos.

Para corrigir essa descoberta:

  1. Acesse a página das chaves de API.
    Chaves de API do Go
  2. Para cada chave de API:
    1. Clique em Editar .
    2. Em Restrições do aplicativo, selecione uma categoria de restrição. É possível definir uma restrição de aplicativo por chave.
    3. Clique em Adicionar um item para adicionar restrições com base nas necessidades do seu aplicativo.
    4. Depois de adicionar os itens, clique em Concluído.
    5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

API_KEY_EXISTS

Um projeto está usando chaves de API em vez da autenticação padrão.

As chaves de API não são seguras porque são strings criptografadas simples e fáceis para serem descobertas e usadas. Eles podem ser recuperados em dispositivos em que a chave está armazenada ou podem ser vistas publicamente, por exemplo, em um navegador. Além disso, as chaves de API não identificam exclusivamente os usuários ou aplicativos que fazem solicitações. Em vez disso, use um fluxo de autenticação padrão. Para saber mais, consulte Como autenticar como usuário final.

Para corrigir essa descoberta:

  1. Verifique se os aplicativos estão configurados com uma forma alternativa de autenticação.
  2. Acesse a página Credenciais da API.
    Acessar as credenciais de APIs
  3. Na seção Chaves de API, clique em Excluir ao lado de cada chave de API.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

API_KEY_NOT_ROTATED

Uma chave de API não foi girada há mais de 90 dias.

As chaves de API não expiram, portanto, se uma chave for roubada, ela poderá ser usada indefinidamente, a menos que o dono do projeto a revogue ou gire a chave. Regenerar chaves de API com frequência reduz o tempo que uma chave de API roubada pode ser usada para acessar dados em uma conta comprometida ou encerrada. Girar as chaves de API pelo menos a cada 90 dias. Para mais informações, consulte Como proteger uma chave de API.

Para corrigir essa descoberta:

  1. Acesse a página das chaves de API.
    Acessar as chaves de API
  2. Para cada chave de API:
    1. Verifique a data em Data de criação.
    2. Se a chave tiver mais de 90 dias, clique no nome dela ou em Editar .
    3. Na parte superior da página, clique em Gerar chave novamente.
    4. Clique em Substituir chave.
    5. Para garantir que seus aplicativos continuem funcionando sem interrupções, atualize-os para usar a nova chave de API. A chave de API antiga funciona por 24 horas antes de ser desativada permanentemente.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

AUDIT_CONFIG_NOT_MONITORED

As métricas e os alertas do registro não estão configurados para monitorar as alterações de configuração de auditoria.

O Cloud Logging gera registros de atividade do acesso e de administração de administradores que permitem análise de segurança, rastreamento de alterações de recursos e auditoria de conformidade. Ao monitorar as alterações de configuração de auditoria, você garante que todas as atividades do projeto possam ser auditadas a qualquer momento. Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta, crie métricas, se necessário, e políticas de alertas:

Criar métrica

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Clique em Criar métrica.
  3. Em Tipo de Métrica, selecione Contador.
  4. Em Detalhes:
    1. Defina um Nome da métrica de registro.
    2. Adicione uma descrição.
    3. Definir Unidades para 1.
  5. Em Seleção de filtro, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto atual, se necessário:
      protoPayload.methodName="SetIamPolicy"
      AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*
    
  6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Na seção Métricas definidas pelo usuário, selecione a métrica criada na seção anterior.
  3. Clique em Mais e, em seguida, clique em Criar alerta a partir da métrica. Conclua o processo para adicionar seu projeto a um espaço de trabalho.
  4. No menu de navegação da página exibida, clique em Alertas.
  5. Em O que você quer acompanhar?, clique em Adicionar condição e preencha a caixa de diálogo para definir quais recursos são monitorados e quando os alertas são acionados. Para ver informações sobre os campos de uma condição, consulte Como especificar condições.
  6. Quando terminar, clique em Adicionar e em Avançar.
  7. Em Quem deve ser notificado?, clique na lista suspensa Canais de notificação e selecione como você quer ser notificado. Para mais informações, consulte Como gerenciar canais de notificação.
  8. Clique em OK e em Avançar.
  9. Em Quais são as etapas para corrigir o problema?, defina um Nome de alerta.
  10. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

AUDIT_LOGGING_DISABLED

O registro de auditoria foi desativado para este recurso.

Ative o Cloud Logging para todos os serviços para rastrear todas as atividades de administrador, acesso de leitura e acesso de gravação aos dados do usuário. Dependendo da quantidade de informações, os custos do Cloud Logging podem ser significativos. Para entender o uso do serviço e o custo dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

  1. Acesse a página Configuração de auditoria padrão.
    Acessar a configuração de auditoria padrão
  2. Na guia Tipo de registro, selecione Leitura de administradores, Leitura de dados e Gravação de dados.
  3. Clique em Save.
  4. Na guia Usuários isentos, remova todos os usuários listados clicando em Excluir ao lado de cada nome.
  5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

AUTO_BACKUP_DISABLED

Um banco de dados do Cloud SQL não tem backups automáticos ativados.

Para evitar a perda de dados, ative backups automáticos nas instâncias do SQL. Para mais informações, consulte Como criar e gerenciar backups automáticos e sob demanda.

Para corrigir essa descoberta:

  1. Acesse a página Backups de instâncias SQL.
    Acessar backups de instâncias do SQL
  2. Ao lado de Configurações, clique em Editar .
  3. Marque a caixa Automatizar backups.
  4. No menu suspenso, escolha uma janela de tempo para que o backup dos dados seja feito automaticamente.
  5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

AUTO_REPAIR_DESATIVADO

O recurso de reparo automático de um cluster do Google Kubernetes Engine (GKE), que mantém os nós em um estado íntegro e em execução, é desativado.

Quando ativado, o GKE faz verificações periódicas no estado de integridade de cada nó no cluster. Se um nó falhar em verificações de integridade consecutivas durante um período prolongado, o GKE iniciará um processo de reparo para esse nó. Para mais informações, consulte Como reparar nós automaticamente.

Para corrigir essa descoberta:

  1. Acessar a página de clusters do Kubernetes.
    Acessar os clusters do Kubernetes

  2. Clique na guia Nós.

  3. Para cada pool de nós:

    1. Clique no nome do pool de nós para acessar a página de detalhes.
    2. Clique em Editar .
    3. Em Gerenciamento, selecione Ativar reparo automático.
    4. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

AUTO_UPGRADE_DISABLED

O recurso de upgrade automático de um cluster do GKE, que mantém os clusters e pools de nós na versão estável mais recente do Kubernetes, está desativado.

Para mais informações, consulte Como fazer o upgrade automático dos nós.

Para corrigir essa descoberta:

  1. Acessar a página de clusters do Kubernetes.
    Acessar os clusters do Kubernetes
  2. Na lista de clusters, clique no nome do cluster.
  3. Clique na guia Nós.
  4. Para cada pool de nós:
    1. Clique no nome do pool de nós para acessar a página de detalhes.
    2. Clique em Editar .
    3. Em Gerenciamento, selecione Ativar upgrade automático.
    4. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

BUCKET_CMEK_DISABLED

Um bucket não é criptografado com chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês).

Configurar uma CMEK padrão em um bucket oferece mais controle sobre o acesso aos seus dados. Para mais informações, consulte Chaves de criptografia gerenciadas pelo cliente.

Para corrigir essa descoberta, use CMEK com um bucket seguindo as Como usar chaves de criptografia gerenciadas pelo cliente. A CMEK gera custos adicionais relacionados ao Cloud KMS.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

BUCKET_IAM_NOT_MONITORED

As métricas e os alertas do registro não estão configurados para monitorar as alterações de permissão do IAM do Cloud Storage.

O monitoramento de alterações nas permissões de bucket do Cloud Storage ajuda a identificar usuários com privilégios privilegiados ou atividades suspeitas. Para mais informações, consulte Visão geral das métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

Criar métrica

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Clique em Criar métrica.
  3. Em Tipo de Métrica, selecione Contador.
  4. Em Detalhes:
    1. Defina um Nome da métrica de registro.
    2. Adicione uma descrição.
    3. Definir Unidades para 1.
  5. Em Seleção de filtro, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto atual, se necessário:
      resource.type=gcs_bucket
      AND protoPayload.methodName="storage.setIamPermissions"
    
  6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Na seção Métricas definidas pelo usuário, selecione a métrica criada na seção anterior.
  3. Clique em Mais e, em seguida, clique em Criar alerta a partir da métrica. Conclua o processo para adicionar seu projeto a um espaço de trabalho.
  4. No menu de navegação da página exibida, clique em Alertas.
  5. Em O que você quer acompanhar?, clique em Adicionar condição e preencha a caixa de diálogo para definir quais recursos são monitorados e quando os alertas são acionados. Para ver informações sobre os campos de uma condição, consulte Como especificar condições.
  6. Quando terminar, clique em Adicionar e em Avançar.
  7. Em Quem deve ser notificado?, clique na lista suspensa Canais de notificação e selecione como você quer ser notificado. Para mais informações, consulte Como gerenciar canais de notificação.
  8. Clique em OK e em Avançar.
  9. Em Quais são as etapas para corrigir o problema?, defina um Nome de alerta.
  10. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

BUCKET_LOGGING_DISABLED

Há um bucket de armazenamento sem a geração de registros ativada.

Para ajudar a investigar problemas de segurança e monitorar o consumo de armazenamento, ative os registros de acesso e informação de armazenamento nos seus buckets do Cloud Storage. Os registros de acesso fornecem informações sobre todas as solicitações feitas em um bucket específico e os registros de armazenamento fornecem informações sobre o consumo de armazenamento daquele bucket.

Para corrigir essa descoberta, configure o registro do bucket indicado pela descoberta do Security Health Analytics concluindo o guia de registros de uso e de armazenamento.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

BUCKET_POLICY_ONLY_DISABLED

O acesso uniforme no nível do bucket, anteriormente chamado de Somente política do bucket, não está configurado.

O acesso uniforme no nível do bucket simplifica o controle de acesso do bucket ao desativar permissões no nível do objeto (ACLs). Quando ativadas, somente as permissões do IAM no nível do bucket concedem acesso ao bucket e aos objetos contidos nele. Para mais informações, consulte Acesso uniforme no nível do bucket.

Para corrigir essa descoberta:

  1. Acesse a página Navegador do Cloud Storage.
    Acessar o navegador do Cloud Storage
  2. Na lista de buckets, clique no nome do bucket pretendido.
  3. Clique na guia Permissões..
  4. No card Controle de acesso, clique em Alternar para uniforme.
  5. Na caixa de diálogo, selecione Uniforme.
  6. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

CLUSTER_LOGGING_DISABLED

A geração de registros não está ativada para um cluster do GKE.

Para ajudar a investigar problemas de segurança e monitorar o uso, ative o Cloud Logging nos seus clusters.

Dependendo da quantidade de informações, os custos do Cloud Logging podem ser significativos. Para entender o uso do serviço e o custo dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

  1. Acesse a página de clusters do Kubernetes no Console do Cloud.
    Acessar os clusters do Kubernetes
  2. Selecione o cluster listado na descoberta do Security Health Analytics.
  3. Clique em Editar.

    Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

  4. Na lista suspensa do Stackdriver Logging legado ou do Stackdriver Kubernetes Engine Monitoring, selecione Ativado.

    Essas opções não são compatíveis. Assegure-se de usar o Stackdriver Kubernetes Engine Monitoring apenas, ou Stackdriver Logging legado com Stackdriver Monitoring legado.

  5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

CLUSTER_MONITORING_DISABLED

O monitoramento está desativado nos clusters do GKE.

Para ajudar a investigar problemas de segurança e monitorar o uso, ative o Cloud Monitoring nos seus clusters.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

  1. Acesse a página de clusters do Kubernetes no Console do Cloud.
    Acessar os clusters do Kubernetes
  2. Selecione o cluster listado na descoberta do Security Health Analytics.
  3. Clique em Editar.

    Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

  4. Na lista suspensa do Stackdriver Monitoring legado ou do Stackdriver Kubernetes Engine Monitoring, selecione Ativado.

    Essas opções não são compatíveis. Assegure-se de usar o Stackdriver Kubernetes Engine Monitoring apenas, ou Stackdriver Monitoring legado com o Stackdriver Logging legado.

  5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Os hosts de cluster não estão configurados para usar apenas endereços IP internos e privados para acessar as APIs do Google.

O Acesso privado do Google permite que instâncias de máquina virtual (VM) com apenas endereços IP internos particulares alcancem os endereços IP públicos de APIs e serviços do Google. Para mais informações, consulte Como configurar o Acesso privado do Google.

Para corrigir essa descoberta:

  1. Acesse a página Redes de nuvem privada virtual
    Acessar Redes VPC
  2. Na lista de redes, clique no nome da rede desejada.
  3. Na página Detalhes da rede VPC, clique na guia Sub-redes.
  4. Na lista de sub-redes, clique no nome da sub-rede associada ao cluster do Kubernetes na descoberta.
  5. Na página Detalhes da sub-rede, clique em Editar .
  6. Em Acesso privado ao Google, selecione Ativado.
  7. Clique em Save.
  8. Para remover IPs públicos (externos) de instâncias de VM cujo único tráfego externo seja para APIs do Google, consulte Como cancelar a atribuição de um endereço IP externo estático.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

Chaves SSH em todo o projeto são usadas, o que permite fazer login em todas as instâncias do projeto.

Usar chaves SSH em todo o projeto facilita o gerenciamento de chaves SSH, mas, se comprometido, representa um risco à segurança que pode afetar todas as instâncias de um projeto. Você precisa usar chaves SSH específicas da instância, o que limita a superfície de ataque se as chaves SSH estiverem comprometidas. Para mais informações, consulte Como gerenciar chaves SSH em metadados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias de VM
    Acessar instâncias de VM
  2. Na lista de instâncias, clique no nome da instância na descoberta.
  3. Na página Detalhes da instância de VM, clique em Editar.
  4. Em Chaves SSH, selecione Bloquear chaves SSH do projeto inteiro.
  5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

COMPUTE_SECURE_BOOT_DISABLED

Uma VM protegida não tem a Inicialização segura ativada.

O uso da Inicialização segura ajuda a proteger as máquinas virtuais contra rootkits e bootkits. O Compute Engine não ativa a Inicialização segura por padrão porque alguns drivers não assinados e softwares de nível inferior não são compatíveis. Se sua VM não usa software incompatível e é inicializada com a Inicialização segura ativada, o Google recomenda o uso da Inicialização segura. Se você estiver usando módulos de terceiros com drivers Nvidia, verifique se eles são compatíveis com a Inicialização segura antes de ativá-la.

Para mais informações, consulte Inicialização segura.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias de VMs no Console do Cloud.
    Acessar instâncias de VM
  2. Na lista de instâncias, clique no nome da instância na descoberta.
  3. Na página Detalhes da instância de VM, clique em Interromper.
  4. Depois que a instância for interrompida, clique em Editar.
  5. Em VM protegida, selecione Ativar a inicialização segura.
  6. Clique em Save.
  7. Clique em Iniciar para iniciar a instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

COMPUTE_SERIAL_PORTS_ENABLED

As portas seriais de uma instância, permitindo conexões com o console serial da instância.

Se você ativar o console serial interativo em uma instância, os clientes poderão tentar se conectar a essa instância a partir de qualquer endereço IP. Portanto, o suporte ao console serial interativo deve ser desativado. Para mais informações, consulte Como ativar o acesso para um projeto.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias de VM
    Acessar instâncias de VM
  2. Na lista de instâncias, clique no nome da instância na descoberta.
  3. Na página Detalhes da instância de VM, clique em Editar.
  4. Em Acesso remoto, desmarque a opção Ativar a conexão com as portas seriais.
  5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

COS_NOT_USED

As VMs do Compute Engine não estão usando o Container-Optimized OS, projetado para executar contêineres do Docker no Google Cloud com segurança.

O Google recomenda o sistema operacional Container-Optimized OS para hospedar e executar contêineres no Google Cloud. A pequena pegada do sistema operacional diminui a exposição de segurança, enquanto as atualizações automáticas corrigem vulnerabilidades de segurança em tempo hábil. Para mais informações, consulte Visão geral do Container-Optimized OS.

Para corrigir essa descoberta:

  1. Acessar a página de clusters do Kubernetes.
    Acessar os clusters do Kubernetes
  2. Na lista de clusters, clique no nome do cluster na descoberta.
  3. Clique na guia Nós.
  4. Para cada pool de nós:
    1. Clique no nome do pool de nós para acessar a página de detalhes.
    2. Clique em Editar .
    3. Em Nós -> Tipo de imagem, clique em Alterar.
    4. Selecione Container-Optimized OS e clique em Alterar.
    5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

CUSTOM_ROLE_NOT_MONITORED

As métricas e os alertas do registro não são configurados para monitorar alterações de papéis personalizados.

O IAM fornece papéis predefinidos e personalizados que concedem acesso a recursos específicos do Google Cloud. Ao monitorar as atividades de criação, exclusão e atualização de papéis, você identifica papéis com privilégios iniciais nos estágios iniciais. Para mais informações, consulte Visão geral das métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

Criar métrica

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Clique em Criar métrica.
  3. Em Tipo de Métrica, selecione Contador.
  4. Em Detalhes:
    1. Defina um Nome da métrica de registro.
    2. Adicione uma descrição.
    3. Definir Unidades para 1.
  5. Em Seleção de filtro, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto atual, se necessário:
      resource.type="iam_role"
      AND protoPayload.methodName="google.iam.admin.v1.CreateRole"
      OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
      OR protoPayload.methodName="google.iam.admin.v1.UpdateRole"
    
  6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Na seção Métricas definidas pelo usuário, selecione a métrica criada na seção anterior.
  3. Clique em Mais e, em seguida, clique em Criar alerta a partir da métrica. Conclua o processo para adicionar seu projeto a um espaço de trabalho.
  4. No menu de navegação da página exibida, clique em Alertas.
  5. Em O que você quer acompanhar?, clique em Adicionar condição e preencha a caixa de diálogo para definir quais recursos são monitorados e quando os alertas são acionados. Para ver informações sobre os campos de uma condição, consulte Como especificar condições.
  6. Quando terminar, clique em Adicionar e em Avançar.
  7. Em Quem deve ser notificado?, clique na lista suspensa Canais de notificação e selecione como você quer ser notificado. Para mais informações, consulte Como gerenciar canais de notificação.
  8. Clique em OK e em Avançar.
  9. Em Quais são as etapas para corrigir o problema?, defina um Nome de alerta.
  10. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

REDE DEFAULT

A rede padrão existe em um projeto.

As redes padrão criam automaticamente regras de firewall e configurações de rede que podem não ser seguras. Para mais informações, consulte Rede padrão.

Para corrigir essa descoberta:

  1. Acesse a página Redes VPC no Console do Cloud.
    Acessar redes VPC
  2. Na lista de redes, clique no nome da rede padrão.
  3. Na página Detalhes da rede VPC, clique em Excluir rede VPC.
  4. Para criar uma nova rede com regras de firewall personalizadas, consulte Como criar redes.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

DEFAULT_SERVICE_ACCOUNT_USED

Uma instância do Compute Engine está configurada para usar a conta de serviço padrão.

A conta de serviço padrão do Compute Engine tem o papel de editor no projeto, que permite acesso de leitura e gravação à maioria dos serviços do Google Cloud. Para se defender de escalonamentos de privilégios e acesso não autorizado, não use a conta de serviço padrão do Compute Engine. Em vez disso, crie uma nova conta de serviço e atribua apenas as permissões necessárias à instância. Leia Controle de acesso para informações sobre papéis e permissões.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias de VMs no Console do Cloud.
    Acessar instâncias de VM
  2. Selecione a instância relacionada à descoberta da análise de integridade de segurança.
  3. Na página Detalhes da instância carregada, clique em Parar.
  4. Depois que a instância for interrompida, clique em Editar.
  5. Na seção Conta de serviço, selecione uma conta de serviço diferente da conta de serviço padrão do Compute Engine. Talvez seja necessário criar uma nova conta de serviço. Leia Controle de acesso para informações sobre papéis e permissões do IAM.
  6. Clique em Save. A nova configuração aparecerá na página Detalhes da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

DISK_CMEK_DISABLED

Os discos nessa VM não são criptografados com chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês).

Com a CMEK, as chaves que você cria e gerencia no Cloud KMS unem as chaves que o Google usa para criptografar os dados, oferecendo mais controle sobre o acesso aos seus dados. Para mais informações, consulte Como proteger recursos com chaves do Cloud KMS.

Para corrigir essa descoberta:

  1. Acesse a página Discos do Compute Engine no Console do Cloud.
    Acessar os discos do Compute Engine
  2. Na lista de discos, clique no nome do disco indicado na descoberta.
  3. Na página Gerenciar disco, clique em Excluir.
  4. Para criar um novo disco com a CMEK ativada, consulte Criptografar um novo disco permanente com suas próprias chaves. A CMEK gera custos adicionais relacionados ao Cloud KMS.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

DISK_CSEK_DISABLED

Os discos nessa VM não são criptografados com chaves de criptografia fornecidas pelo cliente (CSEK, na sigla em inglês). Discos para VMs críticas devem ser criptografados com CSEK.

Se você fornecê-las, o Compute Engine usará sua chave para proteger as chaves geradas pelo Google usadas para criptografar e descriptografar seus dados. Para mais informações, consulte Chaves de criptografia fornecidas pelo cliente. A CSEK gera custos adicionais relacionados ao Cloud KMS.

Para corrigir essa descoberta:

Excluir e criar disco

Você só pode criptografar novos discos permanentes com sua própria chave. Não é possível criptografar os discos permanentes atuais com elas.

  1. Acesse a página Discos do Compute Engine no Console do Cloud.
    Acessar os discos do Compute Engine
  2. Na lista de discos, clique no nome do disco indicado na descoberta.
  3. Na página Gerenciar disco, clique em Excluir.
  4. Para criar um novo disco com a CSEK ativada, consulte Criptografar discos com chaves de criptografia fornecidas pelo cliente.
  5. Conclua as etapas restantes para ativar o detector.

Ativar o detector

  1. Acesse a página Recursos do Security Command Center no Console do Cloud.
    Acessar recursos
  2. Ao lado de View by, clique em Resource Type.
  3. Na lista de recursos, selecione Disco. A tabela é preenchida com uma lista de seus discos.
  4. Em resourceProperties.name, marque a caixa ao lado do nome do disco que você quer usar com CSEK e clique em Definir marcações de segurança.
  5. Na caixa de diálogo, clique em Adicionar marcação.
  6. No campo key, insira enforce_customer_supplied_disk_encryption_keys e, no campo value, insira true.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

DNSSEC_DESATIVADO

As extensões de segurança do Sistema de Nome de Domínio (DNSSEC, na sigla em inglês) estão desativadas para zonas do Cloud DNS.

A DNSSEC valida as respostas DNS e atenua os riscos, como invasão de DNS e ataques presenciais, assinando os registros DNS criptograficamente. Você deve ativar o DNSSEC. Para mais informações, consulte a visão geral das extensões de segurança de DNS (DNSSEC, na sigla em inglês).

Para corrigir essa descoberta:

  1. Acesse a página do Cloud DNS no Console do Cloud.
    Acessar as redes do Cloud DNS
  2. Localize a linha com a zona DNS indicada na descoberta.
  3. Clique na configuração da DNSSEC na linha e, em DNSSEC, selecione Ativado.
  4. Leia a caixa de diálogo que aparece. Se estiver satisfeito, clique em Ativar.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

FRERESS_DENY_RULE_NOT_SET

Uma regra de negação de saída não é definida em um firewall.

Um firewall que nega todo o tráfego de rede de saída impede conexões de rede de saída indesejadas, exceto essas conexões que outros firewalls autorizam explicitamente. Para ver mais informações, consulte Casos de saída.

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar Firewall
  2. Clique em Criar regra de firewall.
  3. Dê um nome ao firewall e, opcionalmente, uma descrição.
  4. Em Direção do tráfego, selecione Saída.
  5. Em Ação se houver correspondência, selecione Negar.
  6. No menu suspenso Destinos, selecione Todas as instâncias na rede.
  7. No menu suspenso Filtro de destino, selecione Intervalos de IP e digite 0.0.0.0/0 na caixa Intervalos de IP de destino. para começar.
  8. Em Protocolos e portas, selecione Negar tudo.
  9. Clique em Desativar regra e, em Aplicação, selecione Ativada.
  10. Clique em Criar.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

FIREWALL_NOT_MONITORED

As métricas e os alertas do registro não estão configurados para monitorar as alterações da regra de firewall da rede VPC.

A criação de eventos de criação e atualização de regras de firewall fornece insights sobre alterações no acesso à rede e pode detectar rapidamente atividades suspeitas. Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

Criar métrica

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Clique em Criar métrica.
  3. Em Tipo de Métrica, selecione Contador.
  4. Em Detalhes:
    1. Defina um Nome da métrica de registro.
    2. Adicione uma descrição.
    3. Definir Unidades para 1.
  5. Em Seleção de filtro, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto atual, se necessário:
      resource.type="gce_firewall_rule"
      AND jsonPayload.event_subtype="compute.firewalls.patch"
      OR jsonPayload.event_subtype="compute.firewalls.insert"
    
  6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Na seção Métricas definidas pelo usuário, selecione a métrica criada na seção anterior.
  3. Clique em Mais e, em seguida, clique em Criar alerta a partir da métrica. Conclua o processo para adicionar seu projeto a um espaço de trabalho.
  4. No menu de navegação da página exibida, clique em Alertas.
  5. Em O que você quer acompanhar?, clique em Adicionar condição e preencha a caixa de diálogo para definir quais recursos são monitorados e quando os alertas são acionados. Para ver informações sobre os campos de uma condição, consulte Como especificar condições.
  6. Quando terminar, clique em Adicionar e em Avançar.
  7. Em Quem deve ser notificado?, clique na lista suspensa Canais de notificação e selecione como você quer ser notificado. Para mais informações, consulte Como gerenciar canais de notificação.
  8. Clique em OK e em Avançar.
  9. Em Quais são as etapas para corrigir o problema?, defina um Nome de alerta.
  10. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

FIREWALL_RULE_LOGGING_DISABLED

A geração de registros de regras de firewall está desativada.

O recurso de geração de registros de regras de firewall permite auditar, verificar e analisar os efeitos das suas regras de firewall. Ela pode ser útil para auditar o acesso à rede ou fornecer aviso antecipado de que a rede está sendo usada de maneira não aprovada. O custo dos registros pode ser significativo. Para mais informações sobre a geração de registros de regras de firewall e seu custo, consulte Como usar a geração de registros de regras de firewall.

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall desejada.
  3. Clique em Editar.
  4. Em Registros, selecione Ativado.
  5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

FLOW_LOGS_DISABLED

Há uma sub-rede VPC com registros de fluxo desativados.

Os registros de fluxo de VPC registram uma amostra de fluxos de rede enviados e recebidos por instâncias de VM. Esses registros podem ser usados para monitoramento de rede, perícia forense, análise de segurança em tempo real e otimização de despesas. Para mais informações sobre registros de fluxo e seu custo, consulte Como usar registros de fluxo de VPC.

Para corrigir essa descoberta:

  1. Acesse a página Redes VPC.
    Acessar redes VPC
  2. Na lista de redes, clique no nome da rede desejada.
  3. Na página Detalhes da rede VPC, clique na guia Sub-redes.
  4. Na lista de sub-redes, clique no nome da sub-rede indicada na descoberta.
  5. Na página Detalhes da sub-rede, clique em Editar.
  6. Em Registros de fluxo, selecione Ativar.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

FULL_API_ACCESS

Uma instância do Compute Engine está configurada para usar a conta de serviço padrão com acesso total a todas as APIs do Google Cloud.

Uma instância configurada com o escopo padrão da conta de serviço, Permitir acesso completo a todas as APIs do Cloud, pode permitir que os usuários executem operações ou chamadas de API para as quais não têm permissões do IAM. Para mais informações, consulte a seção Conta do serviço padrão do Compute Engine.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias de VMs no Console do Cloud.
    Acessar instâncias de VM
  2. Na lista de instâncias, clique no nome da instância na descoberta.
  3. Clique em Interromper se a instância estiver iniciada no momento.
  4. Depois que a instância for interrompida, clique em Editar.
  5. Em Conta de serviço, no menu suspenso, selecione Conta de serviço padrão do Compute Engine.
  6. Na seção Acessar escopos, verifique se a opção Permitir acesso completo a todas as APIs do Cloud está selecionada.
  7. Clique em Save.
  8. Clique em Iniciar para iniciar a instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

HTTP_BALANCE_BALANCER

Uma instância do Compute Engine usa um balanceador de carga que é configurado para usar um proxy HTTP de destino em vez de um proxy HTTPS de destino.

Para proteger a integridade dos dados e evitar que invasores falsifiquem suas comunicações, configure os balanceadores de carga HTTP(S) para permitir apenas tráfego HTTPS. Para mais informações, consulte Visão geral do balanceamento de carga de HTTP(S) externo.

Para corrigir essa descoberta:

  1. Acesse a página Proxies de destino no Console do Cloud.
    Acessar proxies de destino
  2. Na lista de proxies de destino, clique no nome do proxy de destino na descoberta.
  3. Clique no link no Mapa de URL.
  4. Clique em Editar.
  5. Clique em Configuração de front-end.
  6. Exclua todas as configurações de IP de front-end e porta que permitam tráfego HTTP e crie novas que permitam tráfego HTTPS.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

IP_ALIAS_DISABLED

Um cluster do GKE foi criado com intervalos de IP de alias desativados.

Quando você ativa os intervalos de IP de alias, os clusters do GKE alocam endereços IP de um bloco CIDR conhecido. Assim, seu cluster é escalonável e interage melhor com os produtos e entidades do Google Cloud. Para mais informações, consulte Visão geral de intervalos de IP de alias.

Para corrigir essa descoberta:

No momento, não é possível migrar um cluster atual para usar IPs de alias. Para criar um novo cluster com IPs de alias ativados, faça o seguinte:

  1. Acesse a página de clusters do Kubernetes no Console do Cloud.
    Acessar os clusters do Kubernetes
  2. Clique em Criar.
  3. No painel de navegação, em Cluster, clique em Rede.
  4. Em Opções avançadas de rede, selecione Ativar roteamento de tráfego nativo de VPC (usando o IP do alias).
  5. Clique em Criar.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

IP_FORWARDING_ENABLED

O encaminhamento de IP está ativado nas instâncias do Compute Engine.

Evite a perda de dados ou a divulgação de informações desativando o encaminhamento de IP de pacotes de dados para suas VMs.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias de VMs no Console do Cloud.
    Acessar instâncias de VM
  2. Na lista de instâncias, marque a caixa ao lado do nome da instância na descoberta.
  3. Clique em Excluir
  4. Selecione Criar instância para criar uma nova instância e substituir a excluída.
  5. Para garantir que o encaminhamento de IP esteja desativado, clique em Gerenciamento, discos, rede, chaves SSH e em Rede.
  6. Em Interfaces de rede, clique em Editar.
  7. Em Encaminhamento de IP, no menu suspenso, verifique se Desativado está selecionado.
  8. Especifique outros parâmetros da instância e clique em Criar. Para mais informações, consulte Como criar e iniciar uma instância de VM.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

KMS_KEY_NOT_ROTATED

A rotação não está configurada em uma chave de criptografia do Cloud KMS.

A rotação regular de chaves de criptografia fornece proteção no caso de uma chave ser comprometida e limita o número de mensagens criptografadas disponíveis para criptografia em uma versão de chave específica. Para mais informações, consulte Rotação de chaves.

Para corrigir essa descoberta:

  1. Acesse a página Chaves do Cloud KMS no Console do Cloud.
    Acessar as chaves do Cloud KMS
  2. Clique no nome do keyring indicado na descoberta.
  3. Clique no nome da chave indicada na descoberta.
  4. Clique em Editar período de rotação.
  5. Defina o período de rotação para no máximo 90 dias.
  6. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

KMS_PROJECT_HAS_OWNER

Um usuário tem permissões roles/Owner em um projeto que tem chaves criptográficas. Para mais informações, consulte Permissões e papéis.

Para corrigir essa descoberta:

  1. Acessar a página "IAM".
    Acessar a página do IAM
  2. Se necessário, selecione o projeto na descoberta.
  3. Para cada membro com o papel de proprietário:
    1. Clique em Editar.
    2. No painel Editar permissões, ao lado do papel Proprietário, clique em Excluir.
    3. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

KMS_PUBLIC_KEY

Um keyring do Cloud KMS ou um keyring do Cloud KMS é público e pode ser acessado por qualquer pessoa na Internet. Para mais informações, consulte Como usar o IAM com o Cloud KMS.

Para corrigir esta descoberta, se estiver relacionada a uma Cryptokey:

  1. Acesse a página Chaves criptográficas no Console do Cloud.
    Chaves criptográficas
  2. Em Nome, selecione o keyring que contém a chave criptográfica relacionada à descoberta do Security Health Analytics.
  3. Na página Detalhes do keyring que é carregada, marque a caixa de seleção ao lado da chave criptográfica.
  4. Se oPAINEL DE INFORMAINFOES não for exibido, clique no íconeMOSTRAR PAINEL DE INFORMAINFOES botão.
  5. Use a caixa de filtro anterior a Papel / membro para pesquisar membros de allUsers e allAuthenticatedUsers e clique em Excluir. para remover o acesso desses membros.

Para corrigir essa descoberta, se estiver relacionada a um keyring:

  1. Acesse a página Chaves criptográficas no Console do Cloud.
    Chaves criptográficas
  2. Encontre a linha com o keyring na descoberta e marque a caixa de seleção.
  3. Se oPAINEL DE INFORMAINFOES não for exibido, clique no íconeMOSTRAR PAINEL DE INFORMAINFOES botão.
  4. Use a caixa de filtro anterior a Papel / membro para pesquisar membros de allUsers e allAuthenticatedUsers e clique em Excluir. para remover o acesso desses membros.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

KMS_ROLE_SEPARATION

Um ou mais membros de sua organização têm múltiplas permissões do Cloud KMS atribuídas. Recomenda-se que a permissão Administrador do Cloud KMS não seja utilizada com outras permissões simultaneamente. Para mais informações, consulte Permissões e papéis.

Para corrigir essa descoberta:

  1. Acesse a página "IAM" no Console do Cloud.
    Acessar IAM
  2. Clique em Editar ao lado do membro listado na descoberta do Security Health Analytics.
  3. Para remover permissões, clique em Excluir ao lado de Administrador do Cloud KMS. Se você quiser remover todas as permissões para o membro, clique em Excluir ao lado de todas as outras permissões.
  4. Clique em Save.
  5. Repita as etapas anteriores para cada um dos membros listados na descoberta do Security Health Analytics.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

LEGACY_AUTHORIZATION_ENABLED

A autorização legada está ativada nos clusters do GKE.

No Kubernetes, o controle de acesso baseado em papéis (RBAC, na sigla em inglês) permite definir papéis com regras que contêm um conjunto de permissões e conceder permissões no cluster e no nível de namespace. Isso oferece maior segurança ao garantir que os usuários tenham acesso somente a recursos específicos. Considere desativar o controle de acesso baseado em atributos (ABAC, na sigla em inglês) legado.

Para corrigir essa descoberta:

  1. Acesse a página de clusters do Kubernetes no Console do Cloud.
    Acessar os clusters do Kubernetes
  2. Selecione o cluster listado na descoberta do Security Health Analytics.
  3. Clique em Editar.

    Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

  4. Na lista suspensa Autorização herdada, selecione Desativada.

  5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

LEGACY_METADATA_ENABLED

Os metadados legados são ativados nos clusters do GKE.

O servidor de metadados de instância do Compute Engine expõe os endpoints /0.1/ e /v1beta1/ legados, que não aplicam cabeçalhos de consulta de metadados. Esse é um recurso nas APIs /v1/ que dificulta que um invasor em potencial recupere metadados de instância. A menos que seja necessário, recomendamos que você desative essas APIs legadas /0.1/ e /v1beta1/.

Para obter mais informações, consulte Como desativar e fazer a transição de APIs de metadados legados.

Para corrigir essa descoberta:

No momento, só é possível desativar as APIs de metadados legados ao criar um novo cluster ou adicionar um novo pool de nós a um cluster atual. Para atualizar um cluster existente e desativar as APIs de metadados legados, consulte Como migrar cargas de trabalho para diferentes tipos de máquina.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

REDE_LEGACY

Há uma rede legada em um projeto.

As redes legadas não são recomendadas porque muitos novos recursos de segurança do Google Cloud não são compatíveis com elas. Em vez disso, use redes VPC. Para mais informações, consulte Redes legadas.

Para corrigir essa descoberta:

  1. Acesse a página Redes VPC no Console do Cloud.
    Acessar redes VPC
  2. Para criar uma nova rede não legada, clique em Criar rede.
  3. Volte para a página Redes VPC.
  4. Na lista de redes, clique em legacy_network.
  5. Na página Detalhes da rede VPC, clique em Excluir rede VPC.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

LOCKED_RETENTION_POLICY_NOT_SET

Uma política de retenção bloqueada não está definida para registros.

Uma política de armazenamento bloqueada impede que os registros sejam substituídos e o bucket de registro seja excluído. Para mais informações, consulte Políticas de armazenamento e bloqueios de política de armazenamento.

Para corrigir essa descoberta:

  1. Acesse a página Navegador do Storage no Console do Cloud.
    Acessar o navegador do Storage
  2. Selecione o bucket listado na descoberta do Security Health Analytics.
  3. Na página Detalhes do bucket, clique na guia Retenção.
  4. Se uma política de retenção não tiver sido definida, clique em Definir política de retenção.
  5. Insira um período de armazenamento.
  6. Clique em Save. A política de retenção é mostrada na guia Retenção.
  7. Clique em Bloquear para que o período de armazenamento não seja reduzido ou removido.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

LOG_NOT_EXPORTED

Um recurso não tem um coletor de registros apropriado configurado.

O Cloud Logging ajuda a encontrar rapidamente a causa raiz dos problemas no sistema e nos aplicativos. No entanto, por padrão, a maioria dos registros é mantida por 30 dias. Exporte cópias de todas as entradas de registro para estender o período de armazenamento. Para mais informações, consulte Visão geral das exportações de registros.

Para corrigir essa descoberta:

  1. Acesse a página Roteador de registros.
    Acessar o roteador de registros
  2. Clique em Criar coletor.
  3. Preencha os campos obrigatórios. Os filtros de inclusão e exclusão permitem escolher quais registros exportar. Para garantir que todos os registros sejam exportados, deixe os filtros de inclusão e exclusão vazios.
  4. Clique em Criar coletor.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

MASTER_AUTHORIZED_NETWORKS_DISABLED

As redes autorizadas do mestre não estão ativadas em clusters do GKE.

As redes autorizadas do mestre melhoram a segurança do cluster de contêiner bloqueando o acesso de endereços IP especificados ao plano de controle do cluster. Para mais informações, consulte Como adicionar redes autorizadas para acessar o plano de controle.

Para corrigir essa descoberta:

  1. Acesse a página de clusters do Kubernetes no Console do Cloud.
    Acessar os clusters do Kubernetes
  2. Selecione o cluster listado na descoberta do Security Health Analytics.
  3. Clique em Editar.

    Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

  4. Na lista suspensa Redes principais autorizadas, selecione Ativadas.

  5. Clique em Adicionar rede autorizada.

  6. Especifique as redes autorizadas que você quer usar.

  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

MFA_NOT_ENFORCED

A autenticação multifatorial, especificamente a verificação em duas etapas (2SV, na sigla em inglês), desativada para alguns usuários na sua organização.

A autenticação multifatorial é usada para proteger contas contra acesso não autorizado e é a ferramenta mais importante para proteger a organização contra credenciais de login comprometidas. Para mais informações, consulte Proteger sua empresa com a verificação em duas etapas.

Para corrigir essa descoberta:

  1. Acesse a página do Admin console.
    Acessar o Admin Console
  2. Aplique a verificação em duas etapas em todas as unidades organizacionais.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

NETWORK_NOT_MONITORED

As métricas e os alertas do registro não estão configurados para monitorar alterações na rede VPC.

Para detectar alterações incorretas ou não autorizadas à configuração de rede, monitore as alterações na rede VPC. Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

Criar métrica

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Clique em Criar métrica.
  3. Em Tipo de Métrica, selecione Contador.
  4. Em Detalhes:
    1. Defina um Nome da métrica de registro.
    2. Adicione uma descrição.
    3. Definir Unidades para 1.
  5. Em Seleção de filtro, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto atual, se necessário:
      resource.type=gce_network AND jsonPayload.event_subtype="compute.networks.insert"
      OR jsonPayload.event_subtype="compute.networks.patch"
      OR jsonPayload.event_subtype="compute.networks.delete"
      OR jsonPayload.event_subtype="compute.networks.removePeering"
      OR jsonPayload.event_subtype="compute.networks.addPeering"
    
  6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Na seção Métricas definidas pelo usuário, selecione a métrica criada na seção anterior.
  3. Clique em Mais e, em seguida, clique em Criar alerta a partir da métrica. Conclua o processo para adicionar seu projeto a um espaço de trabalho.
  4. No menu de navegação da página exibida, clique em Alertas.
  5. Em O que você quer acompanhar?, clique em Adicionar condição e preencha a caixa de diálogo para definir quais recursos são monitorados e quando os alertas são acionados. Para ver informações sobre os campos de uma condição, consulte Como especificar condições.
  6. Quando terminar, clique em Adicionar e em Avançar.
  7. Em Quem deve ser notificado?, clique na lista suspensa Canais de notificação e selecione como você quer ser notificado. Para mais informações, consulte Como gerenciar canais de notificação.
  8. Clique em OK e em Avançar.
  9. Em Quais são as etapas para corrigir o problema?, defina um Nome de alerta.
  10. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

NETWORK_POLICY_DISABLED

A política de rede está desativada nos clusters do GKE.

Por padrão, a comunicação entre pods fica aberta. A comunicação aberta permite que os pods se conectem diretamente entre nós, com ou sem tradução de endereços de rede. Um recurso NetworkPolicy é como um firewall no nível do pod que restringe conexões entre pods, a menos que o recurso NetworkPolicy permita explicitamente a conexão. Saiba como definir uma política de rede.

Para corrigir essa descoberta:

  1. Acesse a página de clusters do Kubernetes no Console do Cloud.
    Acessar os clusters do Kubernetes
  2. Clique no nome do cluster que está na descoberta de análise de integridade de segurança.
  3. Em Rede, na linha de Política de rede, clique em Editar.

    Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

  4. Na caixa de diálogo, selecione Ativar política de rede para mestre e Ativar política de rede para nós.

  5. Clique em Save Changes.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

NODEPOOL_BOOT_CMEK_DISABLED

Os discos de inicialização neste pool de nós não são criptografados com chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês). O CMEK permite que o usuário configure as chaves de criptografia padrão para discos de inicialização em um pool de nós.

Para corrigir essa descoberta:

  1. Acessar a página de clusters do Kubernetes.
    Acessar os clusters do Kubernetes
  2. Na lista de clusters, clique no nome do cluster na descoberta.
  3. Clique na guia Nós.
  4. Para cada pool de nós default-pool, clique em Excluir .
  5. Para criar novos pools de nós usando CMEK, consulte Como usar chaves de criptografia gerenciadas pelo cliente (CMEK). A CMEK gera custos adicionais relacionados ao Cloud KMS.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

NON_ORG_IAM_MEMBER

Um usuário fora da organização tem permissões do IAM em um projeto ou organização. Saiba mais sobre as permissões do IAM.

Para corrigir essa descoberta:

  1. Acesse a página "IAM" no Console do Cloud.
    Acessar IAM
  2. Marque a caixa de seleção ao lado dos usuários fora da organização.
  3. Clique em Remover.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OBJECT_VERSIONING_DISABLED

O controle de versão de objeto não está ativado em um bucket de armazenamento em que os coletores estão configurados.

O Cloud Storage oferece o recurso de controle de versões de objetos para recuperar objetos que são excluídos ou substituídos. Ative o controle de versão de objetos para evitar que os dados do Cloud Storage sejam substituídos ou excluídos acidentalmente. Saiba como ativar o controle de versão de objetos.

Para corrigir essa descoberta, use o comando gsutil versioning set on com o valor apropriado:

    gsutil versioning set on gs://finding.assetDisplayName

Substitua finding.assetDisplayName pelo nome do bucket relevante.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_CASSANDRA_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte às portas do Cassandra pode expor seus serviços do Cassandra aos invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas de serviço do Cassandra são:

  • TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OPEN_CISCOSECURE_WEBSM_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas CiscoSecure/WebSM pode expor seus serviços CiscoSecure/WebSM para invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas de serviço CiscoSecure/WebSM são:

  • TCP - 9090

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_DIRECTORY_SERVICES_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas do diretório pode expor seus serviços de diretório a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço de diretório são:

  • TCP - 445
  • UDP - 445

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_DNS_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas DNS pode expor seus serviços DNS a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas de serviço DNS são:

  • TCP - 53
  • UDP - 53

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_ELASTICSEARCH_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas do Elasticsearch pode expor seus serviços do Elasticsearch aos invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço Elasticsearch são:

  • TCP - 9200, 9300

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OPEN_FIREWALL

As regras de firewall que permitem conexões de todos os endereços IP, como 0.0.0.0/0, ou de todas as portas podem expor desnecessariamente recursos para ataques de fontes indesejadas. Essas regras precisam ser removidas ou direcionadas explicitamente aos intervalos ou portas de IP de origem desejados. Por exemplo, em aplicativos destinados a serem públicos, considere restringir as portas permitidas para os necessários para o aplicativo, como 80 e 443. Se o aplicativo precisar permitir conexões de todos os endereços IP ou portas, considere permitir a listagem do recurso.

Saiba mais sobre como atualizar regras de firewall.

Para corrigir essa descoberta:

  1. Acesse a página Regras de firewall no Console do Cloud.
    Acessar as regras de firewall
  2. Clique na regra de firewall listada na descoberta do Security Health Analytics e clique em Editar.
  3. Em Intervalos de IP de origem, edite os valores de IP para restringir o intervalo de IPs permitidos.
  4. Em Protocolos e portas, selecione Protocolos e portas especificados, selecione os protocolos permitidos e insira as portas que são permitidas.
  5. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OPEN_FTP_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas FTP pode expor seus serviços de FTP a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço FTP são:

  • TCP - 21

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_HTTP_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas HTTP pode expor seus serviços HTTP a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço HTTP são:

  • TCP - 80

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_LDAP_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas LDAP podem expor seus serviços LDAP a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas de serviço LDAP são:

  • TCP - 389, 636
  • UDP - 389

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OPEN_MEMCACHED_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas do Memcached pode expor seus serviços do Memcached a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço Memcached são:

  • TCP - 11211, 11214, 11215
  • UDP - 11211, 11214, 11215

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_MONGODB_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte às portas do MongoDB pode expor seus serviços do MongoDB aos invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço MongoDB são:

  • TCP - 27017, 27018, 27019

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_MYSQL_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte às portas do MySQL podem expor seus serviços do MySQL a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço MySQL são:

  • TCP - 3306

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_NETBIOS_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte às portas do NetBIOS pode expor seus serviços do NetBIOS aos invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas de serviço do NetBIOS são:

  • TCP - 137, 138, 139
  • UDP - 137, 138, 139

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OPEN_ORACLEDB_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte às portas do OracleDB pode expor seus serviços do OracleDB para os invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço OracleDB são:

  • TCP - 1521, 2483, 2484
  • UDP - 2483, 2484

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_POP3_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas POP3 pode expor seus serviços POP3 a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço POP3 são:

  • TCP - 110

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_POSTGRESQL_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte às portas do PostgreSQL pode expor seus serviços do PostgreSQL a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas de serviço do PostgreSQL são:

  • TCP - 5432
  • UDP - 5432

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_RDP_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas RDP pode expor seus serviços RDP a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço RDP são:

  • TCP - 3389
  • UDP - 3389

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_REDIS_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte às portas do Redis pode expor seus serviços do Redis a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas de serviço do Redis são:

  • TCP - 6379

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_SMTP_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas SMTP pode expor seus serviços SMTP a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço SMTP são:

  • TCP - 25

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_SSH_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas SSH pode expor seus serviços SSH a invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas do serviço SSH são:

  • SCTP - 22
  • TCP - 22

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ABRIR_TELNET_PORT

As regras de firewall que permitem que qualquer endereço IP se conecte a portas da Telnet pode expor seus serviços da Telnet aos invasores. Para mais informações, consulte a visão geral das regras de firewall da VPC.

As portas de serviço da Telnet são:

  • TCP - 23

Para corrigir essa descoberta:

  1. Acesse a página Firewall no Console do Cloud.
    Acessar o Firewall
  2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.
  3. Clique em Editar.
  4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.
  5. Adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Adicione protocolos e portas específicos que você quer abrir na instância.
  7. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ORG_POLICY_CONFIDENCIAL_VM_POLICY

Um recurso do Compute Engine não está em conformidade com a política da organização constraints/compute.restrictNonConfidentialComputing. Para mais informações sobre essa restrição de política da organização, consulte Como aplicar restrições da política da organização.

A organização precisa ter o serviço de VM confidencial ativado. As VMs que não têm esse serviço ativado não usarão a criptografia de memória de ambiente de execução, expondo-as a ataques de memória de ambiente de execução.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias de VM
    Acessar instâncias de VM
  2. Na lista de instâncias, clique no nome da instância na descoberta.
  3. Se a VM não exigir o serviço de VM confidencial, mova-o para uma nova pasta ou projeto.
  4. Se a VM exigir VM confidencial, clique em Excluir.
  5. Para criar uma nova instância com a VM confidencial ativada, consulte o Guia de início rápido: como criar uma instância de VM confidencial.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ORG_POLICY_LOCATION_RESTRICTION

A restrição gcp.resourceLocations da política da organização permite restringir a criação de novos recursos às regiões do Cloud selecionadas. Para mais informações, consulte Como restringir locais de recursos.

Para corrigir essa descoberta:

O detector ORG_POLICY_LOCATION_RESTRICTION abrange muitos tipos de recursos, e as instruções de correção são diferentes para cada recurso. A abordagem geral para corrigir violações de localização inclui o seguinte:

  1. Copiar, mover ou fazer backup do recurso fora da região ou dos dados dele em um recurso na região. Leia a documentação de serviços individuais para receber instruções sobre como mover recursos.
  2. Exclua o recurso original fora da região ou os dados dele.

Essa abordagem não é possível para todos os tipos de recursos. Para orientações, consulte as recomendações personalizadas fornecidas na descoberta.

Outras considerações

Recursos gerenciados

Os ciclos de vida dos recursos às vezes são gerenciados e controlados por outros recursos. Por exemplo, um grupo de instâncias gerenciadas do Compute Engine cria e elimina instâncias do Compute Engine de acordo com a política de escalonamento automático do grupo de instâncias. Se os recursos gerenciados e de gerenciamento estiverem no escopo da aplicação de local, ambos poderão ser sinalizados como uma violação da política da organização. A correção de descobertas de recursos gerenciados precisa ser feita no recurso de gerenciamento para garantir a estabilidade operacional.

Recursos em uso

Alguns recursos são usados por outros. Por exemplo, um disco do Compute Engine conectado a uma instância do Compute Engine em execução é considerado em uso pela instância. Se o recurso em uso violar a política da organização de local, você precisará garantir que ele não esteja em uso antes de solucionar a violação de local.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OS_LOGIN_DISABLED

O login do SO está desativado nesta instância do Compute Engine.

O login de SO ativa o gerenciamento centralizado de chave SSH com IAM e desativa a configuração de chave SSH baseada em metadados em todas as instâncias de um projeto. Saiba como configurar e configurar o Login do SO.

Para corrigir essa descoberta:

  1. Acesse a página Metadados no Console do Cloud.
    Acessar metadados
  2. Clique em Editar e depois clique em Adicionar item.
  3. Adicione um item com a chave enable-oslogin e o valor TRUE.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OVER_PRIVILEGED_ACCOUNT

Um nó do GKE está usando o nó de serviço padrão do Compute Engine, que tem amplo acesso por padrão e pode ser substituído por executar o cluster do GKE.

Para corrigir essa descoberta:

Siga as instruções para usar contas de serviço do Google com menos privilégios.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OVER_PRIVILEGED_SCOPES

Uma conta de serviço do nó tem escopos de acesso amplo.

Escopos de acesso são o método legado de especificação das permissões da sua instância. Para reduzir a possibilidade de um encaminhamento de privilégios em um ataque, crie e use uma conta de serviço com privilégios mínimos para executar seu cluster do GKE.

Para corrigir essa descoberta, siga as instruções para usar contas de serviço do Google com menos privilégios.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

Um usuário tem iam.serviceAccountUser ou iam.serviceAccountTokenCreator para envolvidos no projeto em vez de para uma conta de serviço específica.

A concessão desses papéis a um usuário permite que ele acesse todas as contas de serviço atuais e futuras no projeto. Essa situação pode resultar em escalonamento inesperado de privilégios. Para mais informações, consulte Permissões da conta de serviço.

Para corrigir essa descoberta:

  1. Acessar a página "IAM".
    Acessar a página do IAM
  2. Se necessário, selecione o projeto na descoberta.
  3. Para cada membro atribuído roles/iam.serviceAccountUser ou roles/iam.serviceAccountTokenCreator:
    1. Clique em Editar.
    2. No painel Editar permissões, ao lado dos papéis, clique em Excluir.
    3. Clique em Save.
  4. Siga este guia para conceder a usuários individuais permissão para personificar uma única conta de serviço. É necessário seguir o guia de cada conta de serviço com a qual você quer permitir que os usuários escolhidos se comuniquem.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

OWNER_NOT_MONITORED

As métricas e os alertas do registro não são configurados para monitorar as atribuições ou alterações da propriedade do projeto.

O papel de proprietário do IAM tem o nível mais alto de privilégio em um projeto. Para proteger seus recursos, configure alertas para receber notificações quando novos proprietários forem adicionados ou removidos. Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

Criar métrica

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Clique em Criar métrica.
  3. Em Tipo de Métrica, selecione Contador.
  4. Em Detalhes:
    1. Defina um Nome da métrica de registro.
    2. Adicione uma descrição.
    3. Definir Unidades para 1.
  5. Em Seleção de filtro, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto atual, se necessário:
      (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
      AND (ProjectOwnership OR projectOwnerInvitee)
      OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
      AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
      OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
      AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
    
  6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Na seção Métricas definidas pelo usuário, selecione a métrica criada na seção anterior.
  3. Clique em Mais e, em seguida, clique em Criar alerta a partir da métrica. Conclua o processo para adicionar seu projeto a um espaço de trabalho.
  4. No menu de navegação da página exibida, clique em Alertas.
  5. Em O que você quer acompanhar?, clique em Adicionar condição e preencha a caixa de diálogo para definir quais recursos são monitorados e quando os alertas são acionados. Para ver informações sobre os campos de uma condição, consulte Como especificar condições.
  6. Quando terminar, clique em Adicionar e em Avançar.
  7. Em Quem deve ser notificado?, clique na lista suspensa Canais de notificação e selecione como você quer ser notificado. Para mais informações, consulte Como gerenciar canais de notificação.
  8. Clique em OK e em Avançar.
  9. Em Quais são as etapas para corrigir o problema?, defina um Nome de alerta.
  10. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

POD_SECURITY_POLICY_DISABLED

O PodSecurityPolicy está desativado em um cluster do GKE.

Um PodSecurityPolicy é um recurso controlador de admissão que valida solicitações para criar e atualizar pods em um cluster. Os clusters não aceitam pods que não atendam às condições definidas no PodSecurityPolicy.

Para corrigir essa descoberta, defina e autorize PodSecurityPolicies e ative o controlador PodSecurityPolicy. Para instruções, consulte Como usar PodSecurityPolicies.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PRIMITIVE_ROLES_USED

Um usuário tem um dos seguintes papéis básicos do IAM: roles/owner, roles/editor ou roles/viewer. Esses papéis são muito permissivos e não podem ser usados. Em vez disso, eles precisam ser atribuídos somente por projeto.

Para mais informações, consulte Como entender os papéis.

Para corrigir essa descoberta:

  1. Acessar a página de política de IAM.
    Acessar a política de IAM
  2. Para cada usuário com um papel primário, considere usar papéis mais granulares.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PRIVATE_CLUSTER_DISABLED

Um cluster do GKE tem um cluster privado desativado.

Clusters particulares só permitem que os nós tenham endereços IP internos. Esse recurso limita o acesso à Internet de saída para os nós. Se um nó de cluster não tiver um endereço IP público, ele não poderá ser descoberto ou exposto à Internet pública. Ainda é possível rotear o tráfego para um nó usando um balanceador de carga interno. Para mais informações, consulte Clusters particulares.

Não é possível tornar privado um cluster atual. Para corrigir essa descoberta, crie um novo cluster privado:

  1. Acesse a página de clusters do Kubernetes no Console do Cloud.
    Acessar os clusters do Kubernetes
  2. Clique em Criar cluster.
  3. Clique em Disponibilidade, rede, segurança e outros recursos e, depois, selecione as caixas de seleção para Ativar VPC-nativo (usando IP alias) e Cluster privado.
  4. Clique em Criar.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PRIVATE_GOOGLE_ACCESS_DISABLED

Há sub-redes privadas sem acesso às APIs públicas do Google.

O Acesso privado do Google permite que instâncias de VM com endereços IP internos (privados) alcancem os endereços IP públicos de APIs e serviços do Google.

Para mais informações, consulte Como configurar o Acesso privado do Google.

Para corrigir essa descoberta:

  1. Acesse a página Redes VPC.
    Acessar redes VPC
  2. Na lista de redes, clique no nome da rede desejada.
  3. Na página Detalhes da rede VPC, clique na guia Sub-redes.
  4. Na lista de sub-redes, clique no nome da sub-rede associada ao cluster do Kubernetes na descoberta.
  5. Na página Detalhes da sub-rede, clique em Editar .
  6. Em Acesso privado ao Google, selecione Ativado.
  7. Clique em Save.
  8. Para remover IPs públicos (externos) de instâncias de VM cujo único tráfego externo seja para as APIs do Google, consulte Como cancelar a atribuição de um endereço IP externo estático.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PUBLIC_BUCKET_ACL

Um bucket é público, e qualquer pessoa na Internet pode acessá-lo.

Para mais informações, consulte Visão geral do controle de acesso.

Para corrigir essa descoberta:

  1. Acesse a página Navegador do Storage no Console do Cloud.
    Acessar o navegador do Storage
  2. Selecione o bucket listado na descoberta do Security Health Analytics.
  3. Na página Detalhes do bucket, clique na guia Permissões.
  4. Ao lado de Visualizar por, clique em Papéis.
  5. Na caixa Filtro, pesquise allUsers e allAuthenticatedUsers.
  6. Clique em Excluir para remover todas as permissões do IAM concedidas a allUsers e allAuthenticatedUsers.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PUBLIC_COMPUTE_IMAGE

Uma imagem do Compute Engine é pública e qualquer pessoa na Internet pode acessá-la. allUsers representa qualquer pessoa na Internet, e allAuthenticatedUsers representa qualquer pessoa autenticada com uma Conta do Google; nem se limita a usuários na organização.

As imagens do Compute Engine podem conter informações confidenciais, como chaves de criptografia ou softwares licenciados. Essas informações confidenciais não podem ser acessadas publicamente. Se você pretende tornar público essa imagem do Compute Engine, verifique se ela não contém informações confidenciais.

Para mais informações, consulte Visão geral do controle de acesso.

Para corrigir essa descoberta:

  1. Acesse a página de imagens do Compute Engine no Console do Cloud.
    Acessar as imagens do Compute Engine
  2. Selecione a caixa ao lado da imagem public-image e clique em Mostrar painel de informações.
  3. Na caixa Filtro, pesquise os membros allUsers e allAuthenticatedUsers.
  4. Expanda o papel de que você quer remover usuários.
  5. Clique em Excluir para remover um usuário desse papel.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PUBLIC_DATASET

Um conjunto de dados do BigQuery é público e acessível a qualquer pessoa na Internet. O membro do IAM allUsers representa qualquer pessoa na Internet, e allAuthenticatedUsers representa qualquer pessoa que esteja conectada a um serviço do Google e não é restrita aos usuários na organização.

Para mais informações, consulte Como controlar o acesso a conjuntos de dados.

Para corrigir essa descoberta:

  1. Acesse a página Conjunto de dados do BigQuery
    Acessar o conjunto de dados do BigQuery
  2. Clique em Compartilhar conjunto de dados.
  3. No painel Permissões do conjunto de dados, use a caixa Pesquisar membros para procurar allUsers e allAuthenticatedUsers e remover o acesso desses membros.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PUBLIC_IP_ADDRESS

Uma instância do Compute Engine tem um endereço IP público.

Para reduzir a superfície de ataque das suas organizações, evite atribuir endereços IP públicos às VMs. As instâncias interrompidas ainda poderão ser sinalizadas com uma descoberta de IP público, por exemplo, se as interfaces de rede estiverem configuradas para atribuir um IP público temporário ao iniciar. Certifique-se de que as configurações de rede das instâncias interrompidas não incluam acesso externo.

Para mais informações, consulte Como se conectar a instâncias de VM com segurança.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias de VMs no Console do Cloud.
    Acessar Instâncias de VMs
  2. Na lista de instâncias, marque a caixa ao lado do nome da instância na descoberta.
  3. Clique em Editar.
  4. Para cada interface emInterfaces de rede, clique em Pode editar e definirIP externo àNenhuma opção para começar.
  5. Clique em Concluído e depois em Salvar.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PUBLIC_LOG_BUCKET

Um bucket de armazenamento é público e usado como um coletor de registros, o que significa que qualquer pessoa na Internet pode acessar os registros armazenados nele. allUsers representa qualquer pessoa na Internet, e allAuthenticatedUsers representa qualquer pessoa que esteja conectada a um serviço do Google. nem se aplica a usuários da organização.

Para mais informações, consulte Visão geral do controle de acesso.

Para corrigir essa descoberta:

  1. Acesse a página Navegador do Cloud Storage.
    Acessar o navegador do Cloud Storage
  2. Na lista de buckets, clique no nome do bucket indicado na descoberta.
  3. Clique na guia Permissões..
  4. Remova allUsers e allAuthenticatedUsers dos membros do bucket.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PUBLIC_SQL_INSTANCE

A instância do SQL tem 0.0.0.0/0 como uma rede permitida. Essa ocorrência significa que qualquer cliente IPv4 pode passar o firewall da rede e fazer tentativas de login para a instância, inclusive clientes que você não pretendia. Os clientes ainda precisam de credenciais válidas para fazer login na instância.

Para mais informações, consulte Como autorizar com redes autorizadas.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. No painel de navegação, clique em Conexões.
  5. Em Redes autorizadas, exclua 0.0.0.0/0 e adicione endereços IP específicos ou intervalos de IP que você quer conectar à instância.
  6. Clique em Concluído e depois em Salvar.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

PUBSUB_CMEK_DISABLED

Um tópico do Pub/Sub não é criptografado com chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês).

Com a CMEK, as chaves que você cria e gerencia no Cloud KMS unem as chaves que o Google usa para criptografar seus dados, dando a você mais controle sobre o acesso aos seus dados.

Para corrigir esta descoberta, exclua o tópico existente e crie um novo:

  1. Acesse a página Tópicos do Pub/Sub no Console do Cloud.

    Acessar temas

  2. Se necessário, selecione o projeto que contém o tópico do Pub/Sub.

  3. Marque a caixa de seleção ao lado do tópico listado na descoberta e clique em Excluir.

  4. Para criar um novo tópico do Pub/Sub com a CMEK ativada, consulte Como usar chaves de criptografia gerenciadas pelo cliente. A CMEK gera custos adicionais relacionados ao Cloud KMS.

  5. Publique descobertas ou outros dados no tópico Pub/Sub ativado para CMEK.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

ROUTE_NOT_MONITORED

As métricas e os alertas do registro não estão configurados para monitorar as alterações de rota da rede VPC.

As rotas do Google Cloud são destinos e saltos que definem o caminho que o tráfego de rede leva de uma instância de VM para um IP de destino. Monitorando alterações em tabelas de rota, você pode ajudar a garantir que todo o tráfego de VPC flua por um caminho esperado.

Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

Criar métrica

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Clique em Criar métrica.
  3. Em Tipo de Métrica, selecione Contador.
  4. Em Detalhes:
    1. Defina um Nome da métrica de registro.
    2. Adicione uma descrição.
    3. Definir Unidades para 1.
  5. Em Seleção de filtro, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto atual, se necessário:
      resource.type="gce_route"
      AND jsonPayload.event_subtype="compute.routes.delete"
      OR jsonPayload.event_subtype="compute.routes.insert"
    
  6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Na seção Métricas definidas pelo usuário, selecione a métrica criada na seção anterior.
  3. Clique em Mais e, em seguida, clique em Criar alerta a partir da métrica. Conclua o processo para adicionar seu projeto a um espaço de trabalho.
  4. No menu de navegação da página exibida, clique em Alertas.
  5. Em O que você quer acompanhar?, clique em Adicionar condição e preencha a caixa de diálogo para definir quais recursos são monitorados e quando os alertas são acionados. Para ver informações sobre os campos de uma condição, consulte Como especificar condições.
  6. Quando terminar, clique em Adicionar e em Avançar.
  7. Em Quem deve ser notificado?, clique na lista suspensa Canais de notificação e selecione como você quer ser notificado. Para mais informações, consulte Como gerenciar canais de notificação.
  8. Clique em OK e em Avançar.
  9. Em Quais são as etapas para corrigir o problema?, defina um Nome de alerta.
  10. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

REDIS_ROLE_USED_ON_ORG

Um papel do Redis IAM é atribuído no nível da organização ou da pasta.

Os papéis do Redis IAM a seguir precisam ser atribuídos apenas por projeto, não no nível da organização ou da pasta:

  • roles/redis.admin
  • roles/redis.viewer
  • roles/redis.editor

Para mais informações, consulte Controle de acesso e permissões.

Para corrigir essa descoberta:

  1. Acessar a página de política de IAM.
    Acessar a política de IAM
  2. Remova os papéis do IAM do Redis indicados na descoberta e adicione-os nos projetos individuais.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

RSASHA1_FOR_SIGNING (em inglês)

RSASHA1 é usado para assinatura de chaves em zonas do Cloud DNS. O algoritmo usado para assinatura de chaves não pode ser fraco.

Para corrigir essa descoberta, substitua o algoritmo por um recomendado seguindo o guia Como usar opções de assinatura avançadas.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SERVICE_ACCOUNT_KEY_NOT_ROTATED

Uma chave de conta de serviço gerenciada pelo usuário não foi girada há mais de 90 dias.

As chaves da conta de serviço gerenciada pelo usuário precisam ser giradas a cada 90 dias para garantir que os dados não sejam acessados com uma chave antiga que possa ter sido perdida, comprometida ou roubada. Para mais informações, consulte Como gerenciar chaves de conta de serviço.

Para corrigir essa descoberta:

  1. Acesse a página Contas de serviço.
    Acessar Contas de serviço
  2. Se necessário, selecione o projeto indicado na descoberta.
  3. Na lista de contas de serviço, encontre a conta de serviço listada na descoberta e clique em Excluir. Antes de prosseguir, pense no impacto na exclusão de uma conta de serviço nos recursos de produção.
  4. Crie uma nova chave de conta de serviço para substituir a antiga. Para mais informações, consulte Como criar chaves de conta de serviço.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SERVICE_ACCOUNT_ROLE_SEPARATION

Um ou mais membros de sua organização têm múltiplas permissões de conta de serviço atribuídas. Nenhuma conta precisa ter simultaneamente o Administrador da conta de serviço junto com outras permissões de conta de serviço. Para saber mais sobre as contas de serviço e os papéis disponíveis, consulte Contas de serviço.

Para corrigir essa descoberta:

  1. Acesse a página IAM no Console do Cloud.
    Acessar IAM
  2. Clique em Editar ao lado do membro listado na descoberta do Security Health Analytics.
  3. Para remover permissões, clique em Excluir ao lado de Administrador de conta de serviço. Se quiser remover todas as permissões da conta de serviço, clique em Excluir ao lado de todas as outras permissões.
  4. Clique em Save.
  5. Repita as etapas anteriores para cada um dos membros listados na descoberta do Security Health Analytics.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SHIELDED_VM_DISABLED

A VM protegida está desativada nesta instância do Compute Engine.

As VMs protegidas são máquinas virtuais (VMs) no Google Cloud reforçadas por um conjunto de controles de segurança que ajudam na defesa contra rootkits e bootkits. A VM protegida ajuda a garantir que o carregador de inicialização e o firmware sejam assinados e verificados. Saiba mais sobre VMs protegidas.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias de VMs no Console do Cloud.
    Acessar instâncias de VM
  2. Selecione a instância relacionada à descoberta da análise de integridade de segurança.
  3. Na página Detalhes da instância carregada, clique em Parar.
  4. Depois que a instância for interrompida, clique em Editar.
  5. Na seção VM protegida, alterne para Ativar vTPM e Ativar monitoramento de integridade para ativar a VM protegida.
  6. Opcionalmente, se você não usar drivers personalizados ou não assinados, ative também a Inicialização segura.
  7. Clique em Save. A nova configuração aparecerá na página Detalhes da instância.
  8. Clique em Iniciar para iniciar a instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_CMEK_DISABLED

Uma instância de banco de dados SQL não usa chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês).

Com a CMEK, as chaves que você cria e gerencia no Cloud KMS unem as chaves que o Google usa para criptografar seus dados, dando a você mais controle sobre o acesso aos seus dados. Para mais informações, consulte as visões gerais de CMEK do produto: Cloud SQL para MySQL, Cloud SQL para PostgreSQL ou Cloud SQL. para o SQL Server. A CMEK gera custos adicionais relacionados ao Cloud KMS.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Excluir
  4. Para criar uma nova instância com a CMEK ativada, siga as instruções para configurar o CMEK para seu produto:
    1. Cloud SQL para MySQL
    2. Cloud SQL para PostgreSQL
    3. Cloud SQL para SQL Server

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_CONTAINED_DATABASE_AUTHENTICATION

Uma instância de banco de dados do Cloud SQL para SQL Server não tem a sinalização de banco de dados autenticação de banco de dados contida, definida como Off.

A sinalização de autenticação de banco de dados contida controla se é possível criar ou anexar bancos de dados contidos ao Database. Um banco de dados contido inclui todas as configurações e metadados necessários para definir o banco de dados e não tem dependências de configuração na instância do Database Engine em que o banco de dados está instalado.

A ativação dessa sinalização não é recomendada devido ao seguinte:

  • Os usuários podem se conectar ao banco de dados sem autenticação no nível do Database Engine.
  • Isolar o banco de dados do Database Engine permite mover o banco de dados para outra instância do SQL Server.

Os bancos de dados contidos enfrentam ameaças únicas que devem ser compreendidas e mitidas pelos administradores do SQL Server Database Engine. A maioria das ameaças resulta do processo de autenticação USER WITH PASSWORD, que move o limite de autenticação do nível do Database Engine para o nível do banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização de banco de dados Autenticação do banco de dados contida com o valor Desativado.
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_CROSS_DB_OWNERSHIP_CHAINING (em inglês)

Uma instância de banco de dados do Cloud SQL para SQL Server não tem a sinalização de banco de dados Em cadeia de propriedade de banco de dados definida como desativada.

A sinalização de cadeamento de propriedade de banco de dados permite controlar o encadeamento de propriedade entre bancos de dados no nível do banco de dados ou permitir o encadeamento de propriedade entre bancos de dados para todas as instruções de banco de dados.

A ativação dessa sinalização não é recomendada, a menos que todos os bancos de dados hospedados pela instância do SQL Server participem de cadeias de propriedade entre bancos de dados e você esteja ciente das implicações de segurança dessa configuração.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização de banco de dados Em cadeia de propriedade cruzada de banco de dados com o valor Desativado.
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_INSTANCE_NOT_MONITORED

As métricas e os alertas do registro não estão configurados para monitorar as alterações de configuração da instância do Cloud SQL.

A configuração incorreta das opções de instâncias do SQL pode causar riscos de segurança. Desativar o backup automático e as opções de alta disponibilidade podem afetar a continuidade dos negócios, e não restringir redes autorizadas pode aumentar a exposição a redes não confiáveis. O monitoramento de alterações na configuração da instância do SQL ajuda a reduzir o tempo necessário para detectar e corrigir configurações incorretas.

Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Otimização de custos do conjunto de operações do Google Cloud.

Para corrigir essa descoberta:

Criar métrica

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Clique em Criar métrica.
  3. Em Tipo de Métrica, selecione Contador.
  4. Em Detalhes:
    1. Defina um Nome da métrica de registro.
    2. Adicione uma descrição.
    3. Definir Unidades para 1.
  5. Em Seleção de filtro, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto atual, se necessário:
      protoPayload.methodName="cloudsql.instances.update"
    
  6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

  1. Vá para a página Métricas com base em Registros.
    Acessar "Métricas com base em registros"
  2. Na seção Métricas definidas pelo usuário, selecione a métrica criada na seção anterior.
  3. Clique em Mais e, em seguida, clique em Criar alerta a partir da métrica. Conclua o processo para adicionar seu projeto a um espaço de trabalho.
  4. No menu de navegação da página exibida, clique em Alertas.
  5. Em O que você quer acompanhar?, clique em Adicionar condição e preencha a caixa de diálogo para definir quais recursos são monitorados e quando os alertas são acionados. Para ver informações sobre os campos de uma condição, consulte Como especificar condições.
  6. Quando terminar, clique em Adicionar e em Avançar.
  7. Em Quem deve ser notificado?, clique na lista suspensa Canais de notificação e selecione como você quer ser notificado. Para mais informações, consulte Como gerenciar canais de notificação.
  8. Clique em OK e em Avançar.
  9. Em Quais são as etapas para corrigir o problema?, defina um Nome de alerta.
  10. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_LOCAL_INFILE

Uma instância de banco de dados do Cloud SQL para MySQL não tem a sinalização do banco de dados local_infile definida como desativada. Devido a problemas de segurança associados à sinalização local_infile, ela será desativada. Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização local_infile do banco de dados com o valor Desativado.
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_LOG_CHECKPOINTS_DISABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização do banco de dados log_checkpoints definida como Ativada.

A ativação de log_checkpoints faz com que os checkpoints e os pontos de reinicialização sejam registrados no registro do servidor. Algumas estatísticas são incluídas nas mensagens de registro, incluindo o número de buffers gravados e o tempo gasto na gravação.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização log_checkpoints do banco de dados com o valor Ativado.
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_LOG_CONNECTIONS_DISABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_connections definida como On.

A ativação da configuração log_connections faz com que as tentativas de conexão com o servidor sejam registradas, com a conclusão bem-sucedida da autenticação do cliente. Os registros podem ser úteis para solucionar problemas e confirmar tentativas de conexão incomuns com o servidor.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização log_connections do banco de dados com o valor Ativado.
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_LOG_DISCONNECTIONS_DISABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_disconnections definida como On.

Ativar a configuração log_disconnections cria entradas de registro no final de cada sessão. Os registros são úteis para resolver problemas e confirmar atividades incomuns durante um período. Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização log_disconnections do banco de dados com o valor Ativado.
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_LOG_LOCK_WAITS_DISABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_lock_waits definida como Ativada.

Ativar a configuração log_lock_waits cria entradas de registro quando a sessão aguarda mais tempo do que o tempo deadlock_timeout para adquirir um bloqueio. Os registros são úteis para determinar se as esperas de bloqueio estão causando desempenho ruim.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização log_lock_waits do banco de dados com o valor Ativado.
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_min_duration_statement definida como -1.

A sinalização log_min_duration_statement faz com que as instruções SQL executadas durante mais de um tempo especificado sejam registradas. Considere desativar essa configuração porque as instruções SQL podem conter informações confidenciais que não devem ser registradas. Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização log_min_duration_statement do banco de dados com o valor -1.
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_LOG_MIN_ERROR_STATEMENT

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_min_duration_statement definida corretamente.

A sinalização log_min_error_statement controla se as instruções SQL que causam condições de erro são gravadas nos registros do servidor. As instruções SQL da gravidade especificada ou superior são registradas com mensagens para as instruções de erro. Quanto maior a gravidade, mais mensagens são registradas.

Se log_min_error_statement não estiver definido como o valor correto, as mensagens talvez não sejam classificadas como mensagens de erro. Um conjunto de gravidade muito baixo aumentaria o número de mensagens e dificultaria a identificação de erros reais. Um conjunto de gravidade muito alto pode causar que as mensagens de erro de erros reais não sejam registradas.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização de banco de dados log_min_duration_statement com um dos valores recomendados a seguir de acordo com a política de geração de registros da sua organização.
    • debug5
    • debug4
    • debug3
    • debug2
    • debug1
    • info
    • notice
    • warning
    • error
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_LOG_TEMP_FILES

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_temp_files definida como 0.

É possível criar arquivos temporários para classificações, hashes e resultados de consulta temporários. Definir a sinalização log_temp_files como 0 faz com que todas as informações de arquivos temporários sejam registradas. O registro de todos os arquivos temporários é útil para identificar possíveis problemas de desempenho. Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do Cloud SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Clique em Editar.
  4. Na seção Sinalizações do banco de dados, defina a sinalização log_temp_files do banco de dados com o valor 0.
  5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_NO_ROOT_PASSWORD

Uma instância de banco de dados MySQL não tem uma senha definida para a conta raiz. Adicione uma senha à instância do banco de dados MySQL. Para mais informações, consulte Usuários do MySQL.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Na página Detalhes da instância carregada, selecione a guia Usuários.
  4. Ao lado do usuário root, clique em Mais e selecione Alterar senha.
  5. Insira uma senha nova e forte e clique em OK.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_PUBLIC_IP

Um banco de dados do Cloud SQL tem um endereço IP público.

Para reduzir a superfície de ataque da sua organização, os bancos de dados do Cloud SQL não podem ter endereços IP públicos. Os endereços IP particulares oferecem melhor segurança de rede e menor latência para seu aplicativo.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Na guia Conexões, desmarque a caixa de seleção IP público.
  4. Se a instância ainda não estiver configurada para usar um IP particular, consulte Como configurar o IP privado para uma instância atual.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SQL_WEAK_ROOT_PASSWORD

Uma senha de banco de dados MySQL tem uma senha fraca definida para a conta raiz. Defina uma senha forte para a instância. Para mais informações, consulte Usuários do MySQL.

Para corrigir essa descoberta:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Na página Detalhes da instância carregada, selecione a guia Usuários.
  4. Ao lado do usuário root, clique em Mais e selecione Alterar senha.
  5. Insira uma senha nova e forte e clique em OK.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

SSL_NOT_ENFORCED

Uma instância de banco de dados do Cloud SQL não exige todas as conexões de entrada para usar SSL.

Para evitar o vazamento de dados confidenciais em trânsito durante comunicações não criptografadas, todas as conexões de entrada com sua instância do banco de dados do SQL precisam usar o SSL. Saiba mais sobre Como configurar SSL/TLS.

Para remediar essa descoberta, permita apenas conexões SSL para suas instâncias SQL:

  1. Acesse a página Instâncias do Cloud SQL no Console do Cloud.
    Acessar instâncias do SQL
  2. Selecione a instância listada na descoberta do Security Health Analytics.
  3. Na guia Conexões, clique em Permitir apenas conexões SSL.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

TOO_MANY_KMS_USERS

Limite o número de usuários principais que podem usar chaves criptográficas para três. Os papéis predefinidos a seguir concedem permissões para criptografar, descriptografar ou assinar dados usando chaves criptográficas:

  • roles/owner
  • roles/cloudkms.cryptoKeyEncrypterDecrypter
  • roles/cloudkms.cryptoKeyEncrypter
  • roles/cloudkms.cryptoKeyDecrypter
  • roles/cloudkms.signer
  • roles/cloudkms.signerVerifier

Para mais informações, consulte Permissões e papéis.

Para corrigir essa descoberta:

  1. Acesse a página Chaves do Cloud KMS no Console do Cloud.
    Acessar as chaves do Cloud KMS
  2. Clique no nome do keyring indicado na descoberta.
  3. Clique no nome da chave indicada na descoberta.
  4. Selecione a caixa ao lado da versão principal e clique em Mostrar painel de informações.
  5. Reduza o número de principais com permissões para criptografar, descriptografar ou assinar dados em três ou menos. Para revogar as permissões, clique em Excluir ao lado de cada membro.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

USER_MANAGED_SERVICE_ACCOUNT_KEY;

Um usuário gerencia uma chave de conta de serviço.

As contas de serviço não podem ter chaves gerenciadas pelo usuário porque elas podem ser facilmente acessadas. Para mais informações, consulte Como gerenciar chaves de conta de serviço.

Para corrigir essa descoberta:

  1. Acesse a página Contas de serviço.
    Acessar Contas de serviço
  2. Se necessário, selecione o projeto indicado na descoberta.
  3. Excluir as chaves da conta de serviço gerenciadas pelo usuário indicadas na descoberta se elas não forem usadas por qualquer aplicativo.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

WEAK_SSL_POLICY

Uma instância do Compute Engine tem uma política de SSL fraca.

Os balanceadores de carga de proxy SSL e HTTPS usam políticas SSL para determinar os conjuntos de protocolo e criptografia usados nas conexões TLS estabelecidas entre usuários e a Internet. Essas conexões criptografam dados confidenciais para evitar que invasores mal-intencionados os acessem. Com uma política de SSL fraca, os clientes que usam versões desatualizadas de TLS podem se conectar a um protocolo ou pacote de criptografia menos seguro. Para uma lista de conjuntos de criptografia recomendados e desatualizados, acesse a [página de parâmetros de TLS da yana.org] (em inglês). https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4)

Para corrigir essa descoberta:

  1. Acesse a página Proxies de destino no Console do Cloud.
    Acessar proxies de destino
  2. Encontre o proxy de destino indicado nas regras de encaminhamento e observação na coluna Em uso por.
  3. Para criar ou atualizar uma política de SSL, consulte Como usar políticas de SSL. A política precisa ter uma versão mínima de TLS 1.2 e um perfil moderno ou restrito.
  4. Para usar um perfil personalizado , verifique se os seguintes pacotes de criptografia estão desativados:
    • TLS_RSA_WITH_AES_128_GCM_SHA256
    • TLS_RSA_WITH_AES_256_GCM_SHA384
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  5. Aplique a política de SSL a cada regra de encaminhamento que você anotou.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

WEB_UI_ENABLED

A IU da Web do GKE (painel) está ativada.

As contas de serviço do Kubernetes altamente privilegiadas apoiam a interface da Web do Kubernetes. Caso ela seja comprometida, a conta de serviço pode ser violada. Se você já estiver usando o Console do Cloud, a interface da Web do Kubernetes estende a superfície de ataque desnecessariamente. Saiba mais sobre Como desativar a interface da Web do Kubernetes.

Para corrigir essa descoberta, desative a interface da Web do Kubernetes:

  1. Acesse a página de clusters do Kubernetes no Console do Cloud.
    Acessar os clusters do Kubernetes
  2. Clique no nome do cluster que está na descoberta de análise de integridade de segurança.
  3. Clique em Editar.

    Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

  4. Clique em Complementos. A seção se expande para exibir os complementos disponíveis.

  5. Na lista suspensa Painel do Kubernetes, selecione Desativado.

  6. Clique em Save.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.

WORKLOAD_IDENTITY_DISABLED

A Identidade da carga de trabalho está desativada em um cluster do GKE.

A identidade de carga de trabalho é a maneira recomendada de acessar os serviços do Google Cloud a partir do GKE porque oferece melhores propriedades de segurança e capacidade de gerenciamento. Sua ativação evita que metadados de sistema potencialmente confidenciais das cargas de trabalho do usuário sejam executados no seu cluster. Saiba mais sobre ocultação de metadados.

Para corrigir essa descoberta, siga o guia Ativar a identidade da carga de trabalho em um cluster.

Saiba mais sobre os recursos compatíveis e as configurações de verificação desse tipo de descoberta.