Collecter les journaux AWS CloudTrail

Compatible avec :

Ce document explique comment collecter les journaux AWS CloudTrail en configurant un flux Google Security Operations et comment les champs de journaux sont mappés aux champs du modèle de données unifié (UDM) Google SecOps.

Pour en savoir plus, consultez [Ingestion de données dans Google SecOps][1].

Un déploiement typique se compose d'AWS CloudTrail et du flux Google SecOps configuré pour envoyer des journaux à Google SecOps. Votre déploiement peut être différent du déploiement type décrit dans ce document. Le déploiement contient les composants suivants :

  • AWS CloudTrail : plate-forme qui collecte les journaux.

  • AWS S3 : plate-forme qui stocke les journaux.

  • Flux Google SecOps : flux Google SecOps qui récupère les journaux depuis AWS S3 et les écrit dans Google SecOps.

  • Google SecOps : plate-forme qui conserve et analyse les journaux d'AWS CloudTrail.

Une étiquette d'ingestion identifie l'analyseur qui normalise les données de journaux brutes au format UDM structuré. Les informations de ce document s'appliquent au parseur avec le libellé d'ingestion AWS_CLOUDTRAIL.

Avant de commencer

Assurez-vous de remplir les conditions suivantes :

  • Compte AWS
  • les conditions préalables à l'utilisation d'AWS CloudTrail sont remplies. Pour en savoir plus, consultez la page Configurer AWS CloudTrail.
  • Tous les systèmes de l'architecture de déploiement utilisent le fuseau horaire UTC.

Étapes de base pour ingérer des journaux depuis S3 avec SQS

Cette section décrit les étapes de base pour ingérer les journaux AWS CloudTrail dans votre instance Google SecOps. Les étapes décrivent comment procéder à l'aide d'Amazon S3 avec Amazon SQS comme type de source de flux.

Configurer AWS CloudTrail et S3

Dans cette procédure, vous allez configurer les journaux AWS CloudTrail pour qu'ils soient écrits dans un bucket S3.

  1. Dans la console AWS, recherchez CloudTrail.
  2. Cliquez sur Créer un parcours.
  3. Indiquez un nom de parcours.
  4. Sélectionnez Créer un bucket S3. Vous pouvez également choisir d'utiliser un bucket S3 existant.
  5. Indiquez un nom pour l'alias AWS KMS ou choisissez une clé AWS KMS existante.
  6. Vous pouvez conserver les autres paramètres par défaut et cliquer sur Suivant.
  7. Choisissez Type d'événement, ajoutez des événements de données si nécessaire, puis cliquez sur Suivant.
  8. Vérifiez les paramètres dans Vérifier et créer, puis cliquez sur Créer un essai.
  9. Dans la console AWS, recherchez Buckets Amazon S3.
  10. Cliquez sur le bucket de journaux que vous venez de créer, puis sélectionnez le dossier AWSLogs. Cliquez ensuite sur Copier l'URI S3 et enregistrez-le pour l'utiliser lors des étapes suivantes.

Configurer une file d'attente SQS et SNS standards

Si vous utilisez une file d'attente SQS, il doit s'agir d'une file d'attente standard, et non d'une file d'attente FIFO.

  1. Activez AWS CloudTrail et configurez-le pour qu'il envoie les journaux à un bucket S3 à l'aide d'une piste nouvelle ou existante.
  2. Ouvrez la console AWS SNS et créez un sujet standard. Nommez-le, par exemple, CloudTrail-Notification-Topic.
  3. Créez une file d'attente SQS à l'aide de la console AWS SQS, par exemple : CloudTrail-Notification-Queue, et mettez à jour sa stratégie d'accès pour autoriser l'ARN du sujet SNS à envoyer des messages. Pour savoir comment créer des files d'attente SQS, consultez Premiers pas avec Amazon SQS.

    Exemple d'extrait de règle SQS :

    {
       "Version": "2012-10-17",
       "Id": `PolicyForSNS`,
       "Statement": [
          {
             "Sid": "AllowSNS",
             "Effect": "Allow",
             "Principal": { "Service": "sns.amazonaws.com" },
             "Action": "SQS:SendMessage",
             "Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:CloudTrail-Notification-Queue",
             "Condition": {
             "ArnEquals": { "aws:SourceArn": "arn:aws:sns:REGION:ACCOUNT_ID:CloudTrail-Notification-Topic"}
             }
          }
       ]
    }
    
  4. Accédez à Sujet SNS → Abonnements → Créer un abonnement, définissez le protocole sur SQS et le point de terminaison sur l'ARN de la file d'attente SQS.

  5. CloudTrail n'envoie pas de nouveaux journaux à SNS de manière native. Pour activer les notifications, vous pouvez utiliser un sélecteur d'événements CloudTrail pour les événements de gestion ou l'intégration de CloudTrail à CloudWatch Logs, puis créer une règle d'événement CloudWatch qui déclenche les notifications en définissant une rubrique SNS comme cible. Pour en savoir plus, consultez Configurer les notifications sur votre bucket S3.

    Exemple de modèle d'événement :

    {
       "source": ["aws.s3"],
       "detail-type": ["AWS API Call via CloudTrail"],
       "detail": {
          "eventName": ["PutObject"],
          "requestParameters": {
             "bucketName": [`CloudTrail-Notification-Topic`]
          }
       }
    }
    
  6. Assurez-vous que les rôles ou les règles IAM autorisent CloudWatch Events à publier des événements sur SNS, et que SNS est autorisé à envoyer des messages à SQS.

Configurer un utilisateur AWS IAM

Configurez un utilisateur AWS IAM que Google SecOps utilisera pour accéder à la fois à la file d'attente SQS (le cas échéant) et au bucket S3.

  1. Dans la console AWS, recherchez IAM.
  2. Cliquez sur Utilisateurs, puis sur Créer des utilisateurs sur l'écran suivant.
  3. Attribuez un nom à l'utilisateur (par exemple, chronicle-feed-user), puis sélectionnez Provide user access to the AWS Management Console (Fournir un accès utilisateur à la console AWS Management).
  4. Sélectionnez Attach existing policies directly (Associer directement les stratégies existantes), puis AmazonS3ReadOnlyAccess ou AmazonS3FullAccess, selon vos besoins. AmazonS3FullAccess serait utilisé si Google SecOps devait vider les buckets S3 après la lecture des journaux, afin d'optimiser les coûts de stockage AWS S3.
  5. Comme alternative recommandée à l'étape précédente, vous pouvez restreindre davantage l'accès au bucket S3 spécifié uniquement en créant une règle personnalisée. Cliquez sur Créer une stratégie et suivez la documentation AWS pour créer une stratégie personnalisée.
  6. Lorsque vous appliquez une stratégie, assurez-vous d'avoir inclus sqs:DeleteMessage. Google SecOps ne peut pas supprimer les messages si l'autorisation sqs:DeleteMessage n'est pas associée à la file d'attente SQS. Tous les messages sont accumulés côté AWS, ce qui entraîne un retard, car les équipes Google SecOps tentent à plusieurs reprises de transférer les mêmes fichiers.
  7. Cliquez sur Suivant : Tags.
  8. Ajoutez des tags si nécessaire, puis cliquez sur Suivant : Vérification.
  9. Vérifiez la configuration, puis cliquez sur Créer un utilisateur.
  10. Une fois l'utilisateur créé, accédez à l'onglet Security Credentials (Identifiants de sécurité), puis cliquez sur Create Access Key (Créer une clé d'accès).
  11. Choisissez CLI, puis cliquez sur Next:Tags (Suivant : balises).
  12. Ajoutez des tags si nécessaire, puis cliquez sur Créer une clé d'accès : Vérification.
  13. Copiez l'ID de clé d'accès et la clé d'accès secrète de l'utilisateur créé pour les utiliser à l'étape suivante.

Configurer les autorisations de clé KMS

Une clé KMS est requise pour déchiffrer les journaux CloudTrail, qui sont chiffrés côté serveur. AWS KMS offre un chiffrement et une sécurité renforcés pour les données sensibles stockées dans Amazon S3.

  1. Dans la console AWS, recherchez Key Management Service (KMS).
  2. Cliquez sur Créer une clé > Suivant.
  3. Ajoutez un alias pour la clé. Ajoutez éventuellement une Description et des Tags si nécessaire. Cliquez sur Suivant : Vérifier.
  4. Après avoir vérifié la configuration, cliquez sur Suivant.
  5. Sélectionnez les utilisateurs clés qui doivent avoir accès à cette clé, puis cliquez sur Terminer.

Configurer des flux

Il existe deux points d'entrée différents pour configurer les flux dans la plate-forme Google SecOps :

  • Paramètres SIEM> Flux > Ajouter
  • Plate-forme de contenu> Packs de contenu> Premiers pas

Configurer le flux AWS CloudTrail

  1. Cliquez sur le pack Amazon Cloud Platform.
  2. Dans le type de journal AWS CloudTrail, spécifiez les valeurs suivantes :
  3. Indiquez les valeurs des champs suivants :

    • Type de source : Amazon SQS V2
    • Nom de la file d'attente : nom de la file d'attente SQS à partir de laquelle lire les données
    • URI S3 : URI du bucket.
      • s3://your-log-bucket-name/
        • Remplacez your-log-bucket-name par le nom réel de votre bucket S3.
    • Options de suppression de la source : sélectionnez l'option de suppression en fonction de vos préférences d'ingestion.

    • Âge maximal des fichiers : incluez les fichiers modifiés au cours des derniers jours. La valeur par défaut est de 180 jours.

    • ID de clé d'accès à la file d'attente SQS : clé d'accès au compte, qui est une chaîne alphanumérique de 20 caractères.

    • Clé d'accès secrète à la file d'attente SQS : clé d'accès au compte, qui est une chaîne alphanumérique de 40 caractères.

    Options avancées

    • Nom du flux : valeur préremplie qui identifie le flux.
    • Espace de noms de l'élément : espace de noms associé au flux.
    • Libellés d'ingestion : libellés appliqués à tous les événements de ce flux.
  4. Cliquez sur Créer un flux.

Pour en savoir plus sur la configuration de plusieurs flux pour différents types de journaux dans cette famille de produits, consultez Configurer des flux par produit.

Types de journaux AWS CloudTrail compatibles

L'analyseur AWS CloudTrail est compatible avec les services suivants :

  • apigateway.amazonaws.com
  • appconfig.amazonaws.com
  • autoscaling.amazonaws.com
  • cloud9.amazonaws.com
  • cloudsearch.amazonaws.com
  • cloudshell.amazonaws.com
  • cloudtrail.amazonaws.com
  • config.amazonaws.com
  • devicefarm.amazonaws.com
  • ds.amazonaws.com
  • dynamodb.amazonaws.com
  • ec2-instance-connect.amazonaws.com
  • ec2.amazonaws.com
  • ecr-public.amazonaws.com
  • ecr.amazonaws.com
  • ecs.amazonaws.com
  • eks.amazonaws.com
  • elasticache.amazonaws.com
  • elasticloadbalancing.amazonaws.com
  • firehose.amazonaws.com
  • guardduty.amazonaws.com
  • health.amazonaws.com
  • iam.amazonaws.com
  • imagebuilder.amazonaws.com
  • kinesis.amazonaws.com
  • kinesisanalytics.amazonaws.com
  • kinesisvideo.amazonaws.com
  • kms.amazonaws.com
  • lambda.amazonaws.com
  • logs.amazonaws.com
  • macie2.amazonaws.com
  • monitoring.amazonaws.com
  • network-firewall.amazonaws.com
  • organizations.amazonaws.com
  • quicksight.amazonaws.com
  • ram.amazonaws.com
  • rds.amazonaws.com
  • resource-explorer-2.amazonaws.com
  • resource-groups.amazonaws.com
  • route53-recovery-readiness.amazonaws.com
  • route53.amazonaws.com
  • route53domains.amazonaws.com
  • route53resolver.amazonaws.com
  • s3-outposts.amazonaws.com
  • s3.amazonaws.com
  • s3express.amazonaws.com
  • secretsmanager.amazonaws.com
  • securityhub.amazonaws.com
  • ses.amazonaws.com
  • signin.amazonaws.com
  • ssm.amazonaws.com
  • sts.amazonaws.com
  • waf-regional.amazonaws.com
  • waf.amazonaws.com
  • wafv2.amazonaws.com

Pour en savoir plus sur le mappage des champs et de l'UDM, consultez Mappage des champs AWS CloudTrail.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.