Auditoría en Microsoft Fabric: Control Total con el Unified Log y APIs

La auditoría en Microsoft Fabric no es una tarea opcional para entornos empresariales; es el pilar que sostiene la confianza en el gobierno del dato. Cuando un modelo de Power BI deja de funcionar o un Lakehouse ve alterada su estructura de carpetas, la primera pregunta del equipo de IT no es qué ha fallado, sino quién lo hizo y cuándo. En despliegues complejos, especialmente en sectores regulados como el financiero o el industrial, el rastreo de actividades es una exigencia de cumplimiento legal.

A diferencia de sistemas aislados, Microsoft Fabric centraliza gran parte de su telemetría en el Unified Audit Log (UAL) a través de Microsoft Purview. Sin embargo, depender exclusivamente de la interfaz de Purview es un error de principiante. Un consultor senior sabe que los logs deben ser persistentes, consultables y, sobre todo, integrados en el propio ecosistema de datos para realizar análisis históricos que superen los 90 días de retención estándar.

En este artículo desglosamos cómo pasar del rastreo manual a una arquitectura de auditoría robusta. Analizaremos el flujo de eventos, la configuración de APIs de administración y la consolidación de estos datos en un Lakehouse para crear un panel de control de seguridad real. Todo ello bajo la premisa de que, si no puedes auditarlo, no puedes garantizar su integridad.

El ecosistema de auditoría: Purview y el Unified Audit Log

Microsoft Purview actúa como el repositorio centralizado de eventos para toda la plataforma de Microsoft 365 y, por extensión, para Microsoft Fabric. Cada vez que un usuario crea un informe, edita una canalización de datos o modifica un esquema en un Warehouse, se genera una entrada en el registro de auditoría. Estos eventos no son solo informativos; contienen metadatos críticos como la IP de origen, el identificador del objeto (GUID) y el nivel de privilegio utilizado.

Para proyectos en los que la Gestión de Workspaces en Fabric se vuelve masiva, el registro de auditoría se convierte en la única fuente de verdad. El problema principal reside en que, por defecto, el acceso a estos logs requiere permisos de administrador global o de cumplimiento en el portal de Purview, lo cual crea un cuello de botella para el equipo de BI que solo necesita monitorizar la actividad de sus activos de datos.

¿Qué actividades rastrea Fabric exactamente?

El espectro es amplio. Desde operaciones de lectura (ver un informe) hasta operaciones destructivas (eliminar una capacidad). Es vital distinguir entre eventos de plano de control y eventos de plano de datos. El Unified Audit Log se centra principalmente en el plano de control: quién cambió qué configuración. Para el plano de datos, como las consultas SQL ejecutadas en un Warehouse, debemos recurrir a vistas de gestión dinámica (DMVs) dentro del motor de SQL, aunque Purview empieza a capturar eventos de alto nivel de acceso a datos.

Extracción automatizada: APIs de Administración de Fabric

La interfaz web de Purview es útil para una investigación forense puntual, pero ineficiente para el seguimiento diario. Para construir una solución escalable, debemos utilizar las Admin APIs. Estas APIs permiten extraer los eventos de actividad de forma programática. El endpoint clave es GetActivityEvents, que permite recuperar eventos en ventanas de tiempo específicas (normalmente en bloques de un día o incluso minutos para flujos casi en tiempo real).

Para utilizar estas APIs, es imperativo configurar un Service Principal con los permisos de lectura de tenant (Tenant.Read.All o Tenant.ReadWrite.All). Un error frecuente en implementaciones de seguridad es dar permisos excesivos. Siempre debemos aplicar el principio de mínimo privilegio.

// Ejemplo de función en Power Query (M) para llamar a la API de Actividad
let
 GetFabricActivity = (contToken as text, activityDate as text) =>
 let
 url = "https://api.powerbi.com/v1.0/myorg/admin/activityevents?startDateTime='" & activityDate & "T00:00:00.000Z'&endDateTime='" & activityDate & "T23:59:59.999Z'",
 header = [Authorization = "Bearer " & AccessToken],
 options = if contToken = null then [] else [Query = [continuationToken = contToken]],
 Source = Json.Document(Web.Contents(url, [Headers = header, Query = options])),
 // Gestión de la paginación mediante el token de continuación
 NextToken = Source[continuationToken],
 Data = Source[activityEventEntities]
 in
 Data
in
 GetFabricActivity

Este bloque de código muestra la estructura básica de una llamada para extraer eventos. Es fundamental manejar el continuationToken, ya que la API pagina los resultados cuando el volumen de actividad es alto. Ignorar este token resultará en informes de auditoría incompletos y una falsa sensación de seguridad.

Comparativa: Purview vs. Custom Audit Lakehouse

Muchos clientes preguntan si realmente merece la pena construir un sistema de auditoría propio en lugar de usar el portal de Purview. La respuesta depende de la retención y la capacidad de cruzar datos con otras fuentes. En un Lakehouse vs Data Warehouse en Microsoft Fabric, la elección del almacenamiento de logs suele inclinarse hacia el Lakehouse por su flexibilidad para tratar JSONs anidados procedentes de las APIs.

La construcción de un repositorio propio permite realizar análisis de linaje que Purview no muestra de forma agregada. Por ejemplo, podemos correlacionar un pico en el consumo de CUs identificado en la Fabric Capacity Metrics con un cambio de esquema específico registrado en nuestros logs de auditoría.

Arquitectura de una solución de cumplimiento en Fabric

Para implementar un sistema de cumplimiento robusto, recomiendo el patrón de «Auditoría como Código». Esto implica orquestar la extracción de logs mediante Notebooks de Spark que se ejecuten diariamente. Estos notebooks procesan los JSONs de la API de administración y los guardan en una tabla Delta optimizada.

El proceso sigue estos pasos:

1. Autenticación: El Notebook recupera un token de acceso mediante el Service Principal almacenado en un Azure Key Vault.
2. Extracción: Se itera sobre las fechas deseadas llamando al endpoint de actividad.
3. Transformación: Se aplanan los registros JSON. Campos como ItemName, UserId, ClientIP y Activity son obligatorios.
4. Carga: Se realiza un UPSERT en la tabla Delta para evitar duplicados en caso de reejecución.

# Fragmento de PySpark para aplanar logs de auditoría en Fabric
from pyspark.sql.functions import col, from_json

# Asumiendo que 'raw_df' contiene los eventos extraídos de la API
audit_schema = "Id string, CreationTime string, Operation string, OrganizationId string, UserType int, UserKey string, Workload string, UserId string, ClientIP string, UserAgent string, ItemName string, WorkspaceName string"

refined_df = raw_df.select(from_json(col("EventJson"), audit_schema).alias("data")).select("data.*")

# Escritura en capa Bronze/Silver del Lakehouse
refined_df.write.format("delta").mode("append").save("Tables/FabricAuditLogs")

Este enfoque permite aplicar políticas de seguridad granular. Por ejemplo, podemos usar RLS y CLS en Microsoft Fabric sobre esta tabla de auditoría para que los responsables de cada departamento solo vean la actividad generada en sus propios Workspaces, manteniendo la privacidad entre áreas de negocio.

Errores críticos que debes evitar

En mis años como consultor, he visto cómo fallan los sistemas de auditoría por detalles técnicos que pasan desapercibidos en la fase de diseño. Aquí los más comunes:

• Confiar en la retención por defecto: Muchas empresas se dan cuenta de que necesitan un log de hace 6 meses cuando ya ha sido borrado de Purview. Si tienes una auditoría externa, extrae los datos cada 24 horas.
• No filtrar por Workload: La API devuelve eventos de Power BI, pero también de otros servicios. Si solo te interesa Fabric, asegúrate de filtrar para no saturar tu Lakehouse con ruido innecesario.
• Ignorar los fallos de autenticación: Si el Service Principal caduca o cambia su secreto, dejas de recibir logs. Debes configurar alertas sobre la ejecución de tus pipelines de extracción.
• No auditar el propio sistema de auditoría: ¿Quién tiene permiso para borrar los logs de la tabla Delta? Protege tu Lakehouse de auditoría con permisos de solo lectura para la mayoría.

Escenario real: Auditoría en el Sector Retail

Imaginemos una empresa de retail con cientos de tiendas. Los gerentes de tienda acceden a informes de ventas sensibles. El departamento de seguridad detecta una posible fuga de datos. Gracias a un sistema de auditoría centralizado en Fabric, podemos filtrar por la operación ExportPowerBIData y ver exactamente qué usuario descargó qué informe y desde qué dirección IP.

Este nivel de trazabilidad es lo que diferencia una herramienta de visualización de una plataforma de datos empresarial. No se trata de vigilar a los empleados, sino de tener la evidencia técnica ante incidentes de seguridad o errores accidentales que afecten a la calidad del dato.

Checklist de implementación de auditoría

• ¿Está habilitada la auditoría a nivel de Tenant en el portal de administración de Fabric?
• ¿Tienes un Service Principal con permisos de solo lectura para las Admin APIs?
• ¿Has definido una política de retención en tu Lakehouse de auditoría superior a los 90 días?
• ¿Estás cruzando los logs de actividad con los de consumo de capacidad para detectar ineficiencias?
• ¿Has validado que los nombres de los objetos (Workspaces, Reportes) se registran correctamente tras un renombramiento?

Preguntas frecuentes

¿Cuánto tiempo tardan los eventos en aparecer en el Unified Audit Log?

La latencia suele ser de entre 30 y 90 minutos desde que ocurre la acción hasta que es consultable vía API o en el portal de Purview. No esperes una auditoría en tiempo real absoluto; para eso existen otras herramientas de monitorización de red.

¿Necesito una licencia de Power BI Premium o Fabric Capacity para extraer logs?

Para usar las APIs de administración de forma automatizada, necesitas que el contenido esté en una capacidad (Fabric o Premium). Además, el acceso a las APIs requiere que el administrador del Tenant haya habilitado el acceso a las APIs de administración para Service Principals.

¿Es posible auditar qué filas específicas ha visto un usuario (Data-level auditing)?

No a través del Unified Audit Log de forma directa. El UAL te dirá que el usuario accedió al informe o ejecutó una consulta SQL. Para saber exactamente qué filas se filtraron, tendrías que implementar un log personalizado dentro de tus procedimientos almacenados o usar herramientas de telemetría más avanzadas como Azure Monitor Application Insights en informes embebidos.

¿Qué diferencia hay entre el Log de Actividad y el Log de Auditoría?

En el contexto de Fabric, a menudo se usan como sinónimos. Sin embargo, técnicamente el Log de Actividad se refiere a la secuencia de eventos operativos, mientras que el de Auditoría incluye componentes legales y de cumplimiento (quién concedió permisos, quién cambió la configuración del tenant).

»