La seguridad en el desarrollo de software moderno no es un componente adosado, sino un atributo transversal que debe estar integrado desde el diseño arquitectónico.

En sistemas distribuidos, microservicios, aplicaciones nativas de la nube y arquitecturas basadas en eventos, el riesgo se multiplica y las superficies de ataque se amplifican.

Por lo tanto, es necesario adoptar patrones de seguridad arquitectónica que no solo respondan a vulnerabilidades conocidas, sino que también soporten la escalabilidad, interoperabilidad y automatización del entorno moderno.

Este artículo aborda los principales patrones y principios de seguridad aplicados a la arquitectura, explicando no solo qué son, sino cómo y por qué se integran en la infraestructura y los componentes de una solución robusta.

 

Autenticación y Autorización: La primera línea de defensa

 

En el contexto de sistemas distribuidos, la autenticación y autorización no pueden resolverse mediante mecanismos ad-hoc. Se requiere el uso de estándares interoperables, seguros y escalables.

 

OAuth2: Delegación de acceso mediante tokens

OAuth2 no es un protocolo de autenticación, sino de autorización delegada. Permite que una aplicación (cliente) acceda a un recurso protegido en nombre de un usuario, sin manejar directamente sus credenciales.

Arquitectónicamente, OAuth2 separa los roles del sistema:

• Authorization Server: emite tokens de acceso. Es el componente central de confianza.
• Resource Server: valida tokens y protege recursos (APIs).
• Client: la app que solicita el token para acceder a los recursos.
• User (Resource Owner): quien autoriza el acceso.

En sistemas modernos, se suele combinar con OpenID Connect para agregar un proceso formal de autenticación, entregando un ID Token firmado que representa la identidad del usuario.

 

Aplicación típica:

• El frontend obtiene un token desde un Identity Provider (IdP) como Auth0, Azure AD, Keycloak o Cognito.
• El token se envía en cada request a las APIs backend, que lo validan sin necesidad de compartir estado.

 

OpenID Connect (OIDC): Identidad en arquitecturas federadas

 

OIDC extiende OAuth2 con un mecanismo robusto de autenticación, agregando una capa de gestión de identidad federada. Los tokens ID incluyen atributos firmados del usuario (claims), como su nombre, correo, roles o grupos.

Beneficio arquitectónico:

• Posibilita Single Sign-On (SSO) entre múltiples aplicaciones o dominios.
• Delegación total de la gestión de identidad a un proveedor central.
• Base para aplicar seguridad basada en claims o políticas (ABAC o RBAC).

 

API Gateway 

Un patrón común en sistemas distribuidos es delegar la autenticación/autorización inicial a un API Gateway. Este patrón permite:

• Validación centralizada de tokens (OAuth2/JWT).
• Aplicación de políticas de acceso por ruta, método, rol o cliente.
• Registro de auditoría y logging de seguridad.
• Reescritura de headers e inyección de identidad en las llamadas a microservicios internos.

Ventaja arquitectónica: Elimina la necesidad de replicar lógica de seguridad en cada microservicio, disminuyendo errores y costos de mantenimiento.

 

Seguridad en APIs

 

Las APIs no solo deben estar protegidas desde el punto de vista de la identidad, sino también ante abusos de uso, amenazas externas e integraciones maliciosas.

 

Rate Limiting y Throttling

Rate Limiting impone un número máximo de solicitudes por unidad de tiempo. Es útil para evitar:

• DDoS a endpoints críticos

• Agotamiento de recursos computacionales

• Abuso de clientes (por bugs o ataques)

Throttling es una técnica dinámica que desacelera o bloquea solicitudes cuando se detecta congestión o comportamiento anómalo, útil para escenarios de recuperación o defensa.

Implementación común:

• A nivel de API Gateway (como Kong, Apigee, AWS API Gateway)
• Directamente en proxies como Envoy o Istio (sidecar en service mesh)
• Como middleware en el backend (con Redis, token buckets o leaky buckets)

 

JWT (JSON Web Tokens): Identidad portable y autocontenida

JWT es el formato de token preferido para OAuth2 y OIDC. Contiene información firmada que puede ser verificada sin mantener sesión ni consultar un store externo.

Claims comunes:

• sub: ID del usuario
• exp: expiración
• aud: audiencia
• scope / roles: permisos

Ventaja arquitectónica: Permite que cada servicio verifique de forma autónoma los permisos del usuario, sin necesidad de estado compartido o cacheo centralizado.

Peligro habitual:

• No revocabilidad inmediata
• Validación incorrecta de firma o expiración
• Tamaño excesivo transmitido en headers

 

CORS

CORS (Cross-Origin Resource Sharing) es un mecanismo de protección que impide que scripts maliciosos desde otros dominios accedan a recursos sensibles vía navegador.

Implementación segura:

• Listas blancas de orígenes (Access-Control-Allow-Origin)
• Preflight requests con OPTIONS
• Headers de control de métodos, credenciales y headers permitidos

Aunque no es un mecanismo de seguridad en sí, mal configurarlo puede dejar una API completamente expuesta al acceso desde cualquier origen.

 

Seguridad en sistemas distribuidos: más allá del perímetro

 

En arquitecturas distribuidas, la seguridad debe ser transversal, confiable y resistente al fallo o a la desconfiguración. Esto requiere adoptar patrones avanzados.

 

Zero Trust Architecture (ZTA)

El modelo Zero Trust parte de la premisa de que ningún componente es confiable por defecto, ni siquiera los internos. Cada solicitud debe ser autenticada, autorizada y validada de forma explícita.

Principios fundamentales:

• Autenticación fuerte en cada capa.
• Mínimo privilegio: cada componente solo accede a lo estrictamente necesario.
• Verificación continua de contexto (ubicación, dispositivo, riesgo).
• Telemetría constante de uso y acceso.

Aplicación concreta:

• Microservicios que verifican JWTs internamente, sin asumir que ya fueron validados.
• Segmentación de red con políticas L4/L7 (como Istio Authorization Policies).
• Autenticación mTLS entre servicios (mutual TLS).

 

Aislamiento de dominios y recursos

Para reducir el radio de impacto en caso de ataques o errores, se recomienda aislar componentes a nivel de infraestructura y datos:

• Cada microservicio con su base de datos (Database per Service).
• Separación de cuentas o proyectos en entornos multicloud.
• Contenedores sin privilegios, redes separadas, y ejecución mínima.
• Roles de acceso definidos por contexto (IAM granular).

 

Gestión segura de secretos

Uno de los errores más comunes es almacenar secretos sensibles en el código o archivos estáticos. Esto incluye passwords, claves de API, tokens, certificados, etc.

Patrones seguros de gestión de secretos:

• Uso de vaults (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault)
• Inyección dinámica en tiempo de ejecución (env vars temporales o montajes secretos)
• Control de acceso basado en políticas y contextos (como IAM)
• Automatización de rotación y expiración

Métrica clave: ningún desarrollador debería tener acceso directo a secretos en producción. El pipeline y el entorno deben proveerlos dinámicamente.

 

Conclusión

 

Los patrones de seguridad en arquitectura no se tratan simplemente de prevenir ataques, sino de garantizar que el sistema pueda operar de forma confiable, consistente y segura, incluso bajo condiciones adversas. La seguridad debe ser tratada como una capacidad estructural, no como un complemento funcional.

Aplicar autenticación basada en estándares, reforzar la protección de APIs, adoptar Zero Trust y aislar componentes mediante principios de menor privilegio no solo mitiga riesgos, sino que permite construir plataformas verdaderamente escalables, auditables y resilientes.