Auditoría y evidencias de cumplimiento en Monopam
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 1 → 2
Actualización3 lecciones actualizadasduración
Actualización de contenido. Se notificó a los estudiantes inscritos.
La duración cambió de 10 a 12 minutos.
Los auditores rara vez piden "enséñeme los registros". Hacen una pregunta concreta sobre una persona, un sistema y un periodo. Como Monopam intermedia cada sesión y cada revelación, la mayoría de esas preguntas tienen un único lugar correcto donde mirar.
| El auditor pregunta | Dónde está la respuesta | Aquí no |
| --- | --- | --- |
| ¿Quién accedió a este servidor el trimestre pasado, quién lo aprobó y qué hizo? | En el historial de sesiones del servidor, leído junto con sus aprobaciones y grabaciones: cada sesión intermediada está ligadapertenece a un usuario con nombre, a su aprobación y a su grabación está en `Recordings` y la aprobación correspondiente es la solicitud asociada en `Requests` | `Live Sessions` solo muestra quién está conectado ahora. `Requests` por sí solo tiene las aprobaciones, no lo que se hizo |
| ¿Quién vio o copió realmente esta contraseña? | En el evento de auditoría `Vault Revealed / Copied`, con el nombre del campo y el usuario | Abrir la página del elemento no es una revelación |
| ¿Qué sesiones abrió un asistente de IA y qué llamó? | En la insignia `AI` de las sesiones en `Recordings` y `Live Sessions`, más una fila de auditoría `MCP Tool Call` por llamada | Una sesión sin insignia no se abrió a través del servidor MCP de Monopam |
| Muéstreme todas las solicitudes de acceso del inquilino | `Requests` con el ámbito `Everyone` | El ámbito por defecto `Mine` solo lista sus propias solicitudes y las que esperan su decisión |
::diagram pam-evidence-map
Tres detalles sostienen estas respuestas.
**La revelación se registra por campo.** Un elemento del vault puede tener varios campos protegidos, y el evento nombra el que se mostró o copió. El valor desaparece de la pantalla a los 30 segundos, pero eso es una comodidad, no un control: no impide una captura de pantalla. La evidencia es el evento.
**Las llamadas a herramientas se registran tanto si tienen éxito como si fallan.** Cada fila `MCP Tool Call` lleva la herramienta, el resultado y los argumentos, con los valores que parecen secretos enmascarados. Un asistente actúa con los permisos y políticas del usuario o la identidad que tiene detrás, así que la insignia indica cómo se abrió la sesión, no que se aplicaran otras reglas.
**El ámbito `Everyone` requiere un permiso.** A un auditor interno que solo ve sus propias solicitudes y no tiene el conmutador `Everyone` le falta `monopam.requests.full`. Figurar como aprobador no lo concede. El servidor aplica la misma regla que la pantalla.
### Las notas en las grabaciones no son evidencia
Quien revisa puede dejar notas en un instante de una grabación, `Shared` por defecto. Las notas son material de revisión. No forman parte de la cadena de auditoría a prueba de manipulación, el autor puede editar las suyas y un superadministrador puede borrar las de cualquiera, pero no reescribirlas.
Eso importa cuando una nota sale mal. Suponga que un revisor pega una contraseña de producción en una nota compartida y se va de vacaciones. Un superadministrador borra la nota. Borrar no rota nada y la nota puede haberse leído ya, así que la contraseña se considera expuesta y se rota. Si el expediente del incidente necesita el texto, cópielo antes de borrar.
> Consejo: ensaye antes de la auditoría. Inicie sesión con la cuenta que usará el auditor, abra `Requests` y confirme que el conmutador `Everyone` está ahí. Un `monopam.requests.full` ausente se corrige fácilmente una semana antes y resulta incómodo descubrirlo en la reunión.
Dos preguntas vuelven en cada auditoría: "¿qué hizo este proveedor en nuestros sistemas?" y "¿qué pasó en esta ubicación?". Monopam tiene un informe listo para cada una y un proceso de revisión para las cuentas de proveedores.
### El Activity Report del proveedor
En la página `Vendors`, el menú de fila de un proveedor ofrece `Activity Report`. Elija un periodo y use `Export CSV` o `Export PDF`. El archivo lista las conexiones hechas por los usuarios de ese proveedor con el usuario, el correo, el recurso, el tipo, el estado, la hora de inicio, la última actividad y si la sesión se grabó. Es justo el archivo trimestral que un auditor pide sobre un proveedor.
La propia exportación deja rastro: cada una se escribe en la traza de auditoría como un evento `Downloaded` con el formato, el periodo y el número de filas. Así también puede mostrar quién se llevó una copia del informe.
### El informe de sitio y su única trampa
Cada sitio tiene un informe de actividad del mismo tipo con las mismas exportaciones. Responde a "qué pasó en esta ubicación", pero se construye a partir de los **recursos asignados al sitio**, no del gateway que llevó la sesión.
Por eso una planta puede parecer silenciosa en el papel y estar muy activa en la realidad. Si los gateways de la planta se asignaron al sitio pero sus servidores nunca, los gateways llevan cientos de sesiones y el informe del sitio queda vacío. Revise el recuento `Resources` en la lista `Sites`, asigne los recursos (`Advanced` > `Site`) y el informe se llena.
::diagram pam-site-report
### Revisiones de acceso de proveedores
`Start Access Review` en un proveedor pide al revisor decidir sobre cada usuario externo del proveedor.
| Decisión | Efecto |
| --- | --- |
| Approve | Se mantiene el acceso. No cambia nada |
| Reject | La cuenta se deshabilita y sus sesiones en vivo se cortan. El cambio se ve en aproximadamente un minuto |
Dígaselo a los revisores antes de empezar. Rechazar a un contratista en plena ventana de mantenimiento termina ese trabajo de inmediato. Un usuario rechazado por error puede activarse de nuevo desde la página `Users`. El inicio de una revisión y cada deshabilitación quedan en la traza de auditoría, que es la prueba de que la revisión se hizo.
### Una rutina trimestral
1. Exporte el `Activity Report` de cada proveedor para el trimestre y archívelo.
2. En la lista `Sites`, compare el contador `Resources` de cada sitio con lo que sabe que hay allí. Un cero junto a una planta con actividad significa un informe vacío.
3. Ejecute `Start Access Review` para cada proveedor y avise antes a los revisores de que `Reject` corta las sesiones activas.
Un registro solo es evidencia si se sabe qué dice y qué no. Tres tipos de registro se malinterpretan con facilidad.
::diagram pam-record-limits
### Ejecuciones de descubrimiento
Cada ejecución de descubrimiento se guarda en el historial, y sus hallazgos enlazan con ella. Las ejecuciones con más de **90 días** se eliminan una vez al día. Ningún ajuste lo cambia. Los hallazgos permanecen, solo pierden el enlace con su ejecución.
Para el cumplimiento esto significa planificar. Si la auditoría del año próximo pedirá prueba de cada ejecución del año, capture los registros mientras existan, por ejemplo como parte de un control mensual. Esperar a la petición del auditor es tarde para todo lo anterior a 90 días.
Leer los hallazgos exige el mismo cuidado:
| Hallazgo | Cómo leerlo |
| --- | --- |
| Una cuenta Unix con uid 0 que no está en sudoers | Un administrador real. uid 0 siempre se marca como administrador, se llame como se llame |
| `Exclude Built-in Accounts` está activado y aun así aparece una cuenta con uid 0 | Correcto. La opción excluye las cuentas de sistema con uid bajo, pero nunca root ni otra cuenta con uid 0 |
| Un usuario de sudo o wheel aparece como cuenta normal | Un agente que no puede listar administradores devuelve las cuentas sin esa marca en lugar de fallar. Las filas de `Logs` muestran el aviso |
| La ejecución terminó y una cuenta no aparece | No prueba que la cuenta no exista. Revise antes las filas de `Logs` de ese host |
La última fila es la que duele. Un cliente pide confirmación por escrito de que una cuenta de administrador local ya no existe porque la última ejecución no la listó. Una ejecución terminada puede haber omitido líneas que no pudo leer o no haber tenido el listado de administradores. Lea las filas de `Logs` del host antes de firmar nada.
### Lecturas de secretos por máquinas
Los pipelines y operadores leen secretos mediante identidades de máquina, a menudo cada minuto. Para que la auditoría siga siendo legible, Monopam tiene en `System` > `Secrets API` el ajuste `Machine read audit window (minutes)`, 10 por defecto. Dentro de la ventana, la repetición de la misma lectura por la misma identidad solo incrementa un contador, y la entrada siguiente indica cuántas lecturas absorbió. Los inicios de sesión, las escrituras y las revelaciones humanas siempre se registran una a una.
Si un regulador exige un registro por lectura, por ejemplo para un pipeline de pagos, ponga la ventana en `0`. Cada lectura tendrá su propia fila y la tabla de auditoría crecerá en consecuencia.
Las lecturas e inicios de sesión que llegan por la API compatible con Vault llevan en la auditoría el sufijo `(Vault-compatible API)`. Así se distingue un cliente al estilo de HashiCorp Vault de la CLI de Monopam cuando ambos usan la misma identidad.
### Sentencias de base de datos
El proxy de base de datos escribe un registro de auditoría **por sentencia**, con la decisión tomada: permitida, bloqueada, enmascarada o enviada a aprobación. Una sentencia que pasó la política pero falló en la base de datos se registra como error de backend. Esta es la evidencia de "qué ejecutaron los usuarios y qué se detuvo". `Requests` solo contiene las solicitudes de aprobación.
Por defecto la sentencia se guarda saneada: los literales se sustituyen por marcadores, de modo que se ve `UPDATE customers SET email = $1 WHERE id = $2`. La opción `AuditRawSql` guarda el texto en bruto con los literales desde el momento en que se activa. Los literales pueden contener datos personales o secretos, así que decídalo con el responsable de privacidad, no en solitario.
> Consejo: antes de entregar cualquiera de estos registros, hágase dos preguntas. ¿Cuánto tiempo se conserva? ¿Qué se agrupó o se omitió? El historial de ejecuciones se conserva 90 días, las lecturas de máquina se agrupan dentro de la ventana y las sentencias se guardan sin sus literales salvo que `AuditRawSql` esté activo.