Dos equipos piden el mismo artefacto y entienden cosas distintas. El revisor quiere la prueba de que una persona concreta aprobó un rol hasta una fecha, mientras que el equipo de red tiene un registro del cortafuegos lleno de destinos y da por hecho que cuenta. No cuenta, y por eso las carpetas de aprobaciones se llenan de nombres de host y aun así fallan la primera pregunta de auditoría. Lo que de verdad necesita es poco, y nada de ello exige registrar dónde ha navegado nadie.

El tamaño del registro sigue tres condiciones: si la aprobación se concede por persona o por rol, si el derecho puede sobrevivir a la relación laboral de la persona y si un contrato o marco cita la revisión de accesos como evidencia obligatoria.

Empiece por la pregunta del revisor, no por la conexión

Escriba la pregunta que un auditor haría en voz alta antes de elegir un solo campo. Quién aprobó el acceso para esta identidad, para qué, entre qué fechas y quién debía retirarlo al final. Cada campo del formulario debe responder a una parte de esa frase, y todo lo que no lo haga es inventario del que acaba de asumir la obligación de proteger.

Esa prueba elimina la mayor parte de lo que se añade por costumbre. Las listas de destinos, las consultas de DNS, los gráficos de uso de aplicaciones y las capturas de una sesión en vivo describen conducta. La conducta no es la aprobación, y recogerla traslada el archivo a una clase de sensibilidad mucho más alta, lo que va en contra del objetivo con el que empezó.

Tres condiciones deciden cuánto conservar

Las aprobaciones por persona necesitan una identidad y una fecha de fin. Las aprobaciones por rol necesitan el rol, el alcance que concede y el propietario de la población, porque listar cuarenta personas en una fila crea cuarenta registros que mantener y cuarenta ocasiones de pasar por alto una baja. Cuando el derecho puede sobrevivir a la relación laboral, añada un propietario de la retirada y una periodicidad de revisión, ya que una fecha de caducidad en una hoja de cálculo rara vez hace que alguien actúe.

ConditionAdd to the recordLeave out
Approved per personIdentity, approver, expiryDevice telemetry
Approved per roleRole, scope, population ownerPer-user destinations
Outlives employmentRemoval owner, review dateSession transcripts
Named in a contractThe cited artifact and its revisionA second, friendlier copy

Cuando un marco cita la revisión de accesos como evidencia obligatoria, conserve el artefacto que el proceso de revisión ya cita. Construir una copia paralela para el equipo de VPN es como dos versiones de la misma aprobación acaban discrepando sobre una fecha de fin.

Los campos que portan la decisión

El conjunto viable es corto: la identidad aprobada, el solicitante, el aprobador, el alcance del rol o del recurso, el motivo en una línea, la ventana de vigencia, el propietario de la revisión o de la retirada y un puntero al tique donde se argumentó la solicitud. Refiera el dispositivo o la credencial con un identificador no secreto, como una etiqueta de activo o el sujeto del certificado, nunca con la clave privada ni la contraseña que se utilizó.

Trate el resultado como dato personal aunque no contenga destinos. Un registro que dice que este empleado nombrado tuvo acceso administrativo al segmento de finanzas durante seis meses es sensible por sí solo, así que delimite quién puede leer la carpeta y fije una retención para la finalidad administrativa en lugar de calificar el archivo de anónimo.

Por dónde se cuela la navegación en el expediente de aprobación

Tres fugas explican la mayor parte. Un tique de soporte lleva una captura de la ventana de conexión del cliente, alguien pega una exportación del SIEM para dar contexto, o un informe de inventario se une a la aprobación porque entonces la unión era fácil. Cada adjunto añade conducta a un archivo que solo necesitaba una decisión. Una vez que la captura está dentro, el revisor empieza a preguntar a qué llegaba el usuario, y el archivo hay que reclasificarlo.

Sustituya los adjuntos por punteros siempre que la herramienta lo permita. Si la política insiste en un adjunto, pida el texto de la decisión y el hilo de la solicitud, no la captura de la sesión, y elimine el resto antes de guardar el archivo. El mensaje del propio aprobador suele ser la mejor prueba y la que menos revela.

Verifique el alcance sin el rastro

La política de la pasarela es lo que convierte una aprobación en acceso, así que pruébela directamente. Inicie sesión con una cuenta dentro del alcance aprobado y llegue a un recurso permitido, después pruebe un destino fuera del alcance y confirme la denegación, con el cliente y el método que la política espera y no con una pestaña del navegador en el mismo host.

La monitorización de disponibilidad y el diagnóstico de incidentes pueden conservar su propia visibilidad, con su propia retención y su propia lista de acceso. Mantener separados esos dos propósitos es lo que le permite responder al revisor sin entregar un rastro de navegación, y mantiene el diagnóstico útil cuando algo se rompe de verdad.

Qué comprobar antes de la próxima revisión

Confirme que el formulario responde a la frase del auditor y a nada más. Compruebe que cada fila lleva un aprobador, una ventana y un propietario de la retirada. Después mire la lista de acceso de la propia carpeta y pregunte si es más pequeña que la base de usuarios de la VPN.

El último paso es el que la gente se salta. Tome una aprobación caducada y siga su rastro hasta el proveedor de identidad para ver si la cuenta se desactivó realmente. Si la identidad sigue activa, el registro era exacto y el proceso no.

Artículos relacionados