BLOGGINGIntroduction
Comme tout système informatique, les systèmes dans le cloud restent vulnérables aux attaques et aux failles. Ainsi, stocker des données sur le cloud implique de grandes responsabilités en termes de sécurité. En exposant certaines données sur le cloud, ces dernières se retrouvent exposées aux attaques informatiques dites classiques ainsi qu’aux attaques beaucoup plus sophistiquées par exemple une personne malveillante qui réussirait à s’infiltrer dans les locaux d’Amazon et obtiendrait un accès physique aux serveurs. Dans le premier billet, nous nous sommes attelés aux moyens de sécuriser une infrastructure cloud mais qu’en est-il réellement ? Quelles sont les responsabilités du fournisseur de Cloud en termes de sécurité ? Comment un “hacker” pourrait s’introduire dans mon infrastructure ? Que pourrait-il faire une fois introduit ? Voici les questions que nous aborderons dans cette seconde partie de billet consacrée aux responsabilités du fournisseur ainsi qu’aux attaques sur le Cloud.
À l'image des responsabilités du fournisseur de cloud, les responsabilités de sécurité du fournisseur de service évoluent avec le modèle de service que vous choisissez. Voici la répartition des responsabilités en terme de sécurité dans le cloud :
Dans tous les cas de services de cloud public, le fournisseur de services de cloud est responsable de la sécurisation du cloud lui-même, et les clients sont responsables de la manière dont ils l'utilisent.
Avec le SaaS (Software-as-a-Service), cette utilisation se limite à l'accès des utilisateurs et aux données qui entrent dans le nuage.
Lorsque vous passez à la PaaS et à l'IaaS, la responsabilité du client s'accroît, car il construit désormais son environnement à partir du réseau, y compris les systèmes d'exploitation et les applications, qu'il lui incombe de configurer et d'utiliser en toute sécurité.
Les fournisseurs de services de Cloud ne peuvent pas prévoir comment chaque client utilisera son environnement.
Seuls les clients connaissent les subtilités de ce qu'ils uploadent dans le cloud.
Cette liberté de construire avec l'élasticité et l'agilité du cloud s'accompagne également de possibilités d'erreurs infinies.
La sécurité du cloud est vite devenue un enjeu primordial comme le montre la croissance des dépenses liées au cloud, en effet, Gartner a mesuré une augmentation de plus de 40% des coûts liés à la sécurité du cloud passant de 600 millions de dollars à 850 millions de dollars entre 2020 et 2021.
Cette forte tendance est un excellent indicateur des problématiques liées à la sécurité du cloud ainsi que la criticité de ses dernières. Malheureusement, une augmentation des coûts indique aussi une augmentation des risques et des attaques, nous allons nous intéresser à ce qui est communément appelé les "brèches natives du cloud”’.
Les brèches natives du cloud capitalisent sur ces erreurs et exploitent les fonctionnalités natives du cloud pour exécuter leur attaque, souvent sans que le client du cloud ne s'en aperçoive. Passons maintenant à une définition plus détaillée
Les brèches natives du cloud sont une série d'actions menées par un acteur adverse dans lesquelles il "fait atterrir" son attaque en exploitant des erreurs ou des vulnérabilités dans un déploiement de cloud sans utiliser de malware, "étend" son accès par le biais d'interfaces peu protégées ou faiblement configurées pour localiser des données sensibles, et "exfiltre" ces données vers son propre emplacement de stockage.
Dans les attaques sur site, la méthode d'entrée la plus courante consiste à installer un logiciel malveillant sur un appareil de la victime et à l'étendre à partir de là. Cette méthode fonctionne en raison de la prévalence de systèmes d'exploitation présentant des vulnérabilités bien documentées. Dans le nuage, il n'y a pas forcément de système d'exploitation Windows, macOS, Linux ou même Android à compromettre. Au lieu de cela, les attaquants exploitent plus fréquemment des erreurs de configuration ou utilisent des informations d'identification volées pour un accès direct.
Voyons comment s’organise une attaque via une brèche de sécurité sur le cloud.
Atterrir en prenant pied dans l'environnement IaaS/PaaS.
Exploiter des informations d'identification compromises/faibles pour obtenir un accès en tant qu'utilisateur légitime.
Exploiter une vulnérabilité, telle que la falsification de requête côté serveur (SSRF), dans le logiciel déployé.
Tirer parti de la mauvaise configuration des groupes de sécurité d'entrée/sortie.
S'étendre en trouvant des moyens d'aller au-delà du nœud d'atterrissage.
Exploiter les privilèges associés à un nœud compromis pour accéder à des nœuds distants.
Rechercher et exploiter des applications ou des bases de données mal protégées.
Tirer parti de la faiblesse de la sécurité réseau type pare feu, routages etc.
Exfiltrer des données tout en restant sous le radar.
Copier les données du compte de stockage vers des nœuds anonymes sur Internet.
Créer une passerelle de stockage pour accéder aux données à partir d'un emplacement distant.
Copier les données des comptes de stockage vers un emplacement distant en dehors du cloud privé virtuel (VPC).
Comme on peut le voir, la plupart des attaques proviennent d’identifiants compromis (attaques phishing, fuites de bases de données de mot de passes, Combolists etc), de vulnérabilités (récemment la faille Log4j qui permettait d'exécuter du code à distance via le système d’enregistrement des logs) ou de mauvaises configurations (certains ports pas protégés, des tunnels ouverts non sécurisés etc). D'où l'importance de sécuriser les accès des utilisateurs, de segmenter les zones d’accès.
Voilà qui conclut mon billet sur la sécurisation des données dans le cloud. Nous avons vu quelles étaient les différentes responsabilités quelques best practices de sécurisation et enfin le déroulé en détail d’une faille et attaque. J'espère que celà vous a permis d’obtenir une vision un peu plus claire de cet environnement en plein essor qu’est le cloud. Un autre aspect primordial et plus éthique du traitement des données dans le cloud est celui de l’anonymisation des données qui sera sûrement traité dans un autre billet.
