Trabalhar com a UI dos feeds

Compatível com:

Google SecOps SIEM

Neste documento, explicamos como criar, solucionar problemas e gerenciar feeds na interface do usuário do 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 compatíveis

Os formatos de compactação aceitos para 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 minutos	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 (sem compactação)
Descompactar arquivos	CEP	-	Varia de acordo com o número de arquivos	4 GB (sem compactação)

Limites e delimitadores de linhas de registro

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

• 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: são aceitos os caracteres de nova linha (\n) e retorno de carro + nova linha (\r\n).

Observação: para tipos de registros com alta densidade de dados, verifique se a origem do registro não está agrupando vários eventos em uma única linha que excede o limite de 4 MB. Se você encontrar erros de tamanho, talvez seja necessário ajustar a configuração de geração de registros de origem para garantir que as entradas individuais sejam delimitadas corretamente.

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

Se você estiver atualizando o projeto Google Cloud associado à sua instância do Google SecOps, todos os feeds que ingerem dados usando os seguintes conectores 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 imediatamente de extrair dados ativos 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 uma mensagem informando: 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 a interrupção:

1. Recriar feeds: é necessário criar novos feeds para substituir os que existiam antes da migração.
2. Configurar a idade máxima do arquivo: ao configurar seus novos feeds, defina a idade máxima do arquivo para cerca de duas 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, talvez haja transferência de dados duplicados. Para detalhes técnicos sobre como o Google SecOps filtra esses registros redundantes, consulte Evitar a remoção de duplicação.

   Observação: isso não se aplica a feeds em que a opção Excluir após a transferência está ativada.

4. Registre e exclua os feeds atuais (antes da migração): antes de iniciar a migração BYOP, registre as configurações de todos os feeds 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 vão ficar difíceis de gerenciar 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)

Observação: se você estiver usando a plataforma independente do SIEM, não terá acesso ao Hub de conteúdo. Entre em contato com seu representante do Google SecOps para fazer upgrade.

Configurar seus feeds

Nesta seção, descrevemos como configurar seus feeds em geral, começando com o fluxo processual 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

Atenção: a partir de 15 de abril de 2026, a estrutura do conector v1 para Cloud Storage, Amazon S3, Amazon SQS e Armazenamento de Blobs do Azure será descontinuada. Recomendamos usar a estrutura do conector v2, que usa oGoogle Cloud Serviço de transferência do Cloud Storage (STS) para ingestão quase em tempo real. Para mais informações, consulte Fazer upgrade dos feeds de dados do Cloud Storage para a estrutura do conector v2 e Descontinuações de recursos.

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 próxima página, clique em Configurar um único feed. Observação: essa 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 fonte 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)
   • Impulsionado por eventos do Cloud Storage
   • 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 permissões do Google SecOps 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.
   • Usar o 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 fonte selecionado anteriormente.

   Observação: para o tipo de registro AWS CLOUDTRAIL, verifique se os registros estão no formato JSON e se o nome do arquivo é um arquivo JSON (não compactado) ou um arquivo JSON GZipped (compactado).

   Se você selecionar Cloud Storage como o tipo de origem, use a opção Receber conta de serviço para ter uma conta de serviço exclusiva. Consulte 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 sobre o ícone de ponto de interrogação em cada campo para receber mais informações sobre o que você precisa fornecer.

9. Opcional: você pode 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 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, e o Google SecOps vai tentar buscar os 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 registros de referência: marcados como recomendados. Esses tipos de registros são recomendados para a funcionalidade principal da plataforma.
• Tipos de registros complementares: marcados como opcionais. Esses tipos de registros 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, no CrowdStrike Falcon, é possível criar vários feeds exclusivos nos tipos de registros recomendados e opcionais para garantir uma cobertura de dados abrangente.

Configurar o feed para o EDR do CrowdStrike

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

1. Em Configurações > Feeds, clique em Adicionar novo feed
   1. Clique no produto CrowdStrike Falcon:
   2. Selecione o tipo de registro EDR do CrowdStrike.
2. Ou, 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 EDR do CrowdStrike.

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 do SQS de leitura.
   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 do feed.
   • Namespace do recurso: namespace associado ao feed.
   • Rótulos de ingestão: rótulos aplicados aos eventos deste feed.

5. Clique em Criar feed.

Repita esse processo para criar outros feeds do mesmo tipo de registro. Também é possível configurar feeds para outros tipos de registros 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 registros configurados.

Lista de permissões de IP

Ative a lista de permissões e adicione os intervalos de IP do Google para todos os tipos de registros que ingerem dados de APIs de terceiros.

Observação: a lista de permissões de IP é compatível apenas com tipos de feed específicos: S3_V2, SQS_V2, Azure_Blobstore_V2, S3, SQS, Azure_Blobstore e Hub de eventos do Azure. Os feeds de push HTTPS não exigem uma lista de permissão de IP porque são baseados em push. O Google SecOps não pode garantir que todos os feeds serão originados exclusivamente de endereços IP de acordo com uma região especificada.

Excluir arquivos de origem

Com a opção de exclusão da fonte, é possível 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 fontes de feed, incluindo o Cloud Storage. Esses tipos de origem de feed incluem o campo OPÇÃO DE EXCLUSÃO DE ORIGEM nos fluxos de trabalho Adicionar novo e Editar feed.

Observação: ao configurar o campo OPÇÃO DE EXCLUSÃO DA ORIGEM, se você selecionar uma opção para excluir objetos de origem, ative as permissões de exclusão necessárias para esse tipo de feed. Para informações sobre permissões, consulte Configuração por tipo de origem.

Opções de exclusão de fonte

• Para tipos de fontes de feed compatíveis, incluindo o Cloud Storage, o campo OPÇÃO DE EXCLUSÃO DA FONTE 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 oferece suporte à 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 fontes 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 FONTE 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.

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

Diferentes tipos de fontes 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 (baseada em pull), na ingestão multicloud (pull entre nuvens) e na ingestão baseada em push (API ou em tempo real).

Observação: se você usa o VPC Service Controls, consulte Configurar o VPC Service Controls para o Google SecOps para mais informações.

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

Observação: se você usa a política da organização Compartilhamento restrito de domínio no Google Cloud, adicione o ID do cliente do Google SecOps C02h8e9nw à lista de permissões.

1. No menu do Google SecOps, selecione Configurações e clique em Feeds.
2. Clique em Adicionar novo feed.
3. Na próxima página, 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 para Tipo de origem.
5. Selecione o Tipo de registro. Por exemplo, para criar um feed de registros de auditoria do Google Kubernetes Engine, selecione Registros de auditoria do Google Kubernetes Engine como o Tipo de registro.
6. Clique em Receber conta de serviço. O Google SecOps fornece uma conta de serviço exclusiva que ele usa para ingerir dados. Também é possível receber 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 criada, especifique valores para os seguintes campos:

   • URI do bucket de armazenamento

     Observação: use um caractere curinga para corresponder a um nome de diretório inteiro. Por exemplo, gs://cs-myprod/*/more-data é válido (em que * substitui o nome inteiro de um único nível de diretório).
     Observação: para tipos de feed orientados a eventos do Cloud Storage, configure uma assinatura do Pub/Sub para o Cloud Storage, conforme descrito em Configurar o Pub/Sub.

   • Opção de exclusão da origem

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

   Observação: os feeds de bucket do Cloud Storage não funcionam com nomes de pastas vazios.

10. Clique em Próxima 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ó pode 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 um principal ao seu 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 um principal no bucket e conceda a ela o papel do IAM 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 do 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 ao STS para Amazon S3 e Azure Storage

O STS é usado pelos seguintes feeds do Google Cloud Storage para transferir dados do Amazon S3 e dos repositórios 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 definidos do STS. Esses intervalos de endereços IP da 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 por 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 ler 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 uma amostra 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 creationTime lido do arquivo JSON anterior. Se forem diferentes, atualize as restrições de acesso por IP no Amazon S3 e nos repositórios de blobs do Azure Storage.

   • Para o Amazon S3

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

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

     Observação :se você estiver usando agentes em vez de uma transferência sem agente, adicione os endereços IP da sua máquina de agente à 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 Azure Storage

     Para atualizar as restrições de acesso por 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. Crie um feed de push do Pub/Sub.
2. Especifique o URL do endpoint em uma assinatura do Pub/Sub.

Observação: o feed de push do Pub/Sub precisa estar no seu projeto Google Cloud vinculado ao Google SecOps para que a assinatura seja autenticada. Ele usa um token JWT da sua conta de serviço para autenticação. Para mais detalhes, consulte Autenticação para assinaturas push.

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 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 deste feed.
8. Clique em Próxima.
9. Revise a nova configuração do 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.

Especifique 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 de push do Pub/Sub 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.

Observação: se você precisar enviar registros de outro projeto Google Cloud que não esteja vinculado ao Google SecOps, como de uma conta serviço gerenciado pelo usuário, configure um coletor de registros. Para mais informações sobre coletores de registros, consulte Rotear registros para destinos compatíveis.

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 atual para fazer a 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 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 deste feed.
8. Clique em Próxima.
9. Revise a nova configuração do feed na tela Finalizar e clique em Enviar.
10. Clique em Gerar chave secreta para autenticar o feed.
11. Copie e armazene a chave secreta, porque não será possível conferir esse secret novamente. Você pode gerar uma nova chave secreta, mas a regeneração torna a anterior obsoleta.
12. Na guia Detalhes, copie o URL do endpoint do feed no campo Informações do endpoint. Você precisa desse URL de endpoint ao especificar as configurações de destino do seu fluxo 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 Google Cloud .
2. Clique em Criar credenciais e selecione Chave de API.
3. Restrinja o acesso da chave de API à API Chronicle.

Especifique o URL do endpoint

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

1. Adicione 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 autenticar 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:

• Verifique se um Google Cloud projeto do Google SecOps está configurado e se a API Chronicle está ativada para o projeto.

• Vincule uma instância do Google SecOps aos serviços do Google Cloud .

  Observação: os lotes de dados enviados por feeds de webhook podem sofrer atrasos na ingestão se o tamanho da solicitação ou os limites de QPS forem definidos como muito baixos. O endpoint de push HTTPS aceita um tamanho máximo de solicitação de 4 MB por solicitação e uma capacidade de processamento máxima de 15 K QPS por instância do Google SecOps.

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. Você também pode reutilizar sua chave de API atual para autenticar no Google SecOps.
3. Especifique o URL do endpoint no seu 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 novas linhas 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 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 deste feed.
8. Clique em Próxima.
9. Revise a nova configuração do feed na tela Finalizar e clique em Enviar.
10. Clique em Gerar chave secreta para autenticar o feed.
11. Copie e armazene a chave secreta, porque não será possível conferir esse secret novamente. Você pode gerar uma nova chave secreta, mas a regeneração torna a 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.
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 Google Cloud .
2. Clique em Criar credenciais e, em seguida, selecione Chave de API.
3. Restrinja o acesso da chave de API à API Chronicle.

Especifique 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 de webhook não aceitar 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 autenticar no Google SecOps.
   • SECRET: a chave secreta gerada para autenticar o feed.

Configurar um feed de API personalizada

Observação: esse recurso é coberto pelos Termos de produtos pré-GA dos Termos específicos de serviço do Google Security Operations. Os recursos pré-GA podem ter suporte limitado, e as mudanças realizadas podem não ser compatíveis com outras versões pré-GA. Para mais informações, consulte as diretrizes do serviço de suporte técnico do Google SecOps e os Termos específicos de serviço do Google SecOps.
Se esse recurso não estiver visível no seu ambiente, consulte Gerenciar recursos de prévia ou entre em contato com o administrador do sistema.

Observação:esse recurso não está disponível para todos os clientes em todas as regiões.

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.
• Checkpointing com estado: garante que não haja duplicação de dados nem registros ausentes em todos os ciclos de polling.
• Fan-out de pai-filho:oferece suporte a fluxos de trabalho de descoberta de duas camadas, como listar recursos e buscar a telemetria associada.
• Resiliência e limitação de taxa automatizadas: evita a limitação do fornecedor e o esgotamento da cota. Para uma ingestão confiável e ininterrupta, o feed da API personalizada processa automaticamente as respostas HTTP 429 com uma espera exponencial, limita as 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 restrições de controle de limitação.

Pré-requisitos

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

• Permissões:para criar ou modificar feeds, você precisa ter a função de administrador da API Chronicle (roles/chronicle.admin) ou editor da API Chronicle (roles/chronicle.editor).
• Requisitos de API de terceiros:
  • Um URL base de API válido (precisa usar https://).
  • Credenciais da 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 limites 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, configure o seguinte:

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

   • Frequência de polling: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), recomenda-se de 30 a 60 minutos para permitir a execução completa da tarefa de distribuição de dados sem sobreposição.

9. Em Autenticação, selecione um dos métodos 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 de autenticação 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 de solicitação de chave de API:autentique usando chaves de API personalizadas injetadas em cabeçalhos de 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 em parâmetros de consulta de 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>).
   Observação: todas as credenciais inseridas aqui são mascaradas automaticamente durante a entrada e criptografadas com segurança no Secret Manager, com suporte opcional para chaves de criptografia gerenciadas pelo cliente (CMEK).

10. Selecione o modelo de conector usado pela sua API personalizada:

    • API padrão (sequencial): um fluxo de pesquisa linear em que cada pesquisa se baseia diretamente no estado da anterior. Nesse modelo, a próxima pesquisa usa um cursor, token ou carimbo de data/hora extraído da pesquisa anterior para buscar apenas dados novos. Selecione esse card quando o fornecedor disponibilizar um endpoint que retorne 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 (principal) para recuperar uma lista de recursos ou objetos (por exemplo, uma lista de IDs de usuários ou zonas). Em seguida, o feed gera automaticamente chamadas de acompanhamento dependentes (filhas) para buscar telemetria detalhada de cada recurso identificado. Selecione este card quando a API do fornecedor exigir um padrão de descoberta de duas camadas: primeiro, chame um endpoint para buscar uma lista dinâmica de entidades (por exemplo, zonas, contas, projetos, dispositivos) e, em seguida, execute solicitações de detalhes de acompanhamento por entidade para recuperar telemetria (por exemplo, Cloudflare, AWS CloudWatch ou Tenable).
    Observação: os dois modelos usam checkpointing, um processo de gerenciamento de estado que extrai e armazena o carimbo de data/hora ou ID mais alto de uma pesquisa para retomar a ingestão no próximo ciclo sem perder registros ou criar dados duplicados.

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 a limitação 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 dinâmicas de checkpoint, 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. É 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 o esgotamento da cota durante a paginação em várias páginas.
    4. Opcional: em Cabeçalhos personalizados, configure o Nome do cabeçalho e o Valor. Em seguida, clique em Adicionar para definir 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âmico (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 por deslocamento:pule um número definido de registros para receber 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:vá para 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, configure as configurações que permitem que o conector se lembre de onde parou entre os ciclos de polling recorrentes:

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

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

       • Caminho JSON dos dados de destino:insira o caminho exato no payload da 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 a limitação 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 dinâmicas de checkpoint, 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. É 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 o esgotamento da cota durante a paginação em várias páginas.
       3. Opcional: em Cabeçalhos personalizados, configure o Nome do cabeçalho e o Valor. Em seguida, clique em Adicionar para definir 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âmico (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 por deslocamento:pule um número definido de registros para receber 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:vá para 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, configure as configurações que permitem que o conector se lembre de onde parou entre os ciclos de polling recorrentes:
          • Estratégia:escolha uma das seguintes estratégias e configure os campos obrigatórios:
            • Nenhum:busca todos os dados disponíveis sem rastrear o progresso nos ciclos.
            • Carimbo de data/hora mais recente:rastreie o carimbo de data/hora do registro mais novo. Insira o Caminho JSON do valor do ponto de verificação (por exemplo, timestamp ou event_time) e a Variável do ponto de verificação (por exemplo, last_run_time, referenciada em pesquisas subsequentes como {{.last_run_time}}).
            • Registro mais recente:rastreie o ID de registro mais alto para buscar apenas registros novos. Insira o Caminho JSON do valor do ponto de verificação (por exemplo, id ou event_id) e a Variável do ponto de verificação (por exemplo, last_id, referenciada como {{.last_id}}).
            • Token de iterador:use tokens de continuação persistentes fornecidos pela API. Insira o Caminho JSON do valor do ponto de verificação e a Variável do ponto de verificação (por exemplo, iterator_token, referenciado 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 principal que identifica exclusivamente uma entidade individual (por exemplo, id ou zone_id). O conector extrai esse identificador de cada item na matriz principal.
       • Nome da variável de modelo:especifique um nome de variável personalizado para armazenar o ID extraído (por exemplo, zone_id). A interface mostra um selo dinâmico: Use {{.zone_id}} na solicitação secundária 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 a limitação 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 dinâmicas de checkpoint, 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. É 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 o esgotamento da cota durante a paginação em várias páginas.
       3. Opcional: em Cabeçalhos personalizados, configure o Nome do cabeçalho e o Valor. Em seguida, clique em Adicionar para definir 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âmico (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 por deslocamento:pule um número definido de registros para receber 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:vá para 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, configure as configurações que permitem que o conector se lembre de onde parou entre os ciclos de polling recorrentes:
          • Estratégia:escolha uma das seguintes estratégias e configure os campos obrigatórios:
            • Nenhum:busca todos os dados disponíveis sem rastrear o progresso nos ciclos.
            • Carimbo de data/hora mais recente:rastreie o carimbo de data/hora do registro mais novo. Insira o Caminho JSON do valor do ponto de verificação (por exemplo, timestamp ou event_time) e a Variável do ponto de verificação (por exemplo, last_run_time, referenciada em pesquisas subsequentes como {{.last_run_time}}).

13. Configure as seguintes opções em Programação e rótulos:

    • Frequência de polling: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 validação de credenciais e endpoints. Se a validação for bem-sucedida, o feed vai começar a fazer pesquisas.

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 checkpointing 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 concreto de configuração 2: telemetria de zona do Cloudflare (modelo de lista e detalhes [pai-filho])

A configuração JSON declarativa a seguir demonstra um modelo de distribuição de dados 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ção sobre a frequência de sondagem:
  • Comece com intervalos de pesquisa moderados: defina o intervalo inicial como 15 ou 30 minutos para endpoints de alto volume e observe o comportamento da cota da API do fornecedor antes de reduzir para 5 minutos.
  • Otimize para distribuição de dados 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 controladas sejam concluídas corretamente antes do início do próximo ciclo de descoberta.
• Validar caminhos de ingestão: use a documentação do fornecedor ou ferramentas de teste de API para confirmar o nome exato do campo JSON para carimbos de data/hora antes de configurar a criação de pontos de verificação de estado.
• Decomponha 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.

Medidas de segurança de limitação de taxa e limitação

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:

• Limitação de taxa de solicitações configurável: as solicitações HTTP de saída são automaticamente limitadas para evitar o excesso de limites de taxa do fornecedor. A taxa de espaçamento 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 pelo fornecedor.
• Limite de solicitações secundárias:para feeds principal-secundário (lista e detalhes), uma solicitação de descoberta pode enviar até 500 solicitações secundárias por ciclo de pesquisa.
• Profundidade de distribuição de dados de nível único:o conector impõe estritamente uma profundidade máxima de distribuição de dados de um nível (descoberta de pai → detalhes do filho). Não é possível usar solicitações dependentes aninhadas (chamadas de netos).
• Limite máximo do 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 sem paginação retornar uma resposta maior que 50 MB, a busca vai falhar com um erro de recurso esgotado. Para evitar isso, sempre configure parâmetros de consulta de paginação (como limit ou page_size) para recuperar registros em lotes menores.
• Redução automática de HTTP 429:se uma API de fornecedor terceirizado responder com HTTP 429 (muitas solicitações), o Google SecOps vai capturar automaticamente o status e iniciar um período de redução 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 os 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:não há suporte para APIs que exigem assinaturas criptográficas dinâmicas por solicitação (por exemplo, AWS SigV4, Akamai ou Oracle OCI).
• Sem autenticação em várias etapas:não há suporte para 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 pesquisa.
• Sem WebSockets ou ingestão por push:os feeds de API personalizados são compatíveis com a pesquisa de pull HTTPS padrão. Conexões de streaming persistentes (WebSockets) e webhooks recebidos são indisponíveis.
• 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 personalizados da API

Para investigar erros de feeds de API personalizados 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 feed.

Para filtrar especificamente 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 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 novamente as credenciais válidas e clique em Enviar.
HTTP 404 Não encontrado	URL base ou modelo de caminho do endpoint incorreto.	Inspecione o endpoint na documentação da API do fornecedor. Verifique se o URL de base termina corretamente e se o caminho do endpoint começa com /.
HTTP 429 Há muitas solicitações	Os limites de taxa da API do fornecedor foram excedidos.	Aumente a frequência de polling ou reduza o parâmetro limit nos parâmetros de consulta.
Erro de extração 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 de registro de eventos 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 gerenciamento para monitorar a integridade da ingestão, modificar parâmetros e gerenciar o ciclo de vida do feed. Nesta seção, descrevemos como interpretar os status dos feeds e realizar tarefas essenciais de manutenção 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:

• Pesquisar: use a barra de pesquisa para encontrar um feed pelo nome, ID ou tipo de fonte.

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

• Fazer o download do CSV: clique em Fazer o download 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.

• Ú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 mostrar o menu Mais more_vert .
3. No menu, é possível conferir os detalhes, editar, desativar ou excluir o feed.

Monitorar o status do feed

Monitore o status do feed na página inicial Feeds, em que eles 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ída: os dados foram recuperados com sucesso por este 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 à página Feeds para determinar se ele está funcionando.

  Observação: a coluna Última atualização na página Feeds mostra a última vez que os dados foram buscados com sucesso por esse feed. Para um feed novo, esse campo fica em branco. Feeds de push, como Webhook e Google Cloud pubsub, não preenchem essa coluna. Esses feeds por push não têm uma programação, ou seja, os dados chegam quando são enviados. Para feeds do Amazon SQS (V2), a coluna Última atualização em representa o carimbo de data/hora do sinal de funcionamento da ingestão ativa. As atualizações nessa coluna são limitadas e podem ter um atraso de até 15 minutos.

Editar feeds atuais

Na página Feeds, é possível editar um feed existente 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 reenviá-lo ao Google SecOps, que vai tentar usar o feed atualizado.

   Observação: os feeds atuais mostram [Não configurado] como nome na página Feeds. Edite o feed para adicionar um nome.

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 atuais vão continuar até serem concluídas. Quando você reativa o feed, o Google SecOps pode recuperar os dados que foram perdidos enquanto ele 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 Falha. Os campos desativados são marcados 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 (capacidade de preenchimento)

A capacidade do Google SecOps de fazer o backfill de dados depende de o feed ser baseado em pull (compatível) ou push (indisponível).

Feeds baseados em pull

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

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

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

  Quando você reativa os feeds baseados em pull, o Google SecOps pode recuperar 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 por 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 está desativado e seu sistema envia dados, o Google SecOps envia 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 respectivo período. Para evitar a perda de dados, configure seu sistema para armazenar em buffer e reenviar dados assim que um feed for reativado. O Google SecOps pode ingerir os dados perdidos quando o feed é 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 retém 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 o impacto na ingestão de dados em tempo real, os dados de backfill são processados com uma prioridade menor do que os dados ativos. O preenchimento de dados com base em pull também tem uma taxa limitada, geralmente a um terço (33%) do limite de burst do seu locatário por tipo de registro. Isso garante que feeds críticos baseados em push, como agentes de EDR, não sejam afetados negativamente.
• Limitação limitação de taxa:se o backfill consumir toda a cota de extração disponível, a ingestão será pausada pelo restante do intervalo de cinco minutos e será retomada automaticamente quando o intervalo for reiniciado.
• Armazenamento em nuvem:use as configurações de feed para controlar o backfill, como filtros para arquivos novos ou atualizados ou filtros de período, como "Idade máxima do arquivo".
• Backlogs grandes:se um backlog grande de um feed baseado em pull causar problemas ao ser reativado, entre em contato com o Suporte do Google para limpar o backlog. Isso significa que o feed vai começar a ingerir apenas dados novos a partir de agora, e os dados perdidos não serão preenchidos.
• Edição de feeds desativados:todas 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, você também pode 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.

   Observação: quando você exclui um feed, nenhum dado novo é ingerido. Pode haver dados já na fila que ainda serão processados.

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

• Desmarcada (padrão): a configuração e as credenciais do feed são excluídas, mas os dados de backlog na fila podem ser 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 taxa de ingestão alta 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.

Você pode solicitar um aumento do limite de taxa entrando em contato com o Cloud Customer Care.

Resolver problemas de feeds com falha

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

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 aparece mostrando os detalhes do feed. Para um feed com falha, encontre os detalhes do erro em Detalhes > Status.

Para um feed com falha, os detalhes incluem a causa do erro e as etapas para corrigir o problema.

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.

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