Al final de la lección anterior quedó una grieta abierta en el catálogo de controles: hay controles cuya eficacia no depende de Nimbus. C-03 exige acceso just-in-time a una consultora con sus propios procesos; C-19 replica copias a la región de un proveedor cuyas decisiones nadie de Nimbus toma; el CI arrastra cientos de dependencias escritas por desconocidos. Y el detalle que lo resume todo: el vector del incidente de 02-06 no fue un fallo de Nimbus, sino una brecha en la consultora que Nimbus ni siquiera llegó a conocer hasta el día 20. Esta lección trata de esa parte del perímetro que no controlas y sí respondes: cómo se elige un proveedor, qué se le exige por contrato, cómo se supervisa, cómo se le da de baja, y cómo se gestiona el riesgo del software de terceros que forma parte de tu producto.

1. El perímetro que no controlas: se externaliza la ejecución, nunca la responsabilidad
2. El mapa de terceros de Nimbus
3. El regreso de la consultora: anatomía del vector de 02-06
4. El ciclo de vida de la gestión de proveedores
5. Diligencia debida proporcionada al riesgo
6. Qué debe decir el contrato
7. Responsabilidad compartida en la nube
8. Cadena de suministro de software
9. Supervisión continua y el incidente que no es tuyo
10. El registro de terceros como artefacto

Cuando una clínica de fisioterapia contrata Nimbus, no contrata «Nimbus y sus doce proveedores»: contrata a Nimbus. Si el proveedor de email transaccional filtra los correos de recordatorio de citas, la clínica llamará a Rubén, no al proveedor. Y si los datos que se exponen revelan qué pacientes acuden a qué tratamiento, quien tendrá que dar explicaciones —y, muy probablemente, notificar— será Nimbus.

De ahí la asimetría fundamental de esta lección:

Existe una traducción jurídica de esta idea. Cuando un tercero trata datos personales por cuenta de Nimbus, la normativa europea distingue entre responsable del tratamiento —quien decide para qué y cómo se tratan los datos, que aquí es la clínica, siendo Nimbus responsable a su vez frente a sus propios empleados— y encargado del tratamiento, que es quien los trata siguiendo instrucciones. Un proveedor de infraestructura o de correo transaccional suele ser encargado (o subencargado) de Nimbus. La consecuencia práctica que importa hoy es que elegir mal a un encargado y no vigilarlo es un incumplimiento propio, no ajeno.

Nota de validación. La calificación de cada tercero como encargado, subencargado o responsable independiente, y las obligaciones contractuales asociadas, dependen del caso concreto y tienen consecuencias legales directas. Aquí se presenta solo la idea; el desarrollo corresponde a 06-03. Antes de firmar un contrato de encargo de tratamiento, revísalo con asesoría jurídica o con tu responsable de cumplimiento.

Antes de gestionar hay que listar, y la mayoría de las PYMES descubre aquí que tiene el doble de proveedores de los que creía. La columna que más conversaciones provoca es la última.

Tres lecturas del mapa. Primera: la superficie de terceros es mayor que la propia. Nimbus tiene 22 activos y nueve categorías de tercero, y varias de ellas tocan datos que revelan salud. Segunda: el gestor de incidencias parece inofensivo hasta que recuerdas que los clientes adjuntan capturas de pantalla con datos reales de pacientes al abrir una incidencia; ese es el proveedor que todo el mundo clasifica mal. Tercera: las dependencias de software libre son el único tercero con el que no hay contrato, ni interlocutor, ni SLA, y sin embargo su código se ejecuta con los mismos privilegios que el de Iván.

Prometido en 03-07 y aquí está. Recuerda la cronología: día −45, la consultora sufre una brecha y se filtran credenciales de acceso a sus clientes; no se lo comunica a nadie. Día 0, 22:14, alguien entra en Nimbus con la cuenta compartida de la consultora, sin MFA, y nadie lo nota porque el acceso nocturno de la consultora es habitual. Veinte días después, 1,2 TB exfiltrados y las copias destruidas.

Cinco condiciones tuvieron que darse a la vez, y ninguna era técnica:

Y el coste de no haberlas evitado, según el análisis de 02-06: 40 clínicas paradas, 1,2 TB de datos que revelan salud en manos de un atacante, copias destruidas, notificación de brecha con alcance indeterminado —porque los logs habían rotado a los 7 días— y pérdida de clientes. Es decir: cinco medidas de coste esencialmente nulo separaban a Nimbus del peor día de su historia.

Hay un detalle todavía más incómodo. Las tres primeras condiciones son de Nimbus, pero la brecha ocurrió en la consultora, y Nimbus no se enteró durante 45 días. Aunque Nimbus hubiera tenido MFA, seguiría sin saber que su proveedor había sido comprometido. La cláusula de notificación no es papeleo: es el único mecanismo por el que la información llega desde el perímetro que no controlas.

Lo que debería haber existido, en el orden en que se implanta:

1. Cuentas nominales por técnico con su nombre y su correo, nunca una cuenta «consultora».
2. MFA resistente al phishing obligatorio, sin excepción y por escrito en el contrato.
3. Acceso just-in-time: no existe hasta que se solicita, dura 8 horas y se revoca solo (C-03).
4. Registro de sesión conservado 12 meses, con alerta ante acceso fuera de la ventana pactada (C-09).
5. Revisión trimestral de quién de la consultora sigue teniendo acceso y por qué (C-22).
6. Cláusula contractual de notificación de incidentes con plazo de 24-48 horas.

Las dos fases que más se descuidan son la 1 y, sobre todo, la 5. Cuando una empresa deja de trabajar con un proveedor, la relación comercial acaba el día que se cancela la factura; los accesos técnicos, no. La salida tiene su propia lista de comprobación:

• Revocar todas las cuentas del proveedor, incluidas las de servicio y las claves API que emitiste tú.
• Retirar sus IP de cualquier lista de permitidos y sus certificados o claves SSH.
• Recuperar tus datos en un formato usable antes de cerrar la cuenta, no después.
• Exigir certificado de borrado de tus datos en sus sistemas y en sus copias, con la fecha en que caducan sus propias copias de seguridad.
• Desconectar integraciones, webhooks y secrets del CI que apunten a su servicio.
• Anotar la baja en el registro de terceros con fecha, para que la próxima revisión no lo busque.

Es un trabajo de dos horas que casi nadie hace, y produce exactamente el tipo de acceso huérfano que aparece en los casos de estudio de 02-06.

El principio rector: no le pidas a un proveedor de 3 personas lo mismo que a uno de 3.000. Un cuestionario de 200 preguntas enviado a una consultora local produce dos resultados garantizados: no lo contestan, o lo contestan mintiendo. Proporciona el esfuerzo a la criticidad:

Es el documento que más se pide y menos se lee. Cuatro claves:

• Tipo I frente a Tipo II. El Tipo I dice que los controles estaban diseñados en una fecha; el Tipo II dice que funcionaron durante un periodo (normalmente 6-12 meses). Solo el segundo demuestra eficacia, que es justo la distinción de 04-03.
• El alcance lo es todo. Un informe puede cubrir solo un producto o una región. Si tus datos están en el servicio que queda fuera del alcance, el informe no dice nada sobre ti.
• Ve directamente a las excepciones. La sección de resultados de las pruebas lista las desviaciones encontradas por el auditor. Un informe sin ninguna excepción en 12 meses merece una pregunta, no un aplauso.
• Mira los controles complementarios del usuario. Casi todos los informes incluyen una lista de cosas que tú debes hacer para que los controles del proveedor funcionen. Es la responsabilidad compartida del apartado 7, escrita con nombre y apellidos.

Nota de validación. Todas estas cláusulas tienen efectos jurídicos y económicos, y varias interactúan con la normativa de protección de datos (contrato de encargo de tratamiento) y con la de contratación mercantil. Redáctalas o revísalas con asesoría jurídica; el contenido de esta tabla es una lista de comprobación de temas, no un texto contractual.

Un consejo práctico de negociación para una empresa del tamaño de Nimbus: con los grandes proveedores cloud o SaaS no vas a negociar nada, así que tu trabajo no es redactar cláusulas sino leer las suyas y decidir si el riesgo residual es aceptable (04-01). Donde sí tienes capacidad real de negociación es con los proveedores pequeños —la consultora, la gestoría—, que son justamente los que suelen tener contratos más pobres. Ahí es donde debes gastar tu energía.

El malentendido más caro de la nube es creer que «el proveedor se encarga de la seguridad». El proveedor se encarga de la seguridad de la nube; tú, de la seguridad en la nube. Dónde cae la línea depende del modelo de servicio:

Fíjate en las tres últimas filas: son siempre de Nimbus, en los tres modelos. Y son exactamente las que fallaron en los incidentes de 02-06: el bucket mal configurado fue un fallo de configuración del cliente, no del proveedor; el hallazgo de PostgreSQL en 0.0.0.0:5432 es configuración de red del cliente; y la credencial en el .env es gestión de identidades del cliente. El proveedor cloud no ha fallado en ninguno de los problemas que tiene Nimbus.

La última fila merece un aviso específico para el SaaS: que tus documentos estén en una suite ofimática en la nube no significa que estén respaldados frente a un borrado tuyo o a un ransomware que cifre lo sincronizado. El detalle técnico de configuración segura de nube y contenedores es de 05-07; aquí basta con saber dónde cae la línea.

Las dependencias son el tercero sin contrato. La API de Nimbus declara unas 40 dependencias directas, que arrastran cientos de transitivas, y todas se ejecutan con los mismos privilegios que el código de Iván.

La defensa base es fijar por hash, no por versión ni por etiqueta, porque una etiqueta se puede reasignar y un hash no.

Un SBOM (Software Bill of Materials) es la lista completa de componentes que contiene un artefacto, con versiones y licencias, en un formato estándar como CycloneDX o SPDX. Su valor no es filosófico, es operativo: el día que se publica una vulnerabilidad crítica en una biblioteca, la pregunta es «¿la usamos?», y sin SBOM la respuesta tarda días.

Uso: ./sbom-nimbus.sh genera y almacena; ./sbom-nimbus.sh log4j responde en segundos a la pregunta que en 2021 tuvo a miles de empresas buscando durante una semana.

Firmar y verificar los artefactos propios (cosign con identidad efímera, 03-07) acredita el origen, no la ausencia de malicia: SolarWinds distribuyó una puerta trasera perfectamente firmada. Por eso la firma se combina con revisión y con una política de actualización explícita:

La última fila es la más barata y la más olvidada: el mejor momento para rechazar una dependencia es antes de añadirla. Una biblioteca con un solo mantenedor, sin publicaciones en dos años y con 300 descargas semanales es un riesgo de cadena de suministro que se evita con una conversación de dos minutos en la revisión de código.

La diligencia debida se hace una vez; el riesgo dura todo el contrato. La supervisión mínima viable de Nimbus:

• Trimestral: revisión de accesos activos de terceros (C-22) y de excepciones vigentes.
• Mensual: revisión de los KPI del SLA y de las alertas de acceso fuera de ventana.
• Continuo: suscripción a los avisos de estado y de seguridad de los proveedores críticos, y vigilancia de menciones públicas de brechas.
• Anual: recuestionario de los proveedores de nivel reforzado y actualización del registro de terceros.

Cuando el incidente es del proveedor, la secuencia importa porque la tentación de esperar información es enorme:

Los dos errores clásicos en este flujo son esperar a que el proveedor confirme antes de revocar sus accesos —el paso 3 no depende de nadie más y es gratis— y dar por hecho que si el proveedor no notifica, no ha pasado nada, que es literalmente lo que ocurrió durante 45 días en 02-06.

Nota de validación. Si el incidente de un proveedor puede afectar a datos personales de tus clientes, existen plazos y obligaciones de notificación que no dependen de la voluntad del proveedor. Consulta con tu responsable de cumplimiento o con asesoría jurídica desde el primer momento; el detalle se trata en 04-05 y 06-03.

Fíjate en T-09: una baja no está completa hasta que llega el certificado de borrado, y dejar ese campo visible como «Pendiente» es lo que impide que la salida se dé por buena antes de tiempo.

• No tener inventario de terceros. No puedes revisar lo que no has listado, y siempre hay más de los que crees. Consejo: empieza por la lista de gastos recurrentes de Sara; ahí están todos los SaaS que nadie declaró.
• Confiar en el sello y no leer el alcance. «Tenemos ISO 27001» no dice nada si el alcance no incluye el servicio que tú contratas. Consejo: pide siempre el certificado con su declaración de alcance y la fecha.
• Contratos que solo hablan de precio y disponibilidad. Es el contrato de la consultora en 02-06. Consejo: la cláusula de notificación de incidentes con plazo en horas es la que más valor aporta por línea escrita.
• Diligencia debida solo al firmar. El proveedor cambia, tú cambias y sus subencargados cambian. Consejo: fija la revisión anual en el registro y trátala como un control con propietario.
• Olvidar la salida. Accesos huérfanos y datos tuyos en sistemas de una empresa con la que ya no hablas. Consejo: la baja no se cierra sin certificado de borrado.
• Pedirle a un proveedor pequeño lo mismo que a uno grande. Consigues una respuesta inventada y una falsa sensación de control. Consejo: proporciona el cuestionario al riesgo y gasta tu energía negociadora donde sí puedes negociar.
• Asumir que la nube incluye copias de seguridad. Ni el SaaS ofimático ni el bucket están respaldados frente a tu propio borrado. Consejo: revisa la tabla de responsabilidad compartida servicio por servicio.
• Fijar dependencias por etiqueta. Una etiqueta móvil equivale a ejecutar lo que el mantenedor decida mañana. Consejo: fija por hash y usa --require-hashes.

Para cada uno de estos cuatro terceros de Nimbus, decide el nivel de diligencia (ligero, estándar o reforzado), indica las tres preguntas más importantes del cuestionario para ese caso concreto y la cláusula contractual que no puede faltar:

1. Una herramienta SaaS de firma electrónica que Sara quiere usar para los contratos laborales.
2. Un servicio de traducción automática que Rubén quiere integrar en el soporte, enviándole el texto de los tickets.
3. La empresa de limpieza de la oficina de Valencia.
4. Un nuevo proveedor de observabilidad al que se enviarían los registros de la API en tiempo real.

Este es el registro real de un tercero de Nimbus. Identifica todos los problemas y ordena las correcciones:

Un lunes por la mañana, Marta lee en un medio especializado que el proveedor de email transaccional de Nimbus (A-11) ha sufrido una intrusión: los atacantes accedieron a los metadatos de envío de una parte de sus clientes durante tres semanas. El proveedor no ha comunicado nada a Nimbus todavía.

1. ¿Qué datos de Nimbus podrían estar afectados, y por qué son sensibles aunque «solo» sean metadatos?
2. Enumera las acciones de las primeras cuatro horas, en orden, indicando cuáles no dependen del proveedor.
3. ¿Qué exigirías por escrito al proveedor y con qué plazo?
4. ¿Qué debería cambiar en el contrato y en el registro de terceros después del incidente?

Ejercicio 1

El punto del ejercicio es el 4. Enviar los registros de la API en tiempo real a un tercero significa que ese tercero recibe una copia continua de lo que pasa en producción, y si el equipo no ha depurado el contenido de sus registros, ahí pueden ir identificadores de pacientes, correos, tokens o fragmentos de datos clínicos. Un proveedor de observabilidad es, en la práctica, un proveedor con acceso a datos de producción, y hay que evaluarlo como tal. Y el 2 enseña la trampa contraria: un servicio «pequeño» y barato puede ser el que saque los datos más sensibles de tu perímetro.

Ejercicio 2

Problemas, de más a menos grave:

1. El proyecto terminó en noviembre de 2025 y la agencia sigue con acceso de administrador al repositorio. Es la fase 5 del ciclo de vida sin ejecutar: un acceso huérfano y privilegiado con cuatro meses de antigüedad. Es exactamente el patrón del vector de 02-06.
2. Cuenta compartida («agencia») en vez de cuentas nominales: no se puede saber quién hizo qué, ni si esa persona sigue trabajando allí.
3. Permisos de administrador en el repositorio cuando el trabajo requería, como mucho, escritura en una rama. Mínimo privilegio incumplido.
4. Sin cláusula de notificación de incidentes y sin devolución ni borrado: si la agencia sufre una brecha, Nimbus no se enterará, y su código sigue en los equipos de la agencia.
5. Nunca evaluada (ultima_evaluacion: null) pese a estar clasificada como criticidad Alta.
6. Acceso a preproducción con clasificación «a revisar»: nadie sabe si la agencia ha estado leyendo datos reales de pacientes durante 18 meses, y esa duda es en sí misma un hallazgo notificable si se confirma.

Orden de corrección: (a) hoy mismo, revocar la cuenta agencia, rotar cualquier clave o token que se le entregara y revisar el registro del repositorio y de la base de datos de preproducción para determinar si hubo actividad después de noviembre. (b) Esta semana, determinar si A-22 contiene datos reales —cerrando por fin la casilla «a revisar» del inventario de 01-04— y, si los contiene, evaluar el alcance con el responsable de cumplimiento. (c) Este mes, completar la salida formal: solicitar por escrito el borrado del código y de los datos con certificado, y anotar la baja en el registro. (d) Antes del próximo proyecto, incorporar la evaluación previa, las cuentas nominales, el permiso mínimo y las cláusulas de notificación y salida.

Ejercicio 3

(1) Los metadatos de envío de un proveedor de email transaccional incluyen destinatario, remitente, asunto, fecha y estado de entrega. En el caso de Nimbus eso es: el correo del paciente, la marca temporal, y muy probablemente un asunto del tipo «Recordatorio de su cita del jueves en Fisioterapia Levante». Aunque no haya ningún dato clínico dentro del mensaje, la combinación de destinatario y clínica revela que esa persona es paciente de un centro sanitario concreto, que es precisamente el tipo de dato que la escala de impacto de 04-01 puntúa con un 5. «Solo metadatos» es, en este contexto, un eufemismo peligroso. Además puede estar afectada la clave API que Nimbus le entregó.

(2) Primeras cuatro horas, en orden. No dependen del proveedor las cuatro primeras: (a) abrir el cuaderno de bitácora del incidente y anotar la hora y la fuente de la noticia (04-05); (b) rotar la clave API que Nimbus tiene en ese proveedor, que es una acción propia, inmediata y sin coste; (c) revisar los registros propios de uso de esa clave por si hubiera envíos no originados por Nimbus; (d) determinar exactamente qué información se envía a ese proveedor —qué campos, con qué asuntos, con qué retención— para poder acotar la exposición sin esperar a nadie; (e) contactar con el proveedor por escrito exigiendo confirmación de si Nimbus está entre los afectados; (f) informar a Marta y activar el equipo de respuesta; (g) preparar, sin enviarlo aún, un borrador de comunicación a clientes.

(3) Por escrito y con plazo de 24 horas: si Nimbus figura entre los clientes afectados; ventana temporal exacta del acceso; qué categorías de datos se vieron comprometidas y si incluyen contenido además de metadatos; si hay evidencia de exfiltración o solo de acceso; qué medidas ha tomado; y si ha notificado a la autoridad de control. Y una petición adicional que casi nadie hace: el listado de los envíos de Nimbus comprendidos en esa ventana, que es lo que permitiría notificar con precisión en lugar de asumir el peor escenario, que fue justo el problema de Nimbus en 02-06.

(4) En el contrato: plazo de notificación explícito en horas (si no lo había o era de 72 h, bajarlo a 24), obligación de facilitar el detalle de los envíos afectados, y declaración actualizada de subencargados. En el registro de terceros: subir la criticidad si estaba infravalorada, adelantar la próxima evaluación, y añadir el incidente al historial del proveedor —dato que pesará en la próxima renovación—. Y en el registro de riesgos de 04-01: este incidente es un disparador de reevaluación, y debería aparecer un riesgo específico sobre la exposición de metadatos de citas a través de terceros, con su propio tratamiento. Una mejora técnica que evalúa bien aquí: reducir los datos enviados al proveedor a un identificador opaco y un asunto genérico, aplicando minimización.

Has aprendido a gestionar la parte del perímetro que no controlas. Partes de la asimetría fundamental: se puede externalizar la ejecución, el coste y el conocimiento técnico, pero nunca la responsabilidad, ni frente al cliente ni frente a la autoridad, ni la reputación de A-20 —con la distinción legal entre responsable y encargado del tratamiento apuntada aquí y desarrollada en 06-03—. Tienes el mapa de terceros de Nimbus con sus nueve categorías, y sus tres lecturas: la superficie de terceros es mayor que la propia, el gestor de incidencias es el proveedor que todo el mundo clasifica mal porque los clientes adjuntan capturas con datos de pacientes, y las dependencias de software libre son el único tercero sin contrato, sin interlocutor y sin SLA cuyo código se ejecuta con todos los privilegios.

Has vuelto a la consultora del incidente de 02-06 y has desmontado su vector: cinco condiciones simultáneas —acceso permanente, cuenta compartida, sin MFA, sin registro ni alerta, sin cláusula de notificación—, ninguna de ellas técnica y todas de coste esencialmente nulo. Con el detalle más incómodo: aunque Nimbus hubiera tenido MFA, habría seguido sin saber durante 45 días que su proveedor estaba comprometido, porque la cláusula de notificación es el único mecanismo por el que la información llega desde el perímetro que no controlas.

Conoces el ciclo de vida del proveedor y en especial su fase 5, la salida, que casi nadie ejecuta: revocar todas las cuentas y claves API, retirar IP y certificados, recuperar los datos antes de cerrar la cuenta, exigir certificado de borrado y anotar la baja. Sabes hacer diligencia debida proporcionada con tres niveles y un cuestionario completo para el nivel reforzado, y sabes leer un informe SOC 2: Tipo II y no Tipo I, el alcance por encima del sello, ir directo a las excepciones y no ignorar los controles complementarios del usuario. Tienes la lista de cláusulas contractuales con su nota de validación jurídica y el consejo de negociación realista: con los grandes no negocias, así que lee y decide; con los pequeños sí, y son los que peores contratos tienen.

Dominas el modelo de responsabilidad compartida, con la observación decisiva de que configuración, identidades y datos son siempre tuyos en IaaS, PaaS y SaaS —y que, en consecuencia, el proveedor cloud no ha fallado en ninguno de los problemas que tiene Nimbus—. Y manejas la cadena de suministro de software: dependencias directas y transitivas, typosquatting, confusión de dependencias, toma de control del mantenedor y compromiso del CI; la fijación por hash de acciones y dependencias frente a las etiquetas móviles; el SBOM firmado, cuyo valor es responder en segundos a «¿usamos ese componente?»; la firma de artefactos que acredita el origen y no la ausencia de malicia, con SolarWinds como recordatorio; y una política de actualización con plazos, cuya línea más barata es la última: el mejor momento para rechazar una dependencia es antes de añadirla. Cierran la lección la supervisión continua, el flujo de respuesta cuando el incidente es del proveedor —donde revocar accesos y rotar claves no depende de nadie y es lo primero— y el registro de terceros, en el que una baja no se cierra hasta que llega el certificado de borrado.

Y fíjate en lo que ha pasado dos veces en esta lección. Al analizar la brecha de la consultora y al responder a la del proveedor de correo, has necesitado algo que todavía no tienes: un cuaderno de bitácora, un equipo con roles, una decisión sobre a quién se comunica y en qué plazo, y una secuencia acordada de antemano. En 02-06, a las 09:00 del día 20, Marta convocó al equipo y nadie sabía qué hacer primero. Ese vacío no lo llena ni el mejor registro de riesgos ni el mejor catálogo de controles.

En la siguiente lección, Plan de Respuesta a Incidentes (04-05), escribirás el plan antes del incidente, porque a las tres de la mañana nadie improvisa bien: las fases del NIST SP 800-61, el equipo de respuesta de Nimbus con suplentes y contactos fuera de banda, la matriz de severidad, la preservación de evidencias antes de tocar nada, las disyuntivas reales de la contención, las plantillas de comunicación a clientes, el cuaderno de bitácora, un runbook desarrollado entero y el post mortem sin culpables aplicado al incidente de 02-06.