Modelo de seguridad: el servidor solo guarda datos cifrados

Crunu cifra el contenido de cada entorno en tu navegador o en el agente crunu antes de enviar nada. El servidor guarda datos cifrados, claves públicas y registros firmados, y en ningún punto del protocolo tiene una clave capaz de descifrarlos.

En app.crunu.com, ese servidor lo opera Crunu. Si alojas Crunu por tu cuenta, lo operas tú. En ambos casos, el servidor no puede leer tus valores. Crunu está en acceso anticipado, así que solo describimos lo que hace la versión actual y actualizamos esta página cuando eso cambia.

En resumen

• Tus entornos se cifran en tus dispositivos. El servidor solo guarda datos cifrados y no tiene ninguna clave para leerlos.
• Tu contraseña y tu Secret Key nunca salen de tu dispositivo, así que una base de datos robada no ayuda a nadie a adivinarlas.
• Cada entorno tiene su propia clave. Las personas, las máquinas y los tokens de CI reciben solo los entornos que se les conceden.
• Las listas de acceso y las versiones van firmadas, así que el servidor no puede añadirse como destinatario ni cambiar tus datos sin que se note.
• El servidor sigue viendo metadatos: nombres, direcciones de correo, el registro de auditoría y cuándo se guardó cada versión.
• El principal riesgo que queda es una página web manipulada. Limitaciones conocidas lo explica junto con todos los demás límites que conocemos.
• No publicamos un informe SOC 2 ni una auditoría externa. ¿Has encontrado un problema? Escribe a security@crunu.com.

Cómo viaja un secreto, paso a paso

Sigue a STRIPE_SECRET_KEY desde el momento en que Priya lo guarda hasta los programas que lo leen.

1. El navegador de Priya cifra y firma. Su contraseña y su Secret Key, 26 caracteres aleatorios creados en su dispositivo, se combinan en la clave de su cuenta, y ninguna de las dos se envía nunca. Al guardar, el navegador cifra toda la nueva versión del entorno, con cada archivo y cada variable, como un único registro con la clave de ese entorno (AES-256-GCM). Rellena el registro hasta bloques completos de 4 KB para que no se vea el tamaño exacto, y firma la versión en nombre de Priya (Ed25519).
2. El servidor guarda lo que no puede abrir. Conserva un registro cifrado por versión, no uno por valor, junto con la lista de acceso firmada que indica quién puede leerlo. Decide a quién entregar los datos cifrados, pero no tiene ninguna clave para descifrarlos.
3. Un compañero recibe solo los entornos que se le conceden. Jonas recibe las claves de los entornos development y staging, cada una sellada con su propia clave pública (X25519). Production no está en su lista de acceso, así que nunca recibe su clave. Su navegador comprueba cada firma y cada número de versión antes de descifrar.
4. Un servidor recibe su entorno de la misma forma. El agente de api-prod-1 recibe la clave de production sellada para esa máquina, comprueba lo que le envió el servidor y mantiene el entorno descifrado en memoria. Tu programa lo recibe mediante crunu run, o como archivos donde lo pidas con crunu pull.
5. Un trabajo de CI recibe exactamente su parte. El token de servicio de GitHub Actions solo puede leer web-app / staging. Con una vinculación con la CI (OIDC), solo funciona desde el repositorio y la rama que elegiste.

En app.crunu.com, el servidor se ejecuta en Cloudflare. La página Subencargados enumera todas las empresas que tratan datos para el servicio y qué puede ver cada una.

En la documentación: Cómo funciona el cifrado

Claves y algoritmos

Crunu usa piezas estándar: AES-256-GCM para cifrar, X25519 para sellar claves para un destinatario, Ed25519 para firmar, y HKDF-SHA256 y PBKDF2-SHA256 para derivar claves. El navegador usa su WebCrypto integrado y el agente, la biblioteca estándar de Go. Ambos se prueban con los mismos vectores de prueba.

Si se filtra una copia de la base de datos, no sirve para adivinar tu contraseña: cada intento necesita también tu Secret Key, que nunca estuvo en el servidor, así que comprobar un solo intento supone recorrer unas 2¹²⁸ posibilidades. Los tokens solo se guardan como hashes con clave.

En la documentación: Emergency Kit y Secret Key · Código de recuperación

Cada entorno se sella por separado

• Las organizaciones se separan con sus propias claves. Un servidor puede alojar muchas organizaciones. Cada una tiene sus propias claves de firma y de recuperación, y las claves de sus entornos solo se sellan para los miembros y las máquinas que esa organización ha certificado.
• El acceso a development no abre production. Cada entorno tiene su propia clave, y quien no tiene la clave de production no puede leer production.
• Specific files significa archivos concretos. Una persona con ese rol, o una máquina configurada con Selected files, recibe una copia sellada solo de los archivos elegidos.
• Los operadores configuran máquinas sin ver los valores. No tienen ninguna clave de entorno. Una persona que tiene la clave aprueba el acceso de cada máquina.
• Las reglas de red limitan adónde va el contenido. Un entorno puede entregarse solo a rangos de IP permitidos, por igual a personas, máquinas y tokens. Relajar una regla requiere esperar 15 minutos, con una alerta, salvo que la firme un segundo administrador. Endurecerla tiene efecto inmediato. Es una regla que aplica el servidor, no cifrado.

En la documentación: Roles en organizaciones y entornos · Reglas de red

Qué puede ver el servidor y qué no

Un servidor ciego sigue necesitando algunos datos: a quién entregar los datos cifrados y qué escribir en el registro de auditoría. Esta es la lista completa.

Legible para el servidor

• Los nombres de organizaciones, proyectos, entornos, máquinas, tokens de servicio, perfiles de acceso y listas de redes
• Los nombres y las direcciones de correo de los miembros, y las direcciones a las que se envían las invitaciones
• Quién tiene qué rol en qué entorno, según la lista de acceso firmada
• De cada versión: su número, quién la guardó, cuándo y su tamaño redondeado hacia arriba a un múltiplo de 4 KB
• Qué versión recibió cada persona, máquina y token, cuándo y desde qué dirección IP
• El registro de auditoría, tus dispositivos y sesiones, y las direcciones IP que usan
• Tus reglas de red: los rangos de IP que permites
• El secreto de tu app de autenticación, si usas una. El servidor comprueba tus códigos, así que guarda ese secreto cifrado con su propia clave.

Solo datos cifrados

• Todo lo que hay dentro de un entorno: nombres y valores de las variables, nombres de archivo, rutas, contenido y notas. Cada versión es un único registro cifrado del entorno completo, así que el servidor no ve las variables por separado ni cuál cambió.
• Los archivos que envías mediante enlaces de acceso
• Las claves privadas de las cuentas y de la organización

Nunca se envía al servidor

• Tu contraseña y tu Secret Key
• Tu código de recuperación. El servidor guarda una copia de la clave de tu cuenta que solo ese código puede descifrar.
• Las claves privadas de las máquinas, que se crean en la máquina y se quedan allí
• La clave de un enlace de acceso, que va después del # que los navegadores no envían
• Los propios tokens de servicio. El servidor solo conoce sus claves públicas.

Eso es lo que entendemos por servidor ciego: ve quién y cuándo, pero nada de lo que hay dentro de tus entornos. En app.crunu.com, la lista de datos legibles es exactamente lo que Crunu puede ver, y la Política de privacidad indica cuánto tiempo lo conservamos. No pongas secretos en los nombres: un proyecto con el nombre de un acuerdo aún no anunciado le cuenta al servidor ese acuerdo, aunque todos los valores que contiene sigan cifrados.

En la documentación: Qué ve el servidor

Quién puede leer tus secretos

• Las personas a las que das acceso. Los miembros reciben solo los entornos que se les conceden. Ocultar los valores en la app es una cuestión de presentación: quien puede descifrar un valor puede copiarlo.
• Los propietarios y administradores. Tienen la clave de recuperación de la organización, así que pueden abrir todos los entornos compartidos. También pueden abrir los entornos personales de los miembros mientras esté activada la recuperación de entornos personales de la organización, que viene activada por defecto.
• Las máquinas y la CI. Cada máquina y cada token leen solo lo que se les concedió. Los códigos de inscripción duran 15 minutos por defecto y se consumen en el primer uso, y una máquina solo se aprueba después de comprobar que coincide la huella que crunu enroll muestra en ella. Una máquina revocada descarta sus entornos en cuestión de minutos mientras está en línea.
• No el personal de Crunu. En app.crunu.com, Crunu opera el servidor, y el servidor no tiene ninguna clave. Vemos los metadatos de la lista anterior. Llegar a tus valores exigiría cambiar el código que se ejecuta en tu dispositivo, por ejemplo con una página web manipulada. Limitaciones conocidas explica ese riesgo.
• Quien intente entrar en una cuenta. El inicio de sesión admite 10 fallos por dirección IP y 5 por cuenta en 15 minutos, y un correo desconocido y una contraseña incorrecta reciben la misma respuesta. Un dispositivo nuevo necesita tu segundo factor, una app de autenticación o una llave de acceso, en cuanto activas uno. Las sesiones terminan tras 12 horas de inactividad y 7 días como máximo, y una sesión robada no puede cambiar tu contraseña, tu Secret Key ni las claves de tu cuenta.

En la documentación: Máquinas y concesiones · Vincular un token de servicio a la CI con OIDC · Iniciar sesión desde la terminal

Cómo se compilan y se comprueban las versiones

• Cada versión publicada del agente crunu y de la app web se firma con una clave de publicación Ed25519.
• Las versiones del agente se publican en releases.crunu.com: binarios, paquetes .deb, install.sh y un manifiesto firmado. El instalador comprueba el SHA-256 del binario del agente, y crunu self-update comprueba la firma de la versión con una clave incorporada en el agente. El comando de instalación que muestra la app web lleva las sumas de verificación de la versión firmada.
• Crunu publica el manifiesto firmado de la app web en app.crunu.com. Al cargarse, la app comprueba esa firma y su propia compilación con el manifiesto, y muestra «Signed build» en la barra lateral. Selecciona esa marca para comprobar cada archivo del sitio. Si algo no coincide, la app te avisa de que no introduzcas tu contraseña.
• Esa comprobación se ejecuta en código que entregó el mismo servidor. Detecta un despliegue roto o mezclado, pero no un servidor que cambie a la vez la página y la comprobación.
• La compilación de la app web es reproducible: un mismo commit del código fuente produce siempre los mismos archivos. La página no admite scripts de terceros y carga su propio código con sumas de verificación de integridad (CSP y SRI).
• Pocas dependencias: el agente usa solo la biblioteca estándar de Go, y el código del navegador incluye un único paquete de npm, yaml.

En la documentación: Actualizar crunu con self-update

Copias de seguridad, disponibilidad y salida

• En app.crunu.com, la base de datos conserva hasta 30 días de historial de restauración en Cloudflare. Durante el acceso anticipado no garantizamos ningún nivel de disponibilidad. Consulta los Términos del servicio.
• Guarda tu propia copia. La app puede descargar una copia sin conexión de todos los entornos a los que tienes acceso. Se abre con tu contraseña y tu Secret Key, sin ningún servidor. Los entornos con restricciones de red no se incluyen.
• Ejecútalo por tu cuenta o cámbiate. El mismo servidor funciona en Docker en una máquina propia, en Cloudflare Workers, Vercel y Google Cloud Run, y en AWS App Runner en las cuentas que aún tienen acceso a él. Un único archivo sin valores sin cifrar lo traslada de una plataforma a otra, y ese mismo archivo es tu copia de seguridad. Consulta Autoalojamiento.

En la documentación: Exportación y copia sin conexión · Copias de seguridad y restauración

Qué se conserva y durante cuánto tiempo

• Versiones. Cada entorno conserva sus últimas 100 versiones, hasta 64 MB. Restaurar una versión antigua la guarda como una versión nueva.
• Registro de auditoría. Los inicios de sesión, las invitaciones, los cambios de rol, las versiones guardadas, las rotaciones de claves, las máquinas, los tokens, los enlaces de acceso y las peticiones denegadas van a un registro cuyas entradas forman una cadena de hashes. Modificar, borrar o insertar una entrada rompe la cadena, y «Verify integrity» lo muestra. El registro se conserva 365 días por defecto, y los propietarios pueden ampliar ese plazo. Los valores nunca aparecen en él, porque el servidor no los tiene.
• Registros de entregas y eliminación. El registro de quién recibió cada versión se conserva 90 días después de su última entrega y luego se resume. Para eliminar tu cuenta hacen falta tu contraseña y tu Secret Key. Una organización eliminada deja de estar disponible al instante y se borra por lotes poco después. La Política de privacidad tiene la tabla completa.

En la documentación: Registro de auditoría · Versiones e historial

Si el propio servidor está comprometido

Diseñamos para el peor caso: una base de datos vulnerada, un operador malintencionado o una cuenta en la nube secuestrada, tras lo cual el servidor puede responder lo que quiera. Tus dispositivos comprueban lo que envía, así que ni siquiera entonces puede leer tus valores, añadirse como destinatario, cambiar una clave, modificar una versión, renombrar production, hacer pasar por tuya una organización propia ni colar otra clave cuando alguien se une. Las apps y los agentes también recuerdan el estado más reciente que han aceptado y rechazan cualquier estado anterior, así que reenviar una lista de acceso antigua no devuelve el acceso a alguien que diste de baja. Un dispositivo completamente nuevo no tiene con qué comparar, así que en su primera visita no puede detectar una vuelta atrás.

Lo que sí puede hacer es negarse a dar servicio, leer metadatos y servir una página web manipulada. Las alertas señalan los inicios de sesión desde dispositivos nuevos, los códigos de inscripción reutilizados, los tokens de CI reenviados y los rechazos repetidos. Cuando alguien se va, la app rota las claves que tenía y enumera los valores que hay que reemitir. Para un dispositivo robado, «Device compromised» sustituye las claves de tu cuenta y rota todos los entornos de los que tenías una clave.

Si sabemos que app.crunu.com ha sido vulnerado, avisaremos por correo a los titulares de las cuentas afectadas sin demora indebida: qué pasó, qué datos se vieron afectados y qué hacer a continuación. Una vulneración del servicio expone datos cifrados y metadatos, no los valores de tus entornos, que no se pueden descifrar sin tu contraseña y tu Secret Key. La Política de privacidad recoge el mismo compromiso.

En la documentación: Dar de baja a un compañero · Rotar las claves de los entornos · Alertas

Lo que depende de ti

El cifrado saca al servidor de la lista de cosas que pueden leer tus secretos. Hay algunas cosas que solo puedes hacer tú.

• Imprime tu Emergency Kit al registrarte y guárdalo lejos de tus dispositivos. Nadie, tampoco nosotros, puede restablecer tu contraseña ni recuperar tu Secret Key.
• Crea un código de recuperación y guárdalo separado del Emergency Kit. Abre tu cuenta tras un periodo de espera, una hora por defecto, sin tu segundo factor.
• Activa un segundo factor y mantén corto el bloqueo por inactividad. Por defecto, la app olvida tus claves tras 10 minutos sin actividad.
• Da a cada persona y a cada máquina solo lo que necesitan, y ten pocos propietarios y administradores.
• Cuando alguien se vaya, reemite en cada proveedor los valores que vio. La rotación protege las versiones nuevas, no lo que ya vio.
• Si la app avisa «Build signature doesn’t match: do not enter your password», no la introduzcas y avisa a tu administrador.

En la documentación: Limitaciones · Bloqueo e inactividad

Auditorías y documentación

Crunu es nuevo y está en acceso anticipado. No tiene certificación SOC 2 ni ISO 27001, y no se ha publicado ninguna auditoría externa.

Estos documentos explican cómo trata los datos el servicio:

• Política de privacidad: qué datos tenemos, por qué y durante cuánto tiempo
• Subencargados: quién opera el servicio con nosotros y dónde
• Términos del servicio y Política de uso aceptable

Para tus propias revisiones, los propietarios y administradores pueden exportar el registro de auditoría en JSONL y comprobar su cadena de hashes fuera de Crunu. Cuando alguien se va, el informe de exposición muestra qué versiones de qué entornos recibió, cuándo y desde dónde, y puedes descargarlo.

Informar de una vulnerabilidad

Escribe a security@crunu.com con los pasos para reproducir el problema. No incluyas secretos reales en el informe.

Cuando hagas pruebas, por favor:

• prueba solo con cuentas y organizaciones que hayas creado tú, o con permiso de sus propietarios;
• no accedas a datos de otras personas ni los conserves, y avísanos si llegas a ellos por accidente;
• no hagas pruebas de denegación de servicio, no envíes spam y no uses ingeniería social;
• mantén el escaneo automatizado lo bastante ligero para no afectar a otros usuarios.

Te confirmaremos que hemos recibido tu informe y te mantendremos al tanto mientras trabajamos en él. Acordaremos contigo una fecha de divulgación, normalmente en un plazo de 90 días desde tu informe.

La Política de uso aceptable tiene las reglas completas, incluido nuestro compromiso de no emprender acciones legales por investigaciones de buena fe. El mismo contacto figura en security.txt.