Confidentialite et classification dans le cloud¶

Comment appliquer un modèle de classification des données aux déploiements cloud, et quels contrôles mettre en place pour chaque niveau.

Rappel du modèle de classification¶

La classification des données attribue à chaque actif informationnel un niveau de sensibilité qui determine les contrôles de sécurité applicables. Le modèle à quatre niveaux est le plus repandu :

Risques spécifiques au cloud¶

Le cloud introduit des risques que l'hebergement on-premise ne présente pas, ou présente differemment.

Responsabilité partagee appliquee à la confidentialite¶

Le fournisseur cloud assure la sécurité physique de l'infrastructure (datacenters, réseau physique, hyperviseur). Le client reste responsable de la sécurité logique : chiffrement des données, contrôle d'accès, configuration des services.

Une mauvaise configuration (bucket de stockage public, base de données exposée sans authentification) est la première cause de fuites de données dans le cloud.

Résidence des données¶

Les reglementations européennes et françaises imposent des contraintes sur la localisation géographique des données sensibles :

• RGPD : transfert hors UE/EEE soumis à des mécanismes de protection (clauses contractuelles types, adequation)
• HDS : hébergement en France obligatoire pour les données de sante
• SecNumCloud : exige une immunite au droit extraterritorial et un hebergement sur le territoire national

Le choix de la region cloud est un acte de classification : une donnée Restreinte soumise au droit français ne doit pas résider dans une region US, même chez un fournisseur disposant de regions européennes.

Isolation multi-tenant¶

Les services cloud sont par nature multi-locataires. L'isolation entre clients repose sur des couches logiques (virtualisation, conteneurisation, chiffrement). Pour les données Restreintes, il peut être nécessaire d'exiger :

• Des instances dédiées (dedicated hosts / sole-tenant nodes)
• Des environnements isolés (GovCloud, regions souveraines)
• Un chiffrement avec des clés exclusivement contrôlees par le client

Correspondance classification / services cloud¶

Le choix du service cloud dépend du niveau de classification de la donnée traitee.

Chiffrement dans le cloud¶

Chiffrement au repos et en transit¶

Le chiffrement en transit (TLS 1.2+) est généralement activé par défaut. Le chiffrement au repos varie :

• Chiffrement par défaut : le fournisseur chiffre avec ses propres clés (Google default encryption, AWS SSE-S3). Suffisant pour les données Public et Interne.
• CMEK (Customer-Managed Encryption Keys) : le client crée et contrôle les clés de chiffrement via le service de gestion de clés du fournisseur. Indispensable pour les données Confidentiel.
• CSEK (Customer-Supplied Encryption Keys) : le client fournit directement la clé à chaque opération. Le fournisseur ne stocke jamais la clé. Cas d'usage Restreint spécifiques.

HSM dans le cloud¶

Un HSM (Hardware Security Module) est un dispositif physique dédié à la gestion cryptographique. Les fournisseurs cloud proposent des HSM managés :

Les HSM cloud permettent de stocker les clés maîtres dans un module certifié tout en beneficiant de l'élasticité du cloud pour les opérations de chiffrement.

Chiffrement par enveloppe¶

Le chiffrement par enveloppe (envelope encryption) est le patron standard dans le cloud :

1. Une clé de données (DEK) est générée pour chiffrer les données
2. La DEK est elle-même chiffrée par une clé maître (KEK) stockee dans le KMS ou le HSM
3. Seule la DEK chiffrée est stockee à côté des données

Ce mécanisme permet de chiffrer de grands volumes sans solliciter le KMS pour chaque opération, tout en garantissant que la compromission du stockage ne suffit pas à déchiffrer les données.

Contrôle d'accès¶

Politiques IAM¶

Le contrôle d'accès dans le cloud repose sur des politiques IAM (Identity and Access Management) qui définissent qui peut faire quoi sur quelles ressources.

Principes clés :

• Moindre privilege : chaque identité ne dispose que des permissions strictement nécessaires à sa fonction
• Séparation des rôles : les rôles d'administration, de développement et d'audit sont distincts
• Conditions contextuelles : les politiques peuvent restreindre l'accès par adresse IP source, horaire, ou état du device

Comptes de service¶

Les comptes de service (service accounts) sont des identités non humaines utilisees par les applications. Ils représentent un risque majeur s'ils sont mal gérés :

• Éviter les clés statiques exportees : préférer la fédération d'identité (Workload Identity sur GCP, IRSA sur AWS, Managed Identity sur Azure)
• Appliquer le moindre privilege : un compte de service ne doit accéder qu'aux ressources de son propre périmètre
• Effectuer une rotation régulière des credentials quand les clés statiques sont inévitables

Accès juste-à-temps (JIT)¶

Pour les données Confidentiel et Restreint, l'accès permanent aux ressources sensibles est proscrit. L'accès juste-à-temps (Just-In-Time) accorde des permissions élevées uniquement pour une durée limitee, après validation :

• Approbation manuelle par un pair ou un responsable
• Justification documentee (ticket, incident)
• Révocation automatique après expiration du delai

Audit et traçabilite¶

Journaux d'audit cloud¶

Chaque fournisseur propose un service de journalisation des actions sur les ressources :

Ces journaux doivent être :

• Activés sans exception sur tous les projets/comptes, y compris les environnements de développement
• Exportés vers un stockage immutable (bucket verrouillé, Log Analytics) pour empêcher leur suppression
• Conserves selon la politique de rétention définie par la classification (minimum 1 an pour Confidentiel, 5 ans pour Restreint)

Integration SIEM¶

Les journaux cloud doivent être intégrés dans la plateforme SIEM (Security Information and Event Management) de l'organisation pour :

• Corréler les événements cloud avec les événements on-premise
• Détecter les comportements anormaux (accès inhabituel, exfiltration de données)
• Déclencher des alertes automatisees et alimenter les processus de réponse à incident

Conformite et certifications du fournisseur¶

Les fournisseurs cloud disposent de certifications qui attestent de leurs contrôles de sécurité. Ces certifications sont des artefacts d'audit partagés : le client peut s'appuyer dessus pour sa propre démarche de conformité sans auditer directement le fournisseur.

Landing zones¶

Une landing zone est un environnement cloud pré-configuré qui applique automatiquement les contrôles de sécurité correspondant au niveau de classification des données qu'il heberge.

Principe¶

Plutôt que de configurer manuellement chaque projet ou compte, on définit des modèles de landing zones alignés sur les niveaux de classification :

Mise en œuvre¶

Les landing zones sont déployees via l'infrastructure as code (Terraform, Pulumi) et appliquent des politiques organisationnelles (Organization Policies sur GCP, Service Control Policies sur AWS, Azure Policy) qui empêchent toute deviation par rapport au standard de sécurité.

Un projet déployé dans une landing zone Confidentielle hérite automatiquement du chiffrement CMEK, de la restriction de region et de la journalisation avancee, sans intervention manuelle.

Points clés¶

• La classification des données determine les contrôles cloud à appliquer : chiffrement, accès, audit, localisation
• Le chiffrement CMEK est le minimum requis pour les données Confidentiel ; les données Restreint nécessitent un HSM
• Le contrôle d'accès repose sur le moindre privilege, les comptes de service fédérés et l'accès juste-à-temps
• Les journaux d'audit doivent être immutables, exportés et intégrés au SIEM
• Les landing zones automatisent l'application des contrôles par niveau de classification