La autenticación

01En una frase #sec_ae957ae4

REVIEWIT es su propia autoridad de autenticación: el cliente conserva su proveedor de identidad, y el producto se reserva el derecho de decidir lo que acepta como prueba de identidad, y con qué nivel de confianza.

02El problema #sec_a55cce9c

Una herramienta de recertificación afirma, campaña tras campaña, que tal persona ha decidido tal cosa. Todo el valor probatorio se basa, por tanto, en una pregunta previa a todo lo demás:

¿Qué garantiza que era ella?

Se acumulan tres dificultades, y no son de la misma naturaleza.

El cliente ya tiene su proveedor de identidad. No lo cambiará por una herramienta, y está fuera de cuestión pedirle que cree contraseñas adicionales. Un directorio de empresa, un proveedor en la nube, a veces varios según las entidades: la herramienta debe apoyarse en ellos, no sustituirlos.

Apoyar en un único proveedor encierra al producto. Un software que sólo puede autenticarse contra un solo ecosistema es inutilizable para quien no forma parte de él, y se convierte en rehén de las evoluciones de ese proveedor.

No todas las autenticaciones son iguales. Abrir la cola de trabajo de un revisor y modificar los parámetros de gobernanza de una entidad no deberían exigir la misma prueba. Todavía hay que saber, en el momento de la decisión de acceso, cómo se ha autenticado la persona, información que las aplicaciones casi nunca poseen.

03La elección #sec_d821c25a

El producto delega la verificación de la identidad, nunca la decisión de lo que acepta.

REVIEWIT introduce una autoridad de autenticación interna. Las aplicaciones ya no hablan con un proveedor de identidad: hablan con esta autoridad, en un lenguaje estándar. La autoridad, por su parte, se encarga de ir a verificar la identidad con el proveedor del cliente, sea el que sea.

La ganancia es doble. El cliente mantiene su directorio, sus reglas, su política de autenticación. Y el producto gana un lugar único donde razonar sobre lo que acepta, en lugar de dejarlo a cuatro aplicaciones que lo harían cada una a su manera.

Seis principios estructuran esta elección. Son ellos los que marcan la diferencia entre «funciona» y «aguanta ante una auditoría».

1. La prueba es fehaciente, nunca la solicitud

Es el principio más importante y el más contraintuitivo.

Una aplicación puede solicitar al proveedor de identidad una autenticación fuerte. Pero esta solicitud no es más que una solicitud: según el proveedor, su configuración, el estado de la sesión o la política en vigor, puede ser parcialmente atendida, ignorada o eludida silenciosamente.

REVIEWIT, por tanto, nunca confía en lo que ha pedido. Verifica lo que regresa, y si la prueba esperada no está ahí, se deniega el acceso. Pedir es un esfuerzo de buena voluntad; verificar es la garantía.

Esto es lo que separa una política de seguridad anunciada de una política de seguridad efectiva.

2. El nivel de confianza, no el mecanismo

Las aplicaciones nunca razonan sobre «¿la persona ha utilizado tal dispositivo?». Razonan sobre un nivel de confianza ordenado:

Una pantalla exige un nivel mínimo; el mecanismo que lo ha producido no lo mira. La ventaja es duradera: cuando aparece un nuevo medio de autenticación, basta con saber a qué nivel corresponde, ninguna aplicación debe ser modificada.

El producto también conserva el momento de la autenticación, lo que permite exigir una autenticación reciente para un gesto sensible, y no sólo una autenticación válida. Esta información nunca se reconstruye por aproximación: si falta, la regla de frescura falla en lugar de dejar pasar.

3. Nunca una coincidencia automática por dirección de correo electrónico

Cuando se presenta una identidad desconocida, la tentación es vincularla a una cuenta existente con la misma dirección. REVIEWIT nunca lo hace.

La dirección de correo electrónico no es una prueba de identidad: es declarativa, reasignable y falsificable en un proveedor mal configurado. Una coincidencia automática sobre este criterio es un vector clásico de toma de control de la cuenta: basta con hacer emitir una identidad con la dirección correcta para heredar los derechos de otra persona.

El vínculo entre una identidad externa y una cuenta REVIEWIT se establece, por tanto, sobre un triplete estable -el proveedor, el emisor, el identificador del sujeto- y una coincidencia entre varios proveedores es objeto de un flujo controlado y explícito, nunca de una deducción.

4. La cuenta REVIEWIT es la autoridad de sesión

Una autenticación exitosa en el proveedor del cliente no es suficiente para abrir una sesión.

El producto mantiene su propio registro de cuentas, y este registro dictaminará: una cuenta desactivada en REVIEWIT se verá denegada el acceso incluso si el proveedor de identidad acaba de autenticarla con éxito. Los dos ciclos de vida están separados: revocar un enlace de identidad no es desactivar una cuenta, y viceversa.

Esta verificación se repite en cada emisión de acceso, incluso durante las reconexiones silenciosas que permite la sesión única. Es precisamente el caso en el que uno podría creer que «no hay nada que volver a verificar» -y es el caso en el que una desactivación permanecería sin efecto durante horas.

5. Identidad y contexto no se confunden

La autoridad de autenticación establece quién eres. Nunca decide a qué tienes derecho, ni a qué suscripción o espacio de trabajo perteneces.

Cuando se transmite un contexto, se hace como una pista firmada -útil para evitar que el usuario vuelva a seleccionar su ámbito- y nunca como una prueba de pertenencia. La aplicación vuelve a verificar sistemáticamente los derechos como si esa pista no existiera.

Confundir ambos es el error que produce las elevaciones de privilegios más discretas: un token que afirma un ámbito siempre acaba siendo creído.

6. Los secretos no están en la base de datos

La base de datos contiene la referencia de un secreto, nunca su valor. Los secretos viven en un almacén dedicado, con un mecanismo de rotación de doble versión: el nuevo secreto se activa mientras el antiguo sigue siendo aceptado durante el cambio, y luego se revoca.

El mismo razonamiento es válido para las claves: las que firman los tokens destinados a los humanos son distintas de las destinadas a las máquinas, con emisores y destinatarios explícitos. Un token emitido para una aplicación nunca es aceptable donde se espera otro: los mecanismos son compartidos, nunca los secretos.

04Dos autoridades, deliberadamente separadas #sec_dd4e68e8

Estos dos mundos tienen amenazas, ciclos de vida y requisitos diferentes. Hacer que coexistan en una misma autoridad conduciría tarde o temprano a que un token diseñado para uno sea aceptado por el otro. Ver el [dossier API](REVIEWIT_Dossier_API_v1.0.md).

05El proveedor de identidad del cliente #sec_9c97a8ca

Cada suscripción declara su o sus proveedores de identidad. El enrutamiento se realiza en el dominio de la dirección profesional: el usuario introduce su dirección, y se le envía al proveedor que le concierne.

Los proveedores que cumplen los estándares modernos son compatibles de forma nativa, lo que cubre la mayor parte del parque, incluidos los directorios de empresa alojados en sus versiones recientes. Los protocolos más antiguos son tratados por adaptadores, en un segundo momento.

Un punto de diseño merece ser señalado: la conexión de los usuarios y la recopilación de datos son dos caminos distintos. Las autorizaciones que el producto necesita para hacer un inventario de los recursos de un cliente nunca transitan por el proceso de conexión. Un usuario que se conecta no concede nada más que su identidad, y una modificación de la configuración de recopilación no puede romper la autenticación.

06Los accesos de emergencia #sec_5e779c5b

El producto prevé cuentas de emergencia, para el caso de que el proveedor de identidad del cliente estuviera indisponible.

Dos salvaguardias: estas cuentas son explícitamente designadas, una por una -no existe una regla del tipo «todos los administradores pueden conectarse de otra manera»- y su uso está sujeto a un registro reforzado en la [pista de auditoría](REVIEWIT_Dossier_PisteAudit_v1.0.md).

Un acceso de emergencia es una excepción asumida, no una puerta trasera permanente.

07Una elección asumida: el reemplazo en blanco #sec_50dd8f34

El antiguo dispositivo de autenticación no se migra, se reemplaza. Ningún camino doble, ningún período en el que ambos coexistan.

La razón es de seguridad, no de comodidad. Mantener dos caminos de autenticación, es mantener dos superficies de ataque, dos juegos de secretos, y la obligación permanente de verificar que el más débil de los dos no puede ser tomado para eludir al otro. Las antiguas inscripciones de aplicaciones son desmanteladas y sus secretos revocados.

Es el mismo razonamiento que para la [pista de auditoría](REVIEWIT_Dossier_PisteAudit_v1.0.md): mejor un soporte corto y neto que un soporte largo del que no se puede afirmar nada.

08Lo que el producto no hace #sec_c39b58a6

• No gestiona contraseñas. REVIEWIT no almacena ninguna, no verifica ninguna, y no hace expirar ninguna. Ese es el trabajo del proveedor de identidad del cliente.
• No implementa su propio multifactor. El refuerzo de la autenticación se basa en los dispositivos del cliente. Lo que el producto aporta, es la capacidad de exigir y verificar un nivel dado — no de proporcionarlo.
• No decide los derechos. La autenticación establece la identidad; las autorizaciones son llevadas por el workspace y la suscripción.
• No confía en una declaración. Ni la dirección de correo electrónico, ni un contexto anunciado, ni una solicitud de autenticación fuerte valen como prueba.

09A recordar #sec_5948ea3f

La autenticación es la fundación sobre la que todo lo demás descansa: sin ella, « Marie certificó este acceso el 14 de marzo » es una afirmación inverificable.

REVIEWIT se basa en la identidad que el cliente ya controla, pero mantiene el control sobre lo que acepta. Verifica las pruebas en lugar de confiar en las solicitudes, razona en niveles de seguridad en lugar de mecanismos, rechaza las aproximaciones convenientes que hacen las tomas de control, y se reserva la última palabra sobre la apertura de una sesión.

Esto es lo que permite afirmar no solo que se ha tomado una decisión, sino por quién, y con qué grado de certeza.