Trabalhar com a UI de feeds

Compatível com:

Neste documento, explicamos como criar, resolver problemas e gerenciar feeds na interface de gerenciamento de feeds, incluindo instruções para modificar, ativar e excluir feeds.

Antes de começar

Cada feed de dados exige pré-requisitos específicos antes da configuração no Google Security Operations. Para encontrar os requisitos do seu feed, consulte Configuração por tipo de origem e pesquise sua fonte de dados específica.

Formatos de compactação e tamanhos de arquivo aceitos

Os formatos de compactação compatíveis com a ingestão de feeds incluem .gz, .tar.gz, .tar e solr.gz. A tabela a seguir descreve os diferentes tamanhos de arquivo compatíveis com a transformação de feeds do Google SecOps:

Operação Tipo de entrada Tamanho recomendado Duração esperada Tamanho máximo
Modelagem de dados CSV < 5 GB < 7 min 10 GB
Modelagem de dados CSV < 5 GB ~30 min 10 GB
Modelagem de dados CSV A definir A definir 2 GB
Modelagem de dados XML / JSON < 1 GB < 10 min 2 GB
Modelagem de dados XLS / XLSX < 50 MB ~1 minuto 50 MB
Mesclar arquivos Qualquer < 1 GB Varia de acordo com o número de arquivos 100 GB
Descompactar arquivos Não ZIP < 5 GB Varia de acordo com o número de arquivos 10 GB (descompactados)
Descompactar arquivos CEP - Varia de acordo com o número de arquivos 4 GB (descompactado)

Limites e delimitadores de linha de registro

Ao ingerir registros baseados em texto (JSON, CSV ou Syslog), verifique se os dados estão de acordo com estes limites de ingestão específicos:

  • Tamanho máximo da linha: uma única linha de registro não pode exceder 4 MB. Se uma única linha exceder esse limite, o feed vai falhar com o erro MaxLogLineSize4MBExceeded.
  • Delimitadores compatíveis: há suporte para nova linha (\n) e retorno de carro + nova linha (\r\n).

Impacto da mudança do projeto na nuvem vinculado nos feeds de dados

Se você estiver atualizando o projeto do Google Cloud associado à sua instância do Google SecOps, todos os feeds que ingerem dados usando os conectores a seguir serão interrompidos e precisarão ser recriados manualmente:

  • AMAZON_S3_V2
  • AMAZON_SQS_V2
  • GOOGLE_CLOUD_STORAGE_V2
  • AZURE_BLOBSTORE_V2
  • GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN

Para todos os outros feeds que não usam esses conectores, a ingestão continua sem interrupções. Os clientes não precisam fazer nada.

O que esperar durante a migração

Nos feeds afetados, você vai notar as seguintes mudanças:

  • Status do feed: os feeds criados antes da migração vão parar de extrair dados em tempo real imediatamente e se tornarão somente leitura.
  • Dados atuais: todos os dados que já foram transferidos para o Google SecOps antes da migração serão ingeridos automaticamente. Nenhum dado será perdido.
  • Mensagens de erro: se você tentar editar ou excluir um feed mais antigo, vai receber a mensagem This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed.

Ações necessárias para os clientes

Para garantir a ingestão contínua de dados, recrie manualmente seus feeds no novo ambiente. Siga estas etapas para minimizar as interrupções:

  1. Recriar feeds de notícias: é necessário criar novos feeds de notícias para substituir os que existiam antes da migração.
  2. Configurar a idade máxima do arquivo: ao configurar os novos feeds de notícias, defina a idade máxima do arquivo como cerca de 2 horas antes do início da atualização do BYOP. Esse período garante uma transição tranquila.

  3. Gerenciar dados duplicados: dependendo da Idade máxima do arquivo selecionada, pode haver alguma transferência de dados duplicados. Para detalhes técnicos sobre como o Google SecOps filtra esses registros redundantes, consulte Evitar a eliminação de duplicação.

  4. Registre e exclua os feeds atuais (antes da migração): antes de iniciar a migração do BYOP, registre as definições de configuração de todos os feeds atuais que usam os conectores afetados (por exemplo, Amazon S3 V2) e exclua os feeds. Se você não excluir os feeds criados antes da migração, eles se tornarão não gerenciáveis e permanecerão na interface da Web do Google SecOps como configurações órfãs.

Formas de configurar feeds

Há duas maneiras de os clientes do Google SecOps configurarem um feed na plataforma. Use o método mais adequado para seu ambiente:

  • Configurações do SIEM > Feeds (padrão)
  • Hub de conteúdo > Pacotes de conteúdo (premium)

Configurar a lista de permissões de IP

Quando o Google SecOps extrai dados de APIs do S3, do SQS, do Azure e de terceiros, a infraestrutura do Google se conecta ao bucket do cliente ou à API de terceiros.

Para a lista de permissões de entrada nos buckets de armazenamento ou firewalls, configure a lista de permissões de acordo com o tipo de feed, conforme descrito na lista a seguir:

  • Feeds V2 (S3_V2, SQS_V2, Azure_Blobstore_V2): esses feeds usam exclusivamente o Google Cloud Serviço de transferência do Cloud Storage (STS) para extrair dados do armazenamento do cliente. Eles exigem que os intervalos de IP do STS sejam incluídos na lista de permissões: ipranges.json.
  • APIs de terceiros: exigem goog.json.
  • Feeds legados (S3, Azure_Blobstore): exigem intervalos de IP dedicados. Para mais informações, entre em contato com o suporte do Google SecOps.
  • Hub de Eventos do Azure: requer intervalos de IP específicos da região. Para mais informações, consulte Configurar a segurança de rede (opcional) em Criar um feed do Hub de Eventos do Azure.

Como os intervalos de IP dos Serviços do Google mudam dinamicamente, o Google recomenda que você configure seu firewall para buscar e analisar periodicamente os feeds da seguinte maneira:

  • Feeds V2 (S3_V2, SQS_V2, Azure_Blobstore_V2): a transferência de dados é executada exclusivamente por workers do Serviço de transferência do Cloud Storage. Basta buscar e analisar periodicamente o arquivo ipranges.json.
  • Feeds legados (S3, SQS, Azure_Blobstore, Azure Event Hub) e APIs de terceiros: essas conexões se originam da infraestrutura do Google. Basta buscar e analisar periodicamente goog.json e cloud.json.

Configurar seus feeds

Nesta seção, descrevemos como configurar seus feeds em geral, começando com o fluxo de procedimento padrão. Os feeds de dados listados na página Feeds incluem todos os feeds que o Google configurou para sua conta, incluindo os que você configurou.

Adicionar um feed

Para adicionar um feed à sua conta do Google SecOps, siga estas etapas:

  1. No menu do Google SecOps, selecione Configurações do SIEM > Feeds.

  2. Clique em Adicionar novo feed.

  3. Na página seguinte, clique em Configurar um único feed. Observação: esta etapa não é relevante para clientes que usam a plataforma independente do SIEM do Google SecOps.

  4. Adicione um nome para o feed.

  5. Na lista Tipo de origem, selecione o tipo de origem para importar dados para o Google SecOps. Você pode escolher entre os seguintes tipos de origem de feed:

    • Amazon Data Firehose
    • Amazon S3 (descontinuado)
    • Amazon S3 (V2)
    • Amazon SQS (descontinuado)
    • Amazon SQS (V2)
    • Armazenamento de blobs do Azure (descontinuado)
    • Armazenamento de blobs do Azure (V2)
    • API personalizada
    • Google Cloud Pub/Sub
    • Cloud Storage (descontinuado)
    • Cloud Storage (V2)
    • Cloud Storage orientado por eventos
    • API de terceiros
    • Webhook

    Importante:

    • Ao usar feeds do Amazon S3 (descontinuado), do Amazon SQS (descontinuado), do Armazenamento de Blobs do Azure (descontinuado) e do Google Cloud Cloud Storage (descontinuado), verifique se você tem um caminho de diretório válido.
    • Ao usar o Amazon SQS (descontinuado) ou o Amazon SQS (V2), conceda explicitamente ao Google SecOps permissões para excluir mensagens da fila do Amazon SQS.
    • Ao usar feeds do Amazon SQS (descontinuado), verifique se apenas um feed consome mensagens da fila. As mensagens lidas por outro aplicativo ou feed não são ingeridas no feed atual.
    • O uso do Amazon SQS (descontinuado) como o tipo de origem do feed só é compatível com registros em buckets do Amazon S3.

  6. Na lista Tipo de registro, selecione o tipo de registro que corresponde aos registros que você quer ingerir. Os registros disponíveis variam de acordo com o tipo de origem selecionado anteriormente.

    Se você selecionar Cloud Storage como o tipo de origem, use a opção Receber conta de serviço para receber uma conta de serviço exclusiva. Consulte o exemplo de configuração de feed do Google Cloud Storage.

  7. Clique em Próxima.

  8. Especifique os parâmetros necessários na guia Parâmetros de entrada. As opções apresentadas aqui variam de acordo com a origem e o tipo de registro selecionados na guia Definir propriedades. Mantenha o ponteiro do mouse sobre o ícone de pergunta de cada campo para ver mais informações sobre o que você precisa fornecer.

  9. Opcional: é possível especificar um namespace na guia Definir propriedades. Para mais informações sobre namespaces, consulte Trabalhar com namespaces de recursos.

  10. Clique em Próxima.

  11. Revise a nova configuração do feed de notícias na guia Finalizar.

  12. Clique em Enviar. O Google SecOps conclui uma verificação de validação do novo feed. Se o feed passar na verificação, um nome será gerado para ele, que será enviado ao Google SecOps, que começará a tentar buscar dados.

Configurar vários feeds para uma família de produtos (somente clientes do Google SecOps)

É possível configurar vários feeds por família de produtos, com base no tipo de registro.

  • Tipos de registro de referência: marcados como recomendados. Esses tipos de registro são recomendados para a funcionalidade principal da plataforma.
  • Tipos de registro complementares: marcados como opcionais. Esses tipos de registro fornecem mais contexto.

Para simplificar a configuração, a plataforma oferece instruções específicas e parâmetros predefinidos para cada configuração. Por exemplo, para o CrowdStrike Falcon, é possível criar vários feeds exclusivos nos tipos de registro recomendados e opcionais para garantir que haja cobertura de dados suficiente.

Configurar o feed para o CrowdStrike EDR

Siga estas etapas para configurar um feed de registros para o CrowdStrike EDR.

  1. Em Configurações > Feeds, clique em Adicionar novo feed.
    1. Clique no produto CrowdStrike Falcon:
    2. Selecione o tipo de registro CrowdStrike EDR.
  2. Como alternativa, em Hub de conteúdo > Pacotes de conteúdo, clique no produto CrowdStrike Falcon:
    1. Clique em Primeiros passos.
    2. Selecione o tipo de registro CrowdStrike EDR.

  3. Especifique valores para os seguintes campos:

    Campo Descrição
    Source Type Amazon SQS
    Region A região do AWS S3 associada ao URI.
    Queue Name O nome da fila SQS de onde os dados serão lidos.
    Account Number O número da conta do SQS.
    Source Deletion Option Indica se os arquivos e diretórios devem ser excluídos após a transferência.
    Queue Access Key ID Uma chave de acesso alfanumérica de 20 caracteres para a conta, como AKIAOSFOODNN7EXAMPLE.
    Queue Secret Access Key Uma chave de acesso secreta alfanumérica de 40 caracteres para a conta, como wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

  4. Opcional: configure os seguintes parâmetros:

    • Nome do feed: nome exclusivo pré-preenchido para o feed.
    • Namespace do recurso: namespace associado ao feed.
    • Rótulos de ingestão: rótulos aplicados aos eventos desse feed.

  5. Clique em Criar feed.

Repita esse processo para criar outros feeds para o mesmo tipo de registro. Também é possível configurar feeds para outros tipos de registro disponíveis diretamente nesta página. Quando terminar, acesse a página Gerenciamento de feeds para conferir um resumo detalhado de todos os tipos de registro configurados.

Excluir arquivos de origem

A opção de exclusão da fonte permite excluir objetos de origem do feed (arquivos e pastas) do armazenamento após uma transferência bem-sucedida. Essa opção está disponível apenas para alguns tipos de origem de feed, incluindo o Cloud Storage. Esses tipos de origem de feed incluem o campo OPÇÃO DE EXCLUSÃO DA ORIGEM nos fluxos de trabalho Adicionar novo e Editar feed.

Opções de exclusão de origem

  • Para tipos de origem de feed compatíveis, incluindo o Cloud Storage, o campo OPÇÃO DE EXCLUSÃO DA ORIGEM oferece estas opções:

    • Nunca excluir arquivos
    • Excluir arquivos transferidos e diretórios vazios
    • Excluir arquivos transferidos

  • O Armazenamento de Blobs do Microsoft Azure (AZURE_BLOBSTORE) não é compatível com a exclusão de arquivos de origem. No campo OPÇÃO DE EXCLUSÃO DA FONTE, selecione apenas a opção Nunca excluir arquivos.

  • Para as seguintes origens de feed ("feedSourceType"): GOOGLE_CLOUD_STORAGE_V2, GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN, AMAZON_S3_V2, AMAZON_SQS_V2 e AZURE_BLOBSTORE_V2, o campo OPÇÃO DE EXCLUSÃO DA ORIGEM oferece duas opções:

    • NUNCA: nunca exclui arquivos após as transferências.
    • ON_SUCCESS: exclui todos os arquivos e diretórios vazios após a transferência.

Filtrar objetos por prefixo em feeds do STS

O campo Incluir prefixos (include_prefixes) filtra os objetos de armazenamento transferidos pelo Serviço de transferência do Cloud Storage (STS) antes da ingestão com base em prefixos de chave de objeto. Os valores especificados nesse campo são transmitidos diretamente para o ObjectConditions.include_prefixes do STS.

Tipos de fontes de feed do STS compatíveis

A filtragem baseada em prefixo é compatível com os seguintes tipos de origem de feed do STS (feedSourceType):

  • Cloud Storage (V2) (GOOGLE_CLOUD_STORAGE_V2) e Cloud Storage orientado a eventos (GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN)
  • Amazon S3 (V2) (AMAZON_S3_V2) e Amazon SQS (V2) (AMAZON_SQS_V2)
  • Armazenamento de Blobs do Azure (V2) (AZURE_BLOBSTORE_V2) e Armazenamento de Blobs do Azure orientado por eventos (AZURE_BLOBSTORE_EVENT_DRIVEN)

Sintaxe do prefixo e regras de validação

Ao configurar Incluir prefixos (include_prefixes), siga estas regras de sintaxe e validação:

  • Sem barras iniciais: os prefixos são relativos à raiz do bucket ou do contêiner e não podem começar com uma barra inicial (/). Por exemplo, insira logs/audit/ em vez de /logs/audit/.
  • Barras finais versus correspondência parcial: as barras finais controlam se um prefixo corresponde apenas a objetos em uma pasta específica ou a qualquer chave de objeto que comece com o prefixo:
    • Com uma barra no final: um prefixo que termina com / (por exemplo, logs/app/) restringe as correspondências estritamente aos objetos dentro dessa pasta. Inclua uma barra final para o escopo no nível do diretório.
    • Sem uma barra final: um prefixo sem uma barra final / (por exemplo, logs/app) corresponde a qualquer objeto que comece com essa string, incluindo logs/app_old/ e logs/application/.
  • Diferenciação de maiúsculas de minúsculas: os prefixos de chave de objeto diferenciam maiúsculas de minúsculas.
  • Sem caracteres curinga ou expressões regulares: não há suporte para correspondência de padrões. Caracteres como * e ? são tratados como caracteres literais.
  • Sem valores vazios: as entradas de prefixo individuais não podem estar vazias ou conter apenas espaços em branco. Para ingerir todo o bucket ou contêiner, deixe o campo Incluir prefixos em branco.
  • Namespaces distintos e não sobrepostos: um prefixo não pode ser um prefixo de outro na mesma lista. Por exemplo, ["logs/", "logs/audit/"] é inválido, enquanto os prefixos irmãos, como ["logs/audit/", "logs/vpc/"], são válidos.
  • Limites: um feed aceita até 1.000 prefixos. Cada prefixo pode ter um tamanho máximo de 1.024 bytes quando codificado em UTF-8 e não pode conter caracteres de retorno de carro (\r) ou de nova linha (\n).

Configuração e permissões específicas da origem

Diferentes tipos de origem exigem configurações específicas de autenticação e rede para se comunicar com o Google SecOps. Nesta seção, descrevemos como configurar permissões e contas de serviço. A configuração descrita se concentra na ingestão do Cloud Storage (com base em pull), na ingestão multicloud (pull entre nuvens) e na ingestão com base em push (API ou em tempo real).

Exemplo de configuração de feed do Google Cloud Storage

  1. No menu do Google SecOps, selecione Configurações e clique em Feeds.
  2. Clique em Adicionar novo feed.
  3. Na página seguinte, clique em Configurar um único feed. Esta etapa não se aplica se você estiver usando a plataforma independente do Google SecOps SIEM.
  4. Selecione Cloud Storage v2 em Tipo de origem.
  5. Selecione o Tipo de registro. Por exemplo, para criar um feed para registros de auditoria do Google Kubernetes Engine, selecione Registros de auditoria do Google Kubernetes Engine como o Tipo de registro.
  6. Clique em Acessar conta de serviço. O Google SecOps fornece uma conta de serviço exclusiva que é usada para ingerir dados. Como alternativa, é possível conseguir essa conta de serviço de maneira programática usando a API. Consulte Buscar conta de serviço.
  7. Opcional: configure a conta de serviço. Para mais informações, consulte Conceder acesso à conta de serviço do Google SecOps.
  8. Clique em Próxima.

  9. Com base na configuração do Cloud Storage que você criou, especifique valores para os seguintes campos:

    • URI do bucket de armazenamento

    • Opção de exclusão da origem

    • Opcional: Incluir prefixos (opcional). No momento, ele está em visualização limitada. Para regras de sintaxe e detalhes da lista de permissões, consulte Filtrar objetos por prefixo em feeds do STS.

    Para saber como configurar buckets do Cloud Storage, consulte Criar buckets.

  10. Clique em Próximo e em Enviar.

Conceder acesso à conta de serviço do Google SecOps

  1. No console do Google Cloud , acesse a página Buckets do Cloud Storage.

    Acessar buckets

  2. Conceda acesso à conta de serviço aos objetos relevantes do Cloud Storage.

    • Para conceder permissão de leitura a um arquivo específico, siga estas etapas:

      1. Selecione o arquivo e clique em Acesso de edição.
      2. Clique em Adicionar principal.
      3. No campo Novos principais, insira o nome da conta de serviço do Google SecOps.
      4. Atribua um papel que contenha a permissão de leitura à conta de serviço do Google SecOps. Por exemplo, Leitor de objetos do Storage (roles/storage.objectViewer). Isso só poderá ser feito se você não tiver ativado o acesso uniforme no nível do bucket.
      5. Clique em Salvar.

    • Para conceder permissão de leitura a vários arquivos, conceda acesso no nível do bucket da seguinte maneira:

      • Para obter "feedSourceType": "GOOGLE_CLOUD_STORAGE":

        1. Adicione a conta de serviço do Google SecOps como principal ao bucket de armazenamento e conceda a ela o papel do IAM de Leitor de objetos do Storage (roles/storage.objectViewer).
        2. Se você configurar o feed para excluir arquivos de origem, adicione a conta de serviço do Google SecOps como principal no bucket e conceda a ela o papel do IAM de Administrador de objetos do Storage (roles/storage.objectAdmin).

      • Para "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2", conceda os seguintes papéis:

        1. Conceda este papel:

          • Leitor de objetos do Storage (roles/storage.objectViewer) se a transferência for para outro bucket do Cloud Storage.

        2. Conceda um dos seguintes papéis, dependendo do que você selecionar para a Opção de exclusão da origem. Se você selecionar Em caso de sucesso, conceda o papel Gravador de bucket legado do Storage. Se você selecionar Nunca, conceda o papel Leitor de bucket legado do Storage:

          • Gravador de bucket legado do Storage (roles/storage.legacyBucketWriter) se a permissão de exclusão de objetos for necessária.
          • Leitor de bucket legado do Storage (roles/storage.legacyBucketReader) se a permissão de exclusão de objetos não for necessária.

      • Para obter "feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN":

        1. Conceda um destes papéis:

          • Leitor de objetos do Storage (roles/storage.objectViewer) se a transferência for para outro bucket do Cloud Storage.
          • Criador de objetos do Storage (roles/storage.objectCreator) se a transferência for para um sistema de arquivos.

        2. Conceda um destes papéis:

          • Gravador de bucket legado do Storage (roles/storage.legacyBucketWriter) se a permissão de exclusão de objetos for necessária.
          • Leitor de bucket legado do Storage (roles/storage.legacyBucketReader) se a permissão de exclusão de objetos não for necessária.

Ativar o acesso do STS para o Amazon S3 e o Azure Storage

O STS é usado pelos seguintes feeds do Google Cloud Storage para transferir dados do Amazon S3 e dos armazenamentos de blobs do Azure Storage para o Google SecOps:

  • Amazon S3 (V2)
  • Amazon SQS (V2)
  • Armazenamento de blobs do Azure (V2)

O STS envia solicitações de transferência de dados para os serviços de armazenamento do Amazon S3 e do Azure de um conjunto de intervalos de endereços IP do STS definidos. Esses intervalos de endereços IP do STS são publicados no seguinte arquivo JSON: intervalos de IP.

Para usar esses tipos de origem de feed do STS, talvez seja necessário ajustar as restrições de acesso de IP para permitir que o STS acesse seus serviços de armazenamento do Amazon S3 e do Azure:

  1. Extraia os intervalos de IP mais recentes do arquivo JSON.

    Recomendamos que você leia os dados desse arquivo JSON pelo menos uma vez por semana para manter a configuração de segurança atualizada. Quando um novo intervalo é adicionado ao arquivo, o sistema aguarda pelo menos sete dias antes de usá-lo para solicitações do STS.

    Para ver um exemplo de script Python que busca intervalos de IP de um arquivo JSON, consulte Endereços IP para domínios padrão.

  2. Compare o intervalo de IP atual creationTime com o intervalo de IP creationTime lido do arquivo JSON anterior. Se forem diferentes, atualize as restrições de acesso de IP nos blobstores do Amazon S3 e do Armazenamento do Azure.

    • Para o Amazon S3

      Para atualizar as restrições de acesso de IP no repositório de blobs do Amazon S3:

      Se o projeto da AWS usar restrições de IP para acessar o armazenamento, será necessário adicionar os intervalos de IP usados pelos workers do STS à lista de IPs permitidos.

      Para adicionar esses intervalos como IPs permitidos, use o campo Condition em um bucket policy, conforme descrito na documentação do AWS S3: Como gerenciar o acesso com base em endereços IP específicos.

    • Para o Armazenamento do Azure

      Para atualizar as restrições de acesso de IP no repositório de blobs do Azure Storage:

      Se você restringir o acesso aos recursos do Azure usando um firewall do Azure Storage, adicione os intervalos de IP usados pelos workers do STS à lista de IPs permitidos.

      Para adicionar esses intervalos como IPs permitidos, siga estas instruções: Configurar firewalls e redes virtuais do Azure Storage.

Configurar um feed de push do Pub/Sub

Para configurar um feed de push do Pub/Sub, faça o seguinte:

  1. Criar um feed de push do Pub/Sub.
  2. Especifique o URL do endpoint em uma assinatura do Pub/Sub.

Criar um feed de push do Pub/Sub

  1. No menu do Google SecOps, selecione Configurações e clique em Feeds.
  2. Clique em Adicionar novo.
  3. No campo Nome do feed, insira um nome para o feed.
  4. Na lista Tipo de origem, selecione Push do Google Cloud Pub/Sub.
  5. Selecione o Tipo de registro. Por exemplo, para criar um feed para o Open Cybersecurity Schema Framework, selecione Open Cybersecurity Schema Framework (OCSF) como o Tipo de registro.
  6. Clique em Próxima.
  7. Opcional: especifique valores para os seguintes parâmetros de entrada:
    • Delimitador de divisão: o delimitador usado para separar as linhas de registro. Só é possível usar \n.
    • Namespace do recurso: o namespace do recurso.
    • Rótulos de ingestão: o rótulo a ser aplicado aos eventos desse feed.
  8. Clique em Próxima.
  9. Revise a configuração do novo feed na tela Finalizar e clique em Enviar.
  10. Na guia Detalhes, copie o URL do endpoint do feed no campo Informações do endpoint. Você precisa desse URL de endpoint para criar uma assinatura por push no Pub/Sub.
  11. Opcional: clique no botão Feed ativado para desativar o feed. O feed é ativado por padrão.
  12. Clique em Concluído.

Especificar o URL do endpoint

Depois de criar um feed de push do Pub/Sub, especifique o URL do endpoint da seguinte maneira:

  1. No Pub/Sub, crie uma assinatura por push. Para mais informações sobre como criar uma assinatura por push, consulte Criar assinaturas por push.
  2. Especifique o URL do endpoint, que está disponível no feed push do Pub/Sub do Google Cloud .
  3. Selecione Ativar autenticação e escolha uma conta de serviço.
  4. Desative as opções Desencapsulamento de payload por push e Desencapsulamento de payload por push de metadados das mensagens de gravação.

Configurar um feed do Amazon Data Firehose

Para configurar um feed do Amazon Data Firehose, faça o seguinte:

  1. Crie um feed do Amazon Data Firehose e copie o URL do endpoint e a chave secreta.
  2. Crie uma chave de API para autenticar no Google SecOps. Também é possível reutilizar sua chave de API para autenticação no Google SecOps.
  3. Especifique o URL do endpoint no Amazon Data Firehose.

Criar um feed do Amazon Data Firehose

  1. No menu do Google SecOps, selecione Configurações e clique em Feeds.
  2. Clique em Adicionar novo.
  3. No campo Nome do feed, insira um nome para o feed.
  4. Na lista Tipo de origem, selecione Amazon Data Firehose.
  5. Selecione o Tipo de registro. Por exemplo, para criar um feed para o Open Cybersecurity Schema Framework, selecione Open Cybersecurity Schema Framework (OCSF) como o Tipo de registro.
  6. Clique em Próxima.
  7. Opcional: especifique valores para os seguintes parâmetros de entrada:
    • Delimitador de divisão: o delimitador usado para separar as linhas de registro. Só é possível usar \n.
    • Namespace do recurso: o namespace do recurso.
    • Rótulos de ingestão: o rótulo a ser aplicado aos eventos desse feed.
  8. Clique em Próxima.
  9. Revise a configuração do novo feed de notícias na tela Finalizar e clique em Enviar.
  10. Clique em Gerar chave secreta para gerar uma chave secreta e autenticar esse feed.
  11. Copie e armazene a chave secreta, porque não será possível visualizá-la novamente. É possível gerar uma nova chave secreta, mas isso torna a chave secreta anterior obsoleta.
  12. Na guia Detalhes, copie o URL do endpoint do feed no campo Informações do endpoint. Você vai precisar desse URL de endpoint ao especificar as configurações de destino do stream de entrega no Amazon Data Firehose.
  13. Opcional: clique no botão Feed ativado para desativar o feed. O feed é ativado por padrão.
  14. Clique em Concluído.

Criar uma chave de API para o feed do Amazon Data Firehose

Para criar uma chave de API para o feed do Amazon Data Firehose, faça o seguinte:

  1. Acesse a página Credenciais do console do Google Cloud .
  2. Clique em Criar credenciais e selecione Chave de API.
  3. Restrinja o acesso da chave de API à API Chronicle.

Especificar o URL do endpoint

No Amazon Data Firehose, especifique o endpoint HTTPS e a chave de acesso da seguinte maneira:

  1. Anexe a chave de API ao URL do endpoint do feed e especifique esse URL como o URL do endpoint HTTP no seguinte formato:

      ENDPOINT_URL?key=API_KEY

    Substitua:

    • ENDPOINT_URL: o URL do endpoint do feed.
    • API_KEY: a chave de API para autenticação no Google SecOps.

  2. Para a chave de acesso, especifique a chave secreta que você recebeu ao criar o feed do Amazon Data Firehose.

Configurar um feed de webhook HTTPS

Antes de começar:

Para configurar um feed de webhook HTTPS, faça o seguinte:

  1. Crie um feed de webhook HTTPS e copie o URL do endpoint e a chave secreta.
  2. Crie uma chave de API especificada com o URL do endpoint. Também é possível reutilizar sua chave de API para autenticar no Google SecOps.
  3. Especifique o URL do endpoint no aplicativo.

Enviar vários eventos em uma única solicitação de webhook

O exemplo de código a seguir mostra como formatar um único corpo de solicitação com vários objetos JSON separados por nova linha após o item curl --location:

--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'

Criar um feed de webhook HTTPS

  1. No menu do Google SecOps, selecione Configurações e clique em Feeds.
  2. Clique em Adicionar novo.
  3. No campo Nome do feed, insira um nome para o feed.
  4. Na lista Tipo de origem, selecione Webhook.
  5. Selecione o Tipo de registro. Por exemplo, para criar um feed para o Open Cybersecurity Schema Framework, selecione Open Cybersecurity Schema Framework (OCSF) como o Tipo de registro.
  6. Clique em Próxima.
  7. Opcional: especifique valores para os seguintes parâmetros de entrada:
    • Delimitador de divisão: o delimitador usado para separar as linhas de registro. Só é possível usar \n.
    • Namespace do recurso: o namespace do recurso.
    • Rótulos de ingestão: o rótulo a ser aplicado aos eventos desse feed.
  8. Clique em Próxima.
  9. Revise a configuração do novo feed de notícias na tela Finalizar e clique em Enviar.
  10. Clique em Gerar chave secreta para gerar uma chave secreta e autenticar esse feed.
  11. Copie e armazene a chave secreta, porque não será possível visualizá-la novamente. É possível gerar uma nova chave secreta, mas isso torna a chave secreta anterior obsoleta.

  12. Na guia Detalhes, copie o URL do endpoint do feed no campo Informações do endpoint. É necessário especificar esse URL de endpoint no aplicativo cliente.

    Guia &quot;Detalhes&quot; do feed de webhook mostrando o campo &quot;Informações do endpoint&quot; com uma dica &quot;Copiar para a área de transferência&quot;.

    Figura 1. Informações do endpoint do feed do webhook

  13. Opcional: clique no botão Feed ativado para desativar o feed. O feed é ativado por padrão.

  14. Clique em Concluído.

Criar uma chave de API para o feed de webhook

  1. Acesse a página Credenciais do console do Google Cloud .
  2. Clique em Criar credenciais e, em seguida, selecione Chave de API.
  3. Restrinja o acesso da chave de API à API Chronicle.

Especificar o URL do endpoint

  1. No aplicativo cliente, especifique o endpoint HTTPS, que está disponível no feed do webhook.

  2. Ative a autenticação especificando a chave de API e a chave secreta como parte do cabeçalho personalizado no seguinte formato:

    X-goog-api-key = API_KEY

    X-Webhook-Access-Key = SECRET

    Recomendamos que você especifique a chave de API como um cabeçalho em vez de especificá-la no URL. Se o cliente do webhook não for compatível com cabeçalhos personalizados, especifique a chave de API e a chave secreta usando parâmetros de consulta no seguinte formato:

      ENDPOINT_URL?key=API_KEY&secret=SECRET

    Substitua:

    • ENDPOINT_URL: o URL do endpoint do feed.
    • API_KEY: a chave de API para autenticação no Google SecOps.
    • SECRET: a chave secreta que você gerou para autenticar o feed.

Configurar um feed de API personalizada

Os feeds de API personalizados do Google Security Operations (também conhecidos como conectores sem código) permitem ingerir telemetria de APIs REST de terceiros usando um modelo flexível baseado em configuração. É possível configurar extrações de dados definindo endpoints, autenticação, estratégias de paginação e gerenciamento de estado diretamente no console.

Principais vantagens

  • Acelere a integração: integre novas fontes de telemetria em minutos com um assistente guiado, sem esperar por atualizações de back-end.
  • Checkpoints com estado: garanta que não haja duplicação de dados nem registros ausentes nos ciclos de sondagem.
  • Fan-out pai-filho: oferece suporte a fluxos de trabalho de descoberta de dois níveis, como listar recursos e buscar a telemetria associada.
  • Resiliência automatizada e limitação de taxa: evita a limitação de fornecedores e o esgotamento de cotas. Para uma ingestão confiável e ininterrupta, o feed da API personalizada processa automaticamente as respostas HTTP 429 com uma espera exponencial, controla o ritmo das solicitações com limitação de taxa configurável e escalonamento de atraso de tarefas e aplica proteções de segurança. Para mais informações, consulte Limitação de taxa e proteções de limitação.

Pré-requisitos

Verifique os seguintes pré-requisitos antes de criar um feed de API personalizado:

  • Permissões:para criar ou modificar feeds, é necessário ter o papel de administrador da API Chronicle (roles/chronicle.admin) ou de editor da API Chronicle (roles/chronicle.editor).
  • Requisitos de APIs de terceiros:
    • Um URL de base de API válido (precisa usar https://).
    • Credenciais de API (chave de API, credenciais de autenticação básica ou ID/chave secreta do cliente OAuth 2.0).
    • Documentação da API do fornecedor detalhando caminhos de endpoint, parâmetros de solicitação, estruturas de resposta JSON e limitação de taxa.
  • Acesso ao Secret Manager:as credenciais são criptografadas e gerenciadas com segurança no Secret Manager. A identidade de serviço que executa o conector interage automaticamente com o Secret Manager (roles/secretmanager.secretAccessor e roles/secretmanager.admin).

Configurar um feed de API personalizada

Para configurar um feed de API personalizada, faça o seguinte:

  1. Acesse Configurações do SIEM > Feeds.
  2. Clique em Adicionar novo feed.
  3. Clique em Configurar um único feed.
  4. No campo Nome do feed, insira um nome descritivo exclusivo (por exemplo, 1Password-Audit-Events).
  5. Na lista Tipo de origem, selecione API personalizada.
  6. Na lista Tipo de registro, selecione o tipo de registro de destino do Google SecOps.
  7. Clique em Próxima.

  8. Em Configurações gerais, defina as seguintes configurações:

    • URL de base:insira o host principal (por exemplo, https://events.1password.com). Ele precisa começar com https://. Não anexe subcaminhos ou barras finais.

    • Frequência de sondagem:especifique a frequência com que a plataforma verifica a API em busca de novas telemetrias, em minutos. Intervalo aceito: de 5 a 2.880 minutos (padrão: 15 minutos). Para feeds da API padrão (sequencial), o padrão é de 10 a 15 minutos. Para feeds de lista e detalhes (pai-filho), recomendamos de 30 a 60 minutos para permitir a execução completa da tarefa de fan-out sem sobreposição.

  9. Em Autenticação, selecione um dos métodos de autenticação compatíveis e configure os campos obrigatórios:

    • Autenticação básica:insira o Nome de usuário (identidade da conta da API) e o Secret (ou seja, a senha ou o token secreto).
    • Credenciais do cliente OAuth 2.0:autentique usando o fluxo de concessão de credenciais do cliente OAuth 2.0. O Google SecOps solicita, armazena em cache e atualiza automaticamente os tokens de acesso do portador antes de cada ciclo de ingestão. Insira o endpoint do token OAuth (por exemplo, https://auth.vendor.com/oauth/token), o ID do cliente OAuth e a chave secreta do cliente OAuth.
    • Cabeçalhos da solicitação de chave de API:autentique usando chaves de API personalizadas injetadas nos cabeçalhos da solicitação (o padrão REST empresarial mais comum). Insira o Nome do cabeçalho (por exemplo, Authorization ou X-API-Key) e o Valor do cabeçalho (por exemplo, Bearer <SECRET_TOKEN> ou <SECRET_KEY>).
    • Parâmetros de consulta da chave de API:autentique usando chaves de API personalizadas injetadas nos parâmetros de consulta do URL. Insira o Nome do parâmetro de consulta (por exemplo, api_key) e o Valor do parâmetro de consulta (por exemplo, <SECRET_KEY>).

  10. Selecione o modelo de conector que sua API personalizada usa:

    • API padrão (sequencial): um fluxo de sondagem linear em que cada sondagem se baseia diretamente no estado da anterior. Nesse modelo, a próxima sondagem usa um cursor, token ou carimbo de data/hora extraído da sondagem anterior para buscar apenas dados novos. Selecione esse card quando o fornecedor oferecer um endpoint que retorna diretamente registros de eventos de telemetria (por exemplo, 1Password, Okta, SentinelOne, GitHub ou Slack).
    • Lista e detalhes (pai-filho): um fluxo de descoberta de dois níveis. O feed faz uma chamada inicial (pai) para recuperar uma lista de recursos ou objetos (por exemplo, uma lista de IDs de usuário ou zonas). Em seguida, o feed gera automaticamente chamadas de acompanhamento dependentes (filho) para buscar telemetria detalhada de cada recurso individual identificado. Selecione este card quando a API do fornecedor exigir um padrão de descoberta de dois níveis: primeiro, chamar um endpoint para buscar uma lista dinâmica de entidades (por exemplo, zonas, contas, projetos, dispositivos) e, em seguida, executar solicitações de detalhes de acompanhamento por entidade para recuperar a telemetria (por exemplo, Cloudflare, AWS CloudWatch ou Tenable).

  11. Se você selecionou API padrão (sequencial), faça o seguinte:

    1. Em endpoint de API, configure os seguintes parâmetros para definir a rota técnica e o ritmo de taxa da solicitação:
      • Caminho do endpoint:a rota de API específica anexada ao URL de base (por exemplo, /api/v1/auditevents). Isso define o recurso de telemetria exato a ser consultado.
      • Método HTTP:selecione GET para recuperar dados usando parâmetros de consulta de URL ou POST para enviar um payload de pesquisa ou corpo de filtro.
    2. Corpo da solicitação:para solicitações POST, forneça o payload de dados JSON. É possível incorporar variáveis de checkpoint dinâmicas, como {"limit": 100, "start_time": "{{.last_timestamp}}"}.
    3. Máximo de solicitações por minuto: insira o número máximo de solicitações a serem enviadas por minuto. Esse é um limitador de taxa do lado do cliente para obedecer aos limites de taxa da API do fornecedor (padrão: 5 RPM = 1 solicitação a cada 12 segundos). Essa configuração evita que a cota seja esgotada durante a paginação de várias páginas.
    4. Opcional: em Cabeçalhos personalizados, configure o Nome do cabeçalho e o Valor e clique em Adicionar para definir os cabeçalhos HTTP especializados exigidos pela API de destino (por exemplo, Content-Type: application/json, Accept: application/json).
    5. Opcional: em Parâmetros de consulta, configure a Chave e o Valor e clique em Adicionar para especificar filtros ou opções extras anexados à string de consulta do URL (por exemplo, count=1000, status=active) ou vincular variáveis de modelo dinâmicas (por exemplo, start={{.last_run_time}}).
    6. Em Estratégia de paginação:selecione o mecanismo de paginação que a API de terceiros exige para processar conjuntos de resultados de várias páginas e configure os campos obrigatórios:
      • Nenhum:busca dados em uma única solicitação sem paginação.
      • Paginação por token: use tokens (chaves personalizadas) para acessar a próxima página. Insira o Caminho JSON do token da próxima página (por exemplo, meta.next_cursor) e o Nome do parâmetro de consulta de paginação do token (por exemplo, cursor).
      • Paginação de links: siga os URLs fornecidos na resposta para receber mais dados. Insira o caminho JSON do link da próxima página (por exemplo, links.next ou @odata.nextLink).
      • Paginação de deslocamento: pule um número definido de registros para acessar o próximo conjunto. Insira o Nome do parâmetro de consulta de deslocamento (por exemplo, offset).
      • Paginação por número de página: acesse o próximo número de página sequencial. Insira o nome do parâmetro de consulta do número da página (por exemplo, page).

    7. Em Checkpointing, defina as configurações que permitem que o conector se lembre de onde parou entre os ciclos de sondagem recorrentes:

      • Estratégia: escolha uma das seguintes estratégias e configure os campos obrigatórios:
        • Nenhum:busca todos os dados disponíveis sem acompanhar o progresso entre os ciclos.
        • Carimbo de data/hora mais recente:rastreie o carimbo de data/hora do registro mais recente. Insira o Caminho JSON do valor do checkpoint (por exemplo, timestamp ou event_time) e a Variável do checkpoint (por exemplo, last_run_time, referenciada em sondagens subsequentes como {{.last_run_time}}).
        • Registro mais recente:rastreie o ID de registro mais alto para buscar apenas novos registros. Insira o caminho JSON do valor do checkpoint (por exemplo, id ou event_id) e a variável do checkpoint (por exemplo, last_id, referenciada como {{.last_id}}).
        • Token do iterador:use tokens de continuação persistentes fornecidos pela API. Insira o Caminho JSON do valor do checkpoint e a Variável do checkpoint (por exemplo, iterator_token, referenciada como {{.iterator_token}}).

    8. Em Mapeamento de resposta, forneça regras que informem à plataforma como localizar e extrair registros:

      • Caminho JSON dos dados de destino: insira o caminho exato no payload de resposta da API em que a lista de entradas de registro de destino está localizada. Para matrizes encapsuladas em objetos (por exemplo, {"items": [...]}), insira items. Para APIs que retornam uma matriz JSON raiz diretamente (por exemplo, [{...}, {...}]), deixe esse campo completamente vazio ([]).

  12. Se você selecionou Lista e detalhes (pai-filho), faça o seguinte:

    1. Solicitação principal (descoberta): configure o endpoint que retorna uma lista de itens:
      1. Em endpoint de API, configure os seguintes parâmetros para definir a rota técnica e o ritmo de taxa da solicitação:
        • Caminho do endpoint:a rota de API específica anexada ao URL de base (por exemplo, /api/v1/auditevents). Isso define o recurso de telemetria exato a ser consultado.
        • Método HTTP:selecione GET para recuperar dados usando parâmetros de consulta de URL ou POST para enviar um payload de pesquisa ou corpo de filtro.
        • Corpo da solicitação:para solicitações POST, forneça o payload de dados JSON. É possível incorporar variáveis de checkpoint dinâmicas, como {"limit": 100, "start_time": "{{.last_timestamp}}"}.
      2. Máximo de solicitações por minuto: insira o número máximo de solicitações a serem enviadas por minuto. Esse é um limitador de taxa do lado do cliente para obedecer aos limites de taxa da API do fornecedor (padrão: 5 RPM = 1 solicitação a cada 12 segundos). Essa configuração evita que a cota seja esgotada durante a paginação de várias páginas.
      3. Opcional: em Cabeçalhos personalizados, configure o Nome do cabeçalho e o Valor e clique em Adicionar para definir os cabeçalhos HTTP especializados exigidos pela API de destino (por exemplo, Content-Type: application/json, Accept: application/json).
      4. Opcional: em Parâmetros de consulta, configure a Chave e o Valor e clique em Adicionar para especificar filtros ou opções extras anexados à string de consulta do URL (por exemplo, count=1000, status=active) ou vincular variáveis de modelo dinâmicas (por exemplo, start={{.last_run_time}}).
      5. Em Estratégia de paginação:selecione o mecanismo de paginação que a API de terceiros exige para processar conjuntos de resultados de várias páginas e configure os campos obrigatórios:
        • Nenhum:busca dados em uma única solicitação sem paginação.
        • Paginação por token: use tokens (chaves personalizadas) para acessar a próxima página. Insira o Caminho JSON do token da próxima página (por exemplo, meta.next_cursor) e o Nome do parâmetro de consulta de paginação do token (por exemplo, cursor).
        • Paginação de links: siga os URLs fornecidos na resposta para receber mais dados. Insira o caminho JSON do link da próxima página (por exemplo, links.next ou @odata.nextLink).
        • Paginação de deslocamento: pule um número definido de registros para acessar o próximo conjunto. Insira o Nome do parâmetro de consulta de deslocamento (por exemplo, offset).
        • Paginação por número de página: acesse o próximo número de página sequencial. Insira o nome do parâmetro de consulta do número da página (por exemplo, page).
      6. Em Checkpointing, defina as configurações que permitem que o conector se lembre de onde parou entre os ciclos de sondagem recorrentes:
        • Estratégia: escolha uma das seguintes estratégias e configure os campos obrigatórios:
          • Nenhum:busca todos os dados disponíveis sem acompanhar o progresso entre os ciclos.
          • Carimbo de data/hora mais recente:rastreie o carimbo de data/hora do registro mais recente. Insira o Caminho JSON do valor do checkpoint (por exemplo, timestamp ou event_time) e a Variável do checkpoint (por exemplo, last_run_time, referenciada em sondagens subsequentes como {{.last_run_time}}).
          • Registro mais recente:rastreie o ID de registro mais alto para buscar apenas novos registros. Insira o caminho JSON do valor do checkpoint (por exemplo, id ou event_id) e a variável do checkpoint (por exemplo, last_id, referenciada como {{.last_id}}).
          • Token do iterador:use tokens de continuação persistentes fornecidos pela API. Insira o Caminho JSON do valor do checkpoint e a Variável do checkpoint (por exemplo, iterator_token, referenciada como {{.iterator_token}}).
    2. Extração de dados (a ponte): configure o seguinte:
      • Caminho JSON do identificador do item: o campo específico na resposta pai que identifica de forma exclusiva uma entidade individual (por exemplo, id ou zone_id). O conector extrai esse identificador de cada item na matriz pai.
      • Nome da variável de modelo:especifique um nome de variável personalizada para armazenar o ID extraído (por exemplo, zone_id). A interface mostra um selo dinâmico: Use {{.zone_id}} na solicitação filha abaixo.
    3. Solicitação filha (detalhe): configure o endpoint que retorna registros detalhados para cada item:
      1. Em endpoint de API, configure os seguintes parâmetros para definir a rota técnica e o ritmo de taxa da solicitação:
        • Caminho do endpoint:a rota de API específica anexada ao URL de base (por exemplo, /client/v4/zones/{{.zone_id}}/logs/received). Isso define o recurso de telemetria exato a ser consultado.
        • Método HTTP:selecione GET para recuperar dados usando parâmetros de consulta de URL ou POST para enviar um payload de pesquisa ou corpo de filtro.
        • Corpo da solicitação:para solicitações POST, forneça o payload de dados JSON. É possível incorporar variáveis de checkpoint dinâmicas, como {"limit": 100, "start_time": "{{.last_timestamp}}"}.
      2. Máximo de solicitações por minuto: insira o número máximo de solicitações a serem enviadas por minuto. Esse é um limitador de taxa do lado do cliente para obedecer aos limites de taxa da API do fornecedor (padrão: 5 RPM = 1 solicitação a cada 12 segundos). Essa configuração evita que a cota seja esgotada durante a paginação de várias páginas.
      3. Opcional: em Cabeçalhos personalizados, configure o Nome do cabeçalho e o Valor e clique em Adicionar para definir os cabeçalhos HTTP especializados exigidos pela API de destino (por exemplo, Content-Type: application/json, Accept: application/json).
      4. Opcional: em Parâmetros de consulta, configure a Chave e o Valor e clique em Adicionar para especificar filtros ou opções extras anexados à string de consulta do URL (por exemplo, count=1000, status=active) ou vincular variáveis de modelo dinâmicas (por exemplo, start={{.last_run_time}}).
      5. Em Estratégia de paginação:selecione o mecanismo de paginação que a API de terceiros exige para processar conjuntos de resultados de várias páginas e configure os campos obrigatórios:
        • Nenhum:busca dados em uma única solicitação sem paginação.
        • Paginação por token: use tokens (chaves personalizadas) para acessar a próxima página. Insira o Caminho JSON do token da próxima página (por exemplo, meta.next_cursor) e o Nome do parâmetro de consulta de paginação do token (por exemplo, cursor).
        • Paginação de links: siga os URLs fornecidos na resposta para receber mais dados. Insira o caminho JSON do link da próxima página (por exemplo, links.next ou @odata.nextLink).
        • Paginação de deslocamento: pule um número definido de registros para acessar o próximo conjunto. Insira o Nome do parâmetro de consulta de deslocamento (por exemplo, offset).
        • Paginação por número de página: acesse o próximo número de página sequencial. Insira o nome do parâmetro de consulta do número da página (por exemplo, page).
      6. Em Checkpointing, defina as configurações que permitem que o conector se lembre de onde parou entre os ciclos de sondagem recorrentes:
        • Estratégia: escolha uma das seguintes estratégias e configure os campos obrigatórios:
          • Nenhum:busca todos os dados disponíveis sem acompanhar o progresso entre os ciclos.
          • Carimbo de data/hora mais recente:rastreie o carimbo de data/hora do registro mais recente. Insira o Caminho JSON do valor do checkpoint (por exemplo, timestamp ou event_time) e a Variável do checkpoint (por exemplo, last_run_time, referenciada em sondagens subsequentes como {{.last_run_time}}).

  13. Defina as seguintes configurações de Programação e rótulos:

    • Frequência de sondagem:selecione um intervalo padrão (por exemplo, 5m, 1h).
    • Namespace:tag organizacional opcional.
    • Rótulos de ingestão:pares de chave-valor para RBAC de dados.

  14. Clique em Enviar. O Google SecOps realiza uma verificação automatizada de credenciais e endpoints. Se a validação for bem-sucedida, o feed vai começar a ser consultado.

Exemplo de configuração 1: eventos de auditoria do 1Password (modelo de API padrão (sequencial))

A configuração JSON declarativa a seguir demonstra um modelo de API padrão (sequencial), com checkpoint baseado em cursor para o 1Password:

{
  "base_url": "https://events.1password.com",
  "polling_frequency": 15,
  "header_auth": {
    "header_key_values": [
      {
        "key": "Authorization",
        "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
      }
    ]
  },
  "primary_request": {
    "request_settings": {
      "endpoint_path": "/api/v1/auditevents",
      "http_method": "POST",
      
      "request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
      
      "custom_headers": [
        {
          "key": "Content-Type",
          "value": "application/json"
        }
      ],
      "max_requests_per_minute": 5
    },
    "pagination_strategy": {
      "token": {
        "next_page_token_json_path": "additional_items_url",
        "query_param": "cursor"
      }
    },
    "checkpointing": {
      "latest_timestamp_strategy": {
        "checkpoint_value_path": "timestamp",
        "checkpoint_variable": "last_run_time"
      }
    },
    "response_mapping": {
      "target_data_path": ["items"]
    }
  }
}

Exemplo de configuração concreta 2: telemetria de zona do Cloudflare (modelo de lista e detalhes (pai-filho))

A configuração JSON declarativa a seguir demonstra um modelo de fan-out de lista e detalhes (pai-filho) para o Cloudflare:

{
 "base_url": "https://api.cloudflare.com",
 "polling_frequency": 30,
 "header_auth": {
   "header_key_values": [
     {
       "key": "Authorization",
       "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
     }
   ]
 },

 "primary_request": {
   "request_settings": {
     "endpoint_path": "/client/v4/zones",
     "http_method": "GET"
   },
   "response_mapping": {
     "target_data_path": ["result"]
   },
   "pagination_strategy": {
     "none": {}
   },
   "checkpointing": {
     "none_strategy": {}
   },
   "dependent_requests_config": {
     "item_id_json_path": "id",
     "item_id_variable": "zone_id",
     "dependent_requests": [
       {
         "request_settings": {
           "endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
           "http_method": "GET",
           "query_parameters": [
             {
               "key": "start",
               "value": "{{.last_run_time}}"
             },
             {
               "key": "count",
               "value": "1000"
             }
           ],
           "max_requests_per_minute": 5
         },

         "pagination_strategy": {
           "none": {}
         },
         "checkpointing": {
           "latest_timestamp_strategy": {
             "checkpoint_value_path": "EdgeStartTimestamp",
             "checkpoint_variable": "last_run_time"
           }
         },
         "response_mapping": {
           "target_data_path": []
         }
       }
     ]
   }
 }
}

Práticas recomendadas para APIs personalizadas

  • Orientações sobre a frequência de sondagem:
    • Comece com intervalos de sondagem moderados: defina o intervalo de sondagem inicial como 15 ou 30 minutos para endpoints de alto volume para observar o comportamento da cota da API do fornecedor antes de reduzir para 5 minutos.
    • Otimizar para fan-out de alto volume: para feeds pai-filho (lista e detalhes) que descobrem dezenas ou centenas de recursos, o Google recomenda definir a Frequência de sondagem como 30 a 60 minutos para permitir que todas as tarefas filhas sejam concluídas sem problemas antes do início do próximo ciclo de descoberta.
  • Validar caminhos de ingestão: use a documentação do fornecedor ou as ferramentas de teste de API para confirmar o nome exato do campo JSON para carimbos de data/hora antes de configurar o checkpoint de estado.
  • Decompor APIs com vários filhos: se uma API de terceiros exigir a busca de alertas e registros de auditoria para uma única lista de usuários, crie dois feeds separados com um único filho (um para alertas e outro para registros de auditoria) para manter o isolamento ideal.

Limitação de taxa e de limitação de solicitações

Para evitar que as configurações de feed do cliente sobrecarreguem as cotas de fornecedores terceirizados ou monopolizem os recursos do sistema, o tipo de feed da API personalizada implementa as seguintes proteções automatizadas:

  • Ritmo de solicitação configurável (limitação de taxa): as solicitações HTTP de saída são ritmadas automaticamente para evitar que os limites de taxa do fornecedor sejam excedidos. A taxa de ritmo padrão é de 5 solicitações por minuto (1 solicitação a cada 12 segundos). É possível ajustar isso por endpoint usando o campo Máximo de solicitações por minuto nas configurações do endpoint para corresponder às cotas de API publicadas do seu fornecedor.
  • Limite de solicitações filhas:para feeds pai-filho (lista e detalhes), uma solicitação de descoberta pode enviar até 500 solicitações filhas por ciclo de sondagem.
  • Profundidade de fan-out de nível único:o conector aplica estritamente uma profundidade máxima de fan-out de 1 nível (descoberta de pai → detalhes do filho). Solicitações dependentes aninhadas (chamadas de netos) não são compatíveis.
  • Limite de tamanho do payload de resposta:o tamanho máximo permitido de resposta HTTP para qualquer solicitação ou página é de 50 MB. Se uma API não paginada retornar uma resposta que exceda 50 MB, a busca vai falhar com um erro de recurso esgotado. Para evitar isso, sempre configure os parâmetros de consulta de paginação (como limit ou page_size) para recuperar registros em lotes menores.
  • Retirada automática do HTTP 429: se uma resposta da API de fornecedor terceirizado responder com HTTP 429 (solicitações em excesso), o Google SecOps vai capturar automaticamente o status e iniciar um período de retirada exponencial, pausando a execução da tarefa até que a janela de cota do fornecedor seja preenchida novamente.

Limitações da API personalizada

Ao planejar seus caminhos de ingestão, observe que o tipo de feed da API personalizada tem as seguintes limitações:

  • Suporte estrito a JSON:apenas respostas da API JSON são aceitas. Outros formatos, como XML, CSV, Parquet e Avro, não são compatíveis.
  • Sem assinatura de solicitação dinâmica: as APIs que exigem assinaturas criptográficas dinâmicas por solicitação não são compatíveis (por exemplo, AWS SigV4, Akamai ou Oracle OCI).
  • Sem autenticação em várias etapas:APIs que exigem uma chamada de login programática inicial para trocar credenciais por um token de sessão temporário (como o Saviynt) antes da sondagem não são compatíveis.
  • Sem ingestão de WebSockets ou push:os feeds de API personalizados são compatíveis com a sondagem de pull HTTPS padrão. Não há suporte para conexões de streaming persistentes (WebSockets) e webhooks de entrada.
  • Sem TLS mútuo (mTLS): a autenticação precisa usar chaves de API, autenticação básica ou credenciais de cliente OAuth 2.0 padrão. Não há suporte para handshakes de certificado do lado do cliente.

Resolver problemas com feeds de API personalizados

Para investigar erros de feeds da API personalizada na Análise de Registros do Cloud Logging, use as seguintes consultas:

resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"

Substitua FEED_ID pelo ID do seu feed.

Para filtrar especificamente as solicitações HTTP com falha, use a seguinte consulta:

jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400

Substitua FEED_ID pelo ID do seu feed.

Modos de falha comuns e soluções

Sintoma / Erro Causa raiz Solução / Correção
HTTP 401 Não autorizado / HTTP 403 Proibido Chave de API, senha ou credenciais OAuth expiradas ou inválidas. Edite o feed, insira credenciais válidas novamente e clique em Enviar.
HTTP 404 Não encontrado Modelo de URL de base ou caminho de endpoint incorreto. Inspecione o endpoint na documentação da API do fornecedor. Verifique se o URL de base termina de forma limpa e se o caminho do endpoint começa com /.
HTTP 429: número excessivo de solicitações Os limites de taxa da API do fornecedor foram excedidos. Aumente a frequência de sondagem ou reduza o parâmetro limit nos parâmetros de consulta.
Erro de extração de JSON (items_path vazio) Incompatibilidade no caminho de configuração da resposta. Verifique a estrutura do payload de resposta da API e atualize o caminho JSON dos dados de destino.
Ingestão de dados duplicados Carimbo de data/hora de configuração de estado ou caminho do extrator de ID inválido. Verifique o nome do campo do registro de registro para o carimbo de data/hora e atualize o caminho do extrator.

Gerenciar feeds

Depois de configurar os feeds de dados, use as Ferramentas de gestão para monitorar a integridade da ingestão, modificar os parâmetros atuais e gerenciar o ciclo de vida do feed. Nesta seção, descrevemos como interpretar os status dos feeds e realizar tarefas de manutenção essenciais para garantir a visibilidade contínua dos dados.

A página Feeds oferece várias ferramentas para ajudar você a navegar e organizar sua lista de feeds configurados:

  • Pesquisa: use a barra de pesquisa para encontrar um feed pelo Nome, ID ou Tipo de origem.

  • Filtrar: clique no ícone de filtro para restringir a lista com base em atributos de feed específicos.

  • Baixar CSV: clique em Baixar como CSV para exportar a lista atual de feeds para um arquivo CSV.

  • Paginação: use os controles de paginação para:

    • Mude o número de Linhas por página.

    • Navegue por várias páginas de feeds usando as guias e setas.

  • Horário da última atualização: confira o carimbo de data/hora para saber quando a lista de feeds foi atualizada pela última vez.

Ver feeds configurados

A página Feeds mostra todos os feeds que você configurou.

  1. Acesse Configurações do SIEM > Feeds. A página principal mostra todos os feeds configurados.
  2. Mantenha o ponteiro sobre cada linha para exibir o menu Mais more_vert .
  3. No menu, é possível conferir os detalhes do feed, editar, desativar ou excluir o feed.

Monitorar o status do feed

É possível monitorar o status do feed na página inicial Feeds, em que os feeds podem ter os seguintes status:

  • Ativo: o feed está configurado e pronto para ingerir dados na sua conta do Google SecOps.

  • InProgress: o Google SecOps tenta extrair dados do terceiro configurado.

  • Concluído: os dados foram recuperados por esse feed.

  • Arquivado: feed desativado.

  • Falha: o feed não está conseguindo buscar dados. Isso provavelmente aconteceu devido a um problema de configuração. Clique na pergunta para mostrar o erro de configuração. Depois de corrigir o erro e reenviar o feed, volte para a página Feeds para determinar se ele está funcionando.

Editar feeds

Na página Feeds, é possível editar um feed atual da seguinte maneira:

  1. Mantenha o ponteiro sobre um feed e clique em more_vert na coluna à direita.

  2. Clique em Editar feed. Agora é possível modificar os parâmetros de entrada do feed e enviá-lo novamente ao Google SecOps, que vai tentar usar o feed atualizado.

Ativar (retomar) e desativar (pausar) feeds

Quando você desativa um feed, o Google SecOps para de ingerir novos dados dessa fonte. Para interromper a ingestão de dados imediatamente, exclua o feed. As transferências ativas ou limitadas continuam até serem concluídas. Quando você reativar o feed, o Google SecOps poderá recuperar os dados que foram perdidos enquanto o feed estava desativado. Esse recurso é chamado de "capacidade de preenchimento".

Na coluna Status, os feeds ativados são rotulados como Ativo, Em andamento, Concluído ou Com falha. Os campos desativados são rotulados como Arquivados. Para uma descrição, consulte Monitorar o status do feed.

Na página Feeds, é possível ativar (retomar) ou desativar (pausar) qualquer um dos feeds:

  1. Mantenha o ponteiro sobre um feed e clique em more_vert na coluna à direita.

  2. Opcional: clique no botão Feed ativado para ativar o feed.

  3. Opcional: clique no botão Desativar feed para desativar o feed. O feed agora está marcado como Arquivado.

Recuperação de dados ao reativar feeds (preenchimento retroativo)

A capacidade do Google SecOps de preencher dados depende se o feed é baseado em pull (compatível) ou push (não compatível).

Feeds baseados em pull

Com esses feeds, o Google SecOps extrai dados de fontes externas. Os feeds de pull incluem:

  • Buckets de armazenamento em nuvem, como Amazon S3, Google Cloud Storage, Azure Blob Storage
  • Servidores SFTP

  • APIs de terceiros, como Microsoft 365, Okta, Proofpoint

    Quando você reativa os feeds baseados em pull, o Google SecOps pode recuperar os dados gerados enquanto o feed estava desativado.

Feeds baseados em push

Com esses feeds, os sistemas externos "enviam" dados para o Google SecOps. Os feeds push incluem:

  • Webhooks HTTPS
  • Google Cloud Pub/Sub
  • Amazon Kinesis Data Firehose
  • Ingestões diretas de API/agente, como o Bindplane

O Google SecOps não pode iniciar automaticamente o preenchimento de dados de feeds baseados em push. Enquanto o feed estiver desativado e seu sistema enviar dados, o Google SecOps vai enviar um erro HTTP 403 Forbidden ou um erro 4xx genérico.

Se o sistema não armazenar e tentar reenviar os dados para o Google SecOps, eles serão perdidos. Além disso, se o sistema estiver configurado para "descartar em caso de falha" ou limpar o buffer, os dados serão perdidos permanentemente no período em questão. Para evitar a perda de dados, configure seu sistema para armazenar em buffer e reenviar dados quando um feed for reativado. O Google SecOps pode ingerir os dados perdidos quando o feed for retomado.

Considerações sobre preenchimento

  • Limites do sistema de origem:a quantidade de dados históricos que o Google SecOps pode preencher de feeds baseados em pull é limitada pelo tempo que o sistema de origem mantém os dados e pelo que a API permite. Por exemplo, algumas APIs só fornecem acesso aos dados dos últimos sete dias.
  • Buffer do Google SecOps:para recuperação automatizada, o buffer interno do Google SecOps para feeds baseados em pull armazena dados por até 90 dias. Depois disso, os dados são descartados.
  • Restrições de locatário: locatários não pagantes, como provas de conceito, podem ter limitações no preenchimento de dados mais antigos.
  • Cotas de ingestão: para evitar impactos na ingestão de dados em tempo real, os dados de preenchimento são processados com uma prioridade menor do que os dados em tempo real. O preenchimento de dados baseado em pull também tem limitação de taxa, normalmente de um terço (33%) do limite de burst do locatário por tipo de registro. Isso garante que os feeds críticos baseados em push, como agentes de EDR, não sejam afetados negativamente.
  • Limitação de taxa dinâmica: se o preenchimento consumir toda a cota de pull disponível, a ingestão será pausada pelo restante do intervalo de cinco minutos e retomada automaticamente quando o intervalo for reiniciado.
  • Armazenamento em nuvem:use as configurações do feed para controlar o preenchimento, como filtros para arquivos novos ou atualizados, ou filtros de período, como "Idade máxima do arquivo".
  • Grande acúmulo de dados:se um grande acúmulo de dados de um feed baseado em pull causar problemas ao ser reativado, entre em contato com o Suporte do Google para limpar o acúmulo. Isso significa que o feed vai começar a ingerir apenas novos dados, e os dados perdidos não serão preenchidos.
  • Editar feeds desativados: as mudanças de configuração feitas em um feed enquanto ele está desativado serão aplicadas assim que ele for reativado.

Excluir feeds

Na página Feeds, também é possível excluir um feed:

  1. Mantenha o ponteiro sobre um feed e clique em more_vert na coluna à direita.

  2. Clique em Excluir feed. A janela EXCLUIR FEED é aberta. Para excluir o feed permanentemente, clique em Sim, excluir.

Para feeds de API personalizada, uma janela de diálogo aparece com uma caixa de seleção opcional: Excluir dados pendentes do backlog:

  • Desmarcada (padrão): a configuração e as credenciais do feed são excluídas, mas os dados em fila são processados até a ingestão.
  • Marcada:a configuração do feed, as credenciais e todos os dados pendentes do backlog são removidos permanentemente.

Controlar a taxa de ingestão

Quando a taxa de ingestão de dados de um locatário atinge um determinado limite, o Google Security Operations restringe a taxa de ingestão de novos feeds de dados para evitar que uma fonte com uma alta taxa de ingestão afete a taxa de ingestão de outra fonte de dados. Nesse caso, há um atraso, mas nenhum dado é perdido. O volume de ingestão e o histórico de uso do locatário determinam o limite.

Para solicitar um aumento do limite de taxa, entre em contato com o Cloud Customer Care.

Resolver problemas de feeds com falha

  • Na página Feeds, é possível ver detalhes como tipo de origem, tipo de registro, ID do feed e status dos feeds, da seguinte maneira:

    1. Mantenha o ponteiro sobre um feed e clique em more_vert na coluna à direita.

    2. Clique em Ver feed. Uma caixa de diálogo vai aparecer mostrando os detalhes do feed. Para um feed com falha, você pode encontrar detalhes do erro em Detalhes > Status.

  • Para um feed com falha, os detalhes incluem a causa do erro e as etapas para corrigi-lo.

  • Consulte a tabela Erros de origem e ingestão para ver as mensagens de erro que podem aparecer ao trabalhar com feeds de dados.

  • Para uma análise detalhada e solução de problemas da atividade do feed, consulte os registros no Cloud Logging. Consulte Analisar a atividade do feed com o Cloud Logging.

  • Erro Generic::failed_precondition:

    Erro: Generic::failed_precondition: include_prefixes is not enabled for this customer

    Esse erro ocorre quando você salva um feed do STS com valores no campo Incluir prefixos (include_prefixes), mas seu locatário do Google SecOps não está na lista de permissões para filtragem baseada em prefixo.

    Para resolver esse erro, siga um destes procedimentos:

    1. Remova todos os prefixos do campo Incluir prefixos (include_prefixes) e salve o feed novamente para ingerir todo o bucket ou contêiner.
    2. Entre em contato com sua equipe de conta do Google Cloud , seu gerente técnico de contas (TAM) ou o Cloud Customer Care para solicitar acesso ao recurso include_prefixes (enable_feed_include_prefixes) para seu locatário. Para mais informações, consulte Filtrar objetos por prefixo em feeds do STS.

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.