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 sua organização ou projeto, ele gera descobertas de erros à medida que os detecta. É 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:

Console do Google Cloud

1. No console do Google Cloud, acesse a página Descobertas do Security Command Center.

   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. Os resultados da consulta de descobertas são atualizados para mostrar apenas as descobertas dessa fonte.
4. Para conferir os detalhes de uma descoberta específica, clique no nome dela na coluna Categoria. O painel de detalhes da descoberta é aberto e mostra a guia Resumo.
5. Na guia Resumo, revise os detalhes da descoberta, incluindo informações sobre o que foi detectado, o recurso afetado e, se disponível, as etapas que podem ser realizadas para corrigir a descoberta.
6. Opcional: para conferir a definição JSON completa da descoberta, clique na guia JSON.

Console de operações de segurança

Somente nível Enterprise:esse recurso está disponível apenas com o nível Enterprise do Security Command Center.

1. No console de operações de segurança, acesse a página Descobertas.

   https://CUSTOMER_SUBDOMAIN.backstory.chronicle.security/posture/findings
   

   Substitua CUSTOMER_SUBDOMAIN pelo seu identificador específico do cliente.

2. Na seção Agregações, clique para expandir a subseção Nome de exibição da origem.
3. Selecione Security Command Center. Os resultados da consulta de descobertas são atualizados para mostrar apenas as descobertas dessa fonte.
4. Para conferir os detalhes de uma descoberta específica, clique no nome dela na coluna Categoria. O painel de detalhes da descoberta é aberto e mostra a guia Resumo.
5. Na guia Resumo, revise os detalhes da descoberta, incluindo informações sobre o que foi detectado, o recurso afetado e, se disponível, as etapas que podem ser realizadas para corrigir a descoberta.
6. Opcional: para conferir a definição JSON completa da descoberta, clique na guia JSON.

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 da 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: se feito incorretamente, a modificação da configuração dos recursos 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 atuais.

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 o número de correspondências de um determinado tipo de recurso ou dentro de um escopo especificado. As tags ou 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 recurso, 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.

CIEM service account missing permissions

Somente nível Enterprise:esse recurso está disponível apenas com o nível Enterprise do Security Command Center.

Nome da categoria na API: CIEM_SERVICE_ACCOUNT_MISSING_PERMISSIONS

A conta de serviço usada pelo serviço CIEM não tem permissões. O CIEM não pode gerar uma ou mais categorias de descoberta.

Para corrigir essa descoberta, restaure os papéis do IAM necessários na conta de serviço do CIEM:

1. No console do Google Cloud, abra a página IAM.

   Acessar IAM

2. Selecione a conta de serviço do CIEM da sua organização. O identificador da conta de serviço é um endereço de e-mail com o seguinte formato:

   [e-mail]
   

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

   Se a conta de serviço não estiver listada, clique em GRANT ACCESS na parte de cima da página e insira a conta de serviço como um novo principal.

3. Conceda o papel de agente de serviço do CIEM (roles/ciem.serviceAgent) à conta de serviço. Se você usa papéis personalizados, verifique se eles incluem as seguintes permissões:

   • cloudasset.assets.exportResource
   • cloudasset.assets.exportIamPolicy

4. Clique em Salvar.

CIEM AWS CloudTrail configuration error

Somente nível Enterprise:esse recurso está disponível apenas com o nível Enterprise do Security Command Center.

Nome da categoria na API: AWS_CLOUDTRAIL_CONFIGURATION_ERROR

Todas ou algumas das descobertas da CIEM da AWS não estão sendo enviadas para o Security Command Center. O feed do AWS CloudTrail falhou e não consegue buscar dados devido a um erro de configuração.

Há três possíveis causas para essa descoberta:

• Feed do AWS CloudTrail ausente

  Para corrigir esse problema, crie e configure um feed no console de operações de segurança para ingerir registros do AWS CloudTrail. Defina o par de chave-valor rótulo de transferência como CIEM e TRUE.

  Para instruções sobre como criar um feed, consulte Criar o feed na documentação do Google SecOps.

• Erros na configuração do feed

  Verifique se você configurou o feed corretamente.

  Para configurar um feed, consulte Configurar o feed nas Operações de segurança do Google para processar registros da AWS na documentação das Operações de segurança do Google.

• Configuração incompleta do AWS CloudTrail

  Para corrigir esse problema, configure o bucket do S3 na configuração do AWS CloudTrail para registrar eventos de dados e eventos de gerenciamento de todas as contas da AWS em que você pretende usar o CIEM.

  Para configurar o CloudTrail, consulte Configurar o AWS CloudTrail (ou outro serviço) na documentação do Google SecOps.

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, restaure a conta de serviço padrão do GKE e confirme se ela tem o papel de Agente 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. Na descrição da descoberta nos detalhes da descoberta do console do Google Cloud, analise a mensagem de erro incluída do Kubernetes. A mensagem de erro do Kubernetes deve 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 o agente de serviço do Container Threat Detection gerencie objetos no namespace kube-system.

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

Para mais informações sobre como usar controladores de admissão com o Container Threat Detection, consulte PodSecurityPolicy e controladores de admissão.

Confirmar a correção

Depois que você 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 (transferida por download) 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 e 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 das descobertas da Detecção de ameaças do contêiner 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 necessá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 a 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 ele é 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: a 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 você não puder fazer consultas no nível da organização, peça ao administrador para realizar essa etapa.

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

      Substitua ORGANIZATION_ID pelo ID numérico da sua 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

Esta seção exige que você tenha acesso ao VPC Service Controls no nível da organização. 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ê vai 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 acesso de entrada a um perímetro de serviço a uma conta 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. Em Serviços, selecione Todos os serviços ou selecione cada um dos seguintes serviços individuais que o Security Health Analytics exige:

      • 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 obrigatório, o Security Health Analytics 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

O agente de serviço 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: a 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.