← Volver al listado de tecnologías ← Índice de ISC2 CSSLP

Dominio 4b: Arquitectura y diseño seguros

2 de julio de 2026 Por: Artiko

csslpisc2seguridadarquitecturacriptografiaclouddiseno

Dominio 4b: Arquitectura y diseño seguros

Este capítulo cierra el Dominio 4 (el de mayor peso, 15%). Si el capítulo anterior respondía a “¿qué puede salir mal?”, este responde a “¿qué construimos y qué hacemos al respecto?”: cómo se estructura una solución para que la seguridad sea una propiedad de la arquitectura y no un parche. El arquitecto de seguridad piensa en controles, interfaces, tecnologías reutilizables, modelos formales y topología operacional.

flowchart LR
    TM[Amenazas identificadas] --> AS[Arquitectura de seguridad]
    AS --> IC[Identificación de controles]
    IC --> P[Priorización por riesgo]
    P --> DI[Diseño de interfaces]
    P --> TR[Tecnologías reutilizables]
    P --> OA[Arquitectura operacional]

4.1 Definir la arquitectura de seguridad

La arquitectura de seguridad traduce las amenazas y requisitos en un conjunto priorizado de controles. La actividad clave es la identificación de controles: para cada amenaza, elegir el control (o combinación) que la mitiga, y priorizarlo según el riesgo (probabilidad × impacto) y la clasificación de los activos afectados.

Los controles se clasifican por su naturaleza y su función:

Por función	Descripción	Ejemplo
Preventivo	Evita que el incidente ocurra	Autenticación, cifrado, validación
Detectivo	Detecta el incidente en curso o consumado	Logging, IDS, monitoreo
Correctivo	Restaura tras el incidente	Backups, failover, parches
Disuasorio	Desincentiva al atacante	Avisos legales, banners
Compensatorio	Sustituto cuando el control ideal no es viable	MFA cuando no se puede segmentar

El arquitecto aplica defense in depth (defensa en profundidad): múltiples capas de controles, de modo que la falla de uno no comprometa el sistema. Y fail secure: ante un fallo, el sistema debe quedar en estado seguro (denegar por defecto), no abierto.

💡 Tip de examen: la selección de controles se prioriza por riesgo, no por costo ni por facilidad. Y la mentalidad correcta es defense in depth: nunca un único control como punto de fallo. Ante un fallo, fail secure (denegar), no fail open.

4.2 Diseño seguro de interfaces

Las interfaces son las fronteras del sistema, y por tanto puntos críticos de seguridad. El diseño seguro de interfaces cubre APIs, canales upstream/downstream, protocolos, administración e interfaces de log.

APIs: autenticación y autorización en cada endpoint, validación estricta de entrada, rate limiting, versionado, no exponer más de lo necesario (least privilege de datos), mensajes de error que no filtren información interna.
Upstream/downstream: cada servicio del que dependes (upstream) y cada consumidor tuyo (downstream) es una relación de confianza que debe autenticarse y validarse. No confíes en que un servicio interno “ya validó”.
Protocol design: preferir protocolos seguros y probados (TLS, mTLS) frente a diseñar protocolos propios. Diseñar criptografía o protocolos a medida es una fuente clásica de fallos.
Out-of-band management: las interfaces de administración deben estar en un canal separado del tráfico de usuarios (red de gestión dedicada), nunca expuestas a la red pública. Reduce superficie de ataque de las funciones más peligrosas.
Log interfaces: los logs son a la vez control detectivo y activo sensible. La interfaz de logging debe proteger su integridad (no manipulables) y su confidencialidad (no registrar secretos ni PII innecesaria).

💡 Tip de examen: las interfaces de administración van out-of-band (canal separado), nunca por la misma red que los usuarios. Y nunca confíes en que “un servicio interno ya validó”: cada interfaz valida y autentica de nuevo (complete mediation).

4.3 Tecnologías reutilizables seguras

Un arquitecto evalúa y selecciona componentes de seguridad probados en lugar de reinventarlos. El principio rector es “no construyas tu propia seguridad si existe una solución madura y auditada”.

Gestión de credenciales y hardware de confianza

Tecnología	Qué es	Para qué sirve
Credential vault	Almacén cifrado de secretos (Vault, KMS)	Centralizar y rotar secretos, sacarlos del código
HSM (Hardware Security Module)	Dispositivo dedicado a operaciones criptográficas	Generar/almacenar claves; la clave nunca sale del hardware
TPM (Trusted Platform Module)	Chip en la placa base	Anclaje de confianza, sellado de claves, medición de arranque
TEE (Trusted Execution Environment)	Enclave aislado en el procesador (SGX, TrustZone)	Ejecutar código sensible aislado del SO
Secure containers	Contenedores endurecidos y aislados	Aislamiento de cargas de trabajo

La diferencia que el examen valora: HSM es un dispositivo dedicado (a menudo externo, certificado FIPS 140-2/3) para gestión de claves a escala; TPM es un chip integrado en un equipo concreto, orientado a la integridad de la plataforma. Ambos mantienen las claves fuera del alcance del software.

Identidad federada y SSO

Estándar	Tipo	Uso principal
OAuth 2.0	Autorización (delegación de acceso)	Conceder a una app acceso limitado a recursos sin compartir credenciales
OIDC (OpenID Connect)	Autenticación sobre OAuth 2.0	Verificar identidad; añade el ID token
SAML	Autenticación y SSO (XML)	SSO empresarial, federación entre organizaciones

Distinción crítica: OAuth 2.0 es autorización, OIDC es autenticación. OAuth por sí solo delega acceso a recursos; OIDC añade la capa de identidad. SAML es la opción empresarial clásica (basada en XML) para SSO federado. La federación de identidad permite confiar en un proveedor de identidad (IdP) externo, evitando gestionar credenciales propias.

sequenceDiagram
    participant U as Usuario
    participant SP as Aplicación (SP)
    participant IdP as Proveedor de identidad
    U->>SP: Solicita acceso
    SP->>IdP: Redirige para autenticación
    U->>IdP: Se autentica (MFA)
    IdP-->>SP: Token/aserción firmada
    SP-->>U: Acceso concedido según claims

💡 Tip de examen: OAuth 2.0 = autorización, OIDC = autenticación (construido sobre OAuth), SAML = SSO empresarial en XML. Confundir OAuth con autenticación es un error clásico que el examen aprovecha.

4.6 Modelar propiedades y restricciones de seguridad: modelos formales

Los modelos formales de control de acceso son marcos teóricos que expresan matemáticamente qué operaciones son seguras. El examen no pide demostraciones, pero sí saber qué propiedad protege cada uno.

Modelo	Protege	Reglas clave	Frase mnemónica
Bell-LaPadula	Confidencialidad	No read up (no leer por encima), no write down (property *)	“No read up, no write down”
Biba	Integridad	No read down, no write up	”No read down, no write up” (inverso de BLP)
Clark-Wilson	Integridad (comercial)	Transacciones bien formadas + separación de funciones vía programas certificados	Integridad mediante transacciones controladas
Brewer-Nash (Muralla China)	Conflicto de intereses	El acceso previo restringe accesos futuros a competidores	Evita conflicto de intereses dinámicamente

Bell-LaPadula nació en el ámbito militar: su obsesión es que la información no fluya hacia abajo en clasificación (confidencialidad). Un sujeto no puede leer datos por encima de su clearance ni escribir hacia niveles inferiores (evita fugas).
Biba es el espejo de BLP para integridad: impide que datos de baja integridad contaminen los de alta (no write up) y que se lea de fuentes menos confiables (no read down).
Clark-Wilson modela integridad comercial: los usuarios solo modifican datos a través de transacciones bien formadas y certificadas, con separación de funciones.
Brewer-Nash (muralla china) es dinámico: los permisos cambian según el historial de accesos, para evitar conflictos de interés (típico en consultoría/finanzas).

💡 Tip de examen: Bell-LaPadula = confidencialidad (“no read up, no write down”); Biba = integridad (lo inverso). Si el escenario habla de proteger secretos, es BLP; si habla de proteger la integridad de los datos, es Biba. Clark-Wilson = transacciones bien formadas; Brewer-Nash = conflicto de intereses.

4.7 Arquitectura operacional segura

Define dónde y cómo se despliega el sistema para minimizar riesgo: la topología de red, las zonas de confianza y la separación de entornos.

Zonas de confianza: segmentar la red en niveles de confianza (pública, DMZ, interna, datos). El tráfico entre zonas se controla y filtra.
DMZ (zona desmilitarizada): segmento intermedio entre Internet y la red interna donde viven los servicios expuestos (web, correo). Aísla lo público de lo interno: si comprometen la DMZ, no alcanzan directamente los datos.
Deployment topology: separar entornos (desarrollo, pruebas, staging, producción), aislar bases de datos de la exposición pública, colocar controles (WAF, balanceadores, firewalls) en los cruces de zona.
Segmentación y microsegmentación: limitar el movimiento lateral de un atacante que ya entró.

flowchart LR
    I[Internet] --> FW1[Firewall perimetral]
    subgraph DMZ
        WAF[WAF] --> WEB[Servidor web]
    end
    FW1 --> WAF
    WEB --> FW2[Firewall interno]
    subgraph Zona interna
        APP[App server]
        DB[(Base de datos)]
    end
    FW2 --> APP
    APP --> DB

Las líneas de firewall del diagrama son trust boundaries operacionales: cada salto exige autenticación y filtrado. La base de datos nunca es accesible directamente desde Internet.

💡 Tip de examen: la DMZ aísla los servicios expuestos de la red interna; la segmentación limita el movimiento lateral. La base de datos va en la zona más interna, nunca expuesta directamente a Internet.

Patrones de diseño seguro

Los secure design patterns son soluciones reutilizables a problemas recurrentes de seguridad:

Patrón	Propósito
Secure Factory	Crear objetos con su configuración de seguridad ya aplicada
Secure Proxy / Gatekeeper	Interponer un control de acceso ante el recurso protegido
Input Validator	Centralizar la validación de entradas no confiables
Single Access Point	Un único punto de entrada controlado (complete mediation)
Least Privilege	Componentes con los mínimos permisos necesarios
Defense in Depth	Capas redundantes de control

Estos patrones materializan los principios de diseño seguro (economy of mechanism, complete mediation, fail-safe defaults, separation of privilege, least common mechanism) en estructuras concretas de código y arquitectura.

Criptografía aplicada para el arquitecto

El arquitecto no implementa algoritmos, pero decide qué usar, dónde y cómo gestionar las claves. El examen es conceptual: entender propiedades y errores comunes.

Simétrica vs. asimétrica

Aspecto	Simétrica	Asimétrica
Claves	Una clave compartida	Par pública/privada
Velocidad	Rápida	Lenta
Uso típico	Cifrar grandes volúmenes de datos	Intercambio de claves, firmas
Ejemplos	AES, ChaCha20	RSA, ECC
Reto	Distribuir la clave de forma segura	Gestión de confianza (PKI)

En la práctica se combinan: cifrado híbrido (asimétrico para intercambiar la clave de sesión, simétrico para los datos), como hace TLS.

Hashing y firmas

Hashing: función unidireccional que produce un resumen de tamaño fijo; garantiza integridad. Para contraseñas se usan funciones lentas y con sal (bcrypt, scrypt, Argon2), no hashes rápidos.
Firma digital: hash del mensaje cifrado con la clave privada del emisor; aporta integridad, autenticación y no repudio.

PKI, TLS y gestión de claves

PKI (Public Key Infrastructure): jerarquía de autoridades de certificación (CA) que vincula identidades a claves públicas mediante certificados X.509.
TLS: usa cifrado híbrido y certificados para dar confidencialidad e integridad en tránsito. Preferir TLS 1.2/1.3; deshabilitar SSL y versiones antiguas.
Key management: el eslabón más frágil. Cubre generación, distribución, rotación, almacenamiento (HSM/vault), revocación y destrucción de claves. Una clave mal gestionada anula el mejor algoritmo.
Crypto-agility: diseñar el sistema para poder cambiar de algoritmo sin reescribirlo, anticipando la obsolescencia (por ejemplo, la transición post-cuántica).

Errores comunes de criptografía

Crypto casero: diseñar algoritmos o protocolos propios en lugar de usar estándares auditados. Casi siempre inseguro.
Algoritmos obsoletos: MD5 y SHA-1 (colisiones), DES (clave corta). Usar SHA-256+, AES.
Claves embebidas en el código o repositorio.
ECB como modo de cifrado (revela patrones); preferir modos autenticados (GCM).
Reutilizar nonces/IV o generarlos con RNG débil.

💡 Tip de examen: nunca crypto casero; usa estándares probados. MD5, SHA-1 y DES están obsoletos. La gestión de claves es el punto débil habitual: un algoritmo fuerte con claves mal gestionadas es inseguro. Y para contraseñas: hashing lento con sal (Argon2/bcrypt), jamás MD5/SHA rápido.

Arquitecturas específicas

Cada estilo arquitectónico trae su propio modelo de amenazas y sus controles.

Cloud y responsabilidad compartida

En la nube, la seguridad se reparte entre proveedor y cliente según el modelo de servicio:

Modelo	El proveedor asegura	El cliente asegura
IaaS	Hardware, virtualización, red física	SO, aplicaciones, datos, accesos
PaaS	Lo anterior + SO y runtime	Aplicaciones, datos, configuración
SaaS	Casi toda la pila	Datos, gestión de usuarios y accesos

La regla constante: los datos y la gestión de identidades/accesos son siempre responsabilidad del cliente, en cualquier modelo. Malinterpretar el reparto es causa frecuente de brechas (buckets abiertos, permisos excesivos).

flowchart TD
    subgraph SaaS
        S1[Proveedor: casi todo]
        S2[Cliente: datos y accesos]
    end
    subgraph PaaS
        P1[Proveedor: hasta runtime]
        P2[Cliente: app, datos, config]
    end
    subgraph IaaS
        I1[Proveedor: infraestructura]
        I2[Cliente: SO, app, datos]
    end

Microservicios y service mesh

Muchos servicios pequeños amplían la superficie de ataque y el tráfico este-oeste. Controles: mTLS entre servicios, autenticación servicio a servicio, API gateway, y un service mesh (Istio, Linkerd) que gestiona identidad, cifrado y políticas de forma centralizada. Aplicar zero trust: ningún servicio confía en otro por estar “dentro”.

Contenedores y serverless

Contenedores: imágenes mínimas y firmadas, escaneo de vulnerabilidades, no ejecutar como root, secretos fuera de la imagen, aislamiento del runtime. La superficie incluye el orquestador (Kubernetes) y el registro.
Serverless: menos infraestructura que gestionar, pero cada función es un punto de entrada; foco en permisos mínimos por función (least privilege del rol de ejecución), validación de eventos y gestión de dependencias.

IoT/embebidos, mobile y rich clients

IoT/embebidos: recursos limitados, actualización difícil, exposición física. Controles: arranque seguro (secure boot con TPM), firmware firmado, credenciales únicas por dispositivo, canales cifrados.
Mobile: el dispositivo es un entorno hostil; no almacenar secretos en el cliente, usar el almacenamiento seguro del SO (Keychain/Keystore), certificate pinning, ofuscación como capa adicional (no como única defensa).
Rich clients: nunca confiar en la validación del lado del cliente; toda validación de seguridad se repite en el servidor. El cliente es controlable por el atacante.

DRM, trusted computing y virtualización

DRM (Digital Rights Management): controles para proteger propiedad intelectual y uso de contenido; se apoya en cifrado y, a menudo, en trusted computing.
Trusted computing: cadena de confianza anclada en hardware (TPM/TEE) que verifica la integridad desde el arranque (root of trust).
Virtualización: aísla cargas, pero introduce riesgos propios: VM escape, hypervisor como blanco, aislamiento entre tenants. Endurecer el hipervisor y segregar por sensibilidad.

💡 Tip de examen: en cloud, la responsabilidad compartida varía por modelo, pero datos y gestión de accesos siempre son del cliente. En microservicios y mobile, aplica zero trust y nunca confíes en el cliente: la validación de seguridad se repite en el servidor.

Arquitectura de referencia con trust boundaries

Reuniendo los conceptos, una arquitectura web segura típica define fronteras de confianza explícitas y coloca controles en cada cruce:

flowchart LR
    subgraph Internet["Zona no confiable - Internet"]
        User[Usuario]
    end
    subgraph Edge["DMZ"]
        WAF[WAF + API Gateway]
    end
    subgraph App["Zona de aplicación"]
        Auth[Servicio de identidad OIDC]
        Svc[Microservicios mTLS]
    end
    subgraph Data["Zona de datos"]
        Vault[Credential Vault / HSM]
        DB[(Base de datos cifrada)]
    end
    User -->|TLS 1.3| WAF
    WAF -->|autenticación| Auth
    WAF --> Svc
    Svc -->|mTLS| Svc
    Svc -->|secretos| Vault
    Svc -->|consulta parametrizada| DB

Cada zona es una trust boundary: el WAF valida y filtra la entrada pública, el servicio de identidad centraliza la autenticación (OIDC), los microservicios se comunican con mTLS, los secretos viven en un vault/HSM y la base de datos está cifrada en la zona más interna. Ningún componente confía ciegamente en el anterior: complete mediation y defense in depth en acción.

Puntos clave

La arquitectura de seguridad identifica controles y los prioriza por riesgo; aplica defense in depth y fail secure (denegar ante fallo).
El diseño de interfaces protege APIs (auth, validación, rate limiting), relaciones upstream/downstream y pone la administración out-of-band. Nunca confíes en que “otro servicio ya validó” (complete mediation).
Prefiere tecnologías reutilizables probadas: vaults, HSM (dispositivo dedicado a claves), TPM (chip de integridad de plataforma), TEE. En identidad: OAuth 2.0 = autorización, OIDC = autenticación, SAML = SSO empresarial.
Modelos formales: Bell-LaPadula = confidencialidad (“no read up, no write down”), Biba = integridad (inverso), Clark-Wilson = transacciones bien formadas, Brewer-Nash = conflicto de intereses.
La arquitectura operacional usa DMZ, zonas de confianza y segmentación; la base de datos va en la zona más interna, nunca expuesta a Internet.
Los patrones de diseño seguro (secure proxy, input validator, single access point) materializan los principios de diseño seguro.
Criptografía: simétrica (rápida, datos) vs. asimétrica (claves/firmas); nunca crypto casero; MD5/SHA-1/DES obsoletos; la gestión de claves es el punto débil; contraseñas con hashing lento y con sal; diseña con crypto-agility.
En cloud, la responsabilidad compartida cambia por modelo (IaaS/PaaS/SaaS), pero datos y accesos son siempre del cliente.
En microservicios, contenedores, serverless, IoT y mobile, aplica zero trust, least privilege por componente y nunca confíes en el cliente: la validación de seguridad se repite en el servidor.