« 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