![<\/a><\/div>\nSi vous utilisez AWS, il est facile de supposer que votre s\u00e9curit\u00e9 du cloud est g\u00e9r\u00e9e – mais c’est une id\u00e9e fausse dangereuse. AWS s\u00e9curise sa propre infrastructure, mais la s\u00e9curit\u00e9 dans <\/em>Un environnement cloud reste la responsabilit\u00e9 du client.<\/p>\nPensez \u00e0 la s\u00e9curit\u00e9 AWS comme la protection d’un b\u00e2timent: AWS fournit des murs forts et un toit solide, mais il appartient au client de g\u00e9rer les serrures, d’installer les syst\u00e8mes d’alarme et de s’assurer que les objets de valeur ne sont pas expos\u00e9s.<\/p>\nDans ce blog, nous clarifierons ce que AWS ne s\u00e9curise pas, soulignez les vuln\u00e9rabilit\u00e9s du monde r\u00e9el et comment les scanners de s\u00e9curit\u00e9 cloud aiment Intrus<\/a> peut aider.<\/p>\nComprendre le mod\u00e8le de responsabilit\u00e9 partag\u00e9 AWS<\/strong><\/h2>\nAWS fonctionne sur un Mod\u00e8le de responsabilit\u00e9 partag\u00e9e<\/a>. En termes simples:<\/p>\n\nAWS<\/strong> est responsable de la s\u00e9curisation de l’infrastructure sous-jacente (par exemple, mat\u00e9riel, r\u00e9seautage, centres de donn\u00e9es) – les \u00abmurs et toit\u00bb.<\/li>\nLe client<\/strong> est responsable de la s\u00e9curisation de leurs donn\u00e9es, applications et configurations dans AWS – les \u00abverrous et alarmes\u00bb.<\/li>\n<\/ul>\nComprendre cette distinction est essentiel pour maintenir un environnement AWS s\u00e9curis\u00e9.<\/p>\n5 vuln\u00e9rabilit\u00e9s AWS du monde r\u00e9el que vous devez aborder<\/strong><\/h2>\nExaminons certaines vuln\u00e9rabilit\u00e9s du monde r\u00e9el qui rel\u00e8vent de la responsabilit\u00e9 du client et de ce qui peut \u00eatre fait pour les att\u00e9nuer.<\/p>\nFonctionnement de la demande c\u00f4t\u00e9 serveur (SSRF)<\/strong><\/h4>\nLes applications h\u00e9berg\u00e9es dans AWS sont toujours vuln\u00e9rables aux attaques comme SSRF, o\u00f9 les attaquants incitent un serveur \u00e0 faire des demandes en leur nom. Ces attaques peuvent entra\u00eener un acc\u00e8s aux donn\u00e9es non autoris\u00e9 et une nouvelle exploitation.<\/p>\nSe d\u00e9fendre contre SSRF:<\/p>\n\nNum\u00e9risation et r\u00e9parer r\u00e9guli\u00e8rement les vuln\u00e9rabilit\u00e9s dans les applications.<\/li>\nActiver AWS Imdsv2<\/a>qui fournit une couche de s\u00e9curit\u00e9 suppl\u00e9mentaire contre les attaques SSRF. AWS fournit cette sauvegarde, mais la configuration est la responsabilit\u00e9 du client.<\/li>\n<\/ul>\nFaiblesses de contr\u00f4le d’acc\u00e8s<\/strong><\/h4>\nAWS Identifier et Access Management (IAM) permet aux clients de g\u00e9rer qui peut acc\u00e9der aux ressources – mais elle n’est aussi forte que sa mise en \u0153uvre. Les clients sont charg\u00e9s de garantir que les utilisateurs et les syst\u00e8mes n’ont acc\u00e8s qu’aux ressources dont ils ont vraiment besoin.<\/p>\nLes faux pas communs comprennent:<\/p>\n\nR\u00f4les et acc\u00e8s trop permissifs<\/li>\nContr\u00f4les de s\u00e9curit\u00e9 manquants<\/li>\nSeaux accidentellement publics S3<\/li>\n<\/ul>\nExpositions aux donn\u00e9es<\/strong><\/h4>\nLes clients AWS sont responsables de la s\u00e9curit\u00e9 des donn\u00e9es qu’ils stockent dans le cloud – et de la fa\u00e7on dont leurs applications acc\u00e8dent \u00e0 ces donn\u00e9es.<\/p>\nPar exemple, si votre application se connecte \u00e0 un service de base de donn\u00e9es relationnel AWS (RDS), le client doit s’assurer que l’application n’expose pas les donn\u00e9es sensibles aux attaquants. Une vuln\u00e9rabilit\u00e9 simple comme une r\u00e9f\u00e9rence d’objet direct ins\u00e9curis\u00e9e (IDOR) est tout ce qu’il faudrait \u00e0 un attaquant avec un compte utilisateur pour acc\u00e9der aux donn\u00e9es appartenant \u00e0 tous les autres utilisateurs.<\/p>\nGestion des patchs<\/strong><\/h4>\nCela va presque sans dire, mais AWS ne corrige pas les serveurs! Les clients qui d\u00e9ploient les instances EC2 sont enti\u00e8rement responsables du maintien du syst\u00e8me d’exploitation (OS) et des logiciels \u00e0 jour.<\/p>\nPrenez Redis d\u00e9ploy\u00e9 sur Ubuntu 24.04 \u00e0 titre d’exemple – le client est responsable de la correction des vuln\u00e9rabilit\u00e9s dans le logiciel (Redis) et le syst\u00e8me d’exploitation (Ubuntu). AWS g\u00e8re uniquement les vuln\u00e9rabilit\u00e9s mat\u00e9rielles sous-jacentes, comme les probl\u00e8mes de firmware.<\/p>\nLes services AWS comme Lambda r\u00e9duisent certaines responsabilit\u00e9s de correction, mais vous \u00eates toujours responsable de l’utilisation des temps d’ex\u00e9cution pris en charge et de la mise \u00e0 jour des choses.<\/p>\nPare-feu et surface d’attaque<\/strong><\/h4>\nAWS donne aux clients le contr\u00f4le de leur surface d’attaque, mais n’est pas responsable de ce qu’ils choisissent d’exposer.<\/p>\nPar exemple, si un serveur GitLab est d\u00e9ploy\u00e9 sur AWS, le client est responsable de le superposer derri\u00e8re un VPN, de l’utilisation d’un pare-feu ou de le placer dans un cloud priv\u00e9 virtuel (VPC) tout en veillant \u00e0 ce que leur \u00e9quipe ait un moyen s\u00e9curis\u00e9 d’y acc\u00e9der. Sinon, une vuln\u00e9rabilit\u00e9 z\u00e9ro-jour pourrait laisser vos donn\u00e9es compromises et AWS ne sera pas en faute.<\/p>\nLe point \u00e0 retenir cl\u00e9<\/strong><\/h2>\nCes exemples indiquent une chose claire: la s\u00e9curit\u00e9 du cloud ne sort pas de la bo\u00eete. Alors que AWS s\u00e9curise l’infrastructure sous-jacente, tout ce qui est construit en plus est la responsabilit\u00e9 du client. Surplombant ce fait peut exposer une organisation \u00e0 des risques graves – mais avec les bons outils, rester en s\u00e9curit\u00e9 est enti\u00e8rement \u00e0 port\u00e9e de main.<\/p>\nAugmenter votre s\u00e9curit\u00e9 cloud avec intrus<\/strong><\/h2>\nL’intrus vous aide \u00e0 rester en avance sur toutes ces vuln\u00e9rabilit\u00e9s et plus encore, en combinant Num\u00e9risation de la s\u00e9curit\u00e9 du cloud<\/a>scanne de vuln\u00e9rabilit\u00e9 et gestion de la surface d’attaque dans une plate-forme puissante et facile \u00e0 utiliser.<\/p>\nPourquoi c’est un changeur de jeu:<\/p>\n\nTrouvez ce que les autres manquent: <\/strong>Intruder combine la num\u00e9risation de vuln\u00e9rabilit\u00e9 externe avec des informations provenant de comptes AWS pour trouver des risques que d’autres solutions pourraient manquer.<\/li>\nPas de fausses alarmes:<\/strong> Les outils CSPM peuvent surhyper la gravit\u00e9. Intruder donne la priorit\u00e9 aux v\u00e9ritables risques afin que vous puissiez vous concentrer sur ce qui compte vraiment.<\/li>\nCorrection cristalline:<\/strong> Les probl\u00e8mes sont expliqu\u00e9s en anglais simple avec des directives de correction \u00e9tape par \u00e9tape.<\/li>\nProtection continue: <\/strong>Restez en avance avec une surveillance continue et des alertes lorsque de nouveaux risques \u00e9mergent.<\/li>\nPrix \u200b\u200bpr\u00e9visible:<\/strong> Contrairement \u00e0 d’autres outils de s\u00e9curit\u00e9 du cloud qui peuvent accumuler des co\u00fbts impr\u00e9visibles, il n’y a pas de charges sur des accusations d’intrus.<\/li>\n<\/ul>\nConfigurez en quelques minutes et recevez des informations instantan\u00e9es sur la s\u00e9curit\u00e9 de votre cloud – Commencez votre essai gratuit de 14 jours aujourd’hui<\/a>.<\/p>\n<\/p>\nVous avez trouv\u00e9 cet article int\u00e9ressant? Cet article est un article contribu\u00e9 de l’un de nos pr\u00e9cieux partenaires.<\/span> Suivez-nous Gazouillement \uf099<\/i><\/a> et Liendin<\/a> Pour lire plus de contenu exclusif que nous publions.<\/div>\n<\/div>\n](\"https:\/\/teknomers.com\/fr\/wp-content\/uploads\/2025\/03\/5-vulnerabilites-AWS-percutantes-dont-vous-etes-responsable.jpg\"){kind=link}
Si vous utilisez AWS, il est facile de supposer que votre s\u00e9curit\u00e9 du cloud est g\u00e9r\u00e9e – mais c’est une id\u00e9e fausse dangereuse. AWS s\u00e9curise sa propre infrastructure, mais la s\u00e9curit\u00e9 dans <\/em>Un environnement cloud reste la responsabilit\u00e9 du client.<\/p>\n Pensez \u00e0 la s\u00e9curit\u00e9 AWS comme la protection d’un b\u00e2timent: AWS fournit des murs forts et un toit solide, mais il appartient au client de g\u00e9rer les serrures, d’installer les syst\u00e8mes d’alarme et de s’assurer que les objets de valeur ne sont pas expos\u00e9s.<\/p>\n Dans ce blog, nous clarifierons ce que AWS ne s\u00e9curise pas, soulignez les vuln\u00e9rabilit\u00e9s du monde r\u00e9el et comment les scanners de s\u00e9curit\u00e9 cloud aiment Intrus<\/a> peut aider.<\/p>\n AWS fonctionne sur un Mod\u00e8le de responsabilit\u00e9 partag\u00e9e<\/a>. En termes simples:<\/p>\n Comprendre cette distinction est essentiel pour maintenir un environnement AWS s\u00e9curis\u00e9.<\/p>\n Examinons certaines vuln\u00e9rabilit\u00e9s du monde r\u00e9el qui rel\u00e8vent de la responsabilit\u00e9 du client et de ce qui peut \u00eatre fait pour les att\u00e9nuer.<\/p>\n Les applications h\u00e9berg\u00e9es dans AWS sont toujours vuln\u00e9rables aux attaques comme SSRF, o\u00f9 les attaquants incitent un serveur \u00e0 faire des demandes en leur nom. Ces attaques peuvent entra\u00eener un acc\u00e8s aux donn\u00e9es non autoris\u00e9 et une nouvelle exploitation.<\/p>\n Se d\u00e9fendre contre SSRF:<\/p>\n AWS Identifier et Access Management (IAM) permet aux clients de g\u00e9rer qui peut acc\u00e9der aux ressources – mais elle n’est aussi forte que sa mise en \u0153uvre. Les clients sont charg\u00e9s de garantir que les utilisateurs et les syst\u00e8mes n’ont acc\u00e8s qu’aux ressources dont ils ont vraiment besoin.<\/p>\n Les faux pas communs comprennent:<\/p>\n Les clients AWS sont responsables de la s\u00e9curit\u00e9 des donn\u00e9es qu’ils stockent dans le cloud – et de la fa\u00e7on dont leurs applications acc\u00e8dent \u00e0 ces donn\u00e9es.<\/p>\n Par exemple, si votre application se connecte \u00e0 un service de base de donn\u00e9es relationnel AWS (RDS), le client doit s’assurer que l’application n’expose pas les donn\u00e9es sensibles aux attaquants. Une vuln\u00e9rabilit\u00e9 simple comme une r\u00e9f\u00e9rence d’objet direct ins\u00e9curis\u00e9e (IDOR) est tout ce qu’il faudrait \u00e0 un attaquant avec un compte utilisateur pour acc\u00e9der aux donn\u00e9es appartenant \u00e0 tous les autres utilisateurs.<\/p>\n Cela va presque sans dire, mais AWS ne corrige pas les serveurs! Les clients qui d\u00e9ploient les instances EC2 sont enti\u00e8rement responsables du maintien du syst\u00e8me d’exploitation (OS) et des logiciels \u00e0 jour.<\/p>\n Prenez Redis d\u00e9ploy\u00e9 sur Ubuntu 24.04 \u00e0 titre d’exemple – le client est responsable de la correction des vuln\u00e9rabilit\u00e9s dans le logiciel (Redis) et le syst\u00e8me d’exploitation (Ubuntu). AWS g\u00e8re uniquement les vuln\u00e9rabilit\u00e9s mat\u00e9rielles sous-jacentes, comme les probl\u00e8mes de firmware.<\/p>\n Les services AWS comme Lambda r\u00e9duisent certaines responsabilit\u00e9s de correction, mais vous \u00eates toujours responsable de l’utilisation des temps d’ex\u00e9cution pris en charge et de la mise \u00e0 jour des choses.<\/p>\n AWS donne aux clients le contr\u00f4le de leur surface d’attaque, mais n’est pas responsable de ce qu’ils choisissent d’exposer.<\/p>\n Par exemple, si un serveur GitLab est d\u00e9ploy\u00e9 sur AWS, le client est responsable de le superposer derri\u00e8re un VPN, de l’utilisation d’un pare-feu ou de le placer dans un cloud priv\u00e9 virtuel (VPC) tout en veillant \u00e0 ce que leur \u00e9quipe ait un moyen s\u00e9curis\u00e9 d’y acc\u00e9der. Sinon, une vuln\u00e9rabilit\u00e9 z\u00e9ro-jour pourrait laisser vos donn\u00e9es compromises et AWS ne sera pas en faute.<\/p>\n Ces exemples indiquent une chose claire: la s\u00e9curit\u00e9 du cloud ne sort pas de la bo\u00eete. Alors que AWS s\u00e9curise l’infrastructure sous-jacente, tout ce qui est construit en plus est la responsabilit\u00e9 du client. Surplombant ce fait peut exposer une organisation \u00e0 des risques graves – mais avec les bons outils, rester en s\u00e9curit\u00e9 est enti\u00e8rement \u00e0 port\u00e9e de main.<\/p>\n L’intrus vous aide \u00e0 rester en avance sur toutes ces vuln\u00e9rabilit\u00e9s et plus encore, en combinant Num\u00e9risation de la s\u00e9curit\u00e9 du cloud<\/a>scanne de vuln\u00e9rabilit\u00e9 et gestion de la surface d’attaque dans une plate-forme puissante et facile \u00e0 utiliser.<\/p>\n Pourquoi c’est un changeur de jeu:<\/p>\n Configurez en quelques minutes et recevez des informations instantan\u00e9es sur la s\u00e9curit\u00e9 de votre cloud – Commencez votre essai gratuit de 14 jours aujourd’hui<\/a>.<\/p>\n <\/p>\nComprendre le mod\u00e8le de responsabilit\u00e9 partag\u00e9 AWS<\/strong><\/h2>\n
\n
5 vuln\u00e9rabilit\u00e9s AWS du monde r\u00e9el que vous devez aborder<\/strong><\/h2>\n
Fonctionnement de la demande c\u00f4t\u00e9 serveur (SSRF)<\/strong><\/h4>\n
\n
Faiblesses de contr\u00f4le d’acc\u00e8s<\/strong><\/h4>\n
\n
Expositions aux donn\u00e9es<\/strong><\/h4>\n
Gestion des patchs<\/strong><\/h4>\n
Pare-feu et surface d’attaque<\/strong><\/h4>\n
Le point \u00e0 retenir cl\u00e9<\/strong><\/h2>\n
Augmenter votre s\u00e9curit\u00e9 cloud avec intrus<\/strong><\/h2>\n
\n