Como corrigir erros do Security Command Center

Nesta página, você encontra uma lista de guias e técnicas de referência para corrigir erros do SCC.

Antes de começar

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

Analisar descobertas no console do Google Cloud

Os erros do SCC são erros de configuração que impedem o funcionamento do Security Command Center. A origem Security Command Center gera essas descobertas.

Desde que o Security Command Center esteja configurado para a organização ou projeto, ele gera descobertas de erros à medida que as detectam. É possível ver os erros SCC no Console do Google Cloud.

Use o procedimento a seguir para analisar as descobertas no console do Google Cloud:

1. Acesse a página Descobertas do Security Command Center no Console do Google Cloud.

   Acesse Descobertas

2. Selecione a organização ou o projeto do Google Cloud.

   

3. Na seção Filtros rápidos, na subseção Nome de exibição da origem, selecione Security Command Center.

4. Para ver detalhes sobre uma descoberta específica, clique no nome da descoberta em Category. O painel detalhes da descoberta é expandido para exibir informações, incluindo:

   • Resumo gerado por IA^{Visualização}: uma explicação gerada dinamicamente sobre o problema que foi encontrado
   • Descrição: uma breve explicação sobre o erro detectado
   • Hora do evento: quando a descoberta ocorreu
   • Nome de exibição do recurso: o recurso afetado
   • Próximas etapas: instruções sobre como resolver o erro
   • Nome canônico da descoberta: um identificador exclusivo para a descoberta
   • Nome de exibição da origem: Security Command Center

5. Opcional: para visualizar a definição JSON completa da descoberta, clique na guia JSON.

   O painel exibe a definição JSON da descoberta, em que é possível inspecionar todos os atributos dela.

Desativação de erros do SCC após a correção

Depois de corrigir uma descoberta de SCC error, o Security Command Center define automaticamente o estado da descoberta como INACTIVE durante a próxima verificação. O tempo que leva para o Security Command Center definir o estado de uma descoberta corrigida como INACTIVE depende de quando você corrige a descoberta e a programação da verificação que detecta o erro.

Para informações sobre a frequência de verificação de uma descoberta SCC error, consulte o resumo da descoberta em Detectores de erros.

Corrigir erros de SCC

Esta seção inclui instruções de correção para todos os erros do SCC.

Cuidado: alterar as configurações dos recursos incorretamente pode afetar negativamente o ambiente de produção. Além disso, ativar alguns serviços sugeridos do Google Cloud pode aumentar os custos com a nuvem. Entenda o impacto de todas as etapas de correção antes de fazer alterações.

API disabled

Nome da categoria na API: API_DISABLED

Um dos seguintes serviços está desativado para o projeto:

• Container Threat Detection
• Web Security Scanner

O serviço desativado não pode gerar descobertas.

Para corrigir essa descoberta, siga estas etapas:

1. Revise a descoberta para determinar qual API está desativada.

2. Ative a API:

   • Ative a API Container Threat Detection.

     Ativar a API

   • Ative a API Web Security Scanner.

     Ativar a API

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

APS no resource value configs match any resources

Nome da categoria na API: APS_NO_RESOURCE_VALUE_CONFIGS_MATCH_ANY_RESOURCES

As configurações de valor do recurso são definidas para simulações de caminho de ataque, mas não correspondem a nenhuma instância de recurso no ambiente. As simulações estão usando o conjunto de recursos padrão de alto valor.

As configurações de valor de recurso podem não corresponder a nenhum dos recursos pelos seguintes motivos, identificados na descrição da descoberta no console do Google Cloud:

• Nenhuma das configurações de valor de recurso corresponde a nenhuma instância de recurso.
• Uma ou mais configurações de valor de recurso que especificam NONE substituem todas as outras configurações válidas.
• Todas as configurações de valor de recurso definidas especificam um valor de NONE.

Para corrigir essa descoberta, siga estas etapas:

1. Acesse a página Simulação de caminho de ataque nas Configurações do Security Command Center:

   Acesse configurações

2. Selecione a organização. A página Simulação de caminho de ataque é aberta com as configurações que já existem.

3. Na coluna Valor do recurso da lista Configurações do valor do recurso, verifique os valores de None.

4. Para qualquer configuração que especifique None, faça o seguinte:

   1. Clique no nome de qualquer configuração de valor do recurso para exibir as especificações dela.

   2. Se necessário, edite as especificações de atributos de recursos para reduzir o número de instâncias de recursos que correspondem à configuração.

5. Se o problema não for causado por uma especificação None muito ampla, faça o seguinte:

   1. Clique nos nomes de cada configuração que especifica um valor de HIGH, MEDIUM ou LOW para exibir as especificações de atributo do recurso.

   2. Revise e, se necessário, edite a configuração para corrigir o escopo, o tipo de recurso, a tag ou a especificação do rótulo para corresponder aos recursos pretendidos.

6. Se necessário, crie uma nova configuração de valor de recursos.

As mudanças serão aplicadas à próxima simulação de caminho de ataque.

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

APS resource value assignment limit exceeded

Nome da categoria na API: APS_RESOURCE_VALUE_ASSIGNMENT_LIMIT_EXCEEDED

Na última simulação de caminho de ataque, o número de instâncias de recursos de alto valor, conforme identificado pelas configurações de valor do recurso, excedeu o limite de 1.000 instâncias em um conjunto de recursos de alto valor. Como resultado, o Security Command Center excluiu o número excessivo de instâncias do conjunto de recursos de alto valor.

Para corrigir essa descoberta, você pode tentar as seguintes ações:

• Use tags ou rótulos para reduzir as correspondências numéricas de um determinado tipo de recurso ou dentro de um escopo especificado. As tags ou os rótulos precisam ser aplicados às instâncias de recursos antes de serem correspondidos por uma configuração de valor de recurso.
• Crie uma configuração de valor de recurso que atribua um valor de recurso de NONE a um subconjunto dos recursos especificados em outra configuração. A especificação de um valor de NONE modifica qualquer outra configuração e exclui as instâncias de recursos do seu conjunto de recursos de alto valor.
• Reduza a especificação do atributo de recurso de escopo na configuração do valor do recurso.
• Exclua configurações de valor de recursos que atribuem um valor de LOW.

Para instruções sobre como criar, editar ou excluir uma configuração de valor de recursos, consulte Definir e gerenciar seu conjunto de recursos de alto valor.

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

GKE service account missing permissions

Nome da categoria na API: GKE_SERVICE_ACCOUNT_MISSING_PERMISSIONS

O Container Threat Detection não pode gerar descobertas para um cluster do Google Kubernetes Engine porque a conta de serviço padrão do GKE no cluster não tem permissões. Isso impede que a detecção de ameaças do contêiner seja ativada no cluster.

Para corrigir essa descoberta,restaurar a conta de serviço padrão do GKE e confirme se a conta de serviço tem oAgente de serviço do Kubernetes Engine (roles/container.serviceAgent ).

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

KTD blocked by admission controller

Nome da categoria na API: KTD_BLOCKED_BY_ADMISSION_CONTROLLER

O Container Threat Detection não pode ser ativado em um cluster porque um controlador de admissão de terceiros está impedindo a implantação do objeto DaemonSet do Kubernetes necessário.

Para corrigir essa descoberta, verifique se os controladores de admissão em execução no cluster permitem que o Container Threat Detection crie os objetos necessários do Kubernetes.

Verificar o controlador de admissão

Verifique se o controlador de admissão no cluster está negando a implantação do objeto DaemonSet do Container Threat Detection.

1. Em descrição, nos detalhes da descoberta do console do Google Cloud, analise a mensagem de erro do Kubernetes. A mensagem de erro do Kubernetes será semelhante a esta:

   generic::failed_precondition: incompatible admission webhook:
   admission webhook "example.webhook.sh" denied the request:
   [example-constraint] you must provide labels: {"example-required-label"}.
   

2. Nos Registros de auditoria do Cloud da atividade do administrador do projeto que contém o cluster, procure a mensagem de erro exibida no campo Descrição dos detalhes da descoberta.

3. Se o controlador de admissão estiver funcionando, mas negar a implantação do objeto DaemonSet do Container Threat Detection, configure-o para permitir que a conta de serviço gerenciada pelo Google para o Container Threat Detection gerencie objetos no namespace kube-system.

   A conta de serviço do Container Threat Detection precisa gerenciar objetos específicos do Kubernetes.

Para saber mais sobre como usar controladores de admissão com o Container Threat Detection, consulte PodSecurityPolicy e controladores de admissão.

Confirme a correção

Depois de corrigir o erro, o Security Command Center tentará ativar automaticamente o Container Threat Detection. Após a conclusão da ativação, verifique se o Container Threat Detection está ativo seguindo estas etapas:

1. Acesse a página Cargas de trabalho do Kubernetes Engine no console.

   Acesse Cargas de trabalho do Kubernetes

2. Se necessário, selecione Mostrar cargas de trabalho do sistema.

3. Na página Cargas de trabalho, filtre as cargas de trabalho primeiro pelo nome do cluster.

4. Procure a carga de trabalho container-watcher. Se a container-watcher estiver presente e o status mostrar OK, o Container Threat Detection está ativo.

KTD image pull failure

Nome da categoria na API: KTD_IMAGE_PULL_FAILURE

O Container Threat Detection não pode ser ativado no cluster porque uma imagem de contêiner necessária não pode ser extraída (baixada) do gcr.io, o host de imagem do Container Registry.

A extração ou o download de uma imagem de contêiner pode falhar por qualquer um dos vários motivos possíveis.

Verifique se:

• Verifique se as configurações de rede VPC, DNS ou firewall não estão bloqueando o acesso à rede do cluster para o host de imagens gcr.io.
• Se o cluster for particular, verifique se o Acesso privado do Google está ativado para permitir o acesso ao host de imagens gcr.io.
• Se as configurações de rede ou o Acesso privado do Google não forem a causa da falha, consulte a documentação de solução de problemas do GKE para ver erros ImagePullBackOff e ErrImagePull.

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

KTD service account missing permissions

Nome da categoria na API: KTD_SERVICE_ACCOUNT_MISSING_PERMISSIONS

A conta de serviço do Container Threat Detection identificada nos detalhes da descoberta no console do Google Cloud não tem as permissões necessárias. Todas ou algumas descobertas do Container Threat Detection não estão sendo enviadas ao Security Command Center.

Para corrigir essa descoberta, siga estas etapas:

1. Conceda o papel Agente de serviço do Container Threat Detection (roles/containerthreatdetection.serviceAgent) à conta de serviço. Para mais informações, consulte Conceder um único papel.

   Como alternativa, se você quiser usar um papel personalizado, verifique se ele tem as permissões do agente de serviço do Container Threat Detection.

2. Verifique se não há políticas de negação do IAM que impeçam a conta de serviço de usar qualquer uma das permissões no papel de agente de serviço do Container Threat Detection. Se houver uma política de negação bloqueando o acesso, adicione a conta de serviço como uma principal de exceção na política de negação.

Para mais informações sobre a conta de serviço do Container Threat Detection e o papel e as permissões necessárias, consulte

• Permissões do IAM obrigatórias

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

Misconfigured Cloud Logging Export

Nome da categoria na API: MISCONFIGURED_CLOUD_LOGGING_EXPORT

O projeto configurado para exportação contínua para o Cloud Logging não está disponível. Por isso, o Security Command Center não envia descobertas para o Logging.

Para corrigir essa descoberta, siga um destes procedimentos:

• Se o período de recuperação do projeto ainda não tiver passado, restaure o projeto ausente.

  Observação: é possível verificar o número de dias restantes no período de recuperação usando o método Google Cloud CLI gcloud projects describe.

• Se o projeto tiver sido excluído permanentemente, configure um projeto novo ou existente para exportações do Logging.

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

VPC Service Controls Restriction

Nome da categoria na API: VPC_SC_RESTRICTION

O Security Health Analytics não produz algumas descobertas para um projeto porque o projeto é protegido por um perímetro de serviço. Conceda à conta de serviço do Security Command Center acesso de entrada ao perímetro de serviço.

O identificador da conta de serviço é um endereço de e-mail com o seguinte formato:

[e-mail]

Substitua:

• RESOURCE_KEYWORD: palavra-chave org ou project, dependendo do recurso proprietário da conta de serviço
• RESOURCE_ID: uma das seguintes opções:
  • o ID da organização, se a conta de serviço pertencer à organização
  • o número do projeto, se a conta de serviço pertencer a um projeto

Se houver contas de serviço no nível da organização e do projeto, aplique a correção a ambas.

Para corrigir essa descoberta, siga estas etapas.

Etapa 1: determinar qual perímetro de serviço está bloqueando o Security Health Analytics

1. Consiga o ID exclusivo do VPC Service Controls e o ID do projeto associado à descoberta:
   1. Para ver os detalhes da descoberta, clique no nome da categoria.
   2. No campo Descrição, copie o ID exclusivo do VPC Service Controls, por exemplo, 5e4GI409D6BTWfOp_6C-uSwmTpOQWcmW82sfZW9VIdRhGO5pXyCJPQ.
   3. No campo Caminho do recurso, copie o ID do projeto.

2. Consiga o ID da política de acesso e o nome do perímetro de serviço:

   1. No console do Google Cloud, acesse a página do Explorador de registros.

      Acessar o Explorador de registros

   2. Na barra de ferramentas, selecione o projeto associado à descoberta.

      

   3. Na caixa de pesquisa, insira o ID exclusivo do erro.

      

      Se o erro não aparecer nos resultados da consulta, estenda a linha do tempo no Histograma e, em seguida, execute novamente a consulta.

   4. Clique no erro exibido.

   5. Clique em Expandir campos aninhados.

   6. Copie o valor do campo servicePerimeterName. O valor tem o seguinte formato:

      accessPolicies/ACCESS_POLICY/servicePerimeters/SERVICE_PERIMETER

      Neste exemplo, o nome completo do recurso do perímetro de serviço é accessPolicies/540107806624/servicePerimeters/vpc_sc_misconfigured.

      • ACCESS_POLICY é o ID da política de acesso, por exemplo, 540107806624.
      • SERVICE_PERIMETER é o nome do perímetro de serviço. Por exemplo, vpc_sc_misconfigured.

      

   7. Para ver o nome de exibição que corresponde ao ID da política de acesso, use a CLI gcloud:

      Se não for possível fazer consultas no nível da organização, peça para o administrador realizar esta etapa.

      gcloud access-context-manager policies list --organization ORGANIZATION_ID
      

      Substitua ORGANIZATION_ID pelo ID numérico da organização.

      Você verá um resultado parecido com este:

      NAME          ORGANIZATION  SCOPES                 TITLE           ETAG
      540107806624  549441802605                         default policy  2a9a7e30cbc14371
      352948212018  549441802605  projects/393598488212  another_policy  d7b47a9ecebd4659

      O nome de exibição é o título que corresponde ao ID da política de acesso. Anote o nome de exibição da política de acesso e o nome do perímetro de serviço. Você precisará deles na próxima etapa.

Etapa 2: criar uma regra de entrada que conceda acesso ao projeto

Nesta seção, você precisa ter acesso no nível da organização ao VPC Service Controls. Se você não tiver acesso no nível da organização, peça ao administrador para realizar essas etapas.

Nas etapas a seguir, você criará uma regra de entrada no perímetro de serviço identificado na etapa 1.

Observação: se você não conseguir identificar o perímetro de serviço restrito na etapa 1, recomendamos a execução das seguintes etapas para cada perímetro de serviço na sua organização que restringe o acesso ao projeto e aos serviços que o Security Health Analytics chama. É possível verificar as configurações de cada perímetro de serviço usando o console do Google Cloud ou a Google Cloud CLI.

Para conceder a uma conta de serviço acesso de entrada a um perímetro de serviço, siga estas etapas.

1. Acesse o VPC Service Controls.

   Acessar o VPC Service Controls

2. Na barra de ferramentas, selecione sua organização do Google Cloud.

   

3. Na lista suspensa, selecione a política de acesso que contém o perímetro de serviço a que você quer conceder acesso.

   

   Os perímetros de serviço associados à política de acesso aparecem na lista.

4. Clique no nome do serviço.

5. Clique em Editar perímetro.

6. No menu de navegação, clique em Política de entrada.

7. Clique em Adicionar regra.

8. Configure a regra da seguinte maneira:

   Atributos FROM do cliente da API

   1. Em Origem, selecione Todas as fontes.
   2. Em Identidade, selecione Identidades selecionadas.
   3. No campo Add User/Service Account, clique em Select.
   4. Insira o endereço de e-mail da conta de serviço. Se você tiver contas de serviço no nível da organização e do projeto, adicione ambas.
   5. Clique em Save.

   Atributos TO de serviços/recursos do GCP

   1. Em Projeto, selecione Todos os projetos ou selecione o projeto especificado na descoberta.

   2. Para Serviços, selecione Todos os serviços ou selecione cada um dos seguintes serviços individuais exigidos pelo Security Health Analytics:

      • API BigQuery
      • API Binary Authorization
      • API Cloud Logging
      • API Cloud Monitoring
      • API Compute Engine
      • API Kubernetes Engine

   Se um perímetro de serviço restringir o acesso a um serviço necessário, a Análise de integridade da segurança não poderá produzir descobertas para esse serviço.

9. No menu de navegação, clique em Salvar.

Para mais informações, consulte Como configurar políticas de entrada e saída.

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

Security Command Center service account missing permissions

Nome da categoria na API: SCC_SERVICE_ACCOUNT_MISSING_PERMISSIONS

A conta de serviço gerenciada pelo Google do Security Command Center não tem as permissões necessárias para funcionar corretamente.

O identificador da conta de serviço é um endereço de e-mail com o seguinte formato:

[e-mail]

Substitua:

• RESOURCE_KEYWORD: palavra-chave org ou project, dependendo do recurso proprietário da conta de serviço
• RESOURCE_ID: uma das seguintes opções:
  • o ID da organização, se a conta de serviço pertencer à organização
  • o número do projeto, se a conta de serviço pertencer a um projeto

Se houver contas de serviço no nível da organização e do projeto, aplique a correção a ambas.

Para corrigir essa descoberta, siga estas etapas:

1. Conceda o papel de agente de serviço da Central de segurança (roles/securitycenter.serviceAgent) à conta de serviço.

   Para mais informações, consulte Conceder um único papel.

   Como alternativa, se você quiser usar um papel personalizado, verifique se ele tem as permissões no papel Agente de serviço da Central de segurança.

2. Verifique se não há políticas de negação do IAM que impeçam a conta de serviço de usar qualquer uma das permissões nos papéis necessários. Se houver uma política de negação bloqueando o acesso, adicione a conta de serviço como uma principal de exceção na política de negação.

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

A seguir

Saiba mais sobre os erros do Security Command Center.