Reduire les coûts d'ingestion avec Microsoft Sentinel via la gestion des tiers

Introduction

Les coûts associés à Microsoft Sentinel peuvent rapidement devenir démesurés si vos logs sont mal catégorisés ou si des volumes inutiles sont ingérés dans des niveaux de stockage coûteux. Cet article vous guide à travers une optimisation précise pour réduire ces dépenses : ajustez les règles d’ingestion, triez les données par importance et validez vos économies grâce à KQL.

[IMAGE:index:images/sentinel-cost-path.svg:Flux de coût Microsoft Sentinel]

Conditions préalables

Avant de suivre ce guide, assurez-vous de disposer des éléments suivants :

• Une souscription Azure active avec Microsoft Sentinel intégré : les ajustements et les choix de tables n’ont d’impact que si votre espace de travail est configuré.
• Les autorisations Log Analytics Contributor et Data (manage) dans le portail Defender : nécessaires pour modifier les règles de tables et appliquer des transformations.
• L’Azure CLI installé et un shell compatible KQL : certaines étapes fonctionnent mieux via des scripts.
• Au moins une source bruyante dans votre espace de travail Sentinel : les résultats les plus immédiats proviennent de la réduction des volumes excessifs au niveau des tables.

Étape 1 : Analyser les coûts

Commencez par examiner vos volumes de données et leurs niveaux de stockage. Microsoft Sentinel divise les coûts en plusieurs axes :

Analyse pratique avec KQL

Identifiez les tables qui consomment le plus de stockage en utilisant les exemples suivants :

1Usage
2| where TimeGenerated > ago(7d)
3| where IsBillable == true
4| summarize GB = sum(_BilledSize) / 1024 / 1024 / 1024 by DataType
5| top 10 by GB desc

Cela vous permettra de classer les tables par volume facturé. Ensuite, analysez les modèles de croissance horaire pour cibler les sources les plus problématiques :

1Usage
2| where TimeGenerated > ago(24h)
3| where IsBillable == true
4| where DataType in ('SecurityEvent', 'CommonSecurityLog')
5| summarize GB = sum(_BilledSize) / 1024 / 1024 / 1024 by bin(TimeGenerated, 1h), DataType
6| order by TimeGenerated asc

Étape 2 : Filtrer les données avant ingestion

Appliquez des règles de filtrage à l’aide des Data Collection Rules (DCR) pour bloquer les événements inutiles avant qu’ils ne soient facturés. Voici un exemple de transformation simple :

1{
2  "transformKql": "source | where EventID in (4798, 4799)"
3}

Routage basé sur la gravité

Si vous souhaitez classer les données par gravité au lieu de les supprimer, utilisez un logique de routage comme indiqué ci-dessous :

1source
2| extend Route = iif(Severity in ('High', 'Critical'), 'Analytics', 'DataLake')
3| project TimeGenerated, Computer, Severity, Route

Étape 3 : Affecter les bonnes données aux bons tiers

Une fois les flux nettoyés, configurez vos niveaux de stockage en fonction de la pertinence des données.

Étape 4 : Valider et déployer dans l’ordre

La validation est indispensable pour parvenir à des économies mesurables. Procédez comme suit :

Conclusion

Réduire les coûts d'ingestion dans Microsoft Sentinel requiert une approche méthodique : examinez les coûts actuels, filtrez les données inutiles, assignez chaque type de données au tier approprié et validez les économies avec KQL. Suivez cet ordre pour éviter des dépenses inutiles tout en maintenant votre niveau de sécurité.

[IMAGE:index:images/sentinel-tier-decision.svg:Décision sur les tiers Sentinel]