La brecha de metadatos de Capital One: cuando la configuración en la nube se convirtió en una cadena de responsabilidades

Resumen

• Capital One informó que un individuo externo explotó una vulnerabilidad de configuración los días 22 y 23 de marzo de 2019. Los registros penales y regulatorios describen una cadena de control más larga: un firewall de aplicaciones web mal configurado permitió que comandos alcanzaran el entorno de nube, se obtuvieron credenciales para un rol, dichas credenciales pudieron enumerar y copiar objetos de almacenamiento, y la monitorización no convirtió la actividad sospechosa en una contención oportuna.
• La Oficina del Contralor de la Moneda (OCC) no caracterizó el evento como un error aislado de ingeniería. Sus conclusiones de consentimiento se remontaron a la migración a la nube del banco en 2015 e identificaron una evaluación de riesgos ineficaz, controles deficientes de seguridad de red y prevención de pérdida de datos, una mala gestión de las alertas, brechas en la auditoría interna y una acción ineficaz de la junta para exigir responsabilidades a la gerencia.
• La responsabilidad existió en varios planos sin hacerse legalmente intercambiable. Un jurado federal condenó a Paige Thompson por conducta delictiva. Capital One aceptó una multa de 80 millones de dólares de la OCC sin admitir ni negar las conclusiones de la agencia. Las demandas de los consumidores contra Capital One y Amazon sobrevivieron en parte en la fase de alegaciones y posteriormente se resolvieron, por lo que el caso civil no produjo una asignación de culpa en juicio entre el banco y el proveedor de nube.
• La lección sobre soberanía no es que seleccionar una región de nube nacional resuelva la protección de datos. Aproximadamente seis millones de personas en Canadá se vieron afectadas, incluidos cerca de un millón cuyos números de seguro social se vieron comprometidos. La localidad, la retención, los permisos de identidad, el acceso a metadatos, la autoridad de cifrado, el registro y el acceso del regulador a la evidencia deben gobernarse como un solo sistema.

Una filtración descrita de forma demasiado limitada

La versión habitual de la filtración de Capital One es breve: un firewall estaba mal configurado, un atacante accedió a datos en Amazon Web Services y se tomó información relacionada con más de 100 millones de personas. Cada parte de esa frase apunta en la dirección correcta. No obstante, como relato de responsabilidad, es demasiado limitado. Hace que el evento parezca un único error de configuración en el borde de un entorno por lo demás controlado.

El registro oficial describe algo más estructural. Elcomunicado del 29 de julio de 2019 presentado ante la SECindicó que la empresa determinó el 19 de julio que un individuo externo obtuvo información personal tras explotar una vulnerabilidad de configuración específica. Situó el acceso material no autorizado los días 22 y 23 de marzo, explicó que un informe de divulgación responsable llegó el 17 de julio y que la empresa corrigió la configuración y colaboró con las fuerzas de seguridad federales. También señaló que el modelo operativo en la nube ayudó a la empresa a diagnosticar y corregir el problema rápidamente una vez conocido.

Ese último punto es importante. Capital One no presentó la nube en sí como la causa. La empresa subrayó que los elementos de infraestructura relevantes pueden existir tanto en la nube como en instalaciones propias. La posición es técnicamente defendible: un proxy inverso o un firewall de aplicaciones web puede convertirse en un repetidor no deseado en cualquiera de los dos entornos; las credenciales de servicio pueden tener demasiados privilegios en ambos; una identidad legítima puede leer datos cifrados en ambos. Sin embargo, la nube cambia la velocidad, la abstracción y la escala a las que se combinan esas condiciones.

Un comando que cruza un límite de aplicación puede alcanzar un servicio de metadatos de instancia. Una credencial temporal puede ejercerse a través de una API desde otro lugar. Un rol de almacenamiento puede enumerar un lago de datos medido mucho más allá del disco de un servidor. La misma automatización que hace eficientes las operaciones en la nube puede hacer eficiente un error de permisos para un intruso.

Lapágina de información sobre el incidente de Capital Oneactualmente indica que aproximadamente 100 millones de personas en Estados Unidos y unos seis millones en Canadá se vieron afectadas. La mayor categoría de datos fue la información facilitada por consumidores y pequeñas empresas al solicitar productos de tarjeta de crédito desde 2005 hasta principios de 2019: nombres, direcciones, códigos postales, números de teléfono, direcciones de correo electrónico, fechas de nacimiento e ingresos declarados. Algunos datos de clientes de crédito incluían puntuaciones, límites, saldos, historial de pagos, datos de contacto y fragmentos de datos de transacciones de 23 días a lo largo de 2016, 2017 y 2018. La empresa informó de unos 140 000 números de Seguro Social estadounidenses, cerca de 80 000 números de cuentas bancarias vinculadas y aproximadamente un millón de números de Seguro Social canadienses entre los datos comprometidos. Señaló que los números de cuenta de tarjeta de crédito y las credenciales de inicio de sesión no se vieron comprometidos.

Esas distinciones evitan exageraciones, pero no reducen la cuestión del control a una cifra. Los datos de solicitud pueden seguir siendo sensibles desde el punto de vista de la identidad mucho después de una decisión crediticia. Los ingresos, el historial de direcciones, la fecha de nacimiento, el estado crediticio y los identificadores gubernamentales pueden combinarse entre sistemas. Por tanto, el evento no se refería solo a si un bucket era privado.

Se trataba de por qué un rol orientado a aplicaciones podía alcanzar el corpus almacenado, por qué una ruta de credenciales en un límite de metadatos local podía convertirse en una ruta de datos externa, por qué la monitorización no cerró la brecha y por qué los datos recopilados durante aproximadamente catorce años permanecían dentro del conjunto accesible.

La cronología y la forma cambiante de la rendición de cuentas

Las fechas cambian lo que una organización puede razonablemente esperar saber y hacer. La cronología básica puede extraerse de las divulgaciones de la empresa, la posterior acusación y condena, las órdenes regulatorias y los registros judiciales, sin tratar cada fuente como el mismo tipo de prueba.

La aparente discrepancia entre el 12 y el 22 de marzo no es una contradicción que deba forzarse en una sola fecha. Laacusación formal complementaria de 2021imputó un período más amplio de acceso informático no autorizado a partir del 12 de marzo aproximadamente. El comunicado de Capital One utilizó el 22 y 23 de marzo para el acceso a datos central de su relato del incidente. Una cronología debe preservar esa diferencia entre el curso de conducta imputado y la descripción de la empresa sobre la exfiltración.

La misma disciplina se aplica a las cifras de población. El comunicado inicial de la empresa mencionó aproximadamente 100 millones de personas afectadas en Estados Unidos y seis millones en Canadá. El administrador del acuerdo en EE. UU. describió posteriormente unos 98 millones de consumidores estadounidenses en la clase del acuerdo. Ninguna de las dos cifras debe convertirse silenciosamente en un recuento universal preciso. Pertenecen a registros diferentes, en etapas distintas, con definiciones diferentes.

Cómo el límite de metadatos se convirtió en un límite de credenciales

La cadena técnica comienza con la falsificación de solicitudes del lado del servidor, a menudo abreviada como SSRF. En una condición SSRF, un llamante externo induce a un componente del lado del servidor a realizar una solicitud elegida o influenciada por dicho llamante. La solicitud se realiza desde la posición de red del servidor, por lo que puede alcanzar destinos no disponibles directamente desde Internet público. El problema de seguridad no es simplemente que se aceptara una URL. Es que la aplicación se convierte en un delegado que transporta la intención de un extraño a un contexto de red más confiable.

Lapágina del caso Capital One del Departamento de Justiciadescribe la intrusión como ocurrida a través de un firewall de aplicaciones web mal configurado. La acusación formal complementaria, presentada antes del juicio, alegó que Thompson creó y utilizó escáneres para identificar clientes de nube cuyas configuraciones de firewall de aplicaciones web permitían que comandos externos llegaran y se ejecutaran en sus servidores. Alegó que esos comandos obtuvieron credenciales de seguridad para cuentas o roles de clientes; las credenciales se utilizaron luego para listar buckets de almacenamiento y copiar objetos para los cuales el rol tenía permiso. La acusación utilizó el término neutro «Empresa de Computación en la Nube», pero el registro civil público y los propios escritos de Capital One identifican el entorno como AWS.

Un servicio de metadatos de instancia EC2 existe para que el software en una máquina virtual pueda conocer su entorno de ejecución y obtener credenciales temporales asociadas a un rol de identidad adjunto. Esta es una alternativa útil a almacenar claves de acceso de larga duración en archivos. El diseño asume, sin embargo, que el acceso desde la instancia tiene significado. Si se puede hacer que un componente orientado a la web emita solicitudes internas arbitrarias, «local a la instancia» ya no equivale a «código de carga de trabajo autorizado».

Laexplicación de IMDSv2 de AWS de 2019identifica la dirección de metadatos como un endpoint de enlace local y explica que los metadatos pueden incluir credenciales temporales para un rol adjunto a la instancia. La versión 2 requiere que el software realice primero una solicitud HTTP PUT para establecer una sesión y recibir un token secreto, y luego presente ese token en solicitudes de metadatos posteriores. AWS diseñó el protocolo para añadir resistencia contra firewalls de aplicaciones web abiertos comunes, proxies inversos abiertos, debilidades SSRF y ciertos errores de firewall de capa 3 o de traducción de direcciones de red. Los clientes podían exigir la versión 2 o deshabilitar completamente el acceso a metadatos.

El punto analítico importante no es que una revisión de protocolo demuestre retroactivamente un defecto, ni que una configuración del cliente absuelva al diseñador de la plataforma de toda responsabilidad de diseño. Es que un supuesto de confianza local puede reforzarse en más de una capa. Capital One podía restringir el WAF, bloquear la salida al endpoint de metadatos, acotar el rol, limitar el almacenamiento accesible, detectar usos inusuales de la API y reducir los datos retenidos. AWS podía hacer que el protocolo de metadatos fuera menos reutilizable a través de proxies transparentes y rutas SSRF.

La defensa en profundidad reconoce que un error de aplicación no debería convertirse automáticamente en una credencial de identidad y que una credencial de identidad no debería convertirse automáticamente en una gran exportación de datos.

El firewall de aplicaciones web no fue toda la filtración

Llamar al incidente una mala configuración del firewall puede ocultar tres preguntas separadas. Primero, ¿por qué podía una solicitud no confiable hacer que el firewall o un componente detrás de él alcanzara un destino interno? Segundo, ¿qué identidad quedó expuesta cuando eso sucedió? Tercero, ¿qué podía hacer esa identidad?

La primera es una cuestión de aplicación y de ruta de red. Un firewall de aplicaciones web suele entenderse como un control que filtra la entrada hostil antes de que alcance una aplicación. En este incidente, la configuración relevante lo convirtió en parte de la ruta hacia los recursos internos. Esa inversión debería cambiar la forma en que los equipos de nube prueban los controles de borde. Un WAF no es solo un conjunto de reglas en el perímetro público; es código con un contexto de ejecución, alcance de salida, cabeceras, métodos y una identidad adjunta.

La revisión de seguridad debe preguntar qué puede alcanzar y suplantar el control cuando él mismo es confundido.

La segunda cuestión concierne a las credenciales de metadatos. Las credenciales temporales son más seguras que las claves de larga duración incrustadas en aspectos importantes: rotan, caducan y pueden asociarse centralmente a un rol. Pero «temporal» describe la duración, no el privilegio. Si un atacante puede obtener repetidamente una credencial vigente, o puede usarla durante su ventana válida para copiar un gran conjunto de datos, la rotación no evita el daño. La higiene de credenciales debe incluir, por tanto, la ruta por la que se emite la credencial y los permisos que conlleva.

La tercera cuestión es el privilegio mínimo. La acusación alegó que las cuentas obtenidas tenían el permiso necesario para listar y copiar el almacenamiento objetivo. Elauto de desestimación de septiembre de 2020 del tribunal civilrecoge, como alegación aceptada para esa fase procesal, la descripción de Amazon de una mala configuración del firewall de capa de aplicación agravada por permisos que probablemente eran más amplios de lo previsto. El auto también recoge las alegaciones de los demandantes sobre el acceso al almacenamiento y a un lago de datos. Esos pasajes no son conclusiones del juicio. Siguen siendo útiles porque la decisión del tribunal muestra que una intrusión delictiva no cortó necesariamente la presunta cadena causal entre las decisiones de seguridad y el daño a los consumidores como cuestión de derecho.

Por tanto, una revisión eficaz evitaría cerrar con «el WAF fue arreglado». Reconstruiría el gráfico de privilegios completo: solicitud pública al proxy; proxy al endpoint de metadatos; endpoint de metadatos a la sesión del rol; rol al listado de almacenamiento; listado de almacenamiento a la lectura de objetos; lectura de objetos a la ruta de descifrado; llamada a la API para la salida de red. Cada arista necesita un propietario, una justificación de negocio, controles preventivos y telemetría. Eliminar una regla defectuosa detiene la ruta conocida. No establece que la arquitectura de identidad y datos fuera proporcionada.

El cifrado protegió los medios, no el uso indebido autorizado

Capital One afirmó que cifraba los datos como práctica estándar y tokenizaba campos seleccionados, en particular los números de Seguro Social y de cuenta. También dijo que las circunstancias permitieron el descifrado de los datos accedidos, mientras que los datos tokenizados permanecieron protegidos porque la tokenización utilizaba un método y claves diferentes. Esta es una corrección importante a la afirmación común de que «los datos estaban cifrados» resuelve la cuestión del control.

El cifrado en reposo está diseñado principalmente para proteger los datos cuando los medios de almacenamiento, las instantáneas o el almacenamiento subyacente son accedidos fuera de la ruta de servicio autorizada. Las aplicaciones aún necesitan leer datos. Por tanto, los sistemas de almacenamiento en la nube y de gestión de claves descifran la información para las identidades que satisfacen la política.

Si el atacante adquiere una credencial con la misma autoridad de lectura que la carga de trabajo, el cifrado puede funcionar exactamente como se diseñó mientras entrega texto plano a un humano no autorizado que utiliza una identidad de máquina autorizada.

Eso no es un argumento contra el cifrado. Es un argumento para separar autoridades. Un rol expuesto a un control orientado al público no debería tener amplios permisos de lectura de datos y uso de claves. Los campos altamente sensibles deberían tokenizarse o cifrarse bajo un límite de servicio que la identidad general de lector de almacenamiento no pueda cruzar. Las políticas de claves, de datos y de roles deben revisarse como una sola decisión de autorización. De lo contrario, tres configuraciones individualmente plausibles pueden cruzarse para conceder un acceso que ninguno de sus propietarios pretendía.

El evento también muestra por qué los informes de control deben distinguir la cobertura de la consecuencia. «El cien por cien de los objetos cifrados» puede ser cierto mientras el riesgo de confidencialidad sigue siendo alto. Una métrica más útil para la junta mostraría qué proporción de objetos sensibles puede leer cada rol en tiempo de ejecución, qué identidades pueden invocar el descifrado, si una carga de trabajo orientada al público aparece en esas rutas, y con qué frecuencia un rol lee fuera de su prefijo, volumen, región o patrón temporal normal.

La detección falló antes de que la respuesta tuviera éxito

El programa de divulgación responsable de Capital One funcionó una vez que una persona externa lo utilizó. La empresa dijo que recibió un informe el 17 de julio, confirmó la filtración el 19 de julio, solucionó el problema, contactó con el FBI, anunció el incidente el 29 de julio y apoyó una detención rápida. Estos son hechos significativos de respuesta. No responden a por qué el sistema de control interno no llevó la actividad de marzo a una resolución.

Las conclusiones de la OCC abordan esa brecha a un nivel superior. En laorden de consentimiento de multa civil, el Contralor determinó que Capital One no había establecido una gestión adecuada del riesgo en la nube, incluyendo controles adecuados de prevención de pérdida de datos y una disposición eficaz de las alertas. Capital One no admitió ni negó esas conclusiones. «Disposición» es más que generar una alerta. Es el proceso que determina si un evento es benigno, se escala, se contiene o se cierra con evidencia.

Los entornos de nube generan abundante telemetría: asunción de roles, uso de metadatos, listado de almacenamiento, lecturas de objetos, direcciones de origen de la API, volumen de salida, llamadas denegadas, cambios de políticas y eventos de clasificación de datos. Más señales no crean automáticamente detección. Un programa puede recopilar cada evento relevante y aun así fallar si las reglas no correlacionan la secuencia, si los umbrales son insensibles al comportamiento normal de un rol, si las alertas carecen de un propietario responsable o si las razones de cierre no se revisan de forma independiente.

El hecho de que un informe externo condujera al descubrimiento debe registrarse tanto como un éxito de respuesta como un fallo de aseguramiento. El éxito es que el canal existía, se monitorizaba y permitió actuar. El fallo es que una ruta de acceso de cuatro meses de antigüedad era detectable a través de la actividad pública antes de que los propios controles del banco produjeran una contención definitiva. La divulgación responsable es un valioso sensor externo. No debe contabilizarse como sustituto de la detección interna de la obtención de credenciales, la enumeración inusual de buckets y la copia de grandes objetos.

La OCC trató la filtración como un fallo de gobernanza de la migración

El registro público de rendición de cuentas más sólido no es un análisis post mortem técnico. Es el paquete de medidas de ejecución de la OCC de 2020. Elanuncio de la multa de la agenciaafirma que el banco no estableció procesos eficaces de evaluación de riesgos antes de trasladar operaciones tecnológicas significativas a la nube pública y no corrigió las deficiencias de manera oportuna. La agencia impuso una multa de 80 millones de dólares, reconoció la notificación y corrección del banco, y declaró que la innovación responsable aún requiere una gestión de riesgos y controles internos sólidos.

Las conclusiones de consentimiento son inusualmente específicas. La OCC determinó que en torno a 2015 el banco no estableció una evaluación de riesgos eficaz antes de la migración. Encontró deficiencias en el diseño e implementación de controles de seguridad de red, en la prevención de pérdida de datos y en la disposición de alertas.

Determinó que la auditoría interna no identificó numerosas debilidades y brechas de control, no informó eficazmente de las debilidades identificadas al Comité de Auditoría, y que la junta directiva no tomó medidas eficaces para exigir responsabilidades a la gerencia por ciertas preocupaciones planteadas por la auditoría. Capital One aceptó la orden para evitar el coste del procedimiento y expresamente no admitió ni negó las conclusiones.

Este encuadre cambia la unidad de responsabilidad. Si el evento hubiera sido una sola regla de WAF defectuosa creada en 2019, la corrección podría centrarse en el ingeniero, la revisión del cambio y el control inmediato. Si el fallo relevante comenzó con un modelo operativo evaluado inadecuadamente en 2015, el sistema responsable incluye la gobernanza de la migración, el diseño de controles en la nube, el desafío de la segunda línea, la auditoría interna, los informes al comité, la corrección por parte de la gerencia y la escalada a la junta.

Laorden de cese y desistimiento de la OCCacompañante hizo operativo ese perímetro más amplio. Exigió un comité de cumplimiento de al menos tres directores, planes escritos de medidas correctoras, mejoras en la evaluación de riesgos tecnológicos, la gestión del riesgo de las operaciones en la nube, la gestión independiente de riesgos, las pruebas de controles y la auditoría interna. El plan para la nube debía abordar la seguridad perimetral, la identificación y protección de información sensible, la prevención y detección de divulgación no autorizada, y la gestión de la configuración para objetos contenedorizados. La gestión independiente de riesgos debía definir un universo integral de riesgos y controles y cuestionar la evaluación de primera línea del riesgo cibernético inherente y residual.

Los requisitos de prueba de controles de la orden son especialmente importantes. Capital One debía desarrollar un inventario de controles de nube relevantes, conciliar un plan de pruebas basado en riesgos con ese inventario, rastrear las brechas, remediarlas o aceptar formalmente el riesgo.

La auditoría interna debía validar la integridad y exactitud del inventario de activos tecnológicos, dispositivos configurables y software de la gerencia; mapear su universo de auditoría a las preocupaciones del examen; incorporar las lecciones del análisis de causa raíz de la filtración; revisar la cobertura de auditoría; evaluar la experiencia del personal; y mejorar la información al Comité de Auditoría.

Estas obligaciones responden a un error recurrente de gobernanza en la nube. Una empresa puede tener un catálogo de controles y un plan de auditoría y aun así carecer de una relación fiable entre ellos. El catálogo de controles contiene lo que la gerencia cree que existe. El inventario de activos contiene lo que los equipos creen que operan. El universo de auditoría contiene lo que la auditoría espera revisar. Si esos conjuntos no se concilian, un rol orientado al público, una ruta de metadatos, un bucket de almacenamiento o un motor de configuración pueden situarse entre los modelos de propiedad.

La orden de la OCC exigía evidencia de que los conjuntos se alinean.

La rendición de cuentas de la junta es evidencia, no frecuencia de reuniones

Ladeclaración de representación de 2020 de Capital Oneafirma que la gerencia informó rápidamente del incidente a la junta tras el descubrimiento el 19 de julio. Los miembros independientes de varios comités y la junta en pleno se reunieron más de 20 veces en relación con el incidente y la respuesta. La junta contrató a expertos externos, recibió informes sobre la causa raíz y la corrección, intensificó la supervisión y asignó al Comité de Riesgos el papel principal en la revisión de la gobernanza cibernética reforzada. La gerencia estableció un comité superior para los problemas cibernéticos empresariales y la escalada.

Son respuestas de gobernanza legítimas, pero el número de reuniones no puede probar que un control funcione. Las conclusiones de la OCC se centraron en el período anterior a la filtración, cuando las debilidades de auditoría supuestamente no se señalaron eficazmente y no se exigieron responsabilidades a la gerencia por algunas brechas abiertas. La comparación útil no es, por tanto, «pocas reuniones antes, muchas después». Es si la información que llegaba a los directores cambió de informes de actividad a evidencia de control.

La orden de la OCC definió lo que esa evidencia debería respaldar. Se exigía a los directores que aseguraran medidas correctoras oportunas, verificaran que las acciones fueran eficaces, garantizaran personal y sistemas suficientes, exigieran responsabilidades a la gerencia, requirieran informes adecuados y oportunos, y abordaran el incumplimiento. La junta podía apoyarse en la gerencia, los comités y terceros, pero esa dependencia no eliminaba el deber de asegurar las medidas correctoras.

Para un riesgo de metadatos y almacenamiento en la nube, un paquete informativo de calidad para la junta debería responder a preguntas concretas. ¿Cuántas cargas de trabajo accesibles desde Internet pueden acceder a los metadatos de instancia? ¿Cuántas requieren el protocolo de sesión más seguro? ¿Cuáles pueden deshabilitar completamente los metadatos? ¿Cuántos roles orientados al público pueden listar o leer almacenes de objetos sensibles? ¿Cuál es el volumen máximo de datos que cada rol puede recuperar durante una vida útil de credencial? ¿Qué controles evitan que los datos salgan de una red o región aprobada?

¿Cuántas alertas se cerraron sin evidencia corroboradora? ¿Qué problemas de auditoría de nube han superado las fechas objetivo y qué ejecutivo aceptó el riesgo residual?

Ninguna de esas preguntas pide a los directores que configuren un firewall. Preguntan si la gerencia puede demostrar el límite operativo que afirma. Esa es la distinción entre administración y supervisión. Los directores no necesitan conocer cada parámetro de la API, pero necesitan un sistema de información que haga visibles las combinaciones peligrosas antes que un investigador externo.

La responsabilidad compartida es un mapa de control, no una exención de responsabilidad

AWS describe la seguridad en la nube como compartida entre el proveedor y el cliente. Según elmodelo de responsabilidad compartida de AWS, AWS protege la infraestructura que ejecuta los servicios en la nube, mientras que las obligaciones del cliente varían según la selección del servicio y comúnmente incluyen los datos del cliente, la identidad y el acceso, el software de aplicación, la configuración del sistema operativo, la configuración del firewall, las elecciones de cifrado y la protección del tráfico. Para un servicio de infraestructura como EC2, el cliente controla sustancialmente más de la pila operativa de lo que lo haría en un servicio totalmente gestionado.

El modelo es útil porque evita un error de categoría: alquilar computación no convierte al proveedor en el operador de los permisos de aplicación del cliente. Pero el diagrama es solo el comienzo de la gobernanza. Muchos controles importantes cruzan la línea. El proveedor diseña el servicio de metadatos; el cliente decide si usarlo y cómo. El proveedor suministra la maquinaria de políticas de identidad; el cliente define roles y permisos. El proveedor produce registros; el cliente los habilita, retiene, enruta e investiga.

El proveedor ofrece opciones de región; el cliente selecciona regiones y arquitecturas que satisfacen las obligaciones legales. El proveedor hace posibles configuraciones predeterminadas más seguras; el cliente debe migrar las cargas de trabajo existentes y aplicarlas.

Ladeclaración de computación en la nube del FFIEChace explícita la consecuencia para el sector financiero. La gerencia no debe asumir que existen controles de seguridad y resiliencia simplemente porque los sistemas funcionen en un entorno de nube. La declaración dice que los contratos deben identificar las responsabilidades de las partes, pero las instituciones financieras siguen siendo responsables de una operación segura y sólida y del cumplimiento. Destaca la gobernanza, la arquitectura de la nube, la identidad, la gestión de datos, la gestión de vulnerabilidades, la monitorización, la respuesta a incidentes, la continuidad del negocio y la auditoría como prácticas conectadas.

Por tanto, la responsabilidad compartida debe traducirse en una matriz de control lo suficientemente precisa para ser probada. Para cada control, la matriz debe identificar quién lo diseña, quién lo configura, quién lo opera, quién recibe una alerta, quién valida la eficacia, qué evidencia se conserva y quién actúa cuando falta la evidencia. Una etiqueta como «responsabilidad del cliente» no es un propietario del control.

En un gran banco, «cliente» puede significar ingeniería de plataformas, equipos de aplicación, seguridad en la nube, gobernanza de datos, ingeniería de identidad, riesgo empresarial, auditoría interna, asesoría jurídica o un proveedor. La ambigüedad dentro de la organización del cliente puede ser más peligrosa que la ambigüedad entre el cliente y el proveedor.

Tampoco un diagrama de responsabilidad compartida decide la responsabilidad civil. Los términos contractuales, las representaciones, el diseño técnico, las obligaciones de notificación, la causalidad, la ley estatal y los hechos probados importan. El modelo puede orientar la operación esperada, pero no es una asignación judicial de culpa y no debe presentarse a una junta como si fuera una indemnización.

Responsabilidad penal, responsabilidad regulatoria y exposición civil

El registro público respalda varias formas de rendición de cuentas, cada una con un estatus legal diferente.

La responsabilidad penal es la más clara. Elanuncio de la sentencia del Departamento de Justiciaafirma que un jurado federal declaró a Thompson culpable de fraude electrónico, cinco cargos de acceso no autorizado a un ordenador protegido y daños a un ordenador protegido. Los fiscales demostraron que escaneó cuentas de nube en busca de configuraciones incorrectas, las utilizó para obtener datos y potencia de cómputo, y accedió a más de 30 entidades. Fue condenada a tiempo cumplido y cinco años de libertad condicional. Esa conducta delictiva juzgada no debe suavizarse como un descubrimiento accidental.

La rendición de cuentas regulatoria se centró en el banco. La orden de multa de la OCC es una orden de consentimiento definitiva, pero Capital One no admitió ni negó las conclusiones del Contralor. Elanuncio coordinado de ejecución de la Reserva Federalindicó que la sociedad holding debía mejorar la gestión de riesgos, la gobernanza, la ciberseguridad y los controles de seguridad de la información. Laorden de consentimiento de la Reserva Federaladjunta exigía que la junta de la matriz utilizara sus recursos para asegurar que los bancos cumplieran las órdenes de la OCC y presentara un plan escrito para la supervisión de la junta.

La exposición civil fue más amplia pero menos concluyente sobre la culpa última. Los consumidores demandaron a Capital One y a Amazon bajo teorías de negligencia, contrato, enriquecimiento injusto, notificación y protección al consumidor. En septiembre de 2020, el tribunal de distrito concedió en parte y denegó en parte las mociones de desestimación de los demandados. La mayoría de las reclamaciones por negligencia sobrevivieron, mientras que las reclamaciones por negligencia del estado de Washington y varias teorías de negligencia per se fueron desestimadas.

El tribunal concluyó en esa fase que la conducta delictiva de Thompson no sustituía necesariamente la presunta negligencia de los demandados. Dado que una moción de desestimación acepta como ciertas las alegaciones bien fundamentadas, la resolución estableció que las reclamaciones podían proceder; no estableció que Capital One o Amazon hubieran cometido los actos alegados.

El caso terminó en acuerdo en lugar de un juicio sobre el fondo. Laorden de aprobación finalaprobó un fondo no reversivo de 190 millones de dólares, servicios de defensa y restauración de identidad, y compromisos de prácticas empresariales. El acuerdo resolvió las reclamaciones contra Capital One y Amazon. La aprobación significó que el tribunal consideró la resolución negociada justa, razonable y adecuada según las normas de las acciones colectivas. No asignó un porcentaje de responsabilidad por la filtración entre el banco, AWS y el atacante.

Esta distinción importa porque la frase «¿quién fue responsable?» puede invitar a una respuesta falsa. Thompson fue condenada por actos delictivos. Capital One incurrió en sanciones regulatorias basadas en conclusiones de consentimiento y aceptó deberes correctivos. Capital One y Amazon se enfrentaron a reclamaciones civiles que sobrevivieron en parte y se resolvieron. Los cambios de diseño posteriores del proveedor son relevantes para la prevención pero no constituyen admisiones de culpa legal. Cada declaración tiene una fuente y una postura procesal. Combinarlas en un veredicto generalizado sería inexacto.

IMDSv2 y la gobernanza de configuraciones predeterminadas más seguras

AWS introdujo IMDSv2 en noviembre de 2019, menos de cuatro meses después de que Capital One revelara la filtración. Elaviso de lanzamiento de AWSlo describió como defensa en profundidad contra el acceso no autorizado a metadatos. Los clientes podían exigir el método de solicitud mejorado en instancias nuevas o en ejecución o desactivar el acceso a metadatos. La versión 1 seguía disponible por compatibilidad.

El token de sesión de IMDSv2 crea fricción contra varias rutas de delegado confundido. Un proxy que reenvía solicitudes GET simples puede no permitir el PUT inicial. Un proxy inverso que inserta una cabecera de reenvío puede ser rechazado para la creación del token. Un token está vinculado a la instancia y no puede simplemente reproducirse desde una máquina arbitraria. Los límites de saltos pueden restringir hasta dónde viaja una respuesta de metadatos a través de las capas de red. Estos son valiosos controles de protocolo porque reducen la consecuencia de errores de aplicación y de proxy.

No eliminan la necesidad del privilegio mínimo. Si un código hostil se ejecuta realmente en una instancia, puede realizar el intercambio de tokens igual que el código legítimo. Si una SSRF vulnerable permite métodos y cabeceras arbitrarios, la protección puede ser menos completa. Si el rol adjunto puede leer un lago de datos innecesario, la consecuencia residual sigue siendo alta. El endurecimiento de metadatos es, por tanto, una capa en una secuencia, no un sustituto del diseño de roles, el control de salida, la segmentación de datos y la monitorización.

Las configuraciones predeterminadas también tienen una dimensión temporal. En 2019, los clientes tenían que elegir y aplicar el método más seguro una vez disponible. Más tarde, AWS anunció unahoja de ruta para IMDSv2 por defectoque movió los inicios rápidos de la consola y los tipos de instancia recién lanzados hacia la versión 2, manteniendo opciones de compatibilidad. Esa progresión ilustra un dilema de gobernanza de plataforma. Un cambio obligatorio inmediato puede romper el software existente; una opcionalidad prolongada deja los viejos supuestos en su lugar. Los proveedores deberían hacer medible la migración, proporcionar aplicación a nivel de cuenta, exponer el uso restante de la versión 1 y establecer una dirección clara. Los clientes deberían tratar las actualizaciones de seguridad opcionales como decisiones de riesgo con propietarios y plazos, no como un backlog de funcionalidades.

Para las juntas, la lección es preguntar sobre la deuda de configuraciones predeterminadas. ¿Cuántas cargas de trabajo siguen dependiendo de un modo de metadatos heredado? ¿Por qué? ¿Qué se rompería si se desactivara? ¿Qué aplicaciones no pueden tolerar un límite de saltos más bajo? ¿Qué política organizativa impide nuevas excepciones? ¿Cómo sabe la empresa que una cuenta adquirida o un entorno de desarrollo no ha derivado? Una funcionalidad segura que está disponible pero no se mide produce menos garantía que un programa de migración vinculado al inventario y a la aplicación.

La localidad de los datos no contuvo el acceso lógico

La filtración afectó a personas a ambos lados de la frontera entre EE. UU. y Canadá. LaOficina del Comisionado de Privacidad de Canadáabrió una investigación después de que Capital One informara de que seis millones de canadienses se vieron afectados, incluidos algunos cuyos números de seguro social habían sido accedidos. Lapágina canadiense del incidente de Capital Oneproporcionó avisos y apoyo específicos para el país. El impacto transfronterizo convierte la localidad de una cuestión abstracta de adquisición de nube en una cuestión de rendición de cuentas.

Las fuentes revisadas aquí no establecen la región exacta de AWS de cada objeto afectado, ni muestran que los registros canadienses se almacenaran en una región canadiense separada. Esa ausencia debe preservarse. Sería irresponsable inferir una ubicación de almacenamiento a partir de la nacionalidad del interesado o de una marca de nube global. Lo que el registro sí establece es que un solo incidente afectó a grandes poblaciones regidas por sistemas legales y regulatorios diferentes.

AWS afirma en susmateriales de privacidad de datosque los clientes controlan el contenido del cliente y que los deberes del proveedor y del cliente siguen el modelo de responsabilidad compartida. Su actualmarco de soberanía digitalenfatiza la elección del cliente sobre dónde se ejecutan las cargas de trabajo, el acceso a los datos, la resiliencia y el control. Esas capacidades son relevantes, pero la selección de una región no es un resultado completo de soberanía.

La localidad responde a dónde está configurado un servicio para almacenar o procesar datos en funcionamiento normal. La seguridad también debe responder a quién puede hacer que el servicio los divulgue, dónde pueden ejercerse las credenciales, a dónde van los registros y las copias de seguridad, cómo se controla el acceso de soporte y si los datos exportados pueden cruzar el límite seleccionado. En la cadena de Capital One, una credencial de API fue más determinante que la proximidad física a un disco. Una vez que un rol fue aceptado como autorizado, el almacenamiento podía entregar objetos a través de la interfaz del servicio.

Una región nacional no habría impedido por sí sola esa ruta lógica.

Los controles de soberanía necesitan, por tanto, al menos cuatro capas. La primera es la ubicación: regiones aprobadas, configuraciones de replicación, copias de seguridad, analítica, recuperación ante desastres y servicios de soporte. La segunda es la autoridad: identidades, uso de claves, acceso a metadatos y políticas que restrinjan las llamadas por red, cuenta, organización o región. La tercera es la observabilidad: registros retenidos en una cuenta controlada de forma independiente, evidencia de transferencias entre regiones, alertas para ubicaciones de origen inusuales y registros disponibles para los reguladores pertinentes.

La cuarta es la salida y la continuidad: la capacidad de exportar datos y registros en forma utilizable, revocar el acceso del proveedor, rotar claves y operar un acuerdo de recuperación probado si una región, un proveedor o un mecanismo de transferencia legal deja de estar disponible.

El incidente también muestra que la geografía de los interesados puede importar incluso cuando la geografía de la infraestructura es incierta. Los reguladores canadienses, las personas afectadas, las prácticas de notificación y las necesidades de corrección de identidad no desaparecieron porque Capital One tenga su sede en Estados Unidos. Un programa de nube multinacional debe mapear los conjuntos de datos a las personas y obligaciones que representan, no solo a la cuenta y región en las que los ingenieros los ven.

La retención convirtió una ruta de acceso en un expediente histórico

Capital One dijo que la mayor categoría afectada incluía datos de solicitudes desde 2005 hasta principios de 2019. Ese lapso cambia el análisis de riesgo. Una solicitud de crédito tiene un propósito inmediato: evaluar la elegibilidad, cumplir la ley, prevenir el fraude y establecer una cuenta. Con el tiempo, parte de la información puede seguir siendo necesaria para el servicio, las retenciones legales, los deberes regulatorios, la gobernanza de modelos, la resolución de disputas o el análisis de fraude. Pero la necesidad debe demostrarse por campo, propósito y período.

La retención se trata a menudo como un programa de privacidad separado de la seguridad en la nube. La filtración muestra por qué esa separación es artificial. La cantidad y antigüedad de los datos accesibles por un rol comprometido determinan el impacto. Un programa de eliminación perfecto no puede impedir que un atacante lea registros actuales, pero puede evitar que un solo evento de credencial exponga catorce años de historial de solicitudes. Del mismo modo, clasificar un campo como sensible tiene poco efecto si ninguna política de almacenamiento, límite de clave, rol de acceso o tarea de eliminación cambia debido a la clasificación.

El control apropiado no es simplemente «eliminar datos antiguos». Es un ciclo de vida defendible: identificar el propósito de la recopilación; especificar la base legal y de negocio para la retención; separar los datos operativos activos de los archivos restringidos; minimizar los campos; tokenizar los identificadores duraderos; aplicar la eliminación; conservar solo los registros sujetos a una excepción documentada; y comprobar si los datos eliminados también dejan réplicas, conjuntos de datos derivados, cachés, instantáneas y copias de desarrollo. Cada excepción debe tener un propietario y una revisión de caducidad.

La arquitectura de datos también debería reducir la agregación. Un solo rol no debería obtener acceso a un amplio corpus histórico simplemente porque un trabajo de procesamiento lo necesitó una vez. La partición por propósito, sensibilidad, período de tiempo y jurisdicción da a la política de acceso algo significativo que aplicar. Sin esos límites, el privilegio mínimo se ve obligado a operar al nivel de un bucket o lago de datos muy grande, y la diferencia entre «puede ejecutar esta aplicación» y «puede leer la historia de esta institución» se vuelve peligrosamente pequeña.

La dependencia de la nube incluye la dependencia de la evidencia

Capital One no se limitaba a alquilar discos remotos. Como cualquier gran cliente de nube, dependía de la semántica de identidad definida por el proveedor, del comportamiento de los metadatos, del registro de la API, de los constructos de región, de los controles de almacenamiento, de la disponibilidad del servicio, de la documentación y de la capacidad del proveedor para preservar y explicar la evidencia. Esa es una dependencia más amplia que el tiempo de actividad.

El incidente de 2019 no causó una interrupción pública prolongada de los servicios bancarios centrales de Capital One. El problema de continuidad fue la confidencialidad y la confianza. La empresa tuvo que investigar un gran patrimonio de nube, identificar los registros afectados, notificar a las personas en dos países, trabajar con las fuerzas de seguridad y los reguladores, proporcionar monitorización, defenderse en litigios y corregir los controles mientras seguía operando.

Esto es continuidad bajo evidencia comprometida: los servicios pueden seguir disponibles mientras la institución debe determinar si se puede seguir confiando en sus registros, procesos de identidad y comunicaciones con los clientes.

ElFormulario 10-K de 2019 de Capital Oneinformó de 72 millones de dólares en gastos incrementales de respuesta y corrección en 2019, compensados por 34 millones de dólares en recuperaciones de seguros. La empresa esperaba situarse en el extremo inferior de su rango previamente anunciado de 100 a 150 millones de dólares para el total de partidas de ajuste del incidente, con algunos costes extendiéndose más allá de 2019. Advirtió de intervención regulatoria, litigios, costes de corrección, daño reputacional y pérdida de confianza. Esas cifras precedieron a la multa de 80 millones de dólares de la OCC y al posterior fondo de conciliación colectiva de 190 millones, y no deben sumarse a la ligera porque los seguros, el calendario, el alcance del acuerdo y el tratamiento contable difieren.

La dependencia de la evidencia debe planificarse contractual y técnicamente. Un cliente regulado necesita registros con campos y retención adecuados, notificación rápida de eventos del proveedor, cooperación con la recolección forense, deberes de preservación, información sobre regiones y subprocesadores, acceso a informes de control, comunicación de vulnerabilidades y un proceso para las solicitudes gubernamentales y regulatorias. También necesita su propia copia de los registros críticos en una cuenta de seguridad que la carga de trabajo comprometida no pueda alterar.

Un panel de control del proveedor que diga que un servicio funcionó normalmente no establece que las identidades de los clientes estuvieran correctamente delimitadas.

La planificación de la salida pertenece al mismo paquete. Concentrar los datos y la política de identidad en un solo proveedor puede mejorar la estandarización y la visibilidad, pero también puede dificultar la migración. Una prueba de salida debería medir cuánto se tarda en inventariar los datos, reproducir la política de acceso, exportar claves o volver a cifrar, transferir registros, reconstruir la detección, satisfacer las restricciones de localidad y demostrar la eliminación en el proveedor anterior. El despliegue en múltiples nubes no es automáticamente más seguro; duplicar controles inmaduros puede duplicar la incertidumbre.

El objetivo es la portabilidad creíble de los datos y la evidencia, no un recuento decorativo de proveedores.

Lo que resolvieron los acuerdos y lo que dejaron abierto

El acuerdo con los consumidores es sustancial, pero su significado debe expresarse con cuidado. El acuerdo creó un fondo de 190 millones de dólares para pérdidas directas elegibles, tiempo perdido, servicios de defensa de identidad, servicios de restauración, notificación y administración, y honorarios aprobados por el tribunal. También incluyó compromisos de prácticas empresariales. La orden de aprobación final consideró el acuerdo justo, razonable y adecuado, y desestimó las reclamaciones de los consumidores liberadas con perjuicio.

El acuerdo no estableció que todas las alegaciones de la demanda enmendada fueran ciertas. No convirtió los antecedentes de la moción de desestimación en conclusiones tras la práctica de la prueba. No determinó que el diseño de metadatos de AWS causara un porcentaje específico del daño ni que la configuración de Capital One causara el resto. No borró la responsabilidad penal de Thompson ni desplazó las conclusiones y órdenes regulatorias separadas de la OCC.

Esta asignación no resuelta es en sí misma una lección de gobernanza. Las empresas no pueden esperar a que un tribunal asigne un porcentaje claro antes de mejorar un control compartido. Un proveedor de plataforma puede no tener responsabilidad adjudicada y aún así añadir un protocolo más seguro. Un cliente puede discrepar de las conclusiones del regulador y aun así aceptar una orden y revisar los controles. Una junta puede reservarse las defensas legales mientras trata los hechos operativos como urgentes. La postura legal y la postura de corrección pueden diferir sin contradicción.

La OCC anunció posteriormente quedio por terminada la orden de cese y desistimiento de 2020con efectos del 31 de agosto de 2022. La terminación es un punto final importante para esa orden en particular. No anula la multa, no reescribe las conclusiones históricas ni prueba que el riesgo en la nube se haya vuelto estático. Indica que la orden formal ya no estaba pendiente. Una junta madura debería convertir las disciplinas de inventario de controles, pruebas, auditoría e informes de la orden en gobernanza normal en lugar de dejar que expiren con la supervisión regulatoria.

Un paquete de evidencia para el riesgo de metadatos, identidad y localidad

El registro de Capital One respalda un paquete práctico de evidencia para organizaciones que ejecutan cargas de trabajo sensibles en la nube pública.

Mapear las rutas públicas a la autoridad interna.Inventariar cada proxy, balanceador de carga, WAF, puerta de enlace API y aplicación accesible desde Internet. Para cada uno, mostrar los destinos de salida, el alcance de los metadatos, las identidades adjuntas, los métodos y cabeceras permitidos, y la máxima autoridad de datos alcanzable a través de esa identidad. Probar la ruta desde la perspectiva de un atacante, no solo contra el diagrama de arquitectura previsto.

Hacer medible la postura de metadatos.Registrar si los metadatos son necesarios, si pueden desactivarse, qué versión de protocolo se requiere, el límite de saltos, las restricciones del firewall local, las implicaciones para los contenedores y las llamadas heredadas observadas. Aplicar el estado preferido a nivel de organización o cuenta. Las excepciones deben identificar el software dependiente, el propietario del riesgo, los controles compensatorios y la fecha de eliminación.

Calcular el radio de explosión de las credenciales.Para cada rol en tiempo de ejecución, enumerar los prefijos de almacenamiento, bases de datos, colas, secretos, operaciones de claves y acciones administrativas que puede alcanzar. Estimar cuántos datos sensibles podrían leerse durante una vida útil de credencial y desde qué ubicaciones de red. Probar los permisos efectivos, incluida la intersección de las políticas de identidad, recursos, claves, endpoints y organización.

Separar el acceso al almacenamiento de la autoridad de descifrado.El cifrado no debe colapsar en el mismo rol que está expuesto a través de la ruta de aplicación. Usar tokenización o un servicio distinto para los campos de identidad duraderos. Alertar cuando una identidad orientada al público invoca operaciones de claves o lee una clase de datos fuera de su propósito limitado.

Controlar los datos por propósito y jurisdicción.Etiquetar y particionar los datos según la sensibilidad, el propósito, el período de retención y la población afectada. Aplicar las regiones aprobadas para el almacenamiento primario, las réplicas, la analítica, las copias de seguridad y la recuperación. Registrar cualquier servicio que necesariamente mueva contenido o datos de soporte. Probar la denegación entre regiones y cuentas, no solo la ubicación configurada.

Poseer la pista de auditoría.Enrutar los eventos de identidad, metadatos, almacenamiento, claves, red y pérdida de datos a un entorno de registro administrado de forma independiente. Proteger los registros de los roles de carga de trabajo. Correlacionar la obtención de credenciales, las operaciones de listado, las lecturas de objetos, el descifrado y la salida. Medir si las alertas se investigan hasta una conclusión evidenciada, no solo si se generan.

Conciliar el universo de control.El catálogo de controles de nube de la gerencia, el inventario de activos, el inventario de configuración, el catálogo de datos, el registro de riesgos y el universo de auditoría deben tener identificadores comunes. La auditoría interna debe probar la integridad en lugar de muestrear solo de la lista de la gerencia. Los activos y controles no emparejados deben informarse como cobertura desconocida.

Escalar los hallazgos repetidos y vencidos.Una brecha de configuración con una fecha de corrección incumplida debe aparecer junto a las rutas de identidad y datos que deja expuestas. Los informes de la junta deben nombrar al ejecutivo responsable, los controles compensatorios, el método de validación y la fecha límite. El cierre debe requerir evidencia independiente de que la condición de riesgo cambió.

Ejercitar la respuesta transfronteriza.Un simulacro de filtración debe identificar qué poblaciones y reguladores están implicados, qué registros muestran la ubicación y el acceso, cómo se entregarán los avisos específicos de cada país y cómo funciona la restauración de identidad para diferentes identificadores gubernamentales y sistemas de crédito. La organización debe poder explicar dónde se encontraban los datos afectados sin reconstruir la respuesta durante la crisis.

Preservar la cooperación del proveedor y los derechos de salida.Los contratos y procedimientos operativos deben asegurar el acceso oportuno a los registros, el apoyo forense, el aviso de incidentes, la preservación de la evidencia, los compromisos de región, la transparencia de los subprocesadores y la certificación de eliminación. Los equipos deben probar periódicamente la exportación de datos, políticas, claves y evidencia de auditoría a un entorno de recuperación utilizable.

Este paquete es exigente porque el riesgo es combinatorio. El WAF puede cumplir su línea base. El servicio de metadatos puede funcionar según lo documentado. El rol puede tener una razón de negocio. El bucket puede ser privado. Los objetos pueden estar cifrados. Los registros pueden existir. Sin embargo, la intersección puede permitir que una solicitud pública se convierta en una exportación autorizada. La responsabilidad se encuentra en las intersecciones.

La prueba duradera

La filtración de Capital One sigue siendo un caso útil de responsabilidad en la nube porque resiste dos historias fáciles. La primera dice que la nube pública causó la filtración. Eso ignora la configuración controlada por el cliente, los permisos, la arquitectura de datos, la monitorización y las conclusiones directas de la OCC sobre el programa de riesgo en la nube del banco. La segunda dice que la responsabilidad compartida situó el asunto enteramente en el cliente.

Eso trata un diagrama del proveedor como el final del análisis de diseño y pasa por alto el valor de defensas de metadatos más sólidas, configuraciones predeterminadas más seguras, la telemetría del proveedor y la evidencia contractual.

La mejor explicación sigue la cadena. Un control orientado al público pudo retransmitir una solicitud no deseada. La solicitud alcanzó un límite de confianza de metadatos. La identidad temporal resultante tenía suficiente autoridad para listar y copiar la información almacenada. El cifrado no impidió que una credencial aceptada como autorizada leyera los datos. La monitorización interna no produjo una contención oportuna. Un largo horizonte de retención amplió el corpus expuesto. El mismo evento alcanzó a personas bajo los regímenes de privacidad de EE. UU. y Canadá.

La auditoría y los informes de la junta no habían forzado la resolución de las brechas más amplias de control en la nube identificadas por el regulador.

La responsabilidad se separó luego por foro. El atacante fue condenado. Los reguladores bancarios impusieron obligaciones de consentimiento y una multa a Capital One. Los consumidores demandaron tanto a Capital One como a Amazon; las reclamaciones sobrevivieron en parte y se resolvieron sin una asignación de culpa en juicio. AWS introdujo un protocolo de metadatos más defensivo. Capital One describió la corrección, reforzó la supervisión de la junta y asumió costes sustanciales de respuesta, ejecución y acuerdo.

Para las futuras juntas, la pregunta decisiva no es si el proveedor de nube está certificado, el bucket está cifrado o la regla del firewall ha sido corregida. Es si la institución puede probar que ninguna ruta no confiable puede obtener una identidad de carga de trabajo con autoridad desproporcionada; que el uso inusual de esa identidad será detectado y resuelto; que los datos accesibles están limitados por propósito, tiempo y jurisdicción; y que la evidencia del proveedor y del cliente puede unirse con suficiente rapidez para gobernar el riesgo.

Esa prueba es el significado práctico de la responsabilidad compartida. Sin ella, la responsabilidad solo está dividida sobre el papel mientras el riesgo permanece conectado en producción.