Partage via

Sélectionner une plateforme Azure cible pour héberger les données historiques exportées

  • Article

L’une des décisions importantes que vous prenez lors de votre processus de migration consiste à choisir l’emplacement de stockage de vos données historiques. Pour prendre cette décision, vous devez comprendre et être en mesure de comparer les différentes plateformes cibles.

Cet article compare les plateformes cibles en termes de performances, de coût, de facilité d’utilisation et de surcharge de gestion.

Notes

Les considérations de cette table s’appliquent uniquement à la migration des journaux historiques et non pas à d’autres scénarios comme la rétention à long terme.

Journaux de base/archive Azure Data Explorer (ADX) Stockage Blob Azure ADX + Stockage Blob Azure
Fonctionnalités : • Appliquez la plupart des expériences de journaux Azure Monitor existantes à moindre coût.
• Les journaux de base sont conservés pendant huit jours, puis sont automatiquement transférés vers l’archive (selon la période de rétention d’origine).
• Utilisez des tâches de recherche pour rechercher parmi des pétaoctets de données et trouver des événements spécifiques.
• Pour des investigations approfondies sur un intervalle de temps spécifique, restaurez les données à partir de l’archive. Les données sont ensuite disponibles dans le cache chaud pour une analyse plus approfondie.		 • ADX et Microsoft Sentinel utilisent Kusto Query Language (KQL), ce qui vous permet d’interroger, d’agréger ou de mettre en corrélation des données dans ces deux plateformes. Par exemple, vous pouvez exécuter une requête KQL de Microsoft Sentinel pour joindre des données stockées dans ADX avec des données stockées dans Log Analytics.
• Avec ADX, vous disposez d’un contrôle considérable sur la taille et la configuration du cluster. Par exemple, vous pouvez créer un cluster plus grand pour obtenir un débit d’ingestion plus élevé, ou créer un cluster plus petit pour contrôler vos coûts.		 • Stockage Blob est optimisé pour stocker des quantités massives de données non structurées.
• Offre des coûts compétitifs.
• Adapté à un scénario où votre organisation ne hiérarchise pas l’accessibilité ou les performances, par exemple lorsqu’elle doit s’aligner sur des exigences de conformité ou d’audit.		 • Les données sont stockées dans un stockage d’objets blob, ce qui limite les coûts.
• Vous utilisez ADX pour interroger les données dans KQL, ce qui vous permet d’accéder facilement aux données. Découvrez comment interroger les données Azure Monitor avec ADX
Convivialité : Idéal

Les options d’archivage et de recherche sont simples à utiliser et accessibles à partir du portail Microsoft Sentinel. Toutefois, les données ne sont pas immédiatement disponibles pour les requêtes. Vous devez effectuer une recherche pour récupérer les données, ce qui peut prendre un certain temps, en fonction de la quantité de données analysées et retournées.		 Bien

Assez facile à utiliser dans le contexte de Microsoft Sentinel. Par exemple, vous pouvez utiliser un classeur Azure pour visualiser les données réparties entre Microsoft Sentinel et ADX. Vous pouvez également interroger des données ADX à partir du portail Microsoft Sentinel à l’aide du proxy ADX.		 Médiocre

Avec les migrations de données historiques, vous devrez peut-être traiter des millions de fichiers, et explorer les données devient alors un vrai défi.		 Moyen

Bien que l’utilisation de l’opérateur externaldata soit très difficile avec un grand nombre d’objets blob à référencer, l’utilisation de tables ADX externes élimine ce problème. La définition de table externe comprend la structure des dossiers de stockage d’objets blob et vous permet d’interroger en toute transparence les données contenues dans de nombreux objets blob et dossiers différents.
Surcharge de gestion : Gestion intégrale

Les options de recherche et d’archivage sont entièrement managées et n’entraînent aucune surcharge de gestion.		 Importante

ADX est externe à Microsoft Sentinel, nécessitant une surveillance et une maintenance.		 Low

Bien que cette plateforme nécessite peu de maintenance, elle ajoute des tâches de surveillance et de configuration, notamment la configuration de la gestion du cycle de vie.		 Moyenne

Avec cette option, vous gérez et surveillez ADX et Stockage Blob Azure, tous deux des composants externes à Microsoft Sentinel. Même si ADX peut être parfois arrêtée, tenez compte de la surcharge de gestion supplémentaire que cette plateforme entraîne.
Performances : Moyenne

En règle générale, vous interagissez avec les journaux de base dans l’archive à l’aide de tâches de recherche, qui conviennent lorsque vous souhaitez conserver l’accès aux données, mais n’avez pas besoin d’y accéder immédiatement.		 Élevé à faible

• Les performances des requêtes d’un cluster ADX dépendent du nombre de nœuds dans le cluster, de la référence SKU de la machine virtuelle du cluster, du partitionnement des données, etc.
• Lorsque vous ajoutez des nœuds au cluster, les performances s’améliorent, moyennant un coût supplémentaire.
• Si vous utilisez ADX, nous vous recommandons de configurer la taille de votre cluster pour équilibrer les performances et les coûts. Cette configuration dépend des besoins de votre organisation, notamment de la rapidité de votre migration, de la fréquence d’accès aux données et du temps de réponse attendu.		 Low

Offre deux niveaux de performances : Premium ou Standard. Bien que les deux niveaux constituent une option pour le stockage à long terme, le niveau Standard est plus économique. Découvrez les limites de performances et de scalabilité.		 Low

Comme les données résident dans le Stockage Blob, les performances sont limitées par cette plateforme.
Coût : Importante

Le coût se compose de deux éléments :
• Coût d’ingestion. Chaque Go de données ingérées dans les journaux de base est soumis aux coûts d’ingestion des journaux Microsoft Sentinel et Azure Monitor, qui s’élèvent à environ 1 $/Go. Consultez les détails de la tarification.
• Coût d’archivage. Le coût des données dans le niveau Archive s’élève à environ 0,02 $/Go par mois. Consultez les détails de la tarification.
En plus de ces deux éléments de coût, si vous avez besoin d’un accès fréquent aux données, des coûts supplémentaires s’appliquent lorsque vous accédez aux données via des tâches de recherche.		 Élevé à faible

• Comme ADX est un cluster de machines virtuelles, vous êtes facturé en fonction de l’utilisation du calcul, du stockage et de la mise en réseau, en plus d’un balisage ADX (consultez les détails de la tarification. Par conséquent, plus vous ajoutez de nœuds à votre cluster et plus vous stockez de données, plus le coût sera élevé.
• ADX offre également des fonctionnalités de mise à l’échelle automatique pour s’adapter à la charge de travail à la demande. ADX peut également bénéficier de la tarification appliquée aux instances réservées. Vous pouvez exécuter vos propres calculs de coûts dans la calculatrice de tarification Azure.		 Low

Dans une configuration optimale, Stockage Blob Azure offre les coûts les plus bas. Pour plus d’efficacité et par souci d’économie, la gestion du cycle de vie de Stockage Microsoft permet de placer automatiquement des objets blob plus anciens dans des niveaux de stockage moins chers.		 Low

Dans ce cas, ADX agit uniquement en tant que proxy, de sorte que le cluster peut être petit. En outre, le cluster peut être arrêté quand vous n’avez pas besoin d’accéder aux données et démarré uniquement lorsque l’accès aux données est nécessaire.
Guide pratique pour accéder aux données : Tâches de recherche Requêtes KQL directes externaldata Requêtes KQL modifiées
Scénario : Accès occasionnel

Pour les scénarios où vous n’avez pas besoin d’exécuter des règles d’analyse intensives ou de déclencher des règles d’analyse, et devez uniquement accéder aux données de façon occasionnelle.		 Accès fréquent

Pour les scénarios où vous devez accéder aux données fréquemment et contrôler la taille et la configuration du cluster.		 Conformité/audit

• Solution optimale pour stocker des quantités massives de données non structurées.
• Pour les scénarios où vous n’avez pas besoin d’un accès rapide aux données ou de performances élevées, par exemple à des fins de mise en conformité ou d’audit.		 Accès occasionnel

Pour les scénarios où vous souhaitez bénéficier du faible coût de Stockage Blob Azure et d’un accès relativement rapide aux données.
Complexité : Très faible Moyenne Faible Élevé
Préparation : GA GA GA GA

Considérations d’ordre général

Maintenant que vous en savez plus sur les plateformes cibles disponibles, passez en revue ces principaux facteurs pour finaliser votre décision.

Utiliser des journaux ingérés

Déterminez comment votre organisation utilisera les journaux ingérés pour guider votre sélection de la plateforme d’ingestion.

Tenez compte de ces trois scénarios généraux :

  • Votre organisation doit conserver les journaux uniquement à des fins de mise en conformité ou d’audit. Dans ce cas, votre organisation accède rarement aux données. Même si votre organisation accède aux données, les performances élevées ou la facilité d’utilisation ne constituent pas une priorité.
  • Votre organisation doit conserver les journaux pour vos équipes puissent accéder facilement et assez rapidement aux journaux.
  • Votre organisation doit conserver les journaux pour vos équipes puissent accéder aux journaux de façon occasionnelle. Les performances et la facilité d’utilisation sont secondaires.

Consultez la comparaison des plateformes pour déterminer quelle plateforme convient à chacun de ces scénarios.

Vitesse de migration

Dans certains scénarios, vous devrez peut-être respecter un calendrier serré, par exemple votre organisation doit faire évoluer d’urgence son ancien système SIEM en raison de l’expiration de sa licence.

Passez en revue les composants et facteurs qui déterminent la vitesse de votre migration.

Source de données

La source de données est généralement un système de fichiers local ou un stockage cloud, par exemple S3. Les performances de stockage d’un serveur dépendent de plusieurs facteurs, notamment la technologie de disque (SSD et HDD), la nature des requêtes d’E/S et la taille de chaque requête.

Par exemple, les performances des machines virtuelles Azure varient de 30 Mo par seconde sur des références SKU de machine virtuelle plus petites, à 20 Go par seconde pour certaines références SKU optimisées pour le stockage à l’aide de disques NVM Express (NVMe). Découvrez comment concevoir votre machine virtuelle Azure pour des performances de stockage élevées. Vous pouvez également appliquer la plupart des concepts aux serveurs locaux.

Puissance de calcul

Dans certains cas, même si votre disque est capable de copier vos données rapidement, la puissance de calcul constitue le goulet d’étranglement dans le processus de copie. Dans ces cas, vous pouvez choisir une des options de mise à l’échelle suivantes :

  • Mise à l'échelle verticale. Vous augmentez la puissance d’un seul serveur en ajoutant davantage de processeurs ou en augmentant la vitesse du processeur.
  • Mise à l'échelle horizontale. Vous ajoutez d’autres serveurs, ce qui augmente le parallélisme du processus de copie.

Plateforme cible

Chacune des plateformes cibles décrites dans cette section présente un profil de performances différent.

  • Journaux Azure Monitor de base. Par défaut, les journaux de base peuvent être envoyés à Azure Monitor à un débit d’environ 1 Go par minute. Ce débit vous permet d’ingérer environ 1,5 To par jour soit 43 To par mois.
  • - Azure Data Explorer. Les performances d’ingestion varient selon la taille du cluster que vous approvisionnez et les paramètres de traitement par lots que vous appliquez. Découvrez les meilleures pratiques d’ingestion, notamment les performances et la surveillance.
  • Stockage Blob Azure. Les performances d’un compte Stockage Blob Azure peuvent varier considérablement en fonction du nombre et de la taille des fichiers, de la taille de la tâche, de la concurrence, etc. Découvrez comment optimiser les performances d’AzCopy avec Stockage Azure.

Quantité de données

La quantité de données est le principal facteur qui affecte la durée du processus de migration. Vous devez donc configurer votre environnement en fonction de votre jeu de données.

Pour déterminer la durée minimale de la migration et où le goulet d’étranglement peut survenir, tenez compte de la quantité de données et de la vitesse d’ingestion de la plateforme cible. Par exemple, vous sélectionnez une plateforme cible qui peut ingérer 1 Go par seconde, et vous devez migrer 100 To. Dans ce cas, votre migration prendra au moins 100 000 Go, multipliés par le débit de 1 Go par seconde. Divisez le résultat de 3 600 pour obtenir 27 heures. Ce calcul est correct si le reste des composants du pipeline, notamment le disque local, le réseau et les machines virtuelles, peut être traité à un débit de 1 Go par seconde.

Étapes suivantes

Dans cet article, vous avez appris à mapper vos règles de migration de QRadar vers Microsoft Sentinel.

Sélectionner un outil d’ingestion de données