Fuite 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’un individu externe a exploité une vulnérabilité de configuration les 22 et 23 mars 2019. Les dossiers pénaux 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 pu énumérer et copier des objets de stockage, et la surveillance n'a pas converti l'activité suspecte en un confinement rapide.
• L'Office of the Comptroller of the Currency n'a pas qualifié l'événement d'erreur d'ingénierie isolée. Ses conclusions de consentement remontaient à la migration cloud de la banque en 2015 et ont identifié 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 disposition des alertes, des lacunes d'audit interne et une action inefficace du conseil d'administration pour responsabiliser la direction.
• La responsabilité existait sur plusieurs plans sans devenir juridiquement interchangeable. Un jury fédéral a condamné Paige Thompson pour des 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 réclamations des consommateurs contre Capital One et Amazon ont survécu en partie au stade des plaidoiries et ont été réglées ultérieurement, de sorte que l'affaire civile n'a pas donné lieu à un procès sur la répartition des fautes entre la banque et le fournisseur cloud.
• La leçon de souveraineté n'est pas que la sélection 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 conservation, les autorisations d'identité, l'accès aux métadonnées, l'autorité de chiffrement, la journalisation et l'accès des régulateurs aux preuves doivent être gouvernés comme un seul système.

Une brèche décrite de manière trop étroite

La version familière de la brèche de Capital One est concise: un pare-feu a été mal configuré, un attaquant a atteint des données dans Amazon Web Services, et des informations liées à plus de 100 millions de personnes ont été volées. Chaque partie de cette phrase pointe dans la bonne direction. En tant que récit de responsabilité, cependant, elle est trop étroite. Elle donne l'impression d'un simple mauvais paramétrage en périphérie d'un environnement par ailleurs contrôlé.

Les archives officielles décrivent quelque chose de plus structurel. L'annonce du 29 juillet 2019 de Capital One déposée auprès de la SEC indique que la société a déterminé le 19 juillet qu'un individu externe avait obtenu des informations personnelles après avoir exploité une vulnérabilité de configuration spécifique. Elle situe l'accès non autorisé matériel les 22 et 23 mars, indique qu'un rapport de divulgation responsable est arrivé le 17 juillet, et explique que la société a corrigé la configuration et a travaillé avec les forces de l'ordre fédérales.

Elle précise également que le modèle opérationnel cloud a aidé la société à diagnostiquer et corriger rapidement le problème une fois connu.

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 ailleurs. Un rôle de stockage peut énumérer un lac de données bien au-delà du disque d'un seul serveur. La même automatisation qui rend les opérations cloud efficaces peut rendre une erreur d'autorisation efficace pour un intrus.

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

Des parties des données des clients de crédit comprenaient des scores, des limites, des soldes, l'historique des paiements, les coordonnées et des fragments de données de transaction sur 23 jours répartis entre 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 indiqué que les numéros de compte de carte de crédit et les identifiants de connexion n'ont pas été compromis.

Ces distinctions empêchent l'exagération, mais elles ne réduisent pas la question du contrôle à un chiffre. Les données d'application peuvent rester sensibles à l'identité longtemps après une décision de crédit. Le revenu, l'historique d'adresse, la date de naissance, le statut de crédit et les identifiants gouvernementaux peuvent être combinés entre systèmes. L'événement ne concernait donc pas seulement le fait qu'un compartiment était privé.

Il s'agissait de savoir pourquoi un rôle orienté application pouvait atteindre le corpus stocké, pourquoi un chemin d'identifiants à une limite locale de métadonnées pouvait devenir un chemin de données externe, pourquoi la surveillance n'a pas comblé l'écart, et pourquoi les données collectées sur environ quatorze ans restaient dans l'ensemble accessible.

La chronologie et la forme changeante de la responsabilité

Les dates changent ce qu'une organisation peut raisonnablement être censée savoir et faire. La chronologie centrale peut être tirée des divulgations de l'entreprise, de l'acte d'accusation et de la condamnation ultérieurs, des ordonnances des régulateurs 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 qu'il faut réduire à une seule date. L'acte d'accusation supplétif de 2021 inculpait 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 au cœur de son récit de l'incident. Une chronologie doit préserver cette différence entre la conduite inculpée 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 ensuite décrit environ 98 millions de consommateurs américains dans la classe du règlement. Aucun chiffre ne doit être converti silencieusement en un nombre 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 une falsification 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 à faire une requête choisie ou influencée par cet appelant. La requête est faite depuis la position réseau du serveur, elle peut donc 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. Il est que l'application devient un député transportant l'intention d'un étranger dans un contexte réseau plus fiable.

La page de l'affaire Capital One du Department of Justice décrit l'intrusion comme s'étant produite via un pare-feu d'application web mal configuré. L'acte d'accusation supplétif, déposé avant le procès, alléguait que Thompson avait 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 de s'exécuter sur leurs serveurs. Il alléguait que ces commandes obtenaient des identifiants de sécurité pour des comptes ou rôles clients;

les identifiants étaient ensuite utilisés pour lister les compartiments de stockage et copier les objets pour lesquels le rôle avait la permission. L'acte d'accusation utilisait le terme neutre « Cloud Computing Company », mais le dossier civil public et les propres déclarations de Capital One identifient l'environnement comme AWS.

Un service de métadonnées d'instance EC2 existe pour que les logiciels sur une machine virtuelle puissent connaître leur 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 orienté 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 d'AWS de 2019 sur IMDSv2 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 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'adresse 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 absout le concepteur de la plateforme de toute responsabilité de conception. Il est qu'une hypothèse de confiance locale peut être renforcée à plus d'une couche. Capital One pouvait contraindre le WAF, restreindre le trafic sortant vers le point de terminaison de métadonnées, réduire le rôle, limiter le stockage accessible, détecter une utilisation inhabituelle de l'API et réduire les données conservées.

AWS pouvait rendre le protocole de métadonnées moins réutilisable via des proxys transparents et des chemins SSRF. La défense en profondeur reconnaît qu'une erreur d'application ne doit pas automatiquement devenir un identifiant d'identité et qu'un identifiant d'identité ne doit pas automatiquement devenir une grande exportation de données.

Le pare-feu d'application web n'était pas toute la brèche

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 de chemin d'application et de 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 périphériques. Un WAF n'est pas seulement un ensemble de règles à la périphérie publique; c'est un code avec un contexte d'exécution, une accessibilité sortante, des en-têtes, des méthodes et une identité attachée.

La revue 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 à longue durée intégrées de manière importante: ils tournent, expirent et peuvent être centralement associés à 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 courant, 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 permissions qu'il porte.

La troisième question est le moindre privilège. L'acte d'accusation alléguait que les comptes obtenus avaient la permission requise pour lister et copier le stockage ciblé. L'ordonnance de rejet de septembre 2020 du tribunal civil enregistre, comme une allégation acceptée pour ce stade procédural, la description par Amazon d'une mauvaise configuration du pare-feu de couche application aggravée par des permissions 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 conclusions de procès.

Ils sont néanmoins utiles car la décision du tribunal montre qu'une intrusion pénale ne rompait pas nécessairement la chaîne causale alléguée entre les décisions de sécurité et le préjudice des consommateurs en droit.

Une revue efficace éviterait donc de conclure par « le WAF a été corrigé ». Elle reconstruirait le graphe de privilèges complet: 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 liste de stockage; liste 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éfaillante arrête la route connue.

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

Le chiffrement protégeait les supports, pas les utilisations abusives autorisées

Capital One a déclaré qu'elle chiffrait les données comme pratique standard et tokenisait certains champs sélectionnés, notamment les numéros de sécurité sociale et de compte. Elle a également indiqué que les circonstances permettaient le déchiffrement des données accédé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 une correction importante à une affirmation courante selon laquelle « les données étaient chiffrées » résout la question du contrôle.

Le chiffrement au repos est conçu principalement pour protéger les données lorsque les supports de stockage, les instantanés ou le stockage sous-jacent sont accédés en dehors du chemin de service autorisé. Les applications ont toujours besoin de 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 conçu tout en libérant le texte en clair pour 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 orienté public ne devrait pas porter de larges permissions de lecture de données et d'utilisation de clés. Les champs hautement sensibles devraient être tokenisés ou chiffrés sous une limite de service que l'identité générale de lecteur de stockage ne peut pas franchir. Les politiques de clés, les politiques de données et les politiques de rôles devraient être revues 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 aussi pourquoi les rapports de contrôle devraient distinguer la couverture des conséquences. « Cent pour cent des objets chiffrés » peut être vrai alors que le risque de confidentialité reste élevé. Une métrique de conseil d'administration 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 orientée public apparaît dans ces chemins, et à quelle fréquence un rôle lit en dehors de son préfixe, volume, région ou schéma 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'un externe l'a utilisé. La société a déclaré avoir reçu un rapport le 17 juillet, confirmé la brèche 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 ne répondent pas pourquoi le système de contrôle interne n'a pas résolu l'activité de mars.

Les conclusions de l'OCC abordent cette lacune à un niveau supérieur. Dans l'ordonnance de consentement de pénalité civile, le contrôleur a constaté que Capital One n'avait pas mis en place 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 conclusions. « 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é, contenu ou clos avec des preuves.

Les environnements cloud génèrent une télémétrie abondante: adoption de rôle, utilisation de métadonnées, liste de stockage, lectures d'objets, adresses source API, volume sortant, appels refusés, changements de politique et événements de classification de données. Plus de signaux ne créent pas automatiquement une détection. Un programme peut collecter tous les événements pertinents mais é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 raisons de clôture ne sont pas revues indépendamment.

Le fait qu'un rapport externe ait conduit à la découverte doit être enregistré à la fois 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 via une activité publique avant que les propres contrôles de la banque ne produisent un confinement final. La divulgation responsable est un capteur externe précieux. Elle ne doit pas être considérée comme un substitut à la détection interne de la récupération d'identifiants, de l'énumération inhabituelle de compartiments et de la copie massive d'objets.

L'OCC a traité la brèche comme un échec de gouvernance de migration

Le dossier de responsabilité publique le plus solide n'est pas un post-mortem technique. C'est le paquet d'exécution de l'OCC de 2020. L'annonce de la 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 des opérations technologiques importantes vers le cloud public et n'a pas corrigé les déficiences 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 nécessite toujours une gestion des risques et des contrôles internes solides.

Les conclusions de consentement sont inhabituellement spécifiques. L'OCC a constaté qu'autour de 2015, la banque n'avait pas mis en place une évaluation des risques efficace avant la migration. Elle a constaté des déficiences 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 responsabiliser la direction concernant certaines préoccupations soulevées par l'audit. Capital One a accepté l'ordonnance pour éviter le coût des procédures et n'a expressément ni admis ni nié les conclusions.

Ce cadrage modifie l'unité de responsabilité. Si l'événement était une mauvaise règle WAF créée en 2019, la remédiation pourrait se concentrer sur l'ingénieur, la revue de changement et le contrôle immédiat. Si l'échec pertinent a commencé avec un modèle opérationnel inadéquatement évalué en 2015, le système responsable inclut la gouvernance de migration, la conception des contrôles cloud, la contestation de deuxième ligne, l'audit interne, le reporting aux comités, la remédiation par la direction et l'escalade au conseil d'administration.

L' ordonnance de cessez-et-désistez de l'OCC accompagnante a rendu ce périmètre plus large opérationnel. Elle exigeait un comité de conformité d'au moins trois administrateurs, des plans d'action corrective écrits, des améliorations dans l'évaluation des risques technologiques, la gestion des risques des opérations cloud, la gestion indépendante des risques, les tests de contrôle et l'audit interne. Le plan cloud devait traiter la sécurité périmétrique, 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 des risques et des contrôles et contester l'évaluation de première ligne des risques cyber inhérents et résiduels.

Les exigences de test de contrôle de l'ordonnance sont particulièrement importantes. Capital One devait développer un inventaire des contrôles cloud pertinents, réconcilier un plan de test basé sur les risques avec 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 des actifs technologiques, des dispositifs configurables et des logiciels de la direction; cartographier son univers d'audit sur les préoccupations d'examen; incorporer les leçons de l'analyse des causes profondes de la brèche; 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 mais manquer d'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 opérer. L'univers d'audit contient ce que l'audit s'attend à examiner. Si ces ensembles ne sont pas réconciliés, un rôle orienté public, un chemin de métadonnées, un compartiment de stockage ou un moteur de configuration peut se situer 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

La déclaration 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 racine et la remédiation, renforcé la surveillance et attribué au comité des risques le rôle principal dans l'examen de la gouvernance cyber améliorée. La direction a établi un comité senior pour les problèmes cyber d'entreprise et l'escalade.

Ce 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 concentraient sur la période précédant la brèche, lorsque les faiblesses d'audit auraient prétendument été mal remontées et que la direction n'aurait pas été tenue responsable de certaines lacunes ouvertes. La comparaison utile n'est donc pas « peu de réunions avant, beaucoup après ». Elle est de savoir si l'information parvenant aux administrateurs est passée du rapport d'activité à la preuve de contrôle.

L'ordonnance de l'OCC définissait ce que cette preuve devait soutenir. Les administrateurs étaient tenus d'assurer une action corrective rapide, de vérifier que les actions étaient efficaces, de garantir un personnel et des systèmes suffisants, de tenir la direction responsable, d'exiger un reporting adéquat et opportun, et de traiter la non-conformité. Le conseil pouvait s'appuyer sur la direction, les comités et les tiers, mais la délégation ne supprimait pas l'obligation d'assurer une action corrective.

Pour un risque de métadonnées et de stockage cloud, un dossier de qualité conseil devrait répondre à des questions concrètes. Combien de charges de travail accessibles via Internet peuvent accéder aux métadonnées d'instance? Combien nécessitent le protocole de session plus fort? Combien peuvent désactiver complètement les métadonnées? Combien de rôles orientés public peuvent lister ou lire des magasins d'objets sensibles? Quel est le volume de données maximal 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ée?

Combien d'alertes ont été closes sans preuve corroborante? Quels problèmes d'audit cloud ont dépassé les dates cibles et quel 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 opérationnelle qu'elle revendique. C'est la distinction entre administration et surveillance. Les administrateurs n'ont pas besoin de connaître chaque paramètre API, mais ils ont besoin d'un système de rapport qui rend les combinaisons dangereuses visibles 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 le choix de service et incluent généralement les données client, l'identité et l'accès, les logiciels applicatifs, 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 tel qu'EC2, le client contrôle considérablement plus de la pile opérationnelle que dans un service entièrement géré.

Le modèle est utile car il empêche une erreur de catégorie: louer du calcul ne fait pas du fournisseur l'opérateur des permissions applicatives 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 s'il l'utilise et comment. Le fournisseur fournit la machinerie des politiques d'identité; le client définit les rôles et les permissions. Le fournisseur produit des journaux; le client les active, les conserve, les achemine et les examine. Le fournisseur offre 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 les contrôles de sécurité et de résilience existent simplement parce que les systèmes fonctionnent dans un environnement cloud. La déclaration indique que les contrats doivent identifier les responsabilités des parties, mais les institutions financières restent responsables de l'exploitation saine et sûre et de la conformité.

Elle met en avant 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ôles suffisamment précise pour être testée. Pour chaque contrôle, la matrice devrait identifier qui le conçoit, qui le configure, qui l'opère, qui reçoit une alerte, qui valide l'efficacité, quelle preuve est conservée et qui agit lorsque la preuve manque. Une étiquette telle que « responsabilité du client » n'est pas un propriétaire de contrôle.

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

Un diagramme de responsabilité partagée ne décide pas non plus de la responsabilité civile. Les termes du contrat, 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 l'exploitation attendue, mais ce n'est pas une répartition judiciaire des fautes 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 la condamnation du Department of 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 a scanné des comptes cloud pour des erreurs de configuration, les a utilisés pour obtenir des données et de la puissance de calcul, et a accédé à plus de 30 entités. Elle a été condamnée à la peine déjà purgée et à cinq ans de probation. Cette conduite criminelle jugée ne devrait 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 finale, mais Capital One n'a ni admis ni nié les conclusions du contrôleur. L'annonce coordonnée d'exécution de la Réserve fédérale a indiqué que la société holding devait renforcer 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 jointe exigeait que le conseil de la société mère utilise ses ressources pour garantir que les banques se conforment aux ordonnances de l'OCC et soumettent un plan écrit pour la surveillance du conseil.

L'exposition civile était plus large mais moins concluante sur la faute ultime. Les consommateurs ont poursuivi Capital One et Amazon pour négligence, contrat, enrichissement sans cause, notification et 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 réclamations pour négligence ont survécu, tandis que les réclamations 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 ne remplaçait pas nécessairement la négligence alléguée des défendeurs. Comme une motion de rejet accepte les allégations bien plaidées comme vraies, la décision a établi que les réclamations pouvaient procéder; elle n'a pas établi que Capital One ou Amazon avaient commis les actes allégués.

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

Cette distinction importe car la phrase « qui était responsable? » peut inviter une réponse erronée. Thompson a été condamné pour des actes criminels. Capital One a fait l'objet de sanctions réglementaires sur la base de conclusions de consentement et a accepté des obligations correctives. Capital One et Amazon ont fait face à des réclamations civiles qui ont survécu en partie 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 admissions de faute légale. Chaque déclaration a une source et une posture procédurale.

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

IMDSv2 et la gouvernance de 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 brèche. 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 complètement 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 de simples requêtes GET peut ne pas permettre 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é depuis une machine arbitraire. Les limites de saut peuvent restreindre la distance à laquelle une réponse de métadonnées voyage à 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 ne suppriment pas le besoin de moindre privilège. Si un code hostile s'exécute réellement sur une instance, il peut être capable d'effectuer l'échange de jetons comme le ferait un code légitime. Si un SSRF vulnérable permet des méthodes et 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 des flux sortants, 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 plus forte après qu'elle soit devenue disponible. AWS a ensuite annoncé une feuille de route IMDSv2 par défaut qui a déplacé les démarrages rapides de la console et les types d'instances nouvellement publiés vers la version 2, tout en conservant les options de compatibilité. Cette progression illustre un dilemme de gouvernance de plateforme. Un changement immédiat obligatoire peut casser des logiciels existants; une option prolongée laisse les anciennes hypothèses en place.

Les fournisseurs devraient rendre la migration mesurable, fournir une application au niveau du compte, exposer l'utilisation restante de la version 1 et fixer une direction claire. Les clients devraient 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 backlog de fonctionnalités.

Pour les conseils, la leçon est de s'interroger sur la dette liée aux valeurs 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 casserait s'il était désactivé? Quelles applications ne peuvent pas tolérer une limite de saut inférieure? Quelle politique organisationnelle empêche de nouvelles exceptions? Comment la société sait-elle qu'un compte acquis ou un environnement de développement n'a pas dérivé? Une fonctionnalité de sécurité disponible mais non mesurée produit moins d'assurance qu'un programme de migration lié à un inventaire et à une application.

La localisation des données n'a pas contenu l'accès logique

La brèche 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, dont certains dont les numéros d'assurance sociale avaient été consultés. La page d'incident canadienne de Capital One fournissait des avis et un soutien spécifiques au pays. L'impact transfrontalier transforme la localisation 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 affecté, ni ne montrent que les enregistrements canadiens étaient détenus dans une région canadienne distincte. Cette absence doit être préservée. Il serait irresponsable de déduire un emplacement de stockage 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 des systèmes juridiques et réglementaires différents.

AWS indique dans son FAQ 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 de souveraineté numérique actuel met l'accent sur le choix du client quant à l'endroit où les charges de travail s'exécutent, 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 localisation répond à l'endroit où un service est configuré pour stocker ou traiter des données en fonctionnement normal. La sécurité doit aussi 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 sélectionnée. Dans la chaîne de Capital One, un identifiant API était plus conséquent que la proximité physique avec 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, en elle-même, n'aurait pas 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é indépendamment, preuves de transferts interrégionaux, alertes pour les emplacements source inhabituels et enregistrements disponibles pour les régulateurs concernés.

La quatrième est la sortie et la continuité: la capacité d'exporter les données et les journaux sous 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 juridique devient indisponible.

L'incident montre aussi 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 d'identité n'ont pas disparu parce que Capital One est basée aux États-Unis. Un programme cloud multinational devrait cartographier les ensembles de données avec les personnes et les obligations qu'ils représentent, pas seulement avec le compte et la région dans lesquels les ingénieurs les voient.

La conservation a transformé un chemin d'accès en dossier historique

Capital One a indiqué que la plus grande catégorie touchée comprenait des données d'application de 2005 à début 2019. Cette étendue modifie l'analyse des risques. Une demande de crédit a un objectif immédiat: évaluer l'éligibilité, se conformer à la loi, prévenir la fraude et établir un compte. Avec le temps, certaines informations peuvent rester nécessaires pour le service, les obligations légales, les devoirs réglementaires, la gouvernance des modèles, le règlement des litiges ou l'analyse de la fraude. Mais la nécessité doit être démontrée par champ, objectif et période.

La conservation est souvent traitée comme un calendrier de confidentialité séparé de la sécurité cloud. La brèche montre pourquoi cette séparation est artificielle. La quantité et l'ancienneté 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 courants, mais il peut empêcher un seul événement d'identifiant d'exposer quatorze ans d'historique d'application.

De même, classer un champ comme sensible a peu d'effet si aucune politique de stockage, limite de clé, rôle d'accès ou tâche de suppression ne change en raison 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 l'objectif de la collecte; spécifier la base légale et commerciale de la conservation; 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 quittent également les répliques, les ensembles de données dérivés, les caches, les instantanés et les copies de développement.

Chaque exception doit avoir un propriétaire et une révision d'expiration.

L'architecture des données devrait également réduire l'agrégation. Un seul rôle ne devrait pas obtenir l'accès à un vaste corpus historique simplement parce qu'un seul traitement en avait besoin un jour. La partition par objectif, 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 compartiment 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 des sémantiques d'identité définies par le fournisseur, du comportement des métadonnées, de la journalisation des API, des constructions de régions, 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 la disponibilité.

L'incident de 2019 n'a pas causé de panne publique prolongée des services bancaires de base de Capital One. La question de continuité était la confidentialité et la confiance. La société a dû enquêter sur un vaste environnement cloud, identifier les dossiers affecté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 dossiers, ses processus d'identité et ses communications avec les clients peuvent encore être fiables.

Le Formulaire 10-K 2019 de Capital One a rapporté 72 millions de dollars de dépenses de réponse et de remédiation supplémentaires en 2019, compensés par 34 millions de dollars de recouvrements d'assurance. La société s'attendait à se situer dans la partie basse de la fourchette précédemment annoncée de 100 à 150 millions de dollars pour le total des éléments d'ajustement liés à l'incident, certains coûts s'étendant au-delà de 2019. Elle a mis en garde contre une intervention réglementaire, des litiges, des coûts de remédiation, un préjudice de réputation et une perte de confiance.

Ces chiffres précédaient la pénalité de 80 millions de dollars de l'OCC et le fonds de règlement collectif ultérieur de 190 millions de dollars, et ils ne devraient 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 devrait être planifiée contractuellement et techniquement. Un client réglementé a besoin de journaux avec des champs et une rétention adéquats, d'un avis rapide des événements du fournisseur, d'une coopération pour la collecte forensique, d'obligations de conservation, d'informations sur la région et les sous-traitants, d'un accès aux rapports de contrôle, d'une communication sur les vulnérabilités et d'un processus pour les demandes des gouvernements et des régulateurs. 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 modifier.

Un tableau de bord du fournisseur qui indique que le service a fonctionné normalement n'établit pas que les identités client étaient correctement dimensionnées.

La planification de sortie appartient au même ensemble. Concentrer les données et les politiques d'identité chez un seul fournisseur peut améliorer la standardisation et la visibilité, mais peut aussi rendre la migration difficile. Un test de sortie devrait mesurer combien de temps il faut pour inventorier les données, reproduire la politique d'accès, exporter les clés ou re-chiffrer, transférer les journaux, reconstruire la détection, satisfaire aux contraintes de localisation 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 une 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 consommateur 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 personnelles éligibles, le temps perdu, les services de défense d'identité, les services de restauration, l'avis et l'administration, et les honoraires approuvés par le tribunal. Il comprenait également des engagements de pratiques commerciales. L'ordonnance d'approbation finale a jugé le règlement équitable, raisonnable et adéquat et a rejeté les réclamations des consommateurs libérées avec préjudice.

Le règlement n'a pas établi que chaque allégation de la plainte modifiée était vraie. Il n'a pas converti le contexte de la motion de rejet en conclusions après preuve. Il n'a pas déterminé que la conception des métadonnées d'AWS a causé un pourcentage spécifique du préjudice ni que la configuration de Capital One a causé le reste. Il n'a pas effacé la responsabilité pénale de Thompson et 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 net avant d'améliorer un contrôle partagé. Un fournisseur de plateforme peut n'avoir aucune responsabilité jugée et pourtant ajouter un protocole plus sûr. Un client peut contester les constatations du régulateur et pourtant accepter une ordonnance et réviser les contrôles. Un conseil peut réserver ses 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 ensuite annoncé qu'elle mettait fin à l'ordonnance de cessez-et-désistez de 2020 à compter du 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 et ne prouve pas que le risque cloud est devenu statique. Elle indique que l'ordonnance formelle n'était plus en suspens. Un conseil mature devrait convertir l'inventaire des contrôles, les tests, l'audit et les disciplines de rapport de l'ordonnance en gouvernance normale plutôt que de les laisser expirer avec la supervision réglementaire.

Un dossier de preuves pour le risque lié aux métadonnées, à l'identité et à la localisation

Le dossier de Capital One soutient un dossier 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 via Internet, équilibreur de charge, WAF, passerelle API et application. Pour chacun, montrer les destinations sortantes, l'accessibilité des métadonnées, les identités attachées, les méthodes et en-têtes autorisés, et l'autorité de données maximale accessible via cette identité. Tester le chemin du point de vue d'un attaquant, pas seulement par rapport au 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 du protocole est requise, la limite de saut, les restrictions du pare-feu local, les implications des 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, bases de données, files d'attente, secrets, opérations de clés et actions administratives qu'il peut atteindre. Estimer la quantité de données sensibles pouvant être lues en une durée de vie d'identifiant et à partir de quels emplacements réseau. Tester les permissions 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 devrait pas se confondre dans le même rôle qui est exposé via le chemin applicatif. Utiliser la tokenisation ou un service distinct pour les champs d'identité durables. Alerter lorsqu'une identité orientée 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 objectif et juridiction.Étiqueter et partitionner les données selon la sensibilité, l'objectif, la période de conservation et la population affectée. Appliquer des 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 du contenu ou des données de support. Tester le refus interrégional et intercompte, pas seulement l'emplacement configuré.

Posséder la piste d'audit.Router 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 liste, les lectures d'objets, le déchiffrement et les flux sortants. Mesurer si les alertes sont investiguées jusqu'à une conclusion basée sur des preuves, pas seulement si elles sont générées.

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

Escalader les constats récurrents et en retard.Une lacune de configuration avec une date de remédiation dépassée devrait apparaître à côté des chemins d'identité et de données qu'elle laisse exposés. Les rapports au conseil devraient nommer le dirigeant responsable, les contrôles compensatoires, la méthode de validation et l'échéance. La clôture devrait exiger une preuve indépendante que la condition de risque a changé.

Exercer la réponse transfrontalière.Un exercice de brèche devrait identifier quelles populations et régulateurs sont impliqués, quels enregistrements montrent l'emplacement et l'accès, comment les avis spécifiques par pays seront délivrés, et comment la restauration d'identité fonctionne pour différents identifiants gouvernementaux et systèmes de crédit. L'organisation devrait être capable d'expliquer où les données affectées étaient détenues sans reconstruire 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 devraient garantir un accès rapide aux journaux, un soutien forensique, un avis d'incident, une préservation des preuves, des engagements de région, une transparence des sous-traitants et une certification de suppression. Les équipes devraient tester périodiquement l'exportation des données, des politiques, des clés et des preuves d'audit vers un environnement de récupération utilisable.

Ce dossier est exigeant car le risque est combinatoire. Le WAF peut remplir sa base. Le service de métadonnées peut fonctionner comme documenté. Le rôle peut avoir une raison commerciale. Le compartiment peut être privé. Les objets peuvent être chiffrés. Les journaux peuvent exister. Pourtant, l'intersection peut encore permettre à une requête publique de devenir une exportation autorisée. La responsabilité réside aux intersections.

Le test durable

La brèche de Capital One reste un cas utile de responsabilité cloud car elle résiste à deux histoires faciles. La première dit que le cloud public a causé la brèche. Cela ignore la configuration contrôlée par le client, les permissions, 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 l'affaire entièrement sur le client.

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

Le meilleur récit suit la chaîne. Un contrôle orienté public pouvait relayer une requête non intentionnelle. La requête a atteint une limite de confiance des métadonnées. L'identité temporaire résultante avait suffisamment d'autorité pour lister et copier les informations stockées. Le chiffrement n'a pas empêché un identifiant accepté comme autorisé de lire les données. La surveillance interne n'a pas produit de confinement rapide. Un horizon de conservation 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 rapport au conseil n'avaient pas forcé 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 réclamations ont survécu en partie et ont été réglées sans répartition des fautes 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 futurs conseils, la question décisive n'est pas de savoir si le fournisseur cloud est certifié, si le compartiment est chiffré ou si la règle de pare-feu a été corrigée. Elle 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 objectif, temps et juridiction; et que les preuves du fournisseur et du client peuvent être jointes assez rapidement pour gouverner le risque.

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