Corrigir erros do Security Command Center

Esta página fornece uma lista de guias de referência e técnicas para corrigir erros de SCC.

Antes de começar

Precisa de funções de gestão de identidade e de acesso (IAM) adequadas para ver ou editar descobertas e para aceder ou modificar Google Cloud recursos. Se encontrar erros de autorização ao aceder ao Security Command Center na Google Cloud consola, peça ajuda ao seu administrador. Para saber mais sobre as funções, consulte o artigo Controlo de acesso. Para resolver erros de recursos, leia a documentação dos produtos afetados.

Reveja as conclusões na Google Cloud consola

Os erros do SCC são erros de configuração que impedem o Security Command Center de funcionar conforme esperado. A origem Security Command Centergera estas conclusões.

Desde que o Security Command Center esteja configurado para a sua organização ou projeto, gera resultados de erros à medida que os deteta. Pode ver os erros de SCC na Google Cloud consola.

Use o procedimento seguinte para rever as conclusões na Google Cloud consola:

  1. Na Google Cloud consola, aceda à página Resultados do Centro de comando de segurança.

    Aceda a Conclusões

  2. Selecione o seu Google Cloud projeto ou organização.
  3. Na secção Filtros rápidos, na subsecção Nome a apresentar da origem, selecione Security Command Center. Os resultados da consulta de conclusões são atualizados para mostrar apenas as conclusões desta origem.
  4. Para ver os detalhes de uma descoberta específica, clique no nome da descoberta na coluna Categoria. O painel de detalhes da descoberta é aberto e apresenta o separador Resumo.
  5. No separador Resumo, reveja os detalhes da descoberta, incluindo informações sobre o que foi detetado, o recurso afetado e, se disponíveis, os passos que pode seguir para corrigir a descoberta.
  6. Opcional: para ver a definição JSON completa da descoberta, clique no separador JSON.

Desativação de erros de CCT após a correção

Depois de corrigir uma descoberta do SCC error, o Security Command Center define automaticamente o estado da descoberta como INACTIVE durante a análise seguinte. O tempo que o Security Command Center demora a definir o estado de uma descoberta corrigida como INACTIVE depende do momento em que corrige a descoberta e da programação da análise que deteta o erro.

Para obter informações sobre a frequência de análise de uma deteção SCC error, consulte o resumo da deteção em Detetores de erros.

Corrija erros do SCC

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

API disabled

Nome da categoria na API: API_DISABLED

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

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

Para corrigir esta descoberta, siga estes passos:

  1. Reveja a descoberta para determinar que API está desativada.
  2. Ative a API:

Saiba mais sobre os recursos suportados e as definições de análise deste 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 valores de recursos estão definidas para simulações de caminhos de ataque, mas não correspondem a nenhuma instância de recurso no seu ambiente. As simulações estão a usar o conjunto de recursos de alto valor predefinido.

As configurações de valores de recursos podem não corresponder a nenhum recurso pelos seguintes motivos, que são identificados na descrição da descoberta na consolaGoogle Cloud :

  • Nenhuma das configurações de valor do recurso corresponde a instâncias de recursos.
  • Uma ou mais configurações de valores de recursos 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 esta descoberta, siga estes passos:

  1. Aceda à página Simulação de caminho de ataque no Security Command Center Definições:

    Aceda às Definições

  2. Selecione a sua organização. A página Simulação de caminho de ataque é aberta com as configurações existentes apresentadas.

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

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

    1. Clique no nome de qualquer configuração de valor de recurso para apresentar as especificações de configuração.
    2. Se necessário, edite as especificações dos atributos dos 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 demasiado abrangente, faça o seguinte:

    1. Clique nos nomes de cada configuração que especifica um valor de HIGH, MEDIUM ou LOW para apresentar as especificações dos atributos dos recursos.
    2. Reveja e, se necessário, edite a configuração para corrigir o âmbito, o tipo de recurso, a etiqueta ou a especificação da etiqueta de modo a corresponder aos recursos pretendidos.
  6. Se necessário, crie uma nova configuração do valor do recurso.

As suas alterações são aplicadas à próxima simulação de caminho de ataque.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

APS resource value assignment limit exceeded

Nome da categoria na API: APS_RESOURCE_VALUE_ASSIGNMENT_LIMIT_EXCEEDED

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

Para corrigir esta descoberta, pode experimentar as seguintes ações:

  • Use etiquetas ou rótulos para reduzir o número de correspondências para um determinado tipo de recurso ou num âmbito especificado. As etiquetas têm de ser aplicadas às instâncias de recursos antes de poderem ser correspondidas por uma configuração de valor de recurso.
  • Crie uma configuração de valor do recurso que atribua um valor do recurso de NONE a um subconjunto dos recursos especificados noutra configuração.

    A especificação de um valor de NONE substitui todas as outras configurações e exclui as instâncias de recursos do seu conjunto de recursos de elevado valor.

  • Reduza a especificação do atributo do recurso de âmbito na configuração do valor do recurso.

  • Elimine as configurações de valor do recurso que atribuem um valor de LOW.

Para obter instruções sobre como criar, editar ou eliminar uma configuração de valor do recurso, consulte o artigo Defina e faça a gestão do seu conjunto de recursos de elevado valor.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

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 autorizações. O CIEM não consegue gerar uma ou mais categorias de resultados.

Para corrigir esta descoberta, restaure as funções do IAM necessárias na conta de serviço do CIEM:

  1. Na Google Cloud consola, aceda à página IAM.

    Aceda ao IAM

  2. Selecione a conta de serviço da CIEM da sua organização. O identificador da conta de serviço é um endereço de email 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 não vir a conta de serviço apresentada, clique em CONCEDER ACESSO na parte superior da página e introduza a conta de serviço como um novo principal.

  3. Conceda a função de agente de serviço da CIEM (roles/ciem.serviceAgent) à conta de serviço. Se usar funções personalizadas, certifique-se de que incluem as seguintes autorizações:

    • cloudasset.assets.exportResource
    • cloudasset.assets.exportIamPolicy
  4. Clique em Guardar.

CIEM AWS CloudTrail configuration error

Nome da categoria na API: AWS_CLOUDTRAIL_CONFIGURATION_ERROR

Alguns ou todos os resultados da CIEM da AWS não estão a ser enviados para o Security Command Center. O feed do AWS CloudTrail falhou e não consegue obter dados com êxito devido a um erro de configuração.

Existem três causas possíveis para esta descoberta:

  • Feed do AWS CloudTrail em falta

    Para corrigir este problema, crie e configure um feed na consola do Security Operations para carregar registos do AWS CloudTrail. Defina o par de chave-valor Etiqueta de carregamento como CIEM e TRUE.

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

  • Erros na configuração do feed

    Certifique-se de que configurou o feed corretamente.

    Para configurar um feed, consulte o artigo Configure o feed no Google Security Operations para carregar registos da AWS na documentação do Google SecOps.

  • Configuração do AWS CloudTrail incompleta

    Para corrigir este problema, configure o contentor S3 na configuração do AWS CloudTrail para registar eventos de dados e eventos de gestão de todas as contas da AWS onde pretende usar o CIEM.

    Para configurar o CloudTrail, consulte o artigo Configure 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

A Deteção de ameaças de contentores não consegue gerar resultados para um cluster do Google Kubernetes Engine, porque a conta de serviço predefinida do GKE no cluster não tem autorizações. Isto impede que a Deteção de ameaças de contentores seja ativada com êxito no cluster.

Para corrigir esta descoberta, restaure a conta de serviço predefinida do GKE e confirme que a conta de serviço tem a função Agente de serviço do Kubernetes Engine (roles/container.serviceAgent).

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

KTD blocked by admission controller

Nome da categoria na API: KTD_BLOCKED_BY_ADMISSION_CONTROLLER

Não é possível ativar a Deteção de ameaças de contentores num cluster porque um controlador de admissão de terceiros está a impedir a implementação do objeto Kubernetes DaemonSet necessário.

Para corrigir esta descoberta, certifique-se de que os controladores de admissão que estão a ser executados no cluster permitem que a Deteção de ameaças de contentores crie os objetos Kubernetes necessários.

Verifique o controlador de admissão

Verifique se o controlador de admissão no seu cluster está a recusar a implementação do objeto DaemonSet de deteção de ameaças de contentores.

  1. Na descrição da descoberta nos detalhes da descoberta na Google Cloud consola, reveja a mensagem de erro incluída do Kubernetes. A mensagem de erro do Kubernetes deve ser semelhante à seguinte mensagem:

    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 registos de auditoria do Cloud da atividade do administrador do projeto que contém o seu cluster, procure a mensagem de erro apresentada no campo Descrição dos detalhes da deteção.

  3. Se o controlador de admissão estiver a funcionar, mas estiver a recusar a implementação do objeto DaemonSet de deteção de ameaças de contentores, configure o controlador de admissão para permitir que o agente de serviço para a deteção de ameaças de contentores faça a gestão de objetos no espaço de nomes kube-system.

    O agente de serviço da Deteção de ameaças de contentores tem de conseguir gerir objetos específicos do Kubernetes.

Para mais informações sobre a utilização de controladores de admissão com a deteção de ameaças de contentores, consulte o artigo Política de segurança de pods e controladores de admissão.

Confirme a correção

Depois de corrigir o erro, o Security Command Center tenta automaticamente ativar a deteção de ameaças de contentores. Depois de aguardar a conclusão da ativação, pode verificar se a Deteção de ameaças de contentores está ativa através dos seguintes passos:

  1. Aceda à página Cargas de trabalho do Kubernetes Engine na consola.

    Aceda às cargas de trabalho do Kubernetes

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

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

  4. Procure a carga de trabalho container-watcher. Se container-watcher estiver presente e o respetivo estado mostrar OK, a Deteção de ameaças de contentores está ativa.

KTD image pull failure

Nome da categoria na API: KTD_IMAGE_PULL_FAILURE

Não é possível ativar a Deteção de ameaças de contentores no cluster porque não é possível obter (transferir) uma imagem de contentor necessária de gcr.io, o anfitrião de imagens do Container Registry.

A obtenção ou a transferência de uma imagem de contentor pode falhar por vários motivos possíveis.

Verifique o seguinte:

  • Certifique-se de que as definições da rede VPC, do DNS ou da firewall não estão a bloquear o acesso à rede do cluster ao anfitrião de imagens do gcr.io.
  • Se o cluster for privado, certifique-se de que o acesso privado à Google está ativado para permitir o acesso ao anfitrião de imagens gcr.io.
  • Se as definições de rede e o Acesso privado do Google não forem a causa da falha, consulte a documentação de resolução de problemas do GKE para ver erros ImagePullBackOff e ErrImagePull.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

KTD service account missing permissions

Nome da categoria na API: KTD_SERVICE_ACCOUNT_MISSING_PERMISSIONS

A conta de serviço da Deteção de ameaças de contentores identificada nos detalhes da descoberta na Google Cloud consola não tem as autorizações necessárias. Nem todas ou algumas das conclusões da Deteção de ameaças de contentores estão a ser enviadas para o Security Command Center.

Para corrigir esta descoberta, siga estes passos:

  1. Conceda a função Agente de serviço de deteção de ameaças de contentores (roles/containerthreatdetection.serviceAgent) à conta de serviço. Para mais informações, consulte o artigo Conceda uma única função.

    Em alternativa, se quiser usar uma função personalizada, certifique-se de que tem as autorizações na função Agente do serviço de deteção de ameaças de contentores.

  2. Certifique-se de que não existem políticas de recusa do IAM que impeçam a conta de serviço de usar quaisquer autorizações na função de agente do serviço de deteção de ameaças de contentores. Se existir uma política de recusa a bloquear o acesso, adicione a conta de serviço como um principal de exceção na política de recusa.

Para mais informações acerca da conta de serviço do Container Threat Detection e da função e das autorizações que requer, consulte o artigo Autorizações de IAM necessárias

Saiba mais sobre os recursos suportados e as definições de análise deste 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 está indisponível. Como resultado, o Security Command Center não pode enviar as conclusões para o Logging.

Para corrigir esta descoberta, faça uma das seguintes ações:

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

VPC Service Controls Restriction

Nome da categoria na API: VPC_SC_RESTRICTION

O Security Health Analytics não consegue produzir determinadas conclusões para um projeto porque o projeto está protegido por um perímetro de serviço. Tem de conceder à 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 email com o seguinte formato:

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

Substitua o seguinte:

  • RESOURCE_KEYWORD: a palavra-chave org ou project, consoante o recurso que detém a conta de serviço
  • RESOURCE_ID: uma das seguintes opções:

    • O ID da organização se a conta de serviço for propriedade da organização
    • O número do projeto se a conta de serviço for propriedade de um projeto

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

Para corrigir esta descoberta, siga estes passos.

Passo 1: determine que perímetro de serviço está a bloquear o Security Health Analytics

  1. Obtenha o ID exclusivo dos VPC Service Controls e o ID do projeto associado à descoberta:

    1. Para ver os detalhes da descoberta, clique no nome da respetiva categoria.
    2. No campo Descrição, copie o ID exclusivo dos VPC Service Controls, por exemplo, 5e4GI409D6BTWfOp_6C-uSwmTpOQWcmW82sfZW9VIdRhGO5pXyCJPQ.
    3. No campo Caminho do recurso, copie o ID do projeto.
  2. Obtenha o ID da política de acesso e o nome do perímetro de serviço:

    1. Na Google Cloud consola, aceda à página Explorador de registos.

      Aceda ao Explorador de registos

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

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

      Pesquise por UID do erro

      Se o erro não aparecer nos resultados da consulta, expanda a cronologia no histograma e, em seguida, volte a executar a consulta.

    4. Clique no erro apresentado.

    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.

        Nome completo do recurso do perímetro de serviço

    7. Para obter o nome a apresentar que corresponde ao ID da política de acesso, use a CLI gcloud.

      Se não conseguir fazer consultas ao nível da organização, peça ao administrador para executar este passo.

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

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

      Recebe um resultado semelhante ao seguinte:

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

      O nome a apresentar é o título que corresponde ao ID da política de acesso. Tome nota do nome a apresentar da política de acesso e do nome do perímetro de serviço. Precisa delas na secção seguinte.

Passo 2: crie uma regra de entrada que conceda acesso ao projeto

Esta secção requer que tenha acesso ao nível da organização aos VPC Service Controls. Se não tiver acesso ao nível da organização, peça ao seu administrador para executar estes passos.

Nos passos seguintes, vai criar uma regra de entrada no perímetro de serviço que identificou no passo 1.

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

  1. Aceda aos VPC Service Controls.

    Aceda aos VPC Service Controls

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

  3. Na lista pendente, selecione a política de acesso que contém o perímetro de serviço ao qual quer conceder acesso.

    Lista de políticas de acesso

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

  4. Clique no nome do perímetro de 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 forma:

    Atributos DE do cliente API

    1. Em Origem, selecione Todas as origens.
    2. Para Identidade, selecione Identidades selecionadas.
    3. No campo Adicionar utilizador/conta de serviço, clique em Selecionar.
    4. Introduza o endereço de email da conta de serviço. Se tiver contas de serviço ao nível da organização e do projeto, adicione ambas.
    5. Clique em Guardar.

    TO attributes of services/resources

    1. Para Projeto, selecione Todos os projetos ou selecione o projeto especificado na deteção.

    2. Para Serviços, selecione Todos os serviços ou selecione serviços específicos para os quais aparecem violações dos VPC Service Controls.

    Se um perímetro de serviço restringir o acesso a um serviço necessário, o Security Health Analytics não pode produzir resultados para esse serviço.

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

Para mais informações, consulte o artigo Configurar políticas de entrada e saída.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 autorizações necessárias para funcionar corretamente.

O identificador da conta de serviço é um endereço de email com o seguinte formato:

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

Substitua o seguinte:

  • RESOURCE_KEYWORD: a palavra-chave org ou project, consoante o recurso que detém a conta de serviço
  • RESOURCE_ID: uma das seguintes opções:

    • O ID da organização se a conta de serviço for propriedade da organização
    • O número do projeto se a conta de serviço for propriedade de um projeto

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

Para corrigir esta descoberta, siga estes passos:

  1. Conceda a função de agente de serviço do centro de segurança (roles/securitycenter.serviceAgent) à conta de serviço.

    Para mais informações, consulte o artigo Conceda uma única função.

    Em alternativa, se quiser usar uma função personalizada, certifique-se de que tem as autorizações na função Agente do serviço do Centro de segurança.

  2. Certifique-se de que não existem políticas de recusa de IAM que impeçam a conta de serviço de usar qualquer uma das autorizações nas funções necessárias. Se existir uma política de recusa a bloquear o acesso, adicione a conta de serviço como um principal de exceção na política de recusa.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

O que se segue?

Saiba mais sobre os erros do Security Command Center.