Implantar recursos de monitoramento e telemetria de rede no Google Cloud

Last reviewed 2024-02-13 UTC

A telemetria de rede coleta dados de tráfego de dispositivos da sua rede para que possam ser analisados. A telemetria de rede permite que as equipes de operações de segurança detectem ameaças baseadas em rede e procurem invasores avançados, o que é essencial para as operações de segurança autônomas. Para conseguir a telemetria de rede, você precisa capturar e armazenar dados de rede. Neste blueprint, descrevemos como usar o Espelhamento de pacotes e o Zeek para capturar dados de rede no Google Cloud.

Ele é destinado a analistas de segurança e administradores de rede que querem espelhar o tráfego de rede, armazenar esses dados e encaminhá-los para análise. Neste blueprint, pressupomos que você tenha conhecimento prático de rede e monitoramento de rede.

Ele faz parte de um blueprint de segurança composto pelos seguintes:

  • Um repositório do GitHub que contém um conjunto de configurações e scripts do Terraform.
  • Um guia para os controles de arquitetura, design e segurança que você implementa com o blueprint (este documento).

Usando esse blueprint, você captura pacotes de rede (incluindo metadados de rede) usando o espelhamento de pacotes, transforma os pacotes de rede em registros do Zeek e os armazena no Cloud Logging. O blueprint extrai metadados, como endereços IP, portas, protocolos e solicitações e cabeçalhos da Camada 7. Armazenar metadados de rede como registros do Zeek usa menos volume de dados do que armazenar dados de pacote brutos e, portanto, é mais econômico.

Neste documento, pressupomos que você já tenha configurado um conjunto básico de controles de segurança, conforme descrito no guia de fundações empresariais do Google Cloud.

Casos de uso compatíveis

Esse blueprint é compatível com os seguintes casos de uso:

  • A central de operações de segurança (SOC, na sigla em inglês) requer acesso aos dados de registro de rede do Google Cloud em um local centralizado para que possam investigar incidentes de segurança. Esse blueprint converte dados de pacotes de rede em registros que podem ser encaminhados para suas ferramentas de análise e investigação. As ferramentas de análise e investigação incluem BigQuery, Chronicle, Flowmon, ExtraHop ou informações e gerenciamento de eventos (SIEM, na sigla em inglês).
  • Suas equipes de segurança precisam de visibilidade nas redes do Google Cloud para executar a busca de ameaças usando ferramentas como o Chronicle. É possível usar esse blueprint para criar um pipeline de tráfego de rede do Google Cloud.
  • Você quer demonstrar como sua organização atende aos requisitos de conformidade para detecção e resposta de rede. Por exemplo, sua organização precisa demonstrar conformidade com o Memorando M-21-31 do Escritório de Gerenciamento e Orçamento (OMB, na sigla em inglês) dos Estados Unidos.
  • Os analistas de segurança de rede exigem dados de registro de rede a longo prazo. Esse blueprint é compatível com monitoramento de longo prazo e monitoramento sob demanda.

Se você também precisar de dados de captura de pacotes (pcap), precisará usar ferramentas de análise de protocolo de rede (por exemplo, Wireshark ou tcpdump). O uso de ferramentas de análise de protocolo de rede não está no escopo desse blueprint.

Não é possível implantar esse blueprint com o Sistema de detecção de intrusões na nuvem. Tanto esta solução quanto o Sistema de detecção de intrusões do Cloud usam políticas de espelhamento de pacotes, que podem ser usadas apenas por um serviço por vez.

Custos

Esse modelo pode afetar seus custos porque você está adicionando recursos de computação e armazenando quantidades significativas de dados no Cloud Logging. Considere o seguinte ao implantar o blueprint:

  • Cada máquina virtual (VM) do coletor no Compute Engine é executada como uma instância e2-medium.
  • Você pode controlar os custos de armazenamento com o seguinte:
    • Usando filtros de Espelhamento de pacotes.
    • Não espelhando entre zonas para evitar cobranças de saída entre zonas.
    • Armazenando dados somente pelo tempo exigido pela organização.

Use a calculadora de preços para ter uma estimativa dos seus custos de computação, geração de registros e armazenamento.

Arquitetura

O diagrama de arquitetura a seguir mostra a infraestrutura usada para implementar o blueprint:

A arquitetura de telemetria de rede.

A arquitetura mostrada na imagem anterior usa uma combinação dos seguintes serviços e recursos do Google Cloud:

  • Duas redes de nuvem privada virtual (VPC, na sigla em inglês):

    • Uma rede de nuvem privada virtual para as origens espelhadas.
    • Uma rede VPC para as instâncias do coletor.

    Essas redes VPC precisam estar no mesmo projeto.

  • Compute Engine ou Google Kubernetes Engine (GKE) instâncias (chamadas de origens espelhadas) em particular regiões e sub-redes que são a origem dos pacotes de rede. Identifique quais instâncias para espelhar origens usando um dos seguintes métodos:

    • Tags de rede
    • Nomes de instâncias do Compute
    • Nome da sub-rede

  • Instâncias do Compute Engine que funcionam como instâncias do coletor por trás de um balanceador de carga de rede de passagem interno, na mesma região das origens espelhadas. Essas instâncias executam o Zeek-Fluentd Golden Image ou sua imagem personalizada zeek-fluentd. As VMs são e2-medium e a capacidade de processamento suportada é 4 Gbps.

  • Um balanceador de carga de rede de passagem interno que recebe pacotes das origens espelhadas e as encaminha para as instâncias do coletor para processamento. A regra de encaminhamento para o balanceador de carga usa a sinalização --is-mirroring-collector.

  • Regras de firewall da VPC que permitem:

    • Saída de origens espelhadas para o balanceador de carga de rede de passagem interna.
    • Entrada das instâncias do coletor para as instâncias espelhadas.

  • Uma política de espelhamento de pacotes que define a região, a sub-rede, as instâncias espelhadas, os protocolos, a direção e a regra de encaminhamento. Cada região requer uma política de espelhamento de pacotes própria.

  • Peering de rede VPC para permitir conectividade usando endereços IP internos entre VMs altamente disponíveis do Compute Engine em várias regiões. O Peering de redes VPC permite que as origens espelhadas se comuniquem com o balanceador de carga de rede de passagem interno.

  • Uma instância do Cloud Logging que coleta todos os pacotes para armazenamento e recuperação por meio de uma ferramenta de análise e investigação.

Entenda os controles de segurança necessários

Nesta seção, discutiremos os controles de segurança do Google Cloud que podem ser usados para ajudar a proteger os diferentes componentes da arquitetura de monitoramento de rede.

Controles de segurança de rede VPC

Você cria redes VPC em torno das origens espelhadas e dos coletores. Ao criar a rede VPC para os coletores, você exclui a rota padrão gerada pelo sistema, o que significa que todas as rotas padrão do gateway da Internet estão desativadas. A desativação dos gateways padrão da Internet ajuda a reduzir a superfície de ataque à rede contra invasores de ameaças externas.

Crie sub-redes na rede VPC para cada região. Com as sub-redes, é possível controlar o fluxo do tráfego entre as cargas de trabalho no Google Cloud e também de origens externas. As sub-redes têm o Acesso privado do Google ativado. O Acesso privado do Google também ajuda a reduzir a superfície de ataque da rede, além de permitir que as VMs se comuniquem com as APIs e os serviços do Google.

Para permitir a comunicação entre as redes VPC, ative o peering de rede VPC. O peering de rede VPC usa rotas de sub-rede para conectividade de endereço IP interno. Importe e exporte rotas personalizadas para permitir uma conexão direta entre as origens espelhadas e os coletores. É necessário restringir toda a comunicação a rotas regionais porque o balanceador de carga de rede de passagem interno dos coletores não é compatível com rotas globais.

Regras de firewall

Use regras de firewall para definir as conexões que as origens espelhadas e os coletores podem fazer. Configure uma regra de entrada para permitir verificações de integridade normais de tempo de atividade, uma regra de saída para todos os protocolos nas origens espelhadas e uma regra de entrada para todos os protocolos na coletores.

Controles de segurança da VM do coletor

As VMs do coletor são responsáveis por receber os dados do pacote. As VMs de coletor são VMs idênticas que operam como grupos de instâncias gerenciadas (MIGs). Você ativa as verificações de integridade para permitir a recriação automática de uma VM não responsiva. Além disso, você permite que os coletores façam escalonamento automático com base nos seus requisitos de uso.

Cada VM de coletor executa a imagem do pacote zeek-fluentd. Esta imagem consiste em Zeek, que gera os registros, e em Fluentd, que encaminha os registros para o Cloud Logging. Depois de implantar o módulo do Terraform, é possível atualizar os pacotes de SO da VM e Zeek e aplicar os controles de segurança necessários para sua organização.

Controles de segurança internos do balanceador de carga

O balanceador de carga de rede de passagem interno direciona o tráfego de pacote de rede das origens espelhadas para as VMs do coletor para processamento. Todas as VMs do coletor precisam ser executadas na mesma região do balanceador de carga de rede de passagem interna.

A regra de encaminhamento do balanceador de carga de rede de passagem interno define que o acesso é possível de todas as portas, mas o acesso global não é permitido. Além disso, a regra de encaminhamento define esse balanceador de carga como um coletor de espelhamento, usando a sinalização --is-mirroring-collector.

Você não precisa configurar um balanceador de carga para armazenamento, já que cada VM de coletor faz upload direto de registros no Cloud Logging.

Espelhamento de pacote

O espelhamento de pacotes requer que você identifique as instâncias que quer espelhar. Você pode identificar as instâncias que quer espelhar usando tags de rede, nomes de instâncias ou a sub-rede em que as instâncias estão localizadas. Além disso, é possível filtrar ainda mais o tráfego usando um ou mais dos seguintes itens:

  • Protocolos de camada 4, como TCP, UDP ou ICMP.
  • Intervalos CIDR IPv4 nos cabeçalhos IP, como 10.0.0.0/8.
  • Direção do tráfego que você quer espelhar, como entrada, saída ou ambos.

Contas de serviço e controles de acesso

As contas de serviço são identidades que o Google Cloud pode usar para executar solicitações de API em seu nome. As contas de serviço garantem que as identidades dos usuários não tenham acesso direto aos serviços.

Para implantar o código do Terraform, é preciso personificar uma conta de serviço que tenha os seguintes papéis no projeto:

As VMs do coletor também exigem essa conta de serviço para que possam se autenticar nos serviços do Google Cloud, receber os pacotes de rede e encaminhá-los para o Cloud Logging.

Práticas de retenção de dados

Especifique por quanto tempo o Cloud Logging armazena seus registros de rede usando regras de retenção para os buckets de registros. Para determinar por quanto tempo armazenar os dados, revise os requisitos regulamentares da sua organização.

Geração de registros e auditoria

Use o Cloud Monitoring para analisar o desempenho das VMs do coletor e configurar alertas para verificações de tempo de atividade e condições de desempenho, como carga da CPU.

É possível acompanhar o acesso ou as alterações do administrador aos dados e à configuração usando os registros de auditoria do Cloud. A geração de registros de auditoria é compatível com o Compute Engine, o Cloud Load Balancing e o Cloud Logging.

É possível exportar informações de monitoramento da seguinte forma:

Resumo geral

Para implementar a arquitetura descrita neste documento, faça o seguinte:

  1. Implante um valor de referência seguro no Google Cloud, conforme descrito no Blueprint de bases empresariais do Google Cloud. Se você optar por não implantar o blueprint de bases empresariais, verifique se o ambiente tem uma linha de base de segurança semelhante.
  2. Leia o arquivo Readme do blueprint e verifique se você atende a todos os pré-requisitos.

  3. No ambiente de teste, implante uma das configurações de telemetria de rede de exemplo para ver o blueprint em ação. Como parte do processo de teste, faça o seguinte:

    1. Verifique se as políticas e as sub-redes de espelhamento de pacotes foram criadas.

    2. Verifique se você tem o papel Visualizador de registros (roles/logging.viewer) e execute um comando curl para visualizar seus dados de registro. Exemplo:

      curl http://example.com/

      Você verá que os dados de registro estão armazenados no Cloud Logging.

    3. Use o Security Command Center para verificar os projetos recém-criados de acordo com seus requisitos de conformidade.

    4. Verifique se o sistema está capturando e armazenando os pacotes de rede adequados e ajuste o desempenho conforme necessário.

  4. Implante o blueprint no ambiente de produção.

  5. Conecte o Cloud Logging ao SIEM ou ao Chronicle para que seus analistas de segurança de SOC e de rede possam incorporar a nova telemetria nos painéis.

A seguir