Cloud Compliance

La conformité dans le cloud consiste à démontrer que les données, les charges de travail et leurs contrôles dans les services cloud satisfont les exigences applicables à l'organisation. Elle recouvre des textes comme le GDPR, HIPAA ou la LGPD, des engagements contractuels comme PCI DSS et des référentiels d'évaluation comme ISO 27001 et SOC 2. Confier des systèmes à un fournisseur cloud change l'endroit où s'exécutent les contrôles, pas les obligations.

Ce qui doit être contrôlé dépend du modèle de service. En infrastructure as a service, le client configure les systèmes d'exploitation, les applications et les paramètres de données, donc la plupart des exigences s'appliquent directement. En software as a service, le fournisseur exploite la plateforme, tandis que le client gouverne les identités, les paramètres de partage et ce que les utilisateurs peuvent exporter. Dans tous les modèles, les données réglementées restent sous la responsabilité du client.

Chaque grand fournisseur publie un modèle de responsabilité partagée. Le fournisseur répond du cloud lui-même : matériel, sécurité physique et disponibilité. Le client répond de la sécurité et de la conformité dans le cloud : classification des données, décisions d'accès, configuration et activité des utilisateurs. Les certifications du fournisseur couvrent son côté de cette ligne, jamais celui du client.

Cette répartition compte, car les régulateurs tiennent le propriétaire des données pour responsable. Une autorité de contrôle n'accepte pas « le fournisseur était certifié » comme réponse lorsque la cause est un espace de stockage mal configuré, un document partagé avec quiconque détient le lien ou un salarié qui exporte des enregistrements vers un compte personnel. Le travail de conformité commence par projeter la matrice de responsabilités de chaque service sur les obligations de l'organisation, puis par combler les lacunes côté client : identité, configuration, journalisation et traitement des données.

Le droit de la protection des données suit les données, pas l'infrastructure. Au titre du GDPR, recourir à un fournisseur cloud crée une relation de sous-traitance : il faut un accord de traitement des données, des sous-traitants documentés et des garanties de transfert lorsque les données quittent la région. HIPAA exige un accord de partenaire commercial avant que des informations de santé protégées n'atteignent les services du fournisseur.

Deux obligations en découlent. La première est de savoir quelles données réglementées existent et où elles se trouvent : quels services les hébergent, dans quelles régions et selon quels accords. C'est impossible sans classification ni inventaire des services, qui couvre aussi le Shadow IT, c'est-à-dire les outils adoptés par les salariés de leur propre initiative. La seconde est de maîtriser les flux. Des données réglementées qui sortent du périmètre approuvé par un compte non autorisé ou un partage mal dirigé constituent un événement de conformité, et peuvent aussi relever d'une violation de données, même sans intention malveillante.

Les référentiels fournissent le vocabulaire dans lequel la conformité est démontrée aux clients, aux auditeurs et aux régulateurs. Les plus demandés sont listés ci-dessous.

Un fournisseur cloud ne réduit pas le périmètre de PCI DSS : l'environnement des données de titulaires doit être évalué partout où il s'exécute.

L'audit dans le cloud se fait en couches. Côté fournisseur, il repose sur ses attestations, comme le rapport SOC 2 et le certificat ISO 27001. Côté client, il repose sur les preuves que l'organisation produit elle-même : référentiels de configuration, revues d'accès, journaux d'activité et dossiers d'incidents.

La surveillance continue de la conformité remplace la photographie annuelle. Les environnements cloud changeant chaque jour, les auditeurs attendent des preuves générées automatiquement : alertes sur les dérives de configuration, pistes d'audit complètes sur qui a fait quoi dans quel service, et rapports à la demande. Côté client, la démarche suit en général quatre étapes :

1. 1

   Référentiel

   Consignez la configuration approuvée de chaque service cloud et comparez chaque changement à celle-ci.

2. 2

   Revue des accès

   Vérifiez qui peut atteindre chaque service et supprimez les comptes qui n'ont plus de responsable.

3. 3

   Conserver la piste

   Gardez la trace de qui a fait quoi dans chaque service, avec l'heure et l'objet, aussi longtemps que la politique l'exige.

4. 4

   Rapport à la demande

   Produisez les preuves pour l'auditeur à partir des enregistrements conservés, et non de mémoire.

Dans Anexet, ce contrôle s'exerce sur le poste de travail : les réglages du contrôle du stockage cloud dans le profil de l'agent définissent pour chaque service le niveau d'accès, le mode d'audit et la copie fantôme.

En pratique, un programme rassemble quelques éléments : un inventaire des services cloud réellement utilisés, y compris non autorisés ; la classification des données qui les atteignent ; une mise en correspondance des contrôles avec chaque référentiel applicable, pour qu'un contrôle satisfasse plusieurs exigences ; l'application sur les canaux par lesquels les données entrent et sortent des services ; et la collecte de preuves qui rend l'ensemble démontrable à la demande.

Aucun de ces éléments n'est propre à un seul texte. Les obligations se multiplient, avec une nouvelle loi sur la vie privée, un nouveau contrat ou une nouvelle version d'un référentiel, alors que les contrôles sous-jacents changent rarement. Les organisations qui maintiennent l'inventaire, la classification, l'application et la piste d'audit absorbent chaque nouvelle exigence en la projetant sur des contrôles existants. La partie protection de ce travail est traitée dans Sécurité des Données dans le Cloud.

Pour aller plus loin : Utiliser le système DLP Anexet Ultimate pour la conformité au RGPD.