Planeamiento de la implementación de Power BI: auditoría de nivel de inquilino

Este artículo sobre el planeamiento de la auditoría de nivel de inquilino está dirigido principalmente a:

• Administradores de Power BI: los administradores responsables de supervisar Power BI en la organización. Es posible que los administradores de Power BI tengan que colaborar con los departamentos de TI, seguridad, auditoría interna y otros equipos pertinentes.
• Centro de excelencia, equipo de TI y BI: los equipos que también son responsables de supervisar Power BI. Puede que tengan que colaborar con los administradores de Power BI y otros equipos pertinentes.

El propósito de una solución de auditoría de nivel de inquilino es capturar y analizar datos de todos los usuarios, actividades y soluciones implementados en un inquilino de Power BI. Estos datos de auditoría de nivel de inquilino son valiosos para muchos fines, lo que le permite analizar los esfuerzos de adopción, comprender los patrones de uso, educar a los usuarios, ayudar a los usuarios, mitigar el riesgo, mejorar el cumplimiento, administrar los costos de licencia y supervisar el rendimiento.

La creación de una solución de auditoría completa que sea segura y esté lista para producción es un proyecto importante que lleva su tiempo. Lo puede considerar como la creación de inteligencia empresarial sobre inteligencia empresarial (BI en BI). Para información sobre por qué los datos de auditoría son tan valiosos, consulte Auditoría y supervisión.

Para información sobre la auditoría de nivel de informe, que está destinada a los creadores de informes, consulte Auditoría de nivel de informe.

Para auditar los recursos de datos, que están destinados a los creadores de datos, consulte Auditoría de nivel de datos.

El resto de este artículo se centra en la auditoría de nivel de inquilino.

Cuando planee crear una solución de auditoría de nivel de inquilino, debe dedicar tiempo a las cuatro fases siguientes.

• Fase 1: Planeamiento y decisiones
  • Requisitos y prioridades
  • Necesidades de datos
  • Tipo de solución de auditoría
  • Permisos y responsabilidades
  • Decisiones técnicas
  • Decisiones sobre orígenes de datos
• Fase 2: Requisitos previos y configuración
  • Crear cuenta de almacenamiento
  • Instalar el software y configurar los servicios
  • Registrar una aplicación de Microsoft Entra
  • Configurar un inquilino de Power BI
• Fase 3: Desarrollo y análisis de soluciones
  • Extraer y almacenar los datos sin procesar
  • Crear los datos mantenidos
  • Crear un modelo de datos
  • Mejorar el modelo de datos
  • Crear informes analíticos
  • Tomar medidas en función de los datos
• Fase 4: Mantenimiento, mejora y supervisión
  • Operacionalización y mejora
  • Documentación y soporte técnico
  • Habilitación de alertas
  • Administración continua

Fase 1: Planeamiento y decisiones

La primera fase se centra en el planeamiento y la toma de decisiones. Hay muchos requisitos y prioridades que se deben tener en cuenta, por lo que se recomienda dedicar tiempo suficiente a comprender los temas introducidos en esta sección. El objetivo es tomar buenas decisiones iniciales para que las fases posteriores se desarrollen sin problemas.

Requisitos y prioridades

En la fase inicial, el objetivo es identificar lo que es más importante. Céntrese en lo que más importa y en cómo medirá el impacto en su organización. Esfuércese por definir los requisitos orientados al negocio en lugar de los requisitos orientados a la tecnología.

Estas son algunas preguntas a las que debe responder.

• ¿A qué preguntas clave debe responder? Hay un gran volumen de datos de auditoría que puede explorar. La manera más eficaz de abordar la auditoría es centrarse en responder a preguntas concretas.
• ¿Cuáles son los objetivos de adopción y cultura de datos? Por ejemplo, quizás tenga un objetivo para aumentar el número de creadores de contenido de BI de autoservicio en la organización. En ese caso, deberá medir las actividades de usuario relacionadas con la creación, la edición y la publicación de contenido.
• ¿Qué riesgos inmediatos están presentes? Por ejemplo, puede que sepa que en el pasado se ha compartido contenido en exceso. El entrenamiento de usuarios se ha mejorado desde entonces y ahora quiere auditar la configuración de seguridad y las actividades de forma continua.
• ¿Existen indicadores clave de rendimiento (KPI) u objetivos organizativos? Por ejemplo, quizás tenga un KPI organizativo relacionado con la transformación digital o con convertirse en una organización más orientada a datos. Los datos de auditoría de nivel de inquilino pueden ayudarle a medir si la implementación de Power BI está alineada con estos objetivos.

Para encontrar más ideas sobre las formas en que puede usar los datos de auditoría, consulte Auditoría y supervisión.

Lista de comprobación: al identificar requisitos y prioridades, algunas de las decisiones y acciones más importantes son:

Necesidades de datos

Cuando haya definido los requisitos y las prioridades (descritas anteriormente), estará listo para identificar los datos que necesitará. En esta sección se tratan cuatro categorías de datos.

• Datos de actividad del usuario
• Inventario de inquilino
• Datos de usuarios y grupos
• Datos de seguridad

La mayoría de los datos que necesitará procede de las API de administración, que proporcionan una gran cantidad de metadatos sobre el inquilino de Power BI. Para más información, consulte Elección de una API de usuario o una API de administrador más adelante en este artículo.

Datos de actividad del usuario

Convierta en su prioridad número uno la obtención de datos sobre las actividades del usuario. Las actividades del usuario, que también se denominan eventos u operaciones, son útiles para una amplia variedad de propósitos.

Normalmente, estos datos se conocen como registro de actividad o registro de eventos. Técnicamente, hay varias maneras de adquirir datos de actividad del usuario (el registro de actividad es una de ellas). Para más información sobre las decisiones y las actividades implicadas, consulte Acceso a los datos de actividad del usuario más adelante en este artículo.

Estas son algunas preguntas comunes a las que pueden responder los datos de actividad del usuario.

• Encontrar los mejores usuarios y el mejor contenido
  • ¿Qué contenido se ve con más frecuencia y quiénes lo ven?
  • ¿Cuáles son las tendencias diarias, semanales y mensuales para ver contenido?
  • ¿Las vistas de informe tienen tendencia al alza o a la baja?
  • ¿Cuántos usuarios activos hay?
• Descripción del comportamiento del usuario
  • ¿Qué tipo de seguridad se usa con más frecuencia (aplicaciones, áreas de trabajo o uso compartido por elemento)?
  • ¿Los usuarios usan más los exploradores o las aplicaciones móviles?
  • ¿Qué creadores de contenido publican y actualizan contenido de forma más activa?
  • ¿Qué contenido se publica o actualiza, cuándo y quiénes lo hacen?
• Identificar las oportunidades de aprendizaje y educación de los usuarios
  • ¿Quién comparte (demasiado) desde su área de trabajo personal?
  • ¿Quién realiza un volumen significativo de exportaciones?
  • ¿Quién descarga contenido periódicamente?
  • ¿Quién está publicando muchos modelos semánticos nuevos?
  • ¿Quién usa más suscripciones?
• Mejorar los esfuerzos de gobernanza y cumplimiento
  • ¿Cuándo se cambia la configuración de los inquilinos y qué administrador de Power BI lo hace?
  • ¿Quién ha iniciado una prueba de Power BI?
  • ¿A qué contenido acceden los usuarios externos, quién, cuándo y cómo?
  • ¿Quién ha agregado o actualizado una etiqueta de confidencialidad?
  • ¿Qué porcentaje de vistas de informe se basa en modelos semánticos certificados?
  • ¿Qué porcentaje de modelos semánticos admite más de un informe?
  • ¿Cuándo se crea o actualiza una puerta de enlace o un origen de datos y qué usuario lo hace?

Para más información sobre las formas de usar estos datos, consulte Descripción de los patrones de uso.

Para más información, consulte Acceso a los datos de actividad del usuario.

Inventario de inquilino

A menudo, la segunda prioridad es recuperar los datos para crear un inventario de inquilino. A veces se conoce como inventario del área de trabajo, metadatos del área de trabajo o metadatos del inquilino.

Un inventario de inquilino es una instantánea en un momento dado. Describe lo que se publica en el inquilino. El inventario de inquilino no incluye los datos ni los informes reales, sino que son metadatos que describen todas las áreas de trabajo y sus elementos (como modelos semánticos e informes).

Estas son algunas preguntas comunes a las que puede responder el inventario de inquilino.

• Comprender cuánto contenido tiene y dónde
  • ¿Qué áreas de trabajo tienen más contenido?
  • ¿Qué tipo de contenido se publica en cada área de trabajo (especialmente cuando separa áreas de trabajo de informes y áreas de trabajo de datos)?
  • ¿Qué dependencias existen entre elementos (como flujos de datos que admiten muchos modelos semánticos o un modelo semántico que es un origen para otros modelos compuestos)?
  • ¿Qué es el linaje de datos (dependencias entre elementos de Power BI, incluidos los orígenes de datos externos)?
  • ¿Hay informes huérfanos (que están desconectados de su modelo semántico)?
• Comprensión de la relación entre los modelos semánticos y los informes
  • ¿En qué medida se reutilizan los modelos semánticos?
  • ¿Hay modelos semánticos duplicados o muy similares?
  • ¿Hay oportunidades para consolidar los modelos semánticos?
• Comprender las tendencias entre puntos temporales
  • ¿El número de informes aumenta con el tiempo?
  • ¿El número de modelos semánticos aumenta con el tiempo?
• Encontrar contenido sin usar
  • ¿Qué informes no se usan (o se usan poco)?
  • ¿Qué modelos semánticos no se usan (o se usan poco)?
  • ¿Hay oportunidades para retirar contenido?

Un inventario de inquilino le ayuda a usar nombres actuales al analizar actividades históricas. La instantánea de los elementos del inquilino contiene los nombres de todos los elementos en ese momento. Resulta útil usar los nombres de elementos actuales para los informes históricos. Por ejemplo, si se cambió el nombre de un informe hace tres meses, el registro de actividad en ese momento registra el nombre del informe anterior. Con un modelo de datos definido correctamente, puede usar el inventario de inquilino más reciente para buscar un elemento por su nombre actual (en lugar de su nombre anterior). Para más información, consulte Creación de un modelo de datos más adelante en este artículo.

Para más información sobre las formas de usar un inventario de inquilino, consulte Descripción del contenido publicado.

Dado que un inventario de inquilino es una instantánea en un momento dado, deberá decidir con qué frecuencia extraer y almacenar los metadatos. Una instantánea semanal es útil para realizar comparaciones entre los dos puntos temporales. Por ejemplo, si quiere investigar la configuración de seguridad de un área de trabajo, necesitará la instantánea del inventario de inquilino anterior, los eventos del registro de actividad y la instantánea del inventario de inquilino actual.

Hay dos formas principales de crear un inventario de inquilino. Para más información sobre las decisiones y las actividades implicadas, consulte Acceso a los datos de inventario de inquilino más adelante en este artículo.

Datos de usuarios y grupos

A medida que aumentan las necesidades de análisis, es probable que quiera incluir datos sobre usuarios y grupos en la solución de auditoría completa. Para recuperar esos datos, puede usar Microsoft Graph, que es el origen autoritativo para obtener información sobre los usuarios y grupos de Microsoft Entra ID.

Los datos recuperados de las API REST de Power BI incluyen una dirección de correo electrónico para describir al usuario o el nombre de un grupo de seguridad. Estos datos son una instantánea en un momento dado.

Estas son algunas preguntas comunes a las que puede responder Microsoft Graph.

• Identificar usuarios y grupos
  • ¿Cuál es el nombre de usuario completo (además de la dirección de correo electrónico), el departamento o la ubicación procedentes de su perfil de usuario?
  • ¿Quiénes son los miembros de un grupo de seguridad?
  • ¿Quién es el propietario de un grupo de seguridad (para administrar miembros)?
• Obtener información adicional del usuario
  • ¿Qué licencias (Power BI Pro o Power BI Premium por usuario [PPU]), se asignan a los usuarios?
  • ¿Qué usuarios inician sesión con más frecuencia?
  • ¿Qué usuarios no han iniciado sesión en el servicio Power BI recientemente?

Para más información y recomendaciones sobre cómo acceder a los datos de Microsoft Graph, consulte Acceso a los datos de usuarios y grupos más adelante en este artículo.

Datos de seguridad

Es posible que tenga un requisito para realizar auditorías de seguridad periódicas.

Estas son algunas preguntas comunes a las que pueden responder las API REST de Power BI.

• Identificar personas y aplicaciones
  • ¿A qué informes tiene acceso un usuario, un grupo o una entidad de servicio?
  • ¿Qué usuarios, grupos o entidades de servicio están suscritos para recibir informes con una suscripción de correo electrónico?
• Comprender los permisos de contenido
  • ¿Qué roles de área de trabajo se asignan a qué usuarios y grupos?
  • ¿Qué usuarios y grupos se asignan a cada público de aplicaciones de Power BI?
  • ¿Qué permisos por elemento se asignan, para qué informes y para qué usuarios?
  • ¿Qué permisos por elemento se asignan, para qué modelos semánticos y para qué usuarios?
  • ¿Qué modelos semánticos y datamarts tienen definida la seguridad de nivel de fila (RLS)?
  • ¿Qué elementos se comparten con personas en toda la organización?
  • ¿Qué elementos se exponen públicamente en Internet?
• Descripción de otros permisos
  • ¿Quién tiene permiso para publicar mediante una canalización de implementación?
  • ¿Quién tiene permiso para administrar puertas de enlace y conexiones de datos?
  • ¿Quién tiene permiso para administrar una capacidad Prémium?

Estas preguntas comunes no son una lista exhaustiva; hay una amplia variedad de API REST de Power BI disponibles. Para más información, consulte Uso de las API REST de Power BI.

Para obtener más información sobre el uso de las API de administrador frente a las API de usuario (incluido cómo afecta a los permisos necesarios para el usuario que extrae los datos), consulte Elección de una API de usuario o una API de administrador más adelante en este artículo.

Lista de comprobación: al identificar los datos necesarios para la auditoría, las decisiones y acciones clave incluyen:

Tipo de solución de auditoría

La auditoría de nivel de inquilino se realiza manualmente o con procesos automatizados.

La mayoría de los nuevos procesos de auditoría comienzan como un proceso manual, especialmente durante el desarrollo y mientras se realizan pruebas. Un proceso de auditoría manual puede evolucionar para convertirse en un proceso automatizado. Sin embargo, no todos los procesos de auditoría deben automatizarse completamente.

Procesos de auditoría manual

La auditoría manual se basa en scripts y procesos que un usuario ejecuta a petición (normalmente un administrador de Power BI). Cuando es necesario, el usuario ejecuta consultas de forma interactiva para recuperar datos de auditoría.

La auditoría manual es más adecuada para:

• Nuevos scripts que se están desarrollando y probando.
• Necesidades de auditoría ocasional o excepcional.
• Necesidades de auditoría exploratorias.
• Procesos de auditoría no esenciales que no requieren compatibilidad completa.

Procesos de auditoría automatizados

Los datos de auditoría necesarios de forma periódica deben automatizarse. Se extraen y procesan según una programación frecuente y se conoce como un proceso automatizado. A veces se conoce como un proceso desatendido.

Los objetivos de un proceso automatizado son reducir el esfuerzo manual, reducir el riesgo de error, aumentar la coherencia y eliminar la dependencia de un usuario individual para ejecutarlo.

La auditoría manual es más adecuada para:

• Procesos de auditoría que se ejecutan en producción.
• Procesos desatendidos que se ejecutan según una programación frecuente.
• Scripts que se han probado por completo.
• Procesos de auditoría esenciales que tienen otros informes (u otros procesos) que dependen de ella como origen de datos.
• Procesos de auditoría que se documentan y admiten.

El tipo de proceso (manual o automatizado) podría afectar a la forma de controlar la autenticación. Por ejemplo, un administrador de Power BI podría usar la autenticación de usuario para un proceso de auditoría manual, pero usar una entidad de servicio para un proceso automatizado. Para obtener más información, consulte Determinación del método de autenticación más adelante en este artículo.

Lista de comprobación: al considerar el tipo de solución de auditoría para desarrollar, las decisiones y acciones clave incluyen:

Permisos y responsabilidades

En este momento, debe tener una idea clara de lo que desea lograr y los datos que necesitará inicialmente. Ahora es un buen momento para tomar decisiones sobre los permisos de usuario, así como los roles y las responsabilidades.

Permisos de usuario

Cuando pretenda crear una solución de auditoría de un extremo a otro, considere los permisos de usuario para otros usuarios que deberán acceder a los datos. En concreto, decida quién podrá acceder a los datos de auditoría y verlos.

Algunas consideraciones que se deben tener en cuenta son las siguientes.

Acceso directo a los datos de auditoría

Debe decidir quién puede acceder directamente a los datos de auditoría. Hay varias formas de pensar sobre ello.

• ¿Quién debe ser un administrador de Power BI? Un administrador de Power BI tiene acceso a todos los metadatos de inquilino, incluidas las API de administración. Para obtener más información sobre cómo decidir quién debe ser un administrador de Power BI, consulte Plan de seguridad en el nivel de inquilino.
• ¿Quién puede usar una entidad de servicio existente? Para usar una entidad de servicio (en lugar de permisos de usuario) para acceder a los datos de auditoría, se debe proporcionar un secreto a los usuarios autorizados para que puedan realizar la autenticación basada en contraseña. El acceso a secretos (y claves) debe estar muy controlado.
• ¿Es necesario controlar estrechamente el acceso? Determinados sectores con requisitos normativos y de cumplimiento deben controlar el acceso más estrechamente que otros.
• ¿Hay grandes volúmenes de datos de actividad? Para evitar alcanzar los valores de limitación de API, es posible que tenga que controlar estrechamente quién puede acceder directamente a las API que generan datos de auditoría. En este caso, resulta útil asegurarse de que no haya esfuerzos duplicados o superpuestos.

Acceso a datos sin procesar extraídos

Debe decidir quién puede ver los datos sin procesar extraídos y escritos en una ubicación de almacenamiento. Normalmente, el acceso a los datos sin procesar está restringido a los administradores y auditores. El Centro de excelencia (COE) también puede requerir acceso. Para obtener más información, consulte Determinación de dónde almacenar los datos de auditoría más adelante en este artículo.

Acceso a datos analíticos mantenidos

Debe decidir quién puede ver los datos mantenidos y transformados que están listos para el análisis. Estos datos siempre deben estar disponibles para los administradores y auditores. A veces, un modelo de datos está disponible para otros usuarios de la organización, especialmente cuando se crea un modelo semántico de Power BI con seguridad de nivel de fila. Para obtener más información, consulte Planeamiento de la creación de datos mantenidos más adelante en este artículo.

Roles y responsabilidades

Una vez que haya decidido cómo funcionan los permisos de usuario, es el momento de empezar a pensar en roles y responsabilidades. Se recomienda que implique a las personas adecuadas al principio, especialmente cuando varios desarrolladores o equipos participen en la creación de la solución de auditoría de un extremo a otro.

Decida qué usuarios o equipos serán responsables de las siguientes actividades.

Rol	Tipos de responsabilidades	Quién realiza normalmente el rol
Comunicarse con las partes interesadas	Actividades de comunicación y recopilación de requisitos.	COE en asociación con TI. También puede incluir personas selectas de unidades de negocio clave.
Decidir prioridades y proporcionar orientación sobre los requisitos	Actividades de toma de decisiones relacionadas con la solución de auditoría de un extremo a otro, incluida la forma de cumplir los requisitos.	Equipo que supervisa Power BI en la organización, como el COE. El patrocinador ejecutivo o un comité directivo de gobernanza de datos podrían participar para tomar decisiones críticas o escalar incidencias.
Extraer y almacenar los datos sin procesar	Creación de scripts y procesos para acceder a los datos y extraerlos. También implica escribir los datos sin procesar en el almacenamiento.	Personal de ingeniería de datos, normalmente en TI y en colaboración con el COE.
Crear los datos mantenidos	Limpieza y transformación de datos y la creación de datos mantenidos en el diseño de esquema de estrella.	Personal de ingeniería de datos, normalmente en TI y en colaboración con el COE.
Crear un modelo de datos	Creación de un modelo de datos analíticos, basado en los datos mantenidos.	Creadores de contenido de Power BI, normalmente en TI o el COE.
Crear informes de análisis	Creación de informes para analizar los datos mantenidos. Cambios continuos en los informes basados en nuevos requisitos y cuando los nuevos datos de auditoría están disponibles.	Creadores de informes de Power BI, normalmente en TI o el COE.
Analizar los datos y actuar sobre los resultados	Analice los datos y actúe en respuesta a los datos de auditoría.	Equipo que supervisa Power BI en la organización, normalmente el COE. También puede incluir otros equipos en función de los resultados de la auditoría y de la acción. Otros equipos pueden incluir seguridad, cumplimiento, legal, administración de riesgos o administración de cambios.
Prueba y validación	Pruebe para asegurarse de que se cumplen los requisitos de auditoría y de que los datos presentados son precisos.	Creadores de contenido de Power BI, en asociación con el equipo que supervisa Power BI en la organización.
Proteger los datos	Establezca y administre la seguridad de cada capa de almacenamiento, incluidos los datos sin procesar y los datos mantenidos. Administre el acceso a los modelos semánticos que se crean para analizar los datos.	Administrador del sistema para el sistema que almacena los datos, en asociación con el equipo que supervisa Power BI en la organización.
Programación y automatización	Operacionalice una solución y programe el proceso con la herramienta que prefiera.	Personal de ingeniería de datos, normalmente en TI y en colaboración con el COE.
Soporte técnico de la solución	Supervise la solución de auditoría, incluidas las ejecuciones de trabajos, los errores y la compatibilidad con incidencias técnicas.	Equipo que controla el soporte técnico del sistema de Power BI, que suele ser TI o el COE.

Muchos de los roles y las responsabilidades anteriores se pueden consolidar si los van a realizar el mismo equipo o la misma persona. Por ejemplo, los administradores de Power BI pueden realizar algunos de estos roles.

También es posible que diferentes personas realicen diferentes roles, dependiendo de la circunstancia. Las acciones serán contextuales en función de los datos de auditoría y de la acción propuesta.

Considere varios ejemplos.

• Ejemplo 1: los datos de auditoría muestran que algunos usuarios suelen exportar datos a Excel. Acción realizada: el COE se pone en contacto con los usuarios específicos para comprender sus necesidades y enseñarles mejores alternativas.
• Ejemplo 2: Los datos de auditoría muestran que el acceso de usuario externo se produce de forma inesperada. Acciones realizadas: un administrador del sistema de TI actualiza la configuración pertinente de Microsoft Entra ID para el acceso de usuario externo. El administrador de Power BI actualiza la configuración de inquilino relacionada con el acceso de usuario externo. El COE actualiza la documentación y el entrenamiento para los creadores de contenido que administran la seguridad. Para obtener más información, consulte Estrategia para usuarios externos.
• Ejemplo 3: los datos de auditoría muestran que varios modelos de datos definen la misma medida de forma diferente (disponible en las API de análisis de metadatos, si la configuración detallada del inquilino de metadatos lo permite). Acción realizada: el comité de gobernanza de datos inicia un proyecto para definir definiciones comunes. El COE actualiza la documentación y el entrenamiento para los creadores de contenido que crean modelos de datos. El COE también trabaja con creadores de contenido para actualizar sus modelos, según corresponda. Para obtener más información sobre cómo recuperar metadatos detallados, consulte Acceso a los datos de inventario de inquilino más adelante en este artículo.

Lista de comprobación: al considerar los permisos y las responsabilidades, las decisiones y acciones clave incluyen:

Decisiones técnicas

Al planear una solución de auditoría de nivel de inquilino, deberá tomar algunas decisiones técnicas importantes. Para mejorar la coherencia, evitar rehacer el trabajo y mejorar la seguridad, se recomienda tomar estas decisiones lo antes posible.

La primera fase de planeamiento implica tomar las siguientes decisiones.

• Selección de una tecnología para acceder a los datos de auditoría
• Determinación del método de autenticación
• Elección de una API de usuario o una API de administrador
• Elección de API o cmdlets de PowerShell
• Determinación de dónde almacenar los datos de auditoría
• Planeamiento de la creación de datos mantenidos

Selección de una tecnología para acceder a los datos de auditoría

Lo primero que debe decidir es cómo acceder a los datos de auditoría.

La manera más fácil de empezar es usar los informes pregenerados disponibles en el área de trabajo de supervisión del administrador.

Cuando necesite acceder directamente a los datos y compilar su propia solución, usará una API (interfaz de programa de aplicación). Las API están diseñadas para intercambiar datos a través de Internet. Las API REST de Power BI admiten solicitudes para datos mediante el protocolo HTTP. Cualquier lenguaje o herramienta puede invocar API REST de Power BI cuando es capaz de enviar una solicitud HTTP y recibir una respuesta JSON.

Esta sección se centra en su elección tecnológica. Para conocer las consideraciones sobre el origen para acceder a tipos específicos de datos de auditoría, consulte Decisiones sobre orígenes de datos más adelante en este artículo.

Opciones de plataforma

Hay muchas maneras diferentes de acceder a los datos de auditoría. Dependiendo de la tecnología que elija, puede inclinarse hacia un idioma preferido. También puede que tenga que tomar una decisión específica sobre cómo programar la ejecución de los scripts. Las tecnologías difieren ampliamente en su curva de aprendizaje y facilidad de introducción.

Estas son algunas tecnologías que puede usar para recuperar datos mediante las API REST de Power BI.

Technology	Buena opción para procesos de auditoría manuales	Buena opción para procesos de auditoría automatizados
Área de trabajo de supervisión del administrador
Try-it
PowerShell
Power BI Desktop
Power Automate
Servicio de Azure preferido
Herramienta o lenguaje preferidos
Búsqueda de registros de auditoría de Microsoft Purview
Defender para aplicaciones en la nube
Microsoft Sentinel

En el resto de esta sección se proporciona una breve introducción a cada una de las opciones presentadas en la tabla.

Área de trabajo de supervisión del administrador

El área de trabajo de supervisión del administrador contiene informes y modelos semánticos predefinidos en el servicio Power BI. Es una manera cómoda para que los administradores de Fabric vean los datos de auditoría recientes y les ayuden a comprender las actividades de los usuarios.

Try-it en la documentación de API

Try-it es una herramienta interactiva que lo permite experimentar la API REST de Power BI directamente en la documentación de Microsoft. Es una manera sencilla de explorar las API porque no requiere otras herramientas ni ninguna configuración en el equipo.

Puede usar Try-it para:

• Envíe manualmente una solicitud a una API para determinar si devuelve la información que desea.
• Obtenga información sobre cómo se construye la dirección URL antes de escribir un script.
• Comprobar los datos de manera informal.

Dado que es interactiva, la herramienta Try-it es más adecuada para procesos de aprendizaje, exploración y nuevos procesos de auditoría manuales.

PowerShell y Azure Cloud Shell

Puede crear y ejecutar scripts de PowerShell de varias maneras.

Estas son varias opciones comunes.

• Visual Studio Code: un editor de código fuente moderno y ligero. Es una herramienta de código abierto disponible gratuitamente que se admite en varias plataformas, como Windows, macOS y Linux. Puede usar Visual Studio Code con muchos lenguajes, incluido PowerShell (mediante el uso de la extensión de PowerShell).
• Azure Data Studio: una herramienta para crear scripts y cuadernos. Se basa en Visual Studio Code. Azure Data Studio está disponible de forma independiente o con SQL Server Management Studio (SSMS). Hay muchas extensiones, incluida una extensión para PowerShell.
• Azure Cloud Shell: una alternativa a trabajar con PowerShell localmente. Puede acceder a Azure Cloud Shell desde un explorador.
• Azure Functions: una alternativa a trabajar con PowerShell localmente. Azure Functions es un servicio de Azure que permite escribir y ejecutar código en un entorno sin servidor. PowerShell es uno de diversos lenguajes que admite.

Puede usar PowerShell de varias maneras diferentes. Para obtener más información sobre esta decisión técnica, consulte Elección de API o cmdlets de PowerShell más adelante en este artículo.

Hay muchos recursos en línea disponibles para usar PowerShell y, a menudo, es posible encontrar desarrolladores experimentados que pueden crear y administrar soluciones de PowerShell. PowerShell es una buena opción para crear procesos de auditoría manuales y automatizados.

Power BI Desktop

Dado que Power BI Desktop puede conectarse a las API, es posible que tenga la tentación de usarla para compilar la solución de auditoría. Sin embargo, hay algunas desventajas y complejidades significativas.

• Acumulación del historial: dado que el registro de actividad de Power BI proporciona hasta 30 días de datos, la creación de toda la solución de auditoría implica acumular un conjunto de archivos a lo largo del tiempo que almacenan todos los eventos históricos. La acumulación de archivos históricos es más fácil de lograr con otras herramientas.
• Control de credenciales y claves de forma segura: muchas soluciones que encuentra en línea de blogueros de la comunidad no son seguras porque codifican de forma rígida credenciales y claves en texto sin formato dentro de consultas de Power Query. Aunque ese enfoque es sencillo, no se recomienda porque cualquier persona que obtenga su archivo Power BI Desktop puede leer los valores. No se puede almacenar la contraseña (al usar la autenticación de usuario) ni el secreto (cuando se usa una entidad de servicio) de forma segura en Power BI Desktop a menos que:
  • Use un conector personalizado que se desarrolló con el SDK de Power Query. Por ejemplo, un conector personalizado podría leer valores confidenciales de Azure Key Vault u otro servicio que almacene de forma segura el valor cifrado. También hay varias opciones de conector personalizadas disponibles en la comunidad global de Power BI.
  • Use la opción ApiKeyName, que funciona bien en Power BI Desktop. Sin embargo, no es posible almacenar el valor de clave en el servicio Power BI.
• Tipos de solicitudes: es posible que tenga algunas limitaciones para lo que puede ejecutar en Power BI Desktop. Por ejemplo, Power Query no admite todos los tipos de solicitud de API. Por ejemplo, solo se admiten solicitudes GET y POST cuando se usa la función Web.Contents. Para la auditoría, normalmente se envían solicitudes GET.
• Capacidad de actualizar: debe seguir patrones de desarrollo de Power Query específicos para actualizar correctamente un modelo semántico en el servicio Power BI. Por ejemplo, la opción RelativePath debe estar presente al usar Web.Contents para que Power BI pueda comprobar correctamente la ubicación de un origen de datos sin generar un error en el servicio Power BI.

En la mayoría de los casos, se recomienda usar Power BI Desktop solo para dos finalidades. Debe usarlo para:

• Crear el modelo de datos en función de los datos mantenidos existentes (en lugar de usarlo para extraer inicialmente los datos de auditoría).
• Crear informes analíticos basados en el modelo de datos.

Power Automate

Puede usar Power Automate con Power BI de muchas maneras. En relación con la auditoría, puede usar Power Automate para enviar solicitudes a las API REST de Power BI y, a continuación, almacenar los datos extraídos en la ubicación que prefiera.

Para obtener otras ideas sobre cómo usar Power Automate, busque Power BI en las plantillas de Power Automate.

Servicio de Azure preferido

Hay varios servicios de Azure que pueden enviar solicitudes a las API REST de Power BI. Puede usar el servicio de Azure que prefiera, como:

• Funciones de Azure
• Azure Automation
• Azure Data Factory
• Azure Synapse Analytics

En la mayoría de los casos, puede combinar un servicio de proceso que controle la lógica de la extracción de datos con un servicio de almacenamiento que almacene los datos sin procesar (y los datos mantenidos, cuando corresponda). Las consideraciones para tomar decisiones de arquitectura técnicas se describen más adelante en este artículo.

Herramienta o lenguaje preferidos

Puede usar la herramienta y el lenguaje que prefiera para enviar solicitudes a las API REST de Power BI. Es un buen enfoque cuando el equipo tiene experiencia con una herramienta o lenguaje específicos, como:

• Python
• C# en .NET Framework. Opcionalmente, puede usar el SDK de .NET de Power BI, que actúa como contenedor sobre las API REST de Power BI para simplificar algunos procesos y aumentar la productividad.
• JavaScript

Búsqueda de auditoría de Microsoft Purview

El portal de cumplimiento de Microsoft Purview (anteriormente llamado centro de cumplimiento de Microsoft 365) incluye una interfaz de usuario que le permite ver y buscar los registros de auditoría. Los registros de auditoría unificados incluyen Power BI y todos los demás servicios que admiten los registros de auditoría unificados de Microsoft 365.

Los datos capturados en el registro de auditoría unificado son exactamente los mismos datos contenidos en el registro de actividad de Power BI. Al realizar una búsqueda de registros de auditoría en el portal de cumplimiento Microsoft Purview, se agrega la solicitud a la cola. Los datos podrían tardar unos minutos (o más, dependiendo del volumen de datos) para que los datos estén listos.

Estas son algunas formas comunes de usar la herramienta de búsqueda de registros de auditoría. Puede:

• Seleccionar la carga de trabajo de Power BI para ver los eventos de una serie de fechas.
• Buscar una o varias actividades específicas, como:
  • Informe de Power BI eliminado
  • Acceso de administrador agregado a un área de trabajo personal en Power BI
• Ver las actividades de uno o varios usuarios.

Para los administradores con permisos suficientes, la herramienta de búsqueda de registros de auditoría del portal de cumplimiento de Microsoft Purview es una buena opción para los procesos de auditoría manual. Para obtener más información, consulte Portal de cumplimiento de Microsoft Purview más adelante en este artículo.

Interfaz de usuario de Defender for Cloud Apps

Defender for Cloud Apps está disponible para los administradores en Microsoft Defender XDR (portal de Microsoft 365). Incluye una interfaz de usuario para ver y buscar registros de actividad para varios servicios en la nube, incluido Power BI. Muestra los mismos eventos de registro que se originan en el portal de cumplimiento de Microsoft Purview, además de otros eventos como la actividad de inicio de sesión del usuario de Microsoft Entra ID.

La interfaz de registro de auditoría de Defender for Cloud Apps es una buena opción para los procesos de auditoría manual. Para más información, consulte Defender for Cloud Apps más adelante en este artículo.

Microsoft Sentinel y KQL

Microsoft Sentinel es un servicio de Azure que permite recopilar, detectar, e investigar incidentes y amenazas de seguridad y responder a ellos. Power BI se puede configurar en Microsoft Sentinel como un conector de datos para que los registros de auditoría se transmitan de Power BI a Azure Log Analytics de Microsoft Sentinel (que es un componente del servicio Azure Monitor). Puede usar el lenguaje de consulta Kusto (KQL) para analizar los eventos del registro de actividad almacenados en Azure Log Analytics.

El uso de KQL para buscar los datos en Azure Monitor es una buena opción para ver parte del registro de auditoría. También es una buena opción para los procesos de auditoría manual. Para más información, consulte Microsoft Sentinel más adelante en este artículo.

Consideraciones de plataforma

Estas son algunas consideraciones sobre cómo puede acceder a los datos de auditoría.

• ¿Va a implementar un proceso de auditoría manual o automatizado? Algunas herramientas se adaptan mejor al procesamiento manual o al procesamiento automatizado. Por ejemplo, un usuario siempre ejecuta la funcionalidad Try-it de forma interactiva, por lo que solo es adecuada para procesos de auditoría manuales.
• ¿Cómo se autenticará? No todas las opciones admiten todas las opciones de autenticación. Por ejemplo, la funcionalidad Try-it solo admite la autenticación de usuario.
• ¿Cómo almacenará las credenciales de forma segura? Las distintas tecnologías tienen diferentes opciones para almacenar las credenciales. Para obtener más información, consulte Determinación del método de autenticación más adelante en este artículo.
• ¿Qué tecnología domina ya su equipo? Si hay una herramienta que su equipo prefiere y con la que se siente cómodo, empiece por ahí.
• ¿Qué es capaz de apoyar su equipo? Si un equipo diferente va a dar soporte a la solución implementada, considere si ese equipo es capaz de dar el soporte adecuado. Tenga en cuenta también que los equipos internos pueden apoyar el desarrollo que realizan los consultores.
• ¿Qué herramienta está autorizado a utilizar? Es posible que ciertas herramientas y tecnologías requieran aprobación. Podría deberse al costo. También podría deberse a las directivas de seguridad de TI.
• ¿Cuál es su preferencia en cuanto a programación? Algunas tecnologías toman la decisión de forma autónoma. Otras veces será otra decisión que deba tomar. Por ejemplo, si decide escribir scripts de PowerShell, hay varias maneras de programar su ejecución. Por el contrario, si usa un servicio en la nube como Azure Data Factory, la programación está integrada.

Se recomienda revisar el resto de este artículo antes de elegir una tecnología para acceder a los datos de auditoría.

Lista de comprobación: al decidir qué tecnología usar para acceder a los datos de auditoría, estas son las principales decisiones y acciones que debe adoptar:

Determinación del método de autenticación

La forma en que planea configurar la autenticación es una decisión crítica. A menudo es uno de los aspectos más difíciles al empezar a trabajar con la auditoría y la supervisión. Debe considerar cuidadosamente las opciones disponibles para tomar una decisión informada.

No todas las API de Internet requieren autenticación. Sin embargo, todas las API REST de Power BI requieren autenticación. Al acceder a los datos de auditoría de nivel de inquilino, la plataforma de identidad de Microsoft administra el proceso de autenticación. Es una evolución del servicio de identidad de Microsoft Entra basado en protocolos estándar del sector.

Antes de recuperar los datos de auditoría, primero debe autenticarse, lo que se conoce como iniciar sesión. Los conceptos de autenticación y autorización son independientes, pero están relacionados. Un proceso de autenticación comprueba la identidad de quién realiza la solicitud. Un proceso de autorización concede (o deniega) el acceso a un sistema o recurso comprobando aquello que el usuario o la entidad de servicio tiene permiso para hacer.

Cuando se autentica un usuario o una entidad de servicio, se emite un token de acceso de Microsoft Entra a un servidor de recursos, como una API de REST de Power BI o una Microsoft Graph API. De forma predeterminada, el token de acceso expira después de una hora. Se puede solicitar un token de actualización, si es necesario.

Existen dos tipos de tokens de acceso:

• Tokens de usuario: emitidos en nombre de un usuario con una identidad conocida.
• Tokens de solo aplicación: emitidos en nombre de una aplicación de Microsoft Entra (entidad de servicio).

Para más información, consulte Objetos de aplicación y de entidad de servicio en Microsoft Entra ID.

En la tabla siguiente se describen las dos opciones de autenticación.

Tipo de autenticación	Descripción	Destinado a	Buena opción para procesos de auditoría manuales	Buena opción para procesos de auditoría automatizados
Autenticación de usuarios	Inicie sesión como usuario con el nombre principal de usuario (dirección de correo electrónico) y una contraseña.	Uso ocasional e interactivo
Autenticación de entidad de servicio	Inicie sesión como entidad de servicio mediante un secreto (clave) asignado a un registro de aplicación.	Operaciones desatendidas, programadas y en curso

Cada opción de autenticación se describe con más detalle en la sección siguiente.

Autenticación de usuarios

La autenticación de usuario resulta útil en las situaciones siguientes.

• Procesos de auditoría manual: quiere ejecutar un script mediante los permisos de usuario. Los permisos pueden estar en uno de dos niveles, en función del tipo de solicitud de API:
  • Permisos de administrador para las API de administrador: debe usar los permisos de administrador de Power BI para enviar una solicitud a una API de administrador.
  • Permisos de usuario para las API de usuario: debe usar los permisos de usuario de Power BI para enviar una solicitud a una API de usuario. Para obtener más información, consulte Elección de una API de usuario o una API de administrador.
• Inicio de sesión interactivo: quiere iniciar sesión de forma interactiva, lo que requiere que escriba la dirección de correo electrónico y la contraseña. Por ejemplo, debe iniciar sesión de forma interactiva para usar la experiencia Try-it, que se encuentra en la documentación de la API de Microsoft.
• Seguimiento de quién ha accedido a los metadatos del inquilino: cuando los usuarios individuales y los administradores envían solicitudes de API, es posible que desee auditar quiénes son esos usuarios. Cuando se autentica con una entidad de servicio (que se describe a continuación), el identificador de usuario capturado por el registro de actividad es el identificador de aplicación. Si varios administradores se autentican con la misma entidad de servicio, puede ser difícil saber qué administrador ha accedido a los datos.
• Cuenta de administrador compartida: algunos equipos de TI usan una cuenta de administrador compartida. En función de cómo se implemente y controle, es posible que no sea un procedimiento recomendado. En lugar de una cuenta compartida, debe considerar el uso de Privileged Identity Management (PIM) de Microsoft Entra, que puede conceder derechos de administrador de Power BI ocasionales y temporales para un usuario.
• API que solo admiten la autenticación de usuarios: en ocasiones, es posible que tenga que usar una API que no admita la autenticación por una entidad de servicio. En la documentación, cada API indica si una entidad de servicio puede llamarla.

Autenticación de entidad de servicio

La mayoría de las organizaciones tienen un inquilino de Microsoft Entra, por lo que los términos registro de aplicaciones y entidad de servicio tienden a usarse indistintamente. Cuando registra una aplicación de Microsoft Entra, hay dos componentes.

• Registro de aplicaciones: un registro de aplicaciones es único globalmente. Es la definición global de una aplicación de Microsoft Entra registrada que pueden usar varios inquilinos. Un registro de aplicaciones también se conoce como aplicación cliente o actor. Normalmente, el término aplicación cliente implica una máquina de usuario. Sin embargo, no es la situación de los registros de aplicaciones. En Azure Portal, las aplicaciones de Microsoft Entra se encuentran en la página Registros de aplicaciones de Microsoft Entra ID.
• Entidad de servicio: una entidad de servicio es la representación local del registro de aplicaciones para su uso en el inquilino específico. La entidad de servicio se deriva de la aplicación de Microsoft Entra registrada. En el caso de las organizaciones con varios inquilinos de Microsoft Entra, más de una entidad de servicio puede hacer referencia al mismo registro de aplicaciones. En Azure Portal, las entidades de servicio se pueden encontrar en la página Aplicaciones empresariales de Microsoft Entra ID.

Dado que la entidad de servicio es la representación local, el término autenticación de entidad de servicio es la manera más común de hacer referencia a inicios de sesión.

La autenticación de entidad de servicio es útil en las siguientes situaciones.

• Procesos de auditoría automatizados: quiere ejecutar un proceso desatendido según una programación.
• No es necesario iniciar sesión en el servicio Power BI: solo tiene que conectarse y extraer datos. Una entidad de servicio no puede iniciar sesión en el servicio Power BI.
• Acceso compartido a los datos: Usted (personalmente) no es un administrador de Power BI, pero está autorizado a usar una entidad de servicio. La entidad de servicio tiene permiso para ejecutar API de administración para recuperar datos de nivel de inquilino (u otros permisos específicos).
• Uso de varios administradores: quiere permitir que varios administradores o usuarios usen la misma entidad de servicio.
• Bloqueadores técnicos: hay un bloqueador técnico que impide el uso de la autenticación de usuario. Entre los bloqueadores técnicos comunes se incluyen:
  • Autenticación multifactor (MFA): los procesos de auditoría automatizados (que se ejecutan desatendidos) no se pueden autenticar mediante una cuenta de usuario cuando está habilitada la autenticación multifactor.
  • Sincronización de hash de contraseñas: Microsoft Entra ID requiere la sincronización de hash de contraseñas para que una cuenta de usuario se autentique. A veces, el equipo de TI o de ciberseguridad podría deshabilitar esta funcionalidad.

Convención de nomenclatura y propósito del registro de aplicaciones

Cada registro de aplicaciones debe tener un nombre claro que describa su propósito y la audiencia de destino (quién puede usar el registro de la aplicación).

Considere la posibilidad de implementar una convención de nomenclatura como: <Carga de trabajo> - <Propósito> - <Audiencia de destino> - <Tipo de objeto>

Estas son las partes de la convención de nomenclatura.

• Carga de trabajo: normalmente equivale a un origen de datos (por ejemplo, datos de Power BI o datos de Microsoft Graph).
• Propósito: similar al nivel de permisos (por ejemplo, Read frente a ReadWrite). Como se describe a continuación, el propósito le ayuda a seguir el principio de privilegios mínimos al crear registros de aplicaciones independientes que solo puedan leer datos.
• Audiencia de destino: opcional. Según la carga de trabajo y el propósito, la audiencia de destino le permite determinar los usuarios previstos del registro de aplicaciones.
• Tipo de objeto: EntraApp se incluye para mayor claridad.

La convención de nomenclatura puede ser más específica cuando tiene varios inquilinos o varios entornos (como desarrollo y producción).

En la tabla siguiente se muestran ejemplos de registros de aplicaciones que se pueden usar para extraer datos de auditoría de nivel de inquilino:

Nombre de registro de aplicaciones	Propósito	Audiencia de destino
PowerBIData-Read-AdminAPIs-EntraApp	Extraiga metadatos de todo el inquilino para la auditoría y administración de Power BI. Las API de administrador siempre son de solo lectura y es posible que no tengan permisos concedidos en el identificador de Microsoft Entra (solo configuración de inquilino de Power BI).	Administradores de Power BI y centro de excelencia
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	Administre el inquilino de Power BI. Requiere permisos de lectura y escritura para crear o actualizar recursos.	Administradores de Power BI y centro de excelencia
GraphData-Read-PowerBIAdministrators-EntraApp	Extraiga datos de usuarios y grupos para la auditoría y administración de Power BI. Requiere permiso de lectura.	Administradores de Power BI y centro de excelencia

La administración de varios registros de aplicaciones para diferentes propósitos implica más esfuerzo. Sin embargo, puede beneficiarse de varias ventajas.

• Ver para qué se pretende utilizar el registro de aplicaciones y por qué: cuando vea que el identificador de cliente del registro de aplicaciones aparece en los datos de auditoría, tendrá una idea de para qué se utilizó y por qué. Esta es una ventaja significativa de crear registros de aplicaciones independientes (en lugar de usar solo uno para todos los fines).
• Vea quién se pretende que utilice el registro de aplicaciones: cuando vea que el identificador de cliente del registro de aplicaciones aparece en los datos de auditoría, tendrá una idea de quién lo estaba usando.
• Evite el sobreaprovisionamiento de permisos: puede seguir el principio de privilegios mínimos proporcionando registros de aplicaciones independientes a diferentes conjuntos de personas que tienen diferentes necesidades. Puede evitar el sobreaprovisionamiento de permisos mediante el uso de un registro de aplicaciones de solo lectura cuando no son necesarios los permisos de escritura. Por ejemplo, es posible que tenga algunos usuarios de autoservicio altamente capaces que quieran recopilar datos sobre sus modelos semánticos; necesitan acceso a una entidad de servicio con permiso de lectura. Considerando que puede haber miembros satélite del centro de excelencia trabajando para el equipo financiero que administra mediante programación modelos semánticos; necesitan acceso a una entidad de servicio con permiso de escritura.
• Sepa quién debe estar en posesión del secreto: el secreto de cada registro de aplicación solo debe compartirse con las personas que lo necesitan. Cuando se rota el secreto (descrito más adelante en esta sección), el impacto es menor cuando se usan registros de aplicaciones independientes para diferentes necesidades. Esto resulta útil cuando necesita rotar el secreto porque un usuario deja la organización o cambia los roles.

Permisos del registro de aplicaciones

Hay dos formas principales por las que el registro de aplicaciones puede acceder a datos y recursos. Implica permisos y consentimiento.

• Permisos de solo aplicación: la entidad de servicio controla el acceso y la autorización sin un usuario que haya iniciado sesión. Ese método de autenticación es útil para escenarios de automatización. Al usar permisos de solo aplicación, es fundamental comprender que los permisos no están asignados en Microsoft Entra ID. En su lugar, los permisos se asignan de una de estas dos maneras:
  • Para ejecutar las API de administrador: algunas opciones de configuración de inquilino de Power BI permiten el acceso a los puntos de conexión de las API de administración (que devuelven metadatos de auditoría para todo el inquilino). Para más información, consulte Establecimiento de la configuración de inquilinos de Power BI más adelante en este artículo.
  • Para ejecutar las API de usuario: se aplican permisos de elemento y área de trabajo de Power BI. Los permisos estándar de Power BI controlan qué datos se pueden devolver a una entidad de servicio al ejecutar las API de usuario (que devuelven datos de auditoría basados en los permisos del usuario o la entidad de servicio que invoca la API).
• Permisos delegados: se usan permisos basados en ámbito. La entidad de servicio accede a los datos en nombre del usuario que ha iniciado sesión actualmente. Significa que la entidad de seguridad del servicio no puede acceder a nada más allá de lo que puede acceder el usuario que ha iniciado sesión. Tenga en cuenta que se trata de un concepto diferente de la autenticación solo de usuario, descrita anteriormente. Dado que se requiere una aplicación personalizada para controlar correctamente la combinación de permisos de usuario y aplicación, los permisos delegados rara vez se usan para escenarios de auditoría. Este concepto suele malinterpretarse, lo que se traduce en muchos registros de aplicaciones con una cantidad excesiva de permisos.

Para más información, consulte Registro de una aplicación de Microsoft Entra más adelante en este artículo.

Secretos de registros de aplicaciones

Un registro de aplicaciones suele tener asignado un secreto. El secreto se usa como clave para la autenticación y tiene una fecha de expiración. Por lo tanto, debe planear cómo rotar la clave con regularidad y cómo comunicar la nueva clave a los usuarios autorizados.

También debe preocuparse por dónde almacenar de forma segura el secreto. Un almacén de contraseñas de la organización, como Azure Key Vault, es una excelente opción.

Administración segura de credenciales

Independientemente de si usa la autenticación de usuario o la autenticación de entidad de servicio, uno de los mayores desafíos es cómo administrar de forma segura contraseñas, secretos y claves.

Estos son varios métodos seguros que puede usar para administrar contraseñas, secretos y claves.

• Intégrelos con Azure Key Vault u otro sistema de almacén de contraseñas de la organización, siempre que sea posible.
• Use credenciales y cadenas seguras en los scripts de PowerShell. Una credencial funciona tanto para la autenticación de usuario como para la autenticación de entidad de servicio. Sin embargo, no se puede usar una credencial cuando la autenticación multifactor está habilitada para una cuenta de usuario.
• Solicite una contraseña en el script de PowerShell o use la autenticación interactiva con un explorador.
• Use el módulo Administración de secretos para PowerShell publicado por Microsoft. Puede almacenar valores mediante un almacén local. También puede integrarse con un almacén de Azure Key Vault remoto, lo que resulta útil cuando hay varios administradores en su organización que trabajan con los mismos scripts.
• Cree un conector personalizado para Power BI Desktop para que pueda controlar las credenciales de forma segura. Algunos conectores personalizados están disponibles gracias a los miembros de la comunidad (normalmente en GitHub).

Biblioteca de autenticación de Microsoft

La compatibilidad con la biblioteca de autenticación de Azure AD (ADAL) finalizó en diciembre de 2022. En el futuro, debe usar la biblioteca de autenticación de Microsoft (MSAL). El equipo de seguridad de su organización debe estar familiarizado con este cambio significativo.

Aunque no es importante que los profesionales de Power BI comprendan profundamente la transición a MSAL, debe cumplir las siguientes recomendaciones.

• Use la versión más reciente del módulo de administración de Power BI al autenticarse con el cmdlet Connect-PowerBIServiceAccount de PowerShell. Cambió de ADAL a MSAL en la versión 1.0.946 (26 de febrero de 2021).
• Use el punto de conexión de Microsoft Entra V2 cuando se autentique directamente en el script. El punto de conexión de Microsoft Entra V2 usa MSAL, mientras que el punto de conexión de Microsoft Entra V1 usa ADAL.
• Deje de utilizar las API y los módulos obsoletos. Para obtener más información, consulte API y módulos en desuso más adelante en este artículo.
• Si encuentra una solución de comunidad en línea, asegúrese de que usa MSAL para la autenticación en lugar de ADAL.

Lista de comprobación : al decidir cómo administrar la autenticación, estas son las principales decisiones y acciones que debe adoptar:

Elección de una API de usuario o una API de administrador

Al planear la recuperación de datos de auditoría, es importante usar el tipo correcto de API.

Hay dos tipos de API que se deben considerar.

• API de usuario: confíe en los permisos del usuario (o entidad de servicio) que ha iniciado sesión para enviar solicitudes a la API. Por ejemplo, una manera de devolver una lista de modelos semánticos en un área de trabajo es con una API de usuario. El permiso para leer modelos semánticos puede concederse por rol de área de trabajo o mediante permisos por elemento. La ejecución de las API de usuario se puede realizar de dos maneras:
  • Autenticación de usuario: el usuario que ha iniciado sesión debe tener permiso para acceder al área de trabajo o al elemento.
  • Autenticación de entidad de servicio: la entidad de servicio debe tener permiso para acceder al área de trabajo o al elemento.
• API de administración: recupere los metadatos del inquilino. A veces se conoce como ámbito organizativo. Por ejemplo, para devolver una lista de todos los modelos semánticos del inquilino, use una API de administración. La ejecución de las API de administrador se puede realizar de dos maneras:
  • Autenticación de usuario: el usuario que ha iniciado sesión debe ser un administrador de Power BI para ejecutar las API de administrador.
  • Autenticación de entidad de servicio: la entidad de servicio debe tener permiso para ejecutar API de administración (sin depender de permisos de seguridad, como hace una API de usuario).

Piense en un ejemplo en el que necesita obtener una lista de modelos semánticos. En la tabla siguiente se muestran seis opciones de API que puede usar para hacerlo. Cuatro opciones son API de usuario y dos son API de administrador. El ámbito y el número de elementos que se devuelven son diferentes, en función de la API que elija.

Nombre de la API	Tipo de API	Ámbito	Número de modelos semánticos
Obtener conjunto de datos	Usuario	Área de trabajo personal	Uno
Obtener conjuntos de datos	Usuario	Área de trabajo personal	All
Obtener conjunto de datos en grupo	Usuario	Un área de trabajo	Uno, siempre que el usuario que ha iniciado sesión tenga permiso para leer el modelo semántico.
Obtener conjuntos de datos en grupo	Usuario	Un área de trabajo	Todo, siempre que el usuario que ha iniciado sesión tenga permiso para leer cada modelo semántico.
Obtener conjuntos de datos en grupo como administrador	Administrador	Un área de trabajo	All
Obtener conjuntos de datos como administrador	Administrador	Todo el inquilino	All

Para obtener información sobre la configuración de inquilinos, consulte Establecimiento de la configuración de inquilinos de Power BI más adelante en este artículo.

Lista de comprobación: al elegir si se usa una API de usuario o una API de administrador, estas son las principales decisiones y acciones que debe adoptar:

Elección de API o cmdlets de PowerShell

Una decisión clave que se debe tomar es si se deben usar cmdlets de PowerShell cuando estén disponibles para los datos específicos que desea recuperar. Esta decisión es importante si ha decidido que PowerShell es una de las tecnologías que utilizará para acceder a los datos de auditoría.

PowerShell es una solución de automatización de tareas. El término PowerShell es un término colectivo que hace referencia al lenguaje de scripting, a una aplicación de shell de línea de comandos y a un marco de administración de configuración. PowerShell Core es la versión más reciente de PowerShell, que se ejecuta en Windows, Linux y macOS.

Un cmdlet de PowerShell es un comando que realiza una acción. Un módulo de PowerShell es un paquete que contiene miembros de PowerShell, como cmdlets, proveedores, funciones, flujos de trabajo, variables y alias. Descargue e instale módulos.

Un módulo de PowerShell crea una capa de abstracción sobre las API. Por ejemplo, el cmdlet Get-PowerBIActivityEvent recupera (u obtiene) eventos de auditoría para un inquilino de Power BI. Este cmdlet de PowerShell recupera sus datos de la API REST Obtener eventos de actividad. Por lo general, es más sencillo empezar a usar los cmdlets porque simplifica el acceso a las API subyacentes.

Solo hay disponible un subconjunto de las API como cmdlets de PowerShell. A medida que continúe expandiendo toda la solución de auditoría, es probable que use una combinación de cmdlets y API. El resto de esta sección le ayuda a decidir de qué manera accederá a los datos.

Módulos de PowerShell

Microsoft ha publicado dos módulos de PowerShell que contienen cmdlets relacionados con Power BI. Son el módulo de administración de Power BI y el módulo de puerta de enlace de datos. Estos módulos de PowerShell actúan como contenedor de API sobre las API REST subyacentes de Power BI. El uso de estos módulos de PowerShell puede facilitar la escritura de scripts.

Módulo de administración de Power BI

El módulo de administración de Power BI es un módulo acumulativo que contiene módulos específicos de Power BI para la administración, capacidades, áreas de trabajo, etc. Puede optar por instalar el módulo acumulativo para obtener todos los módulos, o puede instalar módulos específicos. Todos los módulos de administración de Power BI se admiten en Windows PowerShell y PowerShell Core.

Estos son varios cmdlets usados habitualmente que puede usar para recuperar datos de auditoría.

Módulo de administración	Cmdlet	Propósito
Perfil	Connect-PowerBIServiceAccount	Autenticación de un usuario o entidad de servicio de Power BI.
Administrador	Get-PowerBIActivityEvent	Vea o extraiga eventos del registro de actividad de Power BI para el inquilino.
Áreas de trabajo	Get-PowerBIWorkspace	Compile una lista de áreas de trabajo.
Informes	Get-PowerBIReport	Compile una lista de informes para un área de trabajo o el inquilino.
data	Get-PowerBIDataset	Compile una lista de modelos semánticos para un área de trabajo o el inquilino.
Profile	Invoke-PowerBIRestMethod	Envíe una solicitud de API REST (comando). Este cmdlet es una buena opción porque puede invocar cualquiera de las API REST de Power BI. También es una buena opción cuando se desea utilizar la forma más sencilla de autenticación mediante el cmdlet Connect-PowerBIServiceAccount y poder invocar una API que no dispone del cmdlet PowerShell correspondiente. Para más información, consulte Consideraciones sobre el uso de cmdlets de PowerShell más adelante en esta sección.

Puede descargar el módulo de administración de Power BI desde la Galería de PowerShell. La manera más sencilla de instalar módulos es usar PowerShellGet.

Se recomienda instalar el módulo acumulativo de administración de Power BI. De este modo, todos los cmdlets que puede necesitar están disponibles. Como mínimo, necesita el módulo Perfil (para la autenticación) y los módulos específicos que contengan los cmdlets que desea usar.

Módulo Puerta de enlace de datos

El módulo Puerta de enlace de datos contiene cmdlets que recuperan datos de una puerta de enlace de datos local y sus orígenes de datos. El módulo Puerta de enlace de datos solo se admite en PowerShell Core. No se admite en Windows PowerShell.

A diferencia del módulo de administración de Power BI (descrito anteriormente), el módulo Puerta de enlace de datos no incluye ningún cmdlet de administrador. Muchos de los cmdlets (y las API de puerta de enlace correspondientes) requieren que el usuario tenga derechos de administrador de puerta de enlace.

Estos son varios cmdlets del módulo Puerta de enlace de datos que puede usar para recuperar los datos de auditoría.

Cmdlet	Propósito
Connect-DataGatewayServiceAccount	Autentique un usuario de Power BI (normalmente requiere que el usuario pertenezca al rol de administrador de la puerta de enlace).
Get-DataGatewayCluster	Compile una lista de clústeres de puerta de enlace.
Get-DataGatewayClusterDataSource	Compile una lista de orígenes de datos para un clúster de puerta de enlace.
Get-DataGatewayInstaller	Compruebe qué usuarios pueden instalar y registrar puertas de enlace en la organización.

Puede descargar el módulo Puerta de enlace de datos desde la galería de PowerShell.

Técnicas para usar PowerShell

Puede usar PowerShell de varias maneras diferentes. La decisión que tome es importante.

En la tabla siguiente se describen tres técnicas diferentes para usar PowerShell.

Técnica	Descripción	Ejemplo
Use cmdlets de PowerShell para simplificar la autenticación y llamar directamente a las API. Enfoque recomendado	Con esta técnica, hay un equilibrio de simplicidad y flexibilidad. El cmdlet Invoke-PowerBIRestMethod está disponible en el módulo Perfil de administración de Power BI. Este cmdlet se conoce a menudo como navaja suiza porque puede usarlo para llamar a cualquiera de las API REST de Power BI. La ventaja de usar esta técnica es que puede simplificar la autenticación y, a continuación, llamar a cualquiera de las API REST de Power BI. Le recomendamos encarecidamente que use esta técnica.	Después de autenticarse con el cmdlet Connect-PowerBIServiceAccount, use el cmdlet Invoke-PowerBIRestMethod para recuperar datos de la API preferida (por ejemplo, Obtener usuarios de canalización como administración).
Use cmdlets de PowerShell tanto como sea posible, tanto para la autenticación como para la recuperación de datos.	Con esta técnica, PowerShell se usa ampliamente. PowerShell se usa para coordinar la ejecución del script, y los módulos de PowerShell se usan siempre que sea posible para acceder a los datos. Esto crea una mayor dependencia de PowerShell a partir de varios aspectos.	Después de autenticarse con el cmdlet Connect-PowerBIServiceAccount, use un cmdlet (por ejemplo, Get-PowerBIActivityEvent) para recuperar datos.
Use PowerShell solo para coordinar la ejecución del proceso. Los módulos de PowerShell se usan lo menos posible.	Con esta técnica, hay menos dependencias en PowerShell como herramienta, ya que su uso principal es orquestar llamadas API. Solo se usa un módulo genérico de PowerShell para acceder a las API (no se usa ninguno de los módulos de los módulos de administración de Power BI).	Después de autenticarse mediante la biblioteca de autenticación de Microsoft (MSAL), llame a la API preferida (por ejemplo, Obtener usuarios de canalización como administración) mediante el cmdlet genérico Invoke-RestMethod para recuperar datos.

En la tabla anterior, la primera técnica describe un enfoque que equilibra la facilidad de uso con flexibilidad. Este enfoque proporciona el mejor equilibrio para las necesidades de la mayoría de las organizaciones, por lo que es la opción recomendada. Algunas organizaciones pueden tener directivas de TI y preferencias de personal existentes que influyen en cómo decide usar PowerShell.

Los usuarios técnicos (y administradores) pueden usar los módulos de administración de Power BI para recuperar datos o automatizar determinados aspectos de la administración de contenido.

• Para administradores: Establezca el parámetro -Scope en Organization para acceder a las entidades en todo el inquilino (por ejemplo, para recuperar una lista de todas las áreas de trabajo).
• Para usuarios técnicos: establezca el parámetro -Scope en Individual (u omita el parámetro) para acceder a las entidades que pertenecen al usuario (por ejemplo, para recuperar una lista de áreas de trabajo para las que el usuario tiene permiso de acceso).

Piense en un escenario en el que necesita obtener una lista de modelos semánticos. Si decide trabajar directamente con las API, debe especificar a qué API llamar. Sin embargo, si decide usar el cmdlet Get-PowerBIDataset, puede establecer el parámetro -Scope para recuperar una lista de modelos semánticos específica del usuario o de todo el inquilino. La elección que tome dependerá de su decisión sobre cómo utilizar PowerShell (tratada en la tabla anterior).

En la tabla siguiente se describe cómo se traducen los parámetros utilizados en el cmdlet de PowerShell a las llamadas a la API de PowerShell.

Parámetros del cmdlet	API que usa el cmdlet	Tipo de API	Ámbito	Elementos recuperados
-DatasetID {DatasetID} -Scope Individual	Obtener conjunto de datos	Usuario	Área de trabajo personal	Un modelo semántico
-Scope Individual	Obtener conjuntos de datos	Usuario	Área de trabajo personal	Todos los modelos semánticos
-DatasetID {DatasetID} -GroupID {WorkspaceID}	Obtener conjunto de datos en grupo	Usuario	Un área de trabajo	Un modelo semántico, siempre que el usuario que ha iniciado sesión tenga permiso para leer el modelo semántico.
-GroupID {WorkspaceID}	Obtener conjuntos de datos en grupo	Usuario	Un área de trabajo	Todos los modelos semánticos, siempre que el usuario que ha iniciado sesión tenga permiso para acceder al área de trabajo y leer el modelo semántico.
-GroupID {WorkspaceID} -Scope Organization	Obtener conjuntos de datos en grupo como administrador	Administrador	Un área de trabajo	Todos los modelos semánticos
-Scope Organization	Obtener conjuntos de datos como administrador	Administrador	Todo el inquilino	Todos los modelos semánticos

Consideraciones para usar cmdlets de PowerShell

Los cmdlets de PowerShell para Power BI son más fáciles de usar porque resumen parte de la complejidad de las llamadas a la API REST.

Estas son algunas de las formas en que los cmdlets simplifican el acceso a los datos de auditoría.

• Autenticación: la forma más sencilla de autenticarse en un script de PowerShell es usar el cmdlet Connect-PowerBIServiceAccount.
• Simplicidad: resulta más fácil empezar porque las técnicas para recuperar datos de auditoría son más sencillas. Tenga en cuenta que, al usar el cmdlet Get-PowerBIActivityEvent, recupera un día de datos de auditoría. Sin embargo, cuando se llama directamente a la API REST Obtener eventos de actividad, se recupera una hora de datos de auditoría. Por lo tanto, cuando se usa la API REST para recuperar un día de datos de auditoría, debe usar un bucle para llamar a la API 24 veces para extraer cada hora del día.
• Paginación de grandes conjuntos de resultados: los grandes conjuntos de resultados se recuperan eficazmente mediante la paginación. La paginación implica recuperar un fragmento de los resultados a la vez. Los cmdlets administran automáticamente la paginación. Sin embargo, cuando se usan directamente las API REST, el script debe comprobar un token de continuación para determinar si hay más resultados. El script debe continuar recuperando fragmentos de resultados hasta que no se reciba ningún token de continuación. Para obtener un ejemplo del uso de un token de continuación, consulte la REST API de eventos de actividad.
• Expiraciones del token de acceso: tras la autenticación, se devuelve un token de acceso. De forma predeterminada, expira después de una hora. Los cmdlets controlan automáticamente las expiraciones del token de acceso. De este modo, no es necesario escribir lógica para solicitar un token de actualización.
• Formato: el formato de los datos devueltos por un cmdlet es un poco mejor que el de aquellos devueltos por la API REST. La salida es más fácil de usar. En el caso de los procesos de auditoría automatizada, es probable que no resulte un problema. Sin embargo, en el caso de los procesos de auditoría manual, el formato más agradable puede ser útil.

Consideraciones para usar las API REST directamente

En ocasiones, llamar a las API REST de Power BI directamente tiene algunas ventajas.

• Muchas más API disponibles: hay más API REST disponibles que cmdlets de PowerShell. Sin embargo, no pase por alto la flexibilidad del cmdlet Invoke-PowerBIRestMethod, que puede usar para llamar a cualquiera de las API REST de Power BI.
• Frecuencia de las actualizaciones: Microsoft actualiza las API REST con mayor frecuencia que los módulos de PowerShell. Por ejemplo, si se agrega un nuevo atributo a la respuesta de API Obtener conjunto de datos, podría tardar algún tiempo antes de estar disponible en los resultados del cmdlet Get-PowerBIDataset.
• Menos dependencia del lenguaje o la herramienta: cuando se usan las API REST directamente (en lugar de un cmdlet), no es necesario utilizar PowerShell. O bien, puede optar por usar PowerShell solo para orquestar la llamada a muchas API en un script. Al quitar (o evitar) cualquier dependencia de PowerShell, en algún momento del futuro puede volver a escribir la lógica en un lenguaje diferente. Cuando el equipo de TI o desarrolladores tiene fuertes preferencias por herramientas y lenguajes, una menor dependencia puede ser una consideración importante a tener en cuenta.

Independientemente del método que elija usar, las API REST pueden cambiar con el tiempo. Cuando una tecnología evoluciona, las API (y los módulos de PowerShell) pueden quedar en desuso y reemplazarse. Por lo tanto, se recomienda crear scripts que sean fáciles de mantener y resistentes al cambio de forma intencionada.

Lista de comprobación: al elegir si desea acceder a las API REST directamente o mediante cmdlets de PowerShell, entre las decisiones y acciones clave se incluyen las siguientes:

Determinación de dónde almacenar los datos de auditoría

Cuando planee crear una solución de auditoría completa, deberá decidir dónde almacenar los datos sin procesar (y los datos mantenidos, que se tratan en la sección siguiente). Sus decisiones sobre el almacenamiento de datos están relacionadas con sus preferencias sobre cómo controlar la integración de datos.

Cuando extraiga datos de auditoría sin procesar, hágalo de forma sencilla. Se recomienda no seleccionar atributos específicos, realizar transformaciones ni aplicar ningún formato al extraer inicialmente los datos. En su lugar, extraiga todos los atributos disponibles y almacene los datos en su estado original.

Estas son varias razones por las que almacenar los datos sin procesar en su estado original es un procedimiento recomendado.

• Todos los datos disponibles en el historial: nuevos atributos y tipos de evento estarán disponibles con el tiempo. Almacenar todos los datos sin procesar es una buena forma de asegurarse de tener siempre acceso a los datos disponibles en el momento de su extracción. Incluso cuando tarda (semanas o meses) en darse cuenta de que hay nuevos atributos de datos disponibles, es posible analizarlos históricamente al haberlos capturado en los datos sin procesar.
• Resistente al cambio: si cambia el formato de datos sin procesar, el proceso que extrae los datos no se ve afectado. Dado que algunos datos de auditoría dependen del tiempo, es importante asegurarse de diseñar un proceso de extracción de datos que no produzca un error cuando tenga lugar un cambio en el origen.
• Roles y responsabilidades: los distintos miembros del equipo (como ingenieros de datos o administradores de Fabric) pueden ser responsables de crear los procesos para acceder a los datos de auditoría sin procesar, extraerlos y almacenarlos. Simplificar el proceso de extracción de datos facilita el trabajo colectivo de varios equipos.

Estas son algunas opciones para almacenar datos sin procesar.

• Lago de datos o almacenamiento de objetos: un servicio en la nube como OneLake que se especializa en almacenar archivos de cualquier estructura. Es una opción ideal para almacenar los datos de auditoría sin procesar. En una arquitectura de lago de datos, los datos sin procesar deben almacenarse en la capa bronce.
• Sistema de archivos: un sistema de archivos (como Windows o Linux) es una opción común para almacenar los datos de auditoría sin procesar.
• Base de datos: es posible almacenar datos JSON en una base de datos relacional, como Azure SQL Database. Sin embargo, es menos común que almacenar los datos en un lago de datos o en un sistema de archivos. Esto se debe a que la consulta y el mantenimiento de datos JSON pueden resultar desafiantes y costosos, especialmente a medida que crecen los volúmenes de datos.

Considere un ejemplo en el que se incluye una zona de datos sin procesar de un lago de datos. La zona tiene una jerarquía de carpetas para almacenar los datos del registro de actividad: Sin procesar > ActivityLog > AAAA > MM. Las carpetas están particionadas por año y mes. Un archivo almacenado en la carpeta month usa el siguiente formato: PBIActivityLog-AAAAMMDD-AAAAMMDDTTTT.json. AAAAMMDD representa los datos actuales y, AAAAMMDDTTTT, la marca de tiempo de la extracción. Al incluir la marca de tiempo de la extracción, puede determinar qué archivo es el más reciente (en caso de que tenga que extraer los datos de nuevo). Por ejemplo, si extrae datos a las 9:00 (UTC) el 25 de abril de 2023 para la actividad del 23 de abril de 2023, el nombre de archivo sería PBIActivityLog-20230523-202305250900.

Se recomienda encarecidamente usar una tecnología que le permita escribir los datos sin procesar en el almacenamiento inmutable. El almacenamiento inmutable garantiza que los datos no se puedan sobrescribir ni eliminar una vez escritos. Esa distinción es importante para los auditores y le permite confiar en la fiabilidad de los datos sin procesar.

También debe considerar cómo almacenar de forma segura los datos sin procesar. Normalmente, muy pocos usuarios requieren acceso a los datos sin procesar. El acceso a los datos sin procesar se suele proporcionar en caso necesario, normalmente para ingenieros de datos y administradores del sistema. Es posible que los auditores internos también necesiten acceso. Los miembros del equipo responsables de crear los datos mantenidos (descritos a continuación) también requieren acceso a los datos sin procesar.

Estas son algunas consideraciones que le ayudarán a elegir el almacenamiento de datos sin procesar.

• ¿Es un proceso de auditoría manual o automatizada? Un proceso de auditoría automatizada normalmente tiene requisitos más estrictos sobre cómo y dónde se almacenan los datos.
• ¿Es el área de asunto especialmente confidencial? Según el tipo de datos y su confidencialidad, es posible que su organización tenga un requisito sobre cómo y dónde se almacenan. Los datos de auditoría de Power BI contienen la identificación de información de usuario y direcciones IP, por lo que deben almacenarse en un área segura.
• ¿Hay una tecnología de almacenamiento preferida? Puede haber una tecnología de almacenamiento existente que esté en uso dentro de la organización, por lo que es una opción lógica.
• ¿Los usuarios accederán directamente al almacenamiento? Algo importante a tener en cuenta es el modelo de seguridad. Normalmente, a muy pocos usuarios se les concede acceso a los datos sin procesar. El acceso a los datos mantenidos suele estar disponible para los creadores de contenido de Power BI responsables de crear el modelo de datos centralizado (el modelo semántico que actúa como capa para los informes).
• ¿Tiene requisitos de residencia de datos? Algunas organizaciones tienen requisitos de residencia de datos legales o normativos para almacenar datos en una región de datos específica.
• ¿Cómo se organizarán los datos? El uso de la arquitectura medallón es una práctica común, en particular en las implementaciones de lagos de datos y lakehouse. El objetivo es almacenar los datos en capas de datos bronce, plata y oro. La capa bronce contiene los datos sin procesar originales. La capa plateada contiene datos validados y desduplicados usados para las transformaciones. La capa dorada contiene los datos mantenidos y muy refinados que están listos para el análisis.

Lista de comprobación: al planear la ubicación para almacenar los datos sin procesar, algunas de las decisiones y acciones más importantes son:

Planeamiento de la creación de datos mantenidos

Los datos mantenidos admiten el análisis y están diseñados para la facilidad de uso. Debe tomar algunas decisiones sobre cómo y dónde se crearán los datos mantenidos. La tecnología que elija para almacenar los datos mantenidos puede ser cualquiera de las tecnologías enumeradas en la sección anterior.

El objetivo de los datos mantenidos es transformar los datos en un formato más descriptivo optimizado para el análisis y los informes. Constituye el origen de datos de un modelo de datos de Power BI, lo que significa que se usa un modelo de datos de Power BI para analizar el uso de Power BI en su organización. Se aplica la guía fundamental del modelo de datos: debe adoptar un diseño de esquema en estrella, que está optimizado para el rendimiento y la facilidad de uso.

Puede elegir crear datos mantenidos de diferentes maneras. Debe decidir cómo realizar la integración de datos y hasta qué punto de la cadena aplicar las transformaciones que preparan los datos para cargarlos en un esquema en estrella.

Data Lake

Puede aplicar transformaciones y crear archivos de datos mantenidos en un lago de datos. Debe utilizar una capa oro para los datos mantenidos, de modo que estén lógicamente separados de los datos sin procesar almacenados en la capa bronce. La separación de los datos en capas también simplifica la configuración de distintos permisos de acceso de usuario.

Use un lago de datos para transformar y conservar los datos cuando:

• Espera que haya varios modelos de datos de Power BI que suministren informes (lo que justifica la creación de una capa plata intermedia).
• Deba acomodar varios creadores de contenido de autoservicio que necesiten acceso a los datos de auditoría de nivel de inquilino.
• Tenga herramientas y procesos existentes que quiera usar para transformar y cargar datos.
• Quiera minimizar la preparación de datos que debe realizarse (y potencialmente duplicarse) dentro de uno o varios modelos de datos de Power BI.

Modelo de datos de Power BI

Es posible que pueda completar todo el trabajo de transformación en Power BI. Use Power Query para acceder a los datos y transformarlos desde su estado sin procesar al formato mantenido.

Use un modelo de datos de Power BI cuando:

• Quiera simplificar la arquitectura completa y cargar el modelo de datos directamente desde los datos sin procesar. (La actualización incremental puede ayudar a reducir las duraciones de las actualizaciones).
• Prefiera hacer todo el trabajo de transformación mientras se carga el modelo de datos.
• Espere tener un modelo de datos centralizado para los datos de auditoría de nivel de inquilino. Todos los informes (u otros modelos de datos) pueden usar el modelo semántico centralizado de Power BI como origen.
• Quiera proporcionar acceso de usuario solo al modelo semántico centralizado de Power BI (y no a ninguno de los datos de origen).

Para más información sobre las tablas de dimensiones y de hechos que podría incluir en el esquema en estrella, consulte Creación de un modelo de datos más adelante en este artículo.

Lista de comprobación: al planear la supervisión del origen de datos, algunas de las decisiones y acciones más importantes son:

Decisiones sobre orígenes de datos

En este punto, debe tener claros los requisitos, las necesidades de datos y los permisos. Se han tomado decisiones técnicas clave. Ahora debe tomar algunas decisiones sobre el enfoque para obtener determinados tipos de datos.

Acceso a los datos de actividad del usuario

Los datos de actividad del usuario de Power BI, que a veces se conocen como registro de actividad o registros de auditoría, incluyen una gran cantidad de información para ayudarle a comprender lo que sucede en el inquilino de Power BI. Para más información sobre cómo identificar sus necesidades de datos, consulte Datos de actividad del usuario anteriormente en este artículo.

Power BI integra sus registros con el registro de auditoría unificado de Microsoft Purview (anteriormente conocido como registro de auditoría unificado de Microsoft 365). Esta integración es una ventaja porque significa que todos los servicios de Microsoft 365 no tienen que implementar su propia forma única de registro. Esto está habilitada de manera predeterminada.

Tiene varias opciones para recuperar los datos de actividad del usuario.

Técnica	Descripción	Días predeterminados del historial disponible	Buena opción para procesos de auditoría manuales	Buena opción para procesos de auditoría automatizados	Buena opción para configurar alertas	Buena opción para ponerse en marcha rápidamente
Manual (interfaz de usuario)	Portal de cumplimiento de Microsoft Purview	90
Manual (interfaz de usuario)	Defender para aplicaciones en la nube	30
Programático	Registro de actividad de Power BI (API o cmdlet de PowerShell)	30
Programático	API de Actividad de administración de Office 365	7
Programático	Microsoft Sentinel (Azure Monitor)	30

En el resto de esta sección se presenta cada una de las técnicas incluidas en la tabla.

Portal de cumplimiento de Microsoft Purview

La herramienta de búsqueda de auditoría del portal de cumplimiento de Microsoft Purview (anteriormente conocido como centro de cumplimiento de Microsoft 365) es un lugar cómodo para ver actividades y alertas. Esta herramienta no requiere que cree un script para extraer y descargar los datos. Puede elegir una carga de trabajo de Power BI para ver todos los registros de auditoría durante un intervalo de tiempo. También puede restringir los resultados seleccionando actividades y usuarios específicos. Por ejemplo, un administrador le pide que averigüe quién eliminó un área de trabajo anteriormente ese día para que pueda ponerse en contacto rápidamente con la persona para debatir sobre la situación.

Los últimos 90 días del historial están disponibles con Auditoría (Estándar). Con Auditoría (Premium), la retención a largo plazo le permite (opcionalmente) conservar los registros de auditoría más tiempo. Dado que la retención a largo plazo solo se aplica a usuarios de E5 con licencia, excluye los registros de auditoría para usuarios que no son E5 y usuarios invitados. Por lo tanto, se recomienda que solo confíe en el historial predeterminado de 90 días para asegurarse de que se captura toda la actividad.

Hay requisitos de licencia para acceder a los registros de auditoría en el portal de cumplimiento de Microsoft Purview. También se requieren permisos de Exchange Online elevados para acceder a los registros de auditoría.

La interfaz de usuario del portal de cumplimiento de Microsoft Purview es útil para procesos de auditoría manuales e investigaciones ocasionales de actividades del usuario.

Defender para aplicaciones en la nube

El portal de Defender for Cloud Apps es un lugar cómodo para ver las actividades y alertas sin necesidad de crear un script para extraer y descargar los datos. También permite ver los datos del registro de actividad de Power BI e inicios de sesión de usuario.

Defender for Cloud Apps incluye una interfaz de usuario para ver y buscar registros de actividad para varios servicios en la nube, incluido Power BI. Muestra los mismos eventos de registro que se originan en el registro de auditoría unificado de Microsoft Purview e incluye otros eventos, como la actividad de inicio de sesión del usuario de Microsoft Entra ID.

Al igual que el portal de cumplimiento de Microsoft Purview (descrito en la sección anterior), Defender for Cloud Apps tiene una interfaz de usuario que permite búsquedas. Sin embargo, las opciones de filtro son diferentes. Además del historial estándar de 30 días, puede usar Defender for Cloud Apps para ver hasta seis meses de historial del registro de actividad (en incrementos de siete días).

Hay requisitos de licencia para acceder a Defender for Cloud Apps. También se requieren permisos independientes.

La interfaz de usuario de Defender for Cloud Apps es útil para los procesos de auditoría manuales y las investigaciones puntuales de las actividades de usuario.

Registro de actividad de Power BI

El registro de actividad de Power BI se origina a partir del registro de auditoría unificado. Solo contiene actividades de usuario relacionadas con el servicio Power BI.

Tiene dos opciones para acceder al registro de actividad de Power BI.

• Llame a la API REST Obtener eventos de actividad mediante la herramienta que prefiera.
• Use el cmdlet de PowerShell Get-PowerBIActivityEvent. Está disponible en el módulo de administrador de administración de Power BI.

Para obtener información sobre qué opción usar, consulte Elección de API o cmdlets de PowerShell, anteriormente en este artículo.

Los datos del registro de actividad de Power BI están disponibles para todos los administradores de Fabric y administradores de Power Platform. Se puede acceder a los datos desde el registro de auditoría unificado, disponible para determinados roles de Exchange Online. Para obtener más información, vea Seguimiento de actividades de usuario en Power BI.

Se recomienda usar el registro de actividad de Power BI cuando solamente pretenda recuperar los registros de auditoría de Power BI.

API de actividad de administración de Office 365

Puede extraer datos del registro de auditoría unificado para otros servicios, como SharePoint Online, Teams, Exchange Online, Dynamics 365 y Power BI. Cuando el objetivo es implementar una solución de auditoría y supervisión para varios servicios, se recomienda usar la API de actividad de administración de Office 365. Dado que esta API devuelve datos de muchos servicios, se conoce como API de auditoría unificada (o el registro de auditoría unificado). Es una de las API de administración de Office 365.

Antes de crear una nueva solución, se recomienda ponerse en contacto con el departamento de TI para determinar si hay registros de auditoría de Power BI existentes disponibles. Es posible que un proceso ya extraiga y almacene los datos. También es posible que obtenga permiso para acceder a estos datos en lugar de crear una nueva solución.

Puede acceder a los datos de dos maneras.

• Llame directamente a la API Actividad de administración de Office 365 mediante la herramienta que prefiera. De forma predeterminada, la API devuelve 24 horas de datos. Puede recuperar un máximo de siete días de historial.
• Use el cmdlet de PowerShell Search-UnifiedAuditLog. Es un cmdlet de PowerShell de Exchange Online. Puede recuperar un máximo de noventa días de historial.

En general, empezar a trabajar con la API Actividad de administración de Office 365 es más difícil que usar el registro de actividad de Power BI (descrito anteriormente). Esto se debe a que la API devuelve blobs de contenido y cada uno de ellos contiene registros de auditoría individuales. En el caso de organizaciones grandes, podría haber miles de blobs de contenido al día. Dado que los clientes y las aplicaciones de terceros hacen un uso intensivo de esta API, Microsoft implementa la limitación para asegurarse de que su uso del servicio no afecta negativamente a otros (conocido como problema de vecino ruidoso). Por lo tanto, recuperar grandes volúmenes de historial puede ser un desafío en organizaciones más grandes. Para obtener más información, consulte el artículo sobre la solución de problemas.

Para usar esta API, debe autenticarse con una entidad de servicio a la que se haya concedido permiso para recuperar datos de la API Actividad de administración de Office 365.

Recuperar los datos de auditoría mediante programación a partir de la API Actividad de administración de Office 365 es una buena opción cuando TI necesita extraer y almacenar registros de auditoría de varios servicios (más allá de Power BI).

Microsoft Sentinel

Microsoft Sentinel es un servicio de Azure que permite recopilar, detectar, e investigar incidentes y amenazas de seguridad y responder a ellos. Puede configurar Power BI en Microsoft Sentinel como conector de datos. Cuando se conecta, los registros de auditoría (que contienen un subconjunto de datos) se transmiten de Power BI a Azure Log Analytics, que es una funcionalidad de Azure Monitor.

Dado que es un servicio de Azure independiente, se debe conceder permisos a cualquier administrador o usuario que desee que ejecute consultas de Lenguaje de consulta Kusto (KQL) en Azure Log Analytics (Azure Monitor). Cuando tienen permiso, pueden consultar los datos de auditoría almacenados en la tabla PowerBIActivity . Sin embargo, tenga en cuenta que, en la mayoría de los casos, concederá a los usuarios acceso a los datos mantenidos en la capa oro en lugar de a los datos sin procesar de la capa bronce.

KQL se usa para analizar los eventos del registro de actividad almacenados en Azure Log Analytics. Si tiene experiencia en SQL, encontrará muchas similitudes con KQL.

Existen varias formas de acceder a los eventos almacenados en Azure Log Analytics. Puede usar:

• La aplicación de plantilla predefinida de Log Analytics para modelos semánticos de Power BI.
• El conector de Power BI Desktop para Azure Data Explorer (Kusto).
• Experiencia de consulta basada en web en Azure Data Explorer.
• Cualquier herramienta de consulta que pueda enviar consultas KQL.

El período del historial que puede recuperar depende de la directiva de retención de datos para el área de trabajo de Azure Log Analytics. Tenga en cuenta el costo y el acceso a los datos sin procesar al decidir la cantidad de datos que deben conservarse.

Microsoft Sentinel y Azure Monitor son buenas opciones cuando TI ya ha realizado una inversión con Microsoft Sentinel, el nivel de detalle capturado satisface sus necesidades y actividades como la detección de amenazas son una prioridad. Sin embargo, como Microsoft Sentinel no captura todos los datos de actividad de Power BI, no admite realizar un análisis exhaustivo del uso y la adopción de Power BI.

Consideraciones sobre los datos de actividad del usuario

Estas son algunas consideraciones que le ayudarán a elegir el origen de los datos de actividad del usuario.

• ¿El proceso de auditoría será manual o automatizado? Las opciones de la interfaz de usuario funcionan bien para los procesos de auditoría manuales y consultas puntuales ocasionales, sobre todo cuando necesita investigar una actividad concreta. También será necesario un proceso de auditoría automatizado que extraiga los datos de actividad del usuario según una programación para respaldar el análisis de los datos históricos.
• ¿Con qué frecuencia necesita los datos de actividad del usuario? En el caso de los procesos de auditoría automatizados, planee extraer datos de al menos un día antes de la fecha actual con la hora universal coordinada (UTC), en lugar de la hora local. Por ejemplo, si el proceso se ejecuta el viernes por la mañana (hora UTC), debe extraer los datos del miércoles. Existen varias razones por las que debe extraer datos con una latencia de un día.
  • Será más sencillo trabajar con los archivos cuando la extracción sea siempre de 24 horas completas cada vez, lo que evita resultados de días parciales.
  • Minimizará el riesgo de que falten algunos eventos de auditoría. Normalmente, los eventos de auditoría tardan 30 minutos en llegar. En algunas ocasiones, ciertos eventos pueden tardar hasta 24 horas en llegar al registro de auditoría unificado.
• ¿Necesita más datos de Power BI? Considere la forma más eficaz de acceder a los datos necesarios.
  • Cuando solo necesite datos de actividad del usuario de Power BI, utilice el registro de actividad de Power BI.
  • Cuando necesite registros de auditoría de varios servicios, use la API de Actividad de administración de Office 365 para acceder al registro de auditoría unificado.
• ¿Quién desarrollará la solución? Planee invertir tiempo en la creación de la solución. Generar un script listo para producción puede resultar difícil.

Lista de comprobación: al planificar cómo acceder a los datos de actividad del usuario, estas son algunas de las decisiones y las acciones clave:

Acceso a los datos del inventario de inquilinos

Un inventario de inquilinos es una parte necesaria y de gran valor en una solución de auditoría y supervisión consolidada. Le ayuda a comprender qué áreas de trabajo y qué contenido (modelos semánticos, informes y otros elementos) existen en Power BI y es un complemento excelente para los datos de actividad del usuario (descritos en la sección anterior). Para obtener más información sobre cómo identificar sus necesidades de datos, consulte Inventario de inquilinos, anteriormente en este artículo.

Las actividades del usuario (descritas anteriormente) son eventos auditados; es un registro de las acciones que un usuario ha realizado en una fecha y una hora específicas. Sin embargo, el inventario de inquilinos es algo distinto. El inventario de inquilinos es una instantánea en un momento dado. Describe el estado actual de todos los elementos publicados en el servicio Power BI en el momento de la extracción.

Para analizar correctamente lo que ocurre en el inquilino de Power BI, necesita tanto los datos de actividad del usuario como el inventario de inquilinos. Combinarlos le permite entender la cantidad de contenido que tiene y dónde se encuentra. También le permite encontrar contenido no utilizado o infrautilizado (porque no habrá ningún evento correspondiente en el registro de actividad). El inventario de inquilinos también le ayuda a compilar una lista de los nombres actuales de todos los elementos, lo cual resulta útil cuando cambian los nombres de elemento.

Para obtener más información sobre el valor del inventario de inquilinos, consulte Inventario de inquilinos, anteriormente en este artículo.

Puede obtener datos del inventario de inquilinos de dos formas distintas.

Técnica	Descripción	Más adecuada para	Buena opción para procesos de auditoría manuales	Buena opción para procesos de auditoría automatizados
Programático	La API Get Groups as Admin o el cmdlet de PowerShell Get-PowerBIWorkspace pueden proporcionar una lista de áreas de trabajo para todo el inquilino. Opcionalmente, se pueden incluir elementos individuales (como modelos semánticos e informes) por área de trabajo.	Organizaciones más pequeñas o volumen de datos bajo
Programático	Un conjunto de API de administración asincrónicas, conocidas colectivamente como API de examen de metadatos o API de escáner, puede devolver una lista de áreas de trabajo y elementos individuales. Opcionalmente, también se pueden incluir metadatos detallados (como tablas, columnas y expresiones de medida).	Organizaciones con un gran volumen de datos o que necesiten obtener resultados detallados

En el resto de esta sección se presenta cada una de las técnicas incluidas en la tabla.

API de grupo o cmdlet de áreas de trabajo

Para recuperar una lista de áreas de trabajo, puede usar una de varias API REST, como la API Get Groups as Admin (con la herramienta de su elección). Los resultados incluyen metadatos adicionales, como la descripción e información sobre si el área de trabajo se almacena en una capacidad Premium.

La API REST Get Groups as Admin incluye el parámetro $expand, de gran utilidad. Este parámetro permite expandir opcionalmente los resultados para que incluyan una lista de los elementos publicados en el área de trabajo (como modelos semánticos e informes). También puede pasar el tipo de datos users al parámetro $expand para incluir los usuarios asignados a un rol de área de trabajo.

Además, puede utilizar el cmdlet de PowerShell Get-PowerBIWorkspace. Proviene del módulo Áreas de trabajo de administración de Power BI. Cuando establece el parámetro -Scope en organization, funciona como la API Get Groups as Admin. El cmdlet también acepta el parámetro -Include (equivalente al parámetro $expand en la API REST) para incluir elementos publicados en el área de trabajo (como modelos semánticos e informes).

Para ayudarle a elegir qué opción debe usar, consulte Elección de API o cmdlets de PowerShell, anteriormente en este artículo.

La API REST Get Groups as Admin o el cmdlet Get-PowerBIWorkspace de PowerShell son más adecuados para los procesos de auditoría manuales y las investigaciones puntuales. Las organizaciones más grandes con un gran volumen de datos suelen encontrar estas opciones difíciles de usar. La API REST y el cmdlet siempre extraen un conjunto completo de datos, por lo que pueden tardar mucho tiempo en ejecutarse. También es probable que las organizaciones más grandes encuentren limitaciones respecto al número de solicitudes permitidas por hora (lo que se conoce como límite, que se establece para proteger el buen estado del servicio). Las API de examen de metadatos (que se describen a continuación) ofrecen una alternativa más fiable y escalable.

API de examen de metadatos

Las API de examen de metadatos, comúnmente denominadas API de escáner, son un conjunto de API que devuelven una lista de áreas de trabajo y sus elementos de Power BI (modelos semánticos, informes y otros). Conceptualmente, proporcionan los mismos datos (y más) que las API de grupos o el cmdlet de área de trabajo, descritos en la sección anterior. Sin embargo, el método que se usa para recuperar los datos es distinto y más adecuado para extraer el inventario de inquilinos.

Existen dos razones principales por las que debería considerar el uso de las API de examen de metadatos en lugar de la API REST Get Groups as Admin o del cmdlet Get-PowerBIWorkspace (descritos anteriormente).

• Extracción de datos incrementales: las API de escáner solo extraen los datos que han cambiado desde la última ejecución. Por el contrario, la API REST Get Groups as Admin y el cmdlet Get-PowerBIWorkspace aplican operaciones sincrónicas que extraen el conjunto de datos completo cada vez que se ejecutan.
• Nivel de detalle más pormenorizado: las API de escáner pueden recuperar detalles pormenorizados (como tablas, columnas y expresiones de medida), siempre que las dos configuraciones de inquilino hayan concedido permiso para metadatos detallados. Por el contrario, el nivel mínimo de detalle disponible con la API REST Get Groups as Admin y el cmdlet Get-PowerBIWorkspace es por tipo de elemento (por ejemplo, una lista de informes en un área de trabajo).

El uso de las API de escáner implica un mayor esfuerzo, ya que debe llamar a una serie de API. Además, se ejecutan como un proceso asincrónico. Un proceso asincrónico se ejecuta en segundo plano, por lo que no tiene que esperar a que finalice. Cuando sea el momento de crear un script listo para producción que se vaya a programar, puede que tenga que colaborar con TI o con un desarrollador.

Esta es la secuencia de pasos que debe seguir el proceso al usar las API de escáner.

1. Iniciar sesión: inicie sesión en el servicio Power BI mediante una cuenta de administrador de Power BI o una entidad de servicio que tenga permiso para ejecutar las API de administrador. Para obtener más información, consulte Determinación del método de autenticación, anteriormente en este artículo.
2. Obtener los identificadores del área de trabajo: envíe una solicitud para recuperar una lista de identificadores de área de trabajo. La primera vez que se ejecuta no se tiene una fecha de modificación, por lo que devolverá una lista completa de áreas de trabajo. Normalmente, pasará la fecha de modificación para recuperar solo las áreas de trabajo que hayan cambiado desde ese momento dado. La fecha de modificación debe estar dentro de los últimos 30 días.
3. Iniciar un examen de metadatos: inicie una llamada para solicitar un examen de la información del área de trabajo; para ello, pase los identificadores del área de trabajo recuperados en el paso 2. Tenga en cuenta que esta es una API POST (en lugar de una API GET, que es más común al recuperar datos de auditoría). Una API POST es una solicitud HTTP que crea o escribe datos para un recurso especificado. Esta consulta especifica el nivel de detalle que se extraerá, como los detalles del origen de datos, el esquema del modelo semántico, las expresiones del modelo semántico o los usuarios. Cuando se envía, la API devuelve un identificador para el examen. También devuelve la fecha y la hora del examen, que debe registrar como fecha de la instantánea.
4. Comprobar el estado del examen: use el identificador del examen obtenido en el paso 3 para recibir el estado del examen. Puede que tenga que llamar a esta API más de una vez. Cuando el estado que se devuelve es Correcto, puede continuar con el paso siguiente. El tiempo que se tarda en examinar depende de la cantidad de datos que solicite.
5. Obtener los resultados: use el identificador de examen obtenido en el paso 3 para conseguir el resultado del examen y extraer los datos. Debe realizar este paso en un plazo de 24 horas después de completar el paso 4. Tenga en cuenta que la marca de tiempo de la instantánea debe correlacionarse con el paso 3 en lugar de con el paso 5 (cuando hay un retraso significativo). De este modo, tendrá una marca de tiempo de instantánea precisa. Guarde los resultados en su ubicación de almacenamiento de datos preferida. Como ya se ha descrito en este artículo, se recomienda almacenar los datos sin procesar en su estado original.
6. Prepararse para el proceso siguiente: registre la marca de tiempo del examen del paso 3 para poder usarla en el paso 2 la próxima vez que ejecute el proceso. De esa forma, solo extraerá los datos que hayan cambiado desde ese momento. En adelante, todas las extracciones de datos posteriores serán cambios incrementales en lugar de instantáneas completas.

Lista de comprobación: al planificar el acceso a los datos del inventario de inquilinos, estas son algunas de las decisiones y las acciones clave:

Acceso a datos de usuario y de grupo

Además de la información de identificación (por ejemplo, una dirección de correo electrónico) incluida en los datos de actividad del usuario, resulta útil recuperar información adicional, como la ubicación o los detalles organizativos. Puede usar Microsoft Graph para recuperar datos sobre los usuarios, los grupos, las entidades de servicio y las licencias. Microsoft Graph consta de un conjunto de API y bibliotecas cliente que permiten recuperar datos de auditoría de una amplia variedad de servicios.

Estos son algunos detalles sobre los objetos de Microsoft Entra a los que puede acceder.

• Usuario: una identidad que existe en Microsoft Entra ID como una cuenta profesional, educativa o de Microsoft. El término usuario del dominio se usa a menudo para describir a los usuarios de la organización, si bien el término formal es nombre principal de usuario (UPN). El valor UPN suele ser igual que la dirección de correo electrónico del usuario (sin embargo, si la dirección cambia, el UPN no lo hace porque es inmutable). También hay un identificador único de Microsoft Graph para cada usuario. Con frecuencia, una cuenta de usuario está asociada a una persona. Algunas organizaciones crean usuarios que son cuentas de servicio, las cuales se usan para actividades automatizadas o tareas administrativas.
• Entidad de servicio: un tipo de identidad diferente, que se aprovisiona al crear un registro de aplicación. Una entidad de servicio está pensada para actividades desatendidas y automatizadas. Para obtener más información, consulte Determinación del método de autenticación, anteriormente en este artículo.
• Grupo: una colección de usuarios y entidades de servicio. Hay varios tipos de grupos que puede usar para simplificar la administración de permisos. Para obtener más información, consulte Estrategia para usar grupos.

Los datos de usuarios y grupos que recupera son una instantánea que describe el estado actual en un momento dado.

Atributos de análisis

En una auditoría de nivel de inquilino de Power BI, puede extraer y almacenar los siguientes atributos de Microsoft Graph.

• Nombre completo de los usuarios: muchos orígenes de datos solo incluyen la dirección de correo electrónico del usuario que ha realizado una actividad o que está asignado a un rol. Use este atributo cuando quiera mostrar el nombre completo (nombre para mostrar) en los informes analíticos. El uso del nombre completo hace que los informes sean más fáciles de usar.
• Otras propiedades de usuario: es posible que otros atributos descriptivos sobre los usuarios estén disponibles en el id. de Microsoft Entra. Entre algunos ejemplos de atributos de perfil de usuario integrados con valor analítico se incluyen el puesto, el departamento, el administrador, la región y la ubicación de la oficina.
• Miembros de un grupo de seguridad: la mayoría de los orígenes de datos proporcionan el nombre de un grupo (por ejemplo, el registro de actividad de Power BI registra que un grupo de seguridad se ha asignado a un rol de área de trabajo). Recuperar la pertenencia a grupos mejora la capacidad de analizar por completo qué hace un usuario individual o a qué tiene acceso.
• Licencias de usuario: es útil analizar qué licencias de usuario se asignan a los usuarios (gratuita, Power BI Pro o Power BI Premium por usuario [PPU]). Estos datos pueden ayudarle a identificar quién no usa la licencia. También le ayuda a analizar todos los usuarios (distintos usuarios con licencia) frente a los usuarios activos (con actividades recientes). Si está pensando en agregar licencias de Power BI Premium o en ampliarlas, se recomienda analizar los datos de licencias de usuario junto con los datos de actividad de usuario para realizar un análisis de costos.
• Miembros de los roles de administrador: puede compilar una lista de los administradores de Power BI (que incluye a los administradores de Power Platform).

Para obtener la referencia autoritativa de la información de licencia de Power BI que puede encontrar en los datos de auditoría de Microsoft Graph, consulte Nombres de productos e identificadores del plan de servicio para licencias.

Estos son algunos otros atributos que podría extraer y almacenar.

• Tipo de usuario: los usuarios son miembros o invitados. Normalmente, los miembros son usuarios internos y los invitados son usuarios externos (B2B). Almacenar el tipo de usuario es útil cuando es necesario analizar las actividades de los usuarios externos.
• Cambios de rol: al realizar una auditoría de seguridad, resulta útil comprender cuándo un usuario cambió los roles de la organización (por ejemplo, cuando se transfieren a otro departamento). De este modo, puede comprobar si su configuración de seguridad de Power BI se ha actualizado o debe actualizarse.
• Usuarios deshabilitados: cuando un usuario abandona la organización, normalmente un administrador deshabilita su cuenta. Puede crear un proceso para comprobar si los usuarios deshabilitados son administradores del área de trabajo o propietarios de modelos semánticos.

Recuperación de datos de usuarios y grupos

Puede recuperar datos sobre usuarios y grupos de diferentes maneras.

Técnica	Descripción	Buena opción para procesos de auditoría manuales	Buena opción para procesos de auditoría automatizados
Manual	Explorador de gráfico
Programático	API y SDK de Microsoft Graph
Programático	Módulo Az de PowerShell

En el resto de esta sección se presenta cada una de las técnicas incluidas en la tabla. Otras técnicas, que están en desuso y que no se deben usar con nuevas soluciones, se describen al final de esta sección.

Explorador de Microsoft Graph

El Probador de Microsoft Graph es una herramienta para desarrolladores que le permite aprender sobre las instancias de Microsoft Graph API. Es una manera sencilla de empezar porque no requiere ninguna otra herramienta ni configuración en la máquina. Puede iniciar sesión para recuperar datos del inquilino o recuperar datos de ejemplo de un inquilino predeterminado.

Puede usar el Probador de Graph para:

• Enviar manualmente una solicitud a una instancia de Microsoft Graph API para comprobar si devuelve la información que desea.
• Ver cómo construir la dirección URL, los encabezados y el cuerpo antes de escribir un script.
• Comprobar los datos de manera informal.
• Determinar qué permisos son necesarios para cada API. También puede proporcionar consentimiento para los nuevos permisos.
• Obtenga fragmentos de código para usar al crear scripts.

Use este vínculo para abrir el Probador de Graph.

API y SDK de Microsoft Graph

Use las instancias de Microsoft Graph API para recuperar datos de usuarios y grupos. También puede usarlas para recuperar datos de servicios como Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook, etc.

Los SDK de Microsoft Graph actúan como contenedores de API sobre las API subyacentes de Microsoft Graph. Un SDK es un kit de desarrollo de software que agrupa herramientas y funcionalidades. Los SDK de Microsoft Graph exponen todo el conjunto de instancias de Microsoft Graph API.

Puede optar por enviar solicitudes directamente a las API. Como alternativa, puede agregar una capa de simplificación usando su lenguaje preferido y uno de los SDK. Para más información, consulte Elección de API o cmdlets de PowerShell.

Los SDK de Microsoft Graph admiten varios lenguajes y también están los módulos de PowerShell de Microsoft Graph . Otros SDK están disponibles para Python, C# y otros lenguajes.

Puede instalar los módulos de Microsoft Graph de PowerShell desde la Galería de PowerShell. Dado que Microsoft Graph funciona con muchos servicios de Microsoft 365, hay muchos módulos de PowerShell que se instalan.

Para la auditoría de nivel de inquilino de Power BI, estos son los módulos de PowerShell más comunes que debe instalar.

• Autenticación (para el inicio de sesión)
• Usuarios
• Grupos
• Aplicaciones (y entidades de servicio)
• Objetos de directorio (y detalles de licencia)

Módulo Az de PowerShell

También puede usar el módulo Az de PowerShell para recuperar datos de usuarios y grupos. Se centra en los recursos de Azure.

Puede usar el cmdlet Invoke-AzRestMethod cuando no haya un cmdlet correspondiente para una API. Se trata de un enfoque flexible que le permite enviar una solicitud a cualquier instancia de Microsoft Graph API mediante el módulo Az de PowerShell.

A partir de la versión 7 de Az, los cmdlets de Az ahora hacen referencia a Microsoft Graph API. Por lo tanto, el módulo Az actúa como contenedor de API sobre Microsoft Graph. Los módulos Az tienen un subconjunto de funcionalidades contenidas en las instancias de Microsoft Graph API y los módulos de PowerShell. Para las nuevas soluciones, se recomienda usar el SDK de PowerShell de Microsoft Graph.

API y módulos en desuso

Puede encontrar artículos y entradas de blog en línea que sugieren opciones alternativas que no se presentan en esta sección. Se recomienda encarecidamente no crear nuevas soluciones (ni migrar las soluciones existentes) mediante cualquiera de las API o módulos siguientes.

• Módulos AzureRM de PowerShell: en desuso y en proceso de retirada. Se han reemplazado por el módulo Az de PowerShell.
• Módulo Graph API de Azure AD y Azure AD de PowerShell: en desuso y en proceso de retirada. Este cambio es el resultado de la migración de Graph de Azure AD a Microsoft Graph (tenga en cuenta que Graph aparece en ambos nombres, pero Microsoft Graph es la dirección futura). Todas las inversiones futuras de PowerShell se realizarán en el SDK de PowerShell de Microsoft Graph.
• Módulo MS Online (MSOL) de PowerShell: en desuso y en proceso de retirada. Todas las inversiones futuras de PowerShell se realizarán en el SDK de PowerShell de Microsoft Graph.

Lista de comprobación: al planear el acceso a los datos de usuarios y grupos, las decisiones y las acciones clave son, entre otras:

Acceso a datos desde las API REST de Power BI

Quizás como prioridad más baja, también puede recuperar otros datos mediante las API REST de Power BI.

Por ejemplo, puede recuperar datos sobre:

• Todas las aplicaciones de la organización.
• Todos los modelos semánticos importados de la organización.
• Todas las canalizaciones de implementación de la organización.
• Todas las capacidades Premium de la organización.

Durante una auditoría de seguridad, es posible que desee identificar:

• Elementos que se han compartido ampliamente con toda la organización.
• Elementos que están disponibles en la red pública de Internet mediante la publicación en la web.

Para obtener más información sobre los otros tipos de API, consulte Elección de una API de usuario o una API de administrador en un punto anterior de este artículo.

Lista de comprobación: al planear el acceso a datos desde las API de Power BI, las decisiones clave y las acciones son, entre otras:

Fase 2: Requisitos previos y configuración

La segunda fase de planeamiento e implementación de una solución de auditoría de nivel de inquilino se centra en los requisitos previos y la configuración que se deben realizar antes de comenzar el desarrollo de soluciones.

Crear cuenta de almacenamiento

En este momento, ha decidido una ubicación para almacenar datos sin procesar y cómo crear datos mantenidos. En función de esas decisiones, ya lo tiene todo listo para crear una cuenta de almacenamiento. En función de los procesos de la organización, podría implicar el envío de una solicitud a TI.

Como se ha descrito anteriormente, se recomienda usar una tecnología que le permita escribir los datos sin procesar en un almacenamiento inmutable. Una vez escritos los datos, no se pueden cambiar ni eliminar. A continuación, puede tener confianza en los datos sin procesar porque sabe que un administrador con acceso no puede modificarlos de ninguna manera. Sin embargo, los datos mantenidos no necesitan almacenarse (normalmente) en un almacenamiento inmutable. Los datos mantenidos pueden cambiar o se pueden volver a generar.

Lista de comprobación: al crear una cuenta de almacenamiento, las decisiones clave y las acciones son, entre otras:

Instalación del software y configuración de recursos

En este momento, ha tomado sus decisiones sobre qué tecnología usar para acceder a los datos de auditoría. En función de esas decisiones, ya está listo para instalar software y configurar servicios.

Configure el entorno de desarrollo preferido para cada administrador. El entorno de desarrollo les permitirá escribir y probar scripts. Visual Studio Code es una herramienta moderna para desarrollar scripts, por lo que es una buena opción. Además, hay muchas extensiones disponibles para trabajar con Visual Studio Code.

Si ha tomado la decisión (descrita anteriormente) de usar PowerShell, debe instalar PowerShell Core y los módulos de PowerShell necesarios en:

• La máquina de cada administrador o desarrollador que escribirá o probará scripts de auditoría.
• Cada máquina virtual o servidor que ejecutará scripts programados.
• Cada servicio en línea (como Azure Functions o Azure Automation).

Si ha elegido usar cualquier servicio de Azure (como Azure Functions, Azure Automation, Azure Data Factory o Azure Synapse Analytics), debe aprovisionarlos y configurarlos también.

Lista de comprobación: al instalar software y configurar servicios, las decisiones clave y las acciones incluyen:

Registro de una aplicación de Microsoft Entra

En este momento, ha decidido cómo autenticarse. Se recomienda registrar una aplicación de Microsoft Entra (entidad de servicio). Normalmente se conoce como registro de aplicaciones, se debe usar para las operaciones desatendidas que automatizará.

Para obtener más información sobre cómo crear un registro de aplicación para recuperar datos de auditoría de nivel de inquilino, consulte Habilitación de la autenticación de entidad de servicio para las API de administración de solo lectura.

Lista de comprobación: al identificar las necesidades de integración de Microsoft Entra, las decisiones y acciones clave son, entre otras:

Definición de la configuración de un inquilino de Power BI

Hay varias opciones de configuración de inquilino en el portal de administración de Power BI que son relevantes para extraer datos de auditoría de nivel de inquilino.

API de Administración

Hay tres configuraciones de inquilino que son relevantes para ejecutar las API de administración.

La configuración Concesión de permisos a las entidades de servicio para utilizar las API de administración de Power BI de solo lectura le permite establecer qué entidades de servicio pueden llamar a las API de administración. Esta configuración también permite a Microsoft Purview examinar todo el inquilino de Power BI para que pueda rellenar el catálogo de datos.

La configuración de inquilino Mejorar las respuestas de la API de administración con la configuración detallada le permite establecer qué usuarios y entidades de servicio pueden recuperar metadatos detallados. Los metadatos se recuperan mediante las API de examen de metadatos e incluye tablas, columnas y mucho más. Esta configuración también permite que Microsoft Purview acceda a información de nivel de esquema sobre los modelos semánticos de Power BI para que pueda almacenarla en el catálogo de datos.

La configuración de inquilino Mejorar las respuestas de la API de administración con DAX y expresiones mashup permite establecer qué usuarios y entidades de servicio pueden recuperar metadatos detallados. Los metadatos se recuperan de las API de examen de metadatos y pueden incluir consultas y expresiones de medida del modelo semántico.

API de usuario

Hay una configuración de inquilino que se aplica a las API de usuario de llamada. En esta situación, también se requieren permisos de Power BI para la entidad de servicio (por ejemplo, un rol de área de trabajo).

La configuración de inquilino Concesión de permisos a las entidades de servicio para utilizar las API de Power BI permite establecer qué entidades de servicio tienen acceso para ejecutar las API REST (excepto las API de administración, que se conceden mediante una configuración de inquilino diferente, descrita anteriormente).

Hay otras configuraciones de inquilino relacionadas con las API, que permiten el acceso a las API de inserción, las API de streaming, las API de exportación y la API de ejecución de consultas. Sin embargo, estas API están fuera del ámbito de este artículo.

Para más información sobre la configuración de inquilino con respecto a las métricas de uso, consulte Auditoría de nivel de informe.

Lista de comprobación: al realizar la configuración de inquilino de Power BI, algunas de las decisiones y acciones más importantes son:

Fase 3: Desarrollo y análisis de soluciones

La tercera fase de planeamiento e implementación de una solución de auditoría de nivel de inquilino se centra en el desarrollo y el análisis de soluciones. En este momento, se ha realizado el planeamiento y la toma de decisiones, ha satisfecho los requisitos previos y ha finalizado la configuración. Ya está listo para comenzar el desarrollo de una solución que le permita realizar análisis y extraer información de sus datos de auditoría.

Extracción y almacenamiento de los datos sin procesar

En este momento, sus requisitos y prioridades deben ser claros. Se han tomado decisiones técnicas clave sobre cómo acceder a los datos de auditoría y a la ubicación para almacenar los datos de auditoría. Se han seleccionado las herramientas preferidas y se han configurado los requisitos previos y las opciones. Durante las dos fases anteriores, es posible que haya realizado uno o varios proyectos pequeños (pruebas de concepto) para demostrar la viabilidad. El siguiente paso consiste en configurar un proceso para extraer y almacenar los datos de auditoría sin procesar.

Al igual que con los datos devueltos por la mayoría de las API de Microsoft, los datos de auditoría tienen el formato JSON. Los datos con formato JSON se describen automáticamente porque es texto legible para el usuario que contiene estructura y datos.

JSON representa objetos de datos que constan de pares de atributo-valor y matrices. Por ejemplo, "state": "Active" es un ejemplo en el que el valor del atributo state es Activo. Una matriz JSON contiene una lista ordenada de elementos separados por una coma que se incluyen entre corchetes ([ ]). Es habitual encontrar matrices anidadas en los resultados JSON. Cuando esté familiarizado con la estructura jerárquica de un resultado JSON, es sencillo comprender la estructura de datos, como una lista (matriz) de modelos semánticos de un área de trabajo.

Estas son algunas consideraciones que debe tener en cuenta al extraer y almacenar los datos sin procesar recuperados de las API.

• ¿Qué convención de nomenclatura se usará? En el caso de un sistema basado en archivos, se necesita una convención de nomenclatura para archivos, carpetas y zonas de lago de datos. Para una base de datos, se necesita una convención de nomenclatura para tablas y columnas.
• ¿Qué formato se usará para almacenar los datos sin procesar? A medida que Power BI siga introduciendo nuevas características, aparecerán nuevas actividades que no existen actualmente. Por este motivo, se recomienda extraer y conservar los resultados JSON originales. No analice, filtre ni aplique formato a los datos mientras se extraen. De este modo, puede usar los datos sin procesar originales para regenerar los datos de auditoría mantenidos.
• ¿Qué ubicación de almacenamiento se usará? Normalmente, se usa un lago de datos o un almacenamiento de blobs para almacenar datos sin procesar. Para más información, consulte Determinación de dónde almacenar los datos de auditoría anteriormente en este artículo.
• ¿Cuánto historial se almacenará? Exporte los datos de auditoría a una ubicación donde pueda almacenar el historial. Planee acumular al menos un historial de dos años. De este modo, puede analizar tendencias y cambios más allá del período de retención predeterminado de 30 días. Puede optar por almacenar los datos indefinidamente, o puede decidir un período más corto, en función de las directivas de retención de datos de su organización.
• ¿Cómo va a saber cuándo se ejecutó el proceso por última vez? Prepare un archivo de configuración, o equivalente, para registrar las marcas de tiempo de inicio y finalización de un proceso. La próxima vez que se ejecute el proceso, puede recuperar estas marcas de tiempo. Es especialmente importante almacenar marcas de tiempo al extraer datos mediante las API de examen de metadatos.
• ¿Cómo se controlará la limitación? Algunas API REST de Power BI y Microsoft Graph API implementan la limitación. Si la solicitud de API está limitada, recibirá un error 429 (demasiadas solicitudes). La limitación puede ser un problema común en organizaciones más grandes que necesitan recuperar un gran volumen de datos. La forma de evitar los intentos erróneos debido a la limitación depende de la tecnología que use para acceder a los datos y extraerlos. Una opción es desarrollar lógica en los scripts que responda a un error 429 "Demasiadas solicitudes" reintentándolo después de un período de espera.
• ¿Son necesarios los datos de auditoría para el cumplimiento? Muchas organizaciones usan las entadas del registro de auditoría sin procesar para realizar auditorías de cumplimiento o responder a investigaciones de seguridad. En estos casos, se recomienda encarecidamente almacenar los datos sin procesar en almacenamiento inmutable. De este modo, una vez escritos los datos, el administrador u otro usuario no pueden cambiarlos ni eliminarlos.
• ¿Qué capas de almacenamiento son necesarias para respaldar sus requisitos? Los mejores lugares para almacenar datos sin procesar son un lago de datos (como Azure Data Lake Storage Gen2) o almacenamiento de objetos (como Azure Blob Storage). También se puede usar un sistema de archivos si los servicios en la nube no son una opción.

Lista de comprobación: al extraer y almacenar los datos sin procesar, algunas de las decisiones y acciones más importantes son:

Para más información sobre cómo una solución de auditoría y supervisión crece con el tiempo, consulte Operacionalización y mejora más adelante en este artículo.

Creación de los datos mantenidos

En este momento, los datos sin procesar se han extraído y almacenado. El siguiente paso consiste en crear una capa de datos oro independiente para los datos mantenidos. Su objetivo es transformar y almacenar los archivos de datos en un esquema en estrella. Un esquema en estrella consta de tablas de dimensiones y de hechos, y está optimizado intencionadamente para el análisis y la generación de informes. Los archivos de la capa de datos mantenidos se convierten en el origen de un modelo de datos de Power BI (que se describe en el tema siguiente).

Lista de comprobación: al crear la capa de datos mantenidos, algunas de las decisiones y acciones más importantes son:

Creación de un modelo de datos

El tema trata sobre cómo configurar un modelo de datos analítico. Un modelo de datos es un recurso de datos con capacidad de consulta que está optimizado para el análisis. A veces se conoce como modelo semántico o simplemente modelo. Para la solución de auditoría y supervisión, es probable que el modelo de datos se implemente como un modelo semántico de Power BI.

En el contexto de auditoría y supervisión, un modelo de datos origina datos a partir de la capa de datos (oro) mantenida. Si decide no crear una capa de datos mantenida, el modelo de datos origina sus datos directamente desde los datos sin procesar.

Se recomienda que el modelo de datos de Power BI implemente un diseño de esquema de estrella. Cuando los datos de origen están en la capa de datos mantenida, el esquema de estrella del modelo de datos de Power BI debe reflejar el esquema de estrella de la capa de datos mantenida.

Al igual que con cualquier proyecto de Power BI, la creación de un modelo de datos es un proceso iterativo. Puede agregar nuevas medidas según sea necesario. También puede agregar nuevas tablas y columnas a medida que haya nuevos eventos de auditoría disponibles. Con el tiempo, puede incluso integrar nuevos orígenes de datos.

Estas son algunas tablas de dimensiones útiles que puede incluir en el modelo de datos.

• Fecha: un conjunto de atributos de fecha para habilitar el análisis (segmentación y fragmentación) de datos por día, semana, mes, trimestre, año y otros períodos de tiempo pertinentes.
• Hora: si necesita analizar por hora del día y tiene un gran volumen de datos de auditoría, considere la posibilidad de almacenar la parte de la hora por separado del día. Este enfoque puede ayudar a mejorar el rendimiento de las consultas.
• Usuarios: atributos que describen a los usuarios (como el departamento y la región geográfica) que pueden filtrar muchos temas de datos de auditoría. El objetivo es quitar todos los detalles del usuario de las tablas de hechos y almacenarlos en esta tabla de dimensiones para que puedan filtrar muchas tablas de hechos. También puedes almacenar entidades de servicio en esta tabla.
• Eventos de actividad: atributos que agrupan y describen los eventos de actividad (operaciones). Para mejorar los informes, puede crear un diccionario de datos que describa cada evento de actividad. También puede crear una jerarquía que agrupe y clasifique eventos de actividad similares. Por ejemplo, puede agrupar todos los eventos de creación de elementos, eliminar eventos, etc.
• Áreas de trabajo: una lista de áreas de trabajo en las propiedades de inquilino y área de trabajo, como el tipo (personal o estándar) y la descripción. Algunas organizaciones registran más detalles sobre las áreas de trabajo (posiblemente mediante una lista de SharePoint). Puede integrar estos detalles en esta tabla de dimensiones. Debe decidir si esta tabla de dimensiones almacena solo el estado actual del área de trabajo o si almacena los datos con versiones que reflejan cambios significativos en el área de trabajo a lo largo del tiempo. Por ejemplo, cuando cambia un nombre de área de trabajo, ¿los informes históricos muestran el nombre del área de trabajo actual o el nombre del área de trabajo que tenía en aquel momento? Para obtener más información sobre el control de versiones, consulte Dimensiones de variación lenta.
• Tipos de elementos: lista de tipos de elementos de Power BI (modelos semánticos, informes y otros).
• Capacidades: lista de capacidades Prémium en el inquilino.
• Puertas de enlace: lista de puertas de enlace de datos en el inquilino.
• Orígenes de datos: lista de orígenes de datos utilizados por cualquier modelo semántico, flujo de datos o datamart.

Estas son algunas tablas de hechos (temas) útiles que puede incluir en el modelo de datos.

• Actividades del usuario: datos de hechos que proceden de los datos JSON originales. Se quitan todos los atributos que no tienen ningún valor analítico. También se quitan todos los atributos que pertenecen a las tablas de dimensiones (anteriores).
• Inventario del inquilino: instantánea a un momento dado de todos los elementos publicados en el inquilino. Para obtener más información, consulte Inventario del inquilino más arriba en este artículo.
• Modelos semánticos: incluye actividades de usuario que implican modelos semánticos (como cambios de modelo semántico) u orígenes de datos relacionados.
• Actualizaciones del modelo semántico: amacena las operaciones de actualización de datos, incluidos los detalles sobre el tipo (programado o a petición), la duración, el estado y el usuario que inició la operación.
• Roles de área de trabajo: instantánea a un momento dado de las asignaciones de roles del área de trabajo.
• Licencias de usuario: instantánea a un momento dado de las licencias de usuario. Aunque es posible que tenga la tentación de almacenar la licencia de usuario en la tabla de dimensiones Usuarios, ese enfoque no admitirá el análisis de cambios y tendencias de licencia a lo largo del tiempo.
• Pertenencias a grupos de usuarios: instantánea a un momento dado de los usuarios (y entidades de servicio) asignadas a un grupo de seguridad.
• Actividades de la comunidad: incluye hechos relacionados con la comunidad, como eventos de entrenamiento. Por ejemplo, podría analizar las actividades de usuario de Power BI en comparación con la asistencia al entrenamiento. Estos datos podrían ayudar al Centro de excelencia a identificar nuevos campeones potenciales.

Las tablas de hechos no deben incluir columnas que los creadores de informes filtrarán. En su lugar, esas columnas pertenecen a tablas de dimensiones relacionadas. Este diseño no solo es más eficaz para las consultas, sino que también promueve la reutilización de tablas de dimensiones por varios hechos (conocidos como obtención de detalles). Este último punto es importante para generar un modelo de datos útil y fácil de usar que es extensible al agregar nuevas tablas de hechos (temas).

Por ejemplo, la tabla de dimensiones Usuarios estará relacionada con cada tabla de hechos. Debe estar relacionada con la tabla de hechos Actividades del usuario (que realizó la actividad), la tabla de hechos Inventario del inquilino (que creó el elemento publicado) y todas las demás tablas de hechos. Cuando un informe filtra por un usuario en la tabla de dimensiones Usuarios, los objetos visuales de ese informe pueden mostrar hechos para ese usuario desde cualquier tabla de hechos relacionada.

Al diseñar el modelo, asegúrese de que un atributo está visible una vez, y solo una vez, en el modelo. Por ejemplo, la dirección de correo electrónico del usuario solo debe estar visible en la tabla de dimensiones Usuarios. También existirá en otras tablas de hechos (como clave de dimensión para admitir una relación de modelo). Sin embargo, debe ocultarla en cada tabla de hechos.

Se recomienda crear el modelo de datos independiente de los informes. El hecho de desacoplar un modelo semántico y sus informes provoca un modelo semántico centralizado que puede dar servicio a muchos informes. Para más información sobre la utilización de un modelo semántico compartido, consulte el escenario de uso BI con características de autoservicio administrado.

Considere la posibilidad de configurar la seguridad de nivel de fila (RLS) para que otros usuarios (más allá del Centro de excelencia, auditores y administradores) puedan analizar los datos de auditoría e informar sobre ellos. Por ejemplo, podría usar reglas de RLS para permitir que los creadores y consumidores de contenido informen sobre sus propias actividades de usuario o esfuerzos de desarrollo.

Lista de comprobación: al crear el modelo de datos, las decisiones y acciones clave incluyen:

Mejorar el modelo de datos

Para analizar eficazmente el uso de contenido y las actividades de usuario, se recomienda enriquecer el modelo de datos. Las mejoras del modelo de datos se pueden realizar de forma gradual e iterativa a lo largo del tiempo a medida que detecta oportunidades y nuevos requisitos.

Creación de clasificaciones

Una manera de mejorar el modelo y aumentar el valor de los datos es agregar clasificaciones al modelo de datos. Asegúrese de que los informes usan estas clasificaciones de forma coherente.

Puede optar por clasificar usuarios o contenido en función de su nivel de uso.

Clasificación por uso de los usuarios

Tenga en cuenta las siguientes clasificaciones por uso de los usuarios.

• Usuario frecuente: actividad registrada en la última semana y en nueve de los últimos 12 meses.
• Usuario activo: actividad registrada en el último mes.
• Usuario ocasional: actividad registrada en los últimos nueve meses, pero sin actividad en el último mes.
• Usuario inactivo: no se registró ninguna actividad en los últimos nueve meses.

Clasificación por uso del contenido

Tenga en cuenta las siguientes clasificaciones por uso del contenido.

• Contenido usado frecuentemente: actividad registrada en la última semana y en nueve de los últimos 12 meses.
• Contenido usado activamente: actividad registrada en el último mes.
• Contenido usado ocasionalmente: actividad registrada en los últimos nueve meses, pero sin actividad en el último mes.
• Contenido no utilizado: no se registró ninguna actividad en los últimos nueve meses.

Clasificación por el tipo de usuario

Tenga en cuenta las siguientes clasificaciones por el tipo de usuario.

• Creador de contenido: actividad registrada en los últimos seis meses en la que se creó, publicó o editó contenido.
• Visor de contenido: actividad registrada en los últimos seis meses en la que se vio contenido, pero sin ninguna actividad de creación de contenido.

Consideración de inmediatez frente a tendencias

Debe decidir si las clasificaciones por uso de los usuarios o el contenido solamente deben basarse en la inmediatez en que se produjo una actividad . Es posible que también quiera considerar la posibilidad de factorizar el uso promedio o de tendencia a lo largo del tiempo.

Tenga en cuenta algunos ejemplos que muestran cómo la lógica de clasificación simple podría falsear la realidad.

• Un administrador ha visto un informe esta semana. Sin embargo, antes de esa semana, el administrador no había visto ningún informe en los últimos seis meses. Basándose en el uso reciente por sí solo, no debe considerar que este administrador sea un usuario frecuente.
• Un creador de informes publica un nuevo informe cada semana. Al analizar el uso por parte de usuarios frecuentes, la actividad normal del creador del informe parece ser positiva. Sin embargo, tras una investigación adicional, descubre que este usuario ha vuelto a publicar un nuevo informe (con un nuevo nombre de informe) cada vez que edita el informe. Sería útil que el creador del informe entrene más.
• Un ejecutivo visualiza un informe esporádicamente, por lo que su clasificación por uso cambia con frecuencia. Es posible que se tengan que analizar determinados tipos de usuarios, como ejecutivos, de forma diferente.
• Un auditor interno visualiza informes críticos una vez al año. Es posible que el auditor interno parezca ser un usuario inactivo debido a su uso poco frecuente. Alguien podría tomar medidas para eliminar su licencia Pro o PPU. O bien, alguien podría creer que un informe debe retirarse, ya que se usa con poca frecuencia.

Lista de comprobación: al crear la clasificación de datos por uso, las decisiones y acciones clave incluyen:

Creación de informes analíticos

En este momento, los datos de auditoría se han extraído y almacenado, y ha publicado un modelo de datos. El paso siguiente consiste en crear informes analíticos.

Céntrese en la información clave que resulte más relevante para cada audiencia. Es posible que tenga varias audiencias para los informes de auditoría. Cada audiencia estará interesada en información diferente y con fines diferentes. Entre las audiencias que puede servir con los informes se incluyen:

• Patrocinador ejecutivo
• Centro de excelencia
• Administradores de Power BI
• Administradores del área de trabajo
• Administradores de capacidad Prémium
• Administradores de puerta de enlace
• Desarrolladores y creadores de contenido de Power BI
• Auditores

Estos son algunos de los requisitos analíticos más comunes con los que puede empezar al crear los informes de auditoría.

• Vistas de contenido principales: el patrocinador ejecutivo y los equipos de liderazgo podrían estar interesados principalmente en la información resumida y las tendencias a lo largo del tiempo. Los administradores del área de trabajo, los desarrolladores y los creadores de contenido estarán más interesados en los detalles.
• Actividades de usuario principales: su Centro de excelencia estará interesado en quién usa Power BI, cómo y cuándo. Los administradores con capacidad Prémium estarán interesados en quién usa la capacidad para garantizar su estado y estabilidad.
• Inventario de inquilinos: los administradores de Power BI, los administradores del área de trabajo y los auditores estarán interesados en comprender qué contenido existe, dónde, el linaje y su configuración de seguridad.

Esta lista no incluye todo. Está pensada para proporcionarle ideas sobre cómo crear informes analíticos que tienen como destino necesidades específicas. Para obtener más consideraciones, consulte Necesidades de datos anteriormente en este artículo e Información general sobre auditoría y supervisión. Estos recursos incluyen muchas ideas sobre cómo puede usar los datos de auditoría y los tipos de información que puede optar por presentar en los informes.

Lista de comprobación: al planear los informes de auditoría analíticos, las decisiones y acciones clave incluyen:

Toma de medidas en función de los datos

La auditoría de datos es valiosa porque ayuda a comprender lo que sucede en el inquilino de Power BI. Aunque puede parecer obvio, actuar explícitamente sobre lo que aprende a partir de los datos de auditoría se puede pasar por alto fácilmente. Por ese motivo, se recomienda asignar a alguien que tenga la responsabilidad de realizar el seguimiento de mejoras medibles, en lugar de simplemente revisar los informes de auditoría. De este modo, puede realizar avances graduales y medibles en la adopción y el nivel de madurez con Power BI.

Puede realizar muchas acciones diferentes en función de sus objetivos y de lo que aprenda a partir de los datos de auditoría. En el resto de esta sección se proporcionan varias ideas.

Uso del contenido

Estas son algunas acciones que puede realizar en función de cómo se usa el contenido.

• El contenido se usa con frecuencia (diaria o semanalmente): compruebe que cualquier contenido crítico está certificado. Confirme que la propiedad es clara y que la solución se admite de forma adecuada.
• Número elevado de vistas del área de trabajo: cuando se produzca un gran número de vistas de área de trabajo, investigue por qué las aplicaciones de Power BI no están en uso.
• El contenido rara vez se usa: póngase en contacto con los usuarios de destino para determinar si la solución satisface sus necesidades o si han cambiado los requisitos.
• La actividad de actualización se produce con más frecuencia que las vistas: póngase en contacto con el propietario del contenido para comprender por qué un modelo semántico se actualiza periódicamente sin ningún uso reciente del modelo semántico o de los informes relacionados.

Actividades del usuario

Estas son algunas acciones que puede realizar en función de las actividades del usuario.

• Primera acción de publicación por parte de un nuevo usuario: identifique cuándo un tipo de usuario cambia de consumidor a creador, lo que puede identificar al publicar contenido por primera vez. Es una gran oportunidad para enviarles un correo electrónico estándar que proporcione instrucciones y vínculos a recursos útiles.
• Involucración con los creadores de contenido más frecuentes: invite a sus creadores más activos a unirse a su red de campeones o a involucrarse con su comunidad de práctica.
• Administración de licencias: compruebe si los creadores inactivos todavía necesitan una licencia Pro o PPU.
• Activación de prueba del usuario: una activación de licencia de evaluación puede solicitarle que asigne una licencia permanente al usuario antes de que finalice su evaluación.

Oportunidades de entrenamiento para el usuario

Estas son algunas oportunidades de entrenamiento para el usuario que puede identificar a partir de los datos de auditoría.

• Gran número de modelos semánticos publicados por el mismo creador de contenido: enseñe a los usuarios sobre modelos semánticos compartidos y por qué es importante evitar la creación de modelos semánticos duplicados.
• Uso compartido excesivo desde un área de trabajo personal: póngase en contacto con un usuario que utilice en exceso el uso compartido desde su área de trabajo personal. Enséñele sobre áreas de trabajo estándar.
• Vistas de informes significativas de un área de trabajo personal: póngase en contacto con un usuario que posea contenido que tenga un gran número de vistas de informe. Enséñele cómo las áreas de trabajo estándar son mejores que las áreas de trabajo personales.

Seguridad

Estas son algunas situaciones de seguridad que podría supervisar activamente.

• Demasiados usuarios asignados al rol de administrador de alto privilegio Fabric.
• Demasiados administradores del área de trabajo (cuando el rol de área de trabajo Miembro, Colaborador o Visor sería suficiente).
• Permisos de compilación excesivos asignados a modelos semánticos (cuando el permiso de lectura sería suficiente).
• Uso elevado de permisos por elemento, cuando los permisos de la aplicación de Power BI o el rol Visor del área de trabajo serían una mejor opción para los consumidores de contenido.
• Cómo se comparte el contenido con usuarios externos.

Para obtener más información, consulte los artículos Planeamiento de la seguridad.

Gobernanza y mitigación de riesgos

Estas son algunas situaciones que podría encontrar. Considere la posibilidad de buscar explícitamente estos tipos de situaciones en los informes de auditoría, para estar preparado para actuar rápidamente.

• Número elevado de vistas para informes (y modelos semánticos subyacentes) que no están aprobados.
• Uso significativo de orígenes de datos desconocidos o no autorizados.
• Ubicaciones de archivos que no se alinean con las directrices de gobernanza sobre dónde se deben ubicar los archivos de origen.
• Los nombres de área de trabajo no se alinean con los requisitos de gobernanza.
• Se usan etiquetas de confidencialidad para la protección de la información.
• Errores de actualización de datos coherentes.
• Uso importante y periódico de la impresión.
• Uso inesperado o excesivo de suscripciones.
• Uso inesperado de puertas de enlace personales.

Las acciones específicas que se realizarán en cada situación dependerán de las directivas de gobernanza. Para más información, consulte Gobernanza en la hoja de ruta de adopción de Fabric.

Lista de comprobación: al planear posibles acciones basadas en los datos de auditoría, las decisiones y acciones clave incluyen:

Fase 4: Planeamiento y decisiones

La cuarta fase de planeamiento e implementación de una solución de auditoría de nivel de inquilino se centra en el mantenimiento, las mejoras y la supervisión. En este momento, la solución de auditoría está en uso de producción. Ahora le preocupa principalmente mantener, mejorar y supervisar la solución.

Operacionalización y mejora

Normalmente, los procesos de auditoría se consideran que se ejecutan en producción cuando se completan las pruebas y el desarrollo iniciales y se ha automatizado el proceso. Los procesos de auditoría automatizados que se ejecutan en producción tienen mayores expectativas (que los procesos manuales) para la calidad, la confiabilidad, la estabilidad y el soporte técnico.

Se ha operacionalizado un proceso de auditoría de nivel de producción. Una solución operacionalizada suele incluir muchas de las siguientes características.

• Seguridad: las credenciales se almacenan y administran de forma segura. Los scripts no contienen contraseñas ni claves en texto sin formato.
• Programación: hay un sistema de programación confiable.
• Administración de cambios: el uso de prácticas de administración de cambios y varios entornos se emplean para asegurarse de que el entorno de producción está protegido. También puede trabajar con entornos de desarrollo y pruebas, o simplemente con un entorno de desarrollo.
• Compatibilidad: el equipo que admite la solución está claramente definido. Los miembros del equipo han recibido entrenamiento y comprenden las expectativas operativas. Los miembros de copia de seguridad se han identificado y el entrenamiento cruzado se produce cuando corresponde.
• Alertas: cuando algo va mal, las alertas notifican automáticamente al equipo de soporte técnico. Preferiblemente, las alertas incluyen registros y correo electrónico (en lugar de solo correo electrónico). Un registro es útil para analizar los errores y las advertencias registrados.
• Registro: los procesos se registran para que haya un historial de cuándo se actualizaron los datos de auditoría. La información registrada debe registrar la hora de inicio, la hora de finalización y la identidad del usuario o la aplicación que ejecutó el proceso.
• Control de errores: los scripts y los procesos controlan y registran los errores eficazmente (por ejemplo, salir inmediatamente, continuar o esperar e intentarlo de nuevo). Las notificaciones de alerta se envían al equipo de soporte técnico cuando se produce un error.
• Estándares de codificación: se usan buenas técnicas de codificación que funcionan bien. Por ejemplo, los bucles se evitan intencionadamente, excepto cuando es necesario. Se usan estándares de codificación, comentarios, formato y sintaxis coherentes para que la solución las tareas de mantenimiento y soporte técnico en la aplicación resulten sencillas.
• Reutilización y modularización: para minimizar la duplicación, el código y los valores de configuración (como cadenas de conexión o direcciones de correo electrónico para las notificaciones) se modularizan para que otros scripts y procesos puedan reutilizarlos.

Lista de comprobación: al planear la operacionalización y mejorar una solución de auditoría, las decisiones y acciones clave incluyen:

Documentación y soporte técnico

La documentación y el soporte técnico son fundamentales para cualquier solución de nivel de producción. Resulta útil crear varios tipos de documentación, en función de la audiencia de destino y la finalidad.

Documentación técnica

La documentación técnica está dirigida al equipo técnico que creó la solución y que mejorará y ampliará gradualmente esta a lo largo del tiempo. También es un recurso útil para el equipo de soporte técnico.

La documentación técnica debe incluir:

• Un resumen de los componentes y requisitos previos de la arquitectura.
• Quién posee y administra el contenido.
• Quién proporciona soporte técnico para la solución.
• Un diagrama de arquitectura.
• Decisiones de diseño, incluidos objetivos, motivos por los que se tomaron ciertas decisiones técnicas y restricciones (como el costo o las aptitudes).
• Decisiones y opciones de seguridad.
• Convenciones de nomenclatura usadas.
• Estándares y pautas técnicas y de codificación.
• Requisitos de administración de cambios.
• Instrucciones de implementación, configuración e instalación.
• Áreas conocidas de deuda técnica (áreas que se pueden mejorar si hay oportunidad de hacerlo).

Documentación de soporte técnico

En función del nivel de importancia de la solución de auditoría, es posible que tenga un servicio de asistencia o un equipo de soporte técnico que deba poner de manifiesto incidencias urgentes. Es posible que estén disponibles todo el día y todos los días.

La documentación de soporte técnico a veces se conoce como knowledge base o un runbook. Esta documentación está dirigida al equipo de asistencia técnica o soporte técnico y debe incluir:

• Guía de solución de problemas para cuando algo va mal. Por ejemplo, cuando se produce un error de actualización de datos.
• Acciones que se deben realizar de forma continuada. Por ejemplo, podría haber algunos pasos manuales que alguien necesita realizar regularmente hasta que se resuelva un problema.

Documentación del creador de contenido

Se deriva más valor de la solución de auditoría proporcionando análisis de uso y adopción a otros equipos de toda la organización (con seguridad de nivel de fila aplicada, si es necesario).

La documentación del creador de contenido está dirigida a creadores de contenido de autoservicio que crean informes y modelos de datos que generan los datos de auditoría mantenidos. Incluye información sobre el modelo de datos, así como las definiciones de datos comunes.

Lista de comprobación: al planear documentación y el soporte técnico para la solución de auditoría, las decisiones y acciones clave incluyen:

Habilitación de alertas

Es posible que desee generar alertas basadas en condiciones específicas en los datos de auditoría. Por ejemplo, puede generar una alerta cuando alguien elimina una puerta de enlace o cuando un administrador de Power BI cambia una configuración de inquilino.

Para más información, vea Auditoría de nivel de inquilino.

Administración continua

Debe realizar la administración continua de toda la solución de auditoría. Es posible que tenga que ampliar o cambiar la solución de auditoría cuando:

• La organización detecta nuevos requisitos de datos.
• Los nuevos eventos de auditoría aparecen en los datos sin procesar exactos de las API REST de Power BI.
• Microsoft realiza cambios en las API REST de Power BI.
• Los empleados identifican formas de mejorar la solución.

Lista de comprobación: al planear la administración continua de la solución de auditoría, estas son las principales decisiones y acciones que debe adoptar:

Contenido relacionado

En el siguiente artículo de esta serie, obtendrá información sobre la supervisión de nivel de inquilino.