ASL Vault
Un vault que puede llenarse mientras está cerrado.
ASL Vault es un almacén de credenciales sellado con una asimetría deliberada: escribir necesita solo la clave pública; leer necesita su contraseña. La automatización guarda secretos nuevos continuamente mientras el vault permanece sellado — y es estructuralmente incapaz de leer lo ya almacenado.
El problema en sus palabras
Su almacén de secretos es tan seguro como las máquinas que escriben en él.
Cada tarea de CI, script de despliegue o aprovisionamiento que crea un secreto normalmente también tiene las llaves para leer todo el almacén. Un escritor comprometido y el vault queda abierto. Eso está al revés. ASL Vault lo invierte: los productores solo pueden agregar; leer exige una contraseña que nunca toca la automatización.
Qué cambia
Lo que Vault hace más claro
La criptografía — no una opción de configuración — es la que impone quién puede leer.
El estado abierto vive solo en memoria: un reinicio vuelve a sellar el vault
Auditoría encadenada por hash verificable desde el origen — ni el token de administrador puede descifrar secretos
Qué organiza
Capacidades vinculadas con el resultado
- Escritura con el vault sellado usando solo la clave pública — esta asimetría es todo el producto
- Criptografía de caja sellada: X25519 ECDH, HKDF-SHA256 y AES-256-GCM, sin dependencias externas
- La clave privada nunca se guarda sin proteger: scrypt + AES-GCM; una contraseña incorrecta simplemente falla, sin dejar hash que descifrar
- Tokens de mínimo privilegio por aplicación, con 404 a prueba de enumeración que oculta lo que un token no puede ver
- Auditoría de solo agregado, encadenada por hash, con verificación de integridad desde el origen
- Los nombres y metadatos siguen legibles mientras el vault está sellado para poder operar; los valores permanecen cerrados
Límite de protección
Lo que no debe confundirse con una promesa
Preguntas que hacen los compradores
Preguntas que hacen los compradores
Respuestas directas antes de pedir una propuesta.
¿Cuánto cuesta?
El precio se define después de una conversación corta sobre usuarios, alcance, información sensible e integración con su trabajo actual. Podemos comenzar con la versión útil más pequeña de Vault y separar claramente lo opcional.
¿Cómo escribe la automatización sin poder leer?
Escribir usa criptografía de caja sellada con solo la clave pública: cualquier proceso puede depositar un secreto nuevo, pero descifrar lo almacenado exige la clave privada, protegida por su contraseña, que nunca toca la automatización.
¿Qué pasa si comprometen una máquina que escribe?
Filtra únicamente lo que esa máquina iba a escribir; no puede leer nada ya almacenado. Esa es la asimetría estructural del diseño.
¿Cómo se protege nuestra información?
X25519, HKDF-SHA256 y AES-256-GCM; la clave privada protegida con scrypt; el estado abierto solo en memoria (un reinicio re-sella); y una auditoría encadenada por hash que se verifica desde el origen. Ni el token de administrador puede descifrar secretos.
¿Qué ocurre si dejamos de pagar?
La propuesta define antes de comenzar qué puede exportarse, cuánto dura la transición y cuándo se elimina o conserva la información por obligación. La salida no debe descubrirse después de contratar.
Funciona mejor junto
Conecte el flujo sin obligar a una compra de toda la cartera.
Cada capacidad puede comenzar sola. La conexión se agrega solo cuando mejora el resultado.
Próximo paso
Mapeemos el flujo antes de hablar de alcance.
En 20 minutos podemos identificar usuarios, resultado, límites y la primera prueba útil para Vault.