Principios de seguridad para arquitectos

La seguridad como cualidad de la estructura

El Capítulo 2 presentó la seguridad como atributo de calidad: la capacidad del sistema de proteger datos y funciones frente al uso no autorizado mientras sirve a quienes sí están autorizados, expresada mediante escenarios de seguridad comprobables que nombran un atacante, un ataque, un objetivo y una respuesta medible. Este capítulo da el paso siguiente y se pregunta cómo produce la arquitectura esa cualidad. La respuesta es que la mayoría de las propiedades de seguridad las decide la estructura: qué componentes existen, cuáles confían en cuáles, dónde se almacenan y se copian los datos y por qué pocos puntos debe pasar cada solicitud.

Piensa en cómo se producen las brechas reales. Un atacante cambia el número de pedido en una URL y ve la dirección de otro cliente, porque el servicio comprobó que el usuario había iniciado sesión, pero no que el pedido fuera suyo. Un bucket de almacenamiento con exportaciones de la base de datos se puede leer desde internet porque alguien cambió un valor predeterminado hace años. Un servicio interno de informes acepta cualquier solicitud que venga de dentro de la red, así que una sola computadora portátil comprometida llega a todos los registros de clientes. Ninguno de estos casos necesita criptografía ingeniosa para explotarse; cada uno es una decisión de diseño sobre la confianza que nadie tomó de forma explícita. Seguridad desde el diseño significa tomar esas decisiones de forma deliberada, pronto y por escrito, y después hacer que sea difícil violarlas por accidente.

Por eso la arquitectura de seguridad se sitúa junto a las demás inquietudes transversales de la sección 8 de arc42: un modelo de identidad, un modelo de autorización, un concepto de protección de datos y un concepto de logging que todos los equipos siguen. El resto de esta sección establece el vocabulario y los principios sobre los que se apoyan las demás secciones del capítulo.

Confidencialidad, integridad y disponibilidad en un sistema real

La tríada CIA es el punto de partida. En la plataforma de reparto de comida, la confidencialidad abarca los nombres, direcciones, números de teléfono e historiales de pedidos de los clientes, la ubicación en tiempo real y los documentos de identidad de los repartidores, los datos bancarios a los que se pagan las liquidaciones de los restaurantes y los propios secretos de la plataforma. La integridad abarca los precios, los totales del carrito, los reembolsos, los pagos a los repartidores y la carta que ve el cliente: un atacante que puede poner a cero el precio de un plato, o desviar las liquidaciones de un restaurante a su propia cuenta bancaria, no ha leído nada secreto, pero ha causado un daño grave. La disponibilidad importa sobre todo durante el pico de la noche, cuando un ataque de denegación de servicio o una infección de ransomware cuesta ingresos a cada minuto.

ISO/IEC 25010:2023 añade la autenticidad (las identidades se pueden demostrar), la responsabilidad (las acciones se pueden atribuir a quien las realizó), el no repudio (se puede demostrar que las acciones ocurrieron) y la resistencia (el producto sigue funcionando como se espera bajo ataque). Los arquitectos deben nombrar qué propiedades importan para cada activo, porque tiran en direcciones distintas. Fallar en cerrado protege la confidencialidad y la integridad, pero cuesta disponibilidad: si el servicio de autorización está caído, un servicio de pedidos que falla en cerrado rechaza los pedidos. Fallar en abierto preserva la disponibilidad y se juega todo lo demás. La elección correcta varía según la operación: ver una carta pública puede fallar en abierto hacia una copia en caché, mientras que emitir un reembolso debe fallar en cerrado.

Los principios de diseño de Saltzer y Schroeder

En 1975, Jerome Saltzer y Michael Schroeder, a partir de su experiencia con el sistema operativo Multics en el MIT, publicaron ocho principios de diseño para los mecanismos de protección en The Protection of Information in Computer Systems. Medio siglo después siguen siendo la base más citada del diseño seguro, porque tratan de la estructura y no de la tecnología. La tabla reformula cada uno y da un ejemplo actual de la plataforma de reparto de comida.

Defensa en profundidad

La defensa en profundidad consiste en superponer varios controles independientes, de modo que el fallo o la elusión de uno no deje el activo al descubierto. La idea procede de la fortificación militar y es práctica habitual tanto en la ingeniería de seguridad física (safety) como en la seguridad. Su valor depende por completo de la palabra independientes: dos capas que fallan por la misma razón, como dos servicios que confían en la misma cabecera falsificada, son una sola capa dibujada dos veces.

El diagrama muestra las capas en la ruta de un pedido en la plataforma de reparto de comida. Si la validación de tokens del gateway tiene un error, la comprobación a nivel de objeto del servicio de pedidos sigue impidiendo que un cliente lea el pedido de otro. Si un atacante roba las instantáneas de disco de la base de datos, el cifrado en reposo con claves guardadas en otro lugar las protege. Si todo eso falla, la monitorización debería detectar el patrón inusual de solicitudes y alguien debería responder. La defensa en profundidad es también la respuesta honesta a la pregunta "¿y si falla este control?", que todo modelo de amenazas plantea.

Seguro por defecto y seguro desde el diseño

Un producto es seguro por defecto cuando su configuración de fábrica es la segura, de modo que debilitar la protección requiere un acto deliberado. Muchas brechas grandes se debieron a valores predeterminados inseguros que nadie cambió: bases de datos que escuchaban en internet sin contraseña, consolas de administración con las credenciales de fábrica, buckets de almacenamiento que podían hacerse públicos con un solo ajuste. Los proveedores han reaccionado: desde abril de 2023, por ejemplo, los nuevos buckets de Amazon S3 se crean con Block Public Access activado y las listas de control de acceso desactivadas. En 2023, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA) y agencias asociadas de varios países publicaron una guía conjunta que instaba a los fabricantes a hacer productos seguros desde el diseño y por defecto, y en 2024 CISA lanzó un compromiso voluntario, el Secure by Design pledge, para los fabricantes de software.

Para los arquitectos, el principio de seguro por defecto se aplica a la plataforma tanto como a los productos. Si la plantilla de servicio compartida ya incluye la validación de tokens, el logging de seguridad estructurado, un usuario de contenedor que no es root y una cuenta de base de datos con mínimo privilegio, cada nuevo servicio empieza siendo seguro y los equipos tienen que renunciar a ello de forma explícita, lo que se ve en la revisión. Es lo que algunas organizaciones llaman un camino pavimentado (paved road): el camino más fácil es también el seguro.

Muy relacionado está cómo se comporta un sistema cuando algo sale mal. El OWASP Top 10:2025 añadió una categoría para la mala gestión de condiciones excepcionales, que incluye fallar en abierto: un error en una comprobación de permisos que se captura y se ignora, un timeout que por defecto da "permitido", un fallo de análisis que se salta la validación. Los valores predeterminados a prueba de fallos, aplicados en el código, significan que toda ruta de excepción en una decisión de seguridad termina en denegación.

Superficie de ataque y límites de confianza

La superficie de ataque es todo lo que un atacante puede alcanzar e influir: los endpoints públicos y sus parámetros, los puertos abiertos, las subidas de archivos, las colas de mensajes que aceptan entradas de socios, los webhooks, las consolas de administración, las apps para dispositivos móviles que se pueden descompilar, y el código de terceros y las personas en los que confía el sistema. Michael Howard, de Microsoft, popularizó la idea de medirla a principios de la década de 2000; la regla práctica es hacerla lo más pequeña posible y saber exactamente qué hay en ella. Eliminar un endpoint sin uso, cerrar a internet un puerto de administración o desactivar una funcionalidad que nadie usa reduce el riesgo de forma más barata que cualquier control añadido. Cada elección de estilo arquitectónico del Capítulo 6 tiene aquí un costo de seguridad: cada nuevo servicio accesible por red añade endpoints, credenciales y tráfico que proteger.

Un límite de confianza es el punto en el que los datos o el control pasan entre partes con distintos niveles de confianza o de privilegio. El más evidente está entre internet y la plataforma, pero hay muchos más: entre la app del cliente y la API, entre la tableta de un restaurante y el servicio de carta, entre servicios de equipos distintos, entre la plataforma y un proveedor de pagos, entre el código de la aplicación y la base de datos, y entre los usuarios corrientes y los administradores. Los límites de confianza importan porque es ahí donde deben estar las comprobaciones: la autenticación, la autorización, la validación de la entrada y la codificación de la salida se hacen cuando los datos cruzan un límite, nunca suponiendo que el otro lado ya las ha hecho. Dibujar los límites de confianza en un diagrama de flujo de datos es el primer paso del modelado de amenazas.

El OWASP Top 10 como lista de concienciación

El OWASP Top 10 es la lista clasificada de los riesgos de seguridad más críticos de las aplicaciones web que elabora el Open Worldwide Application Security Project a partir de datos de vulnerabilidades aportados y de una encuesta a la comunidad. La edición actual, el OWASP Top 10:2025, es la octava. Frente a la edición de 2021, el control de acceso roto (broken access control) sigue en primer lugar y ahora incluye la falsificación de solicitudes del lado del servidor (SSRF), la configuración de seguridad incorrecta sube al segundo puesto, la antigua categoría de componentes vulnerables y desactualizados se amplía hasta convertirse en fallos de la cadena de suministro de software, y una nueva categoría cubre la mala gestión de condiciones excepcionales.

Trata la lista como lo que OWASP dice que es: un documento de concienciación, no una norma. Es útil para la formación, para comprobar que un modelo de amenazas no ha pasado por alto toda una clase de problemas y para hablar con las partes interesadas. No es un conjunto completo de requisitos, y "cumplimos el OWASP Top 10" significa poco. Para requisitos verificables, el Application Security Verification Standard (ASVS) de OWASP enumera controles comprobables en tres niveles de rigor, y el OWASP API Security Top 10, independiente del anterior, cubre los riesgos propios de las API, como la autorización a nivel de objeto rota (broken object-level authorisation).

Un ciclo de vida de desarrollo seguro y el shift left

Un ciclo de vida de desarrollo seguro integra actividades de seguridad en cada etapa de la entrega, en lugar de depender de una prueba justo antes del lanzamiento. Microsoft hizo obligatorio su Security Development Lifecycle en 2004, tras el memorando Trustworthy Computing de Bill Gates de 2002, y la idea se extendió por todo el sector. La referencia actual es el Secure Software Development Framework (SSDF) del NIST, SP 800-218, cuya versión 1.1 se publicó en febrero de 2022; el NIST publicó un borrador de revisión (versión 1.2) para comentarios en diciembre de 2025, que no se había aprobado de forma definitiva en el momento de redactar este texto. El SSDF agrupa las prácticas en cuatro familias: preparar a la organización (roles, formación, cadenas de herramientas, requisitos de seguridad), proteger el software (proteger la integridad del código y de la compilación, conservar la procedencia), producir software bien protegido (diseñar para cumplir los requisitos de seguridad, modelar amenazas, revisar y probar, configurar de forma segura por defecto) y responder a las vulnerabilidades (identificarlas, corregirlas y analizar las causas raíz para que la misma clase no se repita). Describe resultados en lugar de prescribir herramientas, lo que lo convierte en una buena lista de comprobación para un arquitecto que evalúa un proceso de entrega.

Hacer shift left (desplazar a la izquierda) es adelantar el trabajo de seguridad: requisitos de seguridad y casos de abuso junto con las historias de usuario, modelado de amenazas en el diseño, análisis estático y detección de secretos en cada commit, comprobación de dependencias en el pipeline. El argumento económico es conocido desde el Capítulo 1: una comprobación de autorización ausente que se detecta en una revisión de diseño cuesta una hora; el mismo defecto detectado tras una brecha cuesta una notificación a los reguladores. Los profesionales discrepan sobre hasta dónde llevarlo. Sus defensores dicen que los desarrolladores que entienden de seguridad escriben menos vulnerabilidades. Sus críticos señalan que limitarse a poner herramientas de seguridad delante de los desarrolladores los inunda de hallazgos de baja calidad y convierte la seguridad en el trabajo a tiempo parcial de todos y en la especialidad de nadie; abogan por valores predeterminados seguros integrados en la plataforma (el camino pavimentado), para que el camino seguro no exija un esfuerzo adicional, y por especialistas en seguridad integrados allí donde el riesgo es mayor. La mayoría de las organizaciones maduras hacen ambas cosas y además siguen probando y monitorizando en producción, por lo que algunas hablan ya de llevar la seguridad a todas partes (shifting security everywhere).

Qué es responsabilidad de los arquitectos y qué de los desarrolladores

El trabajo de seguridad es compartido, y la confusión sobre quién es responsable de qué es en sí misma una vulnerabilidad. El arquitecto es responsable de las decisiones que cruzan los límites entre equipos y son caras de cambiar; los equipos son responsables de aplicarlas correctamente. Un patrón habitual es un pequeño equipo central de seguridad que fija los estándares y gestiona los servicios de seguridad de la plataforma, campeones de seguridad (security champions) en cada equipo de producto que dirigen el modelado de amenazas y las revisiones, y arquitectos que se aseguran de que las decisiones estructurales se tomen y se registren.