Nous revoilà pour parler d'un service que je n'ai cessé de mentionner toute la semaine, qui s'appelle CloudTrail. C'est un outil qui va vous permettre de garder une trace complète des appels d'API effectués dans votre compte. Évidemment, c'est un outil précieux pour savoir ce qui se passe à l'intérieur de votre compte, que ce soit sur des sujets de sécurité ou sur des sujets de debugging. Allons-y ! On va présenter rapidement CloudTrail, qui est un service assez simple à comprendre. Vous allez voir qu'il n'y a pas beaucoup de choses à mettre en place. On va regarder comment l'activer, c'est quand même le point le plus important. Ensuite, on va jouer un moment, chercher des événements, et regarder les différentes informations qui figurent dans CloudTrail. On va aussi configurer des notifications lors de l'appel d'une API AWS. On le fera de deux façons : en utilisant CloudWatch et des alarmes, le mécanisme traditionnel, et en utilisant CloudWatch Events. On parlera des deux solutions, des différentes solutions partenaires qui existent pour faciliter l'analyse des logs de CloudTrail, et comme d'habitude, on répondra aux questions. Et comme dirait Sébastien, vive le Québec. Je suis bien d'accord avec ça. En avant !
Alors, CloudTrail est sans doute l'un des services les plus simples à comprendre. Ce que fait CloudTrail, c'est de journaliser en permanence l'intégralité des appels d'API qui sont faits à l'intérieur de votre compte AWS. C'est son unique rôle : logger, logger, logger. Tout au sein d'AWS est basé sur des API, que vous utilisiez la console, un SDK, la ligne de commande, CloudFormation, ou tout autre service qui manipule des ressources AWS. En enregistrant tout, qui a fait quoi, à quelle heure, sur quelles ressources, vous aurez une vue détaillée et extrêmement précise de ce qui s'est passé. J'ai compté la liste des services pris en charge par CloudTrail il y a quelques jours. Si ça a changé, vous trouverez la liste mise à jour sur cette URL. J'en ai compté 63, et les quelques services qui ne sont pas pris en charge sont des services assez particuliers. On peut dire sans trop de risque que tous les services dont vous avez besoin, l'immense majorité des appels que vous faites, sont enregistrés par CloudTrail.
À quoi va vous servir CloudTrail ? Nous sommes dans la Security Week, donc le point essentiel est de parcourir régulièrement ou, malheureusement, en cas d'incident de sécurité, les logs de CloudTrail pour comprendre ce qui s'est passé, à quelle heure, quel a été l'enchaînement des actions, etc. Cela sert à sécuriser l'infrastructure. Mais CloudTrail ne se résume pas à ce cas d'usage, même s'il est important. Comme je le disais, CloudTrail est aussi un excellent outil de debug. Avec l'ensemble des modifications apportées à votre infrastructure, vous pouvez utiliser CloudTrail pour comprendre pourquoi vous avez un problème de production. Le fameux "qui a touché à quoi" rappellera des souvenirs à de nombreuses personnes. Et puis, vous attendez 10 minutes, et comme par magie, ça se remet à marcher. Le problème est réglé, mais quelqu'un a fait une bêtise avec un droit qu'il n'aurait pas dû avoir, et on n'arrive jamais à faire un vrai post-mortem. Avec CloudTrail, on peut dire : "Tiens, là, on a fait ça, et 4 secondes après, on a eu un problème." La causalité est assez claire.
Il y a un dernier point important : l'aide à la conformité. Pour ceux qui sont soumis à ce genre de contrainte, il s'agit de prouver que vous faites ce que vous avez dit que vous feriez. Vous rédigez des processus, des documents, mais il faut prouver que c'est vraiment comme ça que les choses se passent. Sans un outil de logging centralisé comme CloudTrail, c'est relativement compliqué. Par exemple, avec les clés de chiffrement KMS, si vous voulez démontrer qu'une clé KMS n'est utilisée que par une application précise dotée d'un rôle précis dans un contexte précis, sans un outil comme CloudTrail, c'est compliqué. Là, il vous suffit de rechercher l'identifiant de la clé dans vos logs, de sortir le résultat à l'audition, et de dire : "Voilà, il y a eu cette semaine, ou depuis six mois, tant d'accès à la clé, toujours par la même entité autorisée." D'autant plus que CloudTrail est multicertifié, et donc le log CloudTrail vous servira de preuve pour démontrer que votre infrastructure fonctionne bien, comme vos processus.
Qu'est-ce qu'on trouve dans un événement CloudTrail ? On y trouve ce qu'on s'attendrait à y trouver : qui a effectué l'appel, quand (jour et heure), quelle était la nature de l'appel (quelle API précise a été appelée, avec quels paramètres), quelles ressources ont été utilisées (bucket S3, instance, etc.), et d'où l'appel a-t-il été effectué (adresse IP). Avec ça, on a toutes les réponses : qui, quand, quoi, et d'où.
Un point important à noter dans CloudTrail, et on le verra pendant les démos, c'est que CloudTrail n'est pas un système absolument temps réel. Quand un appel d'API est effectué, vous ne voyez pas sa trace dans les fichiers de CloudTrail en quelques secondes. Aujourd'hui, on est aux alentours de 10 minutes. Donc, quand vous appelez une API, il y a un délai de 10 minutes avant qu'elle figure dans un journal. On verra des solutions pour aller plus vite. Les fichiers peuvent être chiffrés, donc CloudTrail est intégré avec KMS. Il y a des informations assez sensibles à l'intérieur de ces données, et il ne s'agit pas qu'elles soient lues par tout le monde. Si vous le jugez indispensable, vous pouvez les chiffrer automatiquement avec KMS.
CloudTrail est disponible dans toutes les régions, y compris GovCloud aux US et les régions chinoises. Le coût de CloudTrail est de 2 dollars pour 100 000 appels d'API pour les management events. Les management events sont tous les appels d'API sauf les data events, qui sont les accès aux objets S3 que vous pouvez également journaliser (get, put, etc.). Les data events coûtent 10 cents pour 100 000 appels. S'ajoute à ça le stockage des logs dans S3, qui est au tarif habituel (3 cents par giga par mois pour US East et d'autres régions). Vous pouvez trouver tous ces prix en ligne. Je trouve ça économique, car il n'y a pas d'infrastructure à gérer, rien à mettre en place. Vous activez CloudTrail en cliquant sur un bouton, et ça log, ça log, ça log.
100 000 appels, est-ce que c'est beaucoup ou pas ? Ça dépend de la taille de votre infrastructure. 100 000 appels d'API dans votre compte devraient suffire à pas mal de monde. Je parie que si vous activez CloudTrail, même dans toutes les régions où vous êtes présent, votre facture ne dépassera pas quelques dollars par mois. Pour ce prix, vous avez la certitude de pouvoir remonter l'historique de tout ce qui s'est passé dans votre compte. Je trouve que ça donne une tranquillité d'esprit importante pour une facilité d'usage et un coût très raisonnables.
Comment met-on en route CloudTrail ? Si vous ne l'avez pas fait, ne le faites pas maintenant, mais après ce webinar, connectez-vous à la console, allez dans la console CloudTrail, et cliquez sur "activer CloudTrail". Je ne vois aucune raison de ne pas activer CloudTrail. Vous ne me direz pas que 2, 5, ou même 10 dollars si vous avez un trafic fou, posent un problème. Il n'y a aucun impact. Activez CloudTrail. Pourquoi ? Parce que CloudTrail est la boîte noire. Comme la boîte noire d'un avion, elle doit être active dès le début. Imaginez une boîte noire qui s'active 10 minutes après le début d'un incendie de moteur, ce n'est pas très utile. La boîte noire, on espère qu'elle n'est jamais nécessaire, mais le jour où on en a besoin, on espère qu'elle a tout enregistré depuis le début. L'historique des appels dans votre compte est une ressource précieuse, vous devez commencer à la construire le plus vite possible. Je vous incite à activer CloudTrail dans toutes les régions où vous avez de l'infrastructure AWS, et de le faire le plus vite possible. Vous oublierez que vous l'avez activé, et un jour, vous en aurez besoin et vous direz : "Julien avait raison, c'était un bon conseil."
Vous pouvez le faire dans la console. Il y a un gros bouton, tout simplement. Je ne peux pas vous le montrer car je l'ai déjà fait. Vous allez dans la console de CloudTrail, ouvrez-la, et vous verrez un gros bouton "Activer CloudTrail dans toutes les régions". Cliquez dessus, et c'est fait. Si vous voulez le faire programmatiquement ou sur une liste de régions plus restreintes, vous avez ce petit script qui vous permettra de le faire. Vous le faites une fois pour toutes. Vous pouvez aussi aller région par région et activer CloudTrail dans chaque région. Mon conseil est de ne pas vous compliquer la vie : allez dans la console, cliquez sur le bouton qui dit "je l'active partout", et on n'en parle plus.
Une fois que c'est fait, il faut créer ce qu'on appelle un trail, une piste d'audit qui va contenir vos logs. On va basculer vers la console. J'ai déjà cliqué sur le gros bouton qui dit de l'activer partout. Quand j'arrive, je vais recharger la page pour avoir les derniers appels. Dans cette console, je vois l'historique des appels qui ont été faits. Attention, vous voyez cette petite précision : ce que vous voyez est uniquement les 7 derniers jours. Vous ne voyez que création, modification, suppression. Pour les activités d'API en lecture seule, allez voir dans S3 ou dans CloudWatch Logs. Ne soyez pas surpris de ne pas voir vos get, discard, etc. La console ne présente que des événements qui modifient votre infrastructure.
Comment crée-t-on un trail ? Un suivi en français. J'en ai créé un ici qui s'appelle "All Regions" et qui va logger dans ce bucket chez moi, envoyé dans CloudWatch Logs, et qui va regrouper toutes les régions. Je vous conseille de faire de même, d'avoir un bucket qui centralise l'intégralité des opérations faites dans votre compte. Cela vous permet d'aller à un seul endroit, dans un seul bucket, pour chercher des informations. Un participant a suggéré d'utiliser Athena, ce qui est une excellente idée. Ce trail suit toutes les régions, inclut tous les services, ne chiffre pas les fichiers, et n'exige pas beaucoup d'informations. Si j'avais envie d'en créer un autre, je le nommerais "CloudTrail Webinar", inclurais toutes les régions, mais peut-être que je voudrais faire l'Irlande, créer un nouveau compartiment S3, que je nommerais "CloudTrail Irlande". Voulez-vous le chiffrer ? Si oui, il vous demandera une clé KMS. Je ne vais pas le faire. Activer une notification SNS pour chaque livraison de fichiers ? Non. Je vais créer. Qu'est-ce qu'il manque ? Ah oui, pardon, je n'ai pas mis de préfixe. Les noms de bucket S3 sont globaux, donc préfixez-les. Voilà, c'est fait. Grâce à ce suivi, je vais retrouver dans ce bucket l'intégralité des actions faites dans la région irlandaise. Ce n'est pas plus compliqué que ça.
Une fois que vous avez fait ça, l'objectif est évidemment de faire des recherches. Dans la console, vous pourrez chercher des problèmes opérationnels ou de sécurité. Vous pourrez chercher les événements des 7 derniers jours et uniquement ceux qui ont modifié votre compte. Pour le reste, on passera par l'analyse des données contenues dans le bucket. On pourra filtrer sur la plage de temps, le nom de l'utilisateur, le nom de l'événement, etc. On s'amusera à faire ça après.
Comment recherche-t-on dans la console CloudTrail ? Je vais aller dans mon historique d'appel. Là, je vois un certain nombre de choses depuis 7 jours. Je vais chercher, par exemple, si j'ai eu des actions faites par l'utilisateur root. Vous savez qu'on n'aime pas trop utiliser l'utilisateur root dans AWS. Si vous avez suivi le webinar IAM, j'ai dû le répéter 30 fois. On préfère avoir des utilisateurs nommés. Néanmoins, qu'est-ce qu'il y a là-dedans ? Est-ce qu'on a du root ? On a du root qui a fait quoi ? Regardons celui-là, create tags. C'est EC2 qui a créé des tags sur une instance qu'il avait créée. Voilà, j'ai un run instance ici qui correspond. En remontant, je vois que l'autoscaling d'EC2 a lancé une instance. Je vois l'identifiant de l'instance, le security group, le VPC, et je peux cliquer pour voir l'instance en question. C'est ma démo X-Ray créée par un template CloudFormation, donc c'est EC2 qui a lancé le service. Je me dis que comme j'avais tagué cette instance, c'est EC2 qui a lancé mon instance pour la démo X-Ray, donc pas de panique. Je vois l'ensemble des informations : qui a fait quoi, dans quelle région, sur quelles ressources, etc. Si je clique, je vois l'événement, c'est la même chose. On peut faire des recherches sur le nom d'utilisateur, la période, le type de ressources, etc.
Je peux aussi faire une recherche sur le type de ressources. Par exemple, qu'est-ce qui s'est passé sur S3 ? J'ai eu un truc bizarre. Les ressources S3 sont forcément des buckets. Je vois qu'il y a eu un delete bucket fait par Julien, peut-être pour préparer sa démo CloudTrail. Je vois le bucket, l'API, etc. Je pourrais chercher ce qui s'est passé sur EC2. Sur EC2, j'ai plus de choses. Qu'est-ce qui s'est passé sur les instances ? Je vois le run instance de tout à l'heure et que j'ai associé une Elastic IP sur une instance EC2. Vous pouvez même chercher le nom de l'événement. Si je cherche, par exemple, delete bucket, qui est le nom de l'API, je vois mes appels à l'API pour effacer mes tests successifs. Je pourrais chercher une ressource précise, par exemple, "jsim webinar bucket-8". Ce bucket était là, il est plus là. Il a été effacé par Julien à 2h22. Il faut lui demander pourquoi il a fait ça, parce que c'était une énorme erreur. Les identifiants de l'événement, etc. Vous avez compris, je ne passe pas trop de temps là-dessus, mais vous pouvez faire ça sur les 7 derniers jours. Si vous voulez aller au-delà des 7 derniers jours, il faut parcourir les fichiers S3 avec une application.
Voilà, donc un petit exemple. À chaque fois, je vous fais la démo et j'essaie de vous mettre des copies d'écran qui résument ce que j'ai fait. Comme ça, quand vous relirez vos slides plus tard, ça vous permettra de vous souvenir un peu de ce que j'ai fait sans forcément être obligé de regarder la vidéo. Bien sûr, on peut aussi le faire en ligne de commande. On peut lister les événements des 7 derniers jours, passer des attributs, et essayer quelques commandes pour voir si elles marchent. Vous pouvez utiliser les mêmes critères de tri et de filtrage que dans la console. On va essayer ça. On a une console, donc on va essayer. On va prendre cela parce que si je lui demande la liste complète des 7 derniers jours, ça va faire beaucoup. On va rien voir. Donc, là, je lui ai demandé la liste des événements effectués par route. Je vois du JSON par défaut. On va essayer un autre format pour voir ce que ça donne. J'utilise mes attributs exactement de la même façon et je retrouve sous forme de JSON ce qu'on a vu dans la console. Si je lui demande un output texte, est-ce que c'est... Ah non, c'est forcé. Ah si, je vois là... Il y a des ressources. L'événement lui-même est encore en JSON, et certaines ressources sont un peu plus lisibles. Le but est de les extraire et de les passer à un script ou une application qui va les filtrer. On va exécuter celle-là pour voir. On va lister tous les événements qui portent sur une instance EC2. Je vois les mêmes événements que tout à l'heure. Je vois que Julien a fait des choses sur Elastic Beanstalk qui a associé une adresse, une Elastic IP, à une instance EC2, etc. Vous avez compris. On peut évidemment le faire aussi avec les security groups. La syntaxe détaillée, vous la trouverez sur ce lien, comment définir les attributs, chercher les ressources, les utilisateurs, etc.
Passons à la fonctionnalité un peu plus intéressante qui est de dire que je veux être notifié sur certains types d'appels. Évidemment, quand vous avez des milliers d'appels d'API par jour, le but n'est pas d'être notifié de tout, mais il y a certaines choses que vous avez peut-être envie de surveiller. Par exemple, être au courant rapidement lorsqu'un événement prévu se produit. Je vais vous montrer une démo où j'envoie une notification quand un bucket S3 est effacé. On peut dire qu'un bucket S3 qui est effacé n'est pas anodin, et on veut être notifié pour s'assurer que ce n'est pas une fausse manipulation. On peut aussi surveiller des tendances, comme le nombre de tentatives de login ratées sur la console dans les 24 dernières heures. Cela peut être un indicateur que quelqu'un est en train de renifler votre sécurité, voire de vous attaquer. Il y a deux façons de le faire : utiliser CloudWatch Logs ou s'intégrer avec CloudWatch Events.
Dans CloudWatch Logs, on peut envoyer tous les événements d'un trail vers CloudWatch Logs, puis définir des alarmes sur ce qui se passe. Si vous faites ça, ça se fait en un clic ou un appel d'API. Attention, il y a un coût supplémentaire sur CloudWatch Logs de 50 cents par giga ingéré, plus le stockage S3. Le conseil que je peux vous donner est de ne pas envoyer l'intégralité de tous les logs de toutes les régions dans CloudWatch Logs. Si vous avez du trafic, ça peut être un coût supplémentaire inutile. Vous pouvez peut-être créer un trail qui surveille spécifiquement tel ou tel type d'appel ou dans une région précise pour n'être alerté que sur ça. La deuxième façon de le faire est de s'intégrer avec CloudWatch Events, ce qui vous permet d'être notifié de manière très réactive, soit par SNS, soit par un appel de lambda sur un appel spécifique d'API. On va voir les deux méthodes.
Quels événements faut-il surveiller ? Ce qui est vraiment critique en termes de sécurité, par exemple, la suppression de bucket S3, les modifications de groupes de sécurité, de VPC, les changements sur les stratégies IAM, les échecs de connexion, les échecs d'autorisation. Si ces événements se produisent avec une fréquence accrue, cela peut être un indicateur avancé d'une tentative d'intrusion. Il peut y avoir des sujets moins graves mais importants, comme surveiller le lancement de clusters, le lancement d'instances très coûteuses. Si quelqu'un lance une palanquée d'instances 8XL, cela peut vous coûter assez cher rapidement. En termes de contrôle de coût et de bonne gestion de vos dépenses, vous pouvez surveiller qu'on ne lance pas ce type d'instances de manière rationnelle et contrôlée.
Comment les configurer, ces fameuses alarmes ? La première étape est d'activer le transfert des données de CloudTrail vers CloudWatch Logs. Cela se fait facilement dans la console. Ensuite, il faut créer des alarmes dans CloudWatch. Des alarmes qui surveilleront le contenu de CloudWatch Logs et se déclencheront quand le contenu correspond à l'alarme. Pour vous simplifier la tâche, on a défini un template CloudFormation qui va créer en quelques minutes 10 alarmes prédéfinies que nous considérons comme importantes. Par exemple, les tentatives d'accès infructueuses sur la console, etc. Vous trouverez l'adresse en bas pour exécuter ce template. Vous prenez le template, vous le lancez dans CloudFormation, et en 5 minutes, vous avez ces 10 alarmes configurées qui vous enverront des notifications par email. Cela peut être un bon point de départ pour commencer à utiliser des alarmes et vous donner des idées pour aller plus loin. N'hésitez pas à faire ça.
Ce qu'on va faire maintenant, c'est en créer une en direct. On va configurer l'export de CloudTrail vers CloudWatch Logs, que j'ai déjà fait, sur la base de mon trail qui suit toutes les régions. On va créer un filtre de métrique, qui est une petite règle qui sera comparée au contenu de CloudWatch Logs. Ici, je vais surveiller l'effacement d'un bucket S3, et puis je vais associer à cette métrique une alarme qui sera déclenchée lorsque la règle est vraie. Dès que le filtre de métrique voit passer une opération de suppression de bucket dans CloudWatch Logs, il lancera l'alarme, et il y aura une notification associée. On va y aller. Vous trouverez dans les slides suivants les différentes opérations : exporter, créer un filtre de métrique, créer une alarme, et effectuer l'action qui déclenche l'alarme. On va déjà créer l'alarme et la métrique. Vous voyez, on revient sur mon trail. Il exporte vers CloudWatch Logs, donc ça, j'ai rien à faire. Je vois effectivement dans CloudWatch Logs, dans la console de CloudWatch, les logs que CloudTrail a envoyés. On va créer un filtre. On va utiliser une petite syntaxe, ne vous inquiétez pas, je vous ai mis le lien de la documentation. Quand EventName est égal à delete bucket, cette règle va s'appliquer. On va lui donner un nom, "delete bucket API". Il s'applique sur des logs, je fais créer. Il n'aime pas un nom de métrique. Il n'aime pas le tiret. On va l'appeler "metric-delete-bucket-API". Voilà, créer un filtre, et c'est tout. Ça va surveiller ce qui se passe en CloudWatch Logs, chercher les événements dont l'événement s'appelle delete.
Maintenant que j'ai fait ça, je vais créer une alarme. Je vais l'appeler "alarme-delete-bucket-api" et la faire sonner quand un bucket S3 est effacé. L'occurrence ici sera l'appel à l'API, donc dès que j'ai un appel à l'API, dès que la métrique est différente de 0 sur une période que je vais définir (une minute), on va faire la somme de cette métrique sur une minute. Dès que j'aurai un appel, la somme sera égale à 1, 2, ou 3 en fonction du nombre de suppressions de bucket que j'ai faites en une minute, et cela déclenchera mon alarme. Je vais mettre une notification par mail, une notification SNS que j'ai déjà créée. Quand en une minute j'ai au moins un delete bucket, ça m'enverra un mail. Je fais créer, et voilà. J'ai créé le filtre, j'ai créé l'alarme, et je dois l'avoir là. Pour l'instant, elle ne va rien faire parce qu'elle vient d'être créée.
Et donc maintenant, qu'est-ce qu'on va faire ? On va essayer de déclencher cette alarme, et puis après, je vous montrerai comment le faire avec l'API et CloudWatch Events. On reste là-dessus, on garde un CloudTrail ouvert ici. On n'ira peut-être pas au bout parce qu'il faut attendre 10 minutes pour que l'événement arrive, mais vous me croirez sur parole. Là, je vois par exemple que j'ai créé un nouveau trail et que je le vois dans CloudTrail. Les opérations de CloudTrail sont elles-mêmes dans CloudTrail. En avant, on va faire ça. On va faire AWS S3 MakeBucket "jsimwebinar-cloudtrail-1". Voilà, je crée un bucket et puis je vais m'empresser de l'effacer. Voilà, là, je l'ai effacé. Cet appel est enregistré, il va arriver dans CloudTrail d'ici une dizaine de minutes, sera envoyé à CloudWatch Logs, le filtre de métrique sera activé, il déclenchera l'alarme, et je vais recevoir un mail. Pendant que tout ça se passe, je vais vous montrer comment le faire d'une autre façon, avec CloudWatch Events.
On va aller dans CloudWatch Events cette fois. On va créer une règle, choisir la source de l'événement. La source de l'événement ici est un appel d'API AWS. On va regarder S3, chercher une bucket level operation, et spécifiquement delete bucket. Donc, quand delete bucket est appelé, qu'est-ce qu'il faut faire ? On pourrait appeler une lambda, mais là, je vais m'envoyer un SMS. Je viens d'en recevoir un. Vous voyez mon téléphone, je ne sais pas si vous l'avez entendu. Ça doit être mes livraisons de cadeaux de Noël. Ce n'est pas l'alerte encore, mais vous l'entendrez tout à l'heure. On va créer une alerte SNS, et je vais m'envoyer un SMS. Ok, ajouter SMS. C'est tout ce que j'ai à faire. Donc, lorsque l'API Delete Bucket est appelée, je vais recevoir un SMS. Je clique là-dessus, on va mettre un nom à la règle. Donc, "rule Delete Bucket API". On va envoyer un SMS à Julien quand un bucket S3 est effacé. Voilà, c'est tout. Je vais refaire la même opération. On va en créer un deuxième. On va créer un nom différent, comme ça, on verra bien. Donc, je crée un bucket, numéro 2. Je m'empresse de l'effacer. Et... Donc on ne va pas passer par CloudTrail pour ce deuxième appel. Et donc vous allez voir, ça doit aller assez vite. Vous allez entendre, alors vous ne pouvez pas voir le SMS que je reçois, mais vous devriez l'entendre. Vous devriez entendre la sonnerie d'ici une minute. Alors, quelle différence entre ces deux façons de faire ? On va attendre que les alertes arrivent. On va regarder ce qui se passe ici dans CloudTrail. Je doute qu'on voit déjà les événements, ça ne fait pas du tout 10 minutes. Voilà, vous voyez, on ne voit pas le Create Bucket. Donc ça, c'est le, je ne vais pas dire le problème, parce que ce n'est pas vraiment un problème, mais c'est le fonctionnement de CloudTrail qu'il faut bien comprendre, c'est qu'il y a une dizaine de minutes avant que l'événement arrive. Donc justement, dans quel cas est-ce que vous utiliseriez une alerte ? Je vais vous remettre le slide, comme ça vous voyez ce que ça fait quand l'alerte se produit. Donc là quand l'alerte va s'activer, mais je pense qu'on n'aura pas le temps de le voir, vous verrez, voilà, vous l'avez entendu ? Donc ça c'est CloudWatch Events. Donc ça c'est la deuxième manip, vous voyez ça a pris moins d'une minute. Donc là on n'est pas sur du temps réel, mais en moins d'une minute, sur un appel d'API dans votre compte, vous recevez une notification. Bon alors vous ne la voyez pas, je ne vais pas vous la lire parce que je pense que c'est Jason qui m'a écrit. Alors que me dit Jason ? Il me dit plein de trucs, il me dit que j'ai fait des LED buckets sur... J. Simon-Webinar-CloudTrail-2, c'est bien le deuxième. Merci Jason. L'utilisation de l'alarme CloudWatch va être plus lente, c'est-à-dire qu'entre le moment où vous faites l'action et le moment où vous recevez la notification, il va s'écouler la dizaine de minutes de CloudTrail qui doit recevoir d'abord cette notification, cet appel d'API. Ensuite, il va falloir que ça arrive dans CloudWatch Logs, c'est plutôt rapide, il faut que la métrique s'applique, il faut que la notification parte. On va dire 10-12 minutes. Vous voyez que quand on le fait avec CloudWatch Events, on l'a en, je ne sais pas, je n'ai pas regardé, mais une trentaine de secondes, c'est l'impression que ça a donné, moins d'une minute en tout cas. Donc vous allez me dire, la deuxième méthode est beaucoup mieux, pourquoi vous nous parlez de la première ? Alors la deuxième méthode, elle est rapide, mais vous voyez, elle ne permet de réagir qu'à un appel. C'est-à-dire que vous avez un appel d'API, une notif, un appel d'API, une notif, un appel d'API, une notif. Alors c'est très bien quand vous voulez surveiller un truc très précis et que vous voulez réagir même s'il n'y a qu'une seule occurrence d'appel. Mais par exemple, dans le cas où vous voulez surveiller les tentatives de login ratées sur la console, ça ne marche pas. Parce que vous avez des utilisateurs qui se trompent, qui mettent le mauvais mot de passe, etc. Donc vous n'avez certainement pas envie d'avoir un SMS à chaque fois que quelqu'un a mal tapé son mot de passe dans la console. Ce que vous avez envie de faire dans ce cas-là, c'est de dire, j'ai une baseline qui est de 10 tentatives ratées par jour, parce que 10 fois par jour, mes utilisateurs se trompent. Et puis si jamais ça passe à 20, c'est deux fois plus que d'habitude et c'est anormal. Et donc ça, avec CloudWatch Events, vous ne pouvez pas le faire puisque vous aurez une notification par appel d'API. Alors vous me direz oui, je pourrais le faire avec une fonction lambda qui est écrite dans DynamoDB, qui compte, oui bien sûr. Mais la façon la plus simple de le faire, ça serait d'utiliser la première méthode que je vous ai montrée, de définir une alerte dans CloudWatch et de dire, bon ici vous voyez sur le slide, j'ai un déclenchement quand la métrique est supérieure à 0 sur 1 minute, je pourrais avoir un déclenchement en disant si la métrique est supérieure à 20 par heure ou par 24 heures, à ce moment-là j'envoie une alarme. Donc quand vous voulez surveiller des événements unitaires avec une très bonne réactivité, je vous conseille plutôt d'utiliser CloudWatch Events. Si vous voulez surveiller des tendances, réagir à des seuils sur des durées de temps plus élevées, à ce moment-là, l'alarme CloudWatch est plus intéressante. Et le fait qu'il faille 10 à 15 minutes pour que l'alarme se déclenche, ce n'est pas très grave. Si vous surveillez sur des périodes de plusieurs heures ou de 24 heures, vous n'êtes pas à 10 minutes près. Voilà le conseil que je peux vous donner pour faire le bon choix et la bonne méthode. L'email de notification ressemble à ça. Voilà. Lui il est assez lisible contrairement au SMS que Jason m'a envoyé tout à l'heure. Là on voit qu'on a une alarme, un delete bucket a été effectué et donc j'ai le lien vers la console pour aller voir ce qui s'est passé. Voilà, ça c'est comment le faire dans CloudWatch Event, c'est ce que je vous ai montré. Je vous ai mis le slide pour référence. CloudTrail, vous voyez que finalement quand on reste dans les 7 jours, on peut très bien travailler avec la ligne de commande ou avec les API. Au-delà, il faut aller chercher, il faut aller fouiller dans S3, il faut développer des scripts, etc. Dans ce cas-là, l'utilisation de solutions partenaires qui s'intègrent à CloudTrail peut être une bonne piste, d'autant plus que certaines de ces solutions sont extrêmement connues, extrêmement répandues. J'ai déjà mentionné Datadog que beaucoup de gens utilisent en SaaS, Greylog, Splunk qui est également très très populaire, Logly et tous les autres aussi sont très bien. Toutes ces solutions là vont vous permettre d'ingérer des logs au format CloudTrail et de les parcourir, de les requêter, de les visualiser etc. Pour des gros volumes ou une utilisation très soutenue, c'est une bonne solution de se baser sur un de nos partenaires. On a aussi des partenaires de consulting qui vont vous proposer de l'intégration et du conseil, Second Watch qui est assez connu, notamment pour bâtir des solutions de monitoring complexes et extrêmement puissantes qui s'appuieront sur CloudTrail. Quelques ressources supplémentaires. Des white papers encore, pour aller au coin du feu, sur l'auditing, sur l'utilisation du logging dans la sécurité. Si vous avez des grosses problématiques d'audit et de compliance, ce sont sans doute les bons documents à lire. Deux sessions de re-invent qui parlent de CloudTrail, mais pas uniquement, qui parlent aussi d'autres outils, dont je ne parle pas cette semaine comme AWS Config en particulier, qui tourne autour de comment automatiser la compliance dans sa plateforme, comment réagir automatiquement à tout un tas de conditions. Je vous ai remis le lien Bitly vers les slides et les vidéos des webinaires que je mettrai à jour à chaque fois que c'est nécessaire au fur et à mesure que nous postons les vidéos. Voilà, merci beaucoup, j'en ai fini pour CloudTrail. Vous comprenez pourquoi j'en ai parlé plein de fois cette semaine, c'est vraiment un outil hyper précieux, c'est un outil qui est très simple à activer. On l'active, on n'y pense plus et puis le jour où on en a besoin, on le trouve et on est très content d'aller retracer l'historique de ce qui s'est passé dans le compte. On va, Hugo, je pense vous afficher le petit sondage de satisfaction, comme d'ailleurs, Je vous rappelle, 5 est la meilleure note, 1 la plus mauvaise, donc si vous êtes très content, 5. Si vous n'êtes pas content du tout, 1, et puis les autres valeurs en fonction. Voilà pour le petit sondage, vous avez l'habitude maintenant. Je crois qu'Hugo va vous partager les slides aussi, si ça n'est pas fait. De toute façon vous les retrouverez à l'URL que je vous ai indiquée et puis ensuite on répondra à vos questions. Voilà, on vous laisse voter encore quelques secondes. Merci. Ok, voilà, je pense que le sondage est pour les gens votés. Merci beaucoup, merci pour le feedback. Alors, commençons par les questions. Alors, peut-on désactiver CloudTrail ? Alors, on va retourner dans la console. Hop. Alors, attendez, je fais un petit peu de ménage à l'écran. Voilà. Donc, je vais prendre mon fameux trail qui contient tout. Alors, vous voyez, il y a ce bouton-là en haut, journalisation, on ou off et donc vous pouvez, oui vous pouvez tout à fait désactiver CloudTrail, ce n'est pas du tout un chemin sans retour. Même si, sincèrement, je vous conseille de le laisser, je ne vois pas vraiment de raison de ne pas activer CloudTrail. Après, effectivement on peut avoir envie de l'activer et puis on se rend compte que non, on n'en a pas besoin et on l'éteint. Voilà, une fois de plus. Je pense que c'est utile de l'avoir allumé. Est-ce que CloudTrail est certifié SOC ? Alors, on va regarder. J'avais la liste de certification sur un slide précédent. Oui, le voilà. Je vous le remontre. Voilà la liste des certifs CloudTrail. PCI DSS pour l'e-commerce. Toute la batterie ISO. Et SOC 1, 2, 3. Donc effectivement, pour des auditeurs, pour des audits SOC, CloudTrail est un atout important, me semble-t-il. Alors, question sur le coût de CloudTrail. Est-ce que le coût est par event ou par event suivi dans un trail ? Donc c'est par event suivi. Suivi dans un trail. Pour les appels d'API que vous n'auriez pas pris en compte dans CloudTrail, on peut remontrer peut-être la fenêtre de trail. Je pense que là j'ai pris tous les... Je n'ai pas de sélecteur d'événements, mais vous voyez je pourrais modifier celui-ci en disant je ne veux que les événements en écriture, je veux les événements de management, oui, donc là je n'ai pas les événements S3. On pourrait limiter le type d'événements qui sont ajoutés. Donc on pourrait ne suivre que quelques événements. Bucket, etc. Donc la facturation elle se fait sur ces événements-là bien sûr, sur les événements qui sont effectivement journalisés. Ceux qui sont ignorés par la journalisation ne sont pas couverts. Alors une question anonyme, les événements sont-ils détruits d'S3 automatiquement après 7 jours ? Non, non, non, non, non, non, non. Mais c'est vrai, je ne l'ai pas assez répété, donc on va aller dans S3. On va voir la nouvelle console S3, je ne sais pas si vous l'avez vue. Connectez-vous à S3 et vous pouvez choisir cette nouvelle console qui est sympathique, un peu plus jolie. Et donc je vois... je vois mon CloudTrail JCMont All Regions. Voilà. On va descendre un peu dans tous ces matchs-là. CloudTrail. Voilà, donc là, je vais voir toutes les régions. Donc là, j'ai plutôt joué dans EU West 1. Vous voyez, c'est hiérarchisé, tout ça. Ça, c'est les jours. Donc ça, ça doit même être les heures, ça, oui. Non, pardon, ça ce sont les jours, on est le 22. Voilà, et donc là je vois l'ensemble des événements. Donc tout ça, ça va persister jusqu'à la fin des temps, puisque S3 durera jusqu'à la fin des temps, comme tout le monde le sait, avec 99,9999 etc. de durabilité. Blague à part, donc, Donc l'histoire des 7 jours, c'est uniquement pour la console. Vous ne voyez dans la console que les 7 derniers jours et les événements en modification, en écriture en clair. Mais dans S3, tout reste. Alors, ça pose effectivement la question de se dire, oui mais bon jusqu'à quand ? Parce que la fin des temps, vous êtes gentil, mais moi ce qui s'est passé dans CloudTrail... il y a 5 ans, ça ne m'intéresse pas. Alors à ce moment-là, ce que vous pouvez faire, c'est définir, on va aller là-dedans, on va définir une règle de cycle de vie, ce n'est pas un webinar sur S3, mais on pourrait, on va définir un nom de règle, alors Purge CloudTrail, suivant, suivant, Et on va lui dire de faire expirer l'expiration. On pourrait lui dire tout ce qui a plus de 365 jours, tu me le vires. Donc ça va vous purger tous les événements qui ont plus d'un an finalement. Ou alors vous pourriez dire je l'émigre, Je les garde quand même parce que oui, ce qui s'est passé il y a des années, j'en ai besoin. Peut-être en termes d'audit, mes auditeurs me demandent de garder la trace de tout pendant 10 ans. Ok, c'est comme ça, je suis obligé de le faire. Maintenant, ce n'est peut-être pas la peine de le garder en ligne dans S3. Donc là, comme c'est des données qui sont dans S3, vous pouvez utiliser les règles de cycle de vie d'S3 pour soit purger, soit migrer vers S3, une fréquent access, voire classier les événements que vous n'avez pas besoin de garder en ligne. Est-il possible d'envoyer le flux CloudTrail sur un CloudWatch Log d'un autre compte AWS ? Ça c'est une bonne question et je ne sais pas. Je sais qu'on peut centraliser CloudTrail, on peut centraliser dans un bucket S3, est-ce qu'on peut l'envoyer sur un CloudWatchLog ? Écoutez, je ne sais pas, envoyez-moi un mail et je vais regarder. J'aime bien les questions auxquelles je ne sais pas répondre, comme ça vous aussi vous m'apprenez des choses. Alors, est-ce que la latence de 10 minutes va diminuer dans le futur ? Là aussi, j'ai du mal à vous répondre. J'aimerais bien avoir des informations là-dessus. Ça serait bien, ouais. Ça serait bien de pouvoir aller un petit peu plus vite. Là aussi, je suis persuadé que c'est dans une roadmap quelque part. Mais je n'ai pas malheureusement d'informations sur ce sujet. Alors on a aussi une question sur les certifications de CloudWatch, alors ça je ne sais pas, on va regarder. Généralement on trouve ça dans les FAQ des services. ... On va chercher, attendez, on aurait même pu chercher peut-être CloudWatch Compliance. Ça nous emmène loin. Généralement, c'est indiqué certif par certif, c'est à dire que quand on regarde certif par certif, on va avoir la liste des services. Oui, je ne doute pas que CloudWatch soit multi certifié. On va jeter un oeil à la FAQ. On va chercher ISO peut-être. Ah non, il n'est pas indiqué. Non, ce n'est pas indiqué dans la FAQ. Bon, elles ne sont pas toujours très homogènes. Je vais vous trouver ça, envoyez-moi un mail et je vais vous renvoyer la liste des certifs. Je suis sûr que c'est quelque part sur le site mais on ne va pas fouiller pendant 10 minutes. Mais CloudWatch, oui, est un élément important. Après, on a des questions sur comment on fait au-delà de cette est-ce qu'il y a, quelle est la bonne façon d'accéder aux logs et d'analyser les logs au-delà de 7 jours plutôt que de faire, parce qu'effectivement je suis assez d'accord avec vous, je pense que si je fais ça, mon ami Jason je l'aime bien, mais ça c'est indigeste et je ne peux pas travailler avec ça. Bon et puis ça une fois de plus ça n'est que 7 jours. Donc je pense que la bonne solution c'est… alors j'ai envie de dire ça dépend de ce que vous cherchez, c'est à dire que si vous cherchez un truc précis, il vaut peut être mieux le… alors vous pouvez aller le chercher dans S3 ou vous pouvez aller le chercher dans CloudWatch Logs, vous pouvez aussi en ligne de commande ou en SDK aller lister des événements dans CloudWatch Logs. Moi, je les extrairais et puis j'écrirais un petit outil ad hoc en Python pour aller me chercher ce que j'ai envie de trouver. Effectivement, l'utilisation d'Athena que j'ai déjà mentionné est une idée intéressante à condition d'avoir le mapping entre ça et la table SQL, donc ça mérite d'être creusé cette idée. Parce que là c'est typiquement des requêtes ad hoc qu'on a envie de passer sur des logs S3. Bon, sincèrement voilà, si je cherchais un truc précis, je pense que je scripterais en Python et puis j'irais chercher, je lirais dans mes fichiers S3, les deux dernières semaines, les événements jusqu'à ce que je trouve ce que j'ai envie de trouver. Après on peut déployer une créativité sans limite et puis prendre ces événements, les ingérer dans une base et faire tout un tas de traitements. Je pense que si c'est du ad hoc, un petit script ou effectivement peut-être un petit coup d'Athéna, si c'est votre job de faire ça, si vous êtes dans l'équipe de monitoring ou l'équipe d'audit, là il vous faut un meilleur outil et là il faut une solution partenaire. Donc là un et de toute façon vous l'avez probablement déjà pour les logs de vos applications donc un grey log ou un splunk ou un logly ou datadog si vous utilisez déjà datadog pour l'analyse et le monitoring me paraissent indispensables soit vous avez un besoin ponctuel et vous le faites vous même soit vous avez un besoin constant et je suis entièrement d'accord on ne va pas le gérer comme ça et on ne va pas le gérer avec des bouts de ficelle donc il faut un vrai. Là je pense qu'on est à court de temps, je vois Hugo qui me fait des grands signes, je pense qu'on a été complet. Il ne me reste plus qu'à vous remercier d'avoir participé à ce 8ème webinar. Je ne sais pas s'il y a des gens qui ont fait les 8 et qui comptent faire les 10, on regardera, ça mériterait de gagner quelque chose. Merci beaucoup de nous avoir suivis encore sur CloudTrail. Demain au programme, un autre webinar très concret, très pratique, assez rigolo sur l'audit de vos instances EC2 avec Inspector. Comment on scanne une instance, comment on scanne les packages, comment on cherche les vulnérabilités sur une instance et qu'est-ce qu'on fait après. J'ai une démo aussi assez rigolote sur le sujet, qui est sans doute un bon complément à CloudTrail. Et puis on conclura cette belle semaine avec un récapitulatif des bonnes pratiques de sécurité où on va essayer de rebalayer un petit peu les différents services dont on a parlé et de vous donner des conseils très très concrets, très très pratiques pour bien les utiliser. Bien les déployer et puis on va essayer de garder du temps pour les questions s'il y a effectivement pas mal de questions auxquelles on n'a pas eu le temps de répondre cette semaine on va essayer de cumuler un peu de faire un petit best-of des questions non répondues et puis d'y répondre demain et puis après il sera temps de s'arrêter et de prendre des vacances je crois voilà merci encore salut aux amis de l'étranger merci de votre présence merci pour tous les gentils commentaires qu'on a reçu dans le chat on y est très très sensibles Hugo et moi beaucoup de mots sympas et d'encouragement ça fait vraiment plaisir vous êtes super merci beaucoup, bonne soirée et j'espère à demain pour Inspector et les best practices ciao, bonne soirée