Grabación de sesión
Configure qué se captura durante una sesión y dónde se guarda: el backend de almacenamiento de objetos para las reproducciones, el almacén separado de los comandos, la marca de agua y en qué se difere
Qué es esto y cuándo usarlo
Toda sesión que la solución intermedia queda grabada, en todos los protocolos, sin ningún interruptor por sesión que se pueda olvidar. Esta página trata de configurar eso: qué se captura en cada protocolo, dónde se escriben los archivos, qué dice la marca de agua y cuánto tiempo sobrevive todo ello.
Encontrar y reproducir una grabación después es otra tarea, en otra pantalla, descrita en Grabaciones de sesión.
Dos almacenes, no uno
La distinción importa en cuanto empieza la configuración, porque los dos se configuran por separado y pueden vivir en lugares distintos:
Almacenamiento de objetos
La reproducción en sí: vídeo de pantalla para las sesiones gráficas, reproducción de terminal para las sesiones de texto
El propio sistema de archivos del servidor del PAM
Almacenamiento de comandos
Los comandos escritos en sesiones de terminal y de base de datos, como texto buscable
La base de datos del PAM
Qué deja tras de sí cada protocolo
SSH, Telnet
Reproducción de terminal
Sí
RDP, VNC, RemoteApp, VirtualApp
Vídeo de pantalla
No
Base de datos
Reproducción de la sesión
Sí, las consultas ejecutadas
SFTP y transferencia de archivos
Ninguna
No son comandos, sino una copia recuperable de cada archivo movido
Antes de empezar
El perfil SYSADMIN.
Una decisión sobre dónde vivirán las grabaciones, tomada antes de pasar a producción. Las sesiones grabadas en el disco local no se migran cuando más adelante se añade un backend externo.
Si va a apuntar a un almacén de objetos: el bucket o contenedor, credenciales acotadas a él y TLS disponible en el endpoint.
Una decisión de retención para los archivos, separada del ajuste de retención de la consola. Vea el aviso del apartado Retención.
Configurar dónde se almacenan las reproducciones
Abra Configuración del sistema › Almacenamiento › Almacenamiento de objetos. Existen dos entradas y ninguna se puede eliminar:
default, de tipo Server, el sistema de archivos local del servidor del PAM. Es el predeterminado activo tras la instalación.
null, de tipo Null, descrito como Do not save. Descarta las grabaciones en lugar de almacenarlas.
Haga clic en Crear y elija el tipo de backend. Los tipos admitidos son S3 (Amazon S3 y cualquier servicio compatible con S3, como MinIO o Wasabi), Ceph, Swift, OSS, Azure, OBS, COS, SFTP, Server y Null.
Rellene el endpoint, el bucket y las credenciales del backend, y déle una Descripción que diga qué sesiones debe guardar.
Fije el nuevo backend como Default. Solo un backend es el predeterminado cada vez, y es aquel en el que se escriben las grabaciones nuevas.
No deje el backend local default en producción. No tiene redundancia, llena el disco del propio servidor del PAM y no escala. Pase a un almacén de objetos externo cuanto antes, y dé al bucket cifrado del lado del servidor y una política que admita solo a la solución: GetObject, PutObject, DeleteObject, ListBucket, y nada más amplio.
Para no grabar deliberadamente una clase de sesiones, como un entorno de laboratorio, el mecanismo es el backend null, no un interruptor por sesión. Sea explícito con esa decisión: una sesión grabada en null sigue produciendo un registro de sesión, así que la lista de auditoría muestra una entrada sin reproducción detrás, indistinguible a primera vista de una grabación que falló.
Configurar dónde se almacenan los comandos
Abra Configuración del sistema › Almacenamiento › Almacenamiento de comandos.
La lista viene vacía de forma predeterminada, y eso no es un error de configuración: sin ningún backend definido, los comandos se almacenan en la base de datos de la propia solución.
Añada un backend, Elasticsearch por ejemplo, cuando la búsqueda de comandos se vuelva lenta. Con volúmenes altos de sesiones, un índice externo es notablemente más rápido de consultar que la base de datos, y saca el historial de comandos de la curva de crecimiento de esta.
Configurar la marca de agua
La marca de agua superpone la identidad a la sesión y a su grabación, de modo que una captura de pantalla o una foto de móvil lleva la identidad de quien la hizo.
Abra Configuración del sistema › Seguridad › Sesiones.
La Marca de agua viene habilitada de forma predeterminada. Se aplica a las sesiones en el navegador y a la grabación almacenada.
Edite el Contenido de la marca de agua para controlar qué dice la superposición, usando las variables de abajo. Se sustituyen por datos reales de la sesión en el momento de la conexión.
${userId}
ID del usuario
${name}
Nombre completo del usuario
${userName}
Nombre de inicio de sesión del usuario
${assetId}
ID del activo
${assetName}
Nombre del activo
${assetAddress}
Dirección del activo
${currentTime}
Fecha y hora actuales
Algunas plantillas utilizables:
La marca de agua la dibuja el conector que intermedia la sesión. Es fiable para SSH y Telnet y para las sesiones gráficas en el navegador, pero una marca de agua en sesión RDP no siempre llega a un cliente RDP nativo. Si la marca de agua es un control de cumplimiento y no solo un elemento disuasorio, mantenga a esos usuarios en la sesión por navegador. Consulte Métodos de conexión para saber cómo quitar la opción de cliente.
Retención
Configuración del sistema › Retenciones › Registro de eventos contiene las ventanas de retención que aplican las tareas nocturnas de limpieza:
Días de retención del registro de sesiones
200
Metadatos de la sesión: usuario, activo, cuenta, inicio y fin, duración, protocolo
Días de retención del registro de FTP
180
Registros de transferencia de archivos
Los días de retención del registro de sesiones controlan los metadatos de la base de datos, no los archivos de grabación. Subirlos no conserva las reproducciones más tiempo, y bajarlos no recupera almacenamiento. El ciclo de vida de los archivos en sí se fija en el propio bucket o contenedor. Configure ambos, o acabará con archivos huérfanos que nadie encuentra, o con registros de sesión cuya evidencia ya ha caducado.
Cómo verificar que funcionó
Demuestre el funcionamiento con sesiones creadas a tal efecto, una por cada protocolo que le importe, porque lo que se captura difiere según el protocolo.
Abra una sesión SSH, escriba un comando identificable y desconéctese.
Abra una sesión RDP, haga algo visualmente identificable y desconéctese.
En Auditoría › Sesiones › Sesiones históricas, confirme que ambas sesiones ofrecen Replay, y reproduzca cada una.
Confirme que la marca de agua se ve en la reproducción, no solo en la pantalla durante la sesión.
Confirme que la sesión SSH tiene lista de comandos y la RDP no: esa asimetría es la esperada, no un fallo.
Si acaba de pasar a un backend externo, mire dentro del bucket y confirme que han llegado objetos nuevos para esas sesiones. Este es el paso que caza las credenciales equivocadas y el endpoint equivocado: la consola informa del backend como configurado mientras las grabaciones siguen yendo al predeterminado antiguo.
Vigile el uso de disco del propio servidor del PAM durante unos días tras el cambio. Debe dejar de crecer al ritmo anterior.
Errores comunes
El disco del servidor del PAM se llena
Las grabaciones siguen yendo al backend local default
Configure un backend externo de almacenamiento de objetos y fíjelo como predeterminado
Se redujo la retención pero el almacenamiento nunca mengua
El ajuste de retención cubre solo los metadatos
Fije una política de ciclo de vida en el bucket o contenedor
Existe un registro de sesión sin reproducción
La sesión se enrutó al backend null, o la grabación falló
Compruebe qué backend es el predeterminado; un destino null se ve idéntico a un fallo desde la lista de auditoría
La marca de agua falta en una sesión abierta con un cliente RDP nativo
La superposición no siempre llega a un cliente nativo
Encamine a esos usuarios a la sesión por navegador
No hay lista de comandos para una sesión RDP o VNC
Los protocolos gráficos no producen registro de comandos alguno
Use la reproducción; no hay nada textual que buscar
Replay atenuado en una sesión muy corta
La sesión fue demasiado corta para contar como conexión correcta
Es lo esperado; no hay nada que recuperar
La búsqueda de comandos es lenta a escala
Los comandos están en la base de datos de la solución
Añada un backend externo de Almacenamiento de comandos, como Elasticsearch
El almacenamiento crece mucho más rápido de lo esperado
Las sesiones gráficas dominan el volumen
Dimensione y alerte sobre el bucket a partir del uso de RDP y VNC, no del de SSH
Páginas relacionadas
Grabaciones de sesión: encontrar, reproducir y descargar una grabación
Registro de auditoría: los registros que se guardan junto a la reproducción
Monitorización en vivo: ver una sesión mientras sigue en curso
Sesiones RDP: por qué una sesión gráfica no tiene lista de comandos
Transferencia de archivos: las copias que se guardan de los archivos movidos durante una sesión
Atualizado
Isto foi útil?