Z3 detecta vulnerabilidades cloud pero no explica por qué
Z3 seguridad cloud plantea una paradoja concreta: este motor de razonamiento creado por Microsoft Research puede demostrar matemáticamente que tu configuración cloud tiene un vector de ataque disponible, pero su respuesta se limita a tres letras. “sat”. Sin contexto, sin explicación, sin señalar qué configuración es el problema.
En 30 segundos
- Z3 es un SMT solver de Microsoft Research, open source, capaz de verificar matemáticamente propiedades de seguridad en configuraciones cloud
- Devuelve “sat” (el estado inseguro es alcanzable) o “unsat” (no lo es), sin explicar cuál propiedad ni cómo remediarlo
- Se usa en producción: AWS Zelkova lo aplica a políticas IAM, Azure lo usa para verificar firewalls, Teleport lo usa para análisis RBAC
- El problema real no es el motor, es la capa de explicabilidad que Z3 no tiene y que necesitás construir (o conseguir de otra herramienta)
- Herramientas como AWS Policy Simulator, Wiz o Prisma Cloud agregan esa capa de interpretación y remediación que Z3 puro no da
Microsoft es una corporación multinacional estadounidense fundada en 1975 por Bill Gates y Paul Allen, que desarrolla software, sistemas operativos y servicios en la nube. Ofrece productos como Windows, Office, Azure y Teams principalmente para usuarios y empresas.
Z3: La paradoja del poder sin explicación
Z3 es un SMT solver (Satisfiability Modulo Theories) que Microsoft Research desarrolló originalmente para verificar diseños de chips y software de sistemas críticos como aviónica. Hoy está disponible como proyecto open source en GitHub y se convirtió en uno de los motores de razonamiento lógico más usados en seguridad de sistemas distribuidos.
Ponele que querés verificar si un usuario anónimo de internet puede leer datos sensibles desde un bucket S3 pasando por un Cognito identity pool. Modelás la configuración como aserciones lógicas en SMT-LIB, formulás la consulta y se la pasás a Z3. En milisegundos tenés la respuesta.
“sat”.
¿Y ahora qué? ¿Es porque el bucket está abierto? ¿Es porque el rol tiene demasiados permisos? ¿Es porque el pool Cognito permite usuarios no autenticados? Z3 no sabe decírtelo, o más precisamente: Z3 no está diseñado para decírtelo.
Cómo funciona Z3: razonamiento lógico en acción
El flujo es relativamente directo. Tomás tu configuración cloud (roles IAM, políticas de bucket, reglas de red), la modelás como un conjunto de aserciones en SMT-LIB (el lenguaje de entrada de Z3), y formulás una pregunta: “¿existe alguna asignación de valores que haga que este estado inseguro sea verdadero?”
El ejemplo que circuló el 17 de mayo de 2026 muestra exactamente esto. El input que ve Z3 para verificar acceso anónimo a S3 vía Cognito se ve así:
(declare-fun allows_unauthenticated (String String) Bool)
(assert (allows_unauthenticated "pool-abc" "true"))
(assert (maps_unauth_to "pool-abc" "role/AppUnauthRole"))
(assert (has_action "role/AppUnauthRole" "s3:GetObject"))
Z3 toma esas aserciones, busca si existe una asignación que las satisfaga todas simultáneamente, y responde. Si la respuesta es “sat”, la condición insegura que modelaste es alcanzable. Si es “unsat”, no lo es (dada tu codificación, que podría tener errores).
Eso sí: si formulaste mal la pregunta, la respuesta es inútil aunque sea matemáticamente correcta. La validez de la respuesta depende completamente de la calidad del modelo que construiste. Ya lo cubrimos antes en herramientas de verificación de Microsoft.
Z3 seguridad cloud: casos de uso reales en producción
Z3 no es solo teoría. Según Microsoft Research, varios sistemas de seguridad cloud lo usan como motor interno:
AWS Zelkova
AWS usa SMT solvers (incluido Z3) en Zelkova, el motor que analiza políticas IAM para detectar si permiten acceso no deseado. Cuando AWS te avisa que una política “puede permitir acceso público”, hay razonamiento formal detrás de esa afirmación.
Azure: verificación de firewalls
Azure usa Z3 para verificar equivalencia de reglas de firewall, particularmente cuando migrás configuraciones entre versiones de Network Security Groups. El objetivo: probar que la nueva configuración tiene exactamente las mismas propiedades de acceso que la anterior.
Teleport: análisis RBAC
Según la documentación técnica de Teleport, usan Z3 para analizar configuraciones RBAC y detectar rutas de acceso no intencionales. El caso típico: un usuario que no debería poder hacer X, pero puede hacerlo combinando tres permisos que sí tiene.
Google Cloud y Network Peerings
Google usa verificación formal para testing de configuraciones de Network Peerings, validando que las reglas de routing no crean rutas inesperadas entre redes que deberían estar aisladas.
El contexto importa: según datos de seguridad cloud de Q1 2026, el 76% de las organizaciones no activa MFA en todas las cuentas cloud y el 63% tiene datos sensibles expuestos en algún bucket con permisos más amplios de lo necesario. Z3 puede probar esas vulnerabilidades. El problema es que no te dice cómo las creaste.
El problema crítico: detecta pero no explica
Acá viene lo bueno, o más bien lo malo: la diferencia entre un motor y una herramienta.
Un motor responde la pregunta que le hacés. Una herramienta explica la respuesta, la contextualiza, te dice qué configuración específica la causa y te sugiere cómo arreglarla. Z3 es un motor. Extraordinariamente potente, matemáticamente riguroso, y completamente mudo sobre el “por qué”.
¿Alguien verificó si Z3 puede generar esas explicaciones de forma nativa? No. No puede. El diseño del solver es responder si una fórmula es satisfacible o no. Punto. Lo que necesitás es una capa adicional que tome el modelo, interprete el resultado, y lo traduzca a algo accionable para un equipo de seguridad. Tema relacionado: asegurar tus pipelines de CI/CD.
El gap es grande. Si obtenés “sat” en una verificación de S3 con Cognito que tiene 40 aserciones modelando 15 recursos distintos, ¿por dónde empezás? Sin un wrapper que analice el contraejemplo que Z3 genera internamente y lo traduzca a términos humanos (o que al menos identifique cuál aserción fue el punto de falla), el resultado es casi inútil para un equipo operacional.
La brecha entre la teoría y la práctica
Usar Z3 directamente para seguridad cloud requiere tres cosas que la mayoría de los equipos no tienen:
Primero, expertise en SMT-LIB. Modelar correctamente una configuración IAM compleja en lógica de primer orden no es trivial. Un error en el modelo produce respuestas correctas para preguntas equivocadas (spoiler: eso es peor que no tener respuesta).
Segundo, infraestructura de extracción. Alguien tiene que leer la configuración cloud real, transformarla en aserciones SMT-LIB, ejecutar Z3, e interpretar el output. Eso es código que tenés que mantener, con pipelines de sync a la configuración live.
Tercero, y acá está el punto que menos se discute: tenés que saber qué preguntar. Z3 responde preguntas específicas que le formulás. Si no preguntás sobre un vector de ataque particular, Z3 nunca te va a avisar que existe. No es un scanner de superficie; es un verificador de propiedades.
Construís el modelo, ejecutás el verificador, obtenés “unsat” en las tres preguntas que se te ocurrieron, y te quedás tranquilo. Pero la cuarta pregunta que no formulaste tenía respuesta “sat”. (Sí, en serio. Esto pasa.)
Herramientas que complementan Z3 para explicabilidad
La buena noticia es que no tenés que usar Z3 puro. Hay herramientas que usan SMT solvers internamente y agregan la capa de explicabilidad que falta: En documentación técnica en múltiples idiomas profundizamos sobre esto.
| Herramienta | Motor | ¿Explica por qué? | ¿Sugiere fix? | Alcance |
|---|---|---|---|---|
| AWS Policy Simulator | Zelkova (SMT) | Sí, por política | Parcialmente | Solo AWS IAM |
| Microsoft Defender for Cloud | Z3 + reglas | Sí | Sí | Azure + AWS + GCP |
| Wiz | Propio | Sí, con grafo | Sí | Multi-cloud |
| Prisma Cloud | Propio | Sí | Sí | Multi-cloud |
| Orca Security | Propio | Sí, con contexto | Sí | Multi-cloud |
| Checkov / tfsec | Reglas estáticas | Sí, por regla | Sí | IaC (Terraform, CF) |
| Z3 puro | Z3 | No | No | Lo que modeles |
AWS Policy Simulator es el ejemplo más claro de qué debería ser: tomás una acción (s3:GetObject), un recurso (arn:aws:s3:::mi-bucket), un rol, y te dice si está permitida y por qué política. Esa explicabilidad es la diferencia entre una herramienta que un equipo puede usar y un motor que requiere un investigador de seguridad dedicado.
Para infraestructura argentina o latinoamericana que corra sobre cloud, la integración con herramientas de IaC es el punto de entrada más práctico. Checkov y tfsec analizán tu Terraform antes del deploy y te dan el “por qué” que Z3 puro no da, sin necesidad de modelar nada en SMT-LIB.
Errores comunes al trabajar con verificación formal en cloud
Asumir que “unsat” significa “seguro”
“unsat” significa que la propiedad específica que modelaste no es violable dado tu modelo. Si tu modelo está incompleto o la pregunta no cubre el vector real, “unsat” es falsa seguridad. Un modelo que no incluye el caso de permisos heredados por grupos anidados puede dar “unsat” en una configuración que un atacante traversaría en minutos.
Confundir Z3 con un scanner de vulnerabilidades
Z3 no escanea superficie de ataque. Verifica propiedades específicas que le formulás. Un scanner como Prowler o ScoutSuite revisa cientos de checks predefinidos contra tu configuración. Z3 responde las preguntas que vos le hacés, que pueden ser mucho más precisas pero también mucho más limitadas si no sabés qué preguntar.
Usar Z3 puro en un equipo operacional sin capa de abstracción
Cualquiera que haya configurado políticas IAM complejas sabe que ya el lenguaje JSON de las políticas es difícil de leer. Pedir al equipo de operaciones que trabaje con SMT-LIB es agregar una capa de complejidad que ralentiza la respuesta a incidentes. Si implementás Z3, construí el wrapper primero, o usá herramientas que ya lo tienen.
Implicaciones prácticas para arquitectos de cloud
Si estás evaluando incorporar verificación formal a tu pipeline de seguridad, tres puntos concretos:
Z3 es el corazón de varias herramientas que quizás ya usás. No tenés que usarlo directamente para aprovecharlo. AWS Zelkova, que corre detrás de IAM Access Analyzer, usa SMT solving. Cuando activás IAM Access Analyzer en tu cuenta AWS, estás usando verificación formal con explicabilidad incluida. Sobre eso hablamos en ejecutar verificaciones sin APIs externas.
Si querés usar Z3 directamente para verificar propiedades custom (algo que las herramientas de mercado no cubren), el enfoque de NCC Group es un buen punto de partida: construir primero el extractor de configuración, luego el traductor a SMT-LIB, y por último el interpretador de resultados. Los tres componentes son necesarios para que sea útil.
La verificación formal tiene su lugar más claro en shift-left: verificar las propiedades de seguridad en tu IaC antes del deploy, cuando cambiar algo cuesta cinco minutos y no un incident response.
Preguntas Frecuentes
¿Qué es Z3 de Microsoft?
Z3 es un SMT solver (Satisfiability Modulo Theories) que Microsoft Research desarrolló inicialmente para verificación de hardware y software de sistemas críticos. Hoy es open source, disponible en GitHub, y se usa como motor de razonamiento lógico en herramientas de seguridad cloud, compiladores, y análisis de programas. Su función es determinar si un conjunto de restricciones lógicas puede satisfacerse simultáneamente.
¿Cómo funciona Z3 para detectar vulnerabilidades en cloud?
Modelás la configuración cloud (políticas IAM, reglas de red, permisos de buckets) como aserciones en SMT-LIB, el lenguaje de entrada de Z3. Luego formulás una pregunta: “¿es posible que un usuario no autenticado acceda a este recurso?” Z3 verifica si existe alguna asignación de valores que haga esa condición verdadera. Si la encuentra, responde “sat”; si no, “unsat”. El proceso toma milisegundos para modelos de tamaño moderado.
¿Por qué Z3 solo dice “sat” o “unsat” sin dar explicaciones?
Porque Z3 es un motor de razonamiento, no una herramienta de seguridad. Su diseño es responder si una fórmula lógica es satisfacible, no explicar qué configuración específica causa el problema ni cómo remediarlo. La capa de explicabilidad debe construirse encima de Z3, o usar herramientas que ya la tienen integrada (AWS Policy Simulator, IAM Access Analyzer, Defender for Cloud).
¿Se puede usar Z3 para verificar seguridad de configuración AWS?
Sí, y de hecho AWS ya lo hace internamente a través de Zelkova, el motor detrás de IAM Access Analyzer. También podés usar Z3 directamente modelando tus políticas IAM en SMT-LIB, aunque requiere expertise técnico considerable. La alternativa práctica para la mayoría de los equipos es usar IAM Access Analyzer o AWS Policy Simulator, que corren el mismo tipo de verificación con explicabilidad incluida.
¿Cuál es la diferencia entre un motor de razonamiento y una herramienta de seguridad?
Un motor responde preguntas que le formulás con precisión matemática. Una herramienta de seguridad extrae automáticamente la configuración relevante, formula las preguntas correctas, interpreta las respuestas, las contextualiza en términos operacionales, y sugiere remediaciones concretas. Z3 es lo primero. Wiz, Prisma Cloud, o IAM Access Analyzer son lo segundo, algunos usando Z3 internamente como motor.
Conclusión
Z3 puede probar matemáticamente que tu cloud tiene un problema. Que no te diga cuál ni cómo arreglarlo no es un bug del solver, es el costo de usar un motor de propósito general para un problema que necesita una capa de interpretación encima.
Lo que cambió en 2026 no es Z3 en sí, sino la proliferación de herramientas que lo usan internamente con la capa de explicabilidad ya construida. IAM Access Analyzer está disponible en todas las cuentas AWS. Defender for Cloud cubre multi-cloud con remediación incluida. Para quien use infraestructura en la nube, la verificación formal ya no es un tema académico.
La decisión práctica es esta: si tu equipo tiene los recursos para modelar configuraciones en SMT-LIB y construir el wrapper de interpretación, Z3 puro te da flexibilidad total. Si no (que es el caso de la mayoría), usá las herramientas que ya hicieron ese trabajo. La verificación formal está ahí en ambos casos; solo cambia cuánto de la plomería ves.
Para equipos que manejan infraestructura propia, una opción que simplifica bastante la capa de hosting y reduce la superficie de configuración que tenés que verificar es consolidar en proveedores que ya tienen estas capas de seguridad integradas, como donweb.com para hosting e infraestructura en la región.
