Violação de metadados da Capital One: quando a configuração em nuvem se tornou uma cadeia de responsabilidade

Resumo

• Capital One afirmou que um indivíduo externo explorou uma vulnerabilidade de configuração nos dias 22 e 23 de março de 2019. Os registros criminais e regulatórios descrevem uma cadeia de controle mais longa: um firewall de aplicação web mal configurado permitiu que comandos alcançassem o ambiente de nuvem, credenciais foram obtidas para uma função, essas credenciais puderam enumerar e copiar objetos de armazenamento, e o monitoramento não converteu atividades suspeitas em contenção oportuna.
• O Office of the Comptroller of the Currency não caracterizou o evento como um erro de engenharia isolado. Suas conclusões de consentimento remontam à migração para a nuvem do banco em 2015 e identificaram avaliação de risco ineficaz, controles de segurança de rede e prevenção de perda de dados deficientes, disposição inadequada de alertas, lacunas de auditoria interna e ação ineficaz do conselho para responsabilizar a administração.
• A responsabilidade existiu em vários planos sem se tornar legalmente intercambiável. Um júri federal condenou Paige Thompson por conduta criminosa. A Capital One aceitou uma multa de US$ 80 milhões do OCC sem admitir ou negar as conclusões da agência. As reivindicações dos consumidores contra a Capital One e a Amazon sobreviveram em parte na fase de alegações e foram posteriormente resolvidas, portanto o caso civil não produziu uma alocação de culpa por julgamento entre o banco e o provedor de nuvem.
• A lição de soberania não é que selecionar uma região de nuvem doméstica resolva a proteção de dados. Aproximadamente seis milhões de pessoas no Canadá foram afetadas, incluindo cerca de um milhão cujos Números de Seguro Social foram comprometidos. Localidade, retenção, permissões de identidade, acesso a metadados, autoridade de criptografia, registro e acesso do regulador às evidências devem ser governados como um sistema.

Uma violação descrita de forma muito restrita

A versão familiar da violação da Capital One é compacta: um firewall foi mal configurado, um atacante alcançou dados na Amazon Web Services e informações de mais de 100 milhões de pessoas foram levadas. Cada parte dessa frase aponta na direção certa. No entanto, como um relato de responsabilidade, é muito restrito. Faz o evento parecer uma única configuração ruim na borda de um ambiente de outra forma controlado.

O registro oficial descreve algo mais estrutural. Oanúncio de 29 de julho de 2019 da Capital One arquivado na SECdisse que a empresa determinou em 19 de julho que um indivíduo externo obteve informações pessoais após explorar uma vulnerabilidade de configuração específica. Ele situou o acesso não autorizado material em 22 e 23 de março, disse que um relatório de divulgação responsável chegou em 17 de julho e explicou que a empresa corrigiu a configuração e trabalhou com a aplicação da lei federal. Também disse que o modelo operacional de nuvem ajudou a empresa a diagnosticar e corrigir o problema rapidamente assim que foi conhecido.

Esse último ponto é importante. A Capital One não apresentou a nuvem em si como a causa. A empresa enfatizou que os elementos de infraestrutura relevantes poderiam existir em nuvem ou localmente. A posição é tecnicamente defensável: um proxy reverso ou firewall de aplicação web pode se tornar um relé não intencional em qualquer ambiente; as credenciais de serviço podem ser muito poderosas em qualquer ambiente; uma identidade legítima pode ler dados criptografados em qualquer ambiente. No entanto, a nuvem altera a velocidade, abstração e escala nas quais essas condições se combinam.

Um comando que cruza um limite de aplicação pode alcançar um serviço de metadados de instância. Uma credencial temporária pode ser exercida através de uma API de outro lugar. Uma função de armazenamento pode enumerar um data lake medido muito além de um disco de servidor. A mesma automação que torna as operações em nuvem eficientes pode tornar um erro de permissão eficiente para um intruso.

A página atual de informações sobre o incidente da Capital One afirma que aproximadamente 100 milhões de indivíduos nos Estados Unidos e aproximadamente seis milhões no Canadá foram afetados. A maior categoria de dados eram informações fornecidas por consumidores e pequenas empresas ao solicitar produtos de cartão de crédito de 2005 até o início de 2019: nomes, endereços, códigos postais, números de telefone, endereços de e-mail, datas de nascimento e renda autoinformada.

Partes dos dados de clientes de crédito incluíam pontuações, limites, saldos, histórico de pagamentos, dados de contato e fragmentos de dados de transações de 23 dias entre 2016, 2017 e 2018. A empresa relatou cerca de 140.000 números de Seguro Social dos EUA, cerca de 80.000 números de contas bancárias vinculadas e aproximadamente um milhão de Números de Seguro Social Canadenses entre os dados comprometidos. Disse que números de contas de cartão de crédito e credenciais de login não foram comprometidos.

Essas distinções impedem o exagero, mas não reduzem a questão de controle a um número. Os dados de aplicação podem permanecer sensíveis à identidade muito depois de uma decisão de crédito. Renda, histórico de endereços, data de nascimento, status de crédito e identificadores governamentais podem ser combinados entre sistemas. O evento não foi, portanto, apenas sobre se um bucket era privado.

Foi sobre por que uma função voltada para aplicação podia alcançar o corpus armazenado, por que um caminho de credencial em um limite de metadados local podia se tornar um caminho de dados externo, por que o monitoramento não fechou a lacuna e por que os dados coletados ao longo de aproximadamente catorze anos permaneceram dentro do conjunto acessível.

A cronologia e a forma mutável de responsabilidade

As datas alteram o que uma organização pode razoavelmente saber e fazer. A cronologia principal pode ser extraída de divulgações da empresa, da acusação e condenação posteriores, ordens regulatórias e registros judiciais sem tratar cada fonte como o mesmo tipo de prova.

A aparente incompatibilidade entre 12 de março e 22 de março não é uma contradição que precisa ser forçada em uma data. A acusação substitutiva de 2021 imputou um período mais amplo de acesso não autorizado a computador começando em ou por volta de 12 de março. O anúncio da Capital One usou 22 e 23 de março para o acesso a dados central em seu relato do incidente. Uma cronologia deve preservar essa diferença entre o curso de conduta imputado e a descrição da empresa sobre a exfiltração.

A mesma disciplina se aplica às contagens populacionais. O anúncio inicial da empresa usou aproximadamente 100 milhões de indivíduos afetados nos Estados Unidos e seis milhões no Canadá. O administrador do acordo nos EUA descreveu posteriormente aproximadamente 98 milhões de consumidores nos EUA na classe do acordo. Nenhum dos números deve ser convertido silenciosamente em uma contagem universal precisa. Eles pertencem a registros diferentes, em estágios diferentes, com definições diferentes.

Como o limite de metadados se tornou um limite de credenciais

A cadeia técnica começa com server-side request forgery, frequentemente abreviado como SSRF. Em uma condição SSRF, um chamador externo induz um componente do lado do servidor a fazer uma requisição escolhida ou influenciada por esse chamador. A requisição é feita a partir da posição de rede do servidor, portanto pode alcançar destinos não disponíveis diretamente da internet pública. O problema de segurança não é simplesmente que uma URL foi aceita. É que a aplicação se torna um representante carregando a intenção de um estranho em um contexto de rede mais confiável.

A página do caso Capital One do Departamento de Justiça descreve a intrusão como ocorrendo através de um firewall de aplicação web mal configurado. A acusação substitutiva, apresentada antes do julgamento, alegou que Thompson criou e usou scanners para identificar clientes de nuvem cujas configurações de firewall de aplicação web permitiam que comandos externos alcançassem e executassem em seus servidores. Alegou que esses comandos obtiveram credenciais de segurança para contas ou funções de clientes; as credenciais foram então usadas para listar buckets de armazenamento e copiar objetos para os quais a função tinha permissão.

A acusação usou o termo neutro "Cloud Computing Company", mas o registro civil público e os próprios arquivos da Capital One identificam o ambiente como AWS.

Um serviço de metadados de instância EC2 existe para que o software em uma máquina virtual possa aprender sobre seu ambiente de execução e obter credenciais temporárias associadas a uma função de identidade anexada. Esta é uma alternativa útil para armazenar chaves de acesso de longa duração em arquivos. O design pressupõe, no entanto, que o acesso da instância tem significado. Se um componente voltado para a web pode ser induzido a emitir requisições internas arbitrárias, "local à instância" não é mais equivalente a "código de carga de trabalho autorizado".

A explicação de 2019 da AWS sobre o IMDSv2 identifica o endereço de metadados como um endpoint link-local e explica que os metadados podem incluir credenciais temporárias para uma função anexada à instância. A Versão 2 exige que o software primeiro faça uma requisição HTTP PUT para estabelecer uma sessão e receber um token secreto, depois apresente esse token em requisições de metadados posteriores. A AWS projetou o protocolo para adicionar resistência contra firewalls de aplicação web abertos comuns, proxies reversos abertos, fraquezas SSRF e certos erros de firewall de camada 3 ou tradução de endereço de rede.

Os clientes podiam exigir a versão 2 ou desabilitar completamente o acesso a metadados.

O ponto analítico importante não é que uma revisão de protocolo prova retroativamente um defeito, nem que uma configuração do cliente absolve o projetista da plataforma de toda responsabilidade de design. É que uma suposição de confiança local pode ser fortalecida em mais de uma camada. A Capital One poderia restringir o WAF, restringir a saída para o endpoint de metadados, limitar a função, reduzir o armazenamento acessível, detectar uso incomum da API e reduzir os dados retidos. A AWS poderia tornar o protocolo de metadados menos reutilizável através de proxies transparentes e caminhos SSRF.

A defesa em profundidade reconhece que um erro de aplicação não deve automaticamente amadurecer em uma credencial de identidade e que uma credencial de identidade não deve automaticamente amadurecer em uma grande exportação de dados.

O firewall de aplicação web não foi toda a violação

Chamar o incidente de uma configuração incorreta de firewall pode ocultar três questões separadas. Primeiro, por que uma requisição não confiável poderia fazer com que o firewall ou um componente atrás dele alcançasse um destino interno? Segundo, que identidade foi exposta quando isso aconteceu? Terceiro, o que essa identidade podia fazer?

A primeira é uma questão de aplicação e caminho de rede. Um firewall de aplicação web é geralmente entendido como um controle que filtra entrada hostil antes que ela alcance uma aplicação. Neste incidente, a configuração relevante o tornou parte da rota para recursos internos. Essa inversão deve mudar a forma como as equipes de nuvem testam os controles de borda. Um WAF não é apenas um conjunto de regras no perímetro público; é código com um contexto de execução, acessibilidade de saída, cabeçalhos, métodos e uma identidade anexada.

A revisão de segurança deve perguntar o que o controle pode alcançar e personificar quando ele próprio é confundido.

A segunda questão diz respeito às credenciais de metadados. As credenciais temporárias são mais seguras do que as chaves de longa duração incorporadas de maneiras importantes: elas giram, expiram e podem ser centralmente associadas a uma função. Mas "temporário" descreve duração, não privilégio. Se um atacante pode recuperar repetidamente uma credencial atual, ou pode usar uma credencial durante sua janela válida para copiar um grande conjunto de dados, a rotação não impede o dano. A higiene de credenciais deve, portanto, incluir o caminho pelo qual a credencial é emitida e as permissões que ela carrega.

A terceira questão é o menor privilégio. A acusação alegou que as contas obtidas tinham a permissão necessária para listar e copiar o armazenamento visado. A ordem de arquivamento do tribunal civil de setembro de 2020 registra, como uma alegação aceita para aquela fase processual, a descrição da Amazon de uma configuração incorreta de firewall de camada de aplicação agravada por permissões que eram provavelmente mais amplas do que o pretendido. A ordem também registra as alegações dos autores sobre acesso ao armazenamento e a um data lake. Essas passagens não são conclusões de julgamento.

Ainda são úteis porque a disposição do tribunal mostra que uma intrusão criminal não necessariamente rompeu a alegada cadeia causal entre decisões de segurança e dano ao consumidor como questão de direito.

Uma revisão eficaz evitaria, portanto, encerrar com "o WAF foi corrigido". Ela reconstruiria o grafo de privilégio completo: requisição pública para proxy; proxy para endpoint de metadados; endpoint de metadados para sessão de função; função para listagem de armazenamento; listagem de armazenamento para leitura de objeto; leitura de objeto para caminho de descriptografia; chamada de API para saída de rede. Cada aresta precisa de um proprietário, uma justificativa de negócio, controles preventivos e telemetria. Remover uma regra defeituosa interrompe a rota conhecida. Não estabelece que a arquitetura de identidade e dados era proporcional.

A criptografia protegeu a mídia, não o uso indevido autorizado

A Capital One disse que criptografou dados como prática padrão e tokenizou campos selecionados, notadamente números de Seguro Social e de contas. Também disse que as circunstâncias permitiram a descriptografia dos dados acessados, enquanto os dados tokenizados permaneceram protegidos porque a tokenização usava um método e chaves diferentes. Esta é uma correção importante para uma alegação comum de que "os dados estavam criptografados" resolve a questão de controle.

A criptografia em repouso é projetada principalmente para proteger dados quando a mídia de armazenamento, snapshots ou armazenamento subjacente são acessados fora do caminho de serviço autorizado. As aplicações ainda precisam ler dados. Os sistemas de armazenamento em nuvem e gerenciamento de chaves, portanto, descriptografam informações para identidades que satisfazem a política. Se o atacante adquirir uma credencial com a mesma autoridade de leitura que a carga de trabalho, a criptografia pode operar exatamente como projetada enquanto libera texto simples para um humano não autorizado usando uma identidade de máquina autorizada.

Isso não é um argumento contra a criptografia. É um argumento para separar autoridades. Uma função exposta a um controle voltado ao público não deve carregar permissões amplas de leitura de dados e uso de chaves. Campos altamente sensíveis devem ser tokenizados ou criptografados sob um limite de serviço que a identidade leitora de armazenamento geral não pode cruzar. As políticas de chave, políticas de dados e políticas de função devem ser revisadas como uma única decisão de autorização. Caso contrário, três configurações individualmente plausíveis podem se cruzar para conceder acesso que nenhum de seus proprietários pretendia.

O evento também mostra por que os relatórios de controle devem distinguir cobertura de consequência. "Cem por cento dos objetos criptografados" pode ser verdade enquanto o risco de confidencialidade permanece alto. Uma métrica mais útil para o conselho mostraria que proporção de objetos sensíveis pode ser lida por cada função de tempo de execução, quais identidades podem invocar descriptografia, se uma carga de trabalho voltada ao público aparece nesses caminhos e com que frequência uma função lê fora de seu prefixo, volume, região ou padrão de tempo normal.

A detecção falhou antes que a resposta tivesse sucesso

O programa de divulgação responsável da Capital One funcionou depois que uma pessoa externa o usou. A empresa disse que recebeu um relatório em 17 de julho, confirmou a violação em 19 de julho, corrigiu o problema, contatou o FBI, anunciou o incidente em 29 de julho e apoiou uma prisão rápida. Esses são fatos de resposta significativos. Eles não respondem por que o sistema de controle interno não trouxe a atividade de março à resolução.

As conclusões do OCC abordam essa lacuna em um nível mais alto. Na ordem de consentimento de multa civil, o Controlador concluiu que a Capital One não havia estabelecido gerenciamento adequado de riscos de nuvem, incluindo controles adequados de prevenção de perda de dados e disposição eficaz de alertas. A Capital One não admitiu nem negou essas conclusões. "Disposição" é mais do que gerar um alerta. É o processo que determina se um evento é benigno, escalado, contido ou encerrado com evidências.

Os ambientes de nuvem geram telemetria abundante: assunção de função, uso de metadados, listagem de armazenamento, leituras de objeto, endereços de origem de API, volume de saída, chamadas negadas, alterações de política e eventos de classificação de dados. Mais sinais não criam automaticamente detecção. Um programa pode coletar todos os eventos relevantes e ainda falhar se as regras não correlacionarem a sequência, se os limites forem insensíveis ao comportamento normal de uma função, se os alertas não tiverem um proprietário responsável ou se as razões de encerramento não forem revisadas independentemente.

O fato de que um relatório externo levou à descoberta deve ser registrado tanto como um sucesso de resposta quanto como uma falha de garantia. O sucesso é que o canal existia, era monitorado e permitia ação. A falha é que um caminho de acesso de quatro meses era descobrível através de atividade pública antes que os próprios controles do banco produzissem contenção final. A divulgação responsável é um sensor externo valioso. Não deve ser contada como um substituto para a detecção interna de recuperação de credenciais, enumeração incomum de buckets e cópia de grandes objetos.

O OCC tratou a violação como uma falha de governança de migração

O registro mais forte de responsabilidade pública não é uma autópsia técnica. É o pacote de execução de 2020 do OCC. O anúncio da penalidade da agência diz que o banco não estabeleceu processos eficazes de avaliação de risco antes de mover operações significativas de tecnologia para a nuvem pública e não corrigiu deficiências em tempo hábil. A agência impôs uma multa de US$ 80 milhões, creditou a notificação e remediação do banco e afirmou que a inovação responsável ainda requer gerenciamento de risco sólido e controles internos.

As conclusões de consentimento são extraordinariamente específicas. O OCC concluiu que em ou por volta de 2015 o banco não estabeleceu avaliação de risco eficaz antes da migração. Constatou deficiências no design e implementação de controle de segurança de rede, prevenção de perda de dados e disposição de alertas. Constatou que a auditoria interna não identificou numerosas fraquezas e lacunas de controle, não relatou eficazmente as fraquezas identificadas ao Comitê de Auditoria e que o conselho não tomou medidas eficazes para responsabilizar a administração por certas preocupações levantadas pela auditoria.

A Capital One concordou com a ordem para evitar o custo de procedimentos e expressamente não admitiu nem negou as conclusões.

Esse enquadramento muda a unidade de responsabilidade. Se o evento fosse uma regra WAF ruim criada em 2019, a remediação poderia se concentrar no engenheiro, na revisão de mudança e no controle imediato. Se a falha relevante começou com um modelo operacional inadequadamente avaliado em 2015, o sistema responsável inclui governança de migração, design de controle de nuvem, desafio de segunda linha, auditoria interna, relatórios de comitê, remediação de gestão e escalação ao conselho.

A ordem de cessação e desistência do OCC tornou esse perímetro mais amplo operacional. Exigiu um comitê de conformidade de pelo menos três diretores, planos de ação corretiva por escrito, melhorias na avaliação de risco de tecnologia, gerenciamento de risco de operações em nuvem, gerenciamento de risco independente, testes de controle e auditoria interna. O plano de nuvem tinha que abordar segurança de perímetro, identificação e proteção de informações sensíveis, prevenção e detecção de divulgação não autorizada e gerenciamento de configuração para objetos conteinerizados.

O gerenciamento de risco independente tinha que definir um universo abrangente de risco e controle e desafiar a avaliação de primeira linha do risco cibernético inerente e residual.

Os requisitos de teste de controle da ordem são especialmente importantes. A Capital One teve que desenvolver um inventário de controles de nuvem relevantes, reconciliar um plano de teste baseado em risco com esse inventário, rastrear lacunas, remediá-las ou aceitar formalmente o risco.

A auditoria interna teve que validar a completude e precisão do inventário de gestão de ativos de tecnologia, dispositivos configuráveis e software; mapear seu universo de auditoria para preocupações de exame; incorporar lições da análise de causa raiz da violação; revisar a cobertura de auditoria; avaliar a expertise da equipe; e melhorar os relatórios ao Comitê de Auditoria.

Essas obrigações respondem a um erro recorrente de governança de nuvem. Uma empresa pode ter um catálogo de controle e um plano de auditoria, mas faltar uma relação confiável entre eles. O catálogo de controle contém o que a administração acredita existir. O inventário de ativos contém o que as equipes acreditam operar. O universo de auditoria contém o que a auditoria espera revisar. Se esses conjuntos não forem reconciliados, uma função voltada ao público, um caminho de metadados, um bucket de armazenamento ou um motor de configuração pode ficar entre os modelos de propriedade.

A ordem do OCC exigia evidências de que os conjuntos estão alinhados.

A responsabilidade do conselho é evidência, não frequência de reuniões

A declaração de procuração de 2020 da Capital One diz que a administração reportou prontamente o incidente ao conselho após a descoberta em 19 de julho. Membros independentes de vários comitês e o conselho pleno reuniram-se mais de 20 vezes sobre o incidente e a resposta. O conselho contratou especialistas externos, recebeu relatórios sobre causa raiz e remediação, aumentou a supervisão e atribuiu ao Comitê de Risco o papel principal na revisão da governança cibernética aprimorada. A administração estabeleceu um comitê sênior para questões cibernéticas empresariais e escalação.

Essas são respostas legítimas de governança, mas a contagem de reuniões não pode provar que um controle funciona. As conclusões do OCC focaram no período anterior à violação, quando as fraquezas de auditoria supostamente não foram eficazmente trazidas à superfície e a administração não foi responsabilizada por algumas lacunas abertas. A comparação útil não é, portanto, "poucas reuniões antes, muitas depois". É se a informação que chega aos diretores mudou de relatórios de atividade para evidências de controle.

A ordem do OCC definiu o que essa evidência deve apoiar. Os diretores foram obrigados a garantir ação corretiva oportuna, verificar se as ações eram eficazes, garantir pessoal e sistemas suficientes, responsabilizar a administração, exigir relatórios adequados e oportunos e abordar o não cumprimento. O conselho podia confiar na administração, comitês e terceiros, mas a confiança não removia o dever de garantir ação corretiva.

Para um risco de metadados e armazenamento em nuvem, um pacote de qualidade para o conselho deve responder a perguntas concretas. Quantas cargas de trabalho acessíveis pela internet podem acessar metadados de instância? Quantas exigem o protocolo de sessão mais forte? Quais podem desabilitar metadados completamente? Quantas funções voltadas ao público podem listar ou ler armazenamentos de objetos sensíveis? Qual é o volume máximo de dados que cada função pode recuperar em uma vida útil de credencial? Quais controles impedem que dados saiam de uma rede ou região aprovada? Quantos alertas foram encerrados sem evidências corroborativas?

Quais questões de auditoria de nuvem perderam datas alvo, e qual executivo aceitou o risco residual?

Nenhuma dessas perguntas pede que os diretores configurem um firewall. Elas perguntam se a administração pode demonstrar o limite operacional que afirma. Essa é a distinção entre administração e supervisão. Os diretores não precisam conhecer cada parâmetro de API, mas precisam de um sistema de relatórios que torne combinações perigosas visíveis antes que um pesquisador externo o faça.

Responsabilidade compartilhada é um mapa de controle, não uma isenção de responsabilidade

A AWS descreve a segurança em nuvem como compartilhada entre provedor e cliente. Sob o modelo de responsabilidade compartilhada da AWS, a AWS protege a infraestrutura que executa os serviços de nuvem, enquanto os deveres do cliente variam com a seleção de serviço e geralmente incluem dados do cliente, identidade e acesso, software de aplicação, configuração do sistema operacional, configuração de firewall, escolhas de criptografia e proteção de tráfego. Para um serviço de infraestrutura como EC2, o cliente controla substancialmente mais da pilha operacional do que em um serviço totalmente gerenciado.

O modelo é útil porque impede um erro de categoria: alugar computação não torna o provedor o operador das permissões de aplicação do cliente. Mas o diagrama é apenas o início da governança. Muitos controles importantes cruzam a linha. O provedor projeta o serviço de metadados; o cliente decide se e como usá-lo. O provedor fornece mecanismos de política de identidade; o cliente define funções e permissões. O provedor produz logs; o cliente os habilita, retém, roteia e investiga. O provedor oferece escolhas de região; o cliente seleciona regiões e arquiteturas que satisfazem obrigações legais.

O provedor torna padrões mais seguros possíveis; o cliente deve migrar cargas de trabalho existentes e aplicá-los.

A declaração de computação em nuvem do FFIEC torna explícita a consequência do setor financeiro. A administração não deve assumir que os controles de segurança e resiliência existem simplesmente porque os sistemas operam em um ambiente de nuvem. A declaração diz que os contratos devem identificar as responsabilidades das partes, mas as instituições financeiras permanecem responsáveis pela operação segura e sólida e conformidade. Destaca governança, arquitetura de nuvem, identidade, gerenciamento de dados, gerenciamento de vulnerabilidades, monitoramento, resposta a incidentes, continuidade de negócios e auditoria como práticas conectadas.

A responsabilidade compartilhada, portanto, tem que ser traduzida em uma matriz de controle precisa o suficiente para testar. Para cada controle, a matriz deve identificar quem o projeta, quem o configura, quem o opera, quem recebe um alerta, quem valida a eficácia, que evidência é retida e quem age quando a evidência está faltando. Um rótulo como "responsabilidade do cliente" não é um proprietário de controle. Em um grande banco, "cliente" pode significar engenharia de plataforma, equipes de aplicação, segurança de nuvem, governança de dados, engenharia de identidade, risco empresarial, auditoria interna, jurídico ou um fornecedor.

A ambiguidade dentro da organização do cliente pode ser mais perigosa do que a ambiguidade entre cliente e provedor.

Nem um diagrama de responsabilidade compartilhada decide responsabilidade civil. Termos contratuais, representações, design técnico, obrigações de notificação, causalidade, lei estadual e fatos provados são todos importantes. O modelo pode guiar a operação esperada, mas não é uma alocação judicial de culpa e não deve ser apresentado a um conselho como se fosse uma indenização.

Responsabilidade criminal, responsabilidade regulatória e exposição civil

O registro público suporta várias formas de responsabilidade, cada uma com um status legal diferente.

A responsabilidade criminal é a mais clara. O anúncio de sentença do Departamento de Justiça afirma que um júri federal considerou Thompson culpada de fraude eletrônica, cinco acusações de acesso não autorizado a um computador protegido e dano a um computador protegido. Os promotores mostraram que ela escaneou contas de nuvem em busca de configurações incorretas, usou-as para obter dados e poder computacional e acessou mais de 30 entidades. Ela foi condenada a tempo já cumprido e cinco anos de liberdade condicional. Essa conduta criminal adjudicada não deve ser suavizada em uma descoberta acidental.

A responsabilidade regulatória focou no banco. A ordem de penalidade do OCC é uma ordem de consentimento final, mas a Capital One não admitiu nem negou as conclusões do Controlador. O anúncio de execução coordenada do Federal Reserve disse que a holding tinha que aprimorar o gerenciamento de risco, governança, segurança cibernética e controles de segurança da informação. A ordem de consentimento do Federal Reserve exigiu que o conselho controlador usasse seus recursos para garantir que os bancos cumprissem as ordens do OCC e submetesse um plano escrito para supervisão do conselho.

A exposição civil foi mais ampla, mas menos conclusiva sobre a culpa final. Os consumidores processaram a Capital One e a Amazon sob teorias de negligência, contrato, enriquecimento ilícito, notificação e proteção ao consumidor. Em setembro de 2020, o tribunal distrital deferiu algumas partes das moções de arquivamento dos réus e indeferiu outras. A maioria das reivindicações de negligência sobreviveu, enquanto as reivindicações de negligência de Washington e várias teorias de negligência per se foram arquivadas. O tribunal concluiu naquela fase que a conduta criminal de Thompson não necessariamente suplantava a suposta negligência dos réus.

Como uma moção de arquivamento aceita alegações bem formuladas como verdadeiras, a decisão estabeleceu que as reivindicações podiam prosseguir; não estabeleceu que a Capital One ou a Amazon haviam cometido os atos alegados.

O caso terminou em acordo em vez de julgamento de mérito. A ordem de aprovação final aprovou um fundo não reversionário de US$ 190 milhões, serviços de defesa e restauração de identidade e compromissos de práticas de negócios. O acordo resolveu reivindicações contra a Capital One e a Amazon. A aprovação significou que o tribunal considerou a resolução negociada justa, razoável e adequada sob as regras de ação coletiva. Não alocou uma porcentagem de responsabilidade pela violação entre o banco, a AWS e o atacante.

Essa distinção é importante porque a frase "quem foi responsável?" pode convidar uma resposta falsa. Thompson foi condenada por atos criminosos. A Capital One incorreu em sanções regulatórias com base em conclusões de consentimento e aceitou deveres corretivos. A Capital One e a Amazon enfrentaram reivindicações civis que sobreviveram em parte e foram resolvidas. As mudanças de design posteriores do provedor são relevantes para a prevenção, mas não são admissões de culpa legal. Cada afirmação tem uma fonte e uma postura processual. Combiná-las em um veredito generalizado seria impreciso.

IMDSv2 e a governança de padrões mais seguros

A AWS introduziu o IMDSv2 em novembro de 2019, menos de quatro meses após a Capital One divulgar a violação. O aviso de lançamento da AWS o descreveu como defesa em profundidade contra acesso não autorizado a metadados. Os clientes podiam exigir o método de requisição aprimorado em instâncias novas ou existentes ou desligar o acesso a metadados. A Versão 1 permaneceu disponível para compatibilidade.

O token de sessão do IMDSv2 cria atrito contra vários caminhos de representante confuso. Um proxy que encaminha requisições GET simples pode não permitir o PUT inicial. Um proxy reverso que insere um cabeçalho de encaminhamento pode ser rejeitado para criação de token. Um token está vinculado à instância e não pode ser simplesmente reproduzido de uma máquina arbitrária. Limites de hop podem restringir até onde uma resposta de metadados viaja através de camadas de rede. Esses são controles de protocolo valiosos porque reduzem a consequência de erros de aplicação e proxy.

Eles não removem a necessidade do menor privilégio. Se código hostil realmente executa em uma instância, ele pode ser capaz de realizar a troca de token assim como o código legítimo. Se um SSRF vulnerável permitir métodos e cabeçalhos arbitrários, a proteção pode ser menos completa. Se a função anexada pode ler um data lake desnecessário, a consequência residual permanece alta. O endurecimento de metadados é, portanto, uma camada em uma sequência, não um substituto para design de função, controle de saída, segmentação de dados e monitoramento.

Os padrões também têm uma dimensão temporal. Em 2019, os clientes tiveram que escolher e aplicar o método mais forte depois que ele se tornou disponível. A AWS posteriormente anunciou um roteiro de IMDSv2 por padrão que moveu inícios rápidos do console e tipos de instância recém-lançados em direção à versão 2, enquanto mantinha opções de compatibilidade. Essa progressão ilustra um dilema de governança de plataforma. Mudança obrigatória imediata pode quebrar software existente; opcionalidade prolongada deixa suposições antigas em vigor.

Os provedores devem tornar a migração mensurável, fornecer aplicação no nível da conta, expor o uso restante da versão 1 e definir uma direção clara. Os clientes devem tratar as atualizações de segurança opcionais como decisões de risco com proprietários e prazos, não como backlog de funcionalidades.

Para os conselhos, a lição é perguntar sobre a dívida de padrões. Quantas cargas de trabalho ainda dependem de um modo de metadados legado? Por quê? O que quebraria se fosse desabilitado? Quais aplicações não podem tolerar um limite de hop mais baixo? Qual política organizacional impede novas exceções? Como a empresa sabe se uma conta adquirida ou ambiente de desenvolvimento não se desviou? Um recurso seguro que está disponível mas não medido produz menos garantia do que um programa de migração vinculado a inventário e aplicação.

A localidade dos dados não conteve o acesso lógico

A violação afetou pessoas em ambos os lados da fronteira EUA-Canadá. O Office of the Privacy Commissioner of Canada abriu uma investigação após a Capital One relatar que seis milhões de canadenses foram afetados, incluindo alguns cujos Números de Seguro Social foram acessados. A página de incidente canadense da Capital One forneceu avisos e suporte específicos do país. O impacto transfronteiriço transforma a localidade de uma questão abstrata de aquisição de nuvem em uma questão de responsabilidade.

As fontes revisadas aqui não estabelecem a região exata da AWS de cada objeto afetado, nem mostram que os registros canadenses foram mantidos em uma região canadense separada. Essa ausência deve ser preservada. Seria irresponsável inferir uma localização de armazenamento a partir da nacionalidade de um titular de dados ou de uma marca global de nuvem. O que o registro estabelece é que um incidente afetou grandes populações governadas por diferentes sistemas legais e regulatórios.

A AWS diz em seus materiais de privacidade de dados que os clientes controlam o conteúdo do cliente e que os deveres do provedor e do cliente seguem o modelo de responsabilidade compartilhada. Sua estrutura atual de soberania digital enfatiza a escolha do cliente sobre onde as cargas de trabalho são executadas, acesso a dados, resiliência e controle. Essas capacidades são relevantes, mas uma seleção de região não é um resultado completo de soberania.

A localidade responde onde um serviço é configurado para armazenar ou processar dados sob operação normal. A segurança também deve responder quem pode fazer o serviço divulgá-lo, onde as credenciais podem ser exercidas, para onde logs e backups vão, como o acesso de suporte é controlado e se os dados exportados podem cruzar o limite selecionado. Na cadeia da Capital One, uma credencial de API foi mais consequente do que a proximidade física a um disco. Uma vez que uma função foi aceita como autorizada, o armazenamento podia entregar objetos através da interface de serviço.

Uma região doméstica não teria, por si só, impedido esse caminho lógico.

Os controles de soberania precisam, portanto, de pelo menos quatro camadas. A primeira é o posicionamento: regiões aprovadas, configurações de replicação, backups, análises, recuperação de desastres e serviços de suporte. A segunda é a autoridade: identidades, uso de chaves, acesso a metadados e políticas que restringem chamadas por rede, conta, organização ou região. A terceira é a observabilidade: logs retidos em uma conta controlada independentemente, evidência de transferências entre regiões, alertas para locais de origem incomuns e registros disponíveis para reguladores relevantes.

A quarta é a saída e continuidade: a capacidade de exportar dados e logs em forma utilizável, revogar o acesso do provedor, girar chaves e operar um acordo de recuperação testado se uma região, provedor ou mecanismo de transferência legal se tornar indisponível.

O incidente também mostra que a geografia do titular dos dados pode ser importante mesmo quando a geografia da infraestrutura é incerta. Reguladores canadenses, indivíduos afetados, práticas de notificação e necessidades de remediação de identidade não desapareceram porque a Capital One está sediada nos Estados Unidos. Um programa de nuvem multinacional deve mapear conjuntos de dados para as pessoas e obrigações que representam, não apenas para a conta e região nas quais os engenheiros os veem.

A retenção transformou um caminho de acesso em um dossiê histórico

A Capital One disse que a maior categoria afetada incluía dados de aplicação de 2005 até o início de 2019. Esse intervalo altera a análise de risco. Uma solicitação de crédito tem um propósito imediato: avaliar elegibilidade, cumprir a lei, prevenir fraude e estabelecer uma conta. Com o tempo, algumas informações podem permanecer necessárias para manutenção, retenções legais, deveres regulatórios, governança de modelos, resolução de disputas ou análise de fraude. Mas a necessidade deve ser demonstrada por campo, propósito e período.

A retenção é frequentemente tratada como um cronograma de privacidade separado da segurança em nuvem. A violação mostra por que essa separação é artificial. A quantidade e idade dos dados acessíveis por uma função comprometida determinam o impacto. Um cronograma de exclusão perfeito não pode impedir um atacante de ler registros atuais, mas pode impedir que um evento de credencial exponha catorze anos de histórico de aplicação. Da mesma forma, classificar um campo como sensível tem pouco efeito se nenhuma política de armazenamento, limite de chave, função de acesso ou trabalho de exclusão mudar por causa da classificação.

O controle apropriado não é simplesmente "excluir dados antigos". É um ciclo de vida defensável: identificar o propósito da coleta; especificar a base legal e comercial para retenção; separar dados operacionais ativos de arquivos restritos; minimizar campos; tokenizar identificadores duráveis; aplicar exclusão; preservar apenas registros sujeitos a uma exceção documentada; e testar se os dados excluídos também saem de réplicas, conjuntos de dados derivados, caches, snapshots e cópias de desenvolvimento. Toda exceção deve ter um proprietário e revisão de expiração.

A arquitetura de dados também deve reduzir a agregação. Uma única função não deve ganhar acesso a um amplo corpus histórico apenas porque um trabalho de processamento um dia precisou dele. A partição por propósito, sensibilidade, período de tempo e jurisdição dá à política de acesso algo significativo para aplicar. Sem esses limites, o menor privilégio é forçado a operar no nível de um bucket ou data lake muito grande, e a diferença entre "pode executar esta aplicação" e "pode ler o histórico desta instituição" torna-se perigosamente pequena.

A dependência de nuvem inclui dependência de evidência

A Capital One não estava simplesmente alugando discos remotos. Como qualquer grande cliente de nuvem, dependia de semânticas de identidade definidas pelo provedor, comportamento de metadados, registro de API, construções de região, controles de armazenamento, disponibilidade de serviço, documentação e capacidade do provedor de preservar e explicar evidências. Essa é uma dependência mais ampla do que uptime.

O incidente de 2019 não causou uma interrupção pública prolongada dos serviços bancários principais da Capital One. A questão de continuidade foi confidencialidade e confiança. A empresa teve que investigar um grande ambiente de nuvem, identificar registros afetados, notificar pessoas em dois países, trabalhar com aplicação da lei e reguladores, fornecer monitoramento, defender litígios e remediar controles enquanto continuava operando.

Isso é continuidade sob evidência comprometida: os serviços podem permanecer disponíveis enquanto a instituição deve determinar se seus registros, processos de identidade e comunicações com clientes ainda podem ser confiados.

O Formulário 10-K de 2019 da Capital One relatou US$ 72 milhões em despesas incrementais de resposta e remediação de 2019, compensados por US$ 34 milhões em recuperações de seguro. A empresa esperava estar no extremo inferior de sua faixa anteriormente anunciada de US$ 100 milhões a US$ 150 milhões para itens de ajuste total do incidente, com alguns custos se estendendo além de 2019. Ela alertou sobre intervenção regulatória, litígios, custos de remediação, danos à reputação e perda de confiança.

Esses números precederam a multa de US$ 80 milhões do OCC e o posterior fundo de acordo coletivo de US$ 190 milhões, e não devem ser somados casualmente porque seguro, timing, escopo do acordo e tratamento contábil diferem.

A dependência de evidência deve ser planejada contratual e tecnicamente. Um cliente regulado precisa de logs com campos e retenção adequados, notificação pronta de eventos do provedor, cooperação com coleta forense, deveres de preservação, informações de região e subprocessador, acesso a relatórios de controle, comunicação de vulnerabilidades e um processo para solicitações de governo e reguladores. Também precisa de sua própria cópia de logs críticos em uma conta de segurança que a carga de trabalho comprometida não pode alterar.

Um painel do provedor que diz que o serviço operou normalmente não estabelece que as identidades do cliente foram devidamente escopadas.

O planejamento de saída pertence ao mesmo pacote. Concentrar dados e políticas de identidade em um provedor pode melhorar a padronização e visibilidade, mas também pode dificultar a migração. Um teste de saída deve medir quanto tempo leva para inventariar dados, reproduzir políticas de acesso, exportar chaves ou re-criptografar, transferir logs, reconstruir detecção, satisfazer restrições de localidade e provar exclusão no provedor antigo. A implantação multi-nuvem não é automaticamente mais segura; duplicar controles imaturos pode dobrar a incerteza.

O objetivo é portabilidade credível de dados e evidências, não contagem decorativa de provedores.

O que os acordos resolveram, e o que deixaram em aberto

O acordo de consumidores é substancial, mas seu significado deve ser declarado com cuidado. O acordo criou um fundo de US$ 190 milhões para perdas reembolsáveis elegíveis, tempo perdido, serviços de defesa de identidade, serviços de restauração, aviso e administração e honorários aprovados pelo tribunal. Também incluiu compromissos de práticas de negócios. A ordem de aprovação final considerou o acordo justo, razoável e adequado e arquivou as reivindicações de consumidores liberadas com prejuízo.

O acordo não estabeleceu que toda alegação na queixa alterada era verdadeira. Não converteu o histórico da moção de arquivamento em conclusões após evidência. Não determinou que o design de metadados da AWS causou uma porcentagem especificada do dano ou que a configuração da Capital One causou o restante. Não apagou a responsabilidade criminal de Thompson, e não substituiu as conclusões e ordens regulatórias separadas do OCC.

Essa alocação não resolvida é em si uma lição de governança. As empresas não podem esperar que um tribunal atribua uma porcentagem limpa antes de melhorar um controle compartilhado. Um provedor de plataforma pode não ter responsabilidade adjudicada e ainda adicionar um protocolo mais seguro. Um cliente pode contestar as conclusões do regulador e ainda aceitar uma ordem e reformar os controles. Um conselho pode reservar defesas legais enquanto trata os fatos operacionais como urgentes. A postura legal e a postura de remediação podem diferir sem contradição.

O OCC posteriormente anunciou que encerrou a ordem de cessação e desistência de 2020 em 31 de agosto de 2022. O encerramento é um ponto final importante para essa ordem específica. Não cancela a penalidade, reescreve as conclusões históricas ou prova que o risco de nuvem se tornou estático. Indica que a ordem formal não estava mais pendente. Um conselho maduro deve converter o inventário de controle, teste, auditoria e disciplinas de relatório da ordem em governança normal, em vez de deixá-los expirar com a supervisão regulatória.

Um pacote de evidências para risco de metadados, identidade e localidade

O registro da Capital One suporta um pacote de evidências prático para organizações que executam cargas de trabalho sensíveis em nuvem pública.

Mapeie caminhos públicos para autoridade interna.Inventarie cada proxy, balanceador de carga, WAF, gateway de API e aplicação acessível pela internet. Para cada um, mostre destinos de saída, acessibilidade de metadados, identidades anexadas, métodos e cabeçalhos permitidos e a autoridade máxima de dados acessível através dessa identidade. Teste o caminho de uma perspectiva de atacante, não apenas contra o diagrama de arquitetura pretendido.

Torne a postura de metadados mensurável.Registre se os metadados são necessários, se podem ser desabilitados, qual versão do protocolo é exigida, o limite de hop, restrições locais de firewall, implicações de contêiner e chamadas legadas observadas. Aplique o estado preferido no nível da organização ou conta. Exceções devem identificar o software dependente, proprietário do risco, controles compensatórios e data de remoção.

Calcule o raio de explosão da credencial.Para cada função de tempo de execução, enumere prefixos de armazenamento, bancos de dados, filas, segredos, operações de chave e ações administrativas que ela pode alcançar. Estime quantos dados sensíveis poderiam ser lidos dentro de uma vida útil de credencial e a partir de quais locais de rede. Teste permissões efetivas, incluindo a interseção de políticas de identidade, recurso, chave, endpoint e organização.

Separe o acesso ao armazenamento da autoridade de descriptografia.A criptografia não deve entrar em colapso na mesma função que é exposta através do caminho da aplicação. Use tokenização ou um serviço distinto para campos de identidade duráveis. Alerte quando uma identidade voltada ao público invocar operações de chave ou ler uma classe de dados fora de seu propósito restrito.

Controle dados por propósito e jurisdição.Etiquete e particione dados de acordo com sensibilidade, propósito, período de retenção e população afetada. Aplique regiões aprovadas para armazenamento primário, réplicas, análises, backups e recuperação. Registre qualquer serviço que necessariamente mova conteúdo ou dados de suporte. Teste a negação entre regiões e contas, não apenas a localização configurada.

Possua a trilha de auditoria.Roteie eventos de identidade, metadados, armazenamento, chave, rede e perda de dados para um ambiente de registro administrado independentemente. Proteja logs de funções de carga de trabalho. Correlacione recuperação de credenciais, operações de lista, leituras de objeto, descriptografia e saída. Meça se os alertas são investigados até uma conclusão evidenciada, não apenas se são gerados.

Reconcile o universo de controle.O catálogo de controle de nuvem da administração, inventário de ativos, inventário de configuração, catálogo de dados, registro de risco e universo de auditoria devem ter identificadores comuns. A auditoria interna deve testar a completude em vez de amostrar apenas da lista da administração. Ativos e controles não correspondentes devem ser relatados como cobertura desconhecida.

Escale achados repetidos e vencidos.Uma lacuna de configuração com uma data de remediação perdida deve aparecer ao lado dos caminhos de identidade e dados que deixa expostos. Os relatórios ao conselho devem nomear o executivo responsável, controles compensatórios, método de validação e prazo. O encerramento deve exigir evidência independente de que a condição de risco mudou.

Exercite a resposta transfronteiriça.Um exercício de violação deve identificar quais populações e reguladores estão implicados, quais registros mostram localização e acesso, como os avisos específicos do país serão entregues e como a restauração de identidade funciona para diferentes identificadores governamentais e sistemas de crédito. A organização deve ser capaz de explicar onde os dados afetados estavam armazenados sem reconstruir a resposta durante a crise.

Preserve a cooperação do provedor e direitos de saída.Contratos e procedimentos operacionais devem garantir acesso oportuno a logs, suporte forense, aviso de incidente, preservação de evidências, compromissos de região, transparência de subprocessadores e certificação de exclusão. As equipes devem testar periodicamente a exportação de dados, políticas, chaves e evidências de auditoria para um ambiente de recuperação utilizável.

Este pacote é exigente porque o risco é combinatório. O WAF pode atender sua linha de base. O serviço de metadados pode operar como documentado. A função pode ter uma razão de negócio. O bucket pode ser privado. Os objetos podem estar criptografados. Os logs podem existir. No entanto, a interseção ainda pode permitir que uma requisição pública se torne uma exportação autorizada. A responsabilidade pertence às interseções.

O teste duradouro

A violação da Capital One continua sendo um caso útil de responsabilidade em nuvem porque resiste a duas histórias fáceis. A primeira diz que a nuvem pública causou a violação. Isso ignora a configuração controlada pelo cliente, permissões, arquitetura de dados, monitoramento e as conclusões diretas do OCC sobre o programa de risco de nuvem do banco. A segunda diz que a responsabilidade compartilhada colocou o assunto inteiramente no cliente. Isso trata um diagrama do provedor como o fim da análise de design e ignora o valor de defesas mais fortes do serviço de metadados, padrões mais seguros, telemetria do provedor e evidência contratual.

O melhor relato segue a cadeia. Um controle voltado ao público podia retransmitir uma requisição não intencional. A requisição alcançou um limite de confiança de metadados. A identidade temporária resultante tinha autoridade suficiente para listar e copiar informações armazenadas. A criptografia não impediu que uma credencial aceita como autorizada lesse dados. O monitoramento interno não produziu contenção oportuna. Um horizonte de retenção longo ampliou o corpus exposto. O mesmo evento alcançou pessoas sob regimes de privacidade dos EUA e Canadá.

A auditoria e os relatórios do conselho não forçaram a resolução das lacunas mais amplas de controle de nuvem identificadas pelo regulador.

A responsabilidade então se separou por foro. O atacante foi condenado. Os reguladores bancários impuseram obrigações de consentimento e uma multa à Capital One. Os consumidores processaram tanto a Capital One quanto a Amazon; as reivindicações sobreviveram em parte e foram resolvidas sem uma alocação de culpa em julgamento. A AWS introduziu um protocolo de metadados mais defensivo. A Capital One descreveu remediação, supervisão aprimorada do conselho e suportou custos substanciais de resposta, execução e acordo.

Para futuros conselhos, a questão decisiva não é se o provedor de nuvem é certificado, o bucket é criptografado ou a regra de firewall foi corrigida. É se a instituição pode provar que nenhum caminho não confiável pode obter uma identidade de carga de trabalho com autoridade desproporcional; que o uso incomum dessa identidade será detectado e resolvido; que os dados acessíveis são limitados por propósito, tempo e jurisdição; e que as evidências do provedor e do cliente podem ser unidas rápido o suficiente para governar o risco.

Essa prova é o significado prático da responsabilidade compartilhada. Sem ela, a responsabilidade é meramente dividida no papel enquanto o risco permanece conectado na produção.