Sécurité, identités et conformité dans le cloud

La sécurité dans le cloud répartit le travail entre le fournisseur et le client. Attribue les tâches selon la couche que chaque partie exploite, sans oublier les paramètres choisis par le client.

Distinguer l’infrastructure des choix du client

AWS appelle la protection de l’infrastructure la sécurité du cloud. Elle couvre les installations, les serveurs physiques, le stockage, les équipements réseau et l’hyperviseur qui sépare les machines virtuelles sur un hôte. Les clients prennent en charge la sécurité dans le cloud : leurs données, leurs identités et leur configuration. Azure et Google Cloud appliquent la même répartition de base. L’approche du destin partagé de Google ajoute des paramètres par défaut sécurisés, des conseils et des outils pour aider les clients à sécuriser leur partie.

Les fournisseurs contrôlent l’accès physique, l’alimentation électrique, le refroidissement, la maintenance du matériel et le retrait sécurisé des disques. Des auditeurs indépendants examinent ces couches ; les clients utilisent leurs rapports pour évaluer les contrôles qu’ils n’appliquent pas eux-mêmes.

Attribuer les responsabilités du client

Quel que soit le modèle de service, le client reste responsable des éléments suivants :

• Données : classification, accès, décisions de protection et conservation.
• Comptes : création, maintenance et suppression des identités.
• Gestion des accès : rôles, authentification multifacteur et politiques de connexion.
• Appareils clients : protection des ordinateurs portables et des téléphones utilisés pour se connecter.

Les paramètres choisis par le client restent à sa charge. Un compartiment public, une règle qui expose une base de données à Internet ou un compte administrateur abandonné peuvent exposer une charge de travail même lorsque les contrôles d’infrastructure du fournisseur fonctionnent correctement.

Certains contrôles sont partagés parce que chaque partie les applique à ses propres couches. Le fournisseur applique les correctifs à l’infrastructure ; les clients les appliquent aux systèmes d’exploitation et aux applications qu’ils gèrent. Chaque partie configure ses propres systèmes et forme son propre personnel. Attribue les responsabilités des deux parties pour chaque contrôle partagé afin que rien ne soit oublié.

Appliquer la répartition au stockage des factures

Une entreprise stocke ses factures dans un compartiment cloud. Le fournisseur applique les correctifs au service de stockage, remplace les disques défaillants et retire les disques du service de façon sécurisée. L’entreprise rend le compartiment privé, accorde à son rôle de facturation l’accès en lecture nécessaire et impose l’authentification multifacteur aux utilisateurs concernés. Elle choisit aussi les paramètres de chiffrement, active les journaux d’accès nécessaires et fixe la durée de conservation des factures.

Si un employé rend le compartiment public, le client doit corriger la permission et examiner l’exposition. Le service de stockage peut renvoyer un contenu lisible en réponse à une requête que le client a autorisée ; la protection physique ne peut pas annuler cet accès.

L’infrastructure cloud et les outils spécialisés de sécurité peuvent fournir à une petite équipe des protections qu’elle ne pourrait pas créer seule. Les fonctionnalités facultatives doivent tout de même être confiées à une personne chargée de les configurer et d’examiner leurs résultats. Consulte les indications relatives aux responsabilités de chaque service lorsque tu attribues ces tâches.

Les services davantage managés transfèrent plus de travail d’exploitation au fournisseur. Les choix du client concernant les identités, les données et les paramètres restent nécessaires malgré ces changements.

Comparer les couches

Les responsabilités relatives aux applications et au réseau peuvent être partagées en PaaS. Les clients SaaS configurent les fonctionnalités de l’application même si le fournisseur exploite le service ; la gestion des appareils peut aussi être partagée. Vérifie le service et la fonctionnalité concernés pour connaître la limite exacte.

Examiner les services

Pour un serveur web sur Amazon EC2, Azure Virtual Machines ou Google Compute Engine, le client installe les mises à jour de sécurité du système d’exploitation invité et assure la maintenance du serveur web. Il restreint l’administration à distance à l’aide des groupes de sécurité AWS, des groupes de sécurité réseau Azure ou des règles de pare-feu Google Cloud, et choisit la protection des disques et les sauvegardes.

Avec Amazon RDS, Azure SQL Database ou Google Cloud SQL, le fournisseur assure la maintenance du système d’exploitation sous-jacent et du moteur managé. Le client choisit toujours les chemins réseau autorisés, les utilisateurs, les permissions, les paramètres de chiffrement, la durée de conservation des sauvegardes et les fenêtres de maintenance disponibles. La possibilité d’effectuer des sauvegardes automatiques ne détermine pas combien de temps l’entreprise doit conserver ses documents.

Pour AWS Lambda, Azure Functions ou Google Cloud Run functions, les environnements d’exécution gérés par le fournisseur retirent de la liste du client l’application des correctifs aux serveurs et à l’environnement d’exécution. Les clients mettent toujours à jour les dépendances incluses, valident les entrées, protègent les secrets et restreignent les permissions d’exécution et d’invocation. Les environnements d’exécution personnalisés ou les conteneurs entraînent des responsabilités de maintenance supplémentaires.

Dans Microsoft 365 ou Google Workspace, le fournisseur applique les correctifs à l’application bureautique. Les clients suppriment les comptes des employés partis, contrôlent le partage externe et définissent la conservation. Certaines organisations assurent aussi leurs propres sauvegardes SaaS.

Attribuer une tâche inconnue

Nomme la couche, identifie le modèle de service, puis consulte la répartition indiquée dans sa documentation. Un disque physique défaillant relève du fournisseur dans tous les modèles. La mise à jour du système d’exploitation invité d’une machine virtuelle relève du client ; celle du système d’exploitation sous une base de données managée relève du fournisseur. La permission d’un utilisateur de la base reste un choix du client. Lorsqu’une organisation utilise plusieurs modèles ensemble, tiens une liste des tâches par service.

L’accès au cloud commence par l’identification d’une personne ou d’une application. Les permissions de cette identité sont ensuite vérifiées. Distinguer ces décisions aide à comprendre pourquoi une connexion réussie peut tout de même aboutir à un message de refus d’accès.

Prouver l’identité, puis vérifier la permission

L’authentification établit qui ou quoi effectue une requête. L’autorisation détermine si cette identité peut effectuer l’action demandée. L’audit consigne ce qui s’est passé. Un mot de passe associé à l’authentification multifacteur peut authentifier un utilisateur ; un rôle peut tout de même refuser à cet utilisateur la permission de supprimer une base de données.

Dans Azure et Google Cloud, les attributions de rôles associent des personnes, des groupes ou des charges de travail à des permissions. Dans AWS, endosser un rôle IAM fournit des informations d’identification temporaires pour une session. Une charge de travail devrait utiliser ce mécanisme d’identité pris en charge plutôt que le mot de passe d’une personne copié dans un fichier de configuration.

Reconnaître les noms utilisés par les fournisseurs

AWS IAM fournit des utilisateurs, des groupes et des rôles. IAM Identity Center permet au personnel d’accéder à plusieurs comptes AWS. Microsoft Entra ID, anciennement Azure Active Directory, est l’annuaire cloud d’Azure ; il comprend des utilisateurs, des groupes, des principaux de service et des identités managées. Google Cloud utilise des comptes et des groupes dans Cloud Identity ou Google Workspace, ainsi que des comptes de service pour les charges de travail.

Une instance EC2 peut recevoir un rôle IAM, une ressource Azure une identité managée et une machine virtuelle Google Cloud un compte de service associé. La plateforme fournit des informations d’identification de courte durée pour les accès pris en charge, ce qui évite de stocker un mot de passe de longue durée.

L’utilisateur racine AWS dispose de tous les pouvoirs sur le compte. Azure et Google Cloud répartissent les accès privilégiés à l’aide de rôles comme Global Administrator dans Entra, Owner pour un abonnement et Owner pour un projet. Ces rôles ont des étendues différentes : le rôle d’administrateur d’annuaire n’est pas interchangeable avec celui d’administrateur de ressources.

Se connecter de manière centralisée

L’authentification unique (SSO) permet à une personne d’utiliser une seule connexion pour plusieurs applications. La fédération d’identités est la relation de confiance qui permet à un cloud ou à une application d’accepter des informations d’identité provenant d’un autre fournisseur d’identité, généralement par SAML 2.0 ou OpenID Connect.

Une entreprise utilise Entra ID pour 200 employés et fédère les accès à AWS et à Google Cloud. Lorsqu’une ingénieure quitte l’entreprise, la désactivation du compte central empêche les nouvelles connexions. L’entreprise doit aussi révoquer les sessions actives et supprimer les comptes locaux indépendants et les clés d’accès. Ces voies peuvent continuer à fonctionner sans nouvelle connexion centralisée.

Les partenaires peuvent utiliser des identités externes : accès invité Entra B2B, rôle intercomptes AWS ou rôles Google Cloud accordés à des principaux externes. Leur employeur gère leur identité d’origine ; ton organisation contrôle leur accès à tes ressources.

Les applications anciennes peuvent nécessiter la jonction au domaine, Kerberos, NTLM ou LDAP. Les offres d’annuaire managé comprennent Entra Domain Services, AWS Directory Service et Google Cloud Managed Service for Microsoft Active Directory. Elles répondent à des besoins applicatifs différents de ceux couverts par une simple connexion cloud moderne.

Une permission associe une action à une ressource. « Lire les objets de ce compartiment » est plus précis que « utiliser le stockage ». Les fournisseurs regroupent les permissions dans des rôles ou des instructions de politique, puis les associent à des identités ou à des ressources.

Associer qui, quoi et où

Le contrôle d’accès fondé sur les rôles (RBAC) attribue des permissions par l’intermédiaire de rôles professionnels. Une attribution de rôle Azure comprend trois éléments : le principal de sécurité, la définition du rôle et l’étendue. Les niveaux d’étendue vont du groupe d’administration à l’abonnement, au groupe de ressources et à la ressource individuelle. Les attributions se transmettent aux ressources situées dans leur étendue.

Priya dispose du rôle Reader sur l’abonnement Prod et du rôle Contributor sur son groupe de ressources web-rg. Elle peut consulter les ressources dans tout Prod et modifier celles de web-rg. Elle ne peut pas modifier db-rg ni donner accès à une autre personne avec Contributor. Les permissions Azure s’additionnent entre les attributions ; certaines fonctionnalités Azure peuvent créer des attributions de refus qui bloquent des actions autrement autorisées.

Les politiques d’autorisation Google Cloud associent des principaux à des rôles sur les ressources. Les accès sont hérités au fil de la hiérarchie : organisation, dossiers, projets et ressources. Les rôles de base très étendus Owner, Editor et Viewer devraient céder la place à des rôles prédéfinis propres aux services ou à des rôles personnalisés adaptés. Modifier la politique d’autorisation d’un enfant ne supprime pas l’accès accordé à son parent. Modifie l’accès accordé au parent ou applique, si nécessaire, une politique de refus prise en charge.

Évaluer une requête AWS

Une politique AWS IAM est un document JSON contenant des instructions avec un Effect, une Action, un ARN de Resource et des conditions facultatives. Les politiques peuvent être associées à des identités ; une politique de ressource, comme une politique de compartiment, est associée à la ressource. Les politiques managées par AWS sont maintenues par le fournisseur, les politiques managées par le client sont des documents réutilisables du client et les politiques en ligne appartiennent à une seule identité.

Pour prendre une décision élémentaire sur une requête :

1. Pars d’un refus implicite : aucune permission n’existe encore.
2. Trouve une autorisation explicite applicable et vérifie toutes les limites de permissions applicables.
3. Applique tout refus explicite : il l’emporte sur les autorisations.

Une politique de contrôle des services (SCP) d’AWS Organizations limite les permissions maximales disponibles. Elle n’accorde aucune permission par elle-même. Une requête hors des limites autorisées par la SCP échoue même si une politique d’identité l’autorise.

Le groupe de Lena peut lire sales-reports/* et aucun garde-fou ne restreint cette lecture. Un téléchargement est autorisé. Un chargement échoue, car aucune autorisation s3:PutObject n’existe. Une politique distincte refuse explicitement la suppression ; ajouter s3:* ensuite ne peut toujours pas autoriser la suppression. La lecture d’un compartiment sans rapport ne dispose pas non plus d’une autorisation.

Distinguer la gestion des ressources de l’accès aux données

Un administrateur peut gérer un compte de stockage par le plan de contrôle sans recevoir de rôle de données Entra lui permettant de lire ses objets blob par le plan de données. Pour cette lecture, un rôle comme Storage Blob Data Reader est nécessaire. Vérifie l’action et l’étendue au lieu de supposer qu’un titre associé à la gestion de ressources privilégiée répond à toutes les questions d’accès aux données.

Le principe du moindre privilège donne à une identité les actions, les ressources et la durée nécessaires à sa tâche. Il réduit le rayon d’impact : les dommages qu’une erreur ou des informations d’identification volées peuvent causer.

Accorder un accès ciblé

Énumère d’abord le travail à accomplir, choisis un rôle ou une politique limitée, définis l’étendue utile la plus restreinte et gère les personnes par des groupes ou des rôles. Limite dans le temps les accès privilégiés et examine-les régulièrement. Un prestataire qui charge des journaux dans un compartiment pendant 30 jours a besoin d’un accès en chargement à cet endroit, et non d’un accès en lecture à tout le stockage ou d’une identité d’administrateur permanente.

L’accès juste à temps limite le moment où une personne peut obtenir des permissions renforcées. Entra Privileged Identity Management peut exiger une approbation et une authentification multifacteur pour une activation limitée dans le temps. Google Privileged Access Manager fournit sur demande des attributions temporaires de rôles. Les rôles AWS fournissent des informations d’identification à durée limitée par Security Token Service, mais un droit permanent d’endosser un rôle administrateur permet d’ouvrir de nouvelles sessions à répétition. Des informations d’identification de courte durée ne suffisent pas à supprimer un privilège permanent.

La séparation des tâches confie à différentes personnes le contrôle des parties sensibles d’un processus. La personne qui demande une modification et celle qui l’approuve doivent être distinctes ; l’administration des clés et la lecture des données doivent aussi être séparées.

Protéger les identités privilégiées

Active l’authentification multifacteur sur l’utilisateur racine AWS, donne-lui un mot de passe fort et unique et ne crée aucune clé d’accès racine. Utilise-le uniquement pour les tâches qui l’exigent. Exemples : modifier son adresse e-mail ou son mot de passe, fermer un compte autonome, rétablir l’accès après le blocage d’un administrateur IAM, activer l’accès IAM à la facturation, s’inscrire comme vendeur sur EC2 Reserved Instance Marketplace et activer la suppression protégée par authentification multifacteur dans S3. Les organisations peuvent supprimer de manière centralisée les informations d’identification racine des comptes membres.

Limite strictement les rôles très privilégiés dans Entra et Google Cloud. Microsoft recommande moins de cinq Global Administrators. Les administrateurs ont besoin d’identités distinctes pour leurs activités courantes et privilégiées, ainsi que d’une authentification multifacteur résistante à l’hameçonnage. La planification des accès d’urgence Entra utilise deux comptes d’accès d’urgence conservés de façon sécurisée et surveillés, afin qu’un échec de connexion normale ne bloque pas tout le monde ; la conception de ces comptes suit les recommandations du fournisseur.

Privilégier les accès de courte durée et les secrets managés

Les clés d’accès de longue durée restent utilisables jusqu’à leur désactivation ou leur suppression. Privilégie les identités de charges de travail, les rôles et l’authentification unique. Effectue la rotation des clés indispensables et garde-les hors du code source. Si une clé est divulguée, supprime l’accès qu’elle permet ; supprimer un fragment de code visible ne révoque pas les informations d’identification.

Stocke les mots de passe de bases de données, les clés API et les certificats dans AWS Secrets Manager ou Systems Manager Parameter Store, Azure Key Vault ou Google Cloud Secret Manager. Les applications récupèrent les secrets nécessaires à l’exécution grâce aux identités de charges de travail. Configure la collecte des données d’audit lorsque c’est nécessaire, notamment dans les paramètres de diagnostic Azure Key Vault.

Pour les mots de passe qui restent nécessaires, les recommandations du NIST de 2025 exigent au moins 15 caractères pour une utilisation à facteur unique, ou au moins 8 dans le cadre d’une authentification multifacteur, ainsi que la prise en charge d’au moins 64 caractères. Elles prévoient une vérification par rapport aux mots de passe courants ou compromis, excluent les combinaisons de caractères imposées et les changements périodiques systématiques, et exigent un changement en cas de compromission suspectée.

Appuie-toi sur des éléments concrets pour réduire les accès : AWS IAM Access Analyzer, rapports d’informations d’identification et données de dernier accès ; vérifications d’accès Entra ; recommandations de rôles IAM Google. Si un rôle autorise 40 services mais que seuls 3 ont été utilisés en 90 jours, examine les permissions des 37 autres services. Vérifie les tâches légitimes à venir avant de les supprimer : l’inactivité désigne des permissions à examiner, mais ne décrit pas tous les besoins de l’entreprise.

L’authentification multifacteur exige au moins deux catégories de facteurs différentes : quelque chose qu’une personne connaît, possède ou est. Un mot de passe et une réponse à une question de sécurité sont tous deux des facteurs de connaissance et restent une authentification à facteur unique.

Comparer les méthodes d’authentification

Le NIST restreint la transmission par le réseau téléphonique. Une configuration TOTP courante utilise six chiffres qui changent toutes les 30 secondes : un million de valeurs possibles donnent à une tentative unique au hasard une chance sur un million de réussir. Les implémentations peuvent utiliser d’autres longueurs ou intervalles.

Une page d’hameçonnage peut transmettre un mot de passe et un code récent au vrai site avant son expiration. La preuve d’une passkey liée au domaine ne peut pas être réutilisée par le faux domaine pour le service authentique. Windows Hello for Business et les méthodes par certificat prises en charge offrent aussi des options résistantes à l’hameçonnage.

Une attaque par fatigue de l’authentification multifacteur envoie des demandes d’approbation répétées dans l’espoir que quelqu’un accepte. La correspondance de nombres relie l’approbation à un écran de connexion, ce qui réduit les acceptations accidentelles ; elle ne fournit pas la même liaison au domaine qu’une méthode résistante à l’hameçonnage.

Vérifier les facteurs d’une connexion sans mot de passe

La connexion sans mot de passe supprime le mot de passe. Une information d’identification détenue sur un appareil et déverrouillée par un code PIN ou une donnée biométrique vérifiés associe la possession à un second facteur. Le code PIN est vérifié localement et n’est pas envoyé au service. Vérifie les facteurs que la méthode utilisée contrôle avant de la classer comme authentification multifacteur. Google appelle son service d’authentification multifacteur 2-Step Verification.

Les fournisseurs imposent l’authentification multifacteur pour certains accès administratifs, notamment ceux de l’utilisateur racine AWS et la connexion au portail Azure. Les clients définissent toujours les exigences pour leurs propres utilisateurs et applications, avec les méthodes les plus robustes pour les accès privilégiés.

Appliquer le contexte et protéger la récupération

Entra Conditional Access évalue l’utilisateur, l’application, l’état de l’appareil, le lieu et le risque lié à la connexion. Il peut autoriser, exiger une authentification renforcée ou un appareil conforme, ou bloquer. Pour la paie, exige un appareil managé et une authentification résistante à l’hameçonnage ; bloque les connexions à haut risque. Les conditions AWS IAM et l’accès contextuel Google fournissent des contrôles apparentés dont le comportement varie selon le service.

Protège la récupération des comptes avec autant de soin : une voie de récupération faible peut remplacer un authentificateur robuste. Refuse les demandes d’approbation inattendues et signale-les selon la procédure de l’organisation. Le principe du moindre privilège et la surveillance limitent toujours le risque si une session authentifiée est volée.

Le chiffrement transforme un texte en clair lisible en texte chiffré à l’aide d’une clé. La bonne clé permet le déchiffrement. Il protège la confidentialité ; le chiffrement authentifié détecte aussi les modifications frauduleuses. Il n’empêche pas une suppression autorisée et ne maintient pas en fonctionnement une application défaillante.

Distinguer trois transformations

Un texte Base64 comme « aGVsbG8= » peut être décodé en « hello » par n’importe qui. Il n’offre aucune confidentialité. Le stockage des mots de passe nécessite une fonction de hachage de mots de passe avec sel, volontairement lente, comme Argon2, bcrypt, scrypt ou PBKDF2. Un seul hachage SHA-256 rapide ne convient pas à cette tâche.

Le chiffrement symétrique utilise la même clé pour chiffrer et déchiffrer. AES-256 est courant pour les grandes quantités de données cloud. La cryptographie asymétrique utilise une paire de clés publique et privée pour des opérations comme l’échange de clés et les signatures numériques ; les opérations prises en charge dépendent de l’algorithme. Le chiffrement à clé publique permet à un expéditeur de protéger des données pour un destinataire qui les déchiffre avec sa clé privée. Une signature numérique permet à d’autres de vérifier une signature créée avec la clé privée.

Une clé symétrique de 256 bits possède $2^{256}\approx \mathrm{1,16}\times {10}^{77}$ valeurs possibles. Même à raison de ${10}^{18}$ essais par seconde, les vérifier toutes prend environ $\mathrm{3,7}\times {10}^{51}$ années. En pratique, protéger l’accès aux clés est bien plus important que prévoir de parcourir cet espace de recherche.

Appliquer le chiffrement aux données stockées

Les données au repos comprennent les objets, les disques, les bases de données, les sauvegardes et les instantanés. Le chiffrement protège le contenu stocké brut si quelqu’un obtient un disque ou copie le stockage sans la clé nécessaire. Le chiffrement côté serveur a lieu dans le service avant l’écriture des données. Le chiffrement côté client a lieu avant le chargement : le fournisseur ne reçoit que du texte chiffré. La perte d’une clé client irremplaçable rend le contenu illisible.

Les paramètres par défaut varient selon le service. Amazon S3 chiffre par défaut tous les nouveaux objets chargés depuis le 5 janvier 2023. Azure Storage chiffre les données stockées et ce chiffrement ne peut pas être désactivé. Google Cloud chiffre par défaut les données clients au repos. Le chiffrement par défaut d’Amazon EBS est un paramètre du compte que le client active dans chaque région.

Suivre une lecture autorisée

Un objet contenant une facture est chiffré sur disque. Un utilisateur le demande par le service de stockage. Le service vérifie les permissions, déchiffre l’objet à l’aide du mécanisme de clé configuré et renvoie un contenu lisible à l’utilisateur autorisé. Si le client autorise la lecture publique, ce processus peut aussi servir des personnes extérieures.

Le chiffrement au repos fonctionne donc avec des paramètres d’accès privé et la journalisation des activités. Commence par la classification des données : publiques, internes, confidentielles ou à accès restreint. La classification guide les choix concernant les personnes autorisées à lire le contenu, les exigences de contrôle des clés et la conservation. Les sauvegardes demandent la même attention, car une base de données protégée peut tout de même avoir une copie exposée.

Un enregistrement peut être chiffré pendant son stockage et rester exposé lors de son passage sur un réseau ou de son traitement. Suis son parcours pour déterminer où chaque protection est nécessaire.

Chiffrer les données en transit avec TLS

Les données en transit circulent entre des navigateurs, des applications, des bases de données, des bureaux ou des régions. TLS protège une connexion contre la lecture et la modification des données et authentifie le serveur à l’aide d’un certificat. HTTPS est le protocole HTTP transporté sur TLS, généralement sur le port 443. Utilise des configurations TLS 1.2 ou 1.3 prises en charge ; SSL ainsi que TLS 1.0 et 1.1 sont obsolètes.

Un certificat numérique associe un domaine à une clé publique. Une autorité de certification reconnue le signe afin que le navigateur puisse vérifier l’association. Les services de certificats comprennent AWS Certificate Manager, les fonctionnalités de certificats d’Azure Key Vault ou d’App Service et Google Cloud Certificate Manager. Le renouvellement managé réduit le risque d’expiration lorsqu’il est pris en charge et configuré. Un certificat expiré peut empêcher les connexions et interrompre un service.

Une connexion HTTPS valide confirme la protection de la connexion à ce domaine. Un site d’hameçonnage peut aussi détenir un certificat valide pour son propre domaine : le cadenas seul n’indique donc pas si cette entreprise ou cette page mérite ta confiance.

Suivre une requête du navigateur

1. Le navigateur établit une connexion HTTPS avec un répartiteur de charge et vérifie son certificat.
2. Le répartiteur de charge termine cette connexion TLS et voit la requête en clair.
3. Une connexion TLS distincte protège l’étape suivante jusqu’à un serveur d’application.
4. L’application utilise une connexion chiffrée à la base de données, configurée pour l’exiger.

Le HTTPS en entrée ne protège que sa propre connexion. Vérifie chaque étape suivante. Une politique S3 peut refuser les requêtes lorsque aws:SecureTransport est faux ; Azure Storage propose d’exiger un transfert sécurisé ; Cloud SQL peut exiger TLS. Les réseaux internes ont aussi besoin d’une protection du trafic, car un attaquant peut déjà y avoir pénétré.

Distinguer chemin privé et chiffrement

Un VPN IPsec site à site chiffre le trafic sur Internet entre un réseau de bureau et un réseau cloud. Les services comprennent AWS Site-to-Site VPN, Azure VPN Gateway et Google Cloud VPN.

Les liaisons dédiées, AWS Direct Connect, Azure ExpressRoute et Google Cloud Interconnect, évitent l’Internet public, mais leur chemin privé ne fournit pas à lui seul de chiffrement de bout en bout par défaut. Utilise une protection TLS, IPsec ou MACsec adaptée et prise en charge là où elle est nécessaire. MACsec protège le segment de liaison pris en charge ; vérifie aussi la protection de l’ensemble du trajet de l’application.

Protéger les données pendant le traitement

Les données en cours d’utilisation sont en cours de traitement, souvent dans une mémoire déchiffrée. L’informatique confidentielle ajoute un isolement assuré par le matériel, avec un chiffrement de la mémoire dans les technologies qui le prennent en charge. Les machines virtuelles confidentielles Azure et Google Confidential VMs chiffrent la mémoire à l’aide de clés conservées dans le processeur. AWS Nitro Enclaves isole la mémoire et les processeurs de l’instance parente et de ses administrateurs.

Pour un dossier patient, le chiffrement de la base de données protège le stockage, TLS protège sa transmission à un médecin et une machine virtuelle confidentielle peut protéger une tâche d’analyse sensible pendant son exécution. Ces contrôles couvrent des expositions différentes. L’application doit toujours avoir la permission de traiter le dossier et reste responsable de ce qu’elle produit.

La maîtrise des clés influe à la fois sur le contrôle de la sécurité et sur le risque d’exploitation. Un client qui obtient le pouvoir de désactiver une clé obtient aussi la possibilité d’interrompre tous les services qui en dépendent.

Comparer les choix de contrôle

Les services cloud de gestion des clés comprennent AWS KMS, Azure Key Vault et Google Cloud KMS. Ils contrôlent les opérations cryptographiques et peuvent journaliser l’utilisation des clés. Active les journaux nécessaires, notamment les paramètres de diagnostic Azure et la journalisation d’audit Data Access de Google Cloud KMS.

Parmi les exemples de clés fournies par le client figurent les processus Amazon S3 SSE-C et Google CSEK pris en charge. Les options externes comprennent les magasins de clés externes AWS KMS et Google Cloud External Key Manager. Ces fonctionnalités dépendent du service ; le service de données choisi doit prendre en charge l’option.

Un module matériel de sécurité (HSM) protège les clés dans du matériel spécialisé. AWS CloudHSM, Azure Managed HSM et Google Cloud HSM fournissent une protection matérielle. Un HSM décrit comment les clés sont protégées ; le contrôle par le fournisseur, le client ou une entité externe décrit qui régit leur utilisation. Ce sont des choix différents.

Comprendre le chiffrement par enveloppe

Le stockage cloud chiffre souvent les contenus volumineux avec une clé de données. Il chiffre ensuite cette clé plus petite avec une clé de chiffrement de clé conservée dans un service de gestion des clés. La clé de données chiffrée peut être stockée à côté du texte chiffré. C’est le chiffrement par enveloppe : les données volumineuses n’ont pas besoin d’être envoyées à KMS pour chaque opération cryptographique.

Pour lire le contenu, le service doit avoir la permission de déchiffrer la clé de données. Désactiver la clé qui la protège bloque cette opération. La destruction définitive de la clé peut rendre illisibles toutes les données qui en dépendent, y compris les anciennes sauvegardes.

Examiner le choix d’un hôpital

Un hôpital choisit une clé KMS AWS gérée par le client pour ses images médicales. Le rôle de son application peut déchiffrer ; l’équipe de sécurité administre la clé sans disposer d’une permission habituelle de lire les images. Cela sépare l’utilisation des données de l’administration des clés. Les éléments d’audit doivent montrer les permissions prévues et l’utilisation de la clé.

La rotation de la clé a lieu chaque année. La rotation fournit de nouveaux éléments pour les chiffrements futurs tout en conservant les anciennes versions nécessaires à la lecture du contenu existant. Cela ne signifie pas que toutes les anciennes images sont immédiatement rechiffrées.

À la fin du service, l’hôpital vérifie toutes les dépendances restantes des données et des sauvegardes avant de programmer la suppression de la clé. AWS KMS applique un délai d’attente de 7 à 30 jours. Après suppression, les textes chiffrés qui en dépendent ne peuvent plus être récupérés à l’aide de cette clé. Détruire l’accès en détruisant la clé s’appelle l’effacement cryptographique.

Adapter le contrôle à une exigence

Choisis des clés gérées par le client ou externes lorsqu’un contrat, une réglementation, une exigence de révocation ou d’audit, ou la séparation des tâches exige ce contrôle. Le même algorithme de chiffrement peut protéger les données dans chacun de ces modèles de gestion. Un contrôle supplémentaire des clés modifie la responsabilité, la planification de la disponibilité et les preuves à fournir ; il ne rend pas AES mathématiquement plus robuste.

La défense en profondeur combine des contrôles indépendants. Si l’un échoue, un autre peut bloquer l’action suivante, limiter ses dommages ou révéler l’attaque.

Répartir les contrôles en couches

La représentation de Microsoft en sept couches va de la sécurité physique aux données placées au centre, en passant par les identités et les accès, le périmètre, le réseau, le calcul et l’application.

La répartition des responsabilités suit le modèle de responsabilité partagée. Les fournisseurs appliquent les contrôles physiques ; les clients contrôlent les identités et les données. La personne chargée de la maintenance du calcul dépend de la solution utilisée : machine virtuelle du client ou plateforme managée.

Suivre une prise de contrôle de compte

Un attaquant obtient le mot de passe d’un développeur de boutique en ligne. L’authentification multifacteur peut bloquer une nouvelle connexion. Supposons que l’attaquant vole plutôt une session déjà authentifiée. Les contrôles suivants doivent limiter ce que cette session peut faire.

Le rôle du développeur autorise la lecture des journaux mais aucune requête sur la base de données ; l’autorisation refuse donc une demande directe de données clients. Les règles réseau limitent séparément les connexions à la base au chemin autorisé de l’application. La surveillance peut signaler une activité inhabituelle. Des sauvegardes protégées permettent une restauration si un attaquant obtient ensuite un accès permettant la destruction.

Le chiffrement des disques protège le stockage brut en l’absence de la clé. Il ne bloquerait pas un contenu lisible renvoyé à une identité compromise disposant de permissions légitimes de lecture et de déchiffrement. Évalue le chemin réel avant de considérer qu’un contrôle bloque cet accès.

Combiner blocage et détection

Un contrôle préventif bloque une requête, comme la création d’un stockage public. Un contrôle de détection signale un événement ou une situation, comme une activité inhabituelle ou un accès excessif. Prévois une réponse qui examine, contient et corrige les problèmes détectés.

Deux pare-feu ayant la même règle erronée peuvent échouer ensemble. Une vérification d’identité distincte, une validation par l’application et un rôle de données limité agissent sur différentes étapes de l’attaque. Suis une requête de l’utilisateur jusqu’aux données, repère les contrôles sur ce trajet et désigne les responsables de leurs paramètres et de leurs alertes.

Le modèle Zero Trust n’accorde aucune autorisation automatique en fonction de l’emplacement réseau. Une adresse interne ne donne pas la permission d’utiliser une application ou de lire ses données.

Appliquer trois principes

Vérifier explicitement : évaluer l’identité et le contexte, notamment l’état de l’appareil, le lieu, le service demandé, la sensibilité des données et les comportements inhabituels.

Appliquer le principe du moindre privilège : accorder uniquement l’accès nécessaire à la tâche, avec une élévation limitée dans le temps si nécessaire. Un utilisateur authentifié doit toujours avoir la permission d’effectuer l’action.

Présumer une violation : restreindre les déplacements, chiffrer le trafic et surveiller l’activité afin qu’une identité ou un appareil compromis ne puisse pas accéder librement à tout.

NIST SP 800-207 décrit cette approche architecturale. Microsoft l’exprime à travers ces trois principes. Les organisations mettent la stratégie en œuvre à l’aide de contrôles coordonnés et peuvent l’adopter progressivement.

Modifier la frontière d’accès

Un modèle de périmètre traditionnel tend à faire confiance aux appareils une fois entrés dans le réseau. Une connexion VPN étendue peut alors permettre à un ordinateur portable infecté d’atteindre de nombreux systèmes. Avec le travail à distance, le SaaS et le multicloud, le lieu seul constitue une mauvaise frontière d’accès.

Un proxy fondé sur l’identité évalue l’accès à une application précise. Google Identity-Aware Proxy, AWS Verified Access et Microsoft Entra Private Access fournissent des fonctionnalités apparentées. L’approche BeyondCorp de Google est un exemple de remplacement de la confiance automatique accordée au réseau interne par une évaluation des accès.

La segmentation et les pare-feu continuent de limiter les accès lorsqu’un autre contrôle échoue. Chiffre aussi les connexions internes : un attaquant peut déjà se trouver dans l’environnement.

Évaluer la requête d’une infirmière

Une infirmière demande l’accès à l’application de planning du personnel depuis son domicile. Un service d’accès vérifie son identité par une authentification résistante à l’hameçonnage, contrôle que l’ordinateur portable est managé et à jour, puis confirme qu’elle possède le rôle lié au planning. Il lui accorde une session pour cette application.

Une demande d’accès à la paie nécessite sa propre décision d’autorisation. La session de planning ne donne aucun accès à la paie. Si la surveillance signale ensuite que l’ordinateur est infecté, une politique peut bloquer ou révoquer l’accès concerné. L’authentification du matin ne détermine pas l’état de l’appareil l’après-midi.

Les services d’identité établissent qui fait la demande ; les contrôles des appareils et l’accès conditionnel évaluent le contexte. Les rôles limitent les actions, les proxys et les segments limitent les accès possibles, et TLS protège les connexions. La surveillance fournit de nouveaux éléments pour les décisions ultérieures. L’achat d’un seul produit laisse à l’organisation le soin de définir ces règles d’accès et ces décisions de réponse.

Commence par la fonction que le contrôle doit remplir. Les grands fournisseurs proposent des catégories de sécurité qui se recoupent, et un même produit peut fournir plusieurs types de résultats. Une faiblesse logicielle détectée appelle une réponse différente de celle apportée à un flot de trafic.

Bloquer les flots de trafic et les attaques web

La protection contre les attaques DDoS traite le trafic destiné à submerger un service. AWS Shield Standard fournit une protection de base automatique ; Shield Advanced ajoute des fonctionnalités payantes et une assistance pour les interventions. Azure fournit une protection par défaut de son infrastructure, complétée par les offres payantes Azure DDoS Protection. Google Cloud Armor protège les applications prises en charge placées derrière un répartiteur de charge.

Un pare-feu applicatif web (WAF) inspecte les requêtes web à la recherche d’attaques comme l’injection SQL, l’exécution de scripts intersites et les robots abusifs. AWS WAF, Azure Web Application Firewall et les politiques de sécurité Cloud Armor appartiennent à cette catégorie. Ils peuvent filtrer les requêtes applicatives ou limiter leur débit. Un pare-feu réseau contrôle le trafic à un autre niveau : AWS Network Firewall, Azure Firewall et Google Cloud Next Generation Firewall en sont des exemples. AWS Firewall Manager aide à appliquer les protections prises en charge à plusieurs comptes.

Détecter les menaces et les faiblesses connues

La détection des menaces examine l’activité à la recherche de signes de compromission. Une machine virtuelle qui contacte un service de minage connu présente un comportement suspect. GuardDuty analyse notamment des informations sur les API, les flux réseau et le DNS. Une plateforme de gestion des informations et des événements de sécurité (SIEM), comme Microsoft Sentinel ou Google Security Operations, rassemble des événements de sécurité provenant de nombreuses sources pour les analyser et enquêter.

La gestion des vulnérabilités repère les faiblesses connues dans les logiciels installés ou les images. Inspector évalue les charges de travail EC2, les conteneurs et les fonctions Lambda pris en charge. Un paquet vulnérable peut exister avant toute activité d’attaquant observée ; sa découverte doit conduire à une mise à jour ou à une autre mesure d’atténuation adaptée.

La gestion de la posture de sécurité cloud (CSPM) vérifie la configuration par rapport aux pratiques et aux normes. Une ressource de stockage accessible au public présente un problème de posture même si aucun accès malveillant n’a été détecté. AWS Security Hub rassemble les résultats ; Security Hub CSPM fournit les contrôles de configuration. Defender for Cloud et Security Command Center proposent aussi une évaluation de la posture.

Trouver les données sensibles et traiter les résultats

Macie peut localiser le contenu sensible dans S3. Purview découvre, classifie et étiquette les données de l’organisation. Google Sensitive Data Protection peut découvrir, classifier et désidentifier le contenu sensible. La découverte de numéros de passeport dans une exportation oubliée indique à l’équipe où renforcer les contrôles d’accès ou de conservation ; la découverte seule ne modifie pas toutes les permissions.

Pour un service en ligne, associe le symptôme à la catégorie. Utilise une protection DDoS contre un flot de trafic, un WAF contre les entrées web malveillantes, une évaluation des vulnérabilités pour une bibliothèque obsolète, la détection des menaces pour une activité suspecte à l’exécution et la CSPM pour des paramètres de ressources risqués. Plusieurs de ces solutions peuvent être nécessaires en même temps.

AWS Trusted Advisor, Azure Advisor et Google Recommender fournissent des recommandations supplémentaires ; les vérifications disponibles et les offres payantes diffèrent. Les places de marché des fournisseurs proposent des produits tiers. La documentation officielle de sécurité, les centres d’intervention, les blogs et les bulletins aident les équipes à suivre les évolutions. Désigne des responsables pour traiter les résultats et active les offres de service pertinentes : un tableau de bord rempli d’alertes non examinées laisse subsister l’exposition sous-jacente.

Les journaux répondent aux questions sur les événements ; la surveillance transforme les observations en actions. Pour disposer de bonnes preuves, il faut collecter les bons événements suffisamment tôt, les conserver assez longtemps et les protéger contre les modifications.

Choisir les éléments adaptés à la question

Les journaux d’audit ou d’activité montrent qui a effectué des actions par la console ou l’API. L’historique de configuration montre comment les paramètres d’une ressource ont changé. Les métriques mesurent l’état et les performances. Les journaux d’accès aux données enregistrent les accès pertinents au contenu et les journaux de flux réseau décrivent les flux de trafic.

L’historique des événements CloudTrail conserve les 90 derniers jours d’événements de gestion par région. Crée un journal de suivi pour envoyer les enregistrements vers S3 afin de les conserver plus longtemps, et éventuellement aussi vers CloudWatch Logs. Les métriques de performance CloudWatch sont des éléments différents de l’enregistrement CloudTrail indiquant qui a modifié une politique.

Le journal d’activité Azure conserve aussi 90 jours par défaut. Les paramètres de diagnostic peuvent envoyer les enregistrements vers un stockage, Log Analytics ou Event Hubs. Les journaux Admin Activity de Google sont toujours activés et ne peuvent pas être désactivés. Les journaux Data Access doivent être activés pour la plupart des services ; BigQuery présente d’importantes différences dans ses paramètres par défaut. Les journaux d’accès Key Vault et l’activité relative aux données Google KMS nécessitent aussi les paramètres de collecte appropriés.

Conserver les preuves avant qu’une enquête en ait besoin

Un compartiment devient public le 2 mars 2026. L’enquête commence le 1er juillet, 121 jours plus tard. L’événement se situe au-delà de la période par défaut de 90 jours. Une exportation configurée auparavant peut conserver l’identité de la personne qui a modifié le paramètre, le moment et l’adresse IP utilisée ; activer une exportation maintenant ne peut pas recréer un enregistrement expiré.

L’historique de configuration peut montrer le paramètre avant et après l’événement. Utilise les deux enregistrements pour comprendre la modification, annuler l’exposition et examiner les accès aux données à l’aide des journaux appropriés qui ont été activés. Un événement de gestion ne constitue pas à lui seul une liste complète des fichiers lus.

Empêcher les modifications et détecter les exceptions

Les garde-fous préventifs bloquent une action interdite : Azure Policy avec l’effet Deny, les restrictions SCP prises en charge et les contraintes d’organisation Google en sont des exemples. Les garde-fous de détection repèrent une situation après son apparition : règles AWS Config, Azure Policy en mode Audit et résultats relatifs à la posture.

Une politique de localisation peut bloquer les nouvelles ressources dans les régions interdites. Un contrôle de configuration peut signaler les ressources qui enfreignent une règle. Ce dernier nécessite une réponse et n’annule pas une modification simplement en produisant un résultat.

Limite l’accès aux journaux, collecte les preuves dans un compte ou un projet distinct et utilise des contrôles d’intégrité ou d’immuabilité si nécessaire. La validation des fichiers journaux CloudTrail peut révéler les modifications apportées aux fichiers transmis. Définis la durée de conservation selon l’exigence applicable ; PCI DSS exige au moins 12 mois d’historique d’audit, les 3 derniers mois étant facilement accessibles. Configure des alertes pour les événements comme les connexions racine ou les modifications de rôles privilégiés et désigne une personne chargée d’y répondre.

La conformité consiste à respecter les exigences applicables et à en apporter la preuve. Les contrôles audités d’un fournisseur de services cloud peuvent t’aider à remplir tes obligations, mais ton organisation doit aussi appliquer et documenter les contrôles qui lui incombent.

Identifier le type d’exigence

ISO/IEC 27001 porte sur un système de management de la sécurité de l’information, ou SMSI. Des organismes de certification accrédités délivrent les certificats, normalement pour un cycle de trois ans avec des audits de surveillance. ISO/IEC 27017 ajoute des contrôles de sécurité cloud. ISO/IEC 27018 traite de la protection des données personnelles pour les sous-traitants de cloud public ; son édition actuelle date de 2025.

Choisir le rapport SOC adapté à la question

SOC 1 concerne les contrôles pertinents pour l’information financière des clients. SOC 2 porte sur les critères des services de confiance applicables : sécurité, disponibilité, intégrité du traitement, confidentialité et protection de la vie privée. Il s’agit d’un rapport détaillé généralement communiqué sous condition de confidentialité. SOC 3 est un rapport d’usage général adapté à une diffusion publique.

Un rapport de type 1 évalue la conception des contrôles à un instant donné. Un rapport de type 2 teste aussi l’efficacité de leur fonctionnement sur une période définie. Pour obtenir la preuve que les contrôles pertinents d’un fournisseur ont fonctionné pendant plusieurs mois, demande un rapport SOC 2 de type 2 récent et examine son périmètre réel. SOC 2 est une attestation, et non une certification.

Reconnaître les besoins sectoriels et gouvernementaux

PCI DSS s’applique aux organisations qui stockent, traitent ou transmettent des données de titulaires de carte. Le périmètre du service cloud compte au même titre que la conception des paiements et les contrôles du client.

HIPAA protège les PHI relevant de son champ d’application : celles des organismes de santé concernés et de leurs partenaires commerciaux. Un fournisseur qui conserve des PHI électroniques pour le compte d’une entité concernée est un partenaire commercial, y compris lorsqu’il stocke des données chiffrées sans la clé. Un Business Associate Agreement (BAA) doit être en place. Aucune certification HIPAA officielle ne remplace ces obligations.

FedRAMP porte sur l’évaluation et la surveillance continue des services cloud destinés aux usages couverts des agences fédérales américaines. Les cas d’usage des agences et les exclusions comptent ; la vente d’un logiciel à installer à une agence ne déclenche pas à elle seule cette exigence. D’autres dispositifs de garantie comprennent C5 en Allemagne, ENS en Espagne, IRAP en Australie et ISMAP au Japon. CSA STAR publie des autoévaluations cloud et des informations de garantie indépendante.

Vérifier le périmètre du service avant de s’appuyer sur une preuve

Une clinique vérifie son BAA et la liste des services admissibles du fournisseur avant de placer des PHI électroniques dans un service. Un commerçant qui traite des données de titulaires de carte vérifie les exigences PCI DSS et peut aussi avoir des obligations au titre du RGPD pour les données personnelles. Une obligation ne remplace pas l’autre.

Un certificat ou un rapport définit un périmètre : services, lieux et dates d’évaluation. Consigne les contrôles du fournisseur dont ta charge de travail hérite, puis mets en œuvre tes propres permissions, configurations, procédures et preuves. Un label général obtenu par le fournisseur ne permet pas de savoir si un nouveau service ou une nouvelle région en particulier est couvert.

Une preuve de conformité est utile lorsqu’elle correspond au service, au lieu et à la période dont tu dépends. Le téléchargement d’un document marque le début de son examen ; son contenu détermine les garanties sur lesquelles tu peux t’appuyer.

Trouver les documents du fournisseur

Les rapports SOC détaillés nécessitent souvent l’acceptation de conditions de confidentialité ou d’un accord de confidentialité. Les rapports SOC 3 d’usage général et de nombreux certificats sont publics. Les pages publiques de conformité aident à identifier les programmes disponibles et les services couverts.

Lire un rapport SOC 2 de type 2 dans l’ordre

1. Lis l’opinion de l’auditeur. Une opinion sans réserve fournit une garantie favorable dans le périmètre indiqué ; une opinion avec réserve signale un point à comprendre.
2. Vérifie que la description et le périmètre du système correspondent aux services et aux lieux choisis.
3. Vérifie la période couverte et la date à laquelle elle a pris fin.
4. Lis les contrôles testés et les exceptions, notamment leurs conséquences sur ton utilisation.
5. Repère les contrôles complémentaires de l’entité utilisatrice (CUEC) : les contrôles que ton organisation doit appliquer.
6. Examine le rôle et le traitement des organisations sous-traitantes sur lesquelles le fournisseur s’appuie.

Un rapport peut être favorable et exiger malgré tout que ton organisation gère les accès des utilisateurs, examine les journaux ou configure un paramètre. Ajoute ces obligations à ton propre plan de contrôle et désigne des responsables.

Le 15 mars 2026, une équipe examine un rapport couvrant la période du 1er octobre 2024 au 30 septembre 2025. La période de test de douze mois a pris fin 166 jours plus tôt. Une lettre de continuité présente la déclaration du fournisseur concernant les changements pertinents survenus depuis cette date. Elle ne constitue pas un nouvel audit indépendant de chaque jour de la période intermédiaire. Obtiens le rapport suivant dès qu’il est disponible.

Conserver les contrats avec les preuves

Le RGPD exige un contrat approprié entre le responsable du traitement et le sous-traitant, généralement fourni sous la forme d’un accord ou d’un avenant de sous-traitance de données personnelles. Parmi les exemples des fournisseurs figurent l’avenant RGPD d’AWS, Products and Services Data Protection Addendum de Microsoft et Cloud Data Processing Addendum de Google. Les relations avec les partenaires commerciaux au titre de HIPAA exigent un BAA.

Un rapport décrit les contrôles évalués. Un accord crée les engagements contractuels correspondants. Aucun de ces documents ne remplit le rôle de l’autre. Veille à ce que les accords applicables aux services utilisés soient acceptés et à jour.

Suivre aussi les contrôles du client

Consigne les contrôles du fournisseur comme hérités, puis rassemble tes propres vérifications d’accès, résultats de configuration, journaux, politiques et justificatifs de formation, selon les besoins. Les packs de conformité AWS Config regroupent des vérifications techniques de configuration ; ils n’évaluent pas toutes les politiques ni toutes les procédures du personnel. Purview Compliance Manager fournit des actions d’amélioration et un score de conformité. Google Assured Workloads applique les contrôles pris en charge pour les charges de travail réglementées, notamment les restrictions de lieu et d’accès.

Considère les scores et les résultats comme une liste de travaux accompagnée de preuves à examiner. Résous les lacunes de périmètre ou de dates avant de présenter les documents à un acheteur ou à un auditeur, et vérifie si un service ou une région récemment adopté nécessite un nouvel examen.

La protection des données associe des décisions sur la finalité, les accès, le lieu et les droits des personnes. Déplacer des dossiers vers une région choisie ne répond qu’à la question du lieu.

Connaître les rôles et les obligations

Le RGPD, applicable depuis le 25 mai 2018, régit les traitements de données personnelles relevant de son champ d’application dans l’UE et l’EEE. Il concerne aussi les organisations situées hors de l’UE qui proposent des biens ou des services à des personnes dans l’UE ou y suivent leur comportement. Il ne se limite pas aux citoyens de l’UE.

Le responsable du traitement décide des finalités et des moyens du traitement. Le sous-traitant agit pour son compte. Pour les dossiers clients hébergés, le client est généralement responsable du traitement et le fournisseur de services cloud son sous-traitant. L’article 28 exige un contrat de sous-traitance écrit. Les rôles dépendent de la relation réelle de traitement, et non simplement de la désignation de l’entreprise dans le cloud.

Les obligations pertinentes pour le cloud comprennent une base légale, la collecte des seules données nécessaires (minimisation des données), une sécurité adaptée au risque, les droits d’accès et d’effacement des personnes et la notification des violations lorsqu’elle s’applique. L’article 32 cite le chiffrement et la pseudonymisation comme exemples de mesures de sécurité.

Selon l’article 33, un responsable du traitement notifie une violation de données personnelles à son autorité de contrôle dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance, sauf si elle n’est pas susceptible de présenter un risque pour les droits et libertés des personnes. Un sous-traitant informe son responsable du traitement dans les meilleurs délais. Si la violation est connue le lundi à 09 h 00, le délai de 72 heures prend fin le jeudi à 09 h 00 ; cela ne permet pas d’attendre lorsqu’une notification plus rapide est possible. Une notification tardive à l’autorité doit expliquer le retard.

La tranche supérieure prévue à l’article 83 autorise un maximum de 20 millions d’euros ou de 4 % du chiffre d’affaires annuel mondial de l’exercice précédent, le montant le plus élevé étant retenu. Pour un chiffre d’affaires de 1,5 milliard d’euros, 4 % représentent 60 millions d’euros ; pour 300 millions d’euros, ils représentent 12 millions d’euros, de sorte que le plafond de 20 millions d’euros est plus élevé. Les sanctions réelles dépendent de l’infraction et de son évaluation.

Distinguer les exigences de localisation

Vérifie les engagements de localisation d’un service, ses sauvegardes, ses répliques et les accès du support. Le choix d’une région n’est pas une garantie générale pour toutes les fonctionnalités du service. Les offres gouvernementales et souveraines, comme AWS GovCloud (US), Azure Government et les options souveraines européennes, répondent à des exigences particulières selon des conditions d’admissibilité et un périmètre définis.

Les transferts hors de l’EEE nécessitent un mécanisme juridique applicable, comme une décision d’adéquation, des clauses contractuelles types ou des règles d’entreprise contraignantes. Le mécanisme fondé sur la décision d’adéquation du cadre de protection des données UE–États-Unis s’applique aux transferts couverts vers des organisations participantes certifiées. L’accès par du personnel situé dans un autre pays peut aussi nécessiter une analyse du transfert, même si le stockage reste dans une région de l’UE.

Un assureur qui conserve les dossiers de sinistres dans l’UE choisit des régions de stockage et de sauvegarde dans l’UE, applique les garde-fous de localisation pris en charge, contrôle l’accès aux clés et examine son accord de sous-traitance et ses conditions de transfert. Les clés gérées par le client ne suffisent pas à elles seules à remplir les obligations de résidence ou de transfert.

Les données personnelles chiffrées restent des données personnelles pour une partie capable de les déchiffrer. Un chiffrement efficace peut supprimer l’obligation d’informer les personnes concernées au titre de l’article 34 lorsque ses conditions sont remplies ; la notification à l’autorité fait l’objet de critères distincts. D’autres lois, notamment la CCPA de Californie modifiée par la CPRA et la LGPD du Brésil, ont leurs propres champs d’application et obligations.