Rechercher dans la communauté

« La sécurité du cloud fait référence aux règles, bonnes pratiques, contrôles et technologies de cybersécurité permettant de sécuriser les applications, les données et l'infrastructure dans les environnements cloud. » Dans ce billet : client = une entreprise qui fait appel à un fournisseur pour accéder à un service cloud Si le cloud peut regrouper pour une entreprises ses données, ses applis, et ses services informatiques, alors une question essentielle se pose. Qui est responsable de la sécurité dans le cloud ? On pourrait croire que le fournisseur est responsable à 100%, comme c’est lui qui fournit le service ; mais ce n’est pas aussi simple. En réalité, la responsabilité est partagée entre le client et le fournisseur,et il existe des périmètres clairement définis. La dernière fois, on avait vu les 3 types de services cloud que proposent les fournisseurs (IaaS, PaaS, SaaS). Enfait, le périmètre va varier en fonction du service. Et c’est cette confusion et incompréhension de supposer que « le cloud s’en occupe » qui va créer des angles morts. Minis définitions par chat GPT pour comprendre certaines notions : Infrastructure : l'ensemble des ressources techniques nécessaires pour faire fonctionner les services informatiques : serveurs, stockage, réseau, etc. Serveur : un ordinateur ou système informatique qui fournit des ressources ou des services à d'autres machines. Runtime : l'environnement logiciel qui permet à une application de s'exécuter. Par exemple, Node.js permet d'exécuter des applications JavaScript côté serveur. Donc là on va classer les types de services du plus au moins de responsabilités pour le client, ça va permettre aussi de mieux comprendre les types de services parce que mes définitions du billet précédent étaient un peu vaseuses : IaaS : « J’aimerais des ressources informatiques sans acheter les machines physiques ». Par exemple, le fournisseur AWS peut fournir un service IaaS avec EC2, qui permet au client de louer une instance (comme une machine virtuelle). Grossomodo, le fournisseur est responsable de l’infrastructure physique, et du réseau sous-jacent. Et là, c’est là où le client a le plus de responsabilité, parce qu’il aura choisit IaaS pour justement avoir davantage de contrôle et de liberté. Il gère une grande partie de son environnement informatique (par exemple, choisir une version spécifique de linux ou choisir les logiciels qu’il veut installer). Donc il aura beaucoup plus de choses à gérer PaaS : La, le founisseur gère une plus grande partie de l’infrastructure et de l’environnement comme le système d’exploitation et le runtime. Le client, n’a pas à gérer directement les serveurs. Prenons un exemple concret. Un forum est une application web qui a besoin d’être relié à internet pour être accessible à nous. Il faut bien l’héberger quelque part ! soit si il est motivé, le fondateur a un serveur chez lui qu’il a configuré, soit il utilise un IaaS mais pareil y a toute la configuration de l’infrastructure, soit un PaaS comme Heroku. Donc la concrètement, si il choisit de déployer son application sur le service PaaS, le développeur est responsable de l’application, des données et des accès. Il veut faire tourner l’application sans s’occuper de toute la machine qui se trouve dessous. Par contre ce n’est pas le fournisseur qui va pouvoir empêcher des attaques par injection SQL, le développeur est responsable de son code. SaaS : Prenons l’exemple de Microsoft 365 Enterprise, qui est une formule qui fournit aux entreprises les outils de Microsoft 365 (Excel, Word, Powerpoint,…) aux employés ainsi qu’un service de messagerie, des fonctions de sécurité avancée,… La concrètement, le fournisseur (ici Microsoft) s’occupe de l’ensemble de la pile. MAIS « le client reste responsable de la configuration du service, des données qu'il y stocke, des accès accordés, et de la conformité réglementaire. » Bref, donc cloud = responsabilité partagée Et une entreprise ou structure a tout intérêt à se préoccuper de la sécurité et à limiter les risques, parce qu’une sécurité défaillante peut avoir un grand impact sur son activité et sur sa réputation. D’où l’importance, d’être conscient des risques pour les limiter au maximum. Quels sont les risques en cloud computing au sein de l’entreprise ? Perte de visibilité : Admettons une entreprise accède à plusieurs services Cloud (Microsoft 365, AWS, un service de stockage, des employés travaillant depuis différents pays et appareils…). Ça fait une grande surface, et donc une grande surface à sécuriser. Donc avec cette complexité de l'environnement, on parle de perte de visibilité lorsque l’entreprise ne voit pas ce qui ce passe et n'arrive pas à tout surveiller, et donc elle aura plus de mal à détecter des activités suspectes. Violations de conformité : une entreprise doit respecter des exigences de conformités strictes. Lors du transfert vers le cloud, elle doit faire attention aux reglementations "Nombre de ces réglementations exigent que votre entreprise sache où se trouvent vos données, qui y a accès, comment elles sont traitées et comment elles sont protégées." L’état de non-conformité expose à des répercussions juridiques et financières. Absence de stratégie et d’architecture de sécurité Cloud : Une entreprise peut avoir hâte de migrer les systèmes et les données vers le cloud. Donc, elle peut obtenir rapidement une infrastructure qui fonctionne, mais avoir beaucoup de failles de sécurité. D’où l’importance d’intégrer la sécurité dès le début. Menaces d’initiés : Initié peut désigner quelqu’un de confiance (employés, partenaires commerciaux,…), c’est dur à croire, mais cela constitue un risque, une menace interne. Pas nécessairement parce que la personne de confiance a une intention malveillante (même si ça peut arriver), mais simplement par négligence ou un manque de formation. Par exemple, un employé a accès à un dossier sensible, il envoie le mauvais fichier à la mauvaise personne, et pouf, un incident de sécurité. Interface utilisateur d’application non sécurisée (API) : Déjà, une API est une manière pour deux logiciels de communiquer ensemble. Par exemple, pour un forum, on a grossomodo le frontend et le backend. Le frontend s’occupe de toute la mise en page du site, et est accessible directement à l’utilisateur. Le backend expose l’API, s’occupe de toute la logique derrière et communique avec la base de donnés. Par exemple lorsqu’on consulte la page des sujets récents, le frontend peut récupérer les nouveaux sujets en envoyant à l’API une requête http style « GET /api/sujets », le backend intéroge la base de données et renvoie la réponse. Certaines choses ne sont consultable/modifiable que par des personnes spécifiques. Par exemple, un utilisateur peut modifier son profil mais pas les autres profil (encore heureux j’ai envie de dire). La requête du frontend va être du style « PUT /api/profile », et le backend va vérifier s’il s’agit bien de l’utilisateur en question. Une API est bien sécurisée si elle vérifie bien qui entre et ce qu’il a le droit de faire. Alors que celle non sécurisée peux permettre à un attaquant de modifier, supprimer des données, d’accèder à des choses qu’il n’est censé consulter,… Mauvaise configuration des services de Cloud : Comme on a dit tout à l’heure, la responsabilité est partagée, et donc même si l’infrastructure peut être très bien sécurisé par le fournisseur, l’entreprise doit être vigilante. Prenons Microsoft 365 Enterprise, une mauvaise configuration peut désigner beaucoup de choses, mais prenons la gestion des privilèges. Une entreprise possède différents comptes utilisateurs, avec des niveaux de privilèges différents : certains comptes avec des privilèges d'administration, les employés avec des droits plus limités. Si dû à une mauvaise configuration, un utilisateur a des privilèges d'admin, alors qu'il en a pas besoin, il pourrait par exemple modifier, créer, supprimer des comptes utilisateurs, réinitialiser les mdp, modifier les permissions et les rôles d’autres utilisateurs, configurer les paramètres de sécurité, etc… on revient un peu à la menace initié, mais ça peut aller au-delà, si l’utilisateur en question se fait compromettre les conséquences peuvent être grandes. D’où un principe fondamental c’est le principe du moindre privilège "Chaque personne, chaque programme et chaque service ne doit recevoir que les droits strictement nécessaires à sa tâche, et pas un de plus" Sources

On a vu que les hackers pouvaient trouver les mots de passe, ok. Mais il reste encore plein de surfaces d’attaque et de méthodes. Vous connaissez le modèle OSI ? En somme, Open Systems Interconnection « est une norme de communication de tous les systèmes informatiques en réseau ». C’est un modèle qui va permettre aux applis, systèmes informatiques et réseaux de communiquer. À quoi ressemble ce modèle ? Il s’organise sous forme de couches (on ne va pas s’attarder dessus, je trouve ça vraiment pénible). Tout ça pour en revenir au fait que chaque couche peut être concernée par un panel de vulnérabilités et d’attaques différentes. Tenez, un exemple récent : La Poste a été victime fin 2025 d’une attaque DDoS très sophistiquée. DDoS, c’est quoi ? C’est le fait de surcharger un service (ici, le site de La Poste). Les serveurs (ordis qui font tourner les services en ligne) ont été inondés de requêtes provenant d’un grand nombre de machines. Mais du coup ? Y avait un grand nombre de complices ?? Non, on les appelle des ordinateurs zombies (ou bots). Ce sont des machines infectées à l’insu de leurs propriétaires, contrôlées à distance par des cybercriminels via une infrastructure de commande et contrôle. Les machines peuvent par exemple avoir été infectées via un malware (un logiciel malveillant), et ça peut être via des e-mails de phishing, des sites web compromis, des téléchargements infectés, etc. Il y a eu à peu près 400 experts en cybersécurité, et les assaillants adaptaient leurs méthodes en temps réel pour contourner les défenses mises en place. Au final, par la mobilisation collective, pendant près de 2 semaines, l’attaque a pu être contenue. Quand on parle de contenir une attaque, l’idée est d’éviter qu’elle ne s’étende et qu’elle fasse encore plus de dégâts. Les conséquences : perturbations des services en ligne, mais sans fuite de données, et la continuité de service a été maintenue pour l’essentiel. Bref, aucune organisation n’est à l’abri, et il existe bien d’autres façons d’attaquer un système… Sources

Le hack / les hackers Commençons par les différents types de hackers, car le mot « hacker » ne désigne pas forcément un « criminel ». Même s’il est en réalité difficile d’être parfaitement exact, différents types de hackers existent ; plus précisément, on les distingue grâce à leur chapeau (ils ne portent pas réellement de chapeau, je vous rassure). Black-hat : un peu comme Dark Vador, ce sont les méchants absolus, ce sont ceux qu’on voit le plus dans les médias et qui font les grands titres. Ils s’introduisent dans les systèmes informatiques, le plus souvent dans de grandes infrastructures comme les entreprises, les hôpitaux, et même l’État. Pourquoi ? Par pure malveillance ou par intérêt personnel (revendre les données et récupérer de l’argent, en somme). White-hat : ce sont les opposés des black-hats, des hackers éthiques. Ils ont aussi la capacité de compromettre des systèmes, sauf qu’ils le font légalement. En gros, ils peuvent être embauchés par les entreprises pour justement tenter de trouver des failles et rapporter tout ça à l’entreprise, pour qu’elle puisse s’améliorer : ce sont les tests d’intrusion. Gray-hat : c’est la zone grise, la vie n’est de toute façon ni toute blanche, ni toute noire. Le pirate peut par exemple chercher les failles d’une entreprise et, après les avoir trouvées, les signaler à l’entreprise. Quel est le problème ? L’entreprise n’avait rien demandé, il s’est introduit dans un système informatique sans autorisation, ce qui est par définition illégal. Mais finalement, pourquoi les black-hat veulent-ils avoir les données des gens ? Ça a vraiment des conséquences pour nous ? On est si intéressants que ça ? (Pardon, c’est l’ego qui monte) Vendre les données à d’autres cybercriminels, un butin qui leur rapporte gros. À leur tour, les acheteurs peuvent les utiliser à leur guise, et notamment pour : Usurper l'identité : utiliser votre carte bancaire, contracter des prêts en votre nom… Prendre le contrôle de votre compte en ligne : c’est logique, mais les conséquences sont plus grandes si le compte en question contient vos données de paiement. Cibler les attaques par phishing : ça peut se faire par mail. Ils peuvent par exemple se faire passer pour une entreprise légitime, vous demander de vous connecter sinon votre compte sera suspendu. Et c’est fort, parce que parfois le site peut visuellement être identique au site légitime. Donc il faut toujours vérifier l’expéditeur et l’URL de la page. Ça n'en finit plus : grâce aux données volées, ils peuvent faire du phishing très ciblé, et voler encore plus de données. Nuire aux entreprises : menacer les entreprises de diffuser les données si elles ne livrent pas de rançon De toute façon, à notre échelle, à part se protéger soi-même, on ne peut pas faire du bénévolat pour la sécurité des sites gouvernementaux, des entreprises, des hôpitaux, des écoles… Donc, un kit de survie : Avoir des mots de passe robustes, longs, générés aléatoirement, et surtout, différents pour chaque compte. Et tout ça, même si ça prend du temps, il faut mémoriser tous les mots de passe. Je plaisante bien sûr sur la mémorisation, utilisez un gestionnaire de mots de passe (pas celui de Google, s’il vous plaît). L’intérêt des gestionnaires de mots de passe, c’est que vous avez seulement le mot de passe principal à retenir (par contre, il ne faut pas l’oublier, hein). Mais c’est quoi l’intérêt ? Imaginez : vous avez le même mot de passe et le même mail partout. Un compte se fait pirater, le hacker n’a plus qu’à faire un script pour tester cette combinaison sur plein de sites Limiter son exposition sur Internet Utiliser plusieurs adresses mail Utiliser l’authentification à deux facteurs (2FA), de préférence avec une application d’authentification (vous avez le choix pour l’appli) En parlant des mots de passe, comment les black-hats peuvent-ils trouver votre mot de passe, du coup ? Déjà, il faut savoir que, c'est la base des bases pour un site où des personnes doivent se connecter, on ne stocke jamais les mots de passe en clair. Si ton mdp c’est « patate », il n’y aura pas marqué « patate » dans la base de données, mais plutôt une suite de caractères illisibles : le hash. Il est créé à partir d’un algorithme de hash (logique jusque-là), et il en existe plusieurs, plus ou moins sécurisés (bcrypt, Argon2…). Voilà à quoi ça peut ressembler en base de données : L’intérêt est que, si le site web se fait pirater, cela empêche les cybercriminels d’accéder à vos mots de passe directement. Le hash, c’est à sens unique, donc difficile pour un hacker, même s’il a le hash, de reconstituer votre mot de passe. Mais bon, vous vous en doutez bien, il y a toujours un « mais », sinon ce ne serait pas drôle. Il y a toujours des failles et des raisons pour lesquelles on insiste tant pour avoir des mots de passe robustes. Voilà comment certains hackers réussissent quand même à trouver votre mot de passe L’attaque par force brute : on teste toutes les combinaisons de mots de passe une à une, pas à la main, mais avec un algorithme. « Un ordinateur personnel est capable de tester plusieurs centaines de milliers, voire quelques millions de mots de passe par seconde », de la part de notre ami Wikipédia. L’attaque par rainbow table C’est grossier, mais c’est pour donner une idée. Déjà, on fait marcher un algorithme de hash sur plein de mots de passe, souvent les mots de passe les plus utilisés, des mots du dictionnaire… On obtient un beau tableau à double entrée, contenant les mots de passe et le hash correspondant. Le hacker a préalablement récupéré les hashs des utilisateurs sur un site et, pour trouver les mots de passe correspondants, il utilise sa fameuse rainbow table. D’ailleurs, pour les mots de passe les plus utilisés en France : Si vous voyez votre mdp, je vous conseille vivement de le changer La, ça souligne également l’importance du choix des plateformes dans leur algorithme de hashage : " Les fonctions de hachage sécurisées comme bcrypt ou Argon2 utilisent le salage pour ajouter des données aléatoires à votre mot de passe avant de créer son hachage" Sources :