Amazon Web Services a lancé de nombreuses innovations en matière de sécurité au cours de ses deux premières décennies. Trois en particulier joueront un rôle clé dans la manière dont l’hyperscaler répondra à certains des problèmes cybernétiques les plus difficiles à ce jour.
Alors qu’Amazon célèbre cette année le 20e anniversaire de son cloud AWS, le plus grand fournisseur de cloud computing au monde est désormais confronté à deux menaces géantes en matière de cybersécurité : l’IA et le quantique.
La manière dont l’entreprise va gérer ces problèmes émergents pour garantir la sécurité et la résilience des systèmes utilisés par ses millions d’entreprises clientes reste une question en constante évolution. Mais les cadres supérieurs d’AWS estiment que les décisions et innovations clés que l’entreprise a prises tout au long de ses 20 années d’existence lui permettent de faire face à ces menaces.
Voici un aperçu de trois avancées clés d’AWS et de la manière dont elles sont prises en compte dans les menaces émergentes auxquelles l’entreprise et ses clients sont confrontés, aujourd’hui et dans les années à venir.
Nitro et infrastructure « zéro humain »
Lorsqu’Amazon a lancé Virtual Private Cloud, sa couche réseau pour AWS, en 2009, il s’agissait uniquement de logiciels.
« Maintenant, le VPC est implémenté dans le matériel », déclare Eric Brandwine, qui est arrivé chez AWS il y a plus de 18 ans pour travailler sur ce projet et est maintenant vice-président et ingénieur distingué pour la sécurité d’Amazon.
Ce qui a changé, c’est l’introduction en 2017 de Nitro, une base matérielle pour la mise en réseau, la sécurité et l’hyperviseur qui impose une forte isolation entre les instances des clients. Amazon a payé plus de 350 millions de dollars pour une entreprise de semi-conducteurs sans usine en 2015 afin de rendre possible le changement technologique.
Nitro permet également à Amazon d’exploiter AWS sans que les employés touchent à l’infrastructure client. « Avec Nitro, il n’y a aucun accès humain », dit-il. « C’est l’une des raisons pour lesquelles nous sommes en mesure de proposer des instances nues. »
Si une maintenance est nécessaire, tout le contenu client est supprimé de la machine avant que les employés puissent y accéder.
« Et nous avons demandé à des tiers d’examiner ce processus », ajoute-t-il, notamment NCC Group, qui a mené un examen de l’architecture des allégations de sécurité d’Amazon en 2023.
Aujourd’hui, Nitro constitue la base de confiance pour protéger les clés de chiffrement à sécurité quantique de l’entreprise, pour sécuriser les identités des agents d’IA, pour protéger l’infrastructure AWS contre les agents malveillants et pour fournir la base de calcul confidentielle pour les charges de travail d’IA elles-mêmes.
Cryptographie symétrique et menace quantique
Au début des années 2010, la plupart des modules de sécurité matériels utilisaient la cryptographie asymétrique pour protéger les clés de sécurité. La cryptographie asymétrique, celle utilisée pour sécuriser les communications en ligne, implique des paires de clés : une pour verrouiller, une autre pour déverrouiller. C’est une approche très utile et pratique lorsqu’il s’agit de traiter avec plusieurs parties.
Amazon a choisi d’utiliser le cryptage symétrique, dans lequel la même clé est utilisée à la fois pour verrouiller et déverrouiller les données, car il est plus rapide et plus efficace.
« L’une des choses que nous avons faites il y a 15 ans est que pour authentifier les clients qui nous parlent, nous nous appuyons sur la cryptographie symétrique », explique Ken Beer, directeur de la cryptographie AWS. « Et pour le service de gestion des clés que j’ai aidé à lancer en 2013, nous avons également déclaré que nous nous appuierions sur la cryptographie symétrique pour protéger toutes les clés. »
Aujourd’hui, plus de 99,9 % de l’ensemble du chiffrement des données au repos n’implique aucune cryptographie asymétrique dans la chaîne de clés qui les sécurise, dit-il.
Cela s’est avéré être une décision extrêmement fortuite.
La raison ? On s’attend à ce que les ordinateurs quantiques soient capables de briser les normes de chiffrement asymétriques actuelles, mais le chiffrement symétrique est sûr. Et les progrès de l’informatique quantique ont été si rapides ces derniers temps que Google et Cloudflare ont tous deux avancé leurs délais.
Les entreprises de toutes tailles doivent désormais mettre à jour leur cryptographie avec des algorithmes à sécurité quantique, à moins que ces algorithmes ne soient symétriques.
« Nous n’avons pas besoin de le changer, et nous sommes heureux de ne pas avoir à le changer », déclare Beer. Quant à toutes les données stockées sur les serveurs d’Amazon, l’entreprise n’a pas besoin de les déchiffrer et de les recrypter avec des méthodes à sécurité quantique. C’est déjà sûr quantiquement.
Cela ne veut pas dire qu’Amazon ne propose aucun cryptage asymétrique nulle part. Les communications avec des contreparties non fiables ou sur Internet public l’exigent.
AWS vise 2028 et 2029 pour achever son authentification post-quantique par certificat public – il y a un retard là-bas car le monde doit encore s’entendre sur un ensemble commun de normes.
« Cela va nécessiter une coopération entre cinq ou dix grands fournisseurs », explique Beer. « Une fois que nous serons d’accord sur la méthode de validation des signatures numériques, tous les fournisseurs qui possèdent différentes parties de la pile technologique la mettront en œuvre. »
Amazon est membre du CA/Browser Forum depuis plus d’une décennie, dit-il, faisant référence à l’organisme industriel qui fixe les règles de fonctionnement de l’infrastructure à clé publique sur Internet. « Nous sommes convaincus que nous ferons évoluer l’industrie d’ici 2029. »
Les clients AWS qui utilisent AWS pour leurs tâches cryptographiques lourdes bénéficient d’une protection post-quantique gratuitement et sans effort supplémentaire. Ceux qui disposent de leur propre cryptographie asymétrique devront cependant faire un travail sérieux.
« Il y a potentiellement beaucoup de cryptographie intégrée dans les applications des gens », explique Beer. « Puis-je le trouver ? Puis-je le modifier ? Dois-je aller parler à un fournisseur auquel je n’ai pas parlé depuis dix ans – ou qui n’existe plus ? » C’est le genre de questions que les entreprises clientes devraient se poser.
Contrôles de sécurité S3 et modèle de responsabilité partagée
Aucune instance publique d’AWS Nitro ou de l’infrastructure de chiffrement n’a été compromise. Le rapport de la CCN, ainsi que d’autres recherches d’analystes, montrent que cela fonctionne.
Mais les violations de données sur Amazon font constamment l’actualité. La raison ? Les clients AWS ne parviennent pas à sécuriser leurs compartiments S3, fuient leurs informations d’identification, codent leurs clés en dur et commettent de nombreuses autres erreurs lors de la gestion de leurs environnements.
Selon la société de cybersécurité UpGuard, la sécurité d’AWS S3 est « défectueuse de par sa conception », avec des milliers de violations détectées par la société au cours des dernières années.
« Depuis le jour du lancement de S3, les buckets sont sécurisés par défaut », rétorque Brandwine.
C’est exact, dit UpGuard, mais AWS rend trop facile une mauvaise configuration accidentelle des compartiments, conclut-il.
Brandwine admet qu’il y a un problème ici. « Si un client passe une mauvaise journée dans le cloud, c’est quelque chose qu’il a fait », dit-il. « Mais si un groupe de clients passe une mauvaise journée dans le cloud, nous devons y jeter un coup d’œil. »
Supposons, par exemple, qu’une entreprise utilise un compartiment S3 pour conserver du contenu, puis supprime le compartiment, mais qu’il existe toujours des pages Web, des services ou des outils qui y renvoient. Les attaquants peuvent détourner ces buckets abandonnés et les utiliser à des fins malveillantes.
Il s’agit d’une erreur de l’utilisateur : les clients qui suppriment des compartiments doivent également supprimer les liens qui pointent vers eux. Mais ça arrive. Et cela arrive fréquemment.
«Nous avons donc construit ce qu’on appelle la défense active», explique Brandwine.
Lorsqu’Amazon détecte quelqu’un qui tente d’utiliser une attaque par dictionnaire pour deviner les noms de compartiments, « nous leur mentons et disons : « Compartiment introuvable » », dit-il. « Cela rend l’analyse inefficace et a effectivement mis fin aux attaques par dictionnaire contre S3. »
Mais l’infrastructure AWS est complexe et il existe de nombreux cas dans lesquels les entreprises clientes peuvent facilement configurer des politiques de manière incorrecte. Et il ne s’agit pas uniquement de clients.
Les employés d’Amazon font également des erreurs. Dans CodeBreach, les ingénieurs AWS ont mal configuré les propres systèmes d’AWS, selon les chercheurs de Wiz.
Les attaquants ont toujours recherché des opportunités pour exploiter les erreurs de configuration, les informations d’identification faibles et les problèmes similaires côté client. Aujourd’hui, avec l’IA, les risques sont plus grands que jamais.
« L’IA ne change pas ce que font les acteurs de la menace », déclare Gee Rittenhouse, vice-président des services de sécurité chez Amazon. « Cela change la vitesse et l’échelle avec lesquelles ils opèrent. Nous voyons toujours les principaux vecteurs de menace, tels que le phishing et la compromission des informations d’identification, mais les exploits sont beaucoup plus rapides. »
Amazon exploite également cette technologie, dit-il.
Fin mars, AWS a lancé son agent de sécurité AWS pour les tests d’intrusion à la demande et son agent AWS DevOps, qui résout les incidents de manière autonome.
« Nous avons des agents attaquants opposés à des agents défenseurs et ce qui prenait auparavant quelques semaines, nous sommes désormais capables de le faire en quelques heures », dit-il.
Mais il existe une autre raison pour laquelle l’IA constitue une menace émergente majeure pour Amazon. Les agents d’IA que les entreprises créent et déploient sur AWS pourraient constituer le prochain vecteur de violation majeur, le nouvel équivalent des compartiments S3 non sécurisés.
Amazon peut-il tirer parti de ses succès en matière de sécurisation de son infrastructure et les combiner avec les leçons tirées d’années de violations des compartiments S3 pour construire une base de sécurité pour les agents IA ?
Rittenhouse dit oui. Et cela dépend en grande partie de la couche d’authentification des agents et des privilèges d’accès.
«Nous venons de lancer une nouvelle authentification, l’échange de jetons OAuth 2», dit-il. Cela fait partie d’Amazon Bedrock AgentCore Identity et implique de garder une trace de l’utilisateur pour lequel l’agent IA agit et des ressources auxquelles il tente d’accéder.
« Il évalue si l’agent peut le faire avant de le faire, au niveau de l’infrastructure », explique Rittenhouse. « Et si c’est non, ce n’est pas autorisé à le faire, quel que soit le commandement, que ce soit hallucinant ou qu’il ait été pris en charge, notre infrastructure ne le permet pas. »
«C’est notre avantage», ajoute-t-il. « Nous allons depuis la couche infrastructure. »
