Registro de auditoría y acceso del soporte: quién cambió qué

Imagine a Marta, office manager en una empresa de 250 personas con dos plantas y un aparcamiento. Martes, 9:50. Tres personas le escriben en diez minutos: sus reservas de escritorio se han liberado por ausencia, aunque llegaron a las 9:40 como todas las semanas. Algo ha cambiado y nadie recuerda haberlo cambiado. En la organización hay cuatro administradores, además de una integración que sincroniza los usuarios desde el directorio de la empresa. La pregunta es sencilla: ¿quién cambió qué, y cuándo?

Una semana después, su delegado de protección de datos le hace otra pregunta para la revisión anual de proveedores: "¿Ha accedido este año el proveedor del software a nuestros datos y, si es así, cuándo?". Preguntas así suelen responderse con un documento de políticas. Marta preferiría responderla con una lista.

Este artículo muestra, paso a paso, cómo el registro de auditoría de Desk & Park responde a ambas preguntas, y lo que no hace.

Paso 1: abrir el registro de auditoría y encontrar el cambio

Los administradores encuentran el registro en Registro de auditoría. Arriba hay tres contadores: eventos de las últimas 24 horas, advertencias y eventos críticos. Debajo, una tabla con las entradas más recientes, de la más nueva a la más antigua, con estas columnas:

• Marca de tiempo: cuándo ocurrió.
• Gravedad: Información, Advertencia o Crítico.
• Actor: la dirección de correo de quien hizo el cambio, con su rol debajo, o "system" para las acciones automáticas.
• Acción y Recurso: qué se hizo y sobre qué tipo de objeto.
• Detalles: los valores implicados, por ejemplo role: MEMBER → ADMIN en un cambio de rol.
• Dirección IP: desde dónde llegó la petición.

Marta escribe "policy" en el buscador ("Buscar por actor, acción o detalles..."). Ahí está la entrada: ayer a las 17:12, uno de los administradores cambió la política de reservas y acortó el plazo de check-in. La entrada registra los valores anteriores y posteriores al cambio, así que la conversación que sigue trata de si el nuevo plazo tiene sentido, no de quién lo hizo. (Si está ajustando ese plazo, nuestro artículo sobre reservas fantasma y liberación automática explica el equilibrio.)

Qué se registra

El registro cubre los cambios que un administrador podría necesitar reconstruir: usuarios y roles, reservas, espacios y mapas, sedes, la política de reservas, integraciones, la configuración del inicio de sesión único y de SCIM, la sincronización de calendarios, visitantes, dispositivos de quiosco y copias de seguridad. También aparecen los cambios realizados automáticamente por el aprovisionamiento SCIM, de modo que "el directorio desactivó a esta persona" se distingue de "lo hizo un administrador".

Cada entrada guarda el actor y su rol, la acción y el objeto afectado, el resultado, los valores anteriores y posteriores, la dirección IP y el agente de usuario del navegador.

El filtro de gravedad

Los cambios de rol, las desactivaciones y las eliminaciones se marcan como Advertencia. Las acciones fallidas son Crítico. Filtrar por gravedad es la revisión semanal más rápida: ponga el filtro en Advertencia, repase a quién se ascendió o desactivó, y listo.

Paso 2: el registro de seguridad, integrado en la misma tabla

Los cambios de contenido son solo la mitad del panorama. La misma tabla muestra también el registro de seguridad: inicios de sesión correctos y fallidos, bloqueos tras fallos repetidos, códigos de doble factor solicitados y fallidos, activación o desactivación del doble factor, restablecimientos y cambios de contraseña, y la reutilización de un token de sesión revocado. Un inicio de sesión fallido, un bloqueo o un token reutilizado aparecen como Crítico; desactivar el doble factor aparece como Advertencia.

Para Marta, eso significa un único sitio que consultar. Si una cuenta quedó bloqueada a las 7:00 y su rol cambió a las 7:05, ambas filas aparecen una junto a otra.

Paso 3: responder al DPO, el acceso del soporte queda en su propio registro

Ahora, la segunda pregunta. Cuando el operador de la plataforma, el equipo que gestiona Desk & Park, abre la vista de soporte de su organización para ayudar con un ticket, el sistema escribe una entrada en el propio registro de auditoría de su organización. Aparece como TENANT SUPPORT ACCESS, con la dirección de correo del operador, la hora y la dirección IP.

Así que Marta escribe "support" en el buscador y obtiene la respuesta en forma de lista: cuándo alguien del lado del proveedor abrió los datos de la organización, y quién fue. Esa es la diferencia entre "tenemos una política" y "aquí está el registro". La entrada llega a su registro, no a un registro que solo puede leer el proveedor. Como la página muestra las entradas más recientes, Marta convierte esta comprobación en un hábito mensual y guarda la exportación, en lugar de esperar a la revisión anual.

Dónde vive el registro y cuánto tiempo se conserva

Cada organización en Desk & Park tiene su propia base de datos PostgreSQL, con su propio rol de inicio de sesión en la base de datos, y el registro de auditoría se guarda allí, junto a sus usuarios, mapas y reservas. Explicamos por qué importa esa arquitectura en por qué los datos de su oficina exigen una base de datos aislada. El registro de seguridad lo conserva el servicio de inicio de sesión de la plataforma y se le muestra filtrado para su organización.

Las entradas de auditoría y de seguridad se conservan 365 días por defecto y después se eliminan automáticamente, de acuerdo con los plazos de conservación de la política de privacidad. Alrededor del registro están los demás controles que tiene un administrador sobre los datos de la organización:

• Copias de seguridad nocturnas cifradas de la base de datos de la organización, que el administrador de la organización puede desactivar.
• Una exportación JSON de los datos de la organización, para administradores.
• Una solicitud de eliminación de toda la organización.

Las condiciones del tratamiento de datos están en el DPA.

Consejos prácticos

• Dé a cada persona su propia cuenta de administrador. Un inicio de sesión compartido "admin@" deja inservible la columna Actor. Una persona, una cuenta.
• Haga una revisión semanal de cinco minutos. Filtre por Advertencia y después por Crítico. Busque cambios de rol que no esperaba e inicios de sesión fallidos repetidos.
• Guarde una copia si necesita un historial más largo. El botón Exportar CSV descarga las entradas cargadas en ese momento en la página, que son las más recientes. Si sus auditores quieren más de un año, exporte de forma periódica y guarde los archivos junto a sus demás registros de cumplimiento.
• Incluya el acceso del soporte en su revisión de proveedores. Una vez al mes, busque "support", exporte el resultado y archívelo para la revisión anual. Se tarda un minuto.
• Combine el registro con un inicio de sesión robusto para los administradores. El registro le dice qué ha pasado; el doble factor en cada cuenta de administrador hace menos probable que pase algo malo. Consulte SSO, llaves de acceso y autenticación de dos factores.

Alcance: lo que esto no hace

La página de administración muestra las entradas más recientes y ofrece sobre ellas búsqueda de texto libre y un filtro de gravedad, no un filtro por intervalo de fechas. La exportación CSV cubre las entradas cargadas en la página, no el año completo. No hay envío en flujo de los eventos de auditoría a un SIEM. Las entradas más antiguas que el plazo de conservación se eliminan, así que el archivo a largo plazo es su exportación, no el producto. Y el aislamiento descrito es una base de datos separada por organización, no hardware separado.

Preguntas frecuentes