Partager via

Résoudre les problèmes du connecteur AWS S3

  • Article

Le connecteur Amazon Web Services (AWS) S3 vous permet d’ingérer des journaux des services AWS, collectés dans des compartiments AWS S3, dans Microsoft Sentinel. Les types de journaux que nous prenons actuellement en charge sont AWS CloudTrail, VPC Flow Logs et AWS GuardDuty.

Cet article explique comment identifier rapidement la cause des problèmes qui se produisent avec le connecteur AWS S3 afin de trouver les étapes nécessaires pour résoudre les problèmes.

Découvrir comment connecter Microsoft Sentinel à Amazon Web Services pour ingérer les données des journaux des services AWS.

Microsoft Sentinel ne reçoit pas de données du connecteur Amazon Web Services S3 ou d’un de ses types de données

Les journaux du connecteur AWS S3 (ou d’un de ses types de données) ne sont pas visibles dans l’espace de travail Microsoft Sentinel pendant plus de 30 minutes après la connexion du connecteur.

Avant de rechercher une cause et une solution, passez en revue ces considérations :

  • Jusqu’à 20 à 30 minutes peuvent être nécessaires à partir du moment où le connecteur est connecté pour que les données soient ingérées dans l’espace de travail.
  • L’état de connexion du connecteur indique qu’il existe une règle de collecte. Il n’indique pas que des données ont été ingérées. Si l’état du connecteur Amazon Web Services S3 est vert, cela signifie qu’il existe une règle de collecte pour un des types de données, mais qu’il n’y a toujours pas de données.

Déterminer la cause de votre problème

Dans cette section, nous abordons ces causes :

  1. Les stratégies d’autorisations du connecteur AWS S3 ne sont pas correctement définies.
  2. Les données ne sont pas ingérées dans le compartiment S3 d’AWS.
  3. Le service SQS (Amazon Simple Queue Service) dans le cloud AWS ne reçoit pas de notifications du compartiment S3.
  4. Les données ne peuvent pas être lues à partir de SQS/S3 dans le cloud AWS. Avec les journaux GuardDuty, le problème est provoqué par des autorisations KMS incorrectes.

Cause 1 : Les stratégies d’autorisations du connecteur AWS S3 ne sont pas correctement définies.

Ce problème est provoqué par des autorisations incorrectes dans l’environnement AWS.

Créer des stratégies d’autorisations

Vous avez besoin de stratégies d’autorisations pour déployer le connecteur de données AWS S3. Passez en revue les autorisations requises et définissez les autorisations appropriées.

Cause 2 : Les données appropriées n’existent pas dans le compartiment S3.

Les journaux appropriés n’existent pas dans le compartiment S3.

Solution : Recherchez les journaux et exportez-les si nécessaire

  1. Dans AWS, ouvrez le compartiment S3, recherchez le dossier approprié en fonction des journaux requis, puis vérifiez s’il existe des fichiers journaux dans le dossier.
  2. Si les données n’existent pas, il y a un problème avec la configuration AWS. Dans ce cas, vous devez configurer un service AWS pour exporter les journaux vers un compartiment S3.

Cause 3 : Les données S3 n’arrivent pas au SQS

Les données n’ont pas été transférées de S3 au SQS.

Solution : Vérifiez que les données sont arrivées et configurent des notifications d’événements

  1. Dans AWS, ouvrez le service SQS approprié.
  2. Sous l’onglet Monitoring, vous devez voir le trafic dans le widget Nombre de messages envoyés. S’il n’y a pas de trafic dans le SQS, c’est qu’il y a un problème de configuration d’AWS.
  3. Assurez-vous que la définition des notifications d’événements pour le service SQS inclut les filtres de données appropriés (préfixe et suffixe).
    1. Pour afficher les notifications d’événements, dans le compartiment S3, sélectionnez l’onglet Propriétés, puis accédez à la section Notifications d’événements.
    2. Si vous ne voyez pas cette section, créez-la.
    3. Assurez-vous que SQS dispose des stratégies pertinentes pour obtenir les données à partir du compartiment S3. Le SQS doit contenir cette stratégie sous l’onglet Stratégie d’accès.

Cause 4 : Le SQS n’a pas lu les données

Le SQS n’a pas lu correctement les données S3.

Solution : Vérifiez que le SQS lit les données

  1. Dans AWS, ouvrez le service SQS approprié.

  2. Sous l’onglet Monitoring, vous devez voir le trafic dans les widgets Nombre de messages supprimés et Nombre de messages reçus.

  3. Un seul pic de données n’est pas suffisant. Attendez qu’il y ait suffisamment de données (plusieurs pics), puis recherchez s’il y a des problèmes.

  4. Si au moins un des widgets est vide, vérifiez les journaux d’intégrité en exécutant cette requête :

    SentinelHealth 
| where TimeGenerated > ago(1d)
| where SentinelResourceKind in ('AmazonWebServicesCloudTrail', 'AmazonWebServicesS3')
| where OperationName == 'Data fetch failure summary'
| mv-expand TypeOfFailureDuringHour = ExtendedProperties["FailureSummary"]
| extend StatusCode = TypeOfFailureDuringHour["StatusCode"]
| extend StatusMessage = TypeOfFailureDuringHour["StatusMessage"]
| project SentinelResourceKind, SentinelResourceName, StatusCode, StatusMessage, SentinelResourceId, TypeOfFailureDuringHour, ExtendedProperties

  5. Assurez-vous que la fonctionnalité d’intégrité est activée :

    SentinelHealth 
| take 20

  6. Si la fonctionnalité d’intégrité n’est pas activée, activez-la.

Les données du connecteur AWS S3 (ou de l’un de ses types de données) s’affichent dans Microsoft Sentinel avec un retard de plus de 30 minutes

Ce problème se produit généralement quand Microsoft ne peut pas lire les fichiers dans le dossier S3. Microsoft ne peut pas lire les fichiers, car ils sont chiffrés ou au format incorrect. Dans ces situations, de nombreuses nouvelles tentatives sont à l’origine d’un délai d’ingestion.

Déterminer la cause de votre problème

Dans cette section, nous abordons ces causes :

  • Le chiffrement des journaux n’est pas configuré correctement
  • Les notifications d’événements ne sont pas définies correctement
  • Erreurs d’intégrité ou intégrité désactivée

Cause 1 : Le chiffrement des journaux n’est pas configuré correctement

Si les journaux sont entièrement ou partiellement chiffrés par le service de gestion des clés (KMS), Microsoft Sentinel n’a peut-être pas l’autorisation nécessaire pour que service KMS déchiffre les fichiers.

Solution : Vérifiez le chiffrement des journaux

Vérifiez que Microsoft Sentinel dispose de l’autorisation pour ce service KMS déchiffre les fichiers. Passez en revue les autorisations KMS requises pour les journaux GuardDuty et CloudTrail.

Cause 2 : Les notifications d’événements ne sont pas configurées correctement

Quand vous configurez une notification d’événement Amazon S3, vous devez spécifier les types d’événements pris en charge auxquels Amazon S3 doit envoyer la notification. Si un type d’événement que vous n’avez pas spécifié existe dans votre compartiment Amazon S3, Amazon S3 n’envoie pas la notification.

Solution : Vérifiez que les notifications d’événements sont définies de façon appropriée

Pour vérifier que les notifications d’événements de S3 vers le service SQS sont définies correctement, vérifiez que :

  • La notification est définie à partir du dossier spécifique qui inclut les journaux, et non pas à partir du dossier principal qui contient le compartiment.
  • La notification est définie avec le suffixe .gz. Par exemple :

Cause 3 : Erreurs d’intégrité ou intégrité désactivée

Il peut y avoir des erreurs dans les journaux d’intégrité, ou la fonctionnalité d’intégrité peut ne pas être activée.

Solution : Vérifiez qu’il n’y a aucune erreur dans les journaux d’intégrité et activez l’intégrité

  1. Vérifiez qu’il n’existe aucune erreur dans les journaux d’intégrité en exécutant cette requête :

    SentinelHealth
| where TimeGenerated between (ago(startTime)..ago(endTime))
| where SentinelResourceKind  == "AmazonWebServicesS3"
| where Status != "Success"
| distinct TimeGenerated, OperationName, SentinelResourceName, Status, Description

  2. Assurez-vous que la fonctionnalité d’intégrité est activée :

    SentinelHealth 
| take 20

  3. Si la fonctionnalité d’intégrité n’est pas activée, activez-la.

Étapes suivantes

Dans cet article, vous avez appris à identifier rapidement les causes et à résoudre les problèmes courants liés au connecteur AWS S3.

Nous recevons volontiers les commentaires, les suggestions, les demandes de fonctionnalités, les rapports de bogues, ou les améliorations et les ajouts. Rendez-vous sur le référentiel GitHub de Microsoft Sentinel pour créer un problème ou dupliquer (fork) et charger une contribution.