Fireside chat avec Matthieu Bouthors et Julien Simon

Transcript

Bonjour à toutes et à tous, ravi de vous retrouver pour ce troisième webinar de la Security Week. Après avoir parlé d'IAM et de KMS hier, nous allons mener un webinar un peu différent aujourd'hui, puisque vous n'aurez pas de slides. Je vous épargne une longue série de slides PowerPoint et les remplacer par une discussion que j'espère passionnante avec deux invités. Mathieu, bonjour Mathieu. Bonjour Mathieu Lauter de l'équipe AWS Professional Services. Merci de nous rejoindre pour ce webinar, et Nicolas. Bonjour Nicolas Neas, et merci de me recevoir pour ce webinar. C'est un plaisir. Alors aujourd'hui, vous l'avez compris, on va avoir une discussion au coin du feu et on va commencer avec Mathieu. Mathieu, tu fais partie de l'équipe Professional Services. Est-ce que tu peux en quelques phrases nous expliquer quel est ton rôle auprès des clients d'AWS ? Donc, mon rôle principal, c'est de travailler souvent chez le client, avec le client, et de l'aider dans son adoption, dans sa manière de commencer avec AWS ou d'aller un peu plus loin. C'est vraiment un rôle d'accompagnement, ce qui m'amène à avoir beaucoup de clients assez différents et de les aider à réaliser leur projet, plus particulièrement sur la partie sécurité. Alors justement, quels sont les grands types de clients ? Bien que tous les cas soient évidemment un peu différents, tu vois beaucoup de gens et quelles sont les grandes catégories de sociétés et de clients que tu rencontres ? Alors, c'est vrai que chaque client est différent, mais on voit un peu trois types de clients un peu différents les uns des autres. On va avoir le client qui va vouloir commencer sur AWS, ça peut être des clients dont toute l'activité sera axée sur le web, je pense par exemple à des clients comme Payplug qui va fournir des solutions de paiement sur internet. On va avoir d'autres types de clients plus régulés, des types de grandes entreprises par exemple dans le même domaine d'activité que Payplug, plus des grandes banques, que ce soit françaises ou européennes, où là on va avoir des problématiques de conformité. On ne pourra faire très peu tant qu'on n'aura pas prouvé la conformité. Donc là, on est dans une démarche un peu différente. On ne va pas faire que de la sécurité, on va s'assurer qu'on est capable de prouver et de fournir les bons éléments aux bonnes instances. Et puis, on va avoir aussi d'autres clients qui sont déjà utilisateurs d'AWS et qui veulent aller plus loin, qui veulent par exemple mettre en place des applications plus critiques, qui vont traiter des données personnelles ou des choses comme ça, ou qui veulent tout simplement optimiser un peu leur sécurité sur le cloud. Passons un peu de temps sur chacune de ces catégories de clients, je pense que ça permettra à nos auditeurs encore très nombreux aujourd'hui, merci beaucoup, de se reconnaître et de comprendre finalement quel est le chemin à adopter pour avoir un bon niveau de sécurité sur AWS. Est-ce qu'on peut commencer peut-être par Payplug, qui est une très belle société, une très belle réussite, représentative des boîtes qui commencent et qui se lancent. Alors parle-nous un peu de Payplug, de leurs problématiques de sécurité et des solutions qu'ils ont mises en place. Alors, Payplug a eu deux problématiques importantes. Il y a une première problématique, c'est que Payplug va traiter des paiements bancaires, donc à ce titre-là, il doit avoir un certain nombre de certifications, en particulier PCI DSS. Dans ce cadre-là, ce que Payplug a pu faire sur AWS, c'est tout d'abord reprendre sur la partie sécurité physique, sécurité du data center, tout ce qui avait déjà été fait et audité côté AWS, donc ça a moins à faire de leur côté. Il faut noter que quand Payplug a commencé sa démarche de certification PCI DSS, il était composé de 5 personnes. Les auditeurs en face avaient un peu de mal à... avaient peu de retour d'expérience de clients similaires de cette taille-là qui arrivait à être certifiés. Le deuxième point où ils ont réussi sur cette certification, c'est de reprendre des services de sécurité d'AWS, de reprendre toutes les capacités d'automatisation, de reprendre l'auditabilité par exemple d'un CloudTrail qui va nous donner tous les logs de tous les accès API, simplifiant ainsi la mise en place des mesures de sécurité qui restaient de leur côté du modèle de sécurité partagé. Et donc grâce à ça, ils ont pu, alors qu'ils n'étaient que 5, réussir à faire certifier leur plateforme. Le deuxième point, un point qu'on voit assez souvent, c'est l'anti-DDoS. Donc maintenant, on a AWS Shield. AWS Shield, très bien... Quand on parlera, je crois, jeudi, sauf erreur. Oui, c'est ça, dont Julien parlera jeudi. Il y a toute une stratégie sur des DevOps un peu plus compliquées. On va designer l'infrastructure de manière à ce qu'elle soit résiliente à toutes ces attaques volumétriques. On peut préciser que Payplug a passé avec succès sa certification PCI DSS Service Provider. Je crois qu'ils ont été aussi agréés par la CPR. Ils ont été agréés par la CPR comme établissement de paiement. Ce qui est pour une startup quelque chose d'extraordinaire. Ce qui est assez intéressant puisque ça leur donne une licence, donc c'est un premier niveau de licence bancaire. Tout à fait. Donc voilà un bel exemple d'une société, d'une jeune pousse, d'une startup qui s'appuie sur AWS et le niveau de sécurité qu'offre AWS pour atteindre les niveaux de conformité les plus élevés de l'industrie bancaire française. Alors, justement, ça fait la transition pour parler du deuxième type de client que tu mentionnais, les clients, on va dire, type CAC 40, qui sont dans des industries fortement régulées, souvent en environnement hybride, avec de très fortes contraintes de sécurité. Est-ce que tu peux nous parler un peu de ces clients et de leurs problématiques ? Alors, sur le site de clients, oui, c'est vrai que sur les grosses entreprises, que ce soit au niveau français ou européen, généralement on va arriver dans des secteurs régulés, que ce soit la banque, que ce soit le domaine de l'industrie ou de l'énergie, on aura toujours un certain nombre de contraintes. L'avantage en général c'est que ces contraintes sont déjà connues, le client travaille déjà sur la base de ces contraintes, sur les infrastructures qui existent en data center. Et là quand on va préparer une migration, quand on va préparer le passage de certaines de ces charges côté cloud, on va beaucoup travailler sur la cohérence entre l'existant et la partie cloud. Donc par exemple, pour tout ce qui est gestion des identités, on va aller sur des systèmes de fédération. Plutôt que de recréer, Julien a parlé hier d'IAM, plutôt que de recréer individuellement des utilisateurs IAM, on va juste prendre par exemple l'Active Directory qui existe chez le client. On va fédérer ce mécanisme d'identification et comme ça on a un seul point d'entrée, une seule base des identités internes. Donc on sait qui est administrateur, quels sont les droits pour chaque personne, que ce soit sur la partie data center ou que ce soit sur la partie cloud. Tu parles de fédération, j'en profite parce qu'effectivement j'en ai parlé hier, c'est un point important, assez complexe finalement à comprendre et on essaie de le rendre simple, si j'ose dire, à mettre en œuvre. Est-ce que tu as quelques conseils à donner ou quelques retours d'expérience sur des fédérations avec SAML par exemple qui semble être le plus courant en ce moment ? Alors, le premier point, le premier conseil que j'ai à donner, c'est que oui, ça peut paraître plus simple au début de créer des utilisateurs IAM, de ne pas mettre en place un mécanisme de fédération. Créer un utilisateur est une problématique assez simple. On crée un utilisateur, l'utilisateur quand il a besoin d'un accès, il va le demander, on lui créera son utilisateur. Tout ce qui est la gestion des départs, c'est tout de suite beaucoup plus compliqué. Tout ce qui est la gestion de plusieurs bases d'utilisateurs, est-ce qu'elles sont bien synchronisées ou autre, c'est une problématique différente. Et c'est là que ça vaut le coup d'investir un peu de temps pour mettre en place une fédération. Quand on va mettre en place une fédération SAML, on n'aura pas besoin d'avoir un lien réseau ou autre entre l'Active Directory, par exemple si on utilise ADFS, et Amazon Web Services. On va juste s'échanger des clés publiques qui seront associées à des clés privées qui vont permettre de signer des assertions. Et de ce fait-là, on va pouvoir assez rapidement mettre en place cette fédération. On a pas mal de blog posts qui vont vous expliquer pas à pas sur le blog AWS comment le faire et de la documentation qui vont aider nos clients. Donc souvent, on se rend compte que c'est plus simple à mettre en place que ce qu'on a anticipé. D'accord, c'est une bonne nouvelle. Effectivement, j'ai intégré hier sur les slides que vous pouvez trouver sur le Twitter AWS Actu ou sur mon Twitter Julien Simon, j'en profite parce que tout le monde m'a posé la question ce matin. J'ai mentionné sur les slides ces fameux blog posts qui effectivement sont plutôt bien faits puisque je pense avoir compris, c'est généralement un bon indice. Il nous reste un dernier type de client à évoquer rapidement qui est le troisième type, donc le client qui est déjà dans AWS et qui souhaite optimiser ou industrialiser sa sécurité dans AWS. Quels sont les points clés que tu rencontres souvent chez ces clients ? Souvent, en fait, on va vouloir être plus efficace. Donc par exemple, on va aller beaucoup sur tout ce qui est templatisation, automatisation. C'est-à-dire qu'on déploie une première application sur AWS, on met un certain nombre de mesures de sécurité, on va chiffrer certaines données, on va faire du contrôle d'accès, on va logger les informations nécessaires, on va filtrer les flux réseau avec des security group, monitorer le réseau avec des VPC Flow Logs, et ainsi de suite. On va faire une deuxième application, on va refaire pareil, et ainsi de suite. Puis on se dit, là on va voir une autre application, on voudrait peut-être monitorer un peu plus parce qu'on a un peu plus de... par exemple des données personnelles, donc on va pouvoir mettre un niveau supplémentaire, c'est une première chose. Mais ce qu'on voit souvent aussi, c'est qu'il y a un modèle qui se répète et si on veut être efficace, on a tout intérêt à automatiser plutôt que de refaire quasiment la même chose à chaque fois avec éventuellement des erreurs humaines parce que tout le monde, que ce soit ici ou ailleurs, tout le monde est faillible et dès qu'on va être sur des manipulations par des humains, on aura des erreurs à un moment ou à un autre. Là où le fait de, par exemple, prendre ne serait-ce qu'un template CloudFormation et de dire on reproduit 10 fois le même template, on lance 10 fois le même template, on aura 10 fois le même résultat. Après, il faut toujours auditer le template et il faut toujours s'assurer qu'on n'a pas une erreur humaine dans l'écriture du template. C'est sûr. Mais on a plus ce facteur 10 sur les possibilités d'erreur. Et on gagne du temps. Je crois que c'est vraiment un bon conseil. C'est un point qu'on n'a pas abordé hier, mais le rôle que l'automatisation et des outils comme CloudFormation peuvent jouer aussi dans, pas juste l'automatisation de l'infrastructure, mais aussi l'automatisation de la sécurité. C'est effectivement un très bon conseil. Passons à un autre sujet. Je pense que c'est sans doute la question numéro un qu'on nous pose aujourd'hui, à Mathieu, à moi, quand je participe à des meet-ups ou des conférences, sans doute à beaucoup de gens qui sont à AWS, qui est le fameux sujet de la localisation des données, qui est une question importante pour tous nos clients, une question qui est très légitime et je voulais absolument qu'on l'aborde aujourd'hui. Donc Mathieu, est-ce que tu peux nous expliquer ? Je suis un client AWS, où sont mes données ? Qu'est-ce qui se passe avec mes données ? Oui, alors c'est très simple. En tant que client AWS, à chaque fois que je vais devoir déployer une ressource, que ce soit par exemple un bucket S3 pour y stocker des objets, que ce soit une instance virtuelle EC2, je vais choisir une région AWS. Une région AWS, aujourd'hui en Europe, on en a trois. On a une région en Irlande, une région à Londres et une région à Francfort. Londres qui est toute récente. Et l'année prochaine on aura une région en France dans la région parisienne. À chaque fois qu'on va choisir une région, les données resteront dans cette région-là. C'est-à-dire que nous on va utiliser de multiples data centers qu'on va séparer dans ce qu'on appelle des zones de disponibilité. Par exemple sur la région de Dublin qui est en Irlande, on va avoir trois zones de disponibilité différentes. Une zone de disponibilité c'est un ou plusieurs data centers, mais on restera dans la région de Dublin. Tout ce qui va être durabilité de la donnée, le fait de copier plusieurs fois la donnée dans plusieurs data centers différents pour éviter de perdre de la donnée, on va le faire à l'intérieur de la région. Donc quand on va envoyer une donnée sur la région Dublin en Irlande, on ne quittera pas l'Irlande. Si on envoie la donnée à Londres, on restera en Angleterre. Si on envoie la donnée à Francfort, on restera en Allemagne. On n'est pas forcément dans le périmètre de la ville de Francfort, on est dans Francfort et les villes environnantes, pour s'assurer qu'on a des data centers qui sont sur des profils de risques différents, que ce soit sur des risques environnementaux, alimentation électrique et réseau. Par contre, on restera dans cette région-là. Est-ce que AWS déplace mes données ? AWS ne va pas déplacer les données des clients. On a d'ailleurs pour nos clients européens ce qu'on appelle le Data Protection Addendum. Le Data Protection Addendum, c'est un ensemble de clauses standards qui ont été validés par le Working Group 29 de la Commission européenne, donc en charge des données personnelles. Et donc ces clauses standards vont définir les différents traitements possibles ou pas côté AWS. Et donc en particulier, on va définir que le seul cas où on pourra éventuellement sortir des données d'une région, ce serait dans le cadre d'une réquisition judiciaire, dans un cadre qui est totalement légal et contrôlé par l'autorité judiciaire du pays. On en parlera tout à l'heure, j'ai aussi ces questions dans la liste. Alors ça c'est pour l'Europe, mais si je mets les données aux États-Unis, on sait que c'est là aussi une question qui revient souvent, qu'est-ce qui se passe ? Et qu'ils ne trompent pas les États-Unis aussi. Donc par exemple, un client européen qui va avoir une infrastructure pour ses utilisateurs américains préfère aussi que les données restent aux États-Unis. Ensuite, sur tout ce qui va être l'export de données entre l'Europe et les États-Unis, via le Data Protection Addendum dont je parlais, et via Privacy Shield, sur lequel... qui est la démarche, qui a remplacé l'ancien Safe Harbor pour être précis, on va pouvoir exporter les données dans un cadre contrôlé reconnu des deux côtés. Ok, c'est très clair. Donc je pense qu'on a, j'espère, bien répondu sur les aspects de localisation des données. Donc on ne sort pas de la région dans laquelle le client lance son infrastructure et place ses données. On est très heureux d'avoir la région France qui arrive l'année prochaine. D'ailleurs, je peux vous communiquer la date en exclusivité, ce sera entre janvier et décembre. Oui, qu'est-ce que vous croyez que j'allais me faire avoir ? Et il ne s'agit pas juste de la bonne parole de Julien et de Mathieu, il s'agit d'AWS et de son engagement démontré, validé par le DPA auprès des autorités européennes. Donc il y a le DPA sur la partie engagement légal vis-à-vis des autorités européennes et après on a un certain nombre d'audits par des tierces parties, donc par exemple sur des standards comme ISO 27001, comme SOC, et c'est donc sur ces audits-là, par exemple si je prends l'exemple d'un SOC, un SOC on va avoir des auditeurs qui vont venir nous voir tous les 6 mois et qui tous les 6 mois vont nous demander les preuves que ce qui est demandé par le standard, les points sur lesquels on s'est engagé, fonctionnaient bien sur les 6 derniers mois. Donc ce n'est pas juste un auditeur qui va venir à l'instant T vérifier comment ça se passe à l'instant T, l'auditeur va venir tous les 6 mois vérifier comment ça s'est passé pendant les 6 derniers mois. Une question qui revient aussi souvent, j'en profite, sur les audits, c'est comment je peux avoir accès au rapport d'audit. Donc aujourd'hui pour avoir accès à la plupart des rapports d'audit, par exemple SOC 3 qui est un rapport assez résumé, on va aller directement sur le site web, pour la plupart des rapports d'audit c'est des données qu'on communique dans le cadre d'un non-disclosure agreement. Et aujourd'hui en fait, enfin depuis quelques semaines c'est très simple, il suffit d'aller dans la console AWS, d'aller dans la partie Compliance Report. Je ne me souviens plus comment il est dans la console en français, désolé. Il doit s'appeler Compliance Report. Et donc là, on va pouvoir demander l'accès à ces rapports d'audit. On a un non-disclosure agreement à valider parce que ces audits contiennent quelques informations sur la manière dont on fait de la sécurité, sur quelques informations internes sur l'administration. C'est la manière dont on opère côté AWS. Et donc, on peut en tant que client avoir accès à ces différents rapports d'audit. Ok. Je rappelle l'URL, aws.amazon.com. KMS, on a parlé de chiffrement et qui dit chiffrement dit clé et j'ai parlé de la confiance qu'on pouvait avoir dans KMS. Je voudrais profiter de ta présence pour rediscuter de ces sujets-là. J'ai reçu beaucoup de questions hier aussi à ce sujet, je les ai gardées en réserve. Donc allons-y, est-ce que tu peux nous parler de la façon dont les clés principales, les clés des clients, sont protégées dans KMS. C'est vraiment un point essentiel pour tout le monde. Passons un peu de temps là-dessus. Donc, ce qu'il faut bien voir sur le design de KMS, on va avoir une hiérarchie de clés. Donc, on va avoir une première clé dont tu as dû parler hier, qui est la clé de données, qui est différente pour chaque type de données. Par exemple, sur S3, chaque objet a une clé différente. Derrière, on va avoir ce qu'on appelle une « Customer Master Key ». Donc, c'est une clé maître où chaque client va avoir généralement plusieurs clés maîtres et chacune de ces clés va chiffrer, déchiffrer les clés de données. Et après, on va avoir des clés qui vont chiffrer ces clés maîtres et ainsi de suite côté Amazon. Toutes les opérations chiffrées vont être opérées sur ce qu'on appelle des hardware, des Hardware Security Modules (HSM). Donc c'est des appliances qui sont totalement agnostiques, c'est-à-dire que si on les reboot, elles n'avaient aucune donnée cryptographique sur du volume de stockage, disque dur, SSD ou autre. Et toutes les opérations sur les clés, chiffrement, déchiffrement, vont être effectuées en RAM. Donc on a ces machines-là, bien entendu, on les met en cluster pour ne pas perdre de clés clients. Et ensuite, on va s'appuyer sur différents mécanismes, par exemple des HSM, pour s'assurer de la durabilité des clés qui vont chiffrer le haut de cette hiérarchie de clés. Sachant que si on doit stocker, par exemple quand on va stocker les clés clients, on va les stocker chiffrées. On ne va jamais stocker des clés déchiffrées sur des disques durs ou autres. Je crois qu'on a un livre blanc qui est le détail, on n'a pas le temps d'évoquer tout le contenu évidemment. On a un livre blanc qui s'appelle KMS Cryptographic Details qui va en parler plus longuement que moi, qui est une très bonne lecture. Si vous avez un peu de temps, en anglais. Donc si vous vous ennuyez pendant les fêtes, n'hésitez pas. Oui, effectivement, c'est une bonne lecture au coin du feu là aussi. Alors, une autre question importante, on comprend bien que le KMS est implémenté de manière à ce que les clés soient le plus protégées possible, mais néanmoins, qu'est-ce qui empêche qu'une unique personne chez AWS d'accéder à mes clés ? Bien entendu, on a des humains qui vont administrer cette solution. La bonne nouvelle pour tout le monde, c'est que tout à l'heure, je parlais un peu d'automatisation de la sécurité. Chez nous, c'est obligatoire. AWS a plus d'un million de clients et donc de ce fait, on s'est... se doit d'automatiser pour que pour fonctionner à l'échelle, on ne peut pas embaucher des administrateurs aussi rapidement que la taille des architectures grossit. Ce qu'est les équipes, c'est toujours aussi difficile. Donc la plupart des actions vont être automatisées. Dans certains cas, pour du débugage ou autre, on peut avoir éventuellement des actions humaines. Dans le cadre de KMS, et ça c'est un des points sur lesquels on est audité, donc je vous invite à lire le rapport SOC 1, si vous voulez plus de détails là-dessus, on va aller où on parle de ces points-là de manière très précise. On a mis en place un système de quorum qui fait qu'aucune opération peut être effectuée sur KMS sans avoir un nombre minimum d'intervenants. Ce qui fait qu'un administrateur malicieux ou autre, chez Amazon ne pourra pas effectuer d'opérations sur du matériel cryptographique de KMS. Il ne pourra pas récupérer des clés, que ce soit les clés utilisées en haut de la hiérarchie clé par Amazon, que ce soit des clés clients. D'accord. Et puis j'imagine que de toute façon il y a une chaîne d'audit qui trace tout ça ? Oui, l'ensemble des opérations sur KMS pour le développement. Même des opérations qui ne sont pas forcément effectuées directement par un utilisateur AWS vont être loguées dans CloudTrail. Par exemple, vous lancez une machine virtuelle qui était chiffrée avec KMS, vous allez avoir dans CloudTrail l'information que C2 a demandé l'accès à la clé pour lancer le déchiffrement du volume EBS concerné. Donc effectivement les mécanismes, je n'ai pas encore parlé de clé externe, enfin brièvement hier, et ça s'applique aussi évidemment en interne. Nos propres équipes sont soumises aussi à ces chaînes de bout en bout. C'est ça, voilà, exactement. Alors là on a parlé des clés, on n'a pas parlé des instances aussi. J'imagine que ce que tu dis effectivement, l'automatisation à outrance, ça s'applique aussi sur EC2, mais j'imagine que de temps en temps, là aussi, on doit faire des opérations manuelles sur EC2. Comment ça se passe ? Alors déjà, je vais me permettre de partager un chiffre qui a déjà été… enfin, certains ont peut-être déjà entendu pour ceux qui étaient à l'Enterprise Summit à Paris, par exemple, cette année. Notre RSSI, notre responsable global de la sécurité informatique, donc Steven Schmitt a donné cette année aux équipes un objectif de réduire de 80% les actions non automatisées. C'est-à-dire qu'il y a un certain nombre d'actions qui sont automatisées, puis il y a certaines actions de débugage qui ne sont pas toujours automatisées. Et s'il a eu 80%, il n'a pas cherché de savoir est-ce que c'est un objectif simple à atteindre ou pas. Il a dit à 80%, voilà le chiffre ! De 80% des accès non automatisés, on n'est pas juste en train de dire on en fait un peu moins. On est obligé d'automatiser quelque chose qu'on n'avait pas encore automatisé. Donc ça veut dire que les équipes ont automatisé les processus de débugage, ont automatisé des choses qui étaient encore un peu manuelles. Parce que pour atteindre un objectif à 80% de baisse, on est obligé d'y aller à ce niveau-là. Oui, on est obligé de taper dans le dur. Il n'y a pas de problème. Non, ça peut arriver quand le client est AWS, vous ouvrez un ticket au support, il y a une action de débugage, donc quelqu'un va accéder. Alors, comment c'est tracé ça ? Donc on va avoir dans nos outils internes tout un process de change management qui va être tracé. La personne du support avec qui vous discutez ne pourra pas le faire toute seule, elle va devoir demander un certain nombre d'approbations avant d'avoir l'accès. Ce processus d'approbation peut être très rapide. Mais il y a forcément plusieurs personnes qui se sont impliquées. La personne va se connecter à la machine, va lancer ses commandes. Et là, comme elle va avoir lancé des commandes sur une machine privilégiée sur une machine qui est dans un périmètre client. Ces actions-là sont loguées et tous les matins, donc Steven Schmitt, notre RSSI, va recevoir la liste de ses commandes. Et c'est une liste très courte qu'il a le temps de revoir tous les matins. Ça fait un ou deux écrans sur son téléphone quand il la lit le matin. Alors, j'ai travaillé avec Stéphane pour sa keynote à l'Enterprise Summit, j'espère que vous l'avez vu, je trouvais que c'était plutôt réussi. Et effectivement, pour ne rien vous cacher, on a abordé ce sujet et il a sorti son téléphone de sa poche et il m'a montré ce fameux mail qu'il reçoit tous les matins. Effectivement, on a le détail de qui a fait quoi, sur quelle instance et je peux garantir qu'il le lit. Et il m'a confié que de temps en temps, quand il y a quelque chose qu'il ne comprend pas ou qui il n'aimait pas, il se dépêchait d'intervenir sur le sujet. Donc voilà, c'est une réalité, le Chief Security Officer d'AWS vérifie tous les matins ces listes d'actions et effectivement elle est très courte, on ne parle pas de centaines d'actions, on parle de tout petit nombre d'actions. Et c'est là que c'est impressionnant puisqu'on a une infrastructure à l'échelle pour plus d'un million de clients et à la fin la partie actions privilégiées non automatisées on arrive à quelque chose qui reste manageable par un humain. Alors pour conclure sur cette liste de questions et vraiment je tiens à te remercier beaucoup Mathieu d'accepter de répondre à ces questions qui sont complexes. La question qui revient aussi de temps en temps c'est qu'est-ce qui se passe quand une autorité judiciaire veut accéder à du contenu d'un client en double net ? Alors, c'est très simple. On va répondre, on va d'abord challenger la requête. Donc, nos avocats vont s'assurer que la requête est bien valide, vont challenger la requête. On va communiquer au client dès lors qu'aucune loi nous interdit de le faire. On a quelques cas assez spécifiques où on n'est pas autorisé à communiquer au client. Dans pas mal de cas, on va pouvoir communiquer au client. Et donc, en fonction de la réponse quand on va challenger cette requête, quand on va challenger la légitimité de la requête, soit la requête était bien valide. Donc on va, entre guillemets, s'exécuter et fournir la donnée. Ce qu'on voit assez souvent, c'est que le périmètre de l'enquête est réduit. Donc on va donner une réponse partielle. On va répondre partiellement à l'enquête initiale. Et dans certains cas, on va ne fournir aucune donnée. Donc ces points-là, ce sont des points qui sont présents dans notre Transparency Report qui est disponible sur notre site. Il n'a même pas besoin de se loguer sur sa console ou autre. Pour le coup, il est directement sur le site internet. Il y a jour tous les six mois. Et on a le détail des chiffres, du nombre de requêtes reçues, du nombre de requêtes sur lesquelles on n'a rien répondu. On a répondu partiellement, on a répondu totalement. Chiffre qui est étonnamment faible. Je vous laisserai aller consulter. Vous cherchez AWS Transparency Report dans Google, vous le trouverez. Ça va dépendre de la manière dont elle est chiffrée. Si toute la donnée, par exemple, qui va être chiffrée, Clary-Anne-Sahak, qui va être chiffrée avec des HSM ou autre, AWS n'ayant pas accès à la clé de chiffrement, on donnera la donnée chiffrée sur la requête et on aura probablement une autre requête directement dirigée sur l'utilisateur pour la partie des chiffres. Là, malheureusement, heureusement ou malheureusement, j'ai envie de dire que ce n'est plus le problème d'AWS. Dans tous les cas, AWS se doit de respecter la loi des pays dans lesquels il opère et donc on se doit de répondre à ses requêtes quoi qu'il arrive. Absolument. J'espère qu'on a fait le tour des questions que vous pouviez avoir sur ces sujets qui sont compliqués, mais qui doivent être abordés et je tenais absolument à le faire aujourd'hui pour que vous puissiez en connaissance de cause et avec la tranquillité d'esprit nécessaire que vous puissiez utiliser les services. Si je peux me permettre d'en ajouter un petit point pour conclure sur cette partie protection des données, protection de la confidentialité des données. On a un utilisateur, enfin on a un client un peu particulier qui s'appelle The Guardian, qui est un journal presse-écrite britannique qui a été impliqué, qui a sorti quelques révélations assez consternantes à certains moments, et donc qui est aussi un utilisateur de la plateforme AWS et qui considère aujourd'hui qu'ils sont plus à même de protéger la confidentialité de leurs sources sur la plateforme AWS qu'ils étaient à même de le faire sur leur data center initialement. Alors quand tu parles de consternantes, tu parles de ce qui a été révélé par Edward Snowden, par exemple. Ok, histoire qu'on sache de quoi on parle. Et on s'arrêtera là. Très bien, merci beaucoup Mathieu. Je vais laisser Nicolas nous parler un petit peu de ce que fait Gemalto dans le domaine et puis on va continuer la discussion. D'accord, merci Julien. Merci. Effectivement, ça fait tout de suite écho pour moi tout ce que vient de décrire Mathieu. La protection des données, le contrôle des clés, le chiffrement, c'est notre credo chez Gemalto, dans mon entité Identité Data Protection. Donc on a une gamme de solutions qui vient effectivement s'intégrer dans AWS, ou autour d'AWS, compléter certaines des services d'AWS même. Et la première qui me vient en tête, c'est d'ailleurs à ce que tu mentionnais hier dans ta présentation sur le chiffrement de données, dans le client-side encryption, c'est donc le fait de pouvoir posséder sa clé et de chiffrer la donnée dans son application, dans son entreprise ou sur son serveur EC2 avant de la pousser dans un volume ou S3. Eh bien Gemalto a une solution ProtectApp qui vient se combiner avec les SDK Amazon pour fournir ce Client & Encryption et ce ProtectApp qui est une sorte de connecteur disponible, qu'on peut intégrer dans des serveurs EC2 comme des serveurs chez soi, va se connecter à notre key management, le SafeNet Virtual Key Secure, qui est lui aussi disponible sur Amazon, sur la marketplace Amazon, tout à fait, et qui va venir donc offrir une sécurité certifiée, FIPS, pour la sécurité de cette CMK dont parlait Mathieu tout à l'heure, cette question de master key, qui viendra elle-même protéger les clés de données. Donc, l'utilisateur avec ses fenêtres virtuels qui sécurisent et protègent peut protéger ces objets, on est poussé sur S3, tout en gardant un contrôle de la clé dans ses solutions. Pour les personnes qui étaient présentes hier, au webinaire KMS, souvenez-vous, quand j'ai commencé par parler de l'incursion côté client, en disant que pour tout un tas de raisons, ça pouvait être une solution extrêmement self-taïsée, à la réserve près qu'effectivement, il faut gérer sa propre infrastructure de clé, probablement sur site et également côté AWS. Et donc, voilà, ça c'est une zone où AWS en tant que telle ne peut pas vous aider, mais où effectivement une solution telle que la vôtre est tout à fait adaptée avec un niveau de sécurité élevé. On parle de FIPS, c'est loin d'être une plaisanterie. Non, exactement. Non, non, bien sûr, et ce qu'on cherche à faire, et tu viens de citer un petit peu de règles d'or chez Gemalto, qu'on répète sans cesse à l'ensemble de nos clients, bien sûr, c'est de gérer ces données, de les protéger et de contrôler ces clés de chiffrement. Sans ces clés de chiffrement, bien sûr, le chiffrement ne vaut rien. Donc, voilà, toutes ces solutions et ce virtual net KeySecure vient ici aider dans cette gestion de clés. Donc, on va parler d'un protectable qui pourrait venir protéger avec le SDK d'Amazon le chiffrement de données sur S3, sur EC2. On a du protectable un connecteur qui vient lui chiffrer l'instance EC2 et les volumes attachés à cette instance sur le BS directement. Voilà, d'autres connecteurs, on peut les citer, qui viennent graviter autour de ce SafeNet Virtual Key Secure, qui en plus de cette qualification FIPS, ajoute une donnée intéressante, c'est son intégration avec le Cloud HSM Amazon, dont on a parlé hier et sur lequel on va revenir. Ce Cloud HSM, donc AWS, peut devenir l'encre de confiance ou la route of trust, qui est une désignation qui nous vient du NIST, mais qui veut par là désigner un élément dont la sécurité inhérente, la confiance est inhérente au produit, on n'a pas besoin de la prouver, c'est l'encre de la confiance inhérente du système d'information. Donc cet AWS Cloud HSM et les HSM Gemalto, on les présente comme le root of trust du système d'information et de la solution de chiffrement de vos données. Donc on vient gérer la clé avec un virtual key secure, protéger le virtual key secure avec une root of trust, le cloud HSM, et obtenir de fait une solution qui qualifié avec le Cloud HSM, une protection hardware résistante aux attaques physiques et logicielles, pour garantir la protection de l'ensemble de ces données. Et si l'on parle de gestion de clés, je pense qu'il faut rappeler à tous et à toutes aussi un élément clé, c'est la sauvegarde de ces clés. Sans ces clés, bien sûr, pas de possibilité de recouvrer ces données. Donc, on a pour cela la possibilité d'avoir également des boîtiers hardware pour aller back-up'er ces Cloud HSM Amazon et ces boîtiers hardware, les posséder au sein de son entreprise. En cas de problème sur cloud, de décommissionnement, on a toujours la possibilité de garder ses propres clés. On en est le maître. Et à titre d'information, sachez que sur la FAQ Cloud HSM d'Amazon, vous aurez toutes les instructions et tous les guides pour mettre en place ces mécanismes de backup, de sauvegarde de vos clés sur les Cloud HSM. Et si je ne me trompe pas, que ce soit sur la première partie clé cloud HSM et que ce soit aussi sur Virtual Case Secure, ces solutions, on va pouvoir mettre en place la même solution dans notre data center et sur AWS. Ce qui est dans un scénario hybride, quelque chose qu'on voit beaucoup par exemple dans le monde de l'entreprise, on va pouvoir avoir la même solution, une solution unifiée pour gérer ces clés et son chiffrement. Tout à fait, c'est vraiment une énorme flexibilité pour tous nos clients et nos clients également de pouvoir se dire j'ai mon infra Amazon qui fonctionne avec ma chaîne de sécurité, qualifié, certifié, HSM, key management et chiffrement, mais de se dire je veux retrouver le même service dans mon entreprise et avoir les mêmes niveaux de sécurité, donc je peux très bien mettre en place aussi un HSM, un key secure dans mon entreprise, les mettre en haute disponibilité, donc une configuration avec les éléments présents dans l'infrastructure Amazon et avoir un cloning automatisé, sécurisé pour retrouver à tout instant les clés chez Amazon mais comme chez moi également. C'est une méthode de sauvegarde des affaires qui en plus de tout ce que peut permettre un backup HSM. Mais cette fois-ci, en plus d'être une sauvegarde, c'est aussi opérationnel. C'est l'audispo, hybride. Je peux retrouver toutes mes données et mes applicatifs sécurisés dans mon entreprise. Tous ces points sont intéressants parce que finalement, on retrouve sur des sujets de gestion de clé exactement les mêmes sujets que sur la gestion d'utilisateur ou de la gestion de données, c'est-à-dire quid des sauvegardes, quid de la haute dispo, quid de la gestion hybride. Il faut effectivement y réfléchir aussi en termes de chiffrement, de crypto, etc. Il ne faut pas se limiter uniquement à la confidentialité, il faut aussi, dans cet aspect disponibilité, C'est très important. C'est-à-dire qu'on va prendre un cloud HSM, si on n'en prend qu'un seul, ça reste une appliance physique. Et donc, à un moment, il va falloir la redonder, la vivre. Et à se dire, s'il y a une panne matérielle, ce qui peut arriver, on perd toutes nos données. C'est très mondial. Et dans les conseils que donne aussi Amazon sur ses FAQ, on retrouve le fait de pouvoir installer plusieurs cloud HSM dans des zones de disponibilité différentes afin d'assurer à chaque instant haute disponibilité de ces clés en cas de défaillance d'un équipement. La vue vraiment que Gemalto essaie de promouvoir au sein de ses clients, c'est de ne plus avoir, j'allais dire peur, de la crypto qui est un sujet intimidant, mais plutôt de l'embrasser, de l'utiliser pour la protection des données et de penser ça aussi d'une façon centralisée, unifiée. C'est-à-dire que des outils comme les KMS Amazon, le SafeNet virtuel qui sécurise sont là pour ça, pour penser à la gestion de chiffrement de façon centralisée, unifiée, de permettre la journalisation, la traçabilité, faciliter les audits de conformité, les audits de sécurité, en fournissant simplement qui accédait à quoi en donnant le journal de mon KMS, ou qui manage notre système. Parfait, merci beaucoup Nicolas. Peut-être pour conclure sur ce point et avant de passer aux questions qui s'annoncent déjà assez nombreuses, décidément vous n'arrêtez jamais, Très bien, on est là pour ça. Si on veut en savoir plus sur les solutions Gemalto, gemalto.com. Bien sûr, on a un portail dédié à la data protection qui est extrêmement bien fait, fourni avec de nombreux livres blancs, documentations, brochures sur l'ensemble de nos solutions. Je pense que vous pourrez retrouver aussi un réseau distributeur chez Gemalto qui pourront vous relayer toutes ces informations-là, vous mettre en relation directe avec nos responsables de région également. Et bien sûr, le site internet, portail d'entrée le plus facile, safenet.gemalto.com. Voilà, safenet.gemalto.com pour tout savoir sur les solutions de Gemalto. Et puis, effectivement, les solutions dont Nicolas a parlé sont disponibles sur la marketplace AWS, où vous pouvez les essayer à l'heure, à la journée, etc. C'est un grand avantage pour ne pas dépenser tout son budget tout de suite. Même si, évidemment, on a très envie de vous le dépenser ensuite chez Gemalto. Merci beaucoup Nicolas, c'était intéressant de compléter cette présentation par une vision partenaire, et en particulier Gemalto, qui est vraiment le plus important le leader de ce marché. Alors Hugo et Tomannet, comme d'habitude, je voulais le remercier. Merci Hugo pour l'organisation de ce webinar multipartite. Regardons un peu nos questions. Alors on va essayer de les prendre, on va voir si on peut commencer déjà par des questions AWS. Il y a beaucoup de questions, j'ai mal tout aussi. Alors peut-être... Oui, on a une question. Mathieu, vas-y, je te laisse peut-être relire la question ou la synthétiser et puis répondre. Donc on a une première question là sur le Patriot Act, de savoir... Donc oui, Amazon est soumis au Patriot Act. Ce qu'on voit c'est que beaucoup de nos clients sont déjà soumis aussi au Patriot Act. C'est-à-dire qu'à partir du moment où on a une entité qui va avoir des activités commerciales aux États-Unis, on va être déjà en tant que client soumis au Patriot Act. On voit beaucoup de cas où généralement le Patriot Act aura plus de sens à s'appliquer directement sur le client plutôt que passer par nous. Donc bien entendu on respecte... On se doit de respecter les lois des pays dans lesquels on opère et donc on respecte le Patriot Act. Donc oui, on est soumis au Patriot Act. Comme toutes les entreprises. Comme toutes les entreprises qui ont une activité ou une filiale aux États-Unis. Et donc, ça ne veut pas dire qu'une entreprise française n'est pas soumise au Patriot Act non plus. Oui. Oui, il y a beaucoup de confusion sur ce sujet où les gens pensent qu'à partir du moment où on n'est pas une entreprise 100% américaine, on n'est pas soumis au Patriot Act. Malheureusement, la réalité est plus complexe. Une autre question ? Oui, la question sur les NDA. Mathieu, vas-y, je te laisse. Donc, on a la question sur les non-disclosure agreements. client, donc le client AWS, ou même, on a même des cas où on peut avoir des prospects AWS qui vont signer un NDA pour avoir accès au contenu, il faut juste nous demander par le formulaire de contact, mais on peut vous donner accès au rapport de conformité avant que vous soyez même client. On va pouvoir signer un NDA. Si le client doit envoyer à ses clients ces rapports-là. Il suffit juste que ce deuxième niveau de client signe un IDA avec nous et on pourra envoyer le rapport au client. Il n'y a pas de positivité de l'IDA. Disons que les auditeurs du client, ça va être couvert généralement à valider exactement les entités juridiques à chaque fois, généralement les cas d'audits sont couverts par la partie client, après dès que ça va être un deuxième niveau, le client du client, c'est souvent beaucoup plus simple de passer par une deuxième signature de NDA pour que tout le monde soit couvert au mieux. Donc ça c'est une discussion juridique, à valider avec vos équipes juridiques, mais généralement, c'est la meilleure solution. Oui, et puis le meilleur conseil qu'on peut vous donner, c'est en cas de doute, vous contactez votre client manager, vous lui demandez, et ça vous évite de faire une bêtise et de transmettre des documents que vous n'aviez pas à transmettre. Alors, on a une question sur… Alors, je vois une question sur IAM, je vais y répondre très vite, j'en profite, en attendant qu'on regarde les autres. Donc, une question sur, hier dans la présentation à IAM, j'ai dit qu'il ne fallait pas copier de clés sur les instances EC2. Alors, effectivement, je ne parlais pas de clés crypto, on est bien d'accord, je parlais de clés, les clés d'accès. Donc, l'access key et la secret key, qui sont les clés qui vous servent à accéder aux API, c'est une mauvaise pratique de les mettre sur les instances, et la bonne solution, c'est d'utiliser un rôle. d'assigner à l'instance EC2 un rôle qui va contenir les stratégies AIAB qui lui permettent de faire les bonnes opérations. Donc attention, pas d'ambiguïté, là on parle des clés d'accès, on ne parle pas du tout de clés KMS ou autre chose comme ça. De clés d'API. De clés d'API, pas de clés de commandes données. Quelques questions pour Gemalto ? Oui, peut-être des questions sur Gemalto. Effectivement, je... Je vois des questions sur l'utilisation d'un HSM en comparaison avec un key management système. Quelle serait la différence entre les deux ? Comment fonctionne-t-il ensemble ? En fait, ce sont deux éléments différents, avec des buts différents, des possibilités différentes, mais qui peuvent fonctionner en symbiose, l'un étant un système, l'autre étant, comme je le disais, la route of trust, l'encre de confiance de l'autre. Le key management système est là pour gérer un cycle de vie de clés, peut aller jusqu'à générer des clés, peut être autosuffisant, comme le Pellet, le Virtual Key Secure ou l'Amazon KMS. Ils génèrent leurs clés, ils gèrent, stockent, font du versionning de clés ou de la rotation de clés, qui est un des éléments aussi du important de la gestion de clés. Et on a à côté le HSM qui lui est un hardware avant tout, alors que le Key Management System peut être virtuel. L'HSM lui est ce boîtier hardware avec des facilités cryptographiques. Donc il offre des possibilités cryptographiques de génération de clés, d'opération sur ces clés-là, et peut avoir des possibilités aussi pour sécuriser et stocker quelques clés. Donc on peut également utiliser un HSM pour faire de la gestion de clés, mais avec, j'allais dire, quelques différences, je parlais de cette rotation de clés, de ce versionning qui est propre là au KMS, alors que l'HSM va se baser plutôt directement sur l'opération cryptographique, sur une GERA, d'algorithmes supportés bien plus importants que peut avoir un KMS, mais surtout, il vient comme ancre de confiance hardware avec des certifications bien plus poussées aussi qu'il peut avoir un virtual KMS de fait d'être hardware tout de suite. Alors, on a une autre question. Je pense qu'elle est déjà sortie hier, mais ce n'est pas grave. Je vais Je vais à nouveau y répondre, je sais que ça aussi c'est un favori. C'est quelle est l'utilité d'utiliser le chiffrement interne d'AWS plutôt que d'utiliser des chiffrements, on va dire applicatifs ou des chiffrements en fin de système. Alors, pour moi, ce n'est pas fromage ou dessert, c'est fromage et dessert, pas forcément dans cet ordre d'ailleurs. Mais... Blague à part, je vais reprendre la réponse que j'ai faite hier. Si vous chiffrez vos volumes EBS, les volumes disques réseau qui sont attachés à vos instances, si vous les chiffrez server-side avec KMS, et je vous ai montré à quel point c'était facile de le faire hier, c'est un chiffrement qui va être fait par le hardware de notre côté, qui va être géré par les baies de stockage. Donc on va chiffrer les volumes en mode bloc. Ces volumes, vous allez les attacher à vos instances, vous allez les formater avec le système de votre choix, vous allez les monter, vous allez travailler dessus. Donc là, on vous garantit que le volume est chiffré. Et d'ailleurs, comme il est chiffré par le hardware de stockage, il n'y a aucun impact de performance sur votre instance. Maintenant, rien ne vous empêche... je dirais même au contraire, d'appliquer au niveau file system un chiffrement supplémentaire. Donc si vous avez votre file system crypto favori, vous pouvez tout à fait l'appliquer au niveau de l'OS au-dessus du chiffrement fait par EBS en utilisant KMS. Une petite précision là-dessus. Alors là par contre vous risquez d'avoir un petit impact. Une petite précision là-dessus qui est importante, la difficulté qu'on voit généralement sur un DMCrypt ou un Lux, ça va être comment on va débloquer la grée au bout de l'instance. Et c'est pour ça que l'intégration de KMS va nous simplifier la vie et va nous permettre de chiffrer l'ensemble des volumes EBS, y compris le volume de boot. Là où généralement, en fait, on n'aura pas de solution simple et portable parce qu'on n'est pas sur un ordinateur portable ou autre où l'utilisateur va avoir un clavier pour taper un mot de passe à chaque fois qu'on démarre. Et c'est là où la solution KMS est intéressante. Le point où la solution KMS est intéressante, C'est sur tous les autres services AWS où elle va être intégrée. Par exemple, sur S3, ça fait que S3 va chiffrer pour nous. On n'aura pas besoin de chiffrer avant d'envoyer à S3. Sur des services comme RDS, on va avoir des bases de données qui sont managées par AWS. C'est beaucoup plus simple de demander à RDS de chiffrer plutôt que de chiffrer les chiffres à la volée, les données à l'intérieur des tables de la base de données. Et C'est pour ça aussi que KMS peut être utile. Après, comme disait Julien, on peut chiffrer une deuxième fois les données les plus sensibles en fonction de nos risques. Et il n'y a pas une solution qui va répondre à tous nos besoins. On va souvent, éventuellement, utiliser plusieurs solutions si on a plusieurs besoins, on a des données plus sensibles, et ainsi de suite. Ok, alors une question. pour Nicolas, si on avait laissé respirer Mathieu, qui donne des réponses super exhaustives. J'apprends beaucoup de choses, je profite. Alors question, y a-t-il un intérêt à utiliser un key secure on-premise, donc sur site, plutôt qu'en mode virtuel ? Pas forcément. Pas forcément. J'allais dire, ça peut être bien d'utiliser les deux en même temps, comme on l'a expliqué, dans un mode hybride et dans une envie de haute disponibilité et de sauvegarde chez soi de ses propres clés. Mais sinon, on aura exactement la même solution, que ce soit virtuel sur Amazon ou on-premise, si j'ai mon instance virtuelle également on-premise. On retrouvera les mêmes fonctionnalités. Alors on a une question, si nous avons plusieurs milliers de clients à gérer qui changent tous les mois, grand Dieu, peut-on utiliser les comptes IAM pour gérer la liste des clients actifs et suspendre les autres clients ? Alors, moi je pourrais faire une réponse très rapide en disant peut-être que je regarderai cognito dans ce cas-là. Qu'est-ce que vous pensez, Mathieu ? En fait, la question sur l'identité, il faut bien se poser la question entre la différence entre le client, l'utilisateur de l'application et l'administrateur des ressources Amazon Web Services. Si on a plusieurs milliers de personnes qui vont sur le compte AWS pouvoir administrer des ressources, généralement on a d'autres problèmes que de leur donner les droits à IAM. Niveau gestion, niveau savoir qui a fait quoi quand et s'assurer qu'ils ne se marchent pas sur les pieds les uns des autres, ça va être assez complexe. J'imagine que ça doit être, à ce stade, soit un scénario de fédération dans une grosse boîte, soit des utilisateurs mobiles. Donc là, si c'est pour administrer des ressources AWS, si ces gens-là ont besoin par exemple d'accéder à la console AWS, et peut-être que certains sont uniquement en lecture seuls, il faut se poser la question, est-ce que ça ne vaut pas le coup d'avoir des fois plus plusieurs comptes AWS pour simplifier la problématique. Fédérer les identités, je citais tout à l'heure l'exemple de l'Active Directory, on a d'autres partenaires, par exemple, on a Octa qui a un système de fédération en mode web, qui marche aussi très bien avec AWS pour les accès console et autres. Après, si on est plus dans les utilisateurs de l'application, c'est-à-dire que ces personnes-là vont utiliser l'application peut-être qu'elles vont faire, l'application fait des requêtes DynamoDB ou autre. Là, c'est vrai que Cognito nous permet de gérer beaucoup plus facilement ces cas-là. Par exemple, l'utilisation de Cognito, on a notre jeu sur mobile, on a des milliers, voire des millions d'utilisateurs. Donc chacun aura son identité via Cognito. Éventuellement, il y a une web identity, un compte Google ou autre, et on leur donnera des accès restreints, par exemple pour que l'application fasse un call vers DynamoDB pour voir le scoreboard ou des choses comme ça sur le jeu. Oui, on en a parlé rapidement hier, mais voilà, c'est un bon cas d'utilisation. Il faut bien faire le distinguo entre les deux cas, un cas plus utilisateur, un cas plus administrateur, parce que généralement, on a des facilités pour les utilisateurs qui sont un peu différents des administrateurs. Alors on est presque à court de temps, on va prendre une dernière question, mais juste avant Hugo va vous afficher le sondage de satisfaction. Alors, on apprécie votre feedback, donc merci de voter. Vous pouvez noter ce webinar de 1 à 5, attention, il y a des gens qui se sont trompés hier. 1, vous êtes très fâchés, très mécontent, vous avez perdu votre temps. Et 5, vous êtes très content. 5, c'est la note maximale. 1, c'est la plus mauvaise. Voilà, à vous de jouer. Vous pouvez cliquer. C'est totalement anonyme. C'est juste pour savoir si on a fait du bon boulot ou pas, tout simplement. Et savoir comment adapter le contenu pour les prochains webinars. Donc, à vous de jouer. Vous devez voir la fenêtre. Et peut-être une dernière question. La question qui, effectivement, qui revient souvent, quelle est la bonne pratique pour partager des credentials entre plusieurs instances de C2 ? Alors, j'imagine pas des credentials AWS, mais peut-être des credentials pour d'autres applis. Alors, comment on fait ça intelligemment, vous-même ? Alors, souvent, on a le cas, c'est vrai, par exemple, qu'on a un mot de passe de base de données. Voilà, bon exemple. Un mot de passe de base de données, un token pour se connecter à une API externe, récupérer son code sur GitHub, des choses comme ça. La bonne pratique déjà, ça va être de le chiffrer avant de l'envoyer. Donc par exemple, on va pouvoir demander à KMS de le chiffrer. Donc KMS peut aussi, c'est une utilisation qu'on voit un peu moins souvent, mais on peut demander à KMS de le chiffrer une donnée jusqu'à 4 kHz. Donc plutôt que de juste chiffrer une clé, il va pouvoir chiffrer tout ce qui peut se présenter sous une forme de base 64 de moins de 4 kHz. Donc un mot de passe généralement il fera moins de 4 kHz donc souvent ce qu'on va faire c'est qu'on va pouvoir le chiffrer avec KMS et là le condensé à chiffrer on va le mettre dans le code on va le mettre dans un fichier on va se le partager par différents mécanismes sur lesquels on va et comme c'est un condensé à chiffrer on aura besoin d'avoir un accès à la clé KMS on aura besoin de faire un code valide sur KMS pour demander des chiffres Cette clé-là, on va pouvoir considérer qu'elle est suffisamment protégée et donc on a plus ce côté un peu sensible d'avoir un mot de passe qui est dans un fichier de config ou autre. Oui, l'erreur que l'on a tous faite. On a aussi un nouveau service qui peut être pas mal pour passer des paramètres à des instances qui s'appelle EC2ASM, System Manager, et donc qui va permettre de définir des paramètres qui vont être partagés avec les différentes instances. Ok, intéressant. Ça, ça a sorti à Rain20. Ce qui a été annoncé, oui, il y a quelques semaines à Rain20. Et d'ailleurs, je crois qu'on va parler des autres services à Rain20 un peu plus tard. On est à court de temps. Je voudrais vous remercier encore Mathieu et Nicolas d'avoir pris sur votre temps qui est précieux pour participer à ce webinaire. J'espère que c'était intéressant. C'était sympa, je trouve que la discussion a été super riche, très dense, beaucoup d'infos intéressantes. Vous pouvez retrouver tout un tas d'informations AWS sur aws.amazon.com slash security et slash compliance et vous pouvez retrouver les informations de Gemalto sur safenet.gemalto.com. Merci beaucoup, merci. Merci à tous et à toutes de nous avoir écoutés. On va faire une petite pause avant le prochain webinaire qui est donc la première partie du récap de Réinvent avec quelques surprises. Donc, restez connectés. Merci beaucoup à Hugo pour la logistique, impeccable comme d'habitude. Et donc, rendez-vous dans quelques minutes pour le webinaire Réinvent. Et merci encore. Merci Nicolas, merci Mathieu. Merci.