Sécurité offensive
Gouvernance & conformité
Protection des données
Le Cloud n’est plus un choix, c’est l’état des lieux : messagerie, CRM, paie, sauvegardes, et de plus en plus souvent les applications métier elles-mêmes. Les données sensibles ont suivi. Pourtant, la question de leur protection est encore trop souvent posée au fournisseur seul, comme si le contrat réglait tout. Il ne règle qu’une partie du problème, et pas celle qui provoque la majorité des fuites.
Chez Digitemis, nous auditons des environnements Cloud et nous accompagnons des RSSI et des DPO qui doivent en répondre. Cet article donne les repères qui comptent réellement : ce qui vous incombe, comment choisir un fournisseur, et quels contrôles conduire.
Les données qui méritent le qualificatif de sensibles
Le mot recouvre deux réalités qu’il vaut mieux distinguer, parce qu’elles n’appellent pas les mêmes obligations. Il y a d’abord les données personnelles au sens du RGPD, et parmi elles les catégories particulières de l’article 9 : santé, orientation sexuelle, opinions politiques, convictions religieuses, appartenance syndicale, données biométriques et génétiques. S’y ajoutent les données d’infraction, les identifiants et les données financières, qui ne sont pas des catégories particulières mais dont la fuite expose directement les personnes.
Il y a ensuite les données stratégiques de l’entreprise : propriété intellectuelle, plans commerciaux, listes clients, éléments comptables, secrets de fabrication. Le RGPD ne les protège pas ; leur perte peut pourtant coûter plus cher qu’une sanction de la CNIL.
Avant de parler de fournisseur ou de chiffrement, une organisation doit savoir lesquelles de ces données sont dans le Cloud, dans quels services, et qui y accède. C’est l’inventaire qui manque le plus souvent, et il est impossible de protéger ce qu’on ne sait pas posséder.
Le partage des responsabilités
Tous les grands fournisseurs formalisent un modèle de responsabilité partagée. Le principe est constant : le fournisseur est responsable de la sécurité du Cloud, le client de la sécurité dans le Cloud. Le fournisseur répond de ses centres de données, de son infrastructure physique, de l’hyperviseur et du réseau. Le client répond de ses données, de ses identités, de ses configurations, de ses accès et de ce qu’il chiffre ou non.
La frontière se déplace selon le service. Sur une infrastructure louée (IaaS), le client administre jusqu’au système d’exploitation. Sur une plateforme (PaaS), il ne gère plus que ses applications et ses données. Sur un logiciel en ligne (SaaS), il lui reste les comptes, les droits, les paramètres et les données. Dans tous les cas, ce qui reste au client est exactement ce qui est exploité dans la plupart des incidents Cloud : un espace de stockage ouvert au public, un compte sans authentification forte, une clé d’accès publiée dans un dépôt de code, un droit d’administration donné à tout le monde par commodité.
Un contrat solide ne transfère pas ces responsabilités. Il précise ce que fait le fournisseur, et par soustraction, ce qui vous reste.
Le choix du modèle de déploiement
Le modèle de déploiement conditionne le niveau de contrôle et le coût. Quatre familles existent :
- le Cloud privé, hébergé sur site ou chez un prestataire mais dédié à une seule organisation, qui conserve la maîtrise de l’infrastructure au prix de l’investissement et de l’exploitation ;
- le Cloud public, mutualisé entre clients, élastique et facturé à l’usage, où la sécurité des données repose presque entièrement sur la configuration et la gouvernance du client ;
- le Cloud hybride, qui garde les traitements sensibles sur une infrastructure privée et déporte le reste, ce qui suppose de bien classer les données au préalable ;
- le multicloud, qui répartit les services entre plusieurs fournisseurs pour limiter la dépendance ou respecter des contraintes de localisation, au prix d’une complexité de supervision réelle.
Aucun de ces modèles n’est sûr en soi. Un Cloud privé mal administré est moins protégé qu’un service public correctement configuré. Le modèle se choisit selon les données, les compétences internes et les exigences réglementaires, pas selon une hiérarchie supposée de sécurité.
Les critères de choix d’un fournisseur
Les questions à poser à un fournisseur tiennent en six familles. Elles valent pour un hyperscaler comme pour un éditeur SaaS de dix personnes.
- Localisation et droit applicable. Où sont hébergées les données, où sont-elles sauvegardées, et à quelle législation le fournisseur est-il soumis ? Un hébergement en Europe chez un prestataire de droit américain reste exposé aux demandes d’accès prévues par le droit des États-Unis. Pour les données les plus sensibles, la qualification SecNumCloud de l’ANSSI répond précisément à cette question.
- Certifications et audits. ISO 27001, hébergement de données de santé (HDS) pour le secteur médical, SOC 2 pour les acteurs anglo-saxons. Une certification ne dispense pas de lire son périmètre : elle peut couvrir un centre de données et pas le service que vous achetez.
- Sous-traitance en cascade. Qui sont les sous-traitants du fournisseur, et comment êtes-vous informé de leur changement ? L’article 28 du RGPD l’exige, et c’est souvent là que se cache un transfert hors Union européenne.
- Réversibilité. Dans quel format récupérez-vous vos données, sous quel délai, et à quel coût ? Que devient la donnée après résiliation, sauvegardes comprises ?
- Transparence sur les incidents. Sous quel délai et par quel canal le fournisseur vous notifie-t-il une violation ? Le RGPD vous laisse 72 heures pour notifier la CNIL, et ce délai court à partir du moment où vous en avez connaissance, pas du moment où le fournisseur a fini son enquête.
- Engagements de service. Disponibilité garantie, redondance, plan de continuité et modalités de test. Un taux de disponibilité affiché sans pénalité contractuelle n’engage à rien.
La gouvernance des accès et des usages
C’est le chantier qui relève entièrement du client, et celui où l’écart entre les organisations est le plus grand. Il commence par l’inventaire des services Cloud réellement utilisés, ce qui inclut ceux que les équipes ont souscrits sans passer par la DSI. Le Shadow IT n’est pas une faute morale, c’est une donnée d’entrée : un service inconnu n’est ni contractualisé, ni configuré, ni supervisé.
Il se poursuit par la gestion des identités et des accès. Authentification forte pour tous les comptes, sans exception pour les dirigeants ni pour les comptes de service. Droits attribués selon le principe du moindre privilège et revus périodiquement, en particulier à chaque départ ou changement de poste. Comptes d’administration séparés des comptes d’usage courant. Clés d’accès et secrets stockés dans un coffre, jamais dans le code ni dans un document partagé.
Il se termine par la journalisation. Les journaux d’accès et de configuration doivent être activés, conservés hors de portée d’un attaquant qui aurait compromis un compte, et lus. Une alerte sur un partage public ou sur une connexion depuis un pays inhabituel vaut mieux qu’un rapport trimestriel.
Le chiffrement et la gestion des clés
Le chiffrement des données en transit est acquis chez tout fournisseur sérieux. Le chiffrement au repos l’est presque toujours aussi, mais il faut regarder qui détient la clé. Si le fournisseur la génère, la conserve et l’utilise, il peut lire vos données, et une autorité qui le lui demande aussi. Ce chiffrement protège contre le vol d’un disque, pas contre un accès logique.
Trois niveaux existent au-dessus de ce socle. Le client peut apporter sa propre clé au service de gestion des clés du fournisseur (BYOK), ce qui lui donne la main sur sa rotation et sa révocation. Il peut conserver la clé dans un équipement qu’il contrôle et que le fournisseur interroge à chaque opération (HYOK), ce qui rend les données illisibles pour le fournisseur mais introduit une dépendance technique et une latence. Il peut enfin chiffrer côté client avant l’envoi, solution la plus protectrice et la plus contraignante, qui prive souvent le service de ses fonctions de recherche ou de traitement.
Le bon niveau dépend de la sensibilité des données et de l’usage. Chiffrer côté client une messagerie collaborative la rend inutilisable ; ne pas le faire pour une base de dossiers médicaux hébergée hors HDS est une faute.
Les contrôles à conduire
Un environnement Cloud se dérègle vite : une exception accordée pour un projet, un service activé pour un test et jamais désactivé, un droit élargi pour débloquer une équipe. Les contrôles servent à rattraper cette dérive.
- L’audit de configuration compare l’état réel des services (stockage, identités, réseau, journalisation) aux référentiels de durcissement de l’éditeur et aux bonnes pratiques de l’ANSSI. C’est le contrôle qui détecte les erreurs les plus fréquentes.
- L’audit d’architecture examine la conception d’ensemble : cloisonnement entre environnements, flux, exposition des services, dépendances entre composants.
- Le test d’intrusion externe vérifie ce qu’un attaquant obtient réellement depuis l’extérieur, ou depuis un compte utilisateur compromis.
- Le test du plan de reprise confirme que les sauvegardes se restaurent, dans un délai compatible avec l’activité, et qu’elles ne sont pas chiffrables par le même rançongiciel que la production.
Ces contrôles se conduisent à la mise en place, puis à chaque évolution significative, et au moins une fois par an pour les environnements qui portent des données sensibles. Entre deux audits, les outils de gestion de la posture Cloud proposés par les fournisseurs signalent les écarts de configuration les plus courants, à condition que quelqu’un lise leurs alertes.
Ce que la réglementation attend
Le RGPD impose des mesures de sécurité adaptées au risque (article 32), un contrat encadrant chaque sous-traitant (article 28) et un cadre pour tout transfert hors de l’Union européenne (chapitre V). Il ne nomme jamais le Cloud, mais chacune de ces obligations le concerne au premier chef.
La directive NIS 2 demande aux entités concernées de maîtriser la sécurité de leur chaîne d’approvisionnement, ce qui inclut leurs fournisseurs Cloud. Le règlement DORA, pour le secteur financier, va plus loin : registre des prestataires de services TIC, clauses contractuelles obligatoires, stratégie de sortie pour les prestataires critiques, et supervision européenne directe des plus importants d’entre eux.
Le point commun de ces textes est de vous rendre responsable de vos fournisseurs. Vous pouvez déléguer l’exploitation, pas la responsabilité.
Reste la question de la souveraineté, que nous avons traitée dans un article dédié : elle n’est pas une posture, mais une dépendance qui se mesure, service par service. Protéger ses données sensibles dans le Cloud commence par cette mesure.