Seguridad
Seguridad que sabe a hospitalidad.
Un proveedor de identidad vale lo que valen los muros entre sus inquilinos y el cuidado con que trata los secretos. Así está construido Usher Identity. Describimos lo que hace el software; no afirmamos tener ninguna certificación.
Arquitectura
Dominios separados, redes separadas.
Las páginas de Usher Identity y el emisor de cada cliente están en dominios registrables distintos. Las bases de datos están en una red que no puede llegar a internet, y la única salida es un proxy que comprueba adónde va cada conexión.
- Caddy termina el TLS de todos los hosts y elimina las cabeceras que solo pueden establecer los servicios del propio Usher Identity.
- La capa de autenticación responde por todos los entornos y los distingue por el host; nada se guarda en caché para un host y se sirve a otro.
- Cada servicio se conecta a Valkey con su propio usuario, limitado a sus propias claves. No hay usuario predeterminado.
- Las sentencias que llevan tokens y códigos nunca se escriben con sus valores en el registro de la base de datos.
Internet
Personas, tus apps, tus servidores
El perímetro
Caddy: TLS, HSTS, elimina las cabeceras internas
usheridentity.com
Sitio y Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
Capa de autenticación
El emisor y el Lobby de cada entorno
Red de datos · sin ruta de salida
Postgres
Un esquema por entorno
Valkey
Cada servicio, limitado a sus propias claves
La única salida
Proxy de salida
Para cada URL que da un cliente
Descubrimiento, JWKS, cierre de sesión
Solo direcciones públicas
Aislamiento
Nada importante en común.
Cada entorno de un proyecto tiene su propio esquema de Postgres, sus propias claves de firma y sus propios secretos sellados con su propia clave de datos. Su emisor es un host del dominio de inquilinos y sus cookies están limitadas a ese host, así que un navegador nunca envía la cookie de un entorno a otro.
usheridentity.com
El sitio, Usher Identity Console y las cuentas de Usher Identity
*.usherid.com
Un emisor por entorno, en un dominio aparte
Los usuarios, las sesiones y los tokens están en un esquema creado para este entorno. Las consultas se ejecutan en ese esquema, nunca en una tabla compartida con una columna de inquilino.
Copia el secreto de cliente de Google sellado del entorno de producción de Acme al de producción de Northwind.
Cifrado en reposo
Cifrado de sobre, ligado a su lugar.
Los secretos que das a Usher Identity se sellan con AES-256-GCM con una clave de datos que pertenece a un solo entorno. A su vez, las claves de datos están envueltas por una clave maestra con versiones que se guarda fuera de la base de datos.
- Claves de datos por entorno
- Comprometer la clave de datos de un entorno no revela nada sobre la de otro.
- Vinculación con AAD
- El entorno y la finalidad quedan vinculados a cada texto cifrado, así que un valor no se puede mover entre filas ni entre inquilinos.
- Claves con versiones
- Cada valor sellado registra la versión de la clave con la que se creó, así que las claves se pueden rotar y los valores antiguos se pueden volver a envolver.
- Autenticado
- Gracias a la etiqueta de GCM, un valor manipulado no se puede abrir, en lugar de descifrarse como otra cosa.
Clave maestra
Guardada fuera de la base de datos, con versiones
Clave de datos, una por entorno
Envuelta por la clave maestra
El secreto
Sellado con AES-256-GCM con la clave de datos
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
Prácticas
Los detalles, con cuidado.
Contraseñas, si las usas
Se guardan como hash con Argon2id, con el coste que recomienda OWASP (19 MiB, dos pasadas) y con un límite de cálculos simultáneos para que una avalancha de inicios de sesión no pueda tumbar el servicio. Las contraseñas nuevas se comprueban frente a filtraciones conocidas con la API de rangos de Have I Been Pwned, que solo ve un prefijo corto del hash de la contraseña. La longitud mínima es de 12 caracteres por defecto.
Nada guardado que se pueda reutilizar
Los secretos de cliente, los tokens, los tokens de los enlaces mágicos y los códigos por correo electrónico se guardan como hash. Los códigos de reserva se guardan cifrados. Un código de autorización dura cinco minutos; un código por correo electrónico admite tres intentos.
Límites de frecuencia en todas las puertas
El inicio de sesión, el registro, los códigos por correo electrónico, los enlaces mágicos, el restablecimiento de contraseñas y las comprobaciones del segundo factor tienen cada uno su propio límite: por ejemplo, diez inicios de sesión con contraseña por minuto y cinco códigos por correo electrónico cada diez minutos.
Una Content-Security-Policy estricta
Cada página del Lobby recibe un nonce nuevo y una política construida en torno a él: solo se ejecutan los scripts de este origen que llevan el nonce, los formularios solo se envían al mismo origen y otros sitios no pueden insertar la página en un marco.
Un registro de auditoría fiable
Los cambios en espacios de trabajo, proyectos y entornos se escriben en un registro en el que solo se puede añadir, y cada entrada está encadenada por hash a la anterior, así que una entrada editada o que falte se nota.
Un proxy de salida para las URL de los clientes
Cada petición que Usher Identity hace a una dirección que le ha dado un cliente (descubrimiento OIDC, JWKS, cierre de sesión por canal secundario) sale por un único proxy. Este resuelve el nombre una sola vez, rechaza las direcciones privadas, de loopback, de enlace local y de metadatos de la nube, y se conecta a la dirección que ha comprobado, así que un ataque de DNS rebinding no puede convertir la URL de un cliente en una interna.
Alias que nunca se asignan dos veces
El alias de un entorno de producción es la primera etiqueta de su emisor. A Console solo se accede por invitación, un Lobby denunciado por phishing se suspende, y un alias que ya se ha usado nunca se vuelve a asignar, porque puede que haya apps antiguas que aún confíen en sus tokens.
Sesiones que terminan cuando tú dices
Usher Identity comprueba sus propias sesiones en cada petición en lugar de fiarse de una copia en caché, así que una sesión que cierras se acaba al momento. Los tokens de acceso duran poco (diez minutos por defecto) y tu API puede consultarlos por introspección.
Divulgación responsable
¿Has encontrado algo? Cuéntanoslo primero.
Si crees que has encontrado un problema de seguridad en Usher Identity, queremos saberlo, y trabajaremos contigo para solucionarlo.
- Qué has encontrado, dónde y cómo reproducirlo.
- Qué podría hacer alguien con ello, tal como lo entiendes.
- Cómo podemos ponernos en contacto contigo y si quieres que te mencionemos.
Te pedimos que hagas pruebas solo en entornos que sean tuyos, que no accedas a datos de otras personas y que nos des un plazo razonable para solucionar el problema antes de compartirlo. Para denunciar una página que se hace pasar por un inicio de sesión de Usher Identity, consulta Denunciar un abuso.