La auditoría te permite responder preguntas críticas como "¿Quién cambió este precio?" o "¿Cuándo se eliminó este cliente?". Además, es requisito fundamental para cumplir con regulaciones como GDPR, SOX e HIPAA.
Objetivos de aprendizaje
- Configurar y utilizar el sistema de auditoría de Dataverse
- Implementar políticas de retención de logs
- Cumplir con requisitos de compliance (GDPR, SOX, HIPAA)
- Analizar logs para investigaciones de seguridad
Por qué la auditoría es esencial
Imagina esta situación: un cliente importante llama furioso porque el precio de su contrato cambió sin aviso. Tu equipo de ventas jura que nadie tocó nada. El cliente insiste en que la semana pasada el precio era diferente. ¿Cómo resuelves esto?
Sin auditoría, es palabra contra palabra. Con auditoría, abres el registro del contrato, ves el historial de cambios, y puedes decir exactamente: "El campo Precio fue modificado por [usuario] el [fecha] a las [hora], cambiando de $X a $Y". Fin del misterio.
Pero la auditoría no es solo para resolver disputas. Para muchas organizaciones, es un requisito legal. GDPR exige poder demostrar quién accedió a datos personales. SOX requiere traza de quién modificó información financiera. HIPAA tiene requisitos estrictos sobre acceso a datos médicos.
Cómo funciona la auditoría en Dataverse
El sistema de auditoría tiene tres niveles de configuración que deben estar activos para que funcione:
Nivel 1: Global
Primero tienes que habilitar la auditoría a nivel de todo el entorno. Esto se hace en Settings > Auditing (o Configuración > Auditoría). Si esta opción está desactivada, no importa qué más configures: no se auditará nada.
Nivel 2: Entidad
Luego, para cada tabla que quieras auditar, debes habilitar la auditoría específicamente. Esto se hace en las propiedades de la tabla. Puedes elegir qué tablas auditar y cuáles no.
No tiene sentido auditar absolutamente todo. Las tablas de sistema que cambian constantemente (logs, telemetría) generarían demasiados datos sin valor agregado. Céntrate en las tablas de negocio importantes: Account, Contact, Opportunity, y cualquier entidad personalizada que contenga datos críticos.
Nivel 3: Campo
Finalmente, dentro de cada tabla auditada, puedes especificar qué campos auditar. Por defecto, cuando habilitas auditoría en una tabla, se auditan todos los campos. Pero puedes excluir campos específicos que cambian frecuentemente sin importancia (como campos de timestamp o contadores internos).
Qué se audita
Una vez configurada, la auditoría registra automáticamente:
- Create: Cuándo se creó un registro, por quién, y los valores iniciales
- Update: Cuándo se modificó un registro, por quién, qué campos cambiaron, valores anteriores y nuevos
- Delete: Cuándo se eliminó un registro, por quién, y los valores en el momento de la eliminación
Opcionalmente, también puedes auditar Read: cada vez que alguien ve un registro. Pero cuidado con esto. En un sistema con cientos de usuarios viendo registros constantemente, auditar reads puede generar cantidades masivas de datos y afectar el rendimiento. Solo habilita read auditing cuando hay un requisito específico de compliance que lo exige, y hazlo selectivamente.
Accediendo a los logs de auditoría
Los logs de auditoría se acceden de varias formas:
Desde la interfaz: En un registro específico, puedes ver su historial de auditoría. También hay una vista global de auditoría en la configuración del sistema.
Vía API: Puedes consultar los datos de auditoría programáticamente usando Dataverse Web API o SDK. Esto es útil para construir reportes personalizados o integraciones con sistemas de SIEM (Security Information and Event Management).
Microsoft 365 Compliance Center: Los logs de Dataverse también aparecen en el Unified Audit Log de Microsoft 365, donde puedes correlacionarlos con logs de otros servicios (SharePoint, Exchange, Teams).
Retención de logs
Los logs de auditoría ocupan espacio. Y como la auditoría es continua, crecen indefinidamente si no haces algo al respecto.
Tienes varias opciones:
Definir una política de retención: Puedes configurar que los logs más antiguos de X días/meses se eliminen automáticamente. Esto mantiene el tamaño bajo control pero significa que pierdes el historial antiguo.
Archivar antes de eliminar: Un enfoque más sofisticado es exportar los logs antiguos a Azure Data Lake o a otro almacenamiento de archivo antes de eliminarlos de Dataverse. Así cumples con retención a largo plazo sin consumir capacidad de Dataverse.
Eliminar selectivamente: Puedes eliminar logs de ciertas tablas o periodos específicos manualmente. Por ejemplo, eliminar los logs de read auditing que tienen más de 30 días pero mantener los de delete por 7 años.
La duración de retención debe alinearse con tus requisitos legales. SOX puede requerir 7 años de historial. GDPR tiene sus propias reglas sobre retención de datos. Consulta con tu equipo legal.
Casos de uso de auditoría
Investigación de incidentes: "¿Quién eliminó este cliente?" Abres el log de auditoría, filtras por deletes, y ves exactamente quién, cuándo, y qué valores tenía el registro.
Cumplimiento de regulaciones: Un auditor pregunta "¿Pueden demostrar quién accedió a datos personales de pacientes en los últimos 6 meses?" Con read auditing habilitado, generas un reporte.
Resolución de disputas: "El cliente dice que su precio era X, pero ahora en el sistema es Y". El log muestra exactamente cuándo cambió y por quién.
Detección de anomalías: Si integras los logs con un SIEM, puedes detectar patrones inusuales. ¿Un usuario normalmente accede a 50 registros al día pero hoy accedió a 5000? Algo puede estar pasando.
Puntos clave
- La auditoría se configura a tres niveles: global, entidad y campo
- Registra Create, Update y Delete por defecto; Read es opcional y costoso
- Define políticas de retención según requisitos legales
- Exporta logs antes de eliminar para archivo a largo plazo
- Los logs se integran con Microsoft 365 Compliance Center