Modelo de seguridad

Estado de revisión: Esta página base requiere revisión especializada antes de su aprobación pública. Sus afirmaciones deben mantenerse dentro del alcance indicado aquí.

UbID aplica defensa en profundidad a todo el ciclo de vida de la identidad. Ningún control aislado —contraseña, passkey, comprobación biométrica, firma, base de datos cifrada, referencia blockchain o dashboard de monitoreo— se considera suficiente por sí solo.

El modelo de seguridad conecta controles preventivos, validación, detección, evidencia y recuperación, de forma que una debilidad en una capa no comprometa automáticamente todo el sistema de confianza.

Objetivos de seguridad

Los objetivos públicos de seguridad de UbID son:

• proteger las credenciales del titular y su control criptográfico;
• impedir emisión, presentación, recuperación y acciones administrativas no autorizadas;
• asegurar que los verificadores rechacen evidencia inválida, obsoleta, no confiable o inadecuada para el contexto;
• aislar las claves institucionales del acceso ordinario de las aplicaciones;
• limitar a cada participante y servicio a la autoridad que necesita;
• detectar eventos anómalos en servicios, políticas, dispositivos, credenciales y recuperación;
• conservar evidencia suficiente para investigar sin exponer material secreto;
• recuperarse de forma segura ante pérdida de dispositivos, rotación de claves, fallas de servicio e incidentes de seguridad.

Capas de defensa en profundidad

Capa	Responsabilidad de seguridad
Proofing de identidad	Establecer evidencia antes de emitir claims de alto valor o aprobar acciones sensibles.
Autenticación	Confirmar el control de un autenticador y una sesión aprobados.
Autorización	Determinar si un actor puede ejecutar una operación específica.
Ciclo de vida de credenciales	Proteger emisión, firma, entrega, estado, renovación, suspensión y revocación.
Custodia del titular	Proteger credenciales, claves locales, dispositivos y consentimiento de presentación.
Verificación	Validar confianza del emisor, integridad, estado, vigencia, contexto y política.
Recuperación	Restituir el control legítimo mediante autorización escalonada, distribuida y respaldada por evidencia.
Control criptográfico	Separar finalidad, política, versión, proveedor y ciclo de vida de las claves.
Seguridad de plataforma	Aplicar identidad de servicio, mínimo privilegio, transporte protegido, aislamiento y entrega segura.
Operaciones	Detectar fallas, enrutar alertas, investigar eventos y probar procedimientos de restauración.

Principios Zero Trust

Zero Trust en UbID significa que la confianza no se hereda simplemente porque una solicitud provenga de una red interna, una sesión autenticada o un dispositivo previamente aprobado.

Las operaciones sensibles requieren validación explícita de condiciones relevantes, entre ellas:

• identidad del actor y del servicio;
• finalidad y alcance de la operación;
• estado de la credencial o del dispositivo;
• contexto y vigencia de la transacción;
• versión de la política;
• evidencia de autorización;
• estado de la clave y el algoritmo;
• assurance del entorno cuando corresponda.

La interfaz de usuario puede mostrar acciones disponibles, pero las decisiones autoritativas de política las adoptan servicios controlados.

Separación de funciones

Las operaciones de alto impacto no deben depender de un único actor sin restricciones. La separación de funciones puede aplicarse a:

• preparación de credenciales y emisión final;
• modificación y aprobación de políticas;
• administración de claves y uso por aplicaciones;
• solicitud de recuperación y liberación protegida;
• recopilación de evidencia y decisión final de negocio;
• interpretación por IA y ejecución determinista.

Esto reduce el riesgo de que una cuenta, servicio, administrador o agente automatizado comprometido ejecute silenciosamente una acción sensible de extremo a extremo.

Comportamiento fail-closed

Cuando no puede validarse una condición de confianza obligatoria, el valor seguro por defecto consiste en detenerse o devolver un resultado indeterminado, y no en aceptar silenciosamente evidencia más débil.

Entre los ejemplos se incluyen:

• un emisor no confiable o no resoluble;
• un algoritmo no permitido;
• una credencial expirada, suspendida o revocada;
• ausencia de vigencia o vinculación con la audiencia;
• una comprobación fallida de relación con el titular;
• una fuente autoritativa de política o estado no disponible;
• una etapa de recuperación no autorizada.

Las medidas de disponibilidad y rutas de fallback deben permanecer más restringidas que el acceso ordinario y producir evidencia clara.

Evidencia y revisión de seguridad

Los controles de seguridad deben producir evidencia que respalde:

• revisión de arquitectura y amenazas;
• pruebas de controles internos;
• investigación del ciclo de vida de credenciales y dispositivos;
• rotación de claves y respuesta a incidentes;
• ejercicios de recuperación;
• assurance independiente y auditoría.

La evidencia debe minimizarse. Registrar un secreto para demostrar que un control se ejecutó contradice el propósito del control.

Responsabilidad compartida

UbID aporta capacidades de seguridad, pero cada despliegue debe configurarlas y operarlas correctamente. Las instituciones siguen siendo responsables del gobierno, la asignación de funciones, la aplicación de parches, la infraestructura segura, la aceptación de riesgos, la respuesta a incidentes, las pruebas, la supervisión de proveedores y las obligaciones regulatorias.

Límite de la documentación pública

El portal público excluye diseño de red productiva, umbrales de seguridad, hostnames privados, reglas detalladas de fallback, identificadores de claves, modelos antiabuso, vulnerabilidades, procedimientos de incidentes y criterios internos de aceptación.

Consulta Autenticación y seguridad de dispositivos, Protección criptográfica y Auditabilidad y observabilidad.