Presentation du modele de securite AWS

Transcript

Bonjour à tous, je pense que nous pouvons commencer, il y a encore des participants qui arrivent mais ils prendront le train en route. Bonjour à toutes et à tous, je suis Julien Simon, je suis évangéliste technique chez AWS. J'ai le plaisir d'animer ce nouveau webinaire sur le modèle de sécurité AWS. Aujourd'hui avec moi, j'ai Hugo de l'équipe marketing. Merci Hugo pour l'organisation, les inscriptions, les emails. On n'aurait pas pu y arriver sans toi. Nous avons un webinaire aujourd'hui sur le modèle de sécurité. Avant d'oublier, je vous rappelle que nous en avons un demain, sur les stratégies de migration de données et en décembre nous aurons la Security Week qui comprendra une dizaine de webinars spécifiques à la sécurité. Vous trouverez les informations sur notre site www.amazon.com dans la rubrique événements. Je vous propose de commencer. L'agenda de la présentation, on va commencer par une petite introduction sur la sécurité telle que nous la voyons et telle que nos clients en parlent. Ensuite nous parlerons du modèle de sécurité partagée qui est vraiment le cœur de la discussion pour bien vous expliquer quelles sont nos responsabilités respectives en termes de sécurité. Ensuite je vous parlerai de conformité dans le cloud AWS et puis ensuite nous détaillerons un certain nombre de bonnes pratiques et d'outils que vous pouvez utiliser pour mettre en place un bon niveau de sécurité sur votre plateforme. Et enfin, je conclurai par quelques pistes pour obtenir de l'aide sur les aspects sécurité comme sur le reste si vous en avez besoin. Commençons donc par AWS et la sécurité. Le premier point qui est essentiel, c'est qu'AWS est utilisé aujourd'hui par plus d'un million de clients chaque mois. Et pourquoi est-ce que ce point est important pour la sécurité ? Tout simplement parce que ce million de clients est, comme vous pouvez l'imaginer, extrêmement divers. On va trouver de très petites entreprises, des développeurs individuels même, et on va également trouver de très grandes entreprises qui travaillent dans des secteurs d'activité extrêmement variés. Et donc ce million de clients de toute taille et de tout secteur d'activité nous permet d'être exposés à des exigences de sécurité et de conformité qui sont extrêmement diverses. Il est bien évident qu'une start-up en forte croissance aura des exigences de sécurité et de conformité différentes, des moyens différents, des technologies différentes, qu'une grande entreprise du CAC 40. Et même au sein des grandes entreprises, dont j'ai listé quelques exemples ici, on se doute que les besoins de sécurité sont extrêmement différents dans le secteur financier, si on parle de la Société Générale ou de Fortuneo par exemple, qui sont parmi nos clients. On a des aspects sécurité, mais on a des aspects conformité également, des aspects réglementaires qui sont extrêmement importants. Dans l'industrie, par exemple chez Veolia ou chez Pfizer, on va trouver des enjeux tout aussi importants, mais des réglementations différentes, des certifications différentes. Et puis dans le monde des médias, par exemple chez Netflix ou chez Canal+, ou dans les télécoms, chez Vodafone, on va trouver encore d'autres façons d'implémenter la sécurité, d'autres régulations. Et donc, le fait que tous ces clients et cette diversité de clients utilisent AWS, ça nous permet au fil du temps d'apprendre quels sont les problèmes de sécurité et de conformité de nos clients et de livrer des solutions, des fonctionnalités qui sont à même d'y répondre. Cette richesse, cette diversité des clients, ça nous permet d'avoir une couverture très large en termes de besoin de sécurité. Par conséquent, nous allons être amenés à nous adapter en permanence aux demandes de nos clients. Sur ce graphe, vous voyez le nombre de fonctionnalités qui ont été livrés par AWS chaque année à ses clients, 722 en 2015, et bien évidemment parmi ces 722 fonctionnalités, un nombre important est lié à la sécurité. Et ça fait tout à fait écho à ce que je disais à l'instant, c'est-à-dire que le fait d'avoir de plus en plus de clients, de plus en plus divers, ça nous demande, ça exige de notre part de développer des fonctionnalités, de compléter nos fonctionnalités produits et nos fonctionnalités de sécurité. Vous voyez cette accélération importante, plus on grossit, plus on innove. Pour information, au 30 septembre 2016, nous avons déjà réalisé 709 nouvelles fonctionnalités. J'imagine qu'au 30 septembre 2016, j'imagine qu'aujourd'hui, 18 octobre, on a déjà dû dépasser le chiffre de 722 de l'année dernière. Donc les paris sont ouverts sur le nombre de fonctionnalités qui auront été réalisées au 31 décembre. Mais vous voyez que parmi ces fonctionnalités, il y a beaucoup de sécurité et ça continuera parce que c'est un point extrêmement important pour nous. Au-delà des fonctionnalités que j'évoquerai tout à l'heure qui sont réalisées chaque semaine. Nous avons également, vous le savez, un très vaste réseau de partenaires, en particulier de partenaires logiciels dont les solutions sont disponibles sur l'AWS Marketplace, donc un ensemble d'images de machines virtuelles prêtes à être démarrées, prêtes à être utilisées et prêtes à être déployées au sein de votre infrastructure. Donc vous pouvez utiliser, en plus de la sécurité que vous fournissent les mécanismes AWS, vous pouvez aller chercher dans notre place de marché telle ou telle solution de Fortinet, Trend Micro, SafeNet, etc. et la déployer de manière extrêmement simple dans votre infrastructure. Et tout ça fait qu'aujourd'hui, cette enquête de Forester qui commence à dater un petit peu, je pense qu'elle sera prochainement mise à jour mais elle est quand même importante. Cette enquête de Forester place Amazon Web Services comme un des leaders, pour ne pas dire le leader de la sécurité des clouds publics. Et tout ça vraiment n'est pas un mystère, c'est vraiment lié au fait que AWS existe depuis une dizaine d'années et que, comme on dit chez nous, il n'y a pas de courbe de compression pour l'expérience. C'est vrai pour le cloud en général et c'est vrai pour la sécurité du cloud. Donc le million de clients, les problématiques qu'ils nous ont exposées, qu'ils nous ont demandé de résoudre au travers de nos produits, au travers de nos partenaires, nous permettent d'avoir aujourd'hui cette position agréable, d'être reconnus par les analystes comme le leader en termes de sécurité du cloud public. Mais que disent nos clients finalement ? Parce que les enquêtes d'analystes c'est très bien mais vous savez qu'on préfère toujours que ce soit nos clients qui parlent de nos produits. Alors voilà un premier exemple, ce monsieur, monsieur Tom Soderström qui est le CTO du Jet Propulsion Laboratory de la NASA. Pour les gens qui ne sont pas familiers de la NASA, c'est le labo de la NASA qui fabrique en particulier les rovers qui sont allés sur Mars. Ils sont clients d'AWS depuis longtemps, ils ont beaucoup d'histoires à raconter. Je vous ai mis l'URL de la vidéo en bas du slide, vous pourrez aller la voir, c'est vraiment incroyable. Et que dit le CTO du JPL ? Il dit que selon lui, les plateformes du JPL sont plus en sécurité dans le cloud que dans leur propre data center. C'est quand même une affirmation assez forte venant d'une entité aussi prestigieuse que le JPL. De même, Capital One, qui est une des dix plus grosses banques américaines, qui opère plus de 40 millions de comptes bancaires, utilise AWS et leur DSI, M. Alexander, est venu à notre conférence ReInvent l'année dernière pour témoigner de l'usage d'AWS par Capital One et en particulier pour parler de sécurité. De même, vous voyez, sa citation est très similaire à la précédente, il est convaincu que grâce à AWS, il est capable de faire fonctionner ses applications de manière plus sécurisée que dans ses propres data centers. Donc on imagine bien que quand un DSI d'une aussi grosse banque que Capital One monte sur scène pour dire ce genre de choses, on n'est pas dans l'effet d'annonce, on n'est pas dans le marketing, on est dans la réalité, on est dans l'opérationnel. Là aussi je vous ai mis le case study de Capital One, vous pourrez aller le consulter ultérieurement. Alors la NASA, ok, énorme organisation, le Capital One, énorme organisation, mais qu'en est-il de plus petites structures ? Et bien finalement on va retrouver les mêmes bénéfices pour les petites structures. Je vous ai ici mis un témoignage de la Nouvelle République, un groupe de médias important en France, un groupe de presse important en France, un des dix plus gros. Et eux ont fait une migration assez massive de leur infrastructure vers AWS, et en particulier de leurs applications SAP. Et donc, vous voyez ce qu'en dit leur DSI, M. Gendre, on dit que non seulement les choses se sont passées beaucoup plus vite aujourd'hui, que s'ils avaient dû faire les choses dans leur data center, mais surtout qu'ils ont atteint un niveau de sécurité qui était au moins équivalent à ce qu'ils étaient capables de faire. Donc ça reprend un thème qu'on développe souvent, qui est de dire la sécurité parfois est perçue comme un frein à l'innovation, un frein à l'agilité, et c'est parfois le cas. Mais avec AWS, on peut concilier l'agilité, la rapidité de déploiement et la sécurité. Ce qu'on appelle « move fast and stay secure », qui est vraiment un point important pour nous, de dire la sécurité, ne vous en passez surtout pas, parce qu'avec nous, elle n'est pas un frein. Elle n'est pas un frein. Donc ne coupez pas les virages, ne prenez pas de risques. Implémentez votre sécurité correctement et vous verrez que vous irez aussi vite qu'avant. Si vous voulez en savoir plus sur le déploiement de solutions SAP sur AWS, vous avez également la référence sur le slide. Et puis j'ai tenu à ajouter quand même une dernière référence client qui est une startup que vous connaissez peut-être qui s'appelle Payplug. Payplug est une startup qui personnalise les pages de paiement pour les e-commerçants. Si vous passez beaucoup de commandes en ligne, vous avez sans doute remarqué qu'une fois que vous arrivez sur la page de paiement, bien souvent vous quittez le site web de l'e-commerçant et vous arrivez sur une page de sécurité qui, il faut bien le dire, est souvent assez laide, qui n'est plus sur le site de l'e-commerçant, qui n'est pas à sa charte graphique, etc. Et il se trouve que ça décontenance un certain nombre d'internautes et que c'est une des causes importantes d'abandon de transaction. Et donc Payplug va héberger cette page pour les e-commerçants à leur charte graphique, en la personnalisant, en la rendant la plus efficace, en maximisant le taux de conversion. Et il se trouve que pour pouvoir faire ça, ils vont évidemment devoir recevoir les informations de carte bleue que vous allez rentrer pour payer votre transaction. Et ça, ça nécessite l'obtention d'une certification qui s'appelle PCI DSS Service Provider, qui est un standard extrêmement important dans le monde du paiement. Et que traditionnellement, pour des startups, des petites entreprises, il était impossible d'obtenir ces certifications parce que le travail nécessaire, le travail préparatoire était prohibitif. Il fallait des personnes dédiées pour travailler sur ces certifications et c'était prohibitif. Et en s'appuyant sur AWS, puisque Payplug tourne intégralement dans AWS, Payplug a pu se faire sans grande difficulté certifier PCI DSS et donc innover et proposer à ses clients à la fois une expérience client riche et un niveau de sécurité reconnu. Voilà, donc très belle histoire qui montre qu'en s'appuyant sur AWS, même de petites structures peuvent arriver à des niveaux de sécurité dignes de grands acteurs. Et donc pour conclure sur cette introduction et sur ces références clients, la sécurité pour AWS c'est la priorité numéro un. On est parfaitement conscient de la confiance que nous font les clients en nous confiant, en hébergeant chez nous leur infrastructure, en y plaçant leurs données et donc on est obsédé par la sécurité. On considère qu'aucun produit, aucun feature, rien ne doit sortir, rien ne doit être réalisé si le niveau de sécurité n'est pas adéquat. Et donc ça, ça passe par trois choses, le modèle de sécurité dont je vais parler juste après, la taille de l'équipe sécurité d'AWS qui est énorme, on est sans doute une des entreprises qui emploient le plus de monde dans les sécurités. Pourquoi ? Tout simplement parce que, une fois de plus, c'est notre priorité numéro un. On ne peut pas se permettre d'avoir un incident, on ne peut pas se permettre de briser la confiance que les clients nous ont accordée. Et donc on investit énormément sur la sécurité de notre cloud. Et le troisième point qui est essentiel, comme vous l'avez vu dans les témoignages clients, c'est que tous ces développements de sécurité, eh bien, ils profitent à tous. Il n'y a pas un niveau de sécurité pour les petites startups et un niveau de sécurité pour les boîtes du CAC 40 ou les gouvernements ou la NASA. Tout le monde est logé à la même enseigne, tout le monde profite du même niveau de sécurité maximum. Un petit peu comme pour les autres services finalement, ça permet à tout le monde de se battre à armes égales et de bâtir les plateformes les plus sécurisées possible. Je vais parler maintenant du modèle de sécurité partagée qui est vraiment un point essentiel pour bien comprendre comment se partagent les responsabilités entre AWS et ses clients. Alors là il y a vraiment un concept qui est vital, je vais essayer de l'expliquer le plus clairement possible, c'est de comprendre qu'il y a cette ligne de démarcation, ce pointillé que vous voyez sur le slide qui sépare finalement le socle d'infrastructures et de services d'AWS et les applications et les données du client. Et la façon dont on le définit, c'est qu'AWS se charge de la sécurité du cloud. Et dans nos documentations en anglais, vous trouverez souvent ça sous le nom « Security of the cloud ». Ça recouvre quoi ? Ça recouvre la sécurité de l'infrastructure physique à proprement parler, c'est-à-dire les data centers, les régions, les zones de disponibilité, les edge locations de notre CDN. Bref, toute l'infrastructure physique, le contrôle des bâtiments, l'accès strictement contrôlé au matériel, etc. Ça, c'est évidemment de la responsabilité d'AWS. Au-dessus de l'infrastructure physique, on a les services de base, c'est-à-dire les services de calcul, l'hyperviseur pour EC2, les containers pour les services de containers, etc., les systèmes de stockage, les systèmes de base de données, le réseau, l'architecture réseau, tout ça, évidemment, c'est à nous de veiller qu'il n'y ait pas de faille de sécurité dans notre hyperviseur, qu'il n'y ait pas de faille de sécurité dans notre archi-réseau, qu'il n'y ait pas de faille de sécurité dans nos autres services. Donc ça, c'est nous, nous le faisons et nous essayons d'offrir le niveau de sécurité maximum. Pour le reste, pour ce qui est des actions que mènent les clients, c'est-à-dire vous, la création de plateformes, le lancement de machines virtuelles, le déploiement d'applications, le chargement de données, l'exécution des applications, etc. Ça, c'est à vous de vous en charger. Ça, c'est ce qu'on appelle la sécurité dans le cloud, security in the cloud. Et donc, il est vraiment important de comprendre cette distinction. Le socle infra et les services, c'est nous. Ce que vous faites dans le cloud, ce que vous déployez, c'est vous. Je vais prendre un exemple pour être très concret. Imaginons que vous déployez une application web avec un serveur web et une base de données, disons, MySQL. Nous travaillons sur la sécurité de la machine virtuelle, une fois de plus, l'hyperviseur, etc. En revanche, ce que vous allez installer sur cette machine virtuelle, le serveur web que vous allez installer, le code applicatif que vous allez déployer, les patches de sécurité sur l'OS, que ce soit Linux ou Windows, de la machine virtuelle, etc. Tout ça, c'est à vous de le faire. C'est à vous de veiller à déployer une version de votre serveur web sécurisé, à déployer votre environnement Java, PHP à jour, etc. Vous allez charger des données dans votre base de données, c'est à vous de veiller au chiffrement de ces données. Il faut bien comprendre cette distinction, on va rentrer un petit peu plus dans les détails, mais en première analyse, on va dire le socle c'est nous, ce qui se passe à l'intérieur, c'est vous. Il y a des cas particuliers, en tout cas plus précis. On va rentrer un petit peu plus dans les détails. Imaginons que vous utilisiez des services d'infrastructure, ce qu'on appelle de manière fréquente les services IaaS, infrastructure. Donc par exemple EC2, EBS, les VPC, où vous construisez finalement votre infrastructure à la main. Donc la couche jaune, ça correspond à ce que je décrivais tout à l'heure, l'infrastructure physique, les services de base, ça c'est nous. Au-dessus, c'est vous. Donc vous êtes en charge de chiffrer par exemple les systèmes de fichiers de vos instances. Vous êtes en charge de mettre en place la protection de votre trafic réseau, HTTPS ou autre. Vous êtes en charge de patcher votre OS pour qu'il soit à jour. Vous êtes en charge de vos règles de firewall. Vous êtes en charge d'avoir une version de Java, PHP, Ruby, etc. qui soit à jour. Vous êtes en charge de protéger vos données. Donc si vous utilisez les services IaaS, il y a finalement encore pas mal de travail de sécurité à mener de votre côté. On verra tout à l'heure dans les bonnes pratiques comment le faire. Si vous utilisez des services de plus haut niveau qui s'appuient eux-mêmes sur des instances EC2 mais automatiquement, qui vont créer de l'infrastructure automatiquement, comme par exemple RDS pour les bases de données relationnelles, Elastic Beanstalk pour le déploiement de code ou Elastic MapReduce pour les clusters Hadoop. Là vous voyez, puisque AWS va créer pour vous des instances EC2, elle va mettre en place automatiquement de l'infrastructure pour vous, là on remonte d'un cran. Par exemple dans RDS, c'est quand on démarre une instance MySQL ou une instance Postgre ou Oracle, et bien là, comme c'est nous qui le faisons, nous allons le faire sur un operating system et avec une plateforme MySQL, SQL Server, Oracle, etc., dont nous allons gérer la sécurité. Donc là, on prend en charge ce point-là. Il va rester pour vous la sécurité des données, la sécurité du trafic, etc. Donc vous voyez, c'est aussi un argument pour utiliser des services de plus haut niveau. Vous avez dans AWS la liberté de faire du IaaS, mais comme dirait Spiderman, avec de grands pouvoirs viennent de grandes responsabilités. Et donc si vous faites tout vous-même, vous devez aussi gérer la sécurité. Si vous utilisez des services de plus haut niveau, finalement vous nous déléguez une partie du travail et on va aussi prendre en charge la sécurité. Et puis si on pousse ce raisonnement à l'extrême en utilisant des services gérés, donc des services managés comme S3 pour le stockage ou DynamoDB pour le NoSQL, et bien là on voit qu'on va remonter encore d'un cran puisque là il n'y a plus d'instance EC2, on est vraiment sur des services intégralement géré par AWS avec de l'infrastructure dédiée. Et donc là, la sécurité réseau va être prise en charge par nous, le chiffrement va être pris en charge par nous, etc. Et il vous restera juste la sécurité des données stricto sensu. Donc vous voyez, le modèle de sécurité s'applique toujours, il y a toujours une partie faite par AWS, la partie basse, la partie la plus haute qui reste à votre charge, mais l'emplacement du curseur varie en fonction du service que vous utilisez. Donc si vous faites du IaaS, vous avez encore pas mal de travail. Si vous faites du platform as a service ou des services managés comme ceux-là, et bien finalement, non seulement vous vous déchargez de la gestion de l'infrastructure, mais vous vous déchargez aussi de la gestion de la sécurité, ce qui est à mon avis un bon argument pour promouvoir l'utilisation de ces services. Parlons un peu de conformité, qui est un élément important pour beaucoup d'entreprises. Vous trouverez sur l'URL que j'ai indiqué sur le slide la liste des certifications obtenues par AWS. Rassurez-vous, on ne va pas toutes les détailler. Il y en a une grande partie qui sont des certifications américaines fédérales, qui sont évidemment essentielles pour le marché américain ou pour des entreprises qui doivent opérer aux États-Unis. Si vous déployez des plateformes qui sont utilisées par une agence gouvernementale américaine, une agence fédérale, vous devrez répondre à ces certifications comme FIPS ou FedRAMP ou ce genre de choses. On a aussi des certifications un peu plus européennes comme ISO 27001 qui est la certification pour la gestion de systèmes d'information sécurisés, ISO 9001, SOC 1, 2, 3 qui est un classique également. Bref, une liste assez longue de certification. Vous trouverez la liste complète sur le site web. Vous trouverez les rapports publics également sur le site web. Si vous voulez en savoir plus, si vous voulez les rapports d'audit détaillés, c'est possible, mais ce sont des discussions sous NDA. Je vous encourage à vous rapprocher de votre camp de manager si vous avez besoin de ce genre d'informations. Dernier point que je peux citer là-dessus, c'est que les cibles de ces certifications sont très très larges. Elles couvrent toutes les régions et tous les services. Donc ne vous posez pas la question de savoir est-ce que la région Francfort est plus sécurisée que la région Dublin. Non, ce sont les mêmes certifications, les mêmes règles, les mêmes mécanismes qui s'appliquent dans les deux cas et dans toutes les régions et à tous les services. On essaie de faire les choses de manière la plus globale possible. Je vous renvoie vers le site web pour plus de détails sur telle ou telle certification. Comparons la mise en conformité d'un système que vous bâtiriez sur site chez vous, dans votre data center, et chez AWS. Vous voyez, il y a sept points, on va les prendre un par un. Le premier point, c'est qu'évidemment, si vous êtes sur site, si vous construisez votre propre infrastructure, vous partez de zéro. Peut-être que vous avez déjà un petit socle d'infrastructure, mais en tout cas, la sécurité de cette nouvelle plateforme ou de ce bout de plateforme part de zéro. Chez nous, vous partez sur la base de services qui sont déjà certifiés, déjà audités. On a vu des exemples tout à l'heure avec RDS, avec EMR pour Hadoop, avec S3 pour le stockage. Vous utilisez finalement déjà des services qui sont au plus haut niveau de sécurité d'emblée. Le deuxième point, c'est que, et là les développeurs ne me démentiront pas, il est rare qu'on puisse avoir le temps ou les ressources ou le budget pour inclure la sécurité d'emblée dans le projet. Généralement, on a déjà pas mal de travail pour faire fonctionner l'application et malheureusement, souvent, on se dit qu'on verra plus tard la sécurité. C'est là que les problèmes commencent. Sur AWS, cette question ne se pose pas puisque la sécurité est incluse, elle est complète, est par construction présente dans nos services. Donc vous n'avez pas à réfléchir, est-ce qu'il faut la mettre, est-ce qu'il ne faut pas la mettre, est-ce que ça prend du temps, est-ce que ça ne prend pas de temps. Elle est là, vous l'activez, vous vous en servez. Vous gagnez énormément de temps comme ça. Le troisième point sont les audits. Les audits de sécurité dans des entreprises d'une certaine taille vont être faits généralement par une équipe interne qui va auditer les différentes applications. Et donc, sans porter de jugement de valeur, la qualité des audits va dépendre de la qualité de cette équipe, qui peut être excellente ou pas, selon les cas. Chez AWS, les audits sont effectués par des experts externes qui travaillent à très haut niveau, qui travaillent pour des gouvernements avec un niveau d'exigence le plus élevé possible. Donc, vous avez les meilleurs experts, les plus tatillons, les plus pointus qui travaillent sur nos plateformes. Il est probable que, sauf à être un très gros compte, une très grosse banque, etc., vous ne puissiez pas financer des audits à ce niveau de qualité-là. Le quatrième point, c'est finalement le... La sécurité de votre plateforme, elle ne concerne que vous-même, en bien ou en mal. C'est-à-dire que tous les efforts de sécurité que vous allez faire, ils vont sécuriser ce bout de plateforme, mais peut-être que pour le prochain projet, il faudra tout recommencer. C'est peut-être difficile de capitaliser. Dans le cas d'AWS, tous les progrès de sécurité faits sur tel ou tel service, ou telle nouvelle fonctionnalité, bénéficient instantanément à tout le monde. Donc il y a un effet d'échelle finalement lié au nombre de clients, lié aux partenaires, etc. qui fait monter chaque jour le niveau de sécurité. Le point numéro 5, ce sont les audits externes que vous allez faire. Et au mieux, dans la plupart des cas, vous aurez du budget pour le faire une fois par an, peut-être deux fois par an, et puis ça prend aussi du temps et des ressources en interne. Chez nous, la vérification est faite en permanence par nos propres équipes et par des experts et par les experts de nos clients qui testent en permanence la sécurité de leurs applications dans notre cloud et donc la sécurité de notre cloud. Et donc une fois de plus, on a cet effet vertueux de réseau où les progrès qui sont faits, les efforts qui sont faits par la communauté des utilisateurs bénéficient à tout le monde. La vérification de conformité, point numéro 6, elle va être spécifique à votre plateforme, c'est-à-dire que vous allez faire tout ce travail, tous ces tests, tous ces audits sur un projet et comme je disais tout à l'heure, il est probable que pour le prochain projet, les problématiques soient différentes et qu'il faille recommencer. Dans le cas d'AWS, la conformité est basée sur un projet, un million de clients avec comme je disais tout à l'heure des business très différents, des tailles très différentes. Donc on a une couverture de test, une couverture de conformité qui est infiniment plus large et infiniment plus complète que ce qu'une entreprise pourrait faire sur un seul projet. Et le dernier point, et ça tout le monde le sait, la sécurité d'une plateforme c'est valable à l'instant T. Une fois que vous avez passé votre audit, il est bien possible que le lendemain, une nouvelle vulnérabilité arrive et qu'il faille déjà en être au courant et puis ensuite il faille la corriger sur votre plateforme. Et donc la sécurité c'est une course permanente, c'est une lutte permanente pour rester à l'état de l'art et ça aussi si on veut le faire correctement, ça prend du temps, ça coûte du budget, il faut des équipes pour le faire. Chez nous, une fois de plus, nos équipes et les équipes de nos clients vont être à l'affût de toute vulnérabilité et nous pousser en permanence à trouver les problèmes, à les corriger et à livrer des fonctionnalités toujours plus sécurisées. Et donc, ces sept points permettent de voir ce que vous allez gagner finalement en termes de rapidité mais aussi de tranquillité finalement, de paix si vous déployez sur AWS. Vous bénéficiez finalement d'un travail collectif de tous les clients, de toutes les équipes AWS pour durcir le niveau de sécurité du cloud et avoir un niveau de conformité élevé. Passons maintenant aux bonnes pratiques et aux outils. Alors le premier conseil qui est une évidence sans doute, mais bon, certaines évidences méritent d'être rappelées, c'est que nous vous conseillons fortement de segmenter vos environnements. Il est assez facile au sein de votre compte de créer des VPC, donc des réseaux privés virtuels qui vont communiquer les uns avec les autres ou pas, mais en tout cas qui vont servir de frontières finalement entre les différents morceaux de votre plateforme. Donc par exemple ici on voit qu'on a un VPC avec les sites web de la société qui sont accessibles depuis internet et puis on pourrait avoir un deuxième VPC avec des applications internes, un ERP, une CRM, etc. On pourrait avoir un troisième VPC avec les environnements de développement, les tests, le bac à sable pour les équipes techniques. Et puis on pourrait avoir un quatrième VPC avec toute la partie analytics, reporting, big data, etc. Et puis en parallèle de tout ça, le stockage, et la sauvegarde dans nos services comme S3 et Glacier pour l'archivage. Donc vous voyez, ça, bien sûr on peut le faire aussi avec de l'infrastructure physique, on peut segmenter physiquement son réseau, c'est tout à fait envisageable. Chez nous, vous aurez d'autant plus de facilité à le faire que créer un VPC, ça prend une minute. Et que vous pourrez y appliquer une politique de sécurité particulière, des règles réseau particulières, etc. Donc vraiment segmenter les environnements au sein de votre compte ou de vos comptes, c'est vraiment la première bonne chose à faire. Et voilà, une fois que vous avez fait cette segmentation, vous pouvez en fonction des équipes, en fonction des besoins des différentes équipes, donner accès ou pas à telle ou telle partie de l'infrastructure. On imagine que les équipes projet auront accès au VPC de dev et de test et peut-être pas à la partie analytics qui est réservée aux fonctions sales et marketing, etc. Donc un découpage clair de votre plateforme, un découpage clair de votre organisation et puis des règles de bon sens pour limiter les accès aux stricts nécessaires. Une fois que vous avez réfléchi à ce découpage, vous allez devoir gérer l'identité des utilisateurs de votre plateforme. Pour cela, vous utiliserez un service qui s'appelle IAM au sein d'AWS, Identity and Access Management, qui va vous permettre de contrôler de manière extrêmement fine qui fait quoi dans votre environnement. Voir même quand, sur quelle plage horaire, et à partir d'où, à partir de quelle adresse IP, à partir de quel site. Et donc quand je dis que vous pourrez le faire extrêmement finement, c'est-à-dire que vous pourrez le faire API par API. Je n'ai pas le temps aujourd'hui de rentrer dans les détails, je vais regarder ça pour la Security Week de décembre, mais vous verrez qu'on peut définir de manière extrêmement fine avec une granularité extrêmement fine, les droits d'accès d'un utilisateur. Vous pouvez même aller encore plus loin en intégrant de l'authentification multifacteur, donc étendre finalement le contrôle d'accès avec mot de passe, enfin identifiant mot de passe et un token généré par une authentification multifacteur de type Google Authenticator ou un petit device matériel. Et puis enfin, si vous êtes dans une grande entreprise, que vous avez déjà un annuaire, que vous avez déjà peut-être une plateforme de type Single Sign-On, vous pouvez également intégrer IAM avec cet annuaire ou avec ce SSO, pour avoir une fédération d'identité entre les droits sur votre infrastructure physique, et les droits sur votre infrastructure cloud. Vraiment IAM c'est vraiment le pilier de la sécurité dans votre plateforme pour donner les droits aux utilisateurs et pour définir les rôles des différentes parties de votre infrastructure. Arrivera un moment où vous allez lancer des serveurs, une fois que vous aurez défini les permissions etc., vous allez démarrer des instances avec Amazon EC2 et comme vous m'avez bien écouté tout à l'heure, vous savez que vous êtes donc responsable de la sécurité de ces instances. Puisque là, Security in the Cloud, là c'est vous. Donc vous allez choisir une image, une Amazon Machine Image dans notre catalogue, Linux, Windows, etc. Chaque instance doit avoir le minimum de privilèges. Vous pouvez installer sur cette instance vos logiciels favoris de sécurité. Si c'est une machine Windows, peut-être que vous aurez envie d'avoir un antivirus. Si c'est une machine Linux, peut-être que vous aurez envie d'avoir un système anti-intrusion, etc. Vous avez la main, c'est à vous de jouer. Dernier point, nous avons un service qui s'appelle Amazon Inspector qui permet d'auditer une instance via le déploiement d'un agent sur cette instance, d'auditer le contenu de l'instance, donc l'OS, les applications qui sont installées sur l'instance pour éventuellement y détecter des failles de sécurité et vous indiquer comment y remédier. Amazon Inspector est un outil qui fait partie de notre portefeuille et que vous pouvez évidemment utiliser, qui est relativement simple à utiliser. Mais vraiment, le message clé, c'est ce qui se passe à l'intérieur de l'instance, c'est à vous de jouer. Et puis, bien sûr, il y a les données. Les données, c'est simple, notre recommandation, c'est de chiffrer. Voilà, à chaque fois que vous pouvez chiffrer, faites-le. La différence entre une fuite de données chiffrées et une fuite de données non chiffrées est que si c'est des données chiffrées, en particulier si c'est des données personnelles, c'est évidemment désagréable, mais c'est tout. Si vous vous faites voler des données non chiffrées, des données de vos clients ou des données confidentielles de l'entreprise, les conséquences sont évidemment beaucoup plus graves et peuvent même mettre en danger votre entreprise. Donc le conseil est de tout chiffrer. Il n'y a pas à se poser de questions de ce qui est important ou non. D'autant plus que sur tous nos services de stockage de données, vous avez la possibilité en un clic, en un appel d'API, ou en un paramètre de chiffrer tout automatiquement. Par exemple, dans EBS, qui est le stockage attaché aux instances EC2, lorsque vous créez un volume EBS, il y a un paramètre qui dit « encrypted, yes or no ». Il suffit de mettre « yes » et il sera chiffré. Je ne vois aucune raison de ne pas mettre « yes » dans ce paramètre. Vous pouvez bien sûr surchiffrer, vous pouvez les chiffrer au niveau bloc avec nos mécanismes de chiffrement et puis formater ces volumes avec un système de fichiers cryptographiques ou déployer des utilitaires de chiffrement sur vos instances pour chiffrer de manière supplémentaire avec vos propres clés. Votre application pourrait gérer ça aussi. Si vous voulez le faire automatiquement, si vous voulez vous appuyer sur nous pour le faire, c'est très simple. Mais vous pouvez aussi, et nous vous conseillons aussi, de le faire avec un système de fichiers crypto par exemple. C'est très facile à déployer. S3, c'est pareil. Vous pouvez aisément chiffrer vos buckets S3. Une clé de chiffrement est créée automatiquement dans S3, dans votre compte, pour vous. Il suffit de dire que vous voulez chiffrer ce bucket et c'est tout. Vous pouvez aussi charger vos propres clés de chiffrement et amener vos propres clés pour chiffrer S3. Redshift, qui est notre data warehouse, même histoire, vous pouvez chiffrer automatiquement et vous pouvez chiffrer avec vos propres clés. Même chose pour RDS, notre service de base de données relationnelles, vous pouvez amener des clés via un service qui s'appelle KMS, Key Management Service, pour chiffrer MySQL ou Postgre. Et nous proposons aussi les mécanismes de chiffrement pour SQL Server et Oracle. De manière générale, tous les services qui contiennent des données chez nous vont vous proposer un chiffrement par défaut avec une clé attachée à votre compte ou la possibilité de charger vos clés, généralement avec KMS, pour avoir un niveau de sécurité accru. Donc vraiment, j'insiste sur ce point, il n'y a pas de raison de ne pas chiffrer vos données. Ça ne coûte pas plus cher, tous ces mécanismes-là sont inclus dans le service. Au minimum, chiffrez tout avec les clés que nous créons dans vos comptes. Et si vous avez des problématiques de sécurité supplémentaires, vous pouvez faire des chargements de clés avec KMS et rajouter une couche de chiffrement d'utilisateurs. Je le dirai une dernière fois, chiffrez tout, s'il vous plaît. Un autre point important, c'est la supervision. Certes, vous aurez implémenté toutes les bonnes pratiques dont on vient de parler, mais comment savoir que les droits d'accès que vous avez mis en place sont respectés, comment garantir qu'effectivement personne n'a accès de manière détournée à telle ou telle donnée, à telle ou telle instance. Et en cas d'audit, comment démontrer formellement que la politique de sécurité est bien respectée. Et en cas d'incident de sécurité, comment voir ce qui s'est passé, quelle traçabilité on peut avoir. Pour ça, nous avons construit un produit qui s'appelle CloudTrail, qui est un produit qui va consigner, qui va tracer tous les appels d'API qui sont faits dans votre compte et qui va les écrire dans un journal dans S3. Tous les appels d'API, qu'ils soient faits via la console, via la ligne de commande ou via des SDK, seront enregistrés de manière immuable dans un journal S3. Ça vous donne une trace exhaustive de toutes les opérations, qui a fait quoi quand et à partir de quelle adresse IP. La plupart des services AWS sont intégrés avec CloudTrail, et nous continuons à ajouter des services supplémentaires dans CloudTrail. L'idée est d'avoir tous ces appels d'API au même endroit, d'être capable de faire des recherches dedans, que ce soit pour surveiller de manière routinière, que ce soit dans le cas d'un audit ou que ce soit suite à un incident de sécurité pour comprendre ce qui s'est passé et qui a touché à quoi. Donc c'est vraiment un outil que je vous conseille d'activer, c'est un outil régional, donc pensez à l'activer dans toutes les régions, il s'active en un clic et ensuite il consigne partout dans toutes les régions les appels d'API qui sont faits. Bien évidemment, ces journaux peuvent être ingérés, exportés vers des outils de partenaires comme Splunk par exemple pour faire de l'analyse plus poussée sur les logs. Donc vraiment CloudTrail, aucune raison de ne pas l'activer, le coût est minime et il vous donnera en cas d'audit ou en cas d'incident de sécurité une visibilité vitale sur ce qui se passe à l'intérieur de votre plateforme. Donc chiffrez tout s'il vous plaît et activez CloudTrail partout. Dernière partie de ma présentation, et ensuite on passera aux questions. Comment obtenir de l'aide ? Comment se faire aider sur ces sujets de sécurité ? Le premier niveau qui est vraiment tout simple, qui est à la portée de tous, c'est d'utiliser un de nos produits qui s'appelle Trusted Advisor. Trusted Advisor est un outil qui va jeter un œil à ce qui se passe à l'intérieur de votre compte. Il ne concerne pas que la sécurité, il va faire des recommandations de réduction de coût, de performance, de haute disponibilité, et pour ce qui nous concerne aujourd'hui, de sécurité. Il va faire un ensemble de vérifications, il va vérifier si par hasard vous n'avez pas des instances qui tournent avec des ports ouverts sur internet. Il va regarder si votre configuration IAM est correcte, il va regarder si CloudTrail est activé, il va regarder ce qui se passe un peu partout. Ce n'est pas l'équivalent d'un scan de sécurité, ce n'est pas aussi exhaustif qu'un audit de sécurité, mais ce sont des vérifications importantes de bon sens qui sont automatisées par Trusted Advisor. Quand vous voyez un petit point d'exclamation rouge en particulier dans la partie sécurité de Trusted Advisor, c'est vraiment un problème, c'est vraiment quelque chose qu'il faut regarder. Je vous conseille de l'intégrer dans vos pratiques Ops, de dire une fois par semaine ou tous les jours si vous êtes particulièrement concerné, tous les jours, je jette un œil dans Trusted Advisor, je vérifie qu'il n'y a pas un gros défaut, je vérifie qu'il n'y a pas quelqu'un qui a fait une bêtise et ouvert une grosse porte d'attaque. Ça prend très peu de temps, il suffit de lire ce que Trusted Advisor vous dit, il vous donne des conseils pour le corriger. Ça va boucher un grand nombre de problèmes. C'est vraiment la sécurité au quotidien, Trusted Advisor. Bien sûr, après, vous pouvez avoir des questions. Par exemple, vous voulez charger vos clés avec KMS, vous le faites à partir d'une application Java, c'est un peu compliqué, vous n'y arrivez pas. Et vous avez besoin de support technique. Le premier niveau de support c'est l'équipe qui s'occupe de votre compte, c'est votre compte manager et votre solution architecte, les gens qui sont en charge de votre compte. Si vous êtes une entreprise d'une certaine taille, vous avez cette équipe déjà pour vous, si vous êtes une start-up, peut-être pas encore, mais ça ne vous empêche pas de nous contacter, vous avez déjà des gens qui vont pouvoir vous offrir un premier niveau de support, des premières réponses de proximité. Ensuite, nous avons évidemment un support technique au sens strict du terme qui est en quatre niveaux, un support gratuit qui est basé sur les forums. Je ne sais pas si vous utilisez les forums AWS, mais je vous encourage très fortement à les consulter. Il y a beaucoup de gens dans AWS qui lisent les questions et qui répondent. Ils ne font pas tous partie des équipes support, il y a des gens de l'engineering aussi. Ça permet d'avoir déjà un premier niveau de réponse, et puis évidemment les réponses de la communauté. Vous pouvez créer aussi des tickets, en haut à droite dans la console AWS, vous pouvez ouvrir des tickets au support, et même avec ce niveau gratuit de support, les gens répondent et vous aurez des réponses à vos questions. Ensuite, il y a un deuxième niveau qui est le niveau développeur, qui est un niveau payant, mais assez économique où vous pouvez avoir du support par email et avoir des discussions et un niveau de conseil un peu plus poussé. Ensuite, il y a un niveau professionnel où là vous pouvez avoir du support par email, par chat et par téléphone, ce qui est pratique parfois, et un délai de réponse garantie en une heure. Puis enfin, un niveau enterprise avec un niveau garantie de réponse de 15 minutes et un interlocuteur technique dédié, un technical account manager dédié. Là, pour Enterprise, on est évidemment sur des niveaux de prix un peu plus élevés qui sont réservés aux grosses entreprises. Mais le niveau gratuit est utile. Allez dans les forums, posez vos questions, vous verrez, vous aurez de l'aide. Et créez des tickets au support, vous verrez, vous aurez des réponses. Et puis, si vous avez besoin d'un peu plus, le support développeur est compétitif. Ça peut être une bonne option si vous passez beaucoup de temps à développer sur AWS. Ensuite, l'étape d'après, qui est probablement bien adaptée pour des grosses entreprises, c'est de faire appel à notre équipe de Professional Services. Nous avons une équipe ici dans le bureau de Paris qui va intervenir au long cours chez les clients, parfois c'est quelques jours, parfois ça peut être 6 mois et ils vont venir travailler la main dans la main avec vos équipes pour vous aider à bâtir et à définir vos architectures de sécurité. Les équipes de Professional Services travaillent sur tous les services évidemment, ils peuvent aussi faire de la sécurité. Et vous avez vu certaines des références que j'ai citées tout à l'heure, vous imaginez bien que ces équipes ont été fortement à contribution. Et puis, nous avons notre réseau de partenaires en France également, qui peut là aussi vous aider sur vos projets AWS et sur des sujets de sécurité. Donc en résumé, vous avez compris que la sécurité est vraiment notre priorité numéro un, ce n'est pas un message en l'air, nous investissons énormément de ressources et d'engineering pour faire d'AWS la plateforme la plus sécurisée possible. Et quand vous utilisez AWS, vous êtes dans un environnement qui a été créé et validé par des entreprises ou des organisations gouvernementales qui sont les plus exigeantes au monde en matière de sécurité. Vous bénéficiez du même niveau de sécurité que la NASA. Ce n'est pas une phrase en l'air, c'est une réalité. Nous nous chargeons de la sécurité du cloud, le socle, l'infrastructure physique, les services, et vous avez vu que plus les services sont de haut niveau, moins vous avez de sécurité à gérer. Nous avons des centaines de services, d'outils, de fonctionnalités qui sont mis en place dans notre cloud ou par nos partenaires. Et vous voyez qu'on continue à en livrer en permanence pour continuer à vous offrir l'environnement le plus sécurisé possible. N'oubliez pas que vous restez responsable de la sécurité dans le cloud, donc la sécurité de vos données, le chiffrement, je le répète une dernière fois, et si vous utilisez des instances, la sécurité de ces instances. Pensez à appliquer les patchs, pensez à avoir des environnements de travail à jour, etc. Mais dans tous les cas, vous gardez l'intégration de la possession, du contrôle et de la visibilité sur vos données. Même lorsque vous utilisez les services managés, même lorsque vous déchargez une grosse partie de la sécurité, dans tous les cas, les données, la plateforme, ce sont les vôtres. Vous pouvez voir en permanence ce qui s'y passe, par exemple avec CloudTrail, vous pouvez agir en permanence sur ce qui s'y passe et sur la sécurité. Voilà quelques ressources supplémentaires pour creuser les sujets que j'ai abordés aujourd'hui. Il s'agit vraiment d'une introduction à la sécurité, donc les URL de plus haut niveau pour la sécurité et la compliance. Deux white papers, le premier qui parle des mécanismes de sécurité qu'AWS met en place, et le second qui parle des mécanismes de sécurité que vous devez mettre en place, des bonnes pratiques que vous devez utiliser pour avoir au sein de votre plateforme le bon niveau de sécurité. Et enfin, pour les développeurs, les architectes, les populations techniques, nous avons un blog dédié à la sécurité qui est extrêmement vivant et vous trouverez je pense énormément d'informations. Voilà, j'ai terminé ma présentation. Je vous remercie beaucoup de m'avoir écouté. Vous êtes très nombreux aujourd'hui. On est très contents d'avoir l'opportunité de vous parler de sécurité. Et je pense, Hugo, qu'on va pouvoir passer aux questions. Alors, je vous demande une petite seconde, le temps de les lire et de les classer un peu. Alors, première question. Allez-y, vous continuez à en envoyer, on a déjà de quoi s'occuper mais n'hésitez pas à continuer à envoyer vos questions, on va essayer de répondre au maximum. Alors on a une première question de Guillaume, merci Guillaume, de quoi se protège-t-on vraiment en chiffrant ces données sur S3 ? C'est une bonne question, on se protège de, imaginons que vous ayez une application web déployée sur une instance EC2 et que les images de ce site web soient stockées dans S3. La sécurité d'S3 à proprement parler, c'est nous qui nous en chargeons. Donc si vous définissez votre bucket S3 comme un bucket privé non accessible sur Internet, on vous garantit que les données ne sont pas accessibles depuis Internet. En revanche, si vous avez une faille de sécurité dans votre application ou dans votre environnement PHP, Java, etc., et que quelqu'un arrive à trouver votre application et à prendre la main sur votre instance, il aura le droit d'accéder à S3. Et il est possible qu'il ait accès à des données qui soient en clair. Donc, de manière générale, le chiffrement, ça va vous permettre de rajouter une ligne de défense, pas tellement en cas de problème du service S3, j'espère bien qu'S3 n'aura jamais de problème de sécurité à proprement parler, mais en cas d'intrusion dans votre plateforme et d'accès de l'intérieur de votre plateforme à des données. Si tout est en clair, une fois qu'on est rentré, le renard est dans le poulailler. Si les données sont chiffrées, vous limiterez la casse. Donc vraiment, c'est pour ça que je dis, que ce soit pour S3 ou pour le reste, le chiffrement est un élément important. Deuxième question, je les prends un peu en vrac. Une question de Blaise. Merci Blaise. RDS propose des sauvegardes automatiques. Pouvez-vous nous en dire davantage sur la fiabilité des backups ? Effectivement, RDS, on l'a vu tout à l'heure, c'est le service de base de données relationnelles et effectivement, on peut définir des backups automatiques. Vous pouvez dire, tous les matins à 1h du matin, faites-moi une sauvegarde de ma base. Cette sauvegarde sera stockée dans la même région que votre base. Si vous êtes dans la région Irlande, les backups seront stockés dans la même région. On peut imaginer qu'ils sont stockés dans S3, avec un niveau de redondance et de haute disponibilité qui est élevé. Donc oui, on peut se fier à ces backups et là aussi, je ne vois pas de raison de ne pas les activer. Les backups, Dieu sait que ça m'a compliqué la vie dans le passé. Donc la meilleure solution, c'est d'activer les backups automatiques, de mettre la bonne durée de rétention, 14 jours, 20 jours, ce que vous voulez, et puis vous les oubliez. Et puis si un jour vraiment il faut aller les restaurer, vous pourrez aller les restaurer. Mais rassurez-vous, ils seront là et ils fonctionneront. Donc les backups RDS sont fiables. On a une autre question, une double question, enfin on a deux fois la même question, d'Anis et de Jacques. Quid de l'hébergement des données de santé ? C'est un sujet auquel il est difficile de répondre en 30 secondes. L'hébergement des données de santé doit se faire dans des data centers basés en France, c'est la loi. Il ne vous aura pas échappé qu'aujourd'hui, à l'heure où je parle, AWS n'a pas d'infrastructure en France, néanmoins il ne vous aura pas échappé non plus que nous avons annoncé il y a deux semaines qu'AWS aurait une région en France en 2017. Donc je vous invite à vous rapprocher de nous pour en savoir plus. Si vous avez un account manager, contactez-le, sinon envoyez-moi un mail et je vous mettrai en contact avec les bonnes personnes. Si vous vous attendez un peu, je suis persuadé qu'on aura des bonnes nouvelles de ce point de vue-là en 2017. Si vous avez des besoins plus pressants, nous avons d'autres solutions, mais je souhaite en parler de manière privée avec vous. Donc n'hésitez pas à m'envoyer un mail et on va trouver des solutions pour ça. Une question de JC, peut-on limiter la localisation de nos données à une région seulement pour des raisons réglementaires ? C'est très facile, c'est une bonne question mais la réponse est très simple, merci. Oui, la quasi-totalité des services AWS sont régionaux. Quand je dis qu'un service est régional, ça veut dire qu'il est déployé à l'intérieur d'une région, que donc, évidemment, toutes les données gérées par ce service restent dans une région. Quand vous utilisez par exemple RDS ou S3 en Irlande, les données sont en Irlande. Si vous avez besoin que les données soient à Francfort, très bien, vous utilisez la région à Francfort. Donc, on a quelques services qui sont globaux comme Route 53 pour le DNS ou IAM pour les permissions, mais qui ne sont pas en charge de données. Tous les services qui stockent des données sont régionaux. Donc oui, quand vous stockez des données dans RDS, dans Redshift, etc., dans une région, ça reste dans une région. On ne bouge jamais les données. Vous, vous pouvez les copier d'une région à une autre, mais nous, on ne le fera pas. On ne fait pas de calculs de ce point de vue. Question d'Eric, est-ce que le chiffrement par exemple sur S3 affecte les performances ? Non, c'est difficile de répondre de manière extrêmement catégorique sur ça. Si vous utilisez les plus petites tailles d'instances, vraiment les toutes petites, micro et tout ça, il est possible qu'il y ait un impact, mais j'aurais du mal à le quantifier. Sur des instances de taille raisonnable, je n'imagine pas, et en particulier sur les services managés comme S3, je n'imagine pas qu'il y ait une différence de performance. Si jamais vous en constatez une, je vous incite à m'envoyer un mail avec les éléments, je ferai passer les informations aux équipes produits. Mais non, je n'ai pas connaissance de problème de ce style. On a une question de Disa sur Direct Connect. C'est une bonne question là aussi. Direct Connect, offre-t-il une sécurité supplémentaire ? Direct Connect, c'est un lien privé entre votre infrastructure physique ou votre bureau et nous, et une région AWS. Donc aujourd'hui à Paris, on a un point de présence, Direct Connect qui est chez Telehouse à Paris et qui vous connecte directement à la région de Francfort. L'objectif de Direct Connect, ce n'est pas exclusivement de faire de la sécurité. Néanmoins, il est évident que vous connecter à la région via un lien privé, ça offre un niveau de sécurité par construction qui est supérieur à une connexion via l'Internet public. Dans tous les cas, j'imagine que vous allez monter un VPN, etc. Mais un chemin privé, c'est toujours mieux qu'un chemin public. Donc effectivement, on a pas mal de clients qui utilisent Direct Connect pour des raisons de performance, de bande passante garantie, etc. Mais aussi parce que, je dirais par construction, les échanges entre leur infrastructure physique et la région sont privés. Ils sont privés et passent sur un lien privé. Donc oui, on peut dire que ça contribue à faire monter le niveau de sécurité. Question de Pierre, est-on bien propriétaire de nos données sur S3 ? Oui, ce sont vos données, vous les créez, vous les effacez, vous les copiez, vous faites ce que vous voulez. Ce sont vos données, vous en faites ce que vous voulez. Et que ce soit dans S3 ou ailleurs, dans tous les services, ce sont vos données, personne d'autre que vous ne voit vos données. Merci pour la question Pierre. On a une question de Philippe sur Inspector. Est-ce que Inspector permet de détecter des failles liées à un serveur FTP ou web ? Oui, c'est ce niveau-là, c'est-à-dire qu'Inspector va faire un scan de l'OS et des binaires qui tournent sur l'instance et il va trouver qu'effectivement vous avez une version de bind ou de n'importe quel outil ou une version de PHP qui est vieille et qui est vulnérable. C'est ce niveau-là de scan. C'est pour ça qu'il faut un agent. C'est vraiment un scan sur l'instant, ce n'est pas un scan réseau. On a une question de Luc sur les attaques DDoS. AWS nous interdit de faire des tests d'intrusion de type DDoS, ce qui ne nous permet pas de savoir comment réagiraient nos applications à ce genre d'attaque. Vous pouvez faire des tests d'intrusion sur AWS, vos instances. Tout ce qu'on demande c'est que vous nous préveniez avant parce qu'évidemment nous il nous est impossible de savoir si vous êtes en train de faire un test d'intrusion ou si quelqu'un est en train d'essayer de vous trouver la plateforme. Donc il y a une petite procédure très simple où vous créez un ticket au support, vous expliquez les tests que vous allez faire, soit vous, soit votre cabinet de conseil en sécurité, et ils vont vous approuver le truc, vous dites quelle est la plage horaire, quels sont les jours, etc. pour qu'effectivement, ils puissent faire la différence entre vos tests et une attaque potentielle. Donc ça, ça ne pose pas de soucis. Faire des tests de DDoS, c'est plus compliqué. Je peux vous dire que AWS assure un niveau de protection contre les attaques de type DDoS, mais pour l'instant on ne donne pas plus de détails que ça. Je pense que c'est des discussions qu'on pourrait avoir sous NDA. Donc je vous incite à vous rapprocher de votre compte manager et je suis persuadé qu'on pourra vous donner plus de détails. Mais là en public, vous comprenez que c'est délicat. Maintenant, la réponse concrète que je peux vous donner, en attendant d'avoir une éventuelle discussion plus précise sur ce qu'on fait en termes d'anti-DDoS, c'est qu'il y a tout un tas de bonnes pratiques, et peut-être Luc avez-vous vu ce white paper qui détaille les bonnes pratiques que vous devez adopter en termes d'architecture pour faire face à des montées en charge très brutales, y compris des attaques de type DDoS. Ça va reposer sur de l'autoscaling, ça va reposer sur CloudFront, ça va reposer sur un autre produit dont je n'ai pas parlé, qui s'appelle le WAF, le web application firewall. Donc il y a tout un tas de bonnes pratiques d'architecture que vous pouvez mettre en place qui vont vous protéger contre des pics de trafic légitimes et aussi vous protéger contre des attaques de type DDoS. Sur le sujet DDoS en particulier, je n'ai pas d'informations à vous communiquer publiquement, donc je vous incite à contacter votre compte manager ou à contacter le support qui pourront vous donner plus de détails. On a une question de Joseph, qui est une question intéressante. Pour une entreprise mondiale, dans quelle région placer ces données ? C'est très difficile de donner une réponse absolue. Je dirais, placez vos données au plus près de vos utilisateurs et votre infrastructure de manière générale. Si vous déployez des applis web, plus elles seront près géographiquement de vos utilisateurs, meilleures seront les performances. Si vous avez une infrastructure déployée en Irlande pour servir le marché japonais, vous comprenez évidemment que ce n'est pas forcément la meilleure solution. AWS n'a pas encore réussi à abattre la vitesse de la lumière, donc la latence réseau est là, et donc au plus près de vos utilisateurs, c'est probablement le bon endroit. Après, peut-être avez-vous des obligations réglementaires qui vous obligent à placer les données dans telle ou telle région, mais ça, c'est à vous de le savoir. Vous pouvez aussi les placer dans plusieurs régions, vous pouvez en fonction des services, vous pouvez faire avec RDS par exemple, vous pouvez faire de la réplication de données entre les régions, vous pourriez avoir un serveur de base de données maître en Europe et puis des serveurs esclaves dans différentes régions. Il y a tout un tas de solutions, donc le plus simple, c'est au plus près de vos utilisateurs pour avoir de bonnes performances. Puis après, peut-être ça vaut la peine, pour des raisons aussi de redondance, de disaster recovery, etc., d'avoir les données dans plusieurs régions. Question de David. Quel intérêt de chiffrer les volumes EBS ? Étant donné qu'ils sont côté infra, pourquoi Amazon ne le fait pas par défaut ? C'est vrai qu'on pourrait le faire par défaut. Pourquoi on ne le fait pas par défaut ? Honnêtement, je ne sais pas. Peut-être que ça viendra, parce qu'à force de dire à tout le monde de tout chiffrer, peut-être que ça deviendra un réglage par défaut. Aujourd'hui, ça ne l'est pas. Donc, une fois de plus, on vous conseille d'activer ce chiffrement, qui est une première ligne de défense. Maintenant, vous pourriez m'opposer que si c'est Amazon qui chiffre, c'est Amazon qui a la clé, donc quelqu'un d'Amazon pourrait lire mes données. En pratique, personne d'Amazon de niveau données, mais ok, admettons. Si vous avez un file system crypto, la clé de chiffrement c'est vous qui l'avez installée sur l'instance et donc vous avez une protection supplémentaire, même vis-à-vis de nous, c'est-à-dire que les données que nous stockons sur votre volume sont encore plus inintelligibles. Ça vaut la peine d'avoir la double sécurité à mon avis. Ceinture et bretelles. En termes de sécurité, ce n'est pas une mauvaise approche. Question de Dani. Le cryptage des données via KMS permet-il de crypter tout le système de fichiers des instances EC2 ? KMS est plutôt utilisée pour les autres back-ends. KMS c'est plutôt pour RDS, Redshift, etc. Pour EC2, comme je l'expliquais à l'instant, a priori on va travailler sur EBS, donc le chiffrement EBS du service plus le chiffrement du file system doit suffire. KMS est vraiment un système où vous chargez avec un échange sécurisé des clés crypto, des clés au sens public cryptography. Vous chargez des clés de chiffrement pour chiffrer avec vos clés les données dans RDS, dans EMR, etc. Donc KMS, c'est vraiment pour ces problématiques-là. Question de Corentin, y a-t-il des API dans CloudTrail qui permettraient d'ajouter des données supplémentaires dans les logs, typiquement des logs applicatifs ? Il me semble que non. Il faudrait que je vérifie. Corentin, si vous pouvez poster votre adresse de mail dans le chat, Hugo la notera et je vous répondrai après. Mais à ma connaissance, on ne peut pas faire ça. Je pense que la bonne solution consisterait à exporter les logs CloudTrail vers, par exemple, Splunk et à les agréger dans Splunk avec les autres logs, avec les logs des applications. Je pense que ça serait la meilleure solution, celle qui vous donnerait le plus de flexibilité, puisqu'il sera difficile pour CloudTrail de comprendre vos logs applicatifs. Mais bon, je vais vérifier. Question de Thierry. Dès lors qu'on utilise Elastic Beanstalk, y a-t-il besoin de fragmenter notre environnement ? Je suppose que vous parlez des différents VPC, etc., du découpage, c'est ça ? Si je n'ai pas compris, dites-le dans le chat, Hugo me corrigera. Je maintiens que oui, parce que quand vous créez Elastic Beanstalk, pour les gens qui ne sont pas familiers, Elastic Beanstalk est un outil vraiment orienté vers les développeurs qui vous permet très simplement de déployer du code et le service Beanstalk va provisionner les instances EC2, etc. Donc toute la plomberie infra est créée automatiquement par Beanstalk. Et donc je pense que oui, il est important de séparer vos environnements parce que, certes, le développeur a priori n'a pas besoin d'aller jouer sur son infrastructure, mais l'infrastructure, les instances, les ressources qui vont être créées, elles vont tourner dans un VPC. Les autres utilisateurs du VPC ou les autres ressources qui tournent dans ce VPC pourraient avoir accès à votre environnement, et symétriquement, l'application que vous déployez sur votre environnement Beanstalk pourrait aller jardiner dans les ressources qui sont déployées dans votre VPC. Donc oui, il vaut mieux continuer à isoler vos applications et vos environnements Beanstalk dans des VPC dédiés, ce qui me paraît plus prudent dans les deux sens. Question de Romain sur le WAF. Le WAF, le Web Application Firewall, qui permet de définir des règles de filtrage sur vos applications web. Est-ce qu'il y a des templates pour les règles WAF ? Je ne suis pas tout à fait sûr de ce que vous entendez par template, mais en tout cas, dans le WAF, quand vous créez des règles, en particulier dans la console, il y a tout un tas de cas prédéfinis pour filtrer une IP source, filtrer un user agent, etc. Donc oui, il y a moyen de s'en servir assez facilement sans se poser trop de questions. Essayez le WAF, c'est assez facile à mettre en place et vous verrez, il y a déjà tout un tas de choses qui sont préparées. Hugo est en train de me faire comprendre qu'on n'a plus de temps. Il reste des questions. Hugo, je ne sais pas comment on va gérer. Ce que je vous propose, parce que je n'aime pas laisser des questions sans réponse, c'est que les personnes qui avaient des questions auxquelles je n'ai pas répondu m'envoient un mail. Vous voyez encore le slide, vous voyez mon adresse de mail, envoyez-moi un mail et j'essaie de vous répondre dans un délai raisonnable, sachant qu'en ce moment je suis à Paris, je ne voyage pas trop, donc je vais essayer de vous répondre dans la semaine. N'hésitez pas, il n'y a pas de mauvaise question, c'est juste qu'on est obligé de s'arrêter un moment. Je vous remercie infiniment, vous êtes encore hyper nombreux, on a encore perdu très peu de monde pendant la séance de questions, donc c'est super, je suis vraiment content. Je vous remercie vraiment d'avoir participé à ce webinaire, j'espère que ça vous a plu. On en a un autre demain. Hugo, est-ce qu'il est encore temps de s'inscrire pour demain ou est-ce que c'est trop tard ? Oui, il est encore temps de s'inscrire pour demain. Donc allez voir sur notre site. Demain, on parlera de migration de données, comment migrer ces données avec différentes solutions. On parlera de Direct Connect, d'autres choses aussi, des choses plus rigolotes. Donc il est encore temps de s'inscrire pour demain et puis, en décembre, je crois que c'est la semaine du 19 décembre, on a un marathon sécurité où là on va détailler, et pour certains cas détailler très fortement, le fonctionnement de certains de nos mécanismes de sécurité. Donc l'agenda sera prochainement en ligne sur le site, toujours au même endroit, aws.com, rubrique événements. Les fans de sécurité, les gens qui veulent en savoir encore plus, qui ne sont pas rassasiés après celui-ci, pourront participer à ces prochains webinaires et envoyer encore d'autres questions. Merci encore, merci Hugo pour l'organisation. N'hésitez pas à me joindre par email quand vous avez besoin. Hugo est en train de vous partager les slides, le PDF de la présentation. Je le tweeterai également si jamais vous l'avez raté. Et puis voilà, vous pouvez me suivre sur Twitter, et vous ne raterez plus aucun événement à AWS, que ce soit en France et au-delà. Merci beaucoup, je vous souhaite une bonne fin de journée et je vous donne rendez-vous, peut-être à demain ou en tout cas à un autre webinar. Merci encore et au revoir.