Les fondamentaux du cloud computing
Gouvernance et conformité
Comment la gouvernance cloud fixe les règles propres d'une organisation pour l'usage de ses ressources, comment la conformité prouve que ces règles satisfont un cadre ou une réglementation externe, et où s'arrêtent les certifications d'un fournisseur là où doivent commencer les preuves propres du client.
- Distinguer la gouvernance de la conformité et expliquer à quelle question chacune répond
- Comparer ISO 27001, SOC 2, PCI DSS, HIPAA et le RGPD selon ce que chacun couvre et qui en a généralement besoin
- Expliquer ce que prouve un rapport de conformité d'un fournisseur et ce qu'il laisse au client à démontrer
- Distinguer la résidence des données de la souveraineté des données et identifier laquelle un scénario teste réellement
Un badge qui ne couvrait pas ce qu'ils croyaient
Une startup de santé s'inscrit chez un grand fournisseur cloud, voit les badges SOC 2 et ISO 27001 sur la page de conformité du fournisseur, et annonce à son conseil d'administration que la plateforme est conforme HIPAA. Des mois plus tard, un véritable audit HIPAA réclame les journaux d'accès de la startup elle-même, sa configuration de chiffrement, et les preuves de formation de son personnel à la sécurité, rien de tout cela n'ayant jamais été couvert par les certifications du fournisseur.
C'est exactement l'écart que la première leçon de ce sujet nommait comme une idée reçue, qui se rejoue ici en entier : la certification d'un fournisseur prouve que sa propre infrastructure respecte une norme. Que l'application construite par-dessus respecte cette même norme est une question distincte, et c'est précisément à cela que répondent la gouvernance et la conformité en tant que discipline.
La gouvernance regarde vers l'intérieur, la conformité vers l'extérieur
La gouvernance est le règlement propre à une organisation pour configurer et utiliser ses ressources cloud : qui approuve les demandes d'accès, comment les ressources sont étiquetées, quel niveau de configuration minimal chaque nouveau service doit atteindre avant sa mise en production. Elle vient de l'intérieur, et une entreprise peut avoir une gouvernance solide sans qu'aucun cadre externe n'entre en jeu.
La conformité est différente : elle consiste à prouver, à un auditeur, à un régulateur, ou au service achats d'un client, que les pratiques d'une organisation satisfont une exigence externe précise. Cette exigence peut être une norme certifiable qu'une entreprise choisit de viser, ou une loi qu'elle n'a pas le choix de respecter. Une bonne gouvernance facilite la démonstration de conformité, mais les deux répondent à des questions différentes : la gouvernance demande « faisons-nous cela de façon cohérente », la conformité demande « pouvons-nous le prouver à quelqu'un en dehors de l'organisation ».
Le paysage de la conformité : ce que chaque cadre couvre réellement
| Cadre | Ce qu'il couvre | Qui en a généralement besoin | Certification ou loi |
|---|---|---|---|
| ISO 27001 | Un système complet de management de la sécurité de l'information : évaluation des risques, contrôle d'accès, gestion des incidents | Toute organisation, reconnu à l'international | Certification, valable 3 ans |
| SOC 2 | Cinq critères de confiance : sécurité, disponibilité, intégrité du traitement, confidentialité, respect de la vie privée | Marché américain surtout, éditeurs SaaS et fournisseurs tech | Rapport d'attestation, avis d'un auditeur |
| PCI DSS | La protection des données de cartes de paiement, 12 exigences allant de la sécurité réseau à la restriction d'accès | Toute organisation qui stocke, traite ou transmet des données de cartes | Norme certifiable |
| HIPAA | La protection des informations de santé des patients | Organisations de santé américaines et leurs prestataires | Loi fédérale américaine |
| RGPD | Les données personnelles des résidents européens, y compris les règles de transfert international | Toute organisation traitant des données de résidents européens, où qu'elle soit basée | Règlement européen |
ISO 27001 et SOC 2 se recoupent largement dans les contrôles qu'ils vérifient, assez pour qu'un programme de conformité bien tenu satisfasse souvent les deux sans dédoubler le travail, mais ils s'adressent à des publics différents : SOC 2 est ce qu'un client américain demande en général, ISO 27001 ce qu'un client international attend habituellement.
Où trouver la part du fournisseur : AWS Artifact
Un fournisseur cloud n'envoie pas ses rapports de conformité par e-mail sur demande ; il les publie via un portail en libre-service. La version d'AWS s'appelle AWS Artifact, et donne à tout compte un accès à la demande aux rapports SOC 1/2/3, ISO et PCI d'AWS lui-même, chacun généré avec un filigrane propre au demandeur. Ce portail est le point de départ du client quand un auditeur demande « montrez-moi les contrôles du fournisseur », et il est gratuit. Ce qu'il ne peut jamais fournir, c'est l'autre moitié de la preuve, la configuration, les journaux d'accès et les processus internes du client lui-même, parce qu'AWS Artifact ne documente que la part d'AWS dans la ligne de responsabilité partagée.
Résidence des données et souveraineté des données
Ces deux termes s'emploient souvent l'un pour l'autre, et la frontière que l'examen teste entre eux mérite d'être nommée explicitement. La résidence des données concerne l'emplacement physique : où, géographiquement, les données sont-elles stockées. La souveraineté des données concerne la juridiction légale : quelles lois s'appliquent à ces données, peu importe où elles se trouvent physiquement.
Le RGPD est un bon cas d'étude parce qu'il précise lequel des deux l'intéresse réellement. Le RGPD n'exige pas que les données personnelles européennes restent physiquement à l'intérieur de l'UE. Ce qu'il exige, dans ses règles sur les transferts internationaux, c'est que tout transfert de données personnelles hors de l'UE ou de l'EEE bénéficie d'une protection essentiellement équivalente à celle du RGPD lui-même, via des mécanismes comme une décision d'adéquation couvrant le pays de destination, ou des clauses contractuelles types entre l'expéditeur et le destinataire. Une entreprise peut choisir une région cloud européenne pour de bonnes raisons opérationnelles, une latence plus faible pour ses utilisateurs européens, un argument plus simple pour ses clients, mais ce choix règle une question de résidence, une question de localisation. Il ne règle pas, en soi, la question légale de transfert que pose réellement le RGPD si ces mêmes données sont ensuite copiées, sauvegardées ou traitées ailleurs qu'en Europe.
Exemple concret : choisir une région pour des données personnelles européennes
Imaginez une équipe qui construit un service stockant des données personnelles de résidents européens. Choisir une région basée dans l'UE garde ces données physiquement proches de leurs utilisateurs et donne une réponse simple à « où vivent nos données ». Mais l'équipe doit encore vérifier chaque endroit où ces données voyagent ensuite : un outil de support hébergé hors de l'UE, un pipeline analytique dans une région américaine, une sauvegarde répliquée sur un autre continent. Chacun de ces cas constitue un transfert au sens du chapitre 5 du RGPD, et chacun a besoin de sa propre base légale, une décision d'adéquation pour cette destination, ou des clauses contractuelles, quelle que soit la précaution prise en choisissant la région principale.
Idée reçue, à nouveau : hériter d'un badge
La première leçon de ce sujet nommait cette idée reçue dans le contexte général de la sécurité ; ici, c'est son erreur de conformité la plus fréquente : supposer que la certification d'un fournisseur se transmet automatiquement à tout ce qu'un client construit par-dessus. Ce n'est jamais le cas. AWS Artifact, ou son équivalent chez n'importe quel fournisseur, remet la preuve des contrôles du fournisseur lui-même. Le client doit encore rassembler ses propres preuves : revues d'accès, configuration de chiffrement de la leçon précédente, formation des employés, processus de réponse aux incidents, tout ce que HIPAA, PCI DSS ou le questionnaire de sécurité d'un client demande réellement à voir.
Repères d'examen : associer un scénario à un cadre
| L'énoncé mentionne... | Pointe vers |
|---|---|
| « Informations de santé des patients », « établissement de santé » | HIPAA |
| « Données de cartes bancaires », « environnement de données de cartes » | PCI DSS |
| « Données personnelles de résidents européens », « transfert international » | Le RGPD |
| « Où nos données sont physiquement stockées » | La résidence des données |
| « Quelles lois s'appliquent à nos données » | La souveraineté des données |
| « Besoin des rapports d'audit du fournisseur » | AWS Artifact, ou l'équivalent du fournisseur |
Où cela vous mène
La conformité ne s'hérite jamais entièrement d'un badge affiché par un fournisseur ; elle s'assemble à partir de l'infrastructure certifiée du fournisseur, plus les contrôles propres du client construits par-dessus, exactement la même frontière que le modèle de responsabilité partagée traçait au début de ce sujet, appliquée cette fois à le prouver devant un tiers. Cela referme Sécurité du cloud : vous savez désormais nommer qui possède quelle tâche de sécurité, comment l'identité et le chiffrement font respecter cette possession, et comment la gouvernance et la conformité prouvent que tout tient sous audit. Le prochain sujet de ce domaine laisse la sécurité de côté et pose une question différente : une fois un système sécurisé, comment reste-t-il en marche.