0.5 · Arquitectura de seguridad: modelar la amenaza y confiar con criterio

9 min de lectura · fundamentos / arquitectura / modelo-amenazas / zero-trust / frontera-confianza / stride / identidad · ⎙ PDF

Panorama: la seguridad se diseña, no se agrega#

Los tres capítulos anteriores dieron los sustratos: la red que conecta, el sistema operativo que reparte el privilegio, la criptografía que provee confianza verificable. Este capítulo hace algo distinto: los compone. Porque un sistema real no es una red, ni un sistema operativo, ni un algoritmo; es todo eso ensamblado, y la seguridad del conjunto no es la suma de las seguridades de las partes —emerge, o no, de cómo se las conecta—. Esa composición deliberada es la arquitectura de seguridad, y su primera lección es negativa: la seguridad no se agrega al final como una capa de pintura sobre un sistema ya construido. Lo que se atornilla al final tapa síntomas; lo que protege de verdad se decidió en el diseño.

Diseñar para la seguridad empieza por una pregunta que, asombrosamente, casi nadie hace a tiempo: ¿contra qué, exactamente, nos defendemos? Sin esa pregunta, la seguridad se vuelve una acumulación de controles sin criterio —se compra lo que el mercado ofrece, no lo que la amenaza exige—. Con ella, cada control tiene una razón: responde a una amenaza concreta sobre un activo concreto. El resto del capítulo desarrolla cómo se hace esa pregunta de forma estructurada y qué dos conceptos —la superficie de ataque y la frontera de confianza— organizan la respuesta.

Modelado de amenazas: hacerse la pregunta antes que el atacante#

El modelado de amenazas (threat modeling) es la disciplina de anticipar, de forma estructurada y sobre un dibujo del sistema, cómo podría ser atacado —antes de que lo sea—. No es una auditoría de lo ya construido ni una prueba de penetración: es un ejercicio de diseño que se hace idealmente antes de escribir una línea de código, y que se puede resumir en cuatro preguntas encadenadas: ¿qué estamos construyendo (un diagrama del sistema, sus componentes y cómo fluyen los datos)? ¿qué puede salir mal (las amenazas)? ¿qué vamos a hacer al respecto (las mitigaciones)? ¿lo hicimos bien (la verificación)?

Para que la segunda pregunta no dependa de la inspiración, existen marcos que la sistematizan. El más difundido es STRIDE, un acrónimo que enumera seis categorías de amenaza, cada una como la negación de una propiedad de seguridad deseada: Spoofing (suplantación de identidad, contra la autenticidad), Tampering (manipulación, contra la integridad), Repudiation (repudio: negar haber hecho algo, contra la trazabilidad), Information disclosure (divulgación, contra la confidencialidad), Denial of service (denegación, contra la disponibilidad) y Elevation of privilege (elevación de privilegio, contra la autorización). Recorrer cada componente del diagrama preguntando «¿cómo sufre este cada una de las seis?» convierte la búsqueda de amenazas en un proceso repetible en vez de una lluvia de ideas.

flowchart LR
  Q1["¿qué construimos?\ndiagrama · flujos de datos"] --> Q2["¿qué puede salir mal?\nSTRIDE por componente"]
  Q2 --> Q3["¿qué hacemos?\nmitigaciones por amenaza"]
  Q3 --> Q4["¿lo hicimos bien?\nverificación"]
  Q4 -.->|"el sistema evoluciona:\nel modelo se revisa"| Q1

Se ve por qué STRIDE no es una lista arbitraria: sus seis categorías son, casi exactamente, las propiedades de la tríada CIA extendida puestas del revés. Modelar amenazas es preguntarse, sistema en mano, de qué manera se puede violar cada garantía que uno quería tener. Y el entregable no es un informe: es un conjunto de decisiones de diseño —este dato se cifra, este componente se aísla, este cruce se valida— tomadas por una razón nombrada.

Superficie de ataque: ver para reducir#

De modelar amenazas surge el primer concepto operativo: la superficie de ataque (attack surface). Es la suma de todos los puntos por los que un atacante podría intentar entrar o interactuar con el sistema: cada puerto abierto, cada servicio expuesto, cada campo de entrada, cada dependencia de terceros, cada cuenta con acceso, cada API. La superficie de ataque es, literalmente, todo lo que hay que defender —y por eso el principio de diseño más directo que se deriva de ella es reducirla: lo que no existe no se puede atacar—. Un servicio que no se expone, un puerto que se cierra, una función que se elimina, una cuenta que se desactiva: cada uno es superficie que desaparece, y con ella la clase entera de ataques que la usaban.

La reducción de superficie es la economía de mecanismo de los principios llevada a la arquitectura: cuanto menos hay, menos puede fallar y menos hay que auditar. Y es lo primero que un atacante mide —el reconocimiento de la Parte 4 es, en el fondo, el mapeo de la superficie de ataque de un dominio— y por lo tanto lo primero que un defensor debería haber medido. Ver la superficie es un acto de diseño: no se puede reducir lo que no se sabe que existe, y buena parte de las brechas ocurren en superficie que la organización ni sabía que tenía —un servidor olvidado, una interfaz de administración expuesta, una credencial en un repositorio—.

La frontera de confianza como artefacto de diseño#

El segundo concepto operativo, y el más importante del capítulo, es la frontera de confianza (trust boundary). Ya apareció como hilo en los capítulos anteriores; aquí se vuelve método. Una frontera de confianza es la línea donde algo que confiamos recibe algo que no confiamos: la entrada del usuario que llega a la aplicación, la respuesta del servicio externo que consume nuestro sistema, el documento que un agente lee, el paquete que cruza del segmento no confiable al confiable. En esa línea, y solo en esa línea, es donde hay que validar —porque es donde el dato no confiable intenta volverse acción confiable—.

La diferencia entre un sistema seguro y uno inseguro suele ser si sus fronteras de confianza son explícitas o accidentales. En un diseño maduro, cada frontera está dibujada a propósito: se sabe dónde está, qué la cruza y qué validación la protege. En un diseño inmaduro, las fronteras son accidentes de la implementación —surgieron sin que nadie las decidiera— y por eso quedan sin custodiar. El error recurrente, que la Parte 3 nombró y la Parte 9 reprisó con la seguridad de la inteligencia artificial, es el mismo: cuando aparece una tecnología nueva, reubica la frontera de confianza, y la vulnerabilidad aparece en la frontera que se dejó de mirar porque se la creía interna. El prompt injection es exactamente eso —una frontera de confianza nueva, entre los datos que un modelo procesa y las instrucciones que sigue, que nadie estaba validando—. Convertir la frontera de confianza en un artefacto de diseño explícito es la contramedida general contra toda esa familia de errores: si cada frontera está dibujada, ninguna se deja de mirar.

Del perímetro al zero trust#

Durante décadas la arquitectura de red dominante se organizó alrededor de un perímetro: un borde fortificado —el cortafuegos, la DMZ— que separaba el «afuera» hostil de un «adentro» tratado como confiable. El modelo tenía una metáfora cómoda, el castillo con su foso, y un defecto fatal: una vez dentro, todo era confiable. Bastaba una grieta en el muro —un correo de phishing, una VPN comprometida, un servidor expuesto— para que el atacante quedara en el interior blando, donde podía moverse lateralmente casi sin resistencia. Los mismos ataques de movimiento lateral que el manual recorrió deben buena parte de su eficacia a esa suposición: la red confiaba en quien ya estaba adentro.

El zero trust («confianza cero») es la corrección arquitectónica de ese defecto, y su formulación cabe en una frase: nunca confiar, siempre verificar. En un modelo de confianza cero no hay un «adentro» confiable por ubicación; cada acceso a cada recurso se autentica, se autoriza y se cifra en el momento, sin importar desde dónde se origine, como si cada petición viniera de una red hostil. Visto desde los principios, el zero trust no es una idea nueva: es la mediación completa de Saltzer y Schroeder —verificar en cada acceso, no una sola vez— aplicada a la red entera, más el mínimo privilegio —dar solo el acceso necesario, solo por el tiempo necesario—. Su consecuencia práctica más visible es que la identidad reemplaza a la red como perímetro: si ya no se confía por ubicación, lo que decide cada acceso es quién es el sujeto y qué le corresponde, y por eso la identidad —el terreno que toda la Parte 4 trabajó— se vuelve el punto donde se gana o se pierde la seguridad del sistema moderno.

Diseño seguro por defecto: no repetir el error#

El capítulo cierra con el principio que resume su actitud entera: seguro por diseño y por defecto (secure by design, secure by default). Seguro por diseño significa que la seguridad es una consideración de primera clase desde el comienzo, no un parche posterior —todo lo que este capítulo defendió—. Seguro por defecto significa que la configuración de fábrica del sistema es la segura: la opción cómoda y la opción protegida coinciden, de modo que el usuario no tiene que ser experto ni diligente para estar protegido. Es la contracara de los valores por defecto seguros y de la aceptabilidad psicológica: un sistema que solo es seguro si cada usuario lo endurece a mano será, en la práctica, inseguro para casi todos.

Esta arquitectura —modelar la amenaza, ver y reducir la superficie, dibujar las fronteras de confianza, no confiar por ubicación, ser seguro por defecto— es el marco de diseño. Lo que la sostiene en el tiempo, la vuelve política y la hace cumplir a escala de una organización es la gobernanza de la Parte 7: el diseño decide cómo debería ser el sistema, la gobernanza se asegura de que efectivamente lo sea y lo siga siendo. Este capítulo da el plano; la gobernanza es quien vela por que el edificio se construya según el plano y no se degrade con el uso.

Referencias#

El modelado de amenazas, STRIDE, la superficie de ataque y el diseño seguro por defecto son marcos establecidos de arquitectura de seguridad; su presentación como la composición de los sustratos de red, sistema operativo y criptografía en un sistema defendible es enriquecimiento propio.
La frontera de confianza como artefacto de diseño explícito conecta con el error recurrente que nombraron la Parte 3 (la vulnerabilidad vive en la frontera que se dejó de mirar) y la Parte 9 (prompt injection como frontera nueva); la reducción de superficie, con el reconocimiento como mapeo de esa superficie.
El zero trust es la aplicación de la mediación completa y el mínimo privilegio de 0.1 a la red, con la identidad como nuevo perímetro (eco de la Parte 4). El marco de diseño de este capítulo lo dirige y sostiene la gobernanza de la Parte 7. La síntesis de todo el manual se cierra en 0.6.

Mencionado en

0.1 · Principios: los invariantes que todo presuponeEl capítulo que abre la Parte 0 y, con ella, cierra el manual. La Parte 0 se lee primera —es el cimiento— pero se escribió última, y por eso puede hacer algo que ninguna otra puede: nombrar los invariantes que las otras nueve Partes dieron por supuestos sin enunciarlos. Este capítulo los reúne. Empieza por el objetivo que toda la disciplina persigue —la tríada CIA de confidencialidad, integridad y disponibilidad, y su extensión Parkeriana— y sigue con los ocho principios de diseño de Saltzer y Schroeder, el conjunto de axiomas de ingeniería que en cincuenta años no envejeció: economía de mecanismo, valores por defecto seguros, mediación completa, diseño abierto, separación de privilegio, mínimo privilegio, mecanismo común mínimo y aceptabilidad psicológica. Sobre esa base recoge los hilos conductores que el manual tejió Parte a Parte —separar los datos del código, la defensa en profundidad, la frontera de confianza, no confiar en la entrada, verificar la procedencia, dejar al humano la decisión irreversible— y muestra que cada uno es la aplicación de esos axiomas a una capa concreta. La tesis que ancla la Parte y el libro entero: la seguridad no es un producto que se compra ni una suma de herramientas, sino una propiedad que emerge de aplicar con disciplina un puñado de principios a cada capa del sistema.
0.2 · Redes: el modelo de capas como superficieEl sustrato de conectividad sobre el que se apoyan casi todas las técnicas del manual. Explica la pila TCP/IP como un modelo de capas donde cada nivel confía en el de abajo sin poder verificarlo —y por qué esa confianza no ganada es, a la vez, lo que hace funcionar Internet y lo que la vuelve atacable—. Recorre la encapsulación, el direccionamiento y el enrutamiento, el sistema de nombres de dominio (DNS) como una infraestructura de confianza tan indispensable como frágil, y los mecanismos que dibujan fronteras dentro de la red: NAT, cortafuegos y, sobre todo, la segmentación, cuyo opuesto —la red plana— es el pecado original que convierte un único punto de acceso en el compromiso de todo. Distingue el tráfico norte-sur (que cruza el perímetro) del este-oeste (que se mueve dentro), explica a alto nivel cómo el protocolo TLS levanta un canal cifrado y autenticado sobre un transporte que no lo es, y cierra con el filtrado de salida (egress filtering) como el control que le quita al atacante la vía de retorno. No rehace los ataques de red de las Partes 2, 3 y 4: nombra el modelo que esos ataques presuponen.
0.4 · Criptografía: confianza matemática y sus límitesEl sustrato de confianza verificable. La criptografía es la única herramienta de la seguridad que apoya sus garantías en la matemática y no en la vigilancia: bien usada, permite confiar en la confidencialidad, la integridad y el origen de un dato sin tener que custodiar el canal por el que viaja. Este capítulo ordena sus tres primitivas —el cifrado simétrico (una clave compartida, rápido, para el grueso de los datos), el cifrado asimétrico (un par de claves pública y privada, que resuelve el problema de acordar secretos con desconocidos) y las funciones de hash (huellas de tamaño fijo que garantizan integridad, no confidencialidad)— y combate el error de categoría más común y más caro: confundir cifrar, codificar y hashear. Sobre esas primitivas levanta las construcciones que el resto del manual dio por sentadas: las funciones de derivación de claves con sal que deciden si un hash de contraseña resiste o cae, la firma digital y la infraestructura de clave pública (PKI) que sostiene tanto TLS como la autenticación por certificados del Active Directory, y Kerberos como criptografía aplicada donde la diferencia entre un algoritmo viejo y uno moderno decide si un ticket se puede crackear. Cierra con la lección de arquitectura: la criptografía casi nunca falla en el algoritmo; falla en la implementación y en la gestión de las claves. No rehace Kerberos ni AD CS: da el fundamento matemático que ambos presuponen.
3.19 · Cloud red team: identidad, IAM y la nube como perímetroEl red team en la nube, donde el modelo mental del atacante cambia de raíz. En un centro de datos clásico el objetivo es una máquina en una red; en la nube no hay una 'adentro' de red que conquistar, hay un plano de control gobernado por identidades y políticas, y el atacante no explota memoria ni servicios sino que abusa de permisos mal puestos. El capítulo desarrolla la tesis que lo ordena —en la nube la identidad es el perímetro— y la recorre en los dos grandes proveedores de identidad y cómputo. En el plano de la identidad corporativa (Entra ID, el antiguo Azure AD) trata el phishing de código de dispositivo, el consentimiento ilícito de aplicaciones, el robo de tokens de sesión y los principales de servicio como persistencia. En el plano de la infraestructura (AWS) trata la enumeración de IAM, la escalada por políticas mal configuradas, el abuso del servicio de metadatos de instancia como puente desde una vulnerabilidad web, y las cadenas de asunción de roles. Cubre la persistencia propia de la nube y los puentes entre el dominio local y la nube en entornos híbridos. Y cierra, como siempre, con el mapeo púrpura: la telemetría de la nube (los registros de actividad de la API), la gestión de identidades y los controles de acceso condicional son donde el defensor recupera la ventaja. Es material de dominio actual, sin base destilada, y el complemento cloud del Active Directory de la Parte 4.