Gobierno
El aseguramiento solo es creíble si las acciones, el acceso y los cambios son trazables.
Una evaluación que nadie puede atribuir es un documento, no una prueba. OTReady registra quién puede ver qué, quién decidió qué y cuándo, para que el registro del trabajo pueda examinarse con el mismo cuidado que el trabajo mismo.
- El acceso es por proyecto y denegado por defecto
- Las acciones materiales de gobierno se registran como eventos de auditoría
- Los informes emitidos conservan su versión, digest y emisor
Por qué importa
El registro también tiene que resistir el escrutinio.
Casi todo lo que produce OTReady está pensado para enseñárselo a alguien: un auditor, un regulador, un consejo, un cliente. Esa audiencia preguntará con razón quién llegó a una conclusión, sobre qué base, y si pudo cambiarse después.
Esas preguntas tienen que poder responderse desde el sistema y no desde la memoria, y por eso el acceso y el historial forman parte del producto en vez de ser un añadido administrativo.
People & Access
Personas con nombre, acotadas a un proyecto.
El acceso se concede sobre un proyecto, con roles que llevan capacidades y permisos que las estrechan a exactamente lo que alguien necesita. Una restricción prevalece sobre un permiso más amplio, y por defecto se deniega.
La acotación puede llegar a una evaluación, ámbito o conduit exactos, de modo que a un revisor externo se le pueda dar precisamente aquello que se le pidió mirar y nada contiguo.
- Roles, permisos y restricciones por proyecto
- Denegación por defecto, con prioridad para las restricciones
- Acceso aplicado en el servidor, no ocultando elementos de menú
Momentos de gobierno
Las decisiones que merece la pena registrar.
Son los puntos en los que algo pasa de provisional a acordado. Cada uno es un acto explícito de una persona, no un efecto secundario de guardar un formulario.
- Aprobación de arquitectura
- Un objeto pasa a ser parte acordada de la arquitectura, al margen de dónde viniera.
- Confirmación de objetivo
- Un perfil de Security Level propuesto se convierte en objetivo confirmado sobre un sujeto con nombre.
- Revisión de evidencia
- Un revisor registra qué sustenta una evidencia, y hasta qué nivel.
- Aprobación de remediación
- El trabajo presentado para revisión se verifica y se acepta.
- Emisión de informe
- Se emite una versión, con su número, digest, emisor y momento registrados.
Historial de auditoría
Acciones materiales, legibles después.
El historial registra como eventos los cambios materiales que hacen los usuarios sobre datos canónicos, derivando el actor en el servidor en lugar de aceptarlo como entrada. Leerlo es a su vez consciente de permisos, de modo que un principal acotado no pueda usar el historial para conocer las partes del proyecto que no puede ver.
Una acción denegada no deja evento. El historial registra lo que pasó, no lo que se intentó y se bloqueó.
Qué no se afirma aquí.
Los informes emitidos son versiones inmutables, y los eventos de auditoría se escriben en la misma transacción que el cambio que describen. Eso no es lo mismo que afirmar que cada objeto del sistema sea criptográficamente inmutable, y OTReady no lo afirma. La cobertura de auditoría tampoco es todavía universal en todos los módulos: donde una superficie no está cubierta, la respuesta honesta es que no lo está, en lugar de dar a entender que todo lo está.
Capacidades relacionadas
Informes
Versiones emitidas, y qué queda fijo en ellas.
Arquitectura
Estado de aprobación en los objetos canónicos.
Remediación
Revisión y aprobación del trabajo de remediación.
Muestre el trabajo, y quién lo hizo.
Vea cómo encajan acceso, aprobación e historial en un proyecto real.