Sécurité des données dans le cloud : rendre la responsabilité partagée concrète

Un fournisseur cloud exploite une partie de l'environnement de sécurité. Votre équipe doit néanmoins établir quelles protections elle configure, si elles couvrent les données et services utilisés et comment elle sait qu'elles restent efficaces.

La sécurité des données dans le cloud protège la confidentialité, l'intégrité et la disponibilité lors du stockage, du traitement, du partage et du rétablissement. Elle couvre les bases de données et les stockages objet, mais aussi les autorisations applicatives, les exports SaaS, les identités de service, les sauvegardes et les ordinateurs portables ou systèmes d'automatisation capables de récupérer des données.

Du point de vue d'un CTO, la responsabilité partagée ne devient utile que lorsqu'elle débouche sur des décisions d'ingénierie précises : qui configure une mesure, qui la surveille, quelles preuves démontrent son fonctionnement et qui agit lorsqu'elle échoue. La déclaration de sécurité d'un fournisseur ne peut pas répondre à ces questions pour votre déploiement.

Établir la frontière avant de choisir les mesures

Les environnements cloud combinent des infrastructures, des plateformes et des applications fournies à distance. Le cloud public repose généralement sur une infrastructure exploitée par le fournisseur au service de nombreux clients ; le cloud privé est dédié à une seule organisation. Aucune de ces étiquettes ne détermine si vos données sont correctement protégées. L'isolation, les chemins d'accès, la responsabilité opérationnelle et les dispositifs de rétablissement comptent davantage que l'étiquette.

Partez d'un service métier et retracez ses dépendances. Identifiez les comptes ou abonnements cloud, les régions, les services, les stockages de données, les administrateurs et les systèmes de déploiement. Incluez les produits SaaS utilisés par le support, la finance et l'ingénierie : une base de données de production peut être étroitement contrôlée alors que son export clients se trouve dans un espace de travail largement partagé.

L'inventaire doit répondre à ces questions :

• Quelles informations sont stockées ou traitées, et qui est responsable de la finalité métier ?
• Où se trouvent les enregistrements principaux, les réplicas, les journaux, les exports, les caches et les copies de sauvegarde ?
• Quelles personnes, charges de travail, fournisseurs et destinataires externes peuvent y accéder ?
• Quels comptes, régions et services sont approuvés, et comment les nouveaux sont-ils découverts ?
• Quelles exigences de conservation, de suppression, de disponibilité et contractuelles s'appliquent ?

L'élasticité du cloud et l'accessibilité à distance peuvent améliorer les opérations, tandis que les services managés peuvent réduire la maintenance de l'infrastructure. Ils permettent aussi de créer des ressources et des copies plus vite que les relecteurs ne peuvent les suivre. Le coût de la sécurité inclut donc l'administration des identités, la surveillance, la collecte de preuves, les tests de rétablissement et la supervision des fournisseurs, et pas seulement la facture de stockage.

Classifier les informations là où elles se trouvent réellement

Utilisez un schéma de classification maîtrisable et lié à des actions. Par exemple, les catégories public, interne, confidentiel et restreint peuvent déterminer les règles de partage, les revues d'accès, la journalisation et la conservation. Définissez quelle catégorie couvre les identifiants clients, les secrets d'authentification, les données financières, le code source et les informations personnelles sensibles.

La découverte automatisée peut aider à repérer des jeux de données oubliés, mais faites valider les résultats par les propriétaires des données. Un scanner peut manquer des archives compressées ou des champs propres à une application, tandis qu'une chaîne de test anodine peut déclencher un faux positif. Consignez les emplacements non analysés et les limites d'échantillonnage. Pour un processus de découverte plus complet, consultez découverte des données et protection de la vie privée.

Cartographier les responsabilités service par service

La frontière des responsabilités varie selon le modèle de service et la mise en œuvre du fournisseur. Considérez ce qui suit comme un point de départ à confirmer au regard de la documentation des services et des contrats, et non comme une répartition universelle.

Pour chaque protection importante, consignez la contribution du fournisseur, la configuration côté client, le responsable de l'exploitation, le relecteur et la source de preuve. Évitez les entrées du type « chiffrement : fournisseur ». Écrivez plutôt : « Le fournisseur fournit le chiffrement managé ; l'équipe plateforme choisit la configuration des clés ; la sécurité examine les autorisations de déchiffrement ; le responsable du service teste le rétablissement. »

Incluez les identités de service et l'automatisation du déploiement au même titre que les utilisateurs humains. Un pipeline qui crée des ressources, modifie des politiques d'accès ou récupère des secrets fait partie de la frontière de sécurité. Les opérateurs de services managés et les prestataires de support externes ont eux aussi besoin de responsabilités explicites, même lorsqu'ils administrent l'infrastructure pour votre compte.

Identifiez les défaillances de passage de relais. Si le fournisseur signale un identifiant compromis, qui reçoit l'alerte en dehors des heures ouvrées ? Si une base de données est indisponible, qui décide de restaurer, de basculer ou d'attendre ? Désignez un seul responsable interne pour chaque résultat côté client, même lorsque plusieurs équipes exécutent le travail.

Évaluer l'assurance du fournisseur sans en surestimer la portée

Examinez la documentation de sécurité du service, les communications en cas d'incident, les modalités d'accès du support, les sous-traitants ultérieurs, le comportement en matière de suppression, les options de rétablissement et les journaux d'audit disponibles. Vérifiez que le niveau d'abonnement concerné inclut réellement les fonctionnalités dont votre conception a besoin.

Le périmètre des documents d'assurance doit être examiné. Un rapport SOC 2 est un rapport d'attestation, et non une certification. La certification ISO 27001 porte sur un système de management de la sécurité de l'information doté d'un périmètre défini ; elle ne prouve pas que votre tenant est configuré de manière sécurisée. Vérifiez les services couverts, la période de référence, les exceptions et les mesures incombant au client identifiées dans le rapport.

Le cas échéant, le catalogue C5 du BSI fournit des critères d'assurance pour le cloud. Distinguez une évaluation de type 1, qui porte sur la conception et la mise en œuvre à un instant donné, d'une couverture de type 2, qui porte sur le fonctionnement sur une période. Aucune ne remplace le test de vos propres accès et flux de données.

Traduire les obligations en exigences techniques

Déterminez le droit applicable et les engagements envers les clients avant de choisir une région ou d'accepter les conditions d'un fournisseur. L'applicabilité dépend des informations, des rôles dans le traitement, du secteur, des juridictions et des relations de service. Un rapport ou un certificat du fournisseur n'établit pas la conformité juridique de votre organisation.

Pour les données personnelles relevant du RGPD, l'article 32 impose une sécurité adaptée au risque ; ce n'est pas une obligation générale de chiffrer chaque jeu de données en toutes circonstances. Lorsque le fournisseur agit en tant que sous-traitant, évaluez les exigences contractuelles de l'article 28. Les dispositifs de transferts internationaux exigent une évaluation distincte. La localisation des données ne prouve pas à elle seule la souveraineté ni la conformité au RGPD, en particulier lorsque les accès du support ou des sous-traitants ultérieurs créent des chemins d'accès supplémentaires.

Recommandation pratique : traduisez chaque exigence applicable en un énoncé vérifiable : régions de traitement autorisées, destinataires approuvés, durées de conservation, restrictions d'accès, objectifs de rétablissement ou passages de relais pour la notification des incidents. Faites confirmer l'interprétation par des spécialistes juridiques et de la protection des données pendant que l'ingénierie établit comment l'exigence sera mise en œuvre et prouvée.

Vérifier les accès effectifs, et pas seulement les autorisations prévues

Les identifiants volés, les privilèges excessifs, le partage public et les abus internes sont des voies courantes d'exposition des données dans le cloud. Un stockage chiffré peut tout de même divulguer des enregistrements via un compte autorisé ou une application qui renvoie les données du mauvais client.

Fédérez les identités humaines lorsque c'est possible, afin que les processus d'arrivée, de mobilité et de départ s'appliquent aux services cloud. Exigez une authentification forte pour les accès à privilèges, privilégiez une MFA résistante à l'hameçonnage lorsqu'elle est prise en charge et séparez le travail courant de l'administration. Les accès d'urgence nécessitent des identifiants contrôlés, une utilisation surveillée et un processus de rétablissement testé ; ils ne doivent pas devenir un contournement permanent.

Pour les identités des charges de travail, préférez des identifiants à portée restreinte et de courte durée lorsque c'est possible. Examinez les relations de confiance : quelle charge de travail peut endosser un rôle, sous quelles conditions et dans quel environnement ? Supprimez les secrets intégrés dans les dépôts et les artefacts de déploiement, et restreignez l'accès au service de gestion des secrets lui-même.

Évaluez les autorisations effectives en combinant politiques d'identité, politiques de ressources, endossement de rôles, appartenance à des groupes, liens de partage et restrictions au niveau de l'organisation. Un accès « en lecture seule » peut tout de même permettre l'extraction à grande échelle d'informations sensibles. Un rôle qui ne peut pas lire les enregistrements mais peut modifier l'application ou la politique de clés peut obtenir un accès de manière indirecte.

Les preuves de revue des accès doivent identifier le principal, la ressource, les actions autorisées, la justification métier, l'approbateur et, le cas échéant, la date de retrait. Testez les départs et l'expiration des accès temporaires plutôt que de vous fier exclusivement à une procédure écrite.

Examiner conjointement l'exposition et le comportement des applications

Une mauvaise configuration combine souvent plusieurs paramètres plausibles pris isolément. Pour un stockage objet, le chiffrement par défaut ne dit pas qui peut lire les objets ni si une politique de partage les rend publics. Examinez ensemble les identités, les politiques de ressources, le comportement des applications et la surveillance.

Vérifiez les restrictions d'accès public, les flux réseau entrants, les écoutes des bases de données, les relations de confiance entre comptes, le comportement des liens signés et le partage externe. Les points de terminaison privés peuvent réduire l'exposition, mais ils ne corrigent ni des privilèges excessifs ni une application vulnérable. Séparez les environnements et limitez l'accès à la production depuis les systèmes de développement.

Les API cloud nécessitent une authentification et une autorisation au niveau des objets et des actions. Un jeton utilisateur valide ne doit pas permettre de récupérer les enregistrements d'un autre tenant en modifiant un identifiant. Testez les points de terminaison d'export, les opérations d'administration, les requêtes massives et les gestionnaires de téléversement. La limitation du débit peut réduire les abus, mais elle ne remplace pas l'autorisation.

Utilisez la revue de l'infrastructure as code et des contrôles de politiques pour empêcher les paramètres dangereux connus, puis comparez les règles approuvées avec la configuration déployée. Les modifications dans la console, les migrations et les correctifs d'urgence peuvent créer des dérives. Consignez pourquoi les exceptions existent, leurs mesures compensatoires et leur date d'expiration. La modélisation des menaces peut aider à identifier, avant la mise en œuvre, les chemins menant d'une interface exposée à des données sensibles.

Faire du chiffrement et de l'accès aux clés deux mesures distinctes

Protégez les données en transit à l'aide de protocoles authentifiés modernes et d'une validation appropriée des certificats. Examinez les connexions internes entre applications autant que les points de terminaison publics. Pour les données stockées, établissez quels services, réplicas, exports, instantanés et sauvegardes sont chiffrés, et avec quels dispositifs de clés.

Les clés gérées par le fournisseur et les clés gérées par le client correspondent à des choix opérationnels différents. Choisissez en fonction du modèle de menace, des exigences contractuelles, de la séparation administrative et des besoins de rétablissement. Une clé gérée par le client n'est pas automatiquement plus sûre si le même administrateur sans restriction contrôle à la fois l'accès aux données et les autorisations sur les clés.

Documentez qui peut chiffrer, déchiffrer, administrer, désactiver et supprimer les clés. Examinez les modifications des politiques de clés et les activités de déchiffrement inhabituelles. Établissez des processus de renouvellement, de révocation, de conservation et de récupération ; selon le service, le renouvellement d'une clé ne rechiffre pas nécessairement toutes les copies existantes.

Les services KMS et HSM peuvent soutenir la protection des clés et les opérations cryptographiques, mais ils ne suppriment pas les responsabilités liées au cycle de vie. Testez les conséquences d'une indisponibilité des clés avant d'appliquer un processus de suppression ou de révocation. Une sauvegarde protégée est inutilisable si la clé dont elle dépend ne peut pas être récupérée. Consultez chiffrement et gestion des clés pour les décisions cryptographiques correspondantes.

Surveiller l'activité sur les données et préserver la capacité de réponse

La journalisation doit couvrir les questions auxquelles les équipes de réponse doivent pouvoir répondre. Les événements d'audit d'administration peuvent montrer qui a modifié une politique sans montrer qui a téléchargé un jeu de données. Établissez où la journalisation des accès aux données est disponible, si elle est activée et quels événements ou services restent hors couverture.

Collectez les événements pertinents relatifs aux identités, au plan de contrôle, aux accès aux données, aux applications, à la gestion des clés et au partage. Conservez les identifiants de compte et de ressource, l'identité de l'acteur, les horodatages, les actions et leurs résultats. Protégez les journaux contre l'altération et la suppression non autorisée. Évitez d'y placer des contenus sensibles ou des identifiants réutilisables ; les données de diagnostic peuvent devenir une autre source d'exposition.

Donnez la priorité à des scénarios de détection tels que :

• Un stockage restreint qui devient accessible publiquement.
• Une nouvelle relation de confiance externe ou l'attribution d'un rôle à privilèges.
• Des exports massifs inhabituels ou un accès par une identité inactive.
• La désactivation de la journalisation ou la modification de sa destination.
• La suppression de sauvegardes ou des changements dans l'administration des clés.

Désignez les intervenants et testez les alertes lors d'un exercice contrôlé. Une règle qui se déclenche dans une boîte de réception que personne ne surveille n'est pas un processus de détection efficace. Consignez les échecs de collecte, les retards d'ingestion, les ressources nouvellement créées et les limites du fournisseur plutôt que de présenter un tableau de bord comme une couverture complète.

Pendant un incident, préservez les preuves pertinentes et coordonnez le confinement à travers les identités, les applications et le stockage. Révoquer un jeton peut ne pas mettre fin à d'autres sessions ni arrêter un export déjà en cours. Pour les violations de données personnelles relevant du RGPD, les sous-traitants informent les responsables du traitement dans les meilleurs délais. Les responsables du traitement notifient l'autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, à moins que la violation ne soit pas susceptible d'engendrer un risque pour les droits et libertés des personnes. Les violations présentant un risque élevé exigent aussi une communication aux personnes concernées dans les meilleurs délais, sous réserve des exceptions de l'article 34. Conservez le raisonnement ayant conduit à notifier ou à ne pas notifier.

Utiliser les outils de sécurité pour des questions définies

Les outils de sécurité cloud sont les plus utiles lorsque leur périmètre et la décision qu'ils servent sont clairs :

Commencez l'application de la DLP par des tests représentatifs et une revue par les propriétaires des données. Une règle qui bloque un travail de support légitime peut pousser les utilisateurs vers des contournements non maîtrisés. Limitez les scanners et agents de surveillance aux accès dont ils ont besoin ; un outil de découverte disposant d'un large accès en lecture devient lui-même un composant sensible.

L'automatisation peut réduire les contrôles répétitifs et la collecte de preuves. Elle ne peut pas établir qu'un service non pris en charge est sécurisé ni qu'une interprétation juridique est correcte. Maintenez une revue humaine explicite pour les constats et exceptions significatifs.

Prouver le rétablissement indépendamment de l'état des sauvegardes

Les sauvegardes ne protègent contre la perte et la corruption que si elles peuvent être restaurées dans les délais exigés par le service. Définissez avec le responsable métier les objectifs de point de reprise (RPO), qui fixent la perte de données tolérable, et les objectifs de délai de reprise (RTO), qui fixent l'interruption tolérable.

Distinguez réplication, gestion des versions, instantanés et sauvegardes. La réplication peut copier une corruption ou une suppression. Les instantanés peuvent rester vulnérables au même administrateur qui contrôle la production. Choisissez des copies protégées et une séparation administrative adaptées au modèle de menace, y compris une résistance à la suppression lorsqu'elle est disponible.

Restaurez une charge de travail représentative dans un environnement isolé. Vérifiez la cohérence des données, les dépendances applicatives, la configuration des identités, la disponibilité des clés et le temps de rétablissement écoulé. La restauration d'une base de données ne démontre pas à elle seule que le service métier fonctionne. Consignez les échecs et refaites le test après remédiation.

Évaluez séparément le rétablissement des services SaaS. Le plan de reprise d'activité du fournisseur peut restaurer la plateforme sans annuler une suppression accidentelle dans votre tenant. Déterminez la granularité de restauration disponible, les fenêtres de conservation, les options d'export et la responsabilité du déclenchement du rétablissement. Appliquez aussi les règles de classification et de conservation aux sauvegardes.

Exemple détaillé : un service d'export pour les clients

Prenons l'exemple illustratif d'une équipe SaaS qui utilise une base de données managée, un stockage objet pour les exports et un worker en arrière-plan. Supposons que les exports contiennent des coordonnées confidentielles de clients, que chaque client n'accède qu'à ses propres exports et que les objectifs de rétablissement convenus soient de quatre heures de perte de données et de huit heures d'interruption. Il s'agit d'hypothèses d'exemple, et non de cibles universelles recommandées.

Le fournisseur exploite l'infrastructure managée. L'équipe plateforme configure les restrictions réseau, les identités, le chiffrement et la journalisation. Les ingénieurs applicatifs sont responsables de l'autorisation par tenant et du comportement des liens d'export. Le responsable du service approuve les objectifs de conservation et de rétablissement ; la sécurité examine les accès et les preuves.

Le worker reçoit l'autorisation de lire les enregistrements nécessaires dans la base de données et d'écrire les exports dans le stockage désigné. Il n'a pas besoin d'autorisation pour modifier la politique de stockage ni pour supprimer des sauvegardes. Les téléchargements passent par l'autorisation par tenant ; les éventuels liens temporaires ont une validité limitée et sont traités comme des identifiants au porteur. Les fichiers d'export expirent selon la règle de conservation approuvée.

Les tests comprennent une requête d'objet non authentifiée, la tentative d'un client de récupérer l'export d'un autre client et la tentative du worker d'effectuer une action d'administration interdite. Les relecteurs vérifient aussi que l'accès public est bloqué et que les téléchargements de test produisent les événements d'audit attendus.

Un exercice de restauration vérifie la base de données et les dépendances applicatives au regard des objectifs de rétablissement retenus. Les preuves comprennent des exports de configuration, les résultats des tests d'autorisation, un échantillon d'événements d'accès et le compte rendu de restauration. Si la journalisation des accès aux données manque pour une région, la revue consigne cette lacune et attribue la remédiation ; des tests réussis ailleurs ne la referment pas.

Préserver le périmètre, les exceptions et les décisions de revue

Les preuves doivent identifier le compte, la ressource, la date, la méthode de collecte et le relecteur. Un export de configuration provenant d'un compte ne peut pas établir la posture de tous les comptes. Comparez les ressources collectées avec l'inventaire et consignez les collectes échouées ou les emplacements inaccessibles.

Tenez un ensemble de preuves concis pour chaque service : sa cartographie des responsabilités, la référence approuvée, les contrôles de configuration actuels, la revue des accès effectifs, la couverture de journalisation, les résultats de rétablissement et les exceptions ouvertes. Chaque exception nécessite un responsable, une justification du risque, des mesures compensatoires, une approbation, une date d'expiration et une condition de nouveau test.

Combinez des revues planifiées et des déclencheurs liés à des événements. Les changements de déploiement importants, les nouvelles régions, les changements de fournisseurs, les incidents, les modifications de classification des données et les nouveaux chemins de partage doivent entraîner une réévaluation. Le NIST Cybersecurity Framework fournit une référence d'organisation utile autour des fonctions Govern, Identify, Protect, Detect, Respond et Recover ; il s'agit de recommandations, et non d'une preuve qu'un déploiement satisfait à ses obligations.

Secani peut relier ce travail aux exigences, aux objets cibles, aux preuves, aux responsables, aux tâches et aux décisions de revue. Modélisez le service cloud et ses dépendances, rattachez les exports de configuration et les comptes rendus de tests aux mesures qu'ils étayent et transformez les lacunes de couverture en tâches assignées. Maintenez explicites l'approbation humaine et la traçabilité des sources. Les outils de sécurité cloud restent la source de la configuration technique et des alertes ; l'espace de travail conformité préserve leur périmètre et les actions qu'ils soutiennent.

Pour la prochaine revue d'ingénierie, choisissez un flux de données sensibles. Retracez chaque copie et chaque chemin d'accès, attribuez les responsabilités côté client, testez les autorisations effectives et restaurez une charge de travail représentative. Élargissez le périmètre une fois que cette revue produit des preuves fiables et un processus reproductible.