Una bóveda sobre la que puedes razonar, incluido dónde se detiene

Preguntas que te harán

Gran parte del trabajo de seguridad sobre los secretos consiste en responder preguntas. ¿Quién puede leer production? ¿Quién lo hizo realmente? ¿Qué expondría una brecha en el alojamiento? ¿Qué cambió después de que alguien se fuera?

El trabajo es tener esas respuestas de una forma que puedas enseñar a un auditor, a un cliente o a tu consejo de administración.

Lo que puedes afirmar y por qué se sostiene

• El servidor no puede leer los valores. El cifrado ocurre solo en el navegador y en el agente crunu. El servidor guarda datos cifrados, claves públicas y documentos firmados, y no tiene ninguna clave de descifrado en ningún punto del protocolo.
• Una base de datos robada no abre los valores. La clave de la cuenta se deriva con PBKDF2-SHA256 en 1 000 000 iteraciones a partir de la contraseña y de una Secret Key de unos 128 bits, y ninguna de las dos llega al servidor. Una copia completa de la base de datos no sirve para adivinarlas.
• El servidor no puede concederse acceso a sí mismo. Las listas de acceso y cada versión van firmadas. Los clientes y los agentes comprueban las firmas y rechazan los estados más antiguos que el más reciente que han visto. Un dispositivo que nunca vio el estado más reciente no puede detectar una vuelta atrás.
• Los roles se aplican con claves. Un miembro con acceso a development no tiene la clave de production. Quien tiene el rol Operator inscribe máquinas sin ver ningún valor.
• El registro deja ver las manipulaciones. El registro de auditoría es una cadena de hashes: editar, borrar o insertar una entrada se nota al verificarlo. Verifícalo con un clic o exporta JSONL y compruébalo fuera de Crunu.
• Mostrar y copiar también quedan registrados. Cuando alguien revela, copia o exporta un valor, el evento se registra con su firma y se marca como notificado por el cliente.
• Las salidas dejan un registro. Dar de baja a un miembro genera un informe de exposición: qué versiones de qué entornos recibió la persona, cuándo y desde qué dirección.
• Puedes comprobar el cliente que ejecutas. Las versiones publicadas se firman con Ed25519, el cliente web se compila de forma reproducible y la app comprueba su propia compilación con la versión firmada cada vez que se carga.
• El inicio de sesión tiene límites de frecuencia. 10 intentos fallidos por dirección y 5 por cuenta en 15 minutos, y «no hay cuenta» se ve igual que «contraseña incorrecta». Una sesión dura 12 horas de inactividad y 7 días como máximo, y no puede cambiar la contraseña ni eliminar la cuenta sin la contraseña y la Secret Key.
• Segundos factores en todas las cuentas. Códigos de una app de autenticación y llaves de acceso en la web; en la terminal, un código de la app o la aprobación desde otro dispositivo con la sesión iniciada.

Algoritmos: AES-256-GCM para los valores, X25519 para sellar claves, Ed25519 para las firmas, HKDF-SHA256 para derivar claves. El modelo de seguridad explica cómo encajan.

Cuando algo no cuadra

• Las alertas saltan con inicios de sesión desde un dispositivo nuevo, un código de inscripción reutilizado, una máquina en una dirección nueva, un token de CI reutilizado, una serie de rechazos, una concesión vencida, un inicio de sesión con código de recuperación, certificados a punto de caducar, claves no entregadas y eventos de red como una política relajada o un acceso de emergencia (break-glass). Van a un webhook firmado con HMAC o al correo.
• Las restricciones de red solo sirven production a rangos de direcciones permitidos. Relajar una política espera 15 minutos con una alerta y la opción de deshacer; el acceso de emergencia de un propietario dura hasta 60 minutos, requiere un motivo y genera una alerta.
• La acción Device compromised sustituye las claves de la cuenta de la persona, cierra la sesión en sus otros dispositivos y rota todos los entornos de los que tenía una clave.
• Una conservación que tú controlas. El registro de auditoría se conserva 365 días por defecto, y la organización solo puede ampliarlo, hasta 36 500 días o de forma indefinida. El recorte deja un punto de control, así que la cadena sigue verificándose.

Lo que Crunu no puede proteger

• Un cliente web manipulado es el principal riesgo que queda, como en cualquier bóveda que funciona en un navegador: una página servida por un servidor comprometido podría capturar la contraseña y la Secret Key al iniciar sesión. Las defensas son el manifiesto firmado con el que la app se comprueba a sí misma en cada carga y una política de seguridad de contenido con integridad de subrecursos que bloquea los scripts de terceros. Esa autocomprobación se ejecuta en la misma página, por lo que no puede detectar un servidor que cambie ambas cosas. Las firmas dependen de la clave de publicación, así que no te protegen de quien tenga esa clave.
• Los valores ya vistos no se pueden recuperar. La rotación protege las versiones nuevas. Reemite los valores mismos en cada proveedor.
• El servidor ve metadatos: nombres de organizaciones, proyectos, entornos y máquinas, direcciones de correo, el registro de auditoría, y los tamaños y las horas de las versiones.
• El servidor puede negar el servicio o descartar escrituras. La defensa son las exportaciones, las copias sin conexión y, si alojas el servidor, las copias de seguridad.
• El malware en un dispositivo donde se descifran las claves (un keylogger, una extensión del navegador, root en una máquina) puede leer lo que ese dispositivo puede leer.
• Un código de recuperación abre una cuenta tras un periodo de espera sin segundo factor. La espera la impone el servidor, así que un servidor comprometido podría saltársela.
• Las restricciones de red las aplica el servidor, no el cifrado.
• Los propietarios y los administradores pueden acceder a todos los entornos compartidos mediante la clave de recuperación de la organización.
• Un servidor comprometido que colabore con un miembro dado de baja podría mantener un dispositivo nuevo en un estado anterior de la organización. Cerrar esto por completo requeriría un registro de transparencia externo.
• Si se filtran juntas la base de datos del servidor y su propia clave, los códigos de app de autenticación se debilitan como segundo factor.
• Sin inicio de sesión único (SSO) ni SCIM.

Cada limitación, con lo que puedes hacer al respecto, está en la página de limitaciones.

¿Has encontrado algo?

Escribe a security@crunu.com. Nuestro security.txt está en /.well-known/security.txt.

Documentación relacionada

• Cómo funciona el cifrado
• Qué ve el servidor
• Limitaciones
• Registro de auditoría
• Alertas
• Reglas de red
• Dar de baja a alguien del equipo