Les bases de la sécurité cloud : identités, droits et erreurs de configuration
Aujourd'hui, une grande partie des applications ne tourne plus dans une salle serveur au sous-sol, mais chez un fournisseur de services cloud. On y loue des machines, du stockage, des bases de données, en quelques clics. Cette facilité est la source des principaux risques : une mauvaise case cochée peut exposer des milliers de fichiers au monde entier. Cette leçon vous donne les repères pour comprendre la sécurité du cloud et reconnaître les erreurs de configuration les plus courantes.
Cadre légal : le cloud, c'est le système de quelqu'un d'autre
Tester un environnement cloud sans autorisation écrite expose aux mêmes sanctions que n'importe quelle intrusion (Code pénal, articles 323-1 à 323-3-1). Il y a même deux niveaux d'autorisation : celle de votre client et les règles du fournisseur, qui précisent ce qu'il est permis de tester sur son infrastructure. Lisez toujours la politique de tests du fournisseur avant tout exercice. Pour vous entraîner, utilisez votre propre compte d'essai, que vous configurez vous-même, ou les environnements des plateformes d'entraînement légales.
Dans le chapitre précédent, vous avez construit votre dossier de défense. Nous élargissons maintenant le regard aux environnements modernes. Le fil rouge de ce chapitre est une checklist de revue de sécurité pour une application fictive d'Atelier Boréal déployée dans le cloud ; elle s'enrichira à chaque leçon.
Le modèle de responsabilité partagée
Le principe le plus important du cloud est la responsabilité partagée. Imaginez un immeuble en copropriété : le propriétaire de l'immeuble est responsable de la structure, de l'entrée principale et de la toiture ; chaque locataire est responsable de la serrure de son appartement et de ce qu'il y laisse traîner.
- Le fournisseur sécurise l'infrastructure : bâtiments, matériel, réseau de base, logiciel de virtualisation.
- Le client sécurise ce qu'il y met : ses comptes, ses données, ses droits d'accès, la configuration de ses services, le code de ses applications.
La répartition précise dépend du type de service (machine louée, plateforme managée, service logiciel complet), mais une règle reste constante : les données et les accès sont toujours votre responsabilité. La plupart des incidents cloud viennent de la configuration du client, pas d'une faille du fournisseur.
L'identité, nouveau périmètre
Dans un réseau d'entreprise traditionnel, on protégeait un périmètre (un pare-feu) autour des machines. Dans le cloud, la plupart des ressources sont accessibles via Internet, et l'identité devient le véritable périmètre. Qui est autorisé à faire quoi ? Cette question se gère par la gestion des identités et des accès (IAM). Trois notions de base :
- les identités : utilisateurs humains, mais aussi services et applications (qui ont leurs propres identités techniques) ;
- les rôles et politiques : des ensembles de permissions (« peut lire ce stockage », « peut créer des machines ») attribués aux identités ;
- les clés d'accès et jetons : des secrets qui permettent à un programme de s'authentifier.
Le principe du moindre privilège, rencontré dès le premier cours, devient décisif : chaque identité ne doit recevoir que les permissions dont elle a besoin. Une politique qui autorise « toutes les actions sur toutes les ressources » équivaut à donner un passe-partout à quelqu'un qui n'a besoin que d'une clé de bureau.
Les erreurs de configuration les plus courantes
Voici le catalogue des erreurs que les audits de sécurité cloud rencontrent le plus souvent :
| Erreur | Pourquoi c'est un risque | Bonne pratique |
|---|---|---|
| Stockage de fichiers accessible publiquement | Des données privées lisibles par n'importe qui sur Internet | Accès privé par défaut, public seulement si nécessaire et justifié, contrôles automatiques |
| Permissions trop larges (« tout pour tous ») | Un compte compromis donne accès à tout | Moindre privilège, revues régulières, permissions limitées à des ressources précises |
| Compte administrateur principal utilisé au quotidien, sans authentification multifacteur | Un mot de passe volé suffit pour tout contrôler | Multifacteur obligatoire, comptes d'administration séparés, usage rare du compte racine |
| Secrets (clés d'accès) écrits dans du code ou un dépôt public | Des robots scrutent en permanence les dépôts publics à la recherche de secrets | Coffre-fort de secrets, analyse automatique des dépôts, rotation des clés, révocation immédiate en cas de fuite |
| Ports d'administration ouverts à tout Internet | Exposition aux tentatives de connexion automatisées | Restreindre à des adresses connues, passer par un accès d'administration sécurisé |
| Journalisation désactivée | Impossible d'enquêter ou de détecter un incident | Journaux d'audit activés, centralisés, conservés |
| Données non chiffrées | Exposition accrue en cas d'accès non prévu | Chiffrement au repos et en transit, gestion des clés |
| Ressources oubliées (anciens tests, copies) | Surface d'attaque inconnue et non mise à jour | Inventaire, étiquetage, suppression des ressources inutilisées |
Remarquez qu'aucune de ces erreurs n'exige une attaque sophistiquée pour être exploitée : un simple moteur de recherche ou un balayage automatisé suffit parfois à les trouver. D'où l'importance de la vérification continue.
Auditer le cloud : l'état d'esprit
Un audit de configuration cloud, dans un cadre autorisé, répond à des questions concrètes :
- Qui peut faire quoi ? (analyse des identités et des politiques)
- Qu'est-ce qui est exposé à Internet ? (stockage, réseau, services)
- Où sont les secrets ? Sont-ils protégés et renouvelés ?
- Quels journaux existent, et sont-ils exploitables ?
- Les données sensibles sont-elles chiffrées, localisées et protégées conformément aux exigences légales ?
Des outils d'analyse de la posture de sécurité (CSPM) comparent la configuration réelle à des bonnes pratiques et signalent les écarts. Les fournisseurs proposent leurs propres outils de diagnostic, et plusieurs projets libres existent. L'important est la démarche : on vérifie la configuration, on ne force aucune protection. Les référentiels de bonnes pratiques de l'ANSSI (cyber.gouv.fr) et du NIST (nist.gov) offrent des cadres d'évaluation reconnus ; l'OWASP (owasp.org) propose aussi des ressources sur la sécurité du cloud et des applications.
Penser à la localisation et au droit
Le cloud pose aussi des questions juridiques : où sont stockées les données ? Quel droit s'applique ? Un traitement de données personnelles de résidents européens doit respecter le RGPD, y compris quand le fournisseur est situé hors de l'Union. Le choix de la région de stockage et les clauses contractuelles font partie de la sécurité, au sens large.
À vous de jouer
Voici la description fictive de l'environnement cloud d'Atelier Boréal, tel qu'un audit le découvre :
- Le stockage « plans-clients » est accessible en lecture à tous les internautes, car « c'est plus pratique pour les partenaires ».
- Le développeur principal utilise le compte administrateur principal pour tout, sans authentification multifacteur.
- Une clé d'accès d'application figure dans un fichier de configuration d'un dépôt de code public.
- Les journaux d'audit sont désactivés « pour économiser de l'espace ».
- Le port d'administration à distance des machines est ouvert à toutes les adresses.
Classez ces cinq constats du plus critique au moins critique, et proposez pour chacun une recommandation d'une ligne.
Voir une solution
- Clé d'accès dans un dépôt public : critique et urgent. Recommandation : révoquer la clé immédiatement, en créer une nouvelle, la stocker dans un coffre-fort de secrets, examiner les journaux pour détecter un usage éventuel (et se souvenir que supprimer le fichier ne suffit pas : l'historique du dépôt conserve la clé).
- Stockage public contenant des plans clients : critique. Recommandation : rendre le stockage privé et fournir aux partenaires un accès individuel limité dans le temps.
- Compte administrateur utilisé au quotidien sans multifacteur : critique. Recommandation : activer le multifacteur, créer des comptes distincts à droits limités.
- Port d'administration ouvert à tous : élevé. Recommandation : restreindre à des adresses de confiance ou utiliser un accès d'administration sécurisé.
- Journaux désactivés : élevé, car sans eux, aucune détection ni enquête n'est possible. Recommandation : activer les journaux d'audit et les centraliser ; l'économie de stockage est négligeable face au risque.
L'ordre exact peut varier selon le contexte ; l'essentiel est de le justifier par l'impact et la facilité d'exploitation.
Pour votre checklist
Ajoutez à votre checklist de revue une première section « Cloud » avec les cinq catégories : identités, exposition, secrets, journalisation, chiffrement. Chaque ligne de cette section sera une question à poser à l'équipe responsable.
À retenir
- Dans le cloud, la responsabilité est partagée : le fournisseur sécurise l'infrastructure, le client ses données, ses accès et sa configuration.
- L'identité est le nouveau périmètre : IAM, moindre privilège, multifacteur et comptes distincts sont essentiels.
- Les erreurs de configuration (stockage public, droits trop larges, secrets exposés, journaux absents) causent la majorité des incidents.
- On audite en vérifiant la configuration, avec l'accord du client et en respectant la politique du fournisseur.
- La localisation des données et le RGPD font partie de la sécurité.