Fuite de métadonnées de Capital One: quand la configuration cloud devient une chaîne de responsabilité

Résumé

• Capital One a déclaré qu'un individu extérieur avait exploité une vulnérabilité de configuration les 22 et 23 mars 2019. Les registres pénaux et réglementaires décrivent une chaîne de contrôle plus longue: un pare-feu applicatif mal configuré a permis aux commandes d'atteindre l'environnement cloud, des identifiants ont été obtenus pour un rôle, ces identifiants pouvaient énumérer et copier les objets de stockage, et la surveillance n'a pas converti l'activité suspecte en 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 consensuelles remontent à la migration vers le 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 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 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 plaintes des consommateurs contre Capital One et Amazon ont survécu en partie au stade de la plaidoirie et ont ensuite été réglées, de sorte que l'affaire civile n'a pas produit de jugement répartissant la faute entre la banque et le fournisseur cloud.
• La leçon 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 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 régis comme un seul système.

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

La version familière de la fuite de Capital One est concise: un pare-feu était 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é dérobées. Chaque partie de cette phrase va dans la bonne direction. En tant que récit de responsabilité, elle est cependant trop étroite. Elle fait paraître l'événement comme un simple mauvais réglage à la limite d'un environnement autrement contrôlé.

Le registre officiel décrit quelque chose de plus structurel. L'annonce du 29 juillet 2019 déposée auprès de la SEC par Capital Oneindiquait que la société avait déterminé le 19 juillet qu'un individu extérieur avait obtenu des informations personnelles après avoir exploité une vulnérabilité de configuration spécifique. Elle situait l'accès non autorisé matériel les 22 et 23 mars, précisait qu'un signalement de divulgation responsable était arrivé le 17 juillet, et expliquait que la société avait corrigé la configuration et collaboré avec les forces de l'ordre fédérales. Elle ajoutait que le modèle opérationnel cloud avait 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 applicatif 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 frontière applicative peut atteindre un service de métadonnées d'instance. Un identifiant temporaire peut être utilisé via une API depuis un autre endroit. Un rôle de stockage peut énumérer un lac de données d'une taille bien supérieure au disque d'un serveur. L'automatisation qui rend les opérations cloud efficaces peut rendre une erreur d'autorisation efficace pour un intrus.

Lapage d'information sur l'incident de Capital Oneactuelle 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 concernait les informations fournies par les consommateurs et les petites entreprises lors de la demande de produits de carte de crédit de 2005 à début 2019: noms, adresses, codes postaux, numéros de téléphone, adresses électroniques, dates de naissance et revenus déclarés. Des parties des données des clients de crédit comprenaient les scores, les limites, les soldes, l'historique des paiements, les coordonnées et des fragments de données de transaction sur 23 jours en 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 précisé 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 chiffre. Les données de demande peuvent rester sensibles à l'identité longtemps après une décision de crédit. Les revenus, l'historique des adresses, la date de naissance, le statut de crédit et les identifiants gouvernementaux peuvent être combinés entre les systèmes. L'événement ne portait donc pas seulement sur le caractère privé d'un compartiment. Il portait sur la raison pour laquelle un rôle exposé à l'application pouvait atteindre le corpus stocké, pourquoi un chemin d'identification à une frontière de métadonnées locale pouvait devenir un chemin de données externe, pourquoi la surveillance n'a pas comblé l'écart 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 de base peut être tirée des divulgations de la société, 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 à forcer en une seule date. L'acte d'accusation complémentaire de 2021a accusé une période plus large d'accès informatique non autorisé commençant le 12 mars environ. L'annonce de Capital One utilisait les 22 et 23 mars pour l'accès aux données central de son récit d'incident. Une chronologie doit préserver cette différence entre la conduite accusée et la description de l'exfiltration par la société.

La même discipline s'applique aux chiffres de population. L'annonce initiale de la société utilisait environ 100 millions de personnes touchées aux États-Unis et six millions au Canada. L'administrateur du règlement aux États-Unis a plus tard décrit environ 98 millions de consommateurs américains dans le groupe de règlement. Aucun de ces chiffres ne doit être silencieusement converti en un décompte universel précis. Ils appartiennent à des registres différents, à des stades différents, avec des définitions différentes.

Comment la frontière des métadonnées est devenue une frontière d'identification

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 incite un composant côté serveur à effectuer une requête choisie ou influencée par cet appelant. La requête est effectuée 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. C'est que l'application devient un député portant l'intention d'un étranger dans un contexte réseau plus fiable.

Lapage de l'affaire Capital One du ministère de la Justicedécrit l'intrusion comme s'étant produite via un pare-feu applicatif mal configuré. L'acte d'accusation complémentaire, 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 applicatif permettaient à des commandes extérieures 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 les autorisations. 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 de vie dans des fichiers. La conception suppose cependant que l'accès depuis l'instance a une signification. Si un composant exposé sur le web peut être amené à émettre des requêtes internes arbitraires, « local pour l'instance » n'est plus équivalent à « code de charge de travail autorisé ».

L'explication de 2019 d'IMDSv2 par AWSidentifie l'adresse des métadonnées comme un point de terminaison local au lien 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 effectue 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 applicatifs ouverts, 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 entièrement 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 absolve 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 des métadonnées, limiter 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 applicative ne devrait pas automatiquement mûrir en un identifiant d'identité et qu'un identifiant d'identité ne devrait pas automatiquement mûrir en une exportation de données volumineuse.

Le pare-feu applicatif n'était pas toute la fuite

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

La première est une question de chemin applicatif et réseau. Un pare-feu applicatif 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 faisait 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é sortante, 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 à longue durée de vie intégrées de manière importante: ils tournent, expirent et peuvent être associés centralement à 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 valide 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éguait que les comptes obtenus avaient l'autorisation nécessaire pour lister et copier le stockage ciblé. L'ordonnance de rejet de septembre 2020 du tribunal civilrapporte, comme allégation acceptée à ce stade procédural, la description par Amazon d'une mauvaise configuration du pare-feu de couche applicative aggravée par des autorisations probablement plus larges que prévu. L'ordonnance rapporte é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 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 au consommateur 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 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 bord a besoin d'un propriétaire, d'une justification commerciale, de contrôles préventifs et de télémétrie. Supprimer une règle défectueuse 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 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 permettaient 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 à 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 consultés en dehors du chemin de service autorisé. Les applications ont néanmoins 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 prévu tout en libérant du texte 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 la séparation des autorités. Un rôle exposé à un contrôle orienté public ne devrait pas porter de larges autorisations de lecture de données et d'utilisation de clés. Les champs très sensibles devraient être tokenisés ou chiffrés sous une frontière de service que l'identité générale de lecture du stockage ne peut pas franchir. Les politiques de clés, les politiques de données et les politiques de rôles devraient ê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 tandis 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 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 fuite 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 à la question de savoir 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 sur consentement de pénalité pécuniaire 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 un traitement efficace des alertes. Capital One n'a ni admis ni nié ces conclusions. « Traitement » 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: prise de rôle, utilisation des métadonnées, liste de stockage, lectures d'objets, adresses source API, volume sortant, appels refusés, changements de politique, é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 tout en échouant 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 indépendamment.

Le fait qu'un signalement 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 par 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 compté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 d'objets volumineuse.

L'OCC a traité la fuite comme un échec de gouvernance de la migration

Le registre public de responsabilité le plus solide n'est pas un post-mortem technique. C'est le paquet d'application de l'OCC de 2020. L'annonce de pénalité de l'agenceindique que la banque n'a pas établi 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 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 nécessite toujours une gestion solide des risques et des contrôles internes.

Les conclusions consensuelles 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 le traitement des alertes. Elle a constaté que l'audit interne n'avait pas identifié de nombreuses faiblesses et lacunes de contrôle, n'avait pas efficacement signalé 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 consenti à l'ordonnance pour éviter le coût des procédures et n'a expressément ni admis ni nié les conclusions.

Ce cadrage change 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 des changements et le contrôle immédiat. Si l'échec pertinent a commencé par un modèle opérationnel insuffisamment évalué en 2015, le système responsable inclut la gouvernance de la migration, la conception des contrôles cloud, la contestation de deuxième ligne, l'audit interne, le reporting au comité, la remédiation de la direction et l'escalade au conseil d'administration.

L'ordonnance de cessation et d'abstention de l'OCCa rendu ce périmètre plus large opérationnel. Elle exigeait un comité de conformité d'au moins trois administrateurs, des plans d'action correctifs é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 des objets conteneurisés. La gestion indépendante des risques devait définir un univers complet de risques et de contrôles et contester l'évaluation de première ligne du risque cyber inhérent et résiduel.

Les exigences de test des contrôles 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 corriger ou accepter formellement le risque. L'audit interne devait valider l'exhaustivité et l'exactitude de l'inventaire par la direction des actifs technologiques, des dispositifs configurables et des logiciels; cartographier son univers d'audit avec les préoccupations d'examen; incorporer les leçons de l'analyse des causes racines de la fuite; 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 tout en manquant 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 exploiter. L'univers d'audit contient ce que l'audit s'attend à examiner. Si ces ensembles ne sont pas réconciliés, un rôle exposé au 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 repose sur des preuves, pas sur la fréquence des réunions

Ladéclaration de procuration de 2020 de Capital Oneindique 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 les causes racines et la remédiation, renforcé la surveillance et assigné au comité des risques le rôle principal dans l'examen de la cyber-gouvernance améliorée. La direction a établi un comité senior pour les questions 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 sont concentrées sur la période avant la fuite, lorsque les faiblesses de l'audit n'auraient pas été efficacement signalées et que la direction n'avait pas été 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 si l'information atteignant les administrateurs est passée du rapport d'activité à la preuve de contrôle.

L'ordonnance de l'OCC a défini ce que cette preuve devrait soutenir. Les administrateurs devaient assurer une action corrective rapide, vérifier que les actions étaient efficaces, garantir un personnel et des systèmes suffisants, tenir la direction responsable, exiger des rapports adéquats et opportuns, et 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 plus fort? 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é? Combien d'alertes ont été clôturé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 frontière opérationnelle 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 lemodè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 du 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 comme EC2, le client contrôle substantiellement plus de la pile d'exploitation qu'il ne le ferait dans un service entièrement géré.

Le modèle est utile car il évite une erreur de catégorie: louer du calcul ne fait pas du fournisseur l'opérateur des autorisations de l'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 route et les examine. Le fournisseur offre des choix de régions; le client sélectionne les régions et les architectures qui satisfont aux obligations légales. Le fournisseur rend possibles des paramètres par défaut plus sûrs; le client doit migrer les charges de travail existantes et les appliquer.

Ladéclaration sur le cloud computing du FFIECrend explicite la conséquence pour le secteur financier. 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 d'une exploitation saine et conforme. 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 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 manquantes. 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 de l'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 l'ambiguïté entre le client et le fournisseur.

Un diagramme de responsabilité partagée ne détermine pas non plus la responsabilité civile. Les conditions contractuelles, les représentations, la conception technique, les obligations de notification, la causalité, le droit étatique et les faits prouvés comptent tous. Le modèle peut guider le fonctionnement attendu, mais ce n'est pas une allocation judiciaire de la faute et ne devrait pas être présenté à un conseil d'administration comme s'il s'agissait d'une indemnité.

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

Le registre 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 ministère de la Justiceindique qu'un jury fédéral a reconnu Thompson coupable de fraude électronique, de cinq chefs d'accusation d'accès non autorisé à un ordinateur protégé et de dommage à 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 accédait à 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 sur consentement finale, mais Capital One n'a ni admis ni nié les conclusions du contrôleur. L'annonce coordonnée d'application de la Réserve fédéraleindiquait 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 sur consentement de la Réserve fédéraleexigeait que le conseil d'administration de la société mère utilise ses ressources pour s'assurer que les banques se conformaient aux ordonnances de l'OCC et soumette un plan écrit de 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 injustifié, notification et théories 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 rejeté 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'avait pas nécessairement remplacé la négligence alléguée des défendeurs. Parce qu'une motion de rejet accepte les allégations bien plaidées comme vraies, la décision a établi que les plaintes pouvaient procéder; elle n'a pas établi que Capital One ou Amazon avait commis les actes allégués.

L'affaire s'est terminée par un règlement plutôt qu'un procès sur le fond. L'ordonnance d'approbation finalea approuvé un fonds non réversible de 190 millions de dollars, des services de défense et de restauration d'identité, et des engagements 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. Il n'a pas attribué un pourcentage de responsabilité de la fuite entre la banque, AWS et l'attaquant.

Cette distinction importe parce que la phrase « qui était responsable? » peut inviter une fausse réponse. Thompson a été condamnée pour des actes criminels. Capital One a encouru des sanctions réglementaires basées sur des conclusions consensuelles et a accepté des devoirs correctifs. Capital One et Amazon ont fait face à des plaintes civiles qui ont survécu en partie et ont été réglées. Les changements de conception ultérieurs du fournisseur sont pertinents pour la prévention mais ne sont pas des admissions de faute juridique. 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 paramètres par défaut plus sûrs

AWS a introduit IMDSv2 en novembre 2019, moins de quatre mois après que Capital One a divulgué la fuite. L'avis de lancement d'AWSl'a décrit 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 des 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 transfère des requêtes GET simples 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 sauts peuvent restreindre la distance parcourue par 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 applicatives et de proxy.

Ils ne suppriment pas la nécessité du moindre privilège. Si un code hostile s'exécute effectivement sur une instance, il peut être capable d'effectuer l'échange de jeton tout comme le code légitime. Si un SSRF vulnérable permet 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 paramètres par défaut ont également une dimension temporelle. En 2019, les clients devaient choisir et appliquer la méthode renforcée après qu'elle soit devenue disponible. AWS a plus tard annoncé unefeuille de route IMDSv2-by-defaultqui a fait migrer 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 les logiciels existants; une optionnalité 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 arriéré de fonctionnalités.

Pour les conseils d'administration, la leçon est de s'interroger sur la dette de paramètres 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 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 fuite a touché des personnes des deux côtés de la frontière américano-canadienne. LeCommissariat à la protection de la vie privée du Canadaa 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. Lapage d'incident canadienne de Capital Onea fourni 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 affecté, ni ne montrent que les dossiers canadiens étaient conservés 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 registre établit, c'est qu'un incident a touché de grandes populations régies par des systèmes juridiques et réglementaires différents.

AWS déclare dans sesdocuments sur la confidentialité des donnéesque les clients contrôlent le contenu client et que les devoirs du fournisseur et du client suivent le modèle de responsabilité partagée. Soncadre de souveraineté numériqueactuel 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 les 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 frontière sélectionnée. Dans la chaîne 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 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, analytique, 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 des transferts interrégionaux, alertes pour les emplacements source inhabituels et dossiers disponibles pour les régulateurs pertinents. La quatrième est la sortie et la continuité: la capacité d'exporter les données et les 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 d'identité n'ont pas disparu parce que Capital One a son siège social aux États-Unis. Un programme cloud multinational devrait cartographier les ensembles de données aux personnes et aux obligations qu'ils représentent, pas seulement au compte et à la région dans lesquels les ingénieurs les voient.

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

Capital One a déclaré que la plus grande catégorie affectée comprenait des données de demande de 2005 à début 2019. Cette durée change l'analyse des risques. 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. Avec le temps, certaines informations peuvent rester nécessaires pour le service, les conservations légales, les devoirs réglementaires, la gouvernance des modèles, la résolution des litiges ou l'analyse de la fraude. Mais la nécessité doit être démontrée par champ, but et période.

La conservation est souvent traitée comme un calendrier de confidentialité distinct de la sécurité cloud. La fuite montre pourquoi cette séparation est artificielle. La quantité et l'âge des données accessibles à 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 qu'un événement d'identifiant unique expose quatorze ans d'historique de demande. De même, classer un champ comme sensible a peu d'effet si aucune politique de stockage, frontière de clé, rôle d'accès ou tâche de suppression ne change à cause de la classification.

Le contrôle approprié n'est pas simplement « supprimer les vieilles 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 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 devrait avoir un propriétaire et une revue d'expiration.

L'architecture des données devrait également réduire l'agrégation. Un seul rôle ne devrait pas accéder à un large corpus historique simplement parce qu'un traitement en a eu besoin une fois. Le partitionnement par but, sensibilité, période et juridiction donne à la politique d'accès quelque chose de significatif à appliquer. Sans ces frontières, le moindre privilège est forcé 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'histoire de cette institution » devient dangereusement petite.

La dépendance au cloud inclut la dépendance à la preuve

Capital One ne se contentait pas de louer 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é du service, 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é une panne 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 grand domaine cloud, identifier les enregistrements affectés, notifier les personnes dans deux pays, travailler avec les forces de l'ordre et les régulateurs, fournir une surveillance, défendre des litiges et remédier les contrôles tout en continuant à fonctionner. C'est la continuité sous des 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.

Leformulaire 10-K de 2019 de Capital Onea rapporté 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 à l'extrémité basse 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, avec certains coûts s'étendant au-delà de 2019. Elle avertissait des interventions réglementaires, des litiges, des coûts de remédiation, des atteintes à la réputation et de la 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 collectif ultérieur de 190 millions de dollars, et ils ne devraient pas être additionnés de manière désinvolte car l'assurance, le calendrier, la portée du règlement et le traitement comptable diffèrent.

La dépendance à la preuve devrait ê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 sur les 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élimitées.

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 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 les 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 une portabilité crédible des données et des preuves, pas un compte décoratif de fournisseurs.

Ce que les accords ont résolu et ce qu'ils ont laissé en suspens

Le règlement des 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 remboursables, le temps perdu, les services de défense d'identité, les services de restauration, les avis et l'administration, et les frais 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 plaintes 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 avait causé un pourcentage spécifié du préjudice ou que la configuration de Capital One avait causé le reste. Il n'a pas effacé la responsabilité pénale de Thompson, et il n'a pas déplacé les conclusions et ordonnances réglementaires distinctes de l'OCC.

Cette allocation 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 ajouter quand même un protocole plus sûr. Un client peut contester les conclusions du régulateur et accepter quand même une ordonnance et réviser les contrôles. Un conseil d'administration peut réserver des 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 avaitmis fin à l'ordonnance de cessation et d'abstention de 2020à compter du 31 août 2022. La fin est un point final important pour cette ordonnance particulière. Elle n'annule pas la pénalité, ne réécrit pas les conclusions 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 d'administration mature devrait convertir les disciplines d'inventaire de contrôle, de test, d'audit et 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 le risque lié aux métadonnées, à l'identité et à la localité

Le dossier 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 sortantes, l'accessibilité des métadonnées, les identités attachées, les méthodes et en-têtes autorisés, et l'autorité maximale de données 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 de protocole est requise, la limite de sauts, les restrictions de pare-feu local, les implications de conteneur 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'impact 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 combien de données sensibles pourraient être lues pendant 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 devrait pas s'effondrer 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é exposée au public invoque des opérations de clé ou lit une classe de données en dehors de son but étroit.

Contrôler les données par but et juridiction.Étiqueter et partitionner les données selon la sensibilité, le but, la période de conservation et la population touchée. Appliquer les régions approuvées pour le stockage primaire, les répliques, l'analytique, les sauvegardes et la récupération. Enregistrer tout service qui déplace nécessairement le contenu ou les 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 dans 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 la sortie. Mesurer si les alertes sont examinées jusqu'à une conclusion démontrée, pas seulement si elles sont générées.

Réconcilier l'univers de contrôle.Le catalogue de contrôles cloud de la direction, l'inventaire des actifs, l'inventaire des configurations, le catalogue des 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 couverture inconnue.

Escalader les conclusions répétées et en retard.Un écart 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'il laisse exposés. Les rapports au conseil devraient nommer le cadre responsable, les contrôles compensatoires, la méthode de validation et la date limite. La clôture devrait nécessiter une preuve indépendante que la condition de risque a changé.

Exercer la réponse transfrontalière.Un exercice de fuite devrait 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 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 conservées sans reconstruire la réponse pendant la crise.

Préserver la coopération du fournisseur et les droits de sortie.Les contrats et procédures opérationnelles devraient garantir un accès rapide aux journaux, un support forensique, une notification d'incident, la préservation des preuves, des engagements de région, la transparence des sous-traitants et la certification de suppression. Les équipes devraient périodiquement tester l'exportation des données, de la politique, 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 satisfaire sa référence. Le service de métadonnées peut fonctionner comme documenté. Le rôle peut avoir une raison d'être 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é se situe aux intersections.

Le test durable

La fuite de Capital One reste un cas utile de responsabilité cloud parce qu'elle résiste à deux récits faciles. Le premier dit que le cloud public a causé la fuite. Cela ignore la configuration contrôlée par le client, les autorisations, l'architecture des données, la surveillance et les conclusions directes de l'OCC sur le programme de risque cloud de la banque. Le second dit que la responsabilité partagée place entièrement l'affaire 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 fortes du service de métadonnées, des paramètres par défaut plus sûrs, de la télémétrie du fournisseur et des preuves contractuelles.

Le meilleur récit suit la chaîne. Un contrôle exposé au public pouvait relayer une requête non prévue. La requête a atteint une frontière de confiance des métadonnées. L'identité temporaire résultante avait assez 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 long horizon de conservation a agrandi 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 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 consensuelles et une pénalité à Capital One. Les consommateurs ont poursuivi à la fois Capital One et Amazon; les plaintes ont survécu en partie et ont été réglées sans jugement attribuant la faute. 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, de mise en application et de règlement.

Pour les futurs conseils d'administration, la question décisive n'est pas de savoir si le fournisseur cloud est certifié, le compartiment est chiffré ou la règle de pare-feu a été corrigée. C'est 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 le but, le temps et la 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.