Violation de métadonnées de Capital One: quand la configuration cloud est devenue une chaîne de responsabilité

Résumé

• Capital One a déclaré qu’une personne extérieure avait exploité une vulnérabilité de configuration les 22 et 23 mars 2019. Les dossiers criminels et réglementaires décrivent une chaîne de contrôle plus longue: un pare-feu d’application web mal configuré a permis à des commandes d’atteindre l’environnement cloud, des identifiants ont été obtenus pour un rôle, ces identifiants ont permis de lister et de copier des objets de stockage, et la surveillance n’a pas converti l’activité suspecte en confinement rapide.
• L’Office of the Comptroller of the Currency (OCC) n’a pas qualifié l’événement d’erreur d’ingénierie isolée. Ses conclusions de consentement remontent jusqu’à la migration vers le cloud de la banque en 2015 et identifient une évaluation des risques inefficace, des contrôles de sécurité réseau et de prévention des pertes de données déficients, une mauvaise gestion des alertes, des lacunes dans l’audit interne et une action inefficace du conseil d’administration pour tenir la direction responsable.
• La responsabilité existait à plusieurs niveaux sans devenir juridiquement interchangeable. Un jury fédéral a reconnu Paige Thompson coupable d’actes criminels. Capital One a accepté une pénalité de 80 millions de dollars de l’OCC sans admettre ni nier les conclusions de l’agence. Les plaintes des consommateurs contre Capital One et Amazon ont partiellement survécu au stade des conclusions et ont été réglées plus tard, de sorte que l’affaire civile n’a pas donné lieu à une répartition de la faute par procès entre la banque et le fournisseur cloud.
• La leçon en matière de souveraineté n’est pas que le choix d’une région cloud nationale résout la protection des données. Environ six millions de personnes au Canada ont été touchées, dont environ un million dont les numéros d’assurance sociale ont été compromis. La localité, la rétention, les autorisations d’identité, l’accès aux métadonnées, l’autorité de chiffrement, la journalisation et l’accès réglementaire aux preuves doivent être gérés comme un système unique.

Une violation décrite de manière trop étroite

La version familière de la violation de Capital One est compacte: un pare-feu a été mal configuré, un attaquant a accédé à des données sur Amazon Web Services, et des informations liées à plus de 100 millions de personnes ont été dérobées. Chaque partie de cette phrase va dans la bonne direction. Cependant, en tant que compte rendu de responsabilité, il est trop étroit. Il donne l’impression que l’événement n’est dû qu’à un seul mauvais paramètre à la périphérie d’un environnement par ailleurs contrôlé.

Le dossier officiel décrit quelque chose de plus structurel. L’annonce de Capital One du 29 juillet 2019 déposée auprès de la SEC a déclaré que la société avait déterminé le 19 juillet qu’une personne extérieure avait obtenu des informations personnelles après avoir exploité une vulnérabilité de configuration spécifique. Elle a situé l’accès non autorisé matériel aux 22 et 23 mars, a indiqué qu’un rapport de divulgation responsable était arrivé le 17 juillet et a expliqué que la société avait corrigé la configuration et collaboré avec les forces de l’ordre fédérales.

Elle a également dit que le modèle d’exploitation cloud avait aidé la société à diagnostiquer et à corriger rapidement le problème une fois découvert.

Ce dernier point est important. Capital One n’a pas présenté le cloud lui-même comme la cause. La société a souligné que les éléments d’infrastructure pertinents pouvaient exister dans le cloud ou sur site. La position est techniquement défendable: un proxy inverse ou un pare-feu d’application web peut devenir un relais involontaire dans les deux environnements; les identifiants de service peuvent être trop puissants dans les deux environnements; une identité légitime peut lire des données chiffrées dans les deux environnements. Pourtant, le cloud modifie la vitesse, l’abstraction et l’échelle auxquelles ces conditions se combinent.

Une commande qui franchit une limite d’application peut atteindre un service de métadonnées d’instance. Un identifiant temporaire peut être utilisé via une API depuis un autre emplacement. Un rôle de stockage peut énumérer un lac de données mesuré bien au-delà du disque d’un seul serveur. La même automatisation qui rend les opérations cloud efficaces peut rendre une erreur de permission efficace pour un intrus.

La page d’information actuelle de Capital One sur l’incident indique qu’environ 100 millions de personnes aux États-Unis et environ six millions au Canada ont été touchées. La plus grande catégorie de données était constituée d’informations fournies par les consommateurs et les petites entreprises lors de la demande de produits de carte de crédit entre 2005 et début 2019: noms, adresses, codes postaux, numéros de téléphone, adresses e-mail, dates de naissance et revenus auto-déclarés.

Des parties des données clients incluaient des scores de crédit, des limites, des soldes, l’historique des paiements, des données de contact et des fragments de données transactionnelles sur 23 jours répartis sur 2016, 2017 et 2018. La société a signalé environ 140 000 numéros de sécurité sociale américains, environ 80 000 numéros de compte bancaire liés et environ un million de numéros d’assurance sociale canadiens parmi les données compromises. Elle a déclaré que les numéros de compte de carte de crédit et les identifiants de connexion n’avaient pas été compromis.

Ces distinctions empêchent l’exagération, mais elles ne réduisent pas la question du contrôle à un nombre. Les données de demande peuvent rester sensibles à l’identité longtemps après une décision de crédit. Le revenu, l’historique des adresses, la date de naissance, le statut de crédit et les identifiants gouvernementaux peuvent être combinés entre systèmes. L’événement ne portait donc pas seulement sur le caractère privé d’un bucket.

Il portait sur la raison pour laquelle un rôle exposé à une application pouvait accéder au corpus stocké, pourquoi un chemin d’identifiant à une limite de métadonnées locale pouvait devenir un chemin de données externe, pourquoi la surveillance n’a pas comblé la lacune, et pourquoi des données collectées sur environ quatorze ans restaient dans l’ensemble accessible.

La chronologie et la forme changeante de la responsabilité

Les dates modifient ce qu’une organisation peut raisonnablement être censée savoir et faire. La chronologie principale peut être tirée des divulgations de l’entreprise, de l’acte d’accusation et de la condamnation ultérieurs, des ordonnances réglementaires et des dossiers judiciaires sans traiter chaque source comme le même type de preuve.

Le décalage apparent entre le 12 mars et le 22 mars n’est pas une contradiction qui doit être forcée en une seule date. L’acte d’accusation modifié de 2021 accusait une période plus large d’accès informatique non autorisé commençant vers le 12 mars. L’annonce de Capital One utilisait les 22 et 23 mars pour l’accès aux données central dans son compte rendu d’incident. Une chronologie doit préserver cette différence entre le cours des actions accusé et la description de l’exfiltration par l’entreprise.

La même discipline s’applique aux décomptes de population. L’annonce initiale de l’entreprise utilisait environ 100 millions de personnes touchées aux États-Unis et six millions au Canada. L’administrateur du règlement américain a par la suite décrit environ 98 millions de consommateurs américains dans la catégorie du recours collectif. Aucun de ces chiffres ne doit être converti silencieusement en un décompte universel précis. Ils appartiennent à des dossiers différents, à des stades différents, avec des définitions différentes.

Comment la limite des métadonnées est devenue une limite d’identifiants

La chaîne technique commence par l’usurpation de requête côté serveur, souvent abrégée en SSRF. Dans une condition SSRF, un appelant externe amène un composant côté serveur à effectuer une requête choisie ou influencée par cet appelant. La requête est faite depuis la position réseau du serveur, ce qui lui permet d’atteindre des destinations inaccessibles directement depuis l’internet public. Le problème de sécurité n’est pas simplement qu’une URL a été acceptée. C’est que l’application devient un député portant l’intention d’un tiers dans un contexte réseau plus fiable.

La page de l’affaire Capital One du Département de la Justice décrit l’intrusion comme s’étant produite via un pare-feu d’application web mal configuré. L’acte d’accusation modifié, déposé avant le procès, allègue que Thompson a créé et utilisé des scanners pour identifier les clients cloud dont les configurations de pare-feu d’application web permettaient à des commandes externes d’atteindre et d’exécuter du code sur leurs serveurs.

Il allègue que ces commandes ont obtenu des identifiants de sécurité pour des comptes ou rôles clients; les identifiants ont ensuite été utilisés pour lister des buckets de stockage et copier des objets pour lesquels le rôle disposait d’une autorisation. L’acte d’accusation utilisait le terme neutre « Cloud Computing Company », mais le dossier civil public et les propres dépôts de Capital One identifient l’environnement comme étant AWS.

Un service de métadonnées d’instance EC2 existe pour que le logiciel sur une machine virtuelle puisse connaître son environnement d’exécution et obtenir des identifiants temporaires associés à un rôle d’identité attaché. C’est une alternative utile au stockage de clés d’accès à longue durée dans des fichiers. La conception suppose cependant que l’accès depuis l’instance a un sens. Si un composant exposé au web peut être amené à émettre des requêtes internes arbitraires, « local à l’instance » n’est plus équivalent à « code de charge de travail autorisé ».

L’explication par AWS de l’IMDSv2 en 2019 identifie l’adresse de métadonnées comme un point de terminaison link-local et explique que les métadonnées peuvent inclure des identifiants temporaires pour un rôle attaché à l’instance. La version 2 exige que le logiciel fasse d’abord une requête HTTP PUT pour établir une session et recevoir un jeton secret, puis qu’il présente ce jeton dans les requêtes de métadonnées ultérieures.

AWS a conçu le protocole pour ajouter une résistance contre les pare-feu d’application web ouverts courants, les proxys inverses ouverts, les faiblesses SSRF et certaines erreurs de pare-feu de couche 3 ou de traduction d’adresses réseau. Les clients pouvaient exiger la version 2 ou désactiver complètement l’accès aux métadonnées.

Le point analytique important n’est pas qu’une révision de protocole prouve rétroactivement un défaut, ni qu’une configuration client décharge le concepteur de la plateforme de toute responsabilité de conception. C’est qu’une hypothèse de confiance locale peut être renforcée à plus d’un niveau. Capital One pouvait contraindre le WAF, restreindre la sortie vers le point de terminaison de métadonnées, réduire le rôle, limiter le stockage accessible, détecter une utilisation inhabituelle des API et réduire les données conservées. AWS pouvait rendre le protocole de métadonnées moins réutilisable via les proxys transparents et les chemins SSRF.

La défense en profondeur reconnaît qu’une erreur d’application ne doit pas automatiquement mûrir en un identifiant d’identité et qu’un identifiant d’identité ne doit pas automatiquement mûrir en une exportation de données massive.

Le pare-feu d’application web n’était pas toute la violation

Appeler l’incident une mauvaise configuration de pare-feu peut cacher trois questions distinctes. Premièrement, pourquoi une requête non fiable a-t-elle pu amener le pare-feu ou un composant derrière lui à atteindre une destination interne? Deuxièmement, quelle identité a été exposée lorsque cela s’est produit? Troisièmement, que pouvait faire cette identité?

La première est une question d’application et de chemin réseau. Un pare-feu d’application web est généralement compris comme un contrôle qui filtre les entrées hostiles avant qu’elles n’atteignent une application. Dans cet incident, la configuration pertinente en a fait une partie de la route vers les ressources internes. Cette inversion devrait changer la façon dont les équipes cloud testent les contrôles de périphérie. Un WAF n’est pas seulement un ensemble de règles au périmètre public; c’est du code avec un contexte d’exécution, une accessibilité de sortie, des en-têtes, des méthodes et une identité attachée.

L’examen de sécurité doit demander ce que le contrôle peut atteindre et usurper lorsqu’il est lui-même confus.

La deuxième question concerne les identifiants de métadonnées. Les identifiants temporaires sont plus sûrs que les clés de longue durée intégrées de manière importante: elles tournent, expirent et peuvent être associées de manière centrale à un rôle. Mais « temporaire » décrit la durée, pas le privilège. Si un attaquant peut récupérer à plusieurs reprises un identifiant actuel, ou peut utiliser un identifiant pendant sa fenêtre de validité pour copier un grand ensemble de données, la rotation n’empêche pas le préjudice. L’hygiène des identifiants doit donc inclure le chemin par lequel l’identifiant est émis et les autorisations qu’il porte.

La troisième question est le moindre privilège. L’acte d’accusation allègue que les comptes obtenus avaient la permission requise pour lister et copier le stockage ciblé. L’ordonnance de rejet de motion de septembre 2020 du tribunal civil enregistre, comme allégation acceptée à ce stade procédural, la description par Amazon d’une mauvaise configuration de pare-feu de couche d’application aggravée par des autorisations qui étaient probablement plus larges que prévu. L’ordonnance enregistre également les allégations des plaignants concernant l’accès au stockage et à un lac de données. Ces passages ne sont pas des constatations de procès.

Ils sont toujours utiles car la décision du tribunal montre qu’une intrusion criminelle n’a pas nécessairement rompu la chaîne causale alléguée entre les décisions de sécurité et le préjudice aux consommateurs en droit.

Un examen efficace éviterait donc de conclure par « le WAF a été corrigé ». Il reconstruirait le graphe complet des privilèges: requête publique vers proxy; proxy vers point de terminaison de métadonnées; point de terminaison de métadonnées vers session de rôle; rôle vers listage de stockage; listage de stockage vers lecture d’objet; lecture d’objet vers chemin de déchiffrement; appel API vers sortie réseau. Chaque arête a besoin d’un propriétaire, d’une justification métier, de contrôles préventifs et de télémétrie. Supprimer une règle défectueuse arrête l’itinéraire connu.

Cela n’établit pas que l’architecture d’identité et de données était proportionnée.

Le chiffrement protégeait les supports, pas l’utilisation abusive autorisée

Capital One a déclaré qu’elle chiffrait les données en pratique standard et tokenisait certains champs, notamment les numéros de sécurité sociale et de compte. Elle a également déclaré que les circonstances avaient permis le déchiffrement des données consultées, tandis que les données tokenisées restaient protégées car la tokenisation utilisait une méthode et des clés différentes. C’est un correctif important à l’affirmation courante selon laquelle « les données étaient chiffrées » résout la question du contrôle.

Le chiffrement au repos est principalement conçu pour protéger les données lorsque les supports de stockage, les instantanés ou le stockage sous-jacent sont consultés en dehors du chemin de service autorisé. Les applications doivent toujours pouvoir lire les données. Les systèmes de stockage cloud et de gestion des clés déchiffrent donc les informations pour les identités qui satisfont à la politique.

Si l’attaquant acquiert un identifiant avec la même autorité de lecture que la charge de travail, le chiffrement peut fonctionner exactement comme prévu tout en délivrant le texte en clair à un humain non autorisé utilisant une identité machine autorisée.

Ce n’est pas un argument contre le chiffrement. C’est un argument pour séparer les autorités. Un rôle exposé à un contrôle public ne devrait pas porter d’autorisations générales de lecture de données et d’utilisation de clés. Les champs hautement sensibles doivent être tokenisés ou chiffrés sous une limite de service que l’identité générale de lecture de stockage ne peut pas franchir. Les politiques de clé, les politiques de données et les politiques de rôle doivent être examinées comme une seule décision d’autorisation.

Sinon, trois configurations individuellement plausibles peuvent se croiser pour accorder un accès qu’aucun de leurs propriétaires n’avait prévu.

L’événement montre également pourquoi les rapports de contrôle doivent distinguer la couverture de la conséquence. « Cent pour cent des objets chiffrés » peut être vrai alors que le risque de confidentialité reste élevé. Une métrique de conseil plus utile montrerait quelle proportion d’objets sensibles peut être lue par chaque rôle d’exécution, quelles identités peuvent invoquer le déchiffrement, si une charge de travail exposée au public apparaît dans ces chemins, et à quelle fréquence un rôle lit en dehors de son préfixe, volume, région ou modèle temporel normal.

La détection a échoué avant que la réponse ne réussisse

Le programme de divulgation responsable de Capital One a fonctionné une fois qu’une personne extérieure l’a utilisé. La société a déclaré avoir reçu un signalement le 17 juillet, confirmé la violation le 19 juillet, corrigé le problème, contacté le FBI, annoncé l’incident le 29 juillet et soutenu une arrestation rapide. Ce sont des faits de réponse significatifs. Ils n’expliquent pas pourquoi le système de contrôle interne n’a pas résolu l’activité de mars.

Les conclusions de l’OCC comblent cette lacune à un niveau supérieur. Dans l’ordonnance de pénalité civile, le contrôleur a constaté que Capital One n’avait pas établi une gestion appropriée des risques cloud, y compris des contrôles adéquats de prévention des pertes de données et une disposition efficace des alertes. Capital One n’a ni admis ni nié ces constatations. La « disposition » est plus que la génération d’une alerte. C’est le processus qui détermine si un événement est bénin, escaladé, confiné ou clos avec des preuves.

Les domaines cloud génèrent une télémétrie abondante: hypothèse de rôle, utilisation des métadonnées, listage de stockage, lectures d’objets, adresses source des API, volume de sortie, appels refusés, modifications de politique et événements de classification des données. Plus de signaux ne créent pas automatiquement la détection. Un programme peut collecter chaque événement pertinent et échouer si les règles ne corrèlent pas la séquence, si les seuils sont insensibles au comportement normal d’un rôle, si les alertes manquent d’un propriétaire responsable, ou si les motifs de clôture ne sont pas examinés de manière indépendante.

Le fait qu’un signalement externe ait conduit à la découverte doit être enregistré comme un succès de réponse et un échec d’assurance. Le succès est que le canal existait, était surveillé et a permis l’action. L’échec est qu’un chemin d’accès vieux de quatre mois était découvrable par une activité publique avant que les propres contrôles de la banque n’aboutissent à un confinement final. La divulgation responsable est un capteur externe précieux. Elle ne doit pas être comptée comme un substitut à la détection interne de la récupération d’identifiants, de l’énumération inhabituelle de buckets et de la copie massive d’objets.

L’OCC a traité la violation comme une défaillance de gouvernance de migration

Le dossier public de responsabilité le plus solide n’est pas une autopsie technique. C’est l’ensemble des mesures d’exécution de l’OCC de 2020. L’annonce de pénalité de l’agence indique que la banque n’a pas mis en place de processus efficaces d’évaluation des risques avant de transférer d’importantes opérations technologiques vers le cloud public et n’a pas corrigé les lacunes en temps opportun. L’agence a imposé une pénalité de 80 millions de dollars, a crédité la notification et la remédiation de la banque, et a déclaré que l’innovation responsable exige toujours une gestion des risques et des contrôles internes solides.

Les constatations de consentement sont inhabituellement spécifiques. L’OCC a constaté que vers 2015, la banque n’avait pas établi d’évaluation efficace des risques avant la migration. Elle a constaté des lacunes dans la conception et la mise en œuvre des contrôles de sécurité réseau, la prévention des pertes de données et la disposition des alertes.

Elle a constaté que l’audit interne n’avait pas identifié de nombreuses faiblesses et lacunes de contrôle, n’avait pas signalé efficacement les faiblesses identifiées au comité d’audit, et que le conseil d’administration n’avait pas pris de mesures efficaces pour tenir la direction responsable de certaines préoccupations soulevées par l’audit. Capital One a accepté l’ordonnance pour éviter les frais de procédure et n’a expressément ni admis ni nié les constatations.

Ce cadrage change l’unité de responsabilité. Si l’événement n’était qu’une mauvaise règle de WAF créée en 2019, la remédiation pourrait se concentrer sur l’ingénieur, l’examen des modifications et le contrôle immédiat. Si la défaillance pertinente a commencé avec un modèle d’exploitation insuffisamment évalué en 2015, le système responsable inclut la gouvernance de la migration, la conception des contrôles cloud, la remise en question de la deuxième ligne, l’audit interne, le rapport au comité, la remédiation par la direction et l’escalade au conseil.

L’ordonnance de cessation et d’abstention de l’OCC qui l’accompagne a rendu opérationnel ce périmètre plus large. Elle exigeait un comité de conformité d’au moins trois administrateurs, des plans d’action corrective écrits, des améliorations de l’évaluation des risques technologiques, de la gestion des risques d’exploitation cloud, de la gestion indépendante des risques, du test des contrôles et de l’audit interne.

Le plan cloud devait aborder la sécurité du périmètre, l’identification et la protection des informations sensibles, la prévention et la détection des divulgations non autorisées, et la gestion de la configuration pour les objets conteneurisés. La gestion indépendante des risques devait définir un univers complet de risques et de contrôles et remettre en question l’évaluation de première ligne des risques cybernétiques inhérents et résiduels.

Les exigences de test de contrôle de l’ordonnance sont particulièrement importantes. Capital One devait élaborer un inventaire des contrôles cloud pertinents, rapprocher un plan de test basé sur les risques de cet inventaire, suivre les lacunes, les remédier ou accepter formellement le risque.

L’audit interne devait valider l’exhaustivité et l’exactitude de l’inventaire de la direction concernant les actifs technologiques, les dispositifs configurables et les logiciels; cartographier son univers d’audit sur les préoccupations d’examen; intégrer les leçons de l’analyse des causes profondes de la violation; réviser la couverture d’audit; évaluer l’expertise du personnel; et améliorer le reporting au comité d’audit.

Ces obligations répondent à une erreur récurrente de gouvernance cloud. Une entreprise peut avoir un catalogue de contrôles et un plan d’audit sans une relation fiable entre eux. Le catalogue de contrôles contient ce que la direction croit exister. L’inventaire des actifs contient ce que les équipes croient exploiter. L’univers d’audit contient ce que l’audit s’attend à examiner. Si ces ensembles ne sont pas rapprochés, un rôle exposé au public, un chemin de métadonnées, un bucket de stockage ou un moteur de configuration peut se trouver entre les modèles de propriété. L’ordonnance de l’OCC exigeait la preuve que les ensembles s’alignent.

La responsabilité du conseil d’administration est une preuve, pas une fréquence de réunions

Le document de procuration 2020 de Capital One indique que la direction a rapidement signalé l’incident au conseil après la découverte le 19 juillet. Les membres indépendants de plusieurs comités et le conseil complet se sont réunis plus de 20 fois concernant l’incident et la réponse. Le conseil a engagé des experts externes, reçu des rapports sur la cause profonde et la remédiation, renforcé la surveillance et chargé le comité des risques de diriger l’examen de la gouvernance cyber renforcée. La direction a créé un comité supérieur pour les questions cyber de l’entreprise et l’escalade.

Ces sont des réponses de gouvernance légitimes, mais le nombre de réunions ne peut pas prouver qu’un contrôle fonctionne. Les conclusions de l’OCC se sont concentrées sur la période précédant la violation, lorsque les faiblesses d’audit étaient censées ne pas avoir été signalées efficacement et que la direction n’était pas tenue responsable de certaines lacunes ouvertes. La comparaison utile n’est donc pas « peu de réunions avant, beaucoup de réunions après ». C’est de savoir si les informations parvenant aux administrateurs sont passées du rapport d’activité à la preuve de contrôle.

L’ordonnance de l’OCC a défini ce que ces preuves devraient soutenir. Les administrateurs étaient tenus de garantir des actions correctives en temps opportun, de vérifier que les actions étaient efficaces, d’assurer un personnel et des systèmes suffisants, de tenir la direction responsable, d’exiger des rapports adéquats et en temps opportun, et de traiter la non-conformité. Le conseil pouvait s’appuyer sur la direction, les comités et les tiers, mais cette confiance ne supprimait pas le devoir d’assurer une action corrective.

Pour un risque de métadonnées et de stockage cloud, un dossier de qualité pour le conseil devrait répondre à des questions concrètes. Combien de charges de travail accessibles sur Internet peuvent accéder aux métadonnées d’instance? Combien nécessitent le protocole de session renforcé? Lesquelles peuvent désactiver entièrement les métadonnées? Combien de rôles exposés au public peuvent lister ou lire des magasins d’objets sensibles? Quel est le volume maximal de données que chaque rôle peut récupérer en une durée de vie d’identifiant? Quels contrôles empêchent les données de quitter un réseau ou une région approuvés?

Combien d’alertes ont été fermées sans preuve corroborante? Quels problèmes d’audit cloud ont dépassé les dates cibles, et quel cadre dirigeant a accepté le risque résiduel?

Aucune de ces questions ne demande aux administrateurs de configurer un pare-feu. Elles demandent si la direction peut démontrer la limite d’exploitation qu’elle revendique. C’est la distinction entre l’administration et la surveillance. Les administrateurs n’ont pas besoin de connaître chaque paramètre d’API, mais ils ont besoin d’un système de reporting qui rend visibles les combinaisons dangereuses avant qu’un chercheur externe ne le fasse.

La responsabilité partagée est une carte de contrôle, pas une exonération de responsabilité

AWS décrit la sécurité cloud comme partagée entre le fournisseur et le client. Selon le modèle de responsabilité partagée d’AWS, AWS protège l’infrastructure qui exécute les services cloud, tandis que les devoirs du client varient selon la sélection des services et incluent généralement les données client, l’identité et l’accès, les logiciels d’application, la configuration du système d’exploitation, la configuration du pare-feu, les choix de chiffrement et la protection du trafic. Pour un service d’infrastructure comme EC2, le client contrôle sensiblement plus de la pile d’exploitation que dans un service entièrement géré.

Le modèle est utile car il évite une erreur de catégorie: la location de calcul ne fait pas du fournisseur l’opérateur des autorisations d’application du client. Mais le diagramme n’est que le début de la gouvernance. De nombreux contrôles importants traversent la ligne. Le fournisseur conçoit le service de métadonnées; le client décide si et comment l’utiliser. Le fournisseur fournit la machinerie de politique d’identité; le client définit les rôles et les autorisations. Le fournisseur produit des journaux; le client les active, les conserve, les achemine et les examine.

Le fournisseur propose des choix de région; le client sélectionne les régions et les architectures qui satisfont aux obligations légales. Le fournisseur rend possibles des valeurs par défaut plus sûres; le client doit migrer les charges de travail existantes et les appliquer.

La déclaration sur le cloud computing du FFIEC rend la conséquence pour le secteur financier explicite. La direction ne doit pas supposer que des contrôles de sécurité et de résilience existent simplement parce que des systèmes fonctionnent dans un environnement cloud. La déclaration indique que les contrats doivent identifier les responsabilités des parties, mais que les institutions financières restent responsables d’un fonctionnement sûr et sain et de la conformité.

Elle met en évidence la gouvernance, l’architecture cloud, l’identité, la gestion des données, la gestion des vulnérabilités, la surveillance, la réponse aux incidents, la continuité des activités et l’audit comme des pratiques connectées.

La responsabilité partagée doit donc être traduite en une matrice de contrôle suffisamment précise pour être testée. Pour chaque contrôle, la matrice doit identifier qui le conçoit, qui le configure, qui l’exploite, qui reçoit une alerte, qui valide l’efficacité, quelles preuves sont conservées et qui agit lorsque les preuves sont absentes. Un libellé tel que « responsabilité du client » n’est pas un propriétaire de contrôle.

Dans une grande banque, « client » peut signifier l’équipe d’ingénierie de la plateforme, les équipes d’application, la sécurité cloud, la gouvernance des données, l’ingénierie des identités, le risque d’entreprise, l’audit interne, le service juridique ou un fournisseur. L’ambiguïté à l’intérieur de l’organisation cliente peut être plus dangereuse que l’ambiguïté entre le client et le fournisseur.

Le diagramme de responsabilité partagée ne décide pas non plus de la responsabilité civile. Les conditions contractuelles, les déclarations, la conception technique, les obligations de notification, la causalité, le droit des États et les faits prouvés comptent tous. Le modèle peut guider le fonctionnement attendu, mais il ne constitue pas une répartition judiciaire de la faute et ne doit pas être présenté à un conseil comme s’il s’agissait d’une indemnité.

Responsabilité pénale, responsabilité réglementaire et exposition civile

Le dossier public soutient plusieurs formes de responsabilité, chacune avec un statut juridique différent.

La responsabilité pénale est la plus claire. L’annonce de condamnation du Département de la Justice indique qu’un jury fédéral a reconnu Thompson coupable de fraude électronique, de cinq chefs d’accès non autorisé à un ordinateur protégé et d’endommagement d’un ordinateur protégé. Les procureurs ont montré qu’elle scannait les comptes cloud à la recherche de mauvaises configurations, les utilisait pour obtenir des données et de la puissance de calcul et avait accédé à plus de 30 entités. Elle a été condamnée à la peine de prison déjà purgée et à cinq ans de probation.

Cette conduite criminelle jugée ne doit pas être atténuée en une découverte accidentelle.

La responsabilité réglementaire s’est concentrée sur la banque. L’ordonnance de pénalité de l’OCC est une ordonnance de consentement définitive, mais Capital One n’a ni admis ni nié les constatations du contrôleur. L’annonce coordonnée de la Réserve fédérale indiquait que la société holding devait améliorer la gestion des risques, la gouvernance, la cybersécurité et les contrôles de sécurité de l’information.

L’ordonnance de consentement de la Réserve fédérale qui l’accompagne exigeait que le conseil d’administration de la société mère utilise ses ressources pour s’assurer que les banques respectent les ordonnances de l’OCC et soumettent un plan écrit pour la surveillance du conseil.

L’exposition civile était plus large mais moins concluante quant à la faute ultime. Les consommateurs ont poursuivi Capital One et Amazon sous des théories de négligence, de contrat, d’enrichissement sans cause, de notification et de protection des consommateurs. En septembre 2020, le tribunal de district a accordé certaines parties des motions de rejet des défendeurs et en a refusé d’autres. La plupart des plaintes pour négligence ont survécu, tandis que les plaintes pour négligence de l’État de Washington et plusieurs théories de négligence per se ont été rejetées.

Le tribunal a conclu à ce stade que la conduite criminelle de Thompson n’a pas nécessairement remplacé la négligence alléguée des défendeurs. Puisqu’une motion de rejet accepte les allégations bien plaidées comme vraies, la décision établissait que les plaintes pouvaient procéder; elle n’établissait pas que Capital One ou Amazon avaient commis les actes allégués.

L’affaire s’est terminée par un règlement plutôt que par un procès au fond. L’ordonnance d’approbation finale a approuvé un fonds non réversible de 190 millions de dollars, des services de défense et de restauration d’identité et des engagements en matière de pratiques commerciales. Le règlement a résolu les plaintes contre Capital One et Amazon. L’approbation signifiait que le tribunal avait jugé la résolution négociée équitable, raisonnable et adéquate selon les règles des recours collectifs. Elle n’a pas attribué un pourcentage de responsabilité entre la banque, AWS et l’attaquant.

Cette distinction est importante car l’expression « qui était responsable? » peut inviter à une fausse réponse unique. Thompson a été condamnée pour des actes criminels. Capital One a subi des sanctions réglementaires basées sur des constatations de consentement et a accepté des devoirs correctifs. Capital One et Amazon ont fait face à des plaintes civiles qui ont partiellement survécu et ont été réglées. Les modifications de conception ultérieures du fournisseur sont pertinentes pour la prévention mais ne constituent pas des aveux de faute légale. Chaque déclaration a une source et une posture procédurale.

Les combiner en un verdict généralisé serait inexact.

IMDSv2 et la gouvernance des valeurs par défaut plus sûres

AWS a introduit IMDSv2 en novembre 2019, moins de quatre mois après que Capital One a divulgué la violation. L’avis de lancement d’AWS le décrivait comme une défense en profondeur contre l’accès non autorisé aux métadonnées. Les clients pouvaient exiger la méthode de requête améliorée sur les instances nouvelles ou en cours d’exécution ou désactiver l’accès aux métadonnées. La version 1 restait disponible pour la compatibilité.

Le jeton de session d’IMDSv2 crée une friction contre plusieurs chemins de député confus. Un proxy qui transmet des requêtes GET simples peut ne pas autoriser le PUT initial. Un proxy inverse qui insère un en-tête de transfert peut être rejeté pour la création de jeton. Un jeton est lié à l’instance et ne peut pas simplement être rejoué à partir d’une machine arbitraire. Les limites de sauts peuvent restreindre la distance de transmission d’une réponse de métadonnées à travers les couches réseau. Ce sont des contrôles de protocole précieux car ils réduisent la conséquence des erreurs d’application et de proxy.

Ils n’éliminent pas la nécessité du moindre privilège. Si du code hostile s’exécute effectivement sur une instance, il peut être en mesure d’effectuer l’échange de jeton tout comme le code légitime. Si un SSRF vulnérable autorise des méthodes et des en-têtes arbitraires, la protection peut être moins complète. Si le rôle attaché peut lire un lac de données inutile, la conséquence résiduelle reste élevée. Le durcissement des métadonnées est donc une couche dans une séquence, pas un remplacement pour la conception des rôles, le contrôle de sortie, la segmentation des données et la surveillance.

Les valeurs par défaut ont aussi une dimension temporelle. En 2019, les clients devaient choisir et appliquer la méthode renforcée après sa disponibilité. AWS a annoncé plus tard une feuille de route IMDSv2 par défaut qui orientait les démarrages rapides de la console et les types d’instances nouvellement publiés vers la version 2, tout en conservant des options de compatibilité. Cette progression illustre un dilemme de gouvernance de plateforme. Un changement obligatoire immédiat peut casser le logiciel existant; une optionnelle prolongée laisse les anciennes hypothèses en place.

Les fournisseurs doivent rendre la migration mesurable, fournir une application au niveau du compte, exposer l’utilisation restante de la version 1 et définir une direction claire. Les clients doivent traiter les mises à niveau de sécurité optionnelles comme des décisions de risque avec des propriétaires et des échéances, pas comme un carnet de fonctionnalités.

Pour les conseils, la leçon est de s’interroger sur la dette par défaut. Combien de charges de travail dépendent encore d’un mode de métadonnées hérité? Pourquoi? Qu’est-ce qui se casserait si on le désactivait? Quelles applications ne peuvent pas tolérer une limite de sauts plus basse? Quelle politique organisationnelle empêche de nouvelles exceptions? Comment l’entreprise sait-elle qu’un compte acquis ou un environnement de développement n’a pas dérivé? Une fonctionnalité sécurisée disponible mais non mesurée produit moins d’assurance qu’un programme de migration lié à l’inventaire et à l’application.

La localité des données n’a pas contenu l’accès logique

La violation a touché des personnes des deux côtés de la frontière américano-canadienne. Le Commissariat à la protection de la vie privée du Canada a ouvert une enquête après que Capital One a signalé que six millions de Canadiens étaient touchés, y compris certains dont les numéros d’assurance sociale avaient été consultés. La page canadienne sur l’incident de Capital One fournissait des avis et un soutien spécifiques au pays. L’impact transfrontalier transforme la localité d’une question abstraite d’approvisionnement cloud en une question de responsabilité.

Les sources examinées ici n’établissent pas la région AWS exacte de chaque objet touché, ni ne montrent que les enregistrements canadiens étaient conservés dans une région canadienne distincte. Cette absence doit être préservée. Il serait irresponsable d’inférer un emplacement de stockage à partir de la nationalité d’une personne concernée ou d’une marque cloud mondiale. Ce que le dossier établit, c’est qu’un seul incident a touché de grandes populations régies par différents systèmes juridiques et réglementaires.

AWS indique dans ses documents sur la confidentialité des données que les clients contrôlent le contenu client et que les devoirs du fournisseur et du client suivent le modèle de responsabilité partagée. Son cadre actuel de souveraineté numérique met l’accent sur le choix du client quant à l’emplacement des charges de travail, l’accès aux données, la résilience et le contrôle. Ces capacités sont pertinentes, mais une sélection de région n’est pas un résultat de souveraineté complet.

La localité répond à l’endroit où un service est configuré pour stocker ou traiter des données en fonctionnement normal. La sécurité doit également répondre à qui peut amener le service à les divulguer, où les identifiants peuvent être utilisés, où vont les journaux et les sauvegardes, comment l’accès au support est contrôlé et si les données exportées peuvent franchir la limite choisie. Dans la chaîne de Capital One, un identifiant API était plus conséquent que la proximité physique d’un disque. Une fois qu’un rôle était accepté comme autorisé, le stockage pouvait délivrer des objets via l’interface de service.

Une région nationale n’aurait pas, à elle seule, empêché ce chemin logique.

Les contrôles de souveraineté nécessitent donc au moins quatre couches. La première est le placement: régions approuvées, paramètres de réplication, sauvegardes, analyses, reprise après sinistre et services de support. La deuxième est l’autorité: identités, utilisation des clés, accès aux métadonnées et politiques qui restreignent les appels par réseau, compte, organisation ou région. La troisième est l’observabilité: journaux conservés dans un compte contrôlé de manière indépendante, preuves de transferts interrégionaux, alertes pour les emplacements sources inhabituels et enregistrements disponibles pour les régulateurs concernés.

La quatrième est la sortie et la continuité: la capacité d’exporter des données et des journaux sous une forme utilisable, de révoquer l’accès du fournisseur, de faire tourner les clés et d’exploiter un arrangement de récupération testé si une région, un fournisseur ou un mécanisme de transfert légal devient indisponible.

L’incident montre également que la géographie des personnes concernées peut même lorsque la géographie de l’infrastructure est incertaine. Les régulateurs canadiens, les personnes touchées, les pratiques de notification et les besoins de remédiation de l’identité n’ont pas disparu parce que Capital One a son siège social aux États-Unis. Un programme cloud multinational doit cartographier les ensembles de données vers les personnes et les obligations qu’ils représentent, et pas seulement vers le compte et la région dans lesquels les ingénieurs les voient.

La rétention a transformé un chemin d’accès en un dossier historique

Capital One a déclaré que la plus grande catégorie touchée comprenait des données de demande de 2005 à début 2019. Cette période change l’analyse du risque. Une demande de crédit a un but immédiat: évaluer l’éligibilité, se conformer à la loi, prévenir la fraude et établir un compte. Au fil du temps, certaines informations peuvent rester nécessaires pour le service, les conservations légales, les devoirs réglementaires, la gouvernance des modèles, le règlement des différends ou l’analyse de la fraude. Mais la nécessité doit être démontrée par champ, par finalité et par période.

La rétention est souvent traitée comme un calendrier de confidentialité distinct de la sécurité cloud. La violation montre pourquoi cette séparation est artificielle. La quantité et l’âge des données accessibles par un rôle compromis déterminent l’impact. Un calendrier de suppression parfait ne peut pas empêcher un attaquant de lire les enregistrements actuels, mais il peut empêcher un événement de compromission d’identifiant d’exposer quatorze ans d’historique de demandes.

De même, classer un champ comme sensible a peu d’effet si aucune politique de stockage, de limite de clé, de rôle d’accès ou de tâche de suppression ne change à cause de la classification.

Le contrôle approprié n’est pas simplement « supprimer les anciennes données ». C’est un cycle de vie défendable: identifier le but de la collecte; spécifier la base légale et commerciale de la rétention; séparer les données opérationnelles actives des archives restreintes; minimiser les champs; tokeniser les identifiants durables; appliquer la suppression; ne conserver que les enregistrements soumis à une exception documentée; et tester si les données supprimées laissent également des répliques, des ensembles de données dérivés, des caches, des instantanés et des copies de développement.

Chaque exception doit avoir un propriétaire et un examen d’expiration.

L’architecture des données doit également réduire l’agrégation. Un rôle unique ne devrait pas accéder à un vaste corpus historique simplement parce qu’un travail de traitement en a eu besoin une fois. Le partitionnement par finalité, sensibilité, période et juridiction donne à la politique d’accès quelque chose de significatif à appliquer. Sans ces limites, le moindre privilège est contraint d’opérer au niveau d’un très grand bucket ou lac de données, et la différence entre « peut exécuter cette application » et « peut lire l’historique de cette institution » devient dangereusement petite.

La dépendance au cloud inclut la dépendance aux preuves

Capital One ne louait pas simplement des disques distants. Comme tout grand client cloud, elle dépendait de la sémantique d’identité définie par le fournisseur, du comportement des métadonnées, de la journalisation des API, des constructions de région, des contrôles de stockage, de la disponibilité des services, de la documentation et de la capacité du fournisseur à préserver et à expliquer les preuves. C’est une dépendance plus large que le temps de fonctionnement.

L’incident de 2019 n’a pas causé d’interruption publique prolongée des services bancaires de base de Capital One. Le problème de continuité était la confidentialité et la confiance. L’entreprise a dû enquêter sur un vaste domaine cloud, identifier les enregistrements touchés, notifier les personnes dans deux pays, travailler avec les forces de l’ordre et les régulateurs, fournir une surveillance, défendre les litiges et remédier aux contrôles tout en continuant à fonctionner.

C’est une continuité sous preuves compromises: les services peuvent rester disponibles tandis que l’institution doit déterminer si ses enregistrements, ses processus d’identité et ses communications avec les clients peuvent encore être fiables.

Le formulaire 10-K de Capital One pour 2019 a signalé 72 millions de dollars de dépenses supplémentaires de réponse et de remédiation en 2019, compensées par 34 millions de dollars de recouvrements d’assurance. La société s’attendait à être à la limite inférieure de sa fourchette précédemment annoncée de 100 à 150 millions de dollars pour le total des éléments d’ajustement de l’incident, certains coûts s’étendant au-delà de 2019. Elle a averti d’interventions réglementaires, de litiges, de coûts de remédiation, de préjudice à la réputation et de perte de confiance.

Ces chiffres précèdent la pénalité de 80 millions de dollars de l’OCC et le fonds de règlement du recours collectif de 190 millions de dollars ultérieur, et ils ne doivent pas être additionnés à la légère car l’assurance, le calendrier, la portée du règlement et le traitement comptable diffèrent.

La dépendance aux preuves doit être planifiée contractuellement et techniquement. Un client réglementé a besoin de journaux avec des champs et une conservation adéquats, d’une notification rapide des événements du fournisseur, d’une coopération avec la collecte forensique, de devoirs de préservation, d’informations sur les régions et les sous-traitants, d’un accès aux rapports de contrôle, d’une communication des vulnérabilités et d’un processus pour les demandes gouvernementales et réglementaires.

Il a également besoin de sa propre copie des journaux critiques dans un compte de sécurité que la charge de travail compromise ne peut pas altérer. Un tableau de bord du fournisseur indiquant qu’un service a fonctionné normalement n’établit pas que les identités des clients étaient correctement définies.

La planification de sortie appartient au même ensemble. Concentrer les données et la politique d’identité chez un seul fournisseur peut améliorer la normalisation et la visibilité, mais peut également rendre la migration difficile. Un test de sortie doit mesurer le temps nécessaire pour inventorier les données, reproduire la politique d’accès, exporter les clés ou rechiffrer, transférer les journaux, reconstruire la détection, satisfaire aux contraintes de localité et prouver la suppression chez l’ancien fournisseur. Le déploiement multi-cloud n’est pas automatiquement plus sûr; dupliquer des contrôles immatures peut doubler l’incertitude.

L’objectif est la portabilité crédible des données et des preuves, pas un nombre décoratif de fournisseurs.

Ce que les règlements ont résolu, et ce qu’ils ont laissé ouvert

Le règlement avec les consommateurs est substantiel, mais sa signification doit être énoncée avec soin. Le règlement a créé un fonds de 190 millions de dollars pour les pertes éligibles, le temps perdu, les services de défense de l’identité, les services de restauration, les avis et l’administration, et les honoraires approuvés par le tribunal. Il comprenait également des engagements en matière de pratiques commerciales. L’ordonnance d’approbation finale a jugé le règlement équitable, raisonnable et adéquat et a rejeté avec préjudice les plaintes des consommateurs libérées.

Le règlement n’a pas établi que chaque allégation dans la plainte modifiée était vraie. Il n’a pas converti le contexte de la motion de rejet en constatations après preuves. Il n’a pas déterminé que la conception des métadonnées d’AWS a causé un pourcentage spécifié du préjudice ou que la configuration de Capital One a causé le reste. Il n’a pas effacé la responsabilité pénale de Thompson, et il n’a pas remplacé les constatations et ordonnances réglementaires distinctes de l’OCC.

Cette répartition non résolue est elle-même une leçon de gouvernance. Les entreprises ne peuvent pas attendre qu’un tribunal attribue un pourcentage précis avant d’améliorer un contrôle partagé. Un fournisseur de plateforme peut ne pas avoir de responsabilité jugée et néanmoins ajouter un protocole plus sûr. Un client peut contester les constatations du régulateur et néanmoins accepter une ordonnance et réviser les contrôles. Un conseil peut réserver les défenses juridiques tout en traitant les faits opérationnels comme urgents. La posture juridique et la posture de remédiation peuvent différer sans contradiction.

L’OCC a annoncé plus tard qu’elle avait résilié l’ordonnance de cessation et d’abstention de 2020 avec effet au 31 août 2022. La résiliation est un point final important pour cette ordonnance particulière. Elle n’annule pas la pénalité, ne réécrit pas les constatations historiques, ni ne prouve que le risque cloud est devenu statique. Elle indique que l’ordonnance formelle n’était plus en vigueur. Un conseil mature devrait convertir l’inventaire des contrôles, les tests, l’audit et les disciplines de reporting de l’ordonnance en gouvernance normale plutôt que de les laisser expirer avec la supervision réglementaire.

Un ensemble de preuves pour les risques de métadonnées, d’identité et de localité

Le dossier de Capital One soutient un ensemble de preuves pratique pour les organisations qui exécutent des charges de travail sensibles dans le cloud public.

Cartographier les chemins publics vers l’autorité interne.Inventorier chaque proxy accessible sur Internet, équilibreur de charge, WAF, passerelle API et application. Pour chacun, montrer les destinations de sortie, l’accessibilité des métadonnées, les identités attachées, les méthodes et en-têtes autorisés, et l’autorité maximale sur les données accessible via cette identité. Tester le chemin du point de vue de l’attaquant, pas seulement contre le diagramme d’architecture prévu.

Rendre la posture des métadonnées mesurable.Enregistrer si les métadonnées sont nécessaires, si elles peuvent être désactivées, quelle version de protocole est requise, la limite de sauts, les restrictions locales du pare-feu, les implications pour les conteneurs et les appels hérités observés. Appliquer l’état préféré au niveau de l’organisation ou du compte. Les exceptions doivent identifier le logiciel dépendant, le propriétaire du risque, les contrôles compensatoires et la date de suppression.

Calculer le rayon d’explosion des identifiants.Pour chaque rôle d’exécution, énumérer les préfixes de stockage, les bases de données, les files d’attente, les secrets, les opérations de clé et les actions administratives qu’il peut atteindre. Estimer la quantité de données sensibles qui pourraient être lues en une durée de vie d’identifiant et depuis quels emplacements réseau. Tester les autorisations effectives, y compris l’intersection des politiques d’identité, de ressource, de clé, de point de terminaison et d’organisation.

Séparer l’accès au stockage de l’autorité de déchiffrement.Le chiffrement ne doit pas s’effondrer dans le même rôle que celui exposé par le chemin de l’application. Utiliser la tokenisation ou un service distinct pour les champs d’identité durables. Alerter lorsqu’une identité exposée au public invoque des opérations de clé ou lit une classe de données en dehors de son objectif étroit.

Contrôler les données par finalité et juridiction.Marquer et partitionner les données selon la sensibilité, la finalité, la période de conservation et la population touchée. Appliquer les régions approuvées pour le stockage principal, les répliques, les analyses, les sauvegardes et la reprise. Enregistrer tout service qui déplace nécessairement le contenu ou les données de support. Tester le refus interrégional et intercompte, et pas seulement l’emplacement configuré.

Posséder la piste d’audit.Acheminer les événements d’identité, de métadonnées, de stockage, de clé, de réseau et de perte de données vers un environnement de journalisation administré indépendamment. Protéger les journaux des rôles de charge de travail. Corréler la récupération d’identifiants, les opérations de listage, les lectures d’objets, le déchiffrement et la sortie. Mesurer si les alertes font l’objet d’une enquête aboutissant à une conclusion fondée sur des preuves, et pas seulement si elles sont générées.

Rapprocher l’univers de contrôle.Le catalogue des contrôles cloud, l’inventaire des actifs, l’inventaire des configurations, le catalogue des données, le registre des risques et l’univers d’audit de la direction doivent avoir des identifiants communs. L’audit interne doit tester l’exhaustivité plutôt que d’échantillonner uniquement à partir de la liste de la direction. Les actifs et contrôles non appariés doivent être signalés comme une couverture inconnue.

Escalader les constatations répétées et en retard.Une lacune de configuration avec une date de remédiation manquée doit apparaître à côté des chemins d’identité et de données qu’elle laisse exposés. Les rapports au conseil doivent nommer le cadre responsable, les contrôles compensatoires, la méthode de validation et la date limite. La clôture doit exiger des preuves indépendantes que la condition de risque a changé.

Exercer la réponse transfrontalière.Un exercice de violation doit identifier quelles populations et régulateurs sont impliqués, quels enregistrements montrent l’emplacement et l’accès, comment les avis spécifiques au pays seront délivrés et comment la restauration de l’identité fonctionne pour différents identifiants gouvernementaux et systèmes de crédit. L’organisation doit pouvoir expliquer où les données touchées étaient conservées sans reconstituer la réponse pendant la crise.

Préserver la coopération du fournisseur et les droits de sortie.Les contrats et les procédures opérationnelles doivent garantir l’accès aux journaux en temps opportun, le soutien forensique, la notification des incidents, la préservation des preuves, les engagements de région, la transparence des sous-traitants et la certification de suppression. Les équipes doivent tester périodiquement l’exportation des données, des politiques, des clés et des preuves d’audit dans un environnement de récupération utilisable.

Cet ensemble est exigeant parce que le risque est combinatoire. Le WAF peut atteindre son niveau de base. Le service de métadonnées peut fonctionner comme documenté. Le rôle peut avoir une raison commerciale. Le bucket peut être privé. Les objets peuvent être chiffrés. Les journaux peuvent exister. Pourtant, l’intersection peut encore permettre qu’une requête publique devienne une exportation autorisée. La responsabilité appartient aux intersections.

Le test durable

La violation de Capital One reste un cas utile de responsabilité cloud parce qu’elle résiste à deux histoires faciles. La première dit que le cloud public a causé la violation. Cela ignore la configuration contrôlée par le client, les autorisations, l’architecture des données, la surveillance et les constatations directes de l’OCC sur le programme de risque cloud de la banque. La seconde dit que la responsabilité partagée place entièrement la question sur le client.

Cela traite un diagramme de fournisseur comme la fin de l’analyse de conception et néglige la valeur de défenses plus solides du service de métadonnées, de valeurs par défaut plus sûres, de la télémétrie du fournisseur et des preuves contractuelles.

Le meilleur compte rendu suit la chaîne. Un contrôle exposé au public pouvait relayer une requête non intentionnelle. La requête atteignait une limite de confiance des métadonnées. L’identité temporaire résultante avait suffisamment d’autorité pour lister et copier des informations stockées. Le chiffrement n’a pas empêché un identifiant accepté comme autorisé de lire des données. La surveillance interne n’a pas produit de confinement en temps opportun. Un horizon de rétention long a élargi le corpus exposé. Le même événement a touché des personnes sous les régimes de confidentialité américain et canadien.

L’audit et le reporting au conseil n’avaient pas imposé la résolution des lacunes plus larges de contrôle cloud identifiées par le régulateur.

La responsabilité s’est ensuite séparée par forum. L’attaquant a été condamné. Les régulateurs bancaires ont imposé des obligations de consentement et une pénalité à Capital One. Les consommateurs ont poursuivi à la fois Capital One et Amazon; les plaintes ont partiellement survécu et ont été réglées sans répartition de la faute par procès. AWS a introduit un protocole de métadonnées plus défensif. Capital One a décrit la remédiation, renforcé la surveillance du conseil et supporté des coûts substantiels de réponse, d’exécution et de règlement.

Pour les conseils futurs, la question décisive n’est pas de savoir si le fournisseur cloud est certifié, le bucket est chiffré ou la règle de pare-feu a été corrigée. C’est de savoir si l’institution peut prouver qu’aucun chemin non fiable ne peut obtenir une identité de charge de travail avec une autorité disproportionnée; que l’utilisation inhabituelle de cette identité sera détectée et résolue; que les données accessibles sont limitées par finalité, temps et juridiction; et que les preuves du fournisseur et du client peuvent être jointes assez rapidement pour gouverner le risque.

Cette preuve est le sens pratique de la responsabilité partagée. Sans elle, la responsabilité est simplement divisée sur le papier tandis que le risque reste connecté en production.