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

Resumen

• Capital One afirmó 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 cortafuegos de aplicaciones web mal configurado permitió que comandos alcanzaran el entorno en la nube, se obtuvieron credenciales para un rol, esas credenciales pudieron enumerar y copiar objetos de almacenamiento, y la supervisión no convirtió la actividad sospechosa en contención oportuna.
• La Oficina del Contralor de la Moneda no caracterizó el evento como un error de ingeniería aislado. Sus conclusiones consentidas 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, mala gestión de alertas, brechas en la auditoría interna y una acción ineficaz de la junta para responsabilizar a la gerencia.
• La responsabilidad existió en varios planos sin ser 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 reclamaciones de los consumidores contra Capital One y Amazon sobrevivieron en parte en la etapa de alegaciones y se resolvieron posteriormente, 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 de 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, incluido alrededor 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 brecha descrita de forma demasiado limitada

La versión familiar de la brecha de Capital One es compacta: 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. Sin embargo, como relato de responsabilidad, es demasiado limitado. Hace que el evento suene como una única mala configuración en el perímetro de un entorno por lo demás controlado.

El registro oficial describe algo más estructural. Elanuncio del 29 de julio de 2019 presentado ante la SECde Capital One indicó que la compañía había determinado el 19 de julio que un individuo externo obtuvo información personal tras explotar una vulnerabilidad de configuración específica. Situó el acceso no autorizado material el 22 y 23 de marzo, dijo que un informe de divulgación responsable llegó el 17 de julio y explicó que la compañía solucionó la configuración y trabajó con las fuerzas del orden federales. También dijo que el modelo operativo en la nube ayudó a la compañía 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 compañía enfatizó que los elementos de infraestructura relevantes podían existir en la nube o en instalaciones locales. La posición es técnicamente defendible: un proxy inverso o un firewall de aplicaciones web pueden convertirse en un relevo no intencionado en cualquier entorno; las credenciales de servicio pueden ser demasiado poderosas en cualquier entorno; una identidad legítima puede leer datos cifrados en cualquier entorno. Sin embargo, la nube cambia la velocidad, la abstracción y la escala en que esas condiciones se combinan. 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 del incidenteactual de Capital One indica que aproximadamente 100 millones de personas en Estados Unidos y aproximadamente seis millones en Canadá se vieron afectadas. La mayor categoría de datos fue información proporcionada por consumidores y pequeñas empresas al solicitar productos de tarjetas 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. Partes de los 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 repartidos en 2016, 2017 y 2018. La compañía informó de aproximadamente 140,000 números de la Seguridad Social estadounidense, alrededor 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. Dijo que los números de cuentas de tarjetas de crédito y las credenciales de inicio de sesión no se vieron comprometidos.

Esas distinciones evitan la exageración, pero no reducen la cuestión del control a un número. Los datos de aplicaciones pueden seguir siendo sensibles para 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 lo tanto, el evento no se trató solo de si un bucket era privado. Se trató 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 supervisión no cerró la brecha y por qué los datos recopilados durante aproximadamente catorce años permanecieron dentro del conjunto accesible.

La cronología y la forma cambiante de la responsabilidad

Las fechas cambian lo que razonablemente se puede esperar que una organización sepa y haga. La cronología central se puede extraer de las divulgaciones de la compañía, la acusación y condena posteriores, las órdenes de los reguladores 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 sustitutiva de 2021imputó un período más amplio de acceso no autorizado a ordenadores que comenzó en o alrededor del 12 de marzo. El anuncio de Capital One utilizó el 22 y 23 de marzo para el acceso a datos central en su relato del incidente. Una cronología debe preservar esa diferencia entre el curso de conducta imputado y la descripción de la exfiltración por parte de la compañía.

La misma disciplina se aplica a los recuentos de población. El anuncio inicial de la compañía utilizó aproximadamente 100 millones de personas afectadas en Estados Unidos y seis millones en Canadá. El administrador del acuerdo estadounidense describió posteriormente aproximadamente 98 millones de consumidores estadounidenses en la clase del acuerdo. Ninguna cifra debe convertirse silenciosamente en un recuento universal preciso. Pertenecen a registros diferentes, en etapas diferentes, 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 peticiones 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 petición elegida o influenciada por ese llamante. La petición se realiza desde la posición de red del servidor, por lo que puede alcanzar destinos no disponibles directamente desde la internet pública. 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 externo a un contexto de red más confiable.

Lapágina del caso Capital Onedel Departamento de Justicia describe la intrusión como ocurrida a través de un firewall de aplicaciones web mal configurado. La acusación sustitutiva, 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 alcanzaran y se ejecutaran en sus servidores. Alegó que esos comandos obtuvieron credenciales de seguridad para cuentas o roles de clientes; luego las credenciales se usaron para listar buckets de almacenamiento y copiar objetos para los que el rol tenía permiso. La acusación utilizó el término neutral "Empresa de Computación en la Nube", pero el registro civil público y las propias presentaciones de Capital One identifican el entorno como AWS.

El 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. Sin embargo, el diseño supone que el acceso desde la instancia tiene significado. Si se puede hacer que un componente orientado a la web emita peticiones internas arbitrarias, "local a la instancia" ya no equivale a "código de carga de trabajo autorizado".

Laexplicación de IMDSv2 de 2019de AWS identifica 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 primero realice una petición HTTP PUT para establecer una sesión y recibir un token secreto, y luego presente ese token en las peticiones de metadatos posteriores. AWS diseñó el protocolo para agregar 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 desactivar completamente el acceso a metadatos.

El punto analítico importante no es que una revisión de protocolo pruebe retroactivamente un defecto, ni que una configuración del cliente exima al diseñador de la plataforma de toda responsabilidad de diseño. Es que una suposición de confianza local puede reforzarse en más de una capa. Capital One podía restringir el WAF, limitar la salida al endpoint de metadatos, reducir el rol, limitar el almacenamiento accesible, detectar un uso inusual 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 debe convertirse automáticamente en una credencial de identidad y que una credencial de identidad no debe convertirse automáticamente en una gran exportación de datos.

El firewall de aplicaciones web no fue toda la brecha

Llamar al incidente una mala configuración del firewall puede ocultar tres preguntas separadas. Primero, ¿por qué pudo una petición 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 ruta de red. Un firewall de aplicaciones web suele entenderse como un control que filtra la entrada hostil antes de que llegue a una aplicación. En este incidente, la configuración relevante lo convirtió en parte de la ruta hacia recursos internos. Esa inversión debería cambiar la forma en que los equipos de nube prueban los controles perimetrales. Un WAF no es solo un conjunto de reglas en el perímetro público; es código con un contexto de ejecución, capacidad 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 está confundido.

La segunda cuestión se refiere 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 centralizadamente a un rol. Pero "temporal" describe la duración, no el privilegio. Si un atacante puede obtener repetidamente una credencial actual, o puede usar una credencial 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. Laorden de moción de desestimación de septiembre de 2020del tribunal civil recoge, 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. La orden 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 disposición del tribunal muestra que una intrusión delictiva no rompió necesariamente la cadena causal alegada entre las decisiones de seguridad y el daño al consumidor como cuestión de derecho.

Por lo tanto, una revisión efectiva evitaría cerrar con "el WAF fue arreglado". Reconstruiría el gráfico de privilegios completo: petición 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 API a 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 dijo que cifraba los datos como práctica estándar y tokenizaba campos seleccionados, en particular los números de la Seguridad 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 usaba 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 se acceden fuera de la ruta de servicio autorizada. Las aplicaciones aún necesitan leer datos. Por lo tanto, los sistemas de almacenamiento en la nube y 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 libera texto plano a un humano no autorizado utilizando una identidad de máquina autorizada.

Eso no es un argumento contra el cifrado. Es un argumento a favor de separar las autoridades. Un rol expuesto a un control orientado al público no debería tener permisos amplios 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, políticas de datos y políticas de roles deben revisarse como una única decisión de autorización. De lo contrario, tres configuraciones individualmente plausibles pueden intersectarse para otorgar 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 compañía dijo que recibió un informe el 17 de julio, confirmó la brecha el 19 de julio, solucionó el problema, contactó al FBI, anunció el incidente el 29 de julio y apoyó un arresto rápido. Esos son hechos de respuesta significativos. No responden por qué el sistema de control interno no llevó a resolución la actividad de marzo.

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 de riesgos de nube adecuada, incluyendo controles de prevención de pérdida de datos adecuados y una disposición efectiva de las alertas. Capital One ni 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 API, volumen de salida, llamadas denegadas, cambios de políticas y eventos de clasificación de datos. Más señales no crean detección automáticamente. Un programa puede recopilar cada evento relevante y sin embargo 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 independientemente.

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, era monitoreado y permitió actuar. El fallo es que una ruta de acceso de cuatro meses de antigüedad fue descubrible a través de actividad pública antes de que los propios controles del banco produjeran la contención final. La divulgación responsable es un valioso sensor exterior. No debe contarse 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 brecha como un fallo de gobernanza de la migración

El registro público de responsabilidad más sólido no es una autopsia técnica. Es el paquete de medidas de ejecución de la OCC de 2020. Elanuncio de la multade la agencia dice que el banco no estableció procesos efectivos 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 remediación del banco, y afirmó que la innovación responsable aún requiere una gestión de riesgos sólida y controles internos.

Las conclusiones consentidas son inusualmente específicas. La OCC determinó que en o alrededor de 2015 el banco no estableció una evaluación de riesgos efectiva antes de la migración. Encontró deficiencias en el diseño e implementación de controles de seguridad de red, prevención de pérdida de datos y disposición de alertas. Encontró que la auditoría interna no identificó numerosas debilidades y brechas de control, no informó efectivamente las debilidades identificadas al Comité de Auditoría, y que la junta no tomó medidas efectivas para responsabilizar a la gerencia por ciertas preocupaciones planteadas por la auditoría. Capital One aceptó la orden para evitar el costo de los procedimientos y expresamente no admitió ni negó las conclusiones.

Este encuadre cambia la unidad de responsabilidad. Si el evento fuera una mala regla de WAF creada en 2019, la remediació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 segunda línea, la auditoría interna, los informes a comités, la remediación de la gerencia y la escalada a la junta.

Laorden de cese y desistimiento de la OCCadjunta hizo operativo ese perímetro más amplio. Exigía un comité de cumplimiento de al menos tres directores, planes escritos de acciones correctivas, mejoras en la evaluación de riesgos tecnológicos, gestión de riesgos de operaciones en la nube, gestión de riesgos independiente, pruebas de controles y auditoría interna. El plan de 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 configuración de objetos en contenedores. La gestión de riesgos independiente debía definir un universo integral de riesgos y controles y desafiar la evaluación de primera línea del riesgo cibernético inherente y residual.

Los requisitos de pruebas de controles de la orden son especialmente importantes. Capital One tuvo que desarrollar un inventario de controles de nube relevantes, conciliar un plan de pruebas basado en riesgos con ese inventario, rastrear 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 lecciones del análisis de causa raíz de la brecha; revisar la cobertura de auditoría; evaluar la experiencia del personal; y mejorar los informes 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 pero 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 modelos de propiedad. La orden de la OCC requería evidencia de que los conjuntos están alineados.

La responsabilidad de la junta es evidencia, no frecuencia de reuniones

Ladeclaración de representación de 2020de Capital One dice 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 completa 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 remediación, intensificó la supervisión y asignó al Comité de Riesgos el papel principal en la revisión de la gobernanza cibernética mejorada. La gerencia estableció un comité superior para cuestiones cibernéticas empresariales y escalada.

Esas son respuestas de gobernanza legítimas, pero el número de reuniones no puede probar que un control funciona. Las conclusiones de la OCC se centraron en el período anterior a la brecha, cuando supuestamente las debilidades de auditoría no se expusieron eficazmente y la gerencia no fue responsabilizada por algunas brechas abiertas. Por lo tanto, la comparación útil no es "pocas reuniones antes, muchas reuniones después". Es si la información que llegaba a los directores cambió de informes de actividad a evidencia de controles.

La orden de la OCC definió lo que esa evidencia debía respaldar. Se exigió a los directores que garantizaran acciones correctivas oportunas, verificaran que las acciones fueran efectivas, aseguraran personal y sistemas suficientes, responsabilizaran a la gerencia, exigieran informes adecuados y oportunos y abordaran el incumplimiento. La junta podía confiar en la gerencia, los comités y terceros, pero la confianza no eliminaba el deber de garantizar la acción correctiva.

Para un riesgo de metadatos y almacenamiento en la nube, un paquete de calidad para la junta debería responder 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 fuerte? ¿Cuáles pueden desactivar 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 en 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 corroborante? ¿Qué problemas de auditoría de nube han incumplido 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 API, pero necesitan un sistema de informes que haga visibles las combinaciones peligrosas antes de que lo haga 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 responsabilidades 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 opciones 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 valores predeterminados más seguros; el cliente debe migrar las cargas de trabajo existentes y aplicarlos.

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

Por lo tanto, la responsabilidad compartida debe traducirse en una matriz de control lo suficientemente precisa como para probarse. 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 efectividad, qué evidencia se retiene y quién actúa cuando falta la evidencia. Una etiqueta como "responsabilidad del cliente" no es un propietario del control. En un banco grande, "cliente" puede significar ingeniería de plataforma, equipos de aplicaciones, seguridad en la nube, gobernanza de datos, ingeniería de identidad, riesgo empresarial, auditoría interna, legal 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.

Un diagrama de responsabilidad compartida tampoco 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 guiar 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 responsabilidad, cada una con un estatus legal diferente.

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

La responsabilidad regulatoria se centró en el banco. La orden de multa de la OCC es una orden de consentimiento final, pero Capital One ni admitió ni negó las conclusiones del Contralor. Elanuncio de ejecución coordinada de la Reserva Federaldijo 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 a la junta matriz que utilizara sus recursos para garantizar 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 final. Los consumidores demandaron a Capital One y 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ó algunas partes de las mociones de desestimación de los demandados y denegó otras. La mayoría de las reclamaciones por negligencia sobrevivieron, mientras que las reclamaciones por negligencia de Washington y varias teorías de negligencia per se fueron desestimadas. El tribunal concluyó en esa etapa que la conducta delictiva de Thompson no necesariamente sustituía la negligencia alegada de los demandados. Debido a que una moción de desestimación acepta como ciertas las alegaciones bien formuladas, el fallo estableció que las reclamaciones podían proceder; no estableció que Capital One o Amazon hubieran cometido los actos alegados.

El caso terminó en un 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 comerciales. 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 bajo las reglas de acciones colectivas. No asignó un porcentaje de responsabilidad por la brecha entre el banco, AWS y el atacante.

Esta distinción importa porque la frase "¿quién fue responsable?" puede invitar una respuesta falsa. Thompson fue condenada por actos delictivos. Capital One incurrió en sanciones regulatorias basadas en conclusiones consentidas y aceptó deberes correctivos. Capital One y Amazon enfrentaron reclamaciones civiles que sobrevivieron en parte y fueron resueltas. Los cambios de diseño posteriores del proveedor son relevantes para la prevención pero no son 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 valores predeterminados más seguros

AWS introdujo IMDSv2 en noviembre de 2019, menos de cuatro meses después de que Capital One revelara la brecha. 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 permaneció disponible por compatibilidad.

El token de sesión de IMDSv2 crea fricción contra varias rutas de delegado confundido. Un proxy que reenvía peticiones 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 los errores de aplicación y proxy.

No eliminan la necesidad de privilegio mínimo. Si código hostil se ejecuta realmente en una instancia, puede ser capaz de realizar el intercambio de token al igual que el código legítimo. Si un SSRF vulnerable permite métodos y cabeceras arbitrarias, la protección puede ser menos completa. Si el rol adjunto puede leer un lago de datos innecesario, la consecuencia residual sigue siendo alta. Por lo tanto, el refuerzo de metadatos es una capa en una secuencia, no un reemplazo para el diseño de roles, el control de salida, la segmentación de datos y la supervisión.

Los valores predeterminados también tienen una dimensión temporal. En 2019, los clientes tenían que elegir y aplicar el método más fuerte después de que estuviera disponible. Posteriormente, AWS anunció unahoja de ruta de IMDSv2 por defectoque movió los inicios rápidos de 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. El cambio obligatorio inmediato puede romper el software existente; la opcionalidad prolongada deja las viejas suposiciones 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 trabajos pendientes de funcionalidades.

Para las juntas, la lección es preguntar sobre la deuda de valores predeterminados. ¿Cuántas cargas de trabajo aún dependen 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 organizacional impide nuevas excepciones? ¿Cómo sabe la compañía que una cuenta adquirida o un entorno de desarrollo no se ha desviado? Una característica segura que está disponible pero no medida produce menos seguridad que un programa de migración vinculado al inventario y la aplicación.

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

La brecha 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 que seis millones de canadienses se vieron afectados, incluidos algunos cuyos Números de Seguro Social habían sido accedidos. Lapágina del incidente canadiensede Capital One proporcionó avisos y soporte específicos del país. El impacto transfronterizo convierte la localidad de una cuestión abstracta de adquisición de nube en una cuestión de responsabilidad.

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

AWS dice en susmateriales de privacidad de datosque los clientes controlan el contenido del cliente y que las obligaciones del proveedor y del cliente siguen el modelo de responsabilidad compartida. Sumarco de soberanía digitalactual enfatiza 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 de soberanía completo.

La localidad responde dónde está configurado un servicio para almacenar o procesar datos en operación normal. La seguridad también debe responder 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 se aceptó un rol 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.

Por lo tanto, los controles de soberanía necesitan al menos cuatro capas. La primera es la colocación: regiones aprobadas, configuraciones de replicación, copias de seguridad, análisis, recuperación de desastres y servicios de soporte. La segunda es la autoridad: identidades, uso de claves, acceso a metadatos y políticas que restringen las llamadas por red, cuenta, organización o región. La tercera es la observabilidad: registros retenidos en una cuenta controlada independientemente, evidencia de transferencias entre regiones, alertas para ubicaciones de origen inusuales y registros disponibles para los reguladores pertinentes. La cuarta es la salida y 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, proveedor o mecanismo de transferencia legal deja de estar disponible.

El incidente también muestra que la geografía del sujeto de datos puede importar incluso cuando la geografía de la infraestructura es incierta. Los reguladores canadienses, los individuos afectados, las prácticas de notificación y las necesidades de remediació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 la que los ingenieros los ven.

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

Capital One dijo que la categoría afectada más grande incluía datos de aplicaciones 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 con 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 a menudo se trata como un calendario de privacidad separado de la seguridad en la nube. La brecha 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 calendario de eliminación perfecto no puede impedir que un atacante lea registros actuales, pero puede evitar que un evento de credencial exponga catorce años de historial de aplicaciones. 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 trabajo 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 comercial para la retención; separar los datos operativos activos de los archivos restringidos; minimizar los campos; tokenizar los identificadores duraderos; aplicar la eliminación; preservar solo los registros sujetos a una excepción documentada; y probar 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 vencimiento.

La arquitectura de datos también debe 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 el historial de esta institución" se vuelve peligrosamente pequeña.

La dependencia de la nube incluye la dependencia de la evidencia

Capital One no solo alquilaba discos remotos. Como cualquier gran cliente de nube, dependía de la semántica de identidad definida por el proveedor, el comportamiento de los metadatos, el registro de API, las construcciones de región, los controles de almacenamiento, la disponibilidad del servicio, la documentación y 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 compañía tuvo que investigar un gran entorno de nube, identificar los registros afectados, notificar a las personas en dos países, trabajar con las fuerzas del orden y los reguladores, proporcionar monitoreo, defenderse de litigios y remediar los controles mientras seguía operando. Esto es continuidad bajo evidencia comprometida: los servicios pueden permanecer 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 2019de Capital One informó de 72 millones de dólares en gastos incrementales de respuesta y remediación en 2019, compensados por 34 millones de dólares de recuperaciones de seguros. La compañía esperaba estar 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 costos que se extenderían más allá de 2019. Advirtió de intervención regulatoria, litigios, costos de remediació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 acuerdo colectivo de 190 millones de dólares, y no deben sumarse casualmente porque el seguro, 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 recopilación forense, deberes de preservación, información de región y subprocesadores, acceso a informes de control, comunicación de vulnerabilidades y un proceso para solicitudes gubernamentales y de reguladores. 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 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 datos y evidencia, no un recuento decorativo de proveedores.

Lo que resolvieron los acuerdos y lo que dejaron abierto

El acuerdo de consumidores es sustancial, pero su significado debe expresarse con cuidado. El acuerdo creó un fondo de 190 millones de dólares para pérdidas de bolsillo 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 comerciales. La orden de aprobación final consideró el acuerdo justo, razonable y adecuado y desestimó las reclamaciones de 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 evidencia. No determinó que el diseño de metadatos de AWS causara un porcentaje especificado del daño o que la configuración de Capital One causara el resto. No borró la responsabilidad penal de Thompson, y no 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 aun así agregar un protocolo más seguro. Un cliente puede disputar las conclusiones del regulador y aun así aceptar una orden y reformar los controles. Una junta puede reservarse defensas legales mientras trata los hechos operativos como urgentes. La postura legal y la postura de remediación pueden diferir sin contradicción.

La OCC anunció posteriormente querescindió la orden de cese y desistimiento de 2020con efecto el 31 de agosto de 2022. La rescisión es un punto final importante para esa orden en particular. No cancela la multa, 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 de evidencia práctico 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, la accesibilidad a metadatos, las identidades adjuntas, los métodos y cabeceras permitidos, y la autoridad máxima 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 se necesitan metadatos, si se pueden desactivar, qué versión de protocolo se requiere, el límite de saltos, las restricciones del firewall local, las implicaciones para 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 credenciales.Para cada rol en tiempo de ejecución, enumerar los prefijos de almacenamiento, bases de datos, colas, secretos, operaciones de clave y acciones administrativas que puede alcanzar. Estimar cuántos datos sensibles podrían leerse dentro de una vida útil de credencial y desde qué ubicaciones de red. Probar los permisos efectivos, incluyendo la intersección de políticas de identidad, recurso, clave, endpoint 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 la 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 clave 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 regiones aprobadas para el almacenamiento primario, réplicas, análisis, copias de seguridad y recuperación. Registrar cualquier servicio que necesariamente mueva contenido o datos de soporte. Probar la denegación entre regiones y entre cuentas, no solo la ubicación configurada.

Poseer el rastro de auditoría.Enrutar los eventos de identidad, metadatos, almacenamiento, clave, red y pérdida de datos a un entorno de registro administrado independientemente. 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 controles.El catálogo de controles de nube, el inventario de activos, el inventario de configuración, el catálogo de datos, el registro de riesgos y el universo de auditoría de la gerencia 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 reportarse como cobertura desconocida.

Escalar los hallazgos repetidos y vencidos.Una brecha de configuración con una fecha de remediació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 el plazo. El cierre debe requerir evidencia independiente de que la condición de riesgo cambió.

Ejercitar la respuesta transfronteriza.Un simulacro de brecha debe identificar qué poblaciones y reguladores están implicados, qué registros muestran ubicación y 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 soporte forense, la notificación de incidentes, la preservación de evidencia, los compromisos de región, la transparencia de 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 aún puede permitir que una petición pública se convierta en una exportación autorizada. La responsabilidad pertenece a las intersecciones.

La prueba duradera

La brecha 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 brecha. Eso ignora la configuración controlada por el cliente, los permisos, la arquitectura de datos, la supervisió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 colocó el asunto completamente en el cliente. Eso trata un diagrama del proveedor como el fin del análisis de diseño y pasa por alto el valor de defensas más fuertes del servicio de metadatos, valores predeterminados más seguros, telemetría del proveedor y evidencia contractual.

El mejor relato sigue la cadena. Un control orientado al público podía retransmitir una petición no intencionada. La petición alcanzó un límite de confianza de metadatos. La identidad temporal resultante tenía suficiente autoridad para listar y copiar información almacenada. El cifrado no impidió que una credencial aceptada como autorizada leyera datos. La supervisió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á. Los informes de auditoría y 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 luego se separó por foro. El atacante fue condenado. Los reguladores bancarios impusieron obligaciones consentidas y una multa a Capital One. Los consumidores persiguieron 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 remediación, mejoró la supervisión de la junta y soportó costos sustanciales de respuesta, ejecución y acuerdo.

Para las juntas futuras, la pregunta decisiva no es si el proveedor de nube está certificado, el bucket está cifrado o la regla de firewall ha sido arreglada. 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 lo suficientemente rápido para gobernar el riesgo.

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