Cero cuentas privilegiadas permanentes
Zero Standing Privileges. De verdad.
La industria ya hace credenciales efímeras. Cloud ZSP va un paso más allá: identidad efímera y autorización efímera creadas bajo demanda en AWS, Azure, GCP y AD, destruidas al expirar. Cero residuo. Cero cuenta que rotar. Cero blast radius post-mortem.
No es PAM tradicional. No custodiamos passwords, no grabamos sesiones, no proxeamos tráfico. Hacemos desaparecer la cuenta privilegiada permanente — y la recreamos, con permisos acotados y condiciones de red embebidas, solo cuando alguien humano la necesita.
WE run on InfraApp.
El problema
Vender “acceso justo a tiempo” no basta si la cuenta sigue existiendo entre usos.
La industria del acceso privilegiado lleva 15 años intentando arreglar un modelo que no debería existir. Cloud ZSP no lo arregla — lo reemplaza.
Cuentas dormidas con permisos vivos
En cualquier cloud madura hay decenas o cientos de IAM users, Service Principals y Service Accounts que se usan cinco veces al año pero existen 24/7. Cada una es una llave de repuesto para el atacante.
Rotación manual que nadie hace bien
Access keys AWS, client secrets Azure, SA keys GCP. Se rotan tarde, se rotan mal, o no se rotan. Y el día del incidente descubres que la clave lleva 900 días viva.
PAM tradicional gestiona el caos, no lo resuelve
Vaults + check-out/check-in + rotación forzada mejora el control, pero la causa raíz sigue ahí: la cuenta privilegiada existe entre usos. Solo cambia quién guarda la llave.
PIM eleva sobre lo que ya existe
Azure AD PIM, IAM Identity Center. Te elevan a un role permanente preexistente. La superficie de ataque del role — su Policy, su Trust — sigue viva 24/7.
La premisa
Identidad efímera + autorización efímera. Ambas.
Cuando alguien de tu equipo necesita entrar a producción, Cloud ZSP crea al momento — dentro de tu propia cuenta de AWS, Azure, GCP o AD — un usuario nuevo con permisos nuevos, atados al sitio desde el que llama (VPN, oficina, IP concreta) y con caducidad corta.
Cuando esa caducidad llega — o si la IP cambia a mitad de sesión — Cloud ZSP borra todo lo que creó: la cuenta, los permisos, la política de confianza y las condiciones. En tu IAM no queda ni rastro.
- El propio CSP hace cumplir la condición de red. Cloud ZSP no vigila tráfico: le pide a AWS, Azure o GCP que rechace cualquier llamada que no venga del origen declarado. Es el proveedor el que aplica el candado (aws:SourceIp, Azure Conditional Access, GCP IAM conditions).
- La identidad es real en el CSP, no un token de un intermediario. El dev opera nativo (consola, CLI, SDK). Nada de portales cautivos, nada de proxies que reescriben peticiones.
- Cloud ZSP no está en el camino del tráfico. Cero latencia añadida. Si mañana Cloud ZSP se cayera, las sesiones activas seguirían operando hasta expirar.
- Al expirar, el borrado es real y auditable. No marcamos «disabled»: borramos usuario, permisos, trust y condiciones, y firmamos el borrado en la cadena de auditoría. Verificable end-to-end.
Cómo funciona
Cuatro capas, un solo modelo de acceso.
Desde el trabajo diario sin fricción hasta el rol crítico con aprobación doble, la mecánica es la misma: identidad efímera, autorización efímera, contexto en la política.
- 01
Rol de matriz
Acceso base, sin fricción.
Cada user tiene un rol de matriz por defecto en cada Workspace. Al entrar al portal: sin selección, sin aprobación, se crea identidad efímera + rol de matriz en el CSP. Cubre el trabajo diario low-risk.
- 02
Catálogo de roles con riesgo precalculado
El admin define. El motor decide.
El admin construye un catálogo. Cada rol lleva un riesgo base combinando ámbito de permisos + sensibilidad del recurso. Riesgo bajo → grant directo. Riesgo alto → workflow de doble aprobación.
- 03
Prueba antes de publicar
Cero sorpresas en producción.
Al crear o importar un rol, Cloud ZSP lo materializa contra el CSP real, verifica que los permisos son los esperados, lo elimina, y solo entonces lo marca como verificado. Un rol no aparece en el catálogo del operator hasta que ha pasado este test.
- 04
ABAC de red declarado
El contexto también es efímero.
El user declara su origen de red al solicitar (VPN, oficina, CIDR, o 0.0.0.0/0 con warning). Cloud ZSP traduce esa declaración a una condición real embebida en la identidad efímera. El CSP rechaza si la IP no coincide — no es detección pasiva, es enforcement en la fuente.
Diferenciadores
Contra las categorías vecinas: qué hace Cloud ZSP que los demás no.
Este cuadro compara lo que ofrecemos frente a las herramientas que típicamente entran en la conversación cuando el CISO plantea “acceso privilegiado a la nube”.
| Capacidad | CyberArk / BeyondTrust | StrongDM / Teleport | Cloud ZSP |
|---|---|---|---|
| Elimina cuentas privilegiadas permanentes | ✕ | ✕ | Sí |
| Identidad real en el CSP (no proxy) | — | ✕ | Sí |
| Autorización efímera, no solo credencial | ✕ | ✕ | Sí |
| Importar roles nativos del CSP | ✕ | Parcial | Sí |
| Prueba de rol antes de publicar | ✕ | ✕ | Sí |
| ABAC de red embebido en la identidad CSP | ✕ | Parcial | Sí |
| Federated URL al CSP sin exponer credenciales | ✕ | Parcial | Sí |
| Continuous authorization (revoca por drift de contexto) | ✕ | ✕ | Sí |
Compliance
Diseñado desde cero contra los marcos que te va a auditar tu regulador.
Cada solicitud, cada declaración de contexto ABAC, cada aprobación, cada emisión de credencial y cada revocación se firma criptográficamente y se encadena. Exportable como evidencia forense.
NIST
SP 800-207 Zero Trust Architecture — el norte conceptual de ZSP. SP 800-53r5 AC-2 / AC-6 / AU-9 — ciclo de vida de cuentas, mínimo privilegio, auditoría tamper-evident.
NIS2
Art. 21(2)(d) — separación de privilegios, control de acceso, auditabilidad reforzada.
ENS
op.acc.5 — mecanismos de autenticación, gestión de privilegios, trazabilidad.
ISO 27001:2022
A.5.15 Access control · A.5.18 Access rights · A.8.2 Privileged access · A.8.5 Secure authentication.
SOC 2
CC6 — Logical access controls, con evidencia exportable de cada solicitud, aprobación, sesión y revocación.
Solicita acceso
Prueba Cloud ZSP contra tu propia cuenta AWS o Azure.
Instalación sin fricción — configuras un CryptoStore contra tu Vault o KMS, conectas tu cuenta cloud con permisos narrow, y en minutos tu primer developer pide su primer acceso efímero.