Collecte et sécurité des données du client de découverte

Ce document répond aux questions et préoccupations concernant l'installation du client de découverte Migration Center dans les centres de données. Il met l'accent sur l'importance de la sécurité, de la conformité et des performances lors de la découverte et de la collecte de données à partir des actifs IT des clients dans des environnements hautement réglementés.

Comment les données sont collectées

Le client de découverte utilise plusieurs méthodes pour collecter des données à partir des machines cibles. Les données collectées varient selon la méthode. Au niveau invité, les données sont collectées à l'aide des scripts de collecte. Au niveau de l'hyperviseur, les données sont collectées à l'aide des API de la plate-forme sous-jacente.

Service et processus du client de découverte

Le client de découverte s'exécute en tant que service appelé GoogleMCDC sous un processus appelé mcdc_service.exe.

Scripts de collecte

Toutes les méthodes de collecte au niveau invité utilisées par le client de découverte exécutent des scripts de collecte sur les machines cibles. Vous pouvez consulter les scripts utilisés pour la collecte sur les liens suivants:

Les scripts de collecte stockent les résultats dans un fichier d'archive (zip ou tar) que le client de découverte récupère ensuite.

Mécanismes de collecte

Le client de découverte peut utiliser un ou plusieurs des mécanismes de collecte décrits dans les sections suivantes pour collecter des données auprès des machines cibles.

SSH (Linux)

Lors de la collecte SSH, le processus suivant se produit:

  1. Une session SSH est établie entre la machine collectrice et le serveur cible.
  2. Un répertoire temporaire est créé sous ~/.mcdc-temp/.
  3. Le script de collecte est copié dans ce répertoire.
  4. Le script de collecte est exécuté.
  5. L'archive des résultats est récupérée à l'aide de SCP.
  6. Le répertoire temporaire est nettoyé.

WMI (Windows)

Lors de la collecte WMI sous Windows, le processus suivant se produit:

  1. Une connexion WMI est établie avec la machine cible.
  2. Une clé de registre temporaire (volatile) est créée sur la machine cible sous HKLM:\SOFTWARE\Google\Collector\data.
  3. Le script de collecte est copié dans la clé de registre.
  4. Un répertoire temporaire est créé sous C:\temp.
  5. Le script de collecte est écrit dans le répertoire temporaire.
  6. Le script de collecte est exécuté.
  7. Le résultat de la collecte est écrit dans la clé de registre volatile.
  8. Le résultat est copié sur la machine de collecte.

VMware Guest Tools (Linux et Windows)

Lors de la collecte VMware pour Linux et Windows, le processus suivant se produit:

  1. Un répertoire temporaire est créé à l'aide des outils invités VMware.
  2. Le script de collecte est copié dans ce répertoire.
  3. Le script de collecte est exécuté.
  4. L'archive des résultats est récupérée à l'aide des outils invités VMware.
  5. Le répertoire temporaire est nettoyé.

Collecte de données périodique

Le client de découverte collecte des données de tous les serveurs configurés de manière périodique. Il existe deux types de collections:

  • Collecte complète:s'exécute une fois par jour pour chaque serveur. Cette collection exécute le script de collecte complet qui collecte diverses informations sur la VM, telles que le matériel, l'environnement, les logiciels installés, les processus en cours d'exécution, etc.
  • Collecte des performances:s'exécute toutes les 10 minutes sur chaque serveur. Cette collection exécute le script de collecte des performances qui collecte des données sur l'utilisation du processeur, de la mémoire, du réseau et du disque.

Quelles sont les données recueillies ?

Les scripts de collecte collectent des données sur les VM cibles afin de comprendre comment elles sont configurées et quelles ressources elles utilisent. Cela permet d'évaluer et de planifier leur migration vers le cloud.

La liste suivante décrit les données collectées:

  • Informations système: informations de base essentielles pour déterminer la taille, les exigences de performances et les dépendances de la VM sur du matériel ou des pilotes spécifiques. Il inclut les éléments suivants :
    • Système d'exploitation (version et version)
    • Matériel (processeur, mémoire, informations sur le BIOS)
    • Configuration réseau (interfaces réseau, adresses IP, tables de routage)
    • Stockage (disques, partitions, points d'installation)
  • Logiciels et services installés: les scripts collectent une liste des packages installés et des services en cours d'exécution pour comprendre la pile logicielle de la VM et son rôle. Il inclut les éléments suivants :
    • Serveurs Web (Apache, Tomcat, JBoss)
    • Bases de données (des preuves de SQL Server sont collectées dans le script Windows)
    • Autres applications pouvant nécessiter des configurations spécifiques lors de la migration
  • Configurations d'application: les scripts collectent également les fichiers de configuration des serveurs Web (IIS, Apache, Tomcat, JBoss, WordPress). Cela permet de comprendre les paramètres et les dépendances spécifiques de ces applications, ce qui est essentiel pour assurer une transition fluide vers l'environnement cloud.
  • Détection de VMware et de l'environnement cloud: les scripts Linux et Windows tentent de détecter si la VM s'exécute déjà dans un environnement cloud (AWS ou Google Cloud) ou dans un cluster VCenter. Pour ce faire, ils envoient des requêtes aux serveurs de métadonnées de ces fournisseurs de services cloud. Si la VM se trouve déjà dans le cloud, les scripts collectent les métadonnées pertinentes telles que l'ID d'instance, le type d'instance et d'autres informations.
  • Métriques de performances:les scripts de collecte des performances mesurent l'utilisation des ressources. Par exemple :
    • Processeur
    • Mémoire
    • Opérations d'E/S
    • Mise en réseau
  • Connexions réseau:les scripts collectent les connexions ouvertes pour créer une image des différentes dépendances sur les ressources réseau.

Impact sur les performances des machines cibles

Évaluation de l'utilisation des ressources

L'utilisation des ressources des scripts de collecte sur la machine cible dépend de paramètres tels que le nombre de processus en cours d'exécution, le nombre d'applications déployées, le nombre de connexions réseau actives, etc.

Sous Windows, le script de collecte s'exécute avec la priorité la plus basse disponible via l'API de threading. Sous Linux, une valeur nice de 5 est utilisée pour minimiser les interférences avec les charges de travail de production et s'assurer qu'elles ont une priorité plus élevée que le script de collecte.

Une collecte typique peut prendre entre 5 et 20 secondes d'utilisation élevée du processeur à un seul cœur sur une machine inutilisée. Cela peut prendre plus de temps si d'autres charges de travail sont présentes, car elles ont une priorité plus élevée.

Stratégies d'atténuation

Le client de découverte fournit un mécanisme permettant d'empêcher la collecte de serveurs spécifiques pendant des heures spécifiques. Cette fonctionnalité peut être utilisée pour empêcher la collecte des serveurs exécutant des charges de travail critiques pendant les heures de pointe.

Points à noter concernant la sécurité

Authentification et autorisation

Communication avec les machines cibles

  • Le client de découverte utilise des canaux sécurisés pour s'authentifier et communiquer avec les machines cibles. Cela inclut SSH, WMI, les outils VMware et les connexions VCenter. Le client de découverte utilise les mesures de sécurité intégrées dans le cadre de ces protocoles.
  • Dans SSH, le client de découverte permet à la fois l'authentification par nom d'utilisateur et mot de passe et l'authentification par clé. Pour obtenir la liste complète des types de paires de clés compatibles, consultez la section Exigences concernant les composants cibles.

Communication avec Google Cloud

  • Les clients de découverte enregistrés communiquent avec Google Cloud Migration Center pendant leur fonctionnement normal. La communication s'effectue via un compte de service avec la liaison de rôle roles/migrationcenter.discoveryClient. Le compte de service est créé automatiquement ou fourni par l'utilisateur lors du processus d'enregistrement.
  • La clé privée du compte de service est chiffrée sur la machine cliente de découverte à l'aide du mécanisme de chiffrement décrit dans la section suivante.
  • Toutes les communications avec Google Cloud sont authentifiées à l'aide de ce compte de service et chiffrées à l'aide de SSL/TLS.

Chiffrement des données

  • En transit:tous les canaux de communication du client de découverte utilisent le chiffrement pour protéger les données en transit. Cela inclut la communication avec les machines cibles à l'aide des différents protocoles (SSH/WMI) et la communication avec Google Cloud à l'aide de HTTPS.
  • Au repos:les informations d'identification personnelle, les informations d'identification sensible et les secrets du client de découverte sont tous chiffrés au repos à l'aide de l'algorithme AES128_GCM et de la DPAPI Windows pour stocker les clés de chiffrement de manière sécurisée.

Détection et prévention des intrusions (IDS, Intrusion Detection System, et IPS, Intrusion Prevention System)

Étant donné que le client de découverte est utilisé pour se connecter et exécuter des scripts sur de nombreuses VM de votre organisation, il peut déclencher des alertes EDR ou xDR. Cela dépend fortement de la façon dont vos outils de sécurité sont configurés et des outils spécifiques que vous utilisez. Tenez-en compte et envisagez de créer des exceptions pour les alertes et les appareils spécifiques.

Journalisation et prise en charge

Le client de découverte collecte des journaux pendant son fonctionnement pour permettre le débogage et l'assistance. Les journaux du client de découverte sont collectés à l'aide de deux mécanismes:

  • Journaux locaux:les journaux sont écrits dans un fichier sous C:\ProgramData\Google\mcdc\logs. Les fichiers journaux sont rotatifs et compressés.
  • Journaux Cloud:les clients enregistrés envoient également les journaux à Google Cloud afin qu'ils puissent être utilisés par l'équipe d'assistance Google Cloud lorsque des problèmes client sont signalés.