Déployer des fonctionnalités de surveillance et de télémétrie réseau dans Google Cloud

Last reviewed 2024-02-13 UTC

La télémétrie réseau collecte les données de trafic réseau provenant des appareils de votre réseau afin que les données puissent être analysées. La télémétrie réseau permet aux équipes chargées des opérations de sécurité de détecter les menaces basées sur le réseau et de traquer les pirates informatiques de haut niveau, ce qui est essentiel pour les opérations de sécurité autonomes. Pour obtenir une télémétrie réseau, vous devez capturer et stocker les données réseau. Ce plan explique comment utiliser la mise en miroir de paquets et Zeek pour capturer des données réseau dans Google Cloud.

Ce plan est destiné aux analystes de sécurité et aux administrateurs réseau qui souhaitent mettre en miroir le trafic réseau, stocker ces données et les transférer pour analyse. Dans ce plan, nous partons du principe que vous maîtrisez les bases concernant les réseaux et la surveillance réseau.

Ce plan fait partie d'un plan de sécurité composé des éléments suivants :

  • Un dépôt GitHub contenant un ensemble de configurations et de scripts Terraform.
  • Un guide des contrôles d'architecture, de conception et de sécurité que vous mettez en œuvre avec le plan (ce document).

Avec ce plan, vous capturez des paquets réseau (y compris les métadonnées réseau) à l'aide de la mise en miroir de paquets, vous transformez les paquets réseau en journaux Zeek, puis vous les stockez dans Cloud Logging. Le plan extrait les métadonnées, telles que les adresses IP, les ports, les protocoles, ainsi que les en-têtes et requêtes de couche 7. Le stockage des métadonnées réseau sous forme de journaux Zeek utilise moins de volume de données que le stockage des données de paquets brutes et s'avère donc plus rentable.

Ce document part du principe que vous avez déjà configuré un ensemble fondamental de contrôles de sécurité, comme décrit dans le guide sur les principes de base de l'entreprise dans Google Cloud.

Cas d'utilisation compatibles

Ce plan est compatible avec les cas d'utilisation suivants :

  • Votre centre d'opérations de sécurité (SOC) doit avoir accès aux données de journalisation du réseau Google Cloud dans un emplacement centralisé afin de pouvoir enquêter sur les incidents de sécurité. Ce plan traduit les données des paquets réseau en journaux que vous pouvez transférer vers vos outils d'analyse et d'investigation. Les outils d'analyse et d'investigation incluent BigQuery, Chronicle, Flowmon, ExtraHop, ou la gestion des informations et des événements de sécurité (SIEM).
  • Vos équipes chargées de la sécurité ont besoin de visibilité sur les réseaux Google Cloud pour détecter les menaces à l'aide d'outils tels que Chronicle. Vous pouvez utiliser ce plan afin de créer un pipeline pour le trafic réseau Google Cloud.
  • Vous souhaitez démontrer comment votre organisation répond aux exigences de conformité concernant la détection et la réponse réseau. Par exemple, votre organisation doit démontrer la conformité avec la norme Memorandum M-21-31 du Bureau de la gestion et du budget (Office of Management and Budget, ou OMB) aux États-Unis.
  • Vos analystes de sécurité réseau ont besoin de données de journalisation réseau à long terme. Ce plan est compatible avec la surveillance à long terme et la surveillance à la demande.

S'il vous faut également des données de capture de paquets (pcap), vous devez utiliser des outils d'analyse de protocoles réseau (par exemple, Wireshark ou tcpdump). L'utilisation des outils d'analyse de protocoles réseau n'entre pas dans le cadre de ce plan.

Vous ne pouvez pas déployer ce plan avec Cloud Intrusion Detection System. Cette solution et Cloud Intrusion Detection System utilisent des règles de mise en miroir de paquets qui ne peuvent être utilisées que par un seul service à la fois.

Coûts

Ce plan peut affecter vos coûts, car vous ajoutez des ressources informatiques et stockez d'importants volumes de données dans Cloud Logging. Tenez compte des points suivants lorsque vous déployez le plan :

  • Chaque machine virtuelle (VM) de collecteur dans Compute Engine s'exécute en tant qu'instance e2-medium.
  • Vous pouvez contrôler les coûts de stockage à l'aide des éléments suivants :
    • En utilisant des filtres de mise en miroir de paquets.
    • En n'utilisant pas de mise en miroir entre les zones pour éviter des frais de sortie interzones.
    • En ne stockant les données que le temps nécessaire à votre organisation.

Vous pouvez utiliser le Simulateur de coût pour estimer vos coûts de calcul, de journalisation et de stockage.

Architecture

Le schéma d'architecture suivant illustre l'infrastructure que vous utilisez pour mettre en œuvre ce plan :

Architecture de télémétrie réseau.

L'architecture présentée dans l'image précédente combine les services et les fonctionnalités Google Cloud suivants :

  • Deux réseaux cloud privé virtuel (VPC) :

    • Un réseau cloud privé virtuel pour les sources mises en miroir.
    • Un réseau VPC pour les instances de collecteur.

    Ces réseaux VPC doivent appartenir au même projet.

  • Les instances Compute Engine ou Google Kubernetes Engine (GKE) (appelées sources en miroir) dans des régions et sous-réseaux spécifiques qui sont la source des paquets réseau. Vous identifiez les instances pour lesquelles vous souhaitez mettre les sources en miroir en utilisant l'une des méthodes suivantes :

    • Tags réseau
    • Noms d'instance de calcul
    • Nom du sous-réseau

  • Des instances Compute Engine fonctionnant en tant qu'instances de collecteur derrière un équilibreur de charge réseau interne à stratégie directe, dans la même région que les sources mises en miroir. Ces instances exécutent l'Image d'or Zeek-Fluentd ou votre image zeek-fluentd personnalisée. Les VM sont de type e2-medium et le débit pris en charge est de 4 Gbit/s.

  • Un équilibreur de charge réseau interne à stratégie directe qui reçoit les paquets provenant des sources mises en miroir et les transmet aux instances de collecteur pour traitement. La règle de transfert de l'équilibreur de charge utilise l'option --is-mirroring-collector.

  • Des règles de pare-feu VPC autorisant les éléments suivants :

    • Trafic sortant des sources mises en miroir vers l'équilibreur de charge réseau interne à stratégie directe.
    • Trafic entrant des instances de collecteur vers les instances mises en miroir.

  • Une règle de mise en miroir de paquets qui définit la région, le sous-réseau, les instances mises en miroir, les protocoles, la direction et la règle de transfert. Chaque région nécessite sa propre règle de mise en miroir de paquets.

  • L'appairage de réseaux VPC pour permettre la connectivité des VM Compute Engine hautement disponibles dans plusieurs régions à l'aide d'adresses IP internes. L'appairage de réseaux VPC permet aux sources mises en miroir de communiquer avec l'équilibreur de charge réseau interne à stratégie directe.

  • Une instance Cloud Logging qui collecte tous les paquets pour le stockage et la récupération par un outil d'analyse et d'investigation.

Comprendre les contrôles de sécurité nécessaires

Cette section décrit les contrôles de sécurité au sein de Google Cloud que vous pouvez utiliser pour aider à sécuriser les différents composants de l'architecture de surveillance du réseau.

Contrôles de sécurité du réseau VPC

Vous créez des réseaux VPC autour de vos sources mises en miroir et de vos collecteurs. Lorsque vous créez le réseau VPC pour les collecteurs, vous supprimez la route par défaut générée par le système, ce qui signifie que toutes les routes de la passerelle Internet par défaut sont désactivées. La désactivation des passerelles Internet par défaut permet de réduire la surface d'attaque du réseau des pirates informatiques externes.

Vous créez des sous-réseaux dans votre réseau VPC pour chaque région. Les sous-réseaux vous permettent de contrôler le flux de trafic entre vos charges de travail sur Google Cloud et également à partir de sources externes. L'accès privé à Google est activé sur les sous-réseaux. L'accès privé à Google permet également de réduire la surface d'attaque du réseau, tout en permettant aux VM de communiquer avec les API et les services de Google.

Pour autoriser la communication entre les réseaux VPC, vous devez activer l'appairage de réseaux VPC. L'appairage de réseaux VPC utilise des routes de sous-réseau pour la connectivité des adresses IP internes. Vous importez et exportez des routes personnalisées pour autoriser une connexion directe entre les sources mises en miroir et les collecteurs. Vous devez limiter toutes les communications aux routes régionales, car l'équilibreur de charge réseau interne à stratégie directe pour les collecteurs n'accepte pas les routes globales.

Règles de pare-feu

Vous utilisez des règles de pare-feu pour définir les connexions que peuvent établir les sources mises en miroir et les collecteurs. Vous configurez une règle d'entrée pour autoriser les vérifications d'état régulières du temps d'activité, une règle de sortie pour tous les protocoles sur les sources mises en miroir, et une règle d'entrée pour tous les protocoles sur les collecteurs.

Contrôles de sécurité des VM de collecteur

Les VM de collecteur sont chargées de recevoir les données des paquets. Les VM de collecteur sont des VM identiques qui fonctionnent comme des groupes d'instances gérés (MIG). Vous activez les vérifications de l'état pour autoriser la recréation automatique d'une VM qui ne répond pas. En outre, vous autorisez les collecteurs à effectuer un autoscaling en fonction de vos besoins en termes d'utilisation.

Chaque VM de collecteur exécute l'image Packer de zeek-fluentd. Cette image se compose de Zeek, qui génère les journaux, et de Fluentd, qui transmet les journaux à Cloud Logging. Après avoir déployé le module Terraform, vous pouvez mettre à jour les packages de système d'exploitation et les packages Zeek de la VM et appliquer les contrôles de sécurité requis pour votre organisation.

Contrôles de sécurité des équilibreurs de charge internes

L'équilibreur de charge réseau interne à stratégie directe dirige le trafic de paquet réseau provenant des sources mises en miroir vers les VM de collecteur pour qu'il soit traité. Toutes les VM de collecteur doivent s'exécuter dans la même région que l'équilibreur de charge réseau interne à stratégie directe.

La règle de transfert de l'équilibreur de charge réseau interne à stratégie directe définit que l'accès est possible à partir de tous les ports, mais que l'accès mondial n'est pas autorisé. En outre, la règle de transfert définit cet équilibreur de charge comme un collecteur de mise en miroir, à l'aide de l'option --is-mirroring-collector.

Vous n'avez pas besoin de configurer un équilibreur de charge pour le stockage, car chaque VM de collecteur importe directement les journaux dans Cloud Logging.

Mise en miroir de paquets

La mise en miroir de paquets nécessite d'identifier les instances que vous souhaitez mettre en miroir. Vous pouvez identifier les instances que vous souhaitez mettre en miroir à l'aide de tags réseau, de noms d'instance ou du sous-réseau dans lequel elles se trouvent. En outre, vous pouvez filtrer davantage le trafic à l'aide d'un ou de plusieurs des éléments suivants :

  • Protocoles de couche 4, tels que TCP, UDP ou ICMP.
  • Plages CIDR IPv4 dans les en-têtes IP, par exemple 10.0.0.0/8.
  • Sens du trafic que vous souhaitez mettre en miroir, par exemple entrant, sortant ou les deux.

Comptes de service et contrôles des accès

Les comptes de service sont des identités que Google Cloud peut utiliser pour exécuter des requêtes API en votre nom. Les comptes de service garantissent que les identités des utilisateurs ne disposent pas d'un accès direct aux services.

Pour déployer le code Terraform, vous devez emprunter l'identité d'un compte de service disposant des rôles suivants dans le projet :

Les VM de collecteur nécessitent également ce compte de service pour pouvoir s'authentifier auprès des services Google Cloud, obtenir les paquets réseau et les transférer à Cloud Logging.

Pratiques de conservation des données

Vous pouvez spécifier la durée pendant laquelle Cloud Logging stocke vos journaux réseau à l'aide de règles de conservation pour vos buckets de journaux. Pour déterminer la durée de stockage des données, examinez les exigences réglementaires de votre organisation.

Journalisation et audit

Vous pouvez utiliser Cloud Monitoring pour analyser les performances des VM de collecteur et configurer des alertes pour les tests de disponibilité et les conditions de performances telles que la charge du processeur.

Vous pouvez suivre les accès administrateur ou les modifications apportées aux données et à la configuration à l'aide de Cloud Audit Logs. Les journaux d'audit sont compatibles avec Compute Engine, Cloud Load Balancing et Cloud Logging.

Vous pouvez exporter les informations de surveillance comme suit :

Conclusion

Pour mettre en œuvre l'architecture décrite dans ce document, procédez comme suit :

  1. Déployez une référence sécurisée dans Google Cloud, comme décrit dans le plan de base de l'entreprise de Google Cloud. Si vous choisissez de ne pas déployer le plan de base de l'entreprise, assurez-vous que votre environnement dispose d'une référence de sécurité similaire.
  2. Consultez le fichier README du plan et assurez-vous que vous remplissez toutes les conditions requises.

  3. Dans votre environnement de test, déployez l'un des exemples de configurations de télémétrie réseau pour voir le plan en action. Dans le cadre de votre processus de test, procédez comme suit :

    1. Vérifiez que les règles et sous-réseaux de mise en miroir de paquets ont été créés.

    2. Vérifiez que vous disposez du rôle Lecteur de journaux (roles/logging.viewer) et exécutez une commande curl pour afficher vos données de journal. Exemple :

      curl http://example.com/

      Vous devriez constater que les données de journal sont stockées dans Cloud Logging.

    3. Utilisez Security Command Center pour analyser les ressources nouvellement créées et vérifier qu'elles répondent à vos exigences de conformité.

    4. Vérifiez que votre système capture et stocke les paquets réseau appropriés, et affinez les performances si nécessaire.

  4. Déployez le plan dans votre environnement de production.

  5. Connectez Cloud Logging à votre solution SIEM ou Chronicle afin que vos analystes SOC et de sécurité réseau puissent intégrer la nouvelle télémétrie dans leurs tableaux de bord.

Étape suivante