2.4 - Dépanner les solutions de journalisation (buckets vides, refus KMS, événements de données manquants)

1. Une enquete doit determiner qui a lu un objet S3 precis la semaine derniere. Un trail multi-region existe, mais l'appel GetObject est introuvable dans les journaux. Pourquoi ?

• Les operations de lecture ne sont jamais enregistrees par CloudTrail, car seuls les appels modifiants sont juges pertinents pour une piste d'audit, quelle qu'elle soit
• Le trail doit etre recree dans la meme region que le bucket
• L'activite au niveau des objets S3 est un evenement de donnees, et les evenements de donnees ne sont pas journalises par defaut (bonne réponse)
• L'objet etait chiffre, donc CloudTrail n'a pas pu enregistrer l'appel

CloudTrail journalise par defaut les evenements de gestion, mais les operations au niveau des objets comme GetObject et PutObject sont des evenements de donnees qu'il faut activer explicitement via un selecteur d'evenements, et qui se facturent a part. Les evenements de gestion en lecture seule sont bien journalises, un trail multi-region couvre deja la region du bucket, et le chiffrement de l'objet n'influe pas sur l'enregistrement de l'appel.

2. CloudTrail a ete configure pour livrer dans un bucket d'un autre compte, mais aucun fichier n'arrive jamais. Quelle est la cause la plus probable ?

• La livraison inter-comptes exige que les deux comptes appartiennent a la meme organisation et a la meme region
• Un trail ne peut ecrire que dans un bucket de son propre compte, il faut donc changer de destination
• La politique du bucket de destination n'accorde pas s3:PutObject a cloudtrail.amazonaws.com pour ce trail (bonne réponse)
• Le versionnement est active sur le bucket, ce qui bloque la livraison de nouveaux objets tant que la version precedente n'a pas expire via une regle de cycle de vie

La livraison inter-comptes est prise en charge et courante, mais la politique du bucket de destination doit autoriser le principal de service CloudTrail a appeler s3:GetBucketAcl et s3:PutObject, generalement avec une condition aws:SourceArn nommant le trail. L'appartenance a une organisation et l'identite de region ne sont pas exigees, et le versionnement ne bloque jamais l'ecriture de nouveaux objets.

3. CloudTrail a ete configure pour envoyer ses evenements vers CloudWatch Logs, mais le groupe de journaux reste vide. Que manque-t-il en general ?

• Le role IAM que CloudTrail assume pour ecrire dans le groupe de journaux (bonne réponse)
• Un filtre de metrique sur le groupe de journaux de destination
• Une SCP autorisant logs:PutLogEvents pour tous les principaux de l'organisation, sans laquelle la livraison des enregistrements est refusee silencieusement
• Un point de terminaison VPC pour CloudWatch Logs

CloudTrail a besoin d'un role accordant logs:CreateLogStream et logs:PutLogEvents sur le groupe cible, et un role casse ou supprime interrompt silencieusement la livraison. Un filtre de metrique ne fait que lire ce qui est deja arrive, les SCP restreignent au lieu d'accorder, et la livraison vers CloudWatch Logs est un chemin de service a service qui ne depend pas d'un point de terminaison VPC.

4. Les journaux CloudTrail sont chiffres en SSE-KMS. Des auditeurs disposant de s3:GetObject sur le bucket recoivent un AccessDenied au telechargement d'un fichier. Que manque-t-il ?

• Une ACL de bucket S3 leur accordant la permission READ
• kms:Decrypt sur la cle utilisee pour chiffrer les objets (bonne réponse)
• Une URL pre-signee generee par un administrateur pour chaque objet que les auditeurs doivent ouvrir pendant leur revue
• Un acces en lecture a la console CloudTrail

Lire un objet SSE-KMS exige a la fois la permission de lecture S3 et kms:Decrypt sur la cle, accordee via la politique de cle et la politique d'identite. Les ACL de bucket sont un mecanisme ancien desactive sur les buckets modernes, une URL pre-signee echoue toujours sans droit de dechiffrement car elle ne porte qu'une autorisation S3, et l'acces console ne change rien a la cryptographie des objets.

5. Les journaux d'acces d'un Application Load Balancer ont ete actives mais le bucket S3 reste vide. Que verifier en premier ?

• La politique de bucket autorisant le service de livraison a ecrire dans le prefixe (bonne réponse)
• Si l'equilibreur de charge a au moins deux zones de disponibilite activees
• Si les controles de sante du groupe cible passent, car l'equilibreur suspend la publication des journaux d'acces tant qu'aucune cible saine n'est enregistree derriere lui
• Si le bucket a l'option Requester Pays activee

La livraison des journaux d'acces echoue silencieusement quand la politique du bucket de destination n'autorise pas le principal de livraison a deposer des objets sous le prefixe configure. Le nombre de zones de disponibilite ne conditionne pas la journalisation, des cibles en mauvaise sante produisent des requetes journalisees avec des codes d'erreur plutot qu'une absence de journaux, et Requester Pays decide seulement qui paie les telechargements.

6. L'agent CloudWatch tourne sur une instance EC2 mais aucun flux de journaux n'apparait dans le groupe de destination. Que faut-il verifier ?

• Que l'instance est dans un sous-reseau public avec une adresse IP elastique
• Que le role de l'instance autorise logs:CreateLogStream et logs:PutLogEvents (bonne réponse)
• Que le groupe de journaux a ete cree manuellement au prealable, car l'agent refuse d'ecrire dans un groupe dont le nom ne lui a pas ete fourni a l'installation
• Que la surveillance detaillee est activee sur l'instance

L'agent s'authentifie avec le role de l'instance : l'absence de logs:CreateLogGroup, logs:CreateLogStream ou logs:PutLogEvents est donc la cause classique d'un echec silencieux. Une IP publique n'est pas necessaire si une passerelle NAT ou un point de terminaison VPC Logs assure la connectivite, l'agent cree lui-meme le groupe quand il y est autorise, et la surveillance detaillee ne change que la frequence des metriques EC2.