Journaux d’accès S3 : configuration, livraison et CloudTrail

Les journaux d’accès S3 permettent d’examiner les requêtes adressées à un bucket Amazon S3 : l’opération tentée, l’objet concerné et la réponse renvoyée. Ils sont utiles lorsqu’une application reçoit des erreurs ou lorsque vous devez comprendre l’utilisation d’un bucket.

Ce guide configure la livraison directe vers un bucket S3 distinct, puis vérifie que les fichiers reçus sont lisibles. Il précise aussi quand choisir CloudWatch Logs ou CloudTrail. Les exemples concernent les buckets Amazon S3 à usage général. Un service compatible S3 peut proposer d’autres fonctions de journalisation : ces paramètres AWS ne s’appliquent pas automatiquement à un autre fournisseur.

Choisir le mode de journalisation

La documentation AWS actuelle décrit deux destinations pour les journaux d’accès serveur. La livraison directe crée des objets texte dans un bucket S3. La livraison via CloudWatch Logs fournit des journaux structurés avec une configuration différente, notamment pour le chiffrement KMS et l’analyse centralisée. Cette voie entraîne des frais d’ingestion de journaux CloudWatch.

Besoin	Point de départ	À vérifier
Conserver les requêtes sous forme d’objets S3	Livraison directe des journaux d’accès	Bucket de destination, autorisations et conservation
Interroger les journaux ou centraliser leur traitement	Livraison via CloudWatch Logs	Configuration, chiffrement, frais d’ingestion et conservation
Enregistrer les actions API sur les buckets et objets pour un audit	CloudTrail avec les événements nécessaires	Sélecteurs d’événements de données et actions effectivement enregistrées

AWS recommande CloudTrail pour les actions sur les buckets et les objets. La couverture diffère selon le service. Choisir une destination pour les journaux d’accès ne configure pas CloudTrail.

Les événements de données CloudTrail ne sont pas activés par défaut, entraînent des frais supplémentaires et ne figurent pas dans l’historique des événements CloudTrail. Un historique vide ne prouve donc pas que personne n’a lu un objet. Vérifiez d’abord la configuration des événements.

Comprendre les limites des journaux d’accès

AWS livre les journaux d’accès sans garantie d’exhaustivité ni de délai. Des entrées peuvent arriver tard, apparaître plusieurs fois ou manquer. La livraison prend couramment plusieurs heures et les changements de configuration demandent un temps de propagation.

Utilisez ces fichiers pour examiner le trafic observé. Leur absence ne prouve pas qu’une requête n’a jamais eu lieu, et leur nombre de lignes ne constitue pas un relevé exact de facturation. Si votre enquête nécessite un événement ou une identité précise, vérifiez la couverture du service choisi et conservez les identifiants de requête de l’application.

Préparer un bucket de destination distinct

Pour la livraison directe S3, choisissez une destination existante dans le même compte AWS et la même Région que la source. Utilisez le chiffrement SSE-S3, désactivez Requester Pays et choisissez un bucket sans Object Lock. N’activez pas la journalisation d’accès sur la destination elle-même : elle produirait des journaux sur la livraison des journaux. Ces restrictions concernent la livraison directe décrite dans le guide de configuration AWS.

Gardez les deux buckets privés. Le paramètre de propriété des objets Bucket owner enforced convient à l’approche par stratégie de bucket utilisée ici. Il n’est pas nécessaire d’activer les ACL. Accordez séparément aux personnes chargées des investigations le droit de lire les journaux et au service celui de les écrire.

Commencez avec des buckets de test. Remplacez partout les deux noms d’exemple et l’identifiant de compte 123456789012. Le profil logging-admin doit être configuré pour votre compte et votre Région, avec les droits nécessaires pour gérer la stratégie du bucket et sa journalisation. Il doit aussi disposer des droits de lecture utilisés pendant la vérification.

aws sts get-caller-identity --profile logging-admin
aws s3api get-bucket-logging --bucket amzn-s3-demo-source --expected-bucket-owner 123456789012 --profile logging-admin

Confirmez le compte renvoyé par la première commande. Sauvegardez la configuration de journalisation existante avant toute modification. get-bucket-logging indique la configuration directe S3 ; cette commande ne vérifie ni l’arrivée des fichiers ni une livraison CloudWatch distincte. L’option de propriétaire attendu ajoute un contrôle du compte.

Autoriser le service de livraison à écrire les journaux

Enregistrez le document suivant sous log-delivery-policy.json pour une nouvelle destination de test sans stratégie existante. Il autorise le service de journalisation S3 à écrire sous logs/, avec des conditions liées au bucket source et au compte.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSourceBucketLogDelivery",
      "Effect": "Allow",
      "Principal": {
        "Service": "logging.s3.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-access-logs/logs/*",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:s3:::amzn-s3-demo-source"
        },
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        }
      }
    }
  ]
}

Pour une destination existante, intégrez cette instruction à sa stratégie après vérification, en préservant les autres règles. La commande put-bucket-policy écrit une stratégie complète : elle n’ajoute pas une instruction à la stratégie en place. Notre guide des bucket policies S3 explique les actions, ressources et conditions.

aws s3api put-bucket-policy --bucket amzn-s3-demo-access-logs --policy file://log-delivery-policy.json --expected-bucket-owner 123456789012 --profile logging-admin

Cette autorisation permet la livraison, pas la lecture publique. Ne remplacez pas le principal du service par un caractère générique et ne retirez pas les conditions source pour contourner un échec. Recherchez la condition bloquante ou un refus explicite.

Activer la journalisation avec une partition par date d’événement

Enregistrez le document suivant sous logging.json. Il définit la destination, le préfixe et des clés d’objet organisées par date. Il omet les target grants, puisque l’exemple utilise des stratégies avec les ACL désactivées.

{
  "LoggingEnabled": {
    "TargetBucket": "amzn-s3-demo-access-logs",
    "TargetPrefix": "logs/",
    "TargetObjectKeyFormat": {
      "PartitionedPrefix": {
        "PartitionDateSource": "EventTime"
      }
    }
  }
}

Appliquez-le au bucket source, puis relisez la configuration avec les commandes CLI de journalisation :

aws s3api put-bucket-logging --bucket amzn-s3-demo-source --bucket-logging-status file://logging.json --expected-bucket-owner 123456789012 --profile logging-admin
aws s3api get-bucket-logging --bucket amzn-s3-demo-source --expected-bucket-owner 123456789012 --profile logging-admin

Comparez la destination, le préfixe et le format des clés renvoyés avec le fichier. La réussite de la configuration ne constitue qu’un premier contrôle. Vérifiez ensuite la livraison et la lecture.

Créer une requête connue et vérifier sa livraison

Placez auparavant un objet de test sans données sensibles à l’emplacement logging-check/sample.txt dans le bucket source. Après activation, exécutez ces commandes et notez l’heure et le résultat de la requête :

aws s3api head-object --bucket amzn-s3-demo-source --key logging-check/sample.txt --expected-bucket-owner 123456789012 --profile logging-admin
aws s3api list-objects-v2 --bucket amzn-s3-demo-access-logs --prefix logs/ --max-keys 20 --no-paginate --expected-bucket-owner 123456789012 --profile logging-admin

La commande de liste affiche au maximum une page de 20 objets. Répétez-la plus tard ou consultez la destination dans la console. Un résultat immédiatement vide ne suffit pas à conclure à un échec. Quand les journaux arrivent, ouvrez un fichier et cherchez la clé de test, l’opération et l’heure approximative. Vérifiez que le rôle prévu pour les investigations peut le lire. L’absence d’une entrée reste soumise aux limites de livraison indiquées plus haut.

Avec le partitionnement EventTime, le répertoire correspond au jour de l’événement, tandis que les heures, minutes et secondes du nom de fichier valent zéro. Voici une clé illustrative pour une source située dans eu-west-1 :

logs/123456789012/eu-west-1/amzn-s3-demo-source/2026/11/02/2026-11-02-00-00-00-EXAMPLE

L’heure exacte figure dans l’entrée du journal. Un fichier livré demain peut appartenir à la partition d’aujourd’hui : ne cherchez pas uniquement à la date de livraison.

Lire et interroger les entrées avec soin

Le format texte S3 comprend notamment le bucket, l’heure, l’adresse IP distante, le demandeur, l’opération, la clé, le statut HTTP, le code d’erreur et des champs liés au transfert. Un tiret peut signaler une donnée indisponible ou non applicable. Les champs entre guillemets, comme la requête et le user-agent, peuvent contenir des espaces : découper chaque ligne à chaque espace n’est pas une méthode fiable.

Partez d’une question précise : quelles requêtes vers une clé connue ont reçu un statut 403, ou quelles opérations ont changé autour d’un déploiement ? Conservez l’identifiant de requête avec la clé et l’horodatage. Une adresse IP seule ne suffit pas à identifier une personne.

Pour des volumes plus importants, partez des exemples Athena d’AWS. Faites correspondre l’emplacement de la table et les partitions au préfixe choisi. Comparez les lignes analysées avec les entrées brutes avant de vous fier au résultat, et limitez les dates parcourues. Un résultat vide peut provenir d’un mauvais emplacement ou schéma plutôt que d’une absence d’activité.

Diagnostiquer l’absence de journaux S3

Procédez à ces contrôles avant de modifier les autorisations :

1. Relisez la configuration source et vérifiez le nom de destination, le compte et la Région.
2. Faites correspondre le préfixe d’objet de la stratégie à TargetPrefix, puis vérifiez les deux conditions source.
3. Examinez les refus explicites de la stratégie de destination et des stratégies d’organisation applicables.
4. Contrôlez le chiffrement, Object Lock et Requester Pays sur la destination.
5. Laissez le temps à la configuration et à la livraison de prendre effet, puis créez une autre requête connue.
6. Si les objets arrivent mais restent illisibles, examinez les droits du lecteur et le chiffrement avant d’élargir les droits de livraison.

La référence de dépannage AWS relie les erreurs courantes à ces causes. Distinguez les erreurs de configuration, les délais de livraison et les échecs de lecture dans le compte rendu de l’incident.

Définir la conservation et les droits de lecture

La livraison directe n’entraîne pas de frais de journalisation distincts, mais le stockage et l’analyse des fichiers ont un coût. Définissez la durée de conservation, les personnes autorisées à les lire et leur traitement à échéance. Les journaux peuvent révéler des noms d’objets, des habitudes d’accès et des adresses réseau.

Une règle de cycle de vie S3 peut déplacer ou faire expirer les objets de journal. Vérifiez son préfixe et son effet sur les objets existants avant de l’appliquer. Si le versionnement est actif, tenez aussi compte des versions non courantes. Notre guide du cycle de vie S3 détaille ces choix. Documentez la durée retenue et sa justification avec la configuration.

L’objectif est de relier une requête connue à une entrée lisible, avec une couverture et une conservation documentées. Répétez ce contrôle après toute modification des stratégies, du chiffrement, de la destination ou de la journalisation.