Auditabilidad y observabilidad
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í.
Una infraestructura de identidad confiable exige más que criptografía correcta. Las instituciones necesitan saber si los servicios funcionan, las políticas se aplican, credenciales y dispositivos cambian de estado, las acciones de recuperación están autorizadas y se produce comportamiento anómalo.
UbID combina observabilidad con evidencia operacional minimizada para que los eventos importantes puedan explicarse sin registrar material secreto ni datos personales innecesarios.
Observabilidad y auditoría son diferentes
- Observabilidad ayuda a los operadores a comprender el comportamiento actual del sistema mediante health, métricas, logs, trazas y alertas.
- Evidencia de auditoría permite revisar posteriormente quién o qué ejecutó una acción, bajo qué política, con qué autorización y con qué resultado.
Un dashboard puede resumir ambos aspectos, pero no constituye por sí solo la fuente autoritativa. Los eventos, métricas, referencias de política y artefactos firmados o protegidos mediante checksums siguen siendo la evidencia.
Qué debe ser observable
Los dominios operacionales públicos incluyen:
- health de servicios y disponibilidad de dependencias;
- resultados de emisión y entrega de credenciales;
- estados de éxito, fallo e indeterminación en la verificación;
- cambios de estado de credenciales;
- registro, suspensión, revocación y reemplazo de dispositivos;
- resultados de autenticación y fallback restringido;
- transiciones de etapas de recuperación y resultados de autorización;
- estado y rotación de claves y health de operaciones criptográficas;
- evaluación de políticas y uso de versiones;
- fallas de integración y patrones de error inusuales.
Esto no significa que todos los eventos sean públicos ni que toda telemetría se conserve indefinidamente.
Modelo de evidencia minimizada
Un evento útil de identidad puede registrar:
- referencias de evento y transacción;
- actor, servicio o función organizacional;
- timestamp y entorno;
- referencias de política y tipo de credencial;
- identificadores de challenge o solicitud;
- resultados de autorización y verificación;
- referencias de clave o algoritmo cuando corresponda;
- transición de estado;
- referencia de integridad de la evidencia;
- categoría de error y estado de remediación.
No debe registrar llaves privadas, secretos de recuperación, credenciales completas, claims no divulgados, templates biométricos, documentos de identidad sin procesar, access tokens ni contraseñas ordinarias de usuarios.
Cadena de evidencia
Las operaciones de alto valor pueden generar una cadena de evidencia enlazada que conecte:
- la solicitud y la finalidad declarada;
- la versión de política evaluada;
- las fuentes de evidencia consideradas;
- la decisión de autorización;
- la operación determinista ejecutada;
- el artefacto o cambio de estado resultante;
- alertas, revisión o remediación.
Las referencias de integridad y el versionado ayudan a determinar si los registros se alteraron o se separaron de su contexto original.
Alertas y respuesta
Una alerta solo es útil si tiene responsable, severidad, regla de enrutamiento, respuesta esperada y fuente de evidencia. Un exceso de alertas de baja calidad puede ocultar incidentes importantes.
El gobierno operacional debe distinguir:
- degradación de disponibilidad;
- fallas de política o confianza;
- sospecha de toma de control de cuenta;
- emisión o verificación anómala de credenciales;
- anomalías de dispositivos o recuperación;
- riesgos de claves y firma;
- incidentes de tratamiento de datos o privacidad;
- falla de la propia telemetría.
Los umbrales de alerta, reglas de detección y procedimientos de respuesta específicos de clientes permanecen controlados.
Privacidad de la observabilidad
La telemetría puede transformarse en una base secundaria de identidad si contiene identificadores estables, claims completos, contenido de Wallet o historiales detallados de presentación.
Por ello, el diseño de observabilidad debe aplicar:
- identificadores acotados y referencias seudónimas;
- acceso basado en funciones;
- retención específica por finalidad;
- redacción y allow-lists de campos;
- separación entre datos de seguridad, negocio y soporte;
- exportación y acceso de investigación controlados;
- procedimientos de eliminación y legal hold;
- monitoreo de fugas de observabilidad.
Operaciones asistidas por IA
La IA puede resumir, priorizar y explicar evidencia, pero los sistemas deterministas siguen siendo autoritativos para estado, política y ejecución.
Una explicación generada por IA debe referenciar la evidencia subyacente y declarar su incertidumbre. No debe afirmar que una acción fue ejecutada solo porque la recomendó o porque operó en modo read-only.
Assurance y pruebas
Las instituciones deben probar algo más que las rutas ordinarias de éxito. La evidencia y el monitoreo deben ejercitarse durante:
- rotación de credenciales y claves;
- falla de dependencias del verificador;
- interrupción del servicio de estado;
- compromiso y revocación de dispositivos;
- simulacros de recuperación;
- backup y restauración;
- rollback de políticas;
- respuesta y notificación de incidentes.
Un control que no puede producir evidencia durante una falla puede resultar difícil de confiar en un incidente real.
Límite de la documentación pública
El portal público no expone dashboards privados, umbrales de alerta, consultas de logs, identificadores de clientes, cronologías de incidentes, vulnerabilidades, procedimientos on-call, endpoints internos de health ni lógica de detección.
Consulta UbID Pulse, UbID Sentinel AI y Modelo de seguridad.