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 vai gerar descobertas de erros à medida que as detectar. É 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:

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

Depois de corrigir uma descoberta SCC error, o Security Command Center automaticamente define o estado da descoberta como INACTIVE durante a próxima verificação. Quanto tempo o Security Command Center precisa definir o estado de uma descoberta corrigida para 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 um resumo da descoberta nos detectores de erros.

Corrigir erros de SCC

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

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

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

APS no resource value configs match any resources

Nome da categoria na API: APS_NO_RESOURCE_VALUE_CONFIGS_MATCH_ANY_RESOURCES

Configurações do valor de recurso são definidos para simulações de caminho de ataque, mas não correspondem a nenhum instâncias no seu 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 o configurações existentes exibidas.

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, editar as especificações do atributo de recurso 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.

read_more 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

No(s) último(s) simulação de caminho de ataque, o número de instâncias de recursos de alto valor, conforme identificado pelo Configurações do valor de recursos, excedeu o limite de 1.000 instâncias de recursos em um conjunto de recursos. 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 substitui 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 um valor de recurso do Terraform, consulte Defina e gerencie seu conjunto de recursos de alto valor.

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

CIEM service account missing permissions

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:

   service-org-ORGANIZATION_ID@gcp-sa-ciem.iam.gserviceaccount.com
   

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

   Se a conta de serviço não estiver listada, clique em CONCEDER ACESSO, no parte superior da página e insira a conta de serviço como o 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 o as seguintes permissões:

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

4. Clique em Salvar.

CIEM AWS CloudTrail configuration error

Nome da categoria na API: AWS_CLOUDTRAIL_CONFIGURATION_ERROR

Todas ou algumas descobertas da AWS no CIEM não estão sendo enviadas ao 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 Configure o feed nas Operações de segurança do Google para ingerir os registros da AWS na documentação do Google SecOps.

• Configuração incompleta do AWS CloudTrail

  Para corrigir esse problema, defina o bucket S3 na configuração do AWS CloudTrail para registrar eventos de dados e eventos de gerenciamento de todas as contas da AWS em que 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, restaurar a conta de serviço padrão do GKE, e confirme se a conta de serviço tem o Agente de serviço do Kubernetes Engine (roles/container.serviceAgent).

read_more 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 que estão em execução no cluster, permitem que o Container Threat Detection crie a objetos do Kubernetes.

Verificar o controlador de admissão

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

1. Na descrição da descoberta em "Como encontrar detalhes no console do Google Cloud", analise a mensagem de erro incluída no 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 seu controlador de admissão está funcionando, mas nega a implantação de objeto DaemonSet do Container Threat Detection, configure o controlador de admissão para permitir que o agente de serviço para Container Threat Detection para gerenciar objetos no namespace kube-system.

   O agente de serviço do Container Threat Detection precisa ser capaz de gerenciar objetos 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 container-watcher estiver presente e o status mostra OK, a Detecção de ameaças a contêineres está ativa.

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 Acesso privado do Google está ativado para permitir o acesso ao host de imagem gcr.io.
• Se as configurações de rede e o Acesso privado do Google não forem a causa do da falha, consulte a documentação de solução de problemas do GKE ImagePullBackOff e ErrImagePull erros.

read_more 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 têm as permissões necessárias. Todos 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, garantir que ele tenha permissões no Agente de serviço do Container Threat Detection de rede.

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 o papel e a conta de serviço do Container Threat Detection e as permissões necessárias, consulte Permissões do IAM obrigatórias

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

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 pode enviar descobertas para a geração de registros.

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.

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

read_more 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. Você precisa conceder à conta de serviço do Security Command Center acesso de entrada à perímetro de serviço.

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

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

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 você tiver contas de serviço nos níveis da organização e do projeto, aplique a correção de ambos.

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 ao administrador para 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 serviço. do perímetro. 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 no nível da organização a 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ê vai criar uma regra de entrada no perímetro de serviço identificado na etapa 1.

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 editEditar 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 cada uma das seguintes opções serviços individuais exigidos pela Análise de integridade da segurança:

      • 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.

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

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:

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

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, definir ele tem as permissões Agente de serviço da Central de segurança de rede.

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 negação o acesso de bloqueio de política, adicione a conta de serviço exceção principal na negação política.

read_more 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.