Seguridad, privacidad y cumplimiento desde el diseño

Te damos la bienvenida al Capítulo 8: Seguridad, privacidad y cumplimiento desde el diseño. La mayoría de las brechas graves no se deben a un ataque exótico contra la criptografía. Proceden de decisiones estructurales. Un servicio interno que confiaba en cualquier llamante de la red. Una API de administración que se saltaba una comprobación de autorización. Una clave de acceso subida en un commit a un repositorio. Cada una fue una decisión arquitectónica sobre dónde reside la confianza, qué componente puede hacer qué y por dónde viajan los datos.

Este capítulo es para desarrolladores y arquitectos que conocen las arquitecturas distribuidas y de datos de los Capítulos 6 y 7, y que ahora deben hacerlas seguras. Cada límite de servicio, cola, caché, réplica y copia analítica aumenta la superficie de ataque. La distribución multiplica los límites de confianza, y la arquitectura de datos decide cuántas copias de datos personales existen y cuánto tiempo viven. El capítulo trata la seguridad como un atributo de calidad diseñado en la estructura, en el sentido de los escenarios de seguridad del Capítulo 2, y no como una lista de productos que se compran al final. También da por sabida la sección del Capítulo 0 sobre redes, HTTPS y TLS. Y conduce al Capítulo 9, que mantiene el sistema protegido rápido y en funcionamiento bajo presión.

El ejemplo recurrente es la plataforma de reparto de comida que se usa a lo largo de todo el curso: clientes, restaurantes y repartidores, un API gateway, los servicios de pedidos, pagos, despacho y notificaciones, un flujo de eventos y un almacén de datos. La sección ocho punto uno establece el vocabulario: confidencialidad, integridad y disponibilidad, los principios de diseño de Saltzer y Schroeder de 1975, como el mínimo privilegio, y después la defensa en profundidad, los valores predeterminados seguros y el OWASP Top 10. La sección ocho punto dos convierte esos principios en una actividad de diseño repetible. Dibujas un diagrama de flujo de datos con sus límites de confianza, te preguntas qué puede salir mal con STRIDE y árboles de ataque, valoras los riesgos y decides las mitigaciones. La sección ocho punto tres trata de quién llama: contraseñas, passkeys, sesiones y tokens, OAuth con PKCE, OpenID Connect y los principales modelos para decidir qué puede hacer cada llamante. La sección ocho punto cuatro trata el cifrado en tránsito y en reposo, el hash de contraseñas, la gestión de claves con cifrado de sobre, los secretos, la tokenización y la decisión sobre qué cifrar y dónde.

Esta es una de las ideas centrales de la sección ocho punto uno, la defensa en profundidad, dibujada a lo largo del recorrido de un pedido por la plataforma. Arriba está la app del cliente, fuera del límite de confianza. Se comunica con la plataforma solo por HTTPS, y la plataforma no confía en nada de lo que hay en el dispositivo. Dentro del límite, cada capa añade sus propios controles. El borde absorbe las avalanchas de tráfico, aplica límites de tasa y bloquea patrones de ataque conocidos. El API gateway comprueba cada token y rechaza las solicitudes que no se ajustan al esquema de la API. El servicio de pedidos comprueba que este cliente puede ver este pedido en concreto. La base de datos usa una cuenta con mínimo privilegio y está cifrada en reposo, con copias de seguridad cifradas con claves distintas. El logging de seguridad, la detección y las alertas abarcan todas las capas. Como cada capa tiene sus propios controles, saltarse un único control no deja los datos al descubierto.

Las cuatro secciones siguientes amplían la mirada. La sección ocho punto cinco sustituye la idea de una red interna de confianza por la autenticación y la autorización de cada solicitud entre servicios, mediante TLS mutuo, certificados y puntos separados en los que se decide y se aplica la política. La sección ocho punto seis trata las dependencias, los sistemas de compilación y las imágenes de contenedor como parte de la superficie de ataque, con listas de materiales de software, la firma y el Reglamento de Ciberresiliencia de la UE. La sección ocho punto siete explica cómo el RGPD y el RGPD del Reino Unido dan forma a la arquitectura: minimización de datos, seudonimización, los derechos de las personas a las que se refieren los datos, la conservación y la supresión en las copias de seguridad y los logs de eventos. Y la sección ocho punto ocho cierra el ciclo con el logging de seguridad, la detección, la gestión de vulnerabilidades, la respuesta a incidentes y la notificación de violaciones de datos.

Este diagrama de la sección ocho punto cinco muestra lo que cambia zero trust. Antes, en una red interna plana, cualquier host puede llegar a cualquier puerto, y todos los servicios comparten una sola base de datos. Cuando el servicio de carta queda comprometido, el atacante puede ir directamente a pagos. Después, cada servicio tiene su propia base de datos, y solo identidades con nombre pueden hacer las llamadas permitidas. Pedidos llama a pagos mediante TLS mutuo, con una política. Cuando el servicio de carta comprometido intenta llamar a pagos, se le deniega. Fíjate en lo que zero trust no hace. No impide que un servicio quede comprometido. Limita lo que el servicio comprometido puede alcanzar.

Un arquitecto no necesita ser un pentester ni un criptógrafo, y no debe inventar criptografía. El arquitecto toma las decisiones que son caras de cambiar: dónde se sitúan los límites de confianza y qué proveedor de identidad y qué modelo de tokens usa toda la plataforma. También qué datos se clasifican como restringidos y se cifran con qué claves, y cómo demuestran los servicios su identidad entre sí. Estas decisiones tienen su lugar en los registros de decisiones de arquitectura, como cualquier otra decisión significativa. Los desarrolladores son responsables de un conjunto igual de importante: validar la entrada, codificar la salida, usar correctamente las bibliotecas de seguridad de la plataforma, manejar los errores sin fallar en abierto y mantener las dependencias actualizadas. Ambos se encuentran en el modelado de amenazas, en las revisiones de diseño seguro y en las comprobaciones automatizadas del pipeline de entrega.

La seguridad y la privacidad están llenas de normas numeradas y disposiciones legales. El capítulo las nombra con precisión, indica la edición vigente en el momento de redactarlo, octubre de 2026, y remite a la fuente oficial. El material sobre la regulación explica cómo afecta la ley a la arquitectura. Es información, no asesoramiento jurídico. Para una situación concreta, los abogados y el delegado de protección de datos de cada organización siguen siendo las personas a quienes consultar.

Si recuerdas una sola cosa de este capítulo, que sea esta. Decide en quién y en qué confía tu sistema, para qué y por qué. Decídelo de forma deliberada, pronto y por escrito, en lugar de dejarlo implícito. Y haz que cada una de esas decisiones de confianza sea verificable. Los modelos de amenazas, el mínimo privilegio, los ámbitos (scopes) de OAuth, el cifrado de sobre, el TLS mutuo, las compilaciones firmadas y los logs de auditoría son formas de sustituir la confianza implícita por una confianza explícita y comprobable. Un sistema diseñado así limita el daño de la brecha que acabará llegando y puede mostrar a sus clientes, auditores y reguladores cómo los protege.

Lo mejor es leer las secciones en orden. Pero cada una se sostiene también por sí sola, así que puedes ir directamente a la sección que necesites. Calcula unas tres horas y media para leer el capítulo completo. Al final de cada sección hay preguntas de autoevaluación. Respóndelas mentalmente antes de mirar las respuestas. Cuando estés listo, hay una prueba opcional del capítulo, que dura unos cuarenta y cinco minutos. Tiene veinte preguntas de opción múltiple y dos respuestas escritas. La nota de aprobado es el ochenta por ciento.

Esa es la estructura del capítulo. Empieza por la sección ocho punto uno, principios de seguridad para arquitectos, donde se establece el vocabulario de todo lo que sigue. Nos vemos allí.