Les bonnes pratiques de securite sur AWS

Transcript

Nous revoilà pour ce dernier webinar de la semaine, le dixième, qui va revenir sur les bonnes pratiques pour gérer la sécurité dans AWS. À l'agenda, on va revoir une dernière fois le modèle de sécurité partagée, un sujet qui vous marquera fortement. On balayera les différents sujets abordés cette semaine, peut-être en complétant avec une ou deux choses dont nous n'avons pas eu le temps de parler. On répondra également à vos questions. Le modèle de sécurité partagée a été abordé il y a encore une demi-heure. Je ne vais pas trop y revenir, mais une dernière fois, la sécurité du cloud, l'infrastructure et les services de base, c'est notre responsabilité. La sécurité dans le cloud, la gestion de vos OS, plateformes, langages de développement, applications, contenu, chiffrement, c'est votre responsabilité. La protection des données a été largement discutée, notamment avec Mathieu Boutor, un de nos experts sécurité, mardi. On a beaucoup parlé de la localisation des données et des assurances qu'AWS vous offre à ce sujet. Vos données sont là où vous les mettez. Aujourd'hui, l'infrastructure d'AWS est située dans 16 régions, avec l'espoir que la 17ème, la région française, arrive l'année prochaine, et 42 zones de disponibilité. Vous conservez le contrôle et la propriété complète de vos contenus et applications, et nous ne déplaçons jamais, absolument jamais, vos données en dehors de la région où vous les avez placées. Bien sûr, nous vous fournissons des mécanismes pour copier vos données d'une région à l'autre, comme la réplication cross-région dans S3, la copie de snapshots cross-région, et les reads réplica cross-région avec RDS, mais tout cela se fait à votre initiative. Il n'y aura jamais de déplacement de vos données, applications ou bases de données à notre initiative, c'est vous qui avez la main. Lundi, nous avons parlé en détail des solutions de chiffrement de données, notamment KMS et HSM. Nous encourageons fortement le chiffrement de vos données. La keynote de Stephen Schmitt, dont vous trouverez l'URL à la fin de cette présentation, explique explicitement que chaque fois que vous chiffrez vos données, vous simplifiez la vie de tous. Non seulement vous vous protégez, mais vous nous simplifiez la vie, car même si quelqu'un accède à vos données, ce qui est invraisemblable, elles resteront inintelligibles. Chiffrez vos données, c'est un service que vous vous rendez et que vous nous rendez. Il existe plusieurs approches pour le chiffrement. Vous pouvez faire du chiffrement côté client, en gérant vous-même vos clés avec votre propre infrastructure, que ce soit avec vos solutions maison ou des solutions partenaires comme Gemalto. C'est tout à fait possible, mais attention, l'exploitation de votre infrastructure de clés est un sujet à ne pas prendre à la légère. En cas de panne, indisponibilité ou perte de données sur cette infrastructure, vous risquez des conséquences lourdes pour le fonctionnement de votre plateforme. Ne vous lancez pas à la légère sur ce sujet. Vous pouvez également faire du chiffrement serveur, qui est natif sur de nombreux services comme S3, EBS, RDS, et Redshift. Vous utilisez des clés générées à la volée par nos services pour chiffrer vos données. Tous nos services sont accessibles en SSL et TLS pour le chiffrement des données en transit, que ce soit pour les données en transit ou au repos. Nous vous fournissons toutes les solutions pour vous protéger facilement. Nous avons deux solutions de gestion de clés : KMS, un service managé qui vous permet de créer et stocker des clés principales de manière très sécurisée, et Cloud HSM, pour les utilisateurs soumis à des exigences de conformité et de sécurité élevées. Cloud HSM est un équipement matériel hébergé dans notre data center, mais dont vous êtes le seul utilisateur et administrateur. Il vous permet de créer et gérer des clés avec du matériel dédié et une utilisation exclusive. C'est un service hyper sécurisé, mais plus cher, donc à réserver à des cas d'usage où cette sécurité est justifiée. Nous avons également de nombreux partenaires qui proposent des services de gestion de clés pour le chiffrement côté client, disponibles sur la marketplace AWS à faible coût. Au début de la semaine, nous avons beaucoup parlé des utilisateurs et des autorisations, et nous allons y revenir brièvement. C'est sans doute le sujet le plus important, même avant le chiffrement, pour garantir que seules les bonnes personnes aient le droit de faire les bonnes actions sur les bonnes ressources. La première étape est de créer des utilisateurs. Combien de plateformes partagent des utilisateurs génériques et des logins partagés ? C'est une pratique catastrophique. Sur AWS, créez un utilisateur IAM par utilisateur réel, séparez-les, et donnez-leur des autorisations distinctes. Cela vous permet de savoir qui est qui et rend la traçabilité des actions possible. Le deuxième principe est celui du moindre privilège. Chaque utilisateur doit disposer du minimum de privilèges. Définissez des politiques IAM les plus restrictives possibles. L'onglet Access Advisor dans la console IAM vous montre quels droits sont réellement utilisés par un utilisateur et quand. Cela vous permet de voir quels droits sont présents dans les stratégies IAM mais jamais utilisés. Si vous avez accès à RDS et que vous n'avez jamais fait d'appel sur RDS depuis 328 jours, avez-vous vraiment besoin de ce droit ? L'Access Advisor est une bonne solution pour vérifier que vos politiques sont serrées et qu'il n'y a pas de droits inutilisés. Les groupes sont une bonne façon de définir et factoriser des stratégies IAM pour un ensemble de personnes ayant une fonction identique dans l'entreprise. Lorsque vous voulez changer une stratégie, vous la changez au niveau du groupe, et elle s'applique automatiquement à tous les membres. Ne faites pas de copier-coller de stratégie IAM entre vos utilisateurs. Créez des groupes d'utilisateurs, attachez des stratégies au groupe, et centralisez la gestion de la sécurité pour ce groupe. Pour les accès privilégiés, comme les accès administrateurs et les actions à fort impact (par exemple, l'effacement de Buckets S3, l'effacement de clusters RDS, la terminaison d'instances), vous pouvez durcir les accès en définissant des conditions, comme des conditions d'adresse IP source ou des plages horaires. Il est peu probable qu'un accès ait besoin d'être fait à 3h du matin. Vous pouvez également durcir certains accès en utilisant ces conditions. Hier, nous avons parlé de CloudTrail. Il n'y a aucune raison de ne pas activer CloudTrail dans toutes les régions. Le service est extrêmement économique et peut vous sauver la vie. N'oubliez pas que CloudTrail est la boîte noire de votre infrastructure. Si vous ne l'avez pas encore activé, allez dans la console, cliquez sur le bouton qui dit « Activer CloudTrail dans toutes les régions ». Vous verrez combien cela vous coûte dans une semaine ou deux, et vous serez rassuré sur le fait que c'est un service très peu coûteux. J'espère que vous n'aurez jamais besoin de l'utiliser, mais le jour où vous en aurez besoin, vous serez heureux d'avoir l'historique complet des appels d'API dans votre plateforme. Ensuite, bien sûr, toutes les bonnes pratiques habituelles s'appliquent, comme avoir une stratégie de mot de passe fort pour les utilisateurs qui se connectent à la console. Vous pouvez forcer des longueurs minimales de mots de passe et obliger vos utilisateurs à les changer régulièrement. La rotation régulière des clés et des mots de passe est également une bonne pratique. Changez vos clés, en particulier les clés d'API, une fois par an pour tous les utilisateurs. Pour les utilisateurs privilégiés, en particulier les administrateurs, activez le multifactor authentication (MFA). C'est le meilleur moyen de protéger vos comptes. Le MFA, soit avec des tokens hardware, soit avec Google Authenticator sur vos smartphones, est une solution très efficace. Si vous devez déléguer des droits, utilisez les rôles, qui sont la bonne façon de le faire, par exemple pour l'accès entre comptes ou la fédération d'identité. Restreignez au maximum les droits autorisés à ces rôles. L'avantage des rôles est que vous n'avez pas à stocker les credentials. Ne mettez jamais la clé d'accès ou la clé secrète sur une instance EC2. Utilisez un rôle qui donnera les droits adéquats à cette instance. Les rôles permettent de faire de l'autorisation sans partager de secret, ce qui est une pratique bien plus sécurisée. Cette dernière pratique que vous devez voir clignoter en rouge dans la console IAM est de limiter au strict minimum, voire d'interdire, l'utilisation du compte root. Supprimez les clés associées au compte root. Il n'y a aucune raison de se connecter à AWS avec le compte root ou d'utiliser des clés d'API avec ce compte. Créez des utilisateurs, quitte à leur donner tous les pouvoirs administratifs. Le compte root n'est pas un identifiant d'utilisateur. Voilà, ce sont 11 pratiques qui sont pour la plupart de bon sens et très simples à mettre en œuvre. Après les vacances, revoyez bien vos utilisateurs IAM, vérifiez que vous êtes dans les clous, jetez un œil à votre politique de mot de passe, regardez si vos clés d'accès n'ont pas un an, deux ans, trois ans, et vérifiez que le MFA est activé sur les comptes admin. Vérifiez que vous avez supprimé les clés du compte root. Tout cela se fait en très peu de temps et vous permettra de monter le niveau de sécurité de votre plateforme. CloudTrail, bien sûr, vous permet déjà de monter le niveau de sécurité de manière extrêmement élevée. Je vous incite à passer une ou deux journées pour régler ces points, et vous aurez déjà résolu un grand nombre de problèmes de sécurité. Quelques questions supplémentaires. Est-ce que tous mes utilisateurs doivent avoir des clés d'accès ? Le mot de passe ne sert qu'à la connexion console. Donc non, il n'est pas nécessaire que tous les utilisateurs IAM aient un mot de passe. Si vous avez des utilisateurs qui ne travaillent qu'en ligne de commande ou des applications qui utilisent le SDK ou la CLI, ils n'ont pas besoin d'avoir un mot de passe. Le login console est à réserver aux personnes qui ont absolument besoin de se connecter à la console. Posez-vous la question pour chaque utilisateur. Pensez à échanger régulièrement les clés, comme nous l'avons discuté, et à mettre en place une stratégie de mot de passe robuste. Une autre question est de savoir s'il faut un compte AWS unique ou plusieurs comptes AWS. Avoir un compte AWS unique est plus simple. Tous vos utilisateurs sont dans le même compte, vous avez une unique facture, et c'est plus facile à gérer. Cependant, soyez doublement vigilants sur les permissions IAM attribuées aux utilisateurs, surtout si vous partagez un compte entre le développement et la production. Vérifiez que les développeurs n'ont pas le droit de faire des actions dangereuses sur la production. L'utilisation de plusieurs comptes peut être un peu plus compliquée en termes d'administration, mais vous pouvez consolider la facturation sur un compte. L'avantage d'avoir plusieurs comptes est que vous avez un isolement total entre les comptes. Si vous avez un compte pour les équipes de développement, un compte pour la production, et un compte pour les utilisateurs non techniques, l'utilisateur IAM est créé dans un compte et ne peut pas accéder à un autre compte, sauf via les rôles ou la fédération. Le troisième grand sujet abordé est la journalisation des données, qui vous permet de monitorer et d'auditer votre plateforme. AWS est riche en logs, avec trois catégories : les logs d'infrastructure (CloudTrail, VPC Flow Logs), les logs de services (S3, CloudFront, Beanstalk), et les logs d'instances (logs système, logs applicatifs, logs Windows). Commencez par CloudTrail. Activez-le dans toutes les régions. Vous pouvez activer la validation des logs de CloudTrail pour vérifier leur intégrité. Vous pouvez également les chiffrer avec KMS en server side. Exportez les logs CloudTrail vers CloudWatch Logs pour définir des alarmes. Si vous avez plusieurs comptes, vous pouvez centraliser tous les logs CloudTrail dans un seul compte pour une vision unifiée. Pour le VPC, les logs des accès réseau (VPC Flow Logs) peuvent être activés sur tout le VPC, un sous-réseau, ou une interface. Réfléchissez à ce que vous allez en faire. Si vous activez tous les logs de toutes les connexions sur un VPC actif, cela peut générer beaucoup de données et coûter de l'argent. Définissez un objectif précis pour ces logs, comme le dépannage ou la sécurité. Les journaux des services AWS peuvent être exportés vers CloudWatch Logs, CloudTrail, ou S3. Pour les services de compute (Beanstalk, ECS, Lambda), vous pouvez facilement exporter les logs vers CloudWatch Logs. Pour S3, vous pouvez loguer les data events (get, put) sur les objets. Pour CloudFront et les load balancers, vous pouvez exporter des logs d'accès vers S3. Pour EC2, utilisez l'agent CloudWatch pour exporter les logs des instances vers CloudWatch, où vous pouvez définir des métriques et des alarmes. Le minimum, selon moi, est CloudTrail. Ensuite, en fonction de votre utilisation de tel ou tel service, activez les exports vers CloudWatch Logs ou S3, et définissez des alarmes sur ce qui vous paraît important. Le point suivant est l'automatisation de la sécurité. Utilisez des mécanismes pour réagir efficacement et sans intervention humaine à des événements. L'automatisation de la construction de votre infrastructure, en particulier avec CloudFormation, est une bonne pratique de sécurité. La capacité à créer automatiquement des security groups, des VPC, et des ressources AWS de manière sécurisée élimine les erreurs humaines. Pour la partie applicative, l'automatisation de l'installation de vos services et applications avec OpsWorks ferme également la porte à de nombreuses attaques. Avec CloudTrail et CloudWatch Events, vous pouvez réagir à des événements, comme l'effacement d'un bucket, en envoyant un mail ou en exécutant une fonction Lambda. Vous pouvez également utiliser Inspector pour scanner le contenu de vos instances EC2, Linux et Windows, sur la base de règles prédéfinies. Trusted Advisor, bien que simple, fait déjà un certain nombre de vérifications dans votre compte, notamment sur la sécurité des security groups. Enfin, Config vous permet de définir des règles de conformité sur vos ressources AWS. Il fait un inventaire des ressources et trace chaque modification de configuration. Vous pouvez définir des règles de conformité qui vérifient à chaque changement si la règle est respectée. Par exemple, vous pouvez vérifier que le MFA est activé, que CloudTrail est activé, que les instances sont de type T2 micro, et que les volumes EBS sont chiffrés. Vous pouvez recevoir des notifications lorsqu'une ressource non conforme est lancée et réagir programmatiquement. Voilà pour ce récap. Il nous reste du temps pour les questions. Quelques ressources complémentaires. Le livre blanc qui décrit les process de sécurité d'AWS. Le livre blanc sur le Well-Architected Framework, qui sont un ensemble de bonnes pratiques pour bien architecturer vos plateformes, qui contient un chapitre sécurité, qui mérite d'être lu. Et puis un livre blanc dédié aux pratiques de sécurité, Security Best Practices, qui va reprendre et compléter tout ce dont j'ai parlé aujourd'hui, donc là aussi une bonne lecture pour d'emblée adopter les bonnes pratiques et faire monter le niveau de sécurité de votre plateforme. Et puis deux vidéos re-invent, donc la keynote de Steve Schmitt qui est le Chief Security Officer d'AWS, keynote toute récente, où je vous conseille très fortement, il va revenir sur notre approche de la sécurité, il va parler de certains services, c'est vraiment si vous travaillez au quotidien avec la sécurité informatique, je vous conseille de regarder cette vidéo, c'est vraiment une très bonne présentation. Et puis une session plus technique qui parle de l'automatisation de la sécurité et qui va déployer avec des démos un certain nombre des services dont j'ai parlé pour finalement créer un niveau de sécurité élevé dans votre compte. Voilà, j'ai terminé, presque, grâce à la question. J'ai terminé et je voulais vous remercier énormément de nous avoir suivis toute la semaine, Hugo et moi. On a passé beaucoup de temps à travailler sur ces webinars, on espère que vous avez appris beaucoup. Autre chose et on va passer maintenant aux questions. Je pense que Hugo va peut-être, on va afficher le sondage bien sûr. Donc le sondage de satisfaction de 1 à 5, 5 vous êtes très contents, 1 vous n'êtes pas contents du tout. Voilà, on apprécie beaucoup votre feedback, ça nous aide à identifier les bons sujets et à améliorer les prochaines sessions. Merci. Alors, comme on a pas mal de temps, il fallait quand même que je finisse par vous laisser parler, vous aussi. Il nous reste 15-20 minutes. On va ouvrir les questions à tous les sujets AWS. On va en profiter. Si vous étiez à d'autres webinaires cette semaine et que je n'ai pas eu le temps de répondre à certaines de vos questions, vous pouvez essayer de les reposer. Sachez que je les garde toutes et que je réfléchis à des podcasts pour l'année prochaine que je vais pouvoir faire de manière très régulière pour répondre notamment aux questions. Merci. Donc envoyez vos questions, même si elles ne sont pas traitées aujourd'hui, je garde tout et on va expérimenter un format podcast pour l'année prochaine. Et puis si vous avez des questions sur d'autres services qui n'ont rien à voir avec la sécurité, allez-y, envoyez, c'est le dernier de l'année. Posez toutes vos questions sur Hadoop, EMR, RDS, j'essaierai de faire ce que je peux. Voilà, je pense que vous avez fini de voter sur le sondage. Merci. Alors, on a une question sur l'inspecteur. Est-ce qu'Amazon, enfin, est-ce qu'Amazon, qu'en gros on peut avoir un Inspector pour les applications serverless. Alors un peu comme tout à l'heure, un peu comme sur les containers, aujourd'hui le modèle d'Inspector c'est vraiment un modèle basé sur EC2, vous avez vu on tag les instances EC2 et puis on les scanne, donc c'est un service qui s'appuie uniquement sur les instances. Je ne sais pas ce qui sortira sur Inspector en 2017. Étant donné le focus qui a été mis sur les containers et sur Lambda, effectivement on pourrait souhaiter qu'on ait un système équivalent, au moins sur ECS dans un premier temps, sur Lambda. Sincèrement, ça me paraît un petit peu moins pertinent parce que Lambda, c'est uniquement du code applicatif. Dans Lambda, on vous fournit l'environnement d'exécution sous-jacent, que ce soit du Node ou du Python ou du C Sharp ou du Java maintenant, enfin C Sharp récemment. Donc là, c'est à notre charge finalement de faire en sorte que ces environnements soient sécurisés. Sur Lambda, ça me semble qu'on arrive à un service de ce style. Sur les containers, ça ne serait pas idiot. D'ailleurs, ça me fait penser, j'ai retrouvé le nom du partenaire qui est intégré à ECS pour le scan des containers, c'est Twistlock. Si vous voulez une solution compatible avec AWS, vous pouvez utiliser Twistlock. Je ne les ai pas essayés, donc je ne peux pas vous en dire plus, mais ils sont dans la liste des partenaires ECS. Ça me permet de répondre à la question de tout à l'heure. Fred voudrait savoir s'il peut y avoir le Go sur Lambda en 2017. Je pense qu'il y a des millions d'utilisateurs Ruby et PHP qui demandent eux aussi leur langage. On a annoncé C-Sharp par Invent. Je pense qu'on verra d'autres langages sur Lambda en 2017. Est-ce que ça sera Go, Ruby, PHP ou encore autre chose ? Je n'en sais rien du tout. Mais ça m'étonnerait absolument. A partir du moment où on supporte ces langages dans nos SDK, et effectivement ceux que je mentionne là, ils sont supportés officiellement dans les SDK AWS, il ne serait pas idiot de les voir également arriver dans Lambda. Dans quel ordre le tiercé se fera ? Vous en savez autant que moi. Alors il y a une question sur les pentests. Le compte-racine est obligatoire pour demander l'autorisation d'un test de pénétration ? Je ne suis pas sûr de comprendre la question. Si vous pouvez la préciser, je serais ravi d'y répondre. C'est un sujet intéressant, j'aimerais bien en parler, mais je ne suis pas sûr de comprendre. Ce que vous voulez dire sans doute, c'est qu'il faut être vraiment le root du compte pour demander le pentest. Oui, ça doit être ça la question. Ça ne me paraît pas choquant qu'on soit le super admin du compte pour être autorisé à demander des pentests. Bon, maintenant c'est vrai qu'effectivement, dans des structures, dans des grosses équipes, où il y a peut-être des équipes d'admin avec des comptes d'admin qui n'ont pas accès aux routes à proprement parler, oui, ça peut être… Je vois, en y réfléchissant maintenant, je pense que je comprends la question. Donc oui, effectivement, aujourd'hui, il faut pouvoir démontrer l'accès aux comptes routes pour faire le pen test. C'est une limitation de sécurité. C'est un point intéressant, je vais le noter, je vais voir si je peux trouver des infos supplémentaires là-dessus. Alors on a une question sur les load balancers, tiens ça nous changera. « Quelle est la différence fondamentale entre les ELB et les ALB ? » Alors c'est intéressant, c'est vrai qu'on n'en a pas du tout parlé cette semaine. Donc les élastiques load balancers sont les load balancers historiques d'AWS qui vous permettent de faire du load balancing entre les instances. Mais ce n'est pas leur faire injure que de leur dire qu'ils étaient relativement simples. Donc on pouvait faire du load balancing sur des ports, soit en HTTP, soit en TCP. Mais on ne pouvait pas définir de règles particulièrement évoluées. En particulier pour des architectures type microservices, c'était relativement gênant parce qu'on en venait à créer un ELB par service. Donc si vous aviez 15 microservices dans votre plateforme qui tournaient sur des ports différents, vous étiez obligé de créer 15 microservices. Donc il fallait les gérer, il fallait les payer, on voyait la limitation. Je pense que c'est vraiment l'explosion des architectures microservices qui a conduit à l'introduction de l'ALB, qui n'est pas l'armée de libération de la Bretagne, mais qui est l'application Load Balancer. Et qu'est-ce que je disais ? L'application Load Balancer, load balancer lui va vous permettre de définir un unique ALB, du coup, pour remontage, de définir un unique load balancer pour différents services. Vous allez pouvoir définir des règles de niveau 7, vous allez pouvoir définir des routes basées sur vos URL et envoyer le trafic de telle ou telle route vers tel ou tel pool de serveurs. Donc l'avantage de l'ELB c'est ça, c'est la capacité à définir des règles de niveau 7 et pas juste du lot de balancing sur des ports et par conséquent d'avoir un unique ALB pour l'ensemble de votre application même si elle est composée de plein de services. Donc moins cher, plus facile à gérer. De manière générale notre recommandation c'est de progressivement basculer sur les ALB. Tout ce que savent faire les ELB peut également être fait avec les ALB. Aujourd'hui, il n'y a plus vraiment de raison d'utiliser l'ELB. Réponse un peu longue, mais un sujet intéressant dont on n'avait pas du tout parlé. On a une question sur SimpleDB. Ça, je ne l'attendais pas. Est-ce que je peux encore utiliser SimpleDB ? Oula ! On a un vétéran. SimpleDB, pour la petite histoire, c'est un des plus vieux services d'AWS. Alors, en avant. Je ne devrais même pas vous dire. Le montrer, ça va vous donner de mauvaises idées. SimpleDB c'est l'ancêtre, je n'ose pas dire l'ancêtre de DynamoDB. Il me semble qu'on ne peut plus en créer. Je crois que le service, pour les gens qui l'utilisent encore, le service est encore là, mais il me semble qu'on ne peut plus en créer. Voilà. Quoiqu'il y a encore une tarification, allez savoir. Mon conseil c'est quand même de... Je ne suis pas sûr que ce soit un service qui ait un immense avenir. Voilà, surtout à l'échelle. Si vous avez des besoins de NoSQL, je vous invite plutôt à aller voir du côté de DynamoDB qui est plus intéressant, plus puissant, plus scalable, etc. SimpleDB, ça faisait un moment que je n'en avais pas entendu parler. Qu'est-ce qu'on a encore ? Alors, est-ce que je peux détailler la centralisation des Log Cloud Trail au sein d'un seul compte ? Est-ce qu'on peut centraliser dans un bucket S3 ou directement la console ? Alors, non, on va centraliser dans un bucket. La console, vous vous souvenez, je vais la remettre. Tiens, où est-ce qu'elle est ? La console, elle vous donne une vue incomplète de l'historique. Elle ne vous donne que 7 jours, les 7 derniers jours. Et elle ne vous donne que les événements en modification. Donc création, modification, suppression. Dans la console, on ne voit pas tout. Ce dont je parle là, c'est effectivement de centraliser, de regrouper dans un bucket S3 d'un compte principal, de regrouper les logs provenant des autres comptes. Alors la manip... Comment centraliser ? Dans la doc CloudTrail vous avez spécifiquement tout un paragraphe là dessus. Il va y avoir un peu de IAM et tout ça parce qu'il faut évidemment que vous autorisiez des accès cross-account. Il y a de la bucket policy, des choses comme ça. Mais vous avez tout ça dans la doc. Donc ça, c'est effectivement une bonne pratique. Et ça sera dans S3. Alors, qu'est-ce qu'il nous reste comme question ? On n'a plus grand-chose. Vous êtes à court de questions, vous êtes fatigué. Vous aussi. Allez, posez vos questions. Il reste encore 5 minutes. Je regarde ce qu'on a encore. Qu'est-ce qu'il nous reste ? Alors, on a une question de Guillaume sur les rôles EC2. Alors, je la lis... telle quelle. J'aime bien les rôles pour les instances EC2, moi aussi, mais lorsqu'on donne un rôle à une instance, n'est-ce pas mieux de mettre une clé pour un usager applicatif qui ne donnera accès que pour cet usager ? Ah, alors Guillaume veut mettre des credentials sur les instances EC2. Alors, Moi je ne suis pas là pour vous dire ce qu'il faut faire, pas faire, je ne suis pas là pour faire la police. Chacun a son contexte et sa façon de faire. Je ne peux que répéter que mettre des credentials sur une instance EC2, ça ne me paraît pas une très bonne idée. Donc effectivement je suis d'accord, on pourrait, imaginons, prenons un exemple très concret, disons que cette instance EC2, elle a le droit de lire des objets dans un bucket S3. On va prendre un truc simple qui parle à tout le monde. Donc oui, on pourrait créer un utilisateur IAM qui n'a pas d'accès console et qui a juste une policy qui lui permet d'aller faire list bucket et je ne sais pas, get object dans le bucket S3. Et puis on copierait ces credentials sur l'instance. Pourquoi pas ? En termes de sécurité, ça ne me plaît pas parce que le rôle vous permet de faire la même chose sans révéler les credentials. La sécurité d'un rôle sera toujours supérieure à la sécurité d'un utilisateur créé spécifiquement. Voilà, ça vous ne me convaincrez pas du contraire. Le deuxième point, c'est un problème plus opérationnel qui est de dire, il va falloir les distribuer sur l'instance, ces credentials. Donc soit l'instance est déjà créée et puis il faut trouver une manière sécurisée de copier les credentials sur l'instance, alors vous allez me dire, oui je vais faire SSH puis je vais le faire à la main. Si il n'y en a qu'une, ok, mais si vous avez 10 instances, qu'elles sont dans des groupes d'auto-scaling, vous voyez, l'opération manuelle devient impossible. Alors après vous allez me dire, oui mais bon si c'est dans un groupe d'auto-scaling, je vais construire une AMI spécifique qui va embarquer directement les credentials. Ok, pourquoi pas, mais alors du coup, cette fois vous avez des secrets dans une AMI, il faut que vous contrôliez qui est autorisé à lancer l'AMI, puisque si n'importe qui lance l'AMI, du coup le compte IAM que vous avez créé ne sert à rien, puisque par transitivité la sécurité se décale à qui a le droit de lancer l'AMI, etc. Donc vous voyez, tout ça, tout ça va se compliquer. Précision sur la question court, imaginons que nous ayons deux applications différentes sur une même instance EC2. Alors, ce n'est pas une bonne idée. Non, non, mais ce n'est pas une bonne idée. Après, on peut tout faire, ce n'est pas le problème. C'est sûr que si vous avez deux applications sur la même instance et que l'une a le droit de faire des actions et pas l'autre, oui, on peut imaginer une solution avec des credentials sur l'instance. Maintenant, si on voulait la solution propre, on aurait deux applications. Peut-être plus petites, peut-être même des T2 micro pas chers, free-tear, etc. Et puis avec des rôles différents. La séparation des responsabilités, c'est quand même aussi une bonne pratique de sécurité. Maintenant, à vous de voir quel est l'enjeu, quel est le risque, quel est le contexte, quelle est la taille de la plateforme, que font les applications. Si elles accèdent à des numéros de carte bleue, je vous conseille d'être prudent, si elle redimensionne des images pour un site web. A vous de voir, je ne suis pas là pour faire la police. Effectivement, je suis d'accord, je pense qu'on est d'accord, la bonne solution c'est une appli par instance, ou en tout cas faire en sorte que les applis qui tournent sur la même instance aient besoin des mêmes privilèges. Alors on a une question sur les user data, est-ce qu'il y a des bonnes pratiques dans l'utilisation des user data ? Alors il faut bien savoir une chose, c'est que le user data, il y a souvent une confusion qui est souvent faite, qui est que les gens pensent parfois que le user data est exécuté à chaque reboot, et ce n'est pas le cas. Je me suis déjà fait avoir, c'est pour ça que je vous en parle. Donc le user data, il est uniquement à la création de l'instance. Donc si vous faites un stop start ou un reboot, ça ne réexécute pas UserData. Donc voilà, ça c'est le premier truc à savoir, ça ne s'exécute qu'à la création. Après, des bonnes pratiques de sécurité, non, je pense pas, je ne pense pas. Les discussions philosophico-religieuses sur user data c'est plutôt qu'est-ce qu'on met dans user data et qu'est-ce qu'on met dans l'AMI. C'est la grande discussion de est-ce que je prends des AMI vierges entre guillemets et puis j'installe tout dans user data. Donc c'est sympa, ça permet de rester sur des AMI très standards. Mais ça veut dire que le temps de création de l'instance est beaucoup plus long. Imaginez que vous installez toute votre stack en user data, que vous allez chercher votre code dans un git ou un bucket S3, que vous l'installez, vous le démarrez, vous imaginez le truc, ça marche très bien l'AMI vierge qu'on provisionne complètement User Data, ok, mais ça prend du temps. Donc en particulier si vous faites de l'auto-scaling, ça peut être un problème parce que ça rallonge d'autant plus le délai, la latence entre guillemets de votre scaling. Donc l'autre solution c'est ce qu'on appelle la Golden AMI, c'est-à-dire de construire une AMI complète à chaque fois, donc dans votre pipeline de déploiement continu, vous installez votre stack sur l'AMI, vous déployez la dernière version de l'application et paf, vous créez une image et c'est ça que vous déployez. Donc ça, en termes de rapidité, de démarrage, c'est super parce qu'il n'y a aucun provisioning à faire, vous démarrez l'AMI et elle est complètement prête. Donc pour l'auto-scaling, c'est plutôt ce qu'on recommande. Maintenant, ça veut dire qu'à chaque fois que vous avez une nouvelle appli, vous devez créer une AMI. Après il y a un juste milieu, on peut dire on va peut-être installer Apache, PHP, etc. On va installer la plateforme, mais le code on vient l'installer en user data. A vous de voir. Les bonnes pratiques c'est plutôt ça. Le critère clé c'est la flexibilité versus le temps de démarrage en particulier en automatique. Peut-on héberger des données de santé ? Des données de santé sur AWS ? On a des solutions pour ça. Je vous incite à me contacter par mail et je vous mettrai en contact avec l'équipe partenaire chez nous qui pourra vous répondre sur ces sujets. C'est une question qui est un peu large, un peu compliquée. Je voulais vous faire un petit coucou. N'hésitez pas à nous contacter et je vous mettrai en lien avec les bonnes personnes. Hugo, viens montrer ta tête aussi, il n'y a pas de raison qu'on voit que moi. Merci beaucoup, courageux. Hugo, c'est lui. Je ne pourrais pas vivre sans son aide pour les webinars. Merci beaucoup. Je sais qu'il y a des personnes qui ont fait les 10. On va vous trouver. Je pense qu'on va vous envoyer un petit mail. Je crois qu'il y a un Fred qui a fait les 10. Bravo, vous êtes courageux. En tout cas, merci à tous ceux qui nous ont suivis, ne serait-ce que pour un webinar. On a eu énormément de monde cette semaine. Je pense que ça a dépassé nos attentes, en particulier pour la semaine juste avant Noël. Voilà, donc je voulais juste, je n'ai pas mis mon chapeau de Père Noël, mais j'ai mis mon t-shirt Gandalf quand même. Et je voulais vraiment tous vous remercier, je vous souhaite, j'espère que ça a été utile, je sais qu'il y a plein de questions encore, on va voir comment les traiter, peut-être en podcast, pourquoi pas. On commence à travailler sur les prochains webinars, de janvier. Voilà, on a passé une semaine très très dense, très très riche, je suis vraiment super super content d'avoir pu passer toutes ces heures avec vous, j'espère que vous avez appris plein de choses et qu'on se retrouvera l'année prochaine pour encore plein de webinaires et plein de services. Et puis bon bien sûr, il est 17h49 en France, un peu moins au Canada, ça va être l'heure de rentrer à la maison et d'aller fêter Noël, donc je vous souhaite à tous et à vos familles un très très joyeux Noël, profitez-en bien, mangez bien, buvez bien, avec prudence si vous roulez sur les routes glacées du Québec et reposez-vous, nous aussi on va aller se reposer un peu, je ne vous cache pas que là on en a un peu besoin et puis on vous retrouve en janvier en pleine forme pour encore beaucoup de sujets sur AWS. Merci infiniment de votre confiance, merci pour toutes vos questions. Joyeux Noël, bonne année et rendez-vous en janvier. Ciao, à bientôt.