Share via

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

  • Artículo

Nota

Este artículo forma parte de la serie de artículos sobre el planeamiento de la implementación de Power BI. Esta serie se centra principalmente en la carga de trabajo de Power BI dentro de Microsoft Fabric. Para acceder a una introducción a la serie, consulte el planeamiento de la implementación de Power BI.

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.

Importante

Se recomienda seguir detenidamente el plan de lanzamiento de Power BI para obtener información sobre las futuras mejoras de las funcionalidades de auditoría y supervisión.

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.

Sugerencia

El objetivo principal de este artículo es ayudarle a crear una solución de auditoría competa. Dado que el contenido de este artículo está organizado en cuatro fases, necesitará información en varias fases. Por ejemplo, en la fase 1 encontrará información sobre cómo planear el uso de una entidad de servicio y en la fase 2 sobre los requisitos previos y la configuración.

Por lo tanto, le recomendamos que lea primero este artículo completo para que esté familiarizado con lo que conlleva. De esta forma, estará bien preparado para planear y crear la solución de auditoría de forma iterativa.

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

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.

Diagrama de flujo que describe la Fase 1, que se centra en los requisitos previos y la configuración para crear una solución de auditoría a nivel de inquilino.

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.

Sugerencia

Compruebe los requisitos de auditoría y establezca las prioridades con su patrocinador ejecutivo y centro de excelencia. Resulta tentador extraer datos de auditoría y empezar a crear informes basados en un montón de datos interesantes. Sin embargo, es poco probable que su solución de auditoría le sea valiosa si no está basada en las preguntas a las que necesita responder y las acciones que pretende emprender.

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:

  • Identificar los requisitos: recopile y documente los requisitos empresariales clave para auditar el inquilino de Power BI.
  • Clasificar los requisitos en orden de prioridad: establezca prioridades para los requisitos; los puede clasificar como inmediatos, a corto plazo, a medio plazo y a largo plazo (trabajo pendiente).
  • Elaborar un plan para las prioridades inmediatas: implemente un plan para empezar a recopilar datos de forma que estén disponibles cuando los necesite.
  • Revaluar los requisitos con regularidad: cree un plan para revaluar los requisitos de forma periódica (por ejemplo, dos veces al año). Compruebe si la solución de auditoría y supervisión cumple los requisitos indicados. Actualice los elementos de acción del plan según sea necesario.

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.

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, conocidos anteriormente como "conjuntos de datos"?
    • ¿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.

Importante

Si aún no está extrayendo y almacenando datos sobre las actividades de los usuarios, conviértalo en una prioridad urgente. Como mínimo, asegúrese de extraer los datos sin procesar y almacenarlos en una ubicación segura. De este modo, los datos estarán disponibles cuando esté listo para analizarlos. El historial está disponible durante 30 o 90 días, según el origen que use.

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.

Sugerencia

A menudo combinará los eventos de actividad del usuario (descritos en la sección anterior) y el inventario de inquilino para generar una imagen completa. De este modo, se mejora el valor de todos los datos.

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 (anteriormente conocido como Azure Active Directory).

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?

Advertencia

Algunos métodos más antiguos (que están ampliamente documentados en línea) para acceder a los datos de usuarios y grupos están en desuso y no se deben emplear. Siempre que sea posible, use Microsoft Graph como origen autoritativo de usuarios y grupos de datos.

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.

Importante

En ocasiones, este artículo hace referencia a Power BI Premium o a sus suscripciones de capacidad (SKU P). Tenga en cuenta que Microsoft está consolidando actualmente las opciones de compra y retirando las SKU de Power BI Premium por capacidad. Los clientes nuevos y existentes deben considerar la posibilidad de comprar suscripciones de capacidad de Fabric (SKU F) en su lugar.

Para obtener más información, consulte Actualización importante sobre las licencias de Power BI Premium y Preguntas más frecuentes sobre Power BI Premium.

Sugerencia

Para más consideraciones sobre la seguridad, consulte los artículos de planeamiento de seguridad.

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:

  • Identificar las necesidades de datos específicas para los datos de actividad del usuario: valide los requisitos que ha recopilado. Identifique qué datos de auditoría son necesarios para cumplir cada requisito para los datos de actividad del usuario.
  • Identificar las necesidades de datos específicas para los datos de inventario del inquilino: valide los requisitos que ha recopilado. Identifique qué datos de auditoría son necesarios para compilar un inventario de inquilino.
  • Identificar las necesidades de datos específicas para los datos de usuarios y grupos: valide los requisitos que ha recopilado. Identifique qué datos de auditoría son necesarios para cumplir cada requisito para los datos de usuarios y grupos.
  • Identificar las necesidades de datos específicas para los datos de seguridad: valide los requisitos que ha recopilado. Identifique qué datos de auditoría son necesarios para cumplir cada requisito para los datos de seguridad.
  • Comprobar prioridades: compruebe el orden de las prioridades para saber qué desarrollar primero.
  • Decidir con qué frecuencia se van capturar las actividades: decida con qué frecuencia se van a capturar eventos de actividad (por ejemplo, una vez al día).
  • Decidir con qué frecuencia se van a capturar las instantáneas: decida con qué intervalo se van a capturar datos de instantánea, como un inventario de inquilino o los datos de usuarios y grupos.

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.

Sugerencia

Si hay una necesidad frecuente y recurrente de obtener datos de auditoría que actualmente se controlan manualmente, considere la posibilidad de invertir tiempo para automatizarla. Por ejemplo, si un administrador de Power BI ejecuta manualmente un script todos los días para recuperar datos del registro de actividad de Power BI, existe el riesgo de que falten datos si esa persona está enferma o está de vacaciones.

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

  • Determine la finalidad principal para cada nuevo requisito de auditoría: decida si va a usar un proceso manual o automatizado para cada nuevo requisito. Tenga en cuenta si esa decisión es temporal o permanente.
  • Cree un plan para cómo realizar la automatización: cuando sea adecuado para un requisito de auditoría determinado, cree un plan sobre cómo automatizarlo, cuándo y por quién.

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.

Nota

La configuración de los procesos de extracción de datos suele ser un esfuerzo único con mejoras y solución de problemas ocasionales. El análisis de los datos y la actuación sobre ellos es un esfuerzo continuo que requiere un esfuerzo permanente de forma periódica.

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

  • Identificar qué equipos intervienen: determine qué equipos estarán implicados con la creación de un extremo a otro y el soporte técnico de la solución de auditoría.
  • Decidir permisos de usuario: determine cómo se configurarán los permisos de usuario para acceder a los datos de auditoría. Cree documentación de decisiones clave para referencias posteriores.
  • Decidir roles y responsabilidades: asegúrese de que las expectativas sean claras para quién hace qué, especialmente cuando hay varios equipos implicados. Cree documentación para roles y responsabilidades, que incluye las acciones esperadas.
  • Asignar roles y responsabilidades: asigne roles y responsabilidades específicos a personas o equipos concretos. Actualice las descripciones de trabajos individuales con recursos humanos, cuando corresponda.
  • Crear un plan de entrenamiento: establezca un plan para el personal de entrenamiento cuando dicho personal necesite nuevas aptitudes.
  • Crear un plan de entrenamiento cruzado: asegúrese de que las copias de seguridad y el entrenamiento cruzado están en vigor para los roles clave.

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

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.

Sugerencia

Los cmdlets de PowerShell usan las API REST de Power BI para acceder a los datos de auditoría. Para obtener más información, consulte Elección de API o cmdlets de PowerShell.

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 El área de trabajo de supervisión de administrador es una buena opción para los procesos de auditoría manual.
Try-it Try-it es una buena elección para los procesos de auditoría manuales.
PowerShell PowerShell es una buena elección para los procesos de auditoría manuales. PowerShell es una buena elección para los procesos de auditoría automatizados.
Power BI Desktop Power BI Desktop es una buena elección para los procesos de auditoría manuales.
Power Automate Power Automate es una buena elección para los procesos de auditoría automatizados.
Servicio de Azure preferido El servicio de Azure preferido es una buena elección para los procesos de auditoría automatizados.
Herramienta o lenguaje preferidos La herramienta o el lenguaje preferidos es una buena elección para los procesos de auditoría manuales. La herramienta o el lenguaje preferidos es una buena elección para los procesos de auditoría automatizados.
Búsqueda de registros de auditoría de Microsoft Purview La búsqueda de registros de auditoría de Microsoft Purview es una buena elección para los procesos de auditoría manuales.
Defender para aplicaciones en la nube Defender for Cloud Apps es una buena opción para los procesos de auditoría manuales.
Microsoft Sentinel Microsoft Sentinel es una buena elección para los procesos de auditoría automatizados.

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 y los administradores globales 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.

Nota

Debe ser un usuario de Power BI con licencia y autenticado para usar Try-it. Esta herramienta sigue el modelo de permisos estándar, lo que significa que las API de usuario dependen de los permisos de usuario y las API de administrador requieren permisos de administrador de Power BI. No se puede autenticar con Try-it mediante una entidad de servicio.

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.

Importante

Se recomienda usar la versión más reciente de PowerShell (PowerShell Core) para todo el nuevo trabajo de desarrollo. Debe interrumpir el uso de Windows PowerShell (que no puede ejecutar PowerShell Core) y, en su lugar, usar uno de los editores de código modernos que admiten PowerShell Core. Tenga cuidado al hacer referencia a muchos ejemplos en línea que usan Windows PowerShell (versión 5.1) porque es posible que no usen los enfoques de código más recientes (y mejores).

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.

Sugerencia

Para enviar solicitudes a las API REST de Power BI, puede usar un conector personalizado para Power Automate para autenticar y extraer de forma segura los datos de auditoría. Como alternativa, puede usar Azure Key Vault para hacer referencia a una contraseña o un secreto. Ambas opciones son mejores que almacenar contraseñas y secretos en texto sin formato dentro del flujo de Power Automate.

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:

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

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:

  • Hablar con el personal de TI: hable con los equipos de TI para averiguar si hay determinadas herramientas aprobadas o preferidas.
  • Explorar opciones con una pequeña prueba de concepto (POC): realice alguna experimentación con una POC técnica. Céntrese inicialmente en el aprendizaje. A continuación, céntrese en su decisión sobre qué usar en el futuro.

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.

Importante

Consulte con sus equipos de TI y seguridad sobre esta cuestión. Tómese el tiempo para aprender los conceptos básicos de cómo funciona la seguridad en Microsoft Entra ID.

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.

Sugerencia

El glosario de términos de la plataforma de identidad de Microsoft es un recurso que le ayuda a familiarizarse con los conceptos básicos.

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.

Nota:

Una aplicación de Microsoft Entra es una configuración de identidad que permite que un proceso automatizado se integre con Microsoft Entra ID. En este artículo, se conoce como registro de aplicaciones. El término entidad de servicio también se usa normalmente en este artículo. Estos términos se describen con más detalle posteriormente en esta sección.

Sugerencia

La manera más fácil de autenticarse es usar el cmdlet Connect-PowerBIServiceAccount del módulo de administración de Power BI. Es posible que vea otros cmdlets relacionados con la autenticación en artículos y entradas de blog en línea. Por ejemplo, existen los cmdlets Login-PowerBI y Login-PowerBIServiceAccount, que son alias del cmdlet Connect-PowerBIServiceAccount. También está el cmdlet Disconnect-PowerBIServiceAccount que puede usar para cerrar sesión explícitamente al final de un proceso.

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 La autenticación de usuario es una buena elección para los procesos de auditoría manuales
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 La autenticación con entidad de servicio es una buena elección para los procesos de auditoría automatizados

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.

Importante

Siempre que sea posible, se recomienda usar la autenticación de entidad de servicio para procesos automatizados.

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.

Sugerencia

El administrador de Microsoft Entra puede avisarle quién tiene permiso para crear un registro de aplicaciones en su organización y darle su consentimiento.

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.

Importante

En este artículo, nos centraremos únicamente en la autenticación de usuario o autenticación solo de aplicación. Los permisos delegados (con un usuario interactivo y la entidad de servicio) podrían desempeñar un papel importante al insertar contenido de Power BI mediante programación. Sin embargo, le desaconsejamos encarecidamente que establezca permisos delegados para extraer datos de auditoría. Cada API limita la frecuencia con la que se puede ejecutar (con limitación vigente), por lo que no resulta práctico que distintos usuarios accedan directamente a los datos de auditoría sin procesar. En su lugar, se recomienda extraer los datos de auditoría sin procesar una vez (con un proceso centralizado) y, a continuación, hacer que los datos de auditoría mantenidos estén disponibles para los usuarios autorizados de bajada.

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.

Sugerencia

Como enfoque alternativo a usar un secreto, puede usar una identidad administrada. Una identidad administrada elimina la necesidad de administrar las credenciales. Si piensa usar servicios como Azure Functions o Azure Data Factory para extraer los datos, una identidad administrada es una buena opción que investigar.

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.

Precaución

La primera regla es una que mucha gente incumple: las contraseñas y claves nunca deben aparecer en texto no cifrado en un script. Muchos artículos, blogs y ejemplos en línea lo hacen para simplificar. Sin embargo, es una mala práctica que se debe evitar. Cualquiera que obtenga el script (o el archivo) puede potencialmente acceder a los mismos datos a los que tiene acceso el autor.

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).

Sugerencia

Se recomienda consultar con los equipos de TI y seguridad para que le ayuden a elegir el mejor método o validar que la solución administra las credenciales de forma segura.

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:

  • Decidir qué tipo de autenticación se va a usar: determine si la autenticación de usuario o la autenticación de entidad de servicio es más adecuada, en función del tipo de solución de auditoría que tenga previsto crear.
  • Planear qué registros de aplicaciones necesita: tenga en cuenta los requisitos, las cargas de trabajo y la audiencia de destino (usuarios de cada registro de aplicaciones). Planee el número de registros de aplicaciones que necesita crear para cumplir con estas necesidades.
  • Crear una convención de nomenclatura para los registros de aplicaciones: configure una convención de nomenclatura que facilite la comprensión de la finalidad y los usuarios previstos de cada registro de aplicaciones.
  • Planear cómo administrar las credenciales de forma segura: tenga en cuenta las formas de administrar de forma segura las contraseñas, los secretos y las claves. Piense qué documentación y formación podrían requerirse.
  • Confirmar el uso de MSAL: determine si hay alguna solución de auditoría manual o automatizada existente que se base en ADAL. Si es necesario, cree un plan para volver a escribir estas soluciones para usar la biblioteca de autenticación de MSAL más reciente.

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).

Sugerencia

Todas las API de administrador pertenecen al grupo de operaciones de administración. Cualquier API que tenga el sufijo Como administrador es una API de administrador; todas las API restantes son 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

Nota

Algunos de los nombres de API incluyen el término grupo como referencia a un área de trabajo. Ese término se originó en el modelo de seguridad original de Power BI, que se basaba en los grupos de Microsoft 365. Aunque el modelo de seguridad de Power BI ha evolucionado significativamente a lo largo de los años, los nombres de API existentes se mantienen sin cambios para evitar que las soluciones existentes dejen de funcionar.

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:

  • Consultar los requisitos de datos: recopile y documente los requisitos empresariales clave para una solución de auditoría. En función del tipo de datos que se necesiten, determine si es apropiado un ámbito de usuario o un ámbito de organización.
  • Probar los resultados: realice alguna experimentación. Pruebe la precisión de los resultados devueltos por las distintas API.
  • Revisar los permisos: en el caso de las soluciones de auditoría existentes, confirme que los permisos se asignan correctamente a los administradores y entidades de servicio de Power BI. Para las nuevas soluciones de auditoría, confirme qué método de autenticación se usará.

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.

Sugerencia

Además de los módulos publicados por Microsoft, hay disponibles gratuitamente módulos y scripts de PowerShell publicados (normalmente en GitHub) por miembros de la comunidad de Power BI, asociados e integrantes de los profesionales más valorados (MVP).

Comenzar con una solución comunitaria puede desempeñar un papel importante en la creación de su solución de auditoría integral. Si decide usar una solución disponible libremente, asegúrese de probarla por completo. Familiarícese con el funcionamiento para que pueda administrar eficazmente la solución a lo largo del tiempo. Es posible que el departamento de TI tenga criterios para usar soluciones de la comunidad disponibles públicamente.

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.

Importante

Se recomienda interrumpir el uso de Windows PowerShell (que no puede ejecutar PowerShell Core). En su lugar, use uno de los editores de código modernos que admite PowerShell Core. El ISE (entorno de script integrado) de Windows PowerShell solo es capaz de ejecutar la versión 5.1 de PowerShell , que ya no se actualiza. Windows PowerShell ahora está en desuso, por lo que se recomienda usar PowerShell Core para todo el trabajo de desarrollo nuevo.

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.

Sugerencia

Hay otros cmdlets disponibles para administrar y publicar contenido. Sin embargo, el enfoque de este artículo es recuperar datos de auditoría.

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.

Precaución

Asegúrese de mantener actualizados los módulos en cada servidor, equipo de usuario y servicio en la nube (por ejemplo, Azure Automation) donde use PowerShell. Si los módulos no se actualizan periódicamente, podrían surgir errores o problemas imprevisibles. Algunas herramientas (como Visual Studio Code) le ayudan a mantener actualizados los módulos. Además, tenga en cuenta que PowerShellGet no desinstala automáticamente las versiones anteriores de un módulo al instalar o actualizar una versión más reciente. Instala versiones más recientes junto con las versiones anteriores. Se recomienda comprobar las versiones instaladas y desinstalar periódicamente las versiones anteriores.

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.

Advertencia

No es posible asignar una entidad de servicio como administrador de puerta de enlace (incluso cuando la entidad de servicio es miembro de un grupo de seguridad). Por lo tanto, planee usar las credenciales de usuario al recuperar información sobre las puertas de enlace de datos.

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.

Sugerencia

Puede usar el cmdlet Invoke-ASCmd de PowerShell para crear y ejecutar scripts DAX, XMLA y TMSL. Sin embargo, estos casos de uso están fuera del ámbito de este artículo. Para obtener más información sobre cómo consultar vistas de administración dinámica (DMV), consulte Auditoría de nivel de datos.

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:

  • Consulte con TI sobre el uso de PowerShell: póngase en contacto con los equipos de TI pertinentes para determinar si existen requisitos internos o preferencias sobre cómo se puede usar PowerShell.
  • Decida cómo desea usar PowerShell: determine qué técnicas de PowerShell desea usar y si quiere aumentar o reducir intencionadamente su dependencia de PowerShell. Considere si la comunicación o el entrenamiento internos son necesarios.
  • Actualice a PowerShell Core: investigue con PowerShell Core. Determine si hay que actualizar las máquinas de administrador. Considere qué scripts existentes deben probarse. Determine si los administradores o desarrolladores necesitan un entrenamiento adicional para actualizar sus aptitudes.
  • Determine qué módulos de PowerShell desea usar: considere si se usarán los módulos de administración de Power BI o el módulo de puerta de enlace de datos.
  • Decida si se permiten proyectos de la comunidad: determine si se le permite (o incluso se le recomienda) usar módulos de PowerShell disponibles en línea (frente a módulos publicados por Microsoft). Consulte con TI para determinar si hay criterios para los proyectos de la comunidad obtenidos en línea.
  • Aclare cómo apoyar proyectos de la comunidad: si se permiten proyectos de la comunidad de PowerShell, considere quién será responsable de apoyarlos una vez que se usen internamente.
  • Complete una pequeña prueba de concepto (POC): experimente con una POC técnica. Confirme sus herramientas de cliente y su método de acceso a los datos preferidos.
  • Determine cómo admitir usuarios avanzados: considere cómo va a admitir usuarios técnicos que creen una automatización por su cuenta mediante las API de usuario.

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 globales) 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.

Sugerencia

Cuando se usa un lago de datos, un almacenamiento de objetos o un sistema de archivos, se recomienda almacenar los datos de una forma fácil de organizar y segura. También es importante especificar claramente si los datos incluyen eventos (que normalmente se anexan) o si se trata de una instantánea de un momento dado (que requiere la selección de una fecha que se va a analizar).

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:

  • Consultar con los responsables de TI: póngase en contacto con los equipos de TI pertinentes para determinar si hay procesos existentes en marcha para extraer los datos de auditoría sin procesar. Si es así, averigüe si puede acceder a los datos existentes. Si se requiere un nuevo proceso de extracción de datos, determine si hay preferencias o requisitos con respecto a dónde se deben almacenar los datos.
  • Decidir dónde almacenar los datos sin procesar: determine la mejor ubicación y estructura de almacenamiento para almacenar los datos sin procesar.
  • Determinar los requisitos de residencia de datos: averigüe si hay requisitos legales o normativos con respecto a dónde se pueden almacenar los datos.
  • Crear una estructura de carpetas y una convención de nomenclatura: determine qué convención de nomenclatura se va a usar para los archivos de datos sin procesar, incluida la estructura de carpetas. Incluya estos detalles en la documentación técnica.
  • Tener en cuenta cómo funcionará la seguridad de los datos sin procesar: aunque diseñe la ubicación de almacenamiento de datos sin procesar, tenga en cuenta quién necesitará acceder a los datos y cómo se concederá acceso.

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).

Sugerencia

Al crear los datos mantenidos, configúrelos de forma que pueda volver a ejecutar fácilmente el proceso en intervalos de fechas anteriores. Por ejemplo, si descubre que un nuevo atributo ha aparecido en los registros de auditoría hace tres meses, querrá poder analizarlo desde que apareció por primera vez. La posibilidad de volver a cargar el historial de datos mantenidos es una de las varias razones por las que es importante almacenar los datos sin procesar en su estado original (descrito anteriormente en este artículo).

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:

  • Decidir dónde deben realizarse las transformaciones: considere en qué fase previa debe realizarse el trabajo de transformación y dónde encaja en su plan con respecto a toda la arquitectura.
  • Decidir qué herramienta usar para transformar los datos en un esquema en estrella: confirme qué herramientas y servicios se usarán para transformar los datos sin procesar en datos mantenidos.
  • Decidir dónde se deben almacenar los datos mantenidos: determine la mejor opción para almacenar los datos sin procesar que se han transformado en un formato de esquema en estrella. Decida si una capa plata intermedia es útil en la arquitectura completa.
  • Crear una convención de nomenclatura: determine qué convención de nomenclatura se va a usar para los archivos y carpetas de datos mantenidos (si procede). Incluya los detalles en la documentación técnica.
  • Tener en cuenta cómo funcionará la seguridad de los datos mantenidos: al diseñar la ubicación de almacenamiento de datos mantenidos, tenga en cuenta quién necesitará acceder a los datos y cómo se asignará la seguridad.

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.

Importante

Si aún no está extrayendo datos sobre la actividad del usuario, conviértalo en una prioridad urgente. Los datos de actividad del usuario están disponibles durante los últimos 30 o 90 días (según el origen). Aunque no esté preparado para realizar análisis en profundidad, es importante empezar a extraer y almacenar los datos lo antes posible. De este modo, contará con un historial valioso para analizar.

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 El portal de cumplimiento de Microsoft Purview es una buena opción para los procesos de auditoría manuales. El portal de cumplimiento de Microsoft Purview es una buena opción para ponerse en marcha rápidamente.
Manual (interfaz de usuario) Defender para aplicaciones en la nube 30 Defender for Cloud Apps es una buena opción para los procesos de auditoría manuales. Defender for Cloud Apps es una buena opción para configurar alertas.
Programático Registro de actividad de Power BI (API o cmdlet de PowerShell) 30 El registro de actividad de Power BI (API o cmdlet de PowerShell) es una buena opción para los procesos de auditoría automatizados. El registro de actividad de Power BI (API o cmdlet de PowerShell) es una buena opción para ponerse en marcha rápidamente.
Programático API de Actividad de administración de Office 365 7 La API de Actividad de administración de Office 365 es una buena opción para los procesos de auditoría automatizados.
Programático Microsoft Sentinel (Azure Monitor) 30 Microsoft Sentinel (Azure Monitor) es una buena elección para los procesos de auditoría automatizados. Microsoft Sentinel (Azure Monitor) es una buena elección para configurar alertas.

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.

Sugerencia

De forma predeterminada, los administradores de Power BI no tienen permiso para acceder a la búsqueda del registro de auditoría unificado en el portal de cumplimiento de Microsoft Purview. Dado que contiene datos para muchos servicios de Microsoft 365, es un rol con privilegios elevados. En la mayoría de las organizaciones, esos permisos están reservados para un pequeño número de administradores de TI. Hay otras opciones disponibles para los administradores de Power BI, que se describen más adelante en esta sección.

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.

Sugerencia

De forma predeterminada, los administradores de Power BI no tienen permiso para acceder a Defender for Cloud Apps. Hay un rol de Power BI en Defender for Cloud Apps. Agregar administradores de Power BI a este rol es una buena manera de concederles acceso a un conjunto limitado de datos.

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.

Sugerencia

En el caso de las organizaciones que pretenden extraer actividades de usuario, se recomienda que empiecen con el registro de actividad de Power BI. Es el origen más sencillo para acceder mediante programación.

Tiene dos opciones para acceder al registro de actividad 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.

Sugerencia

Para obtener ejemplos de cómo acceder al registro de actividad de Power BI con PowerShell, consulte Acceso al registro de actividad de Power BI.

Los datos del registro de actividad de Power BI están disponibles para todos los administradores de Power BI, administradores de Power Platform y administradores globales. 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.

Nota

En los datos del registro de auditoría, las áreas de trabajo se conocen como carpetas. En la API REST de Power BI, las áreas de trabajo se conocen como grupos.

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.

Importante

El cmdlet Search-UnifiedAuditLog no se escala bien y requiere que implemente una estrategia de bucle para superar su límite de 5000 filas. Por estos motivos, es adecuado para consultas ocasionales o para pequeñas organizaciones que experimentan poca actividad. Cuando solo necesite datos de Power BI, se recomienda usar el cmdlet Get-PowerBIActivityEvent en su lugar.

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.

Sugerencia

De forma predeterminada, los administradores de Power BI no tienen permiso para acceder a la API Actividad de administración de Office 365. Dado que contiene datos para muchos servicios de Microsoft 365, el acceso requiere los roles de administrador o auditoría con privilegios elevados. En la mayoría de las organizaciones, estos roles están reservados para un pequeño número de administradores de TI. El registro de actividad de Power BI está pensado para su uso por parte de los administradores de Power BI.

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.

Sugerencia

Azure Log Analytics se basa en la misma arquitectura que usan los registros de eventos del modelo semántico de nivel de área de trabajo. Para obtener más información sobre los registros de eventos de modelo semántico, consulte Auditoría de nivel de datos.

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.

Precaución

Tenga en cuenta que solo se almacena un subconjunto de los datos del registro de actividad de Power BI en Azure Monitor. Cuando quiera realizar un análisis completo del uso y de la adopción de Power BI en la organización, se recomienda usar otras opciones (descritas anteriormente en esta sección) para recuperar los datos de actividad.

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.
  • ¿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:

  • Aclarar el alcance de las necesidades: determine si solo necesita acceder a los registros de auditoría de Power BI o a los datos de auditoría de varios servicios.
  • Consultar con TI: averigüe si TI extrae actualmente los registros de auditoría y si es posible obtener acceso a los datos sin procesar para que no sea necesario compilar una nueva solución.
  • Decidir sobre un origen de datos: determine el origen más adecuado para acceder a los datos de actividad del usuario.
  • Completar una prueba de concepto: planee completar una pequeña prueba de concepto (POC) técnica. Úsela para validar sus decisiones sobre cómo se compilará la solución final.
  • Hacer un seguimiento de necesidades de datos adicionales: puede correlacionar los datos del registro de actividad con otros orígenes para incrementar el valor de los datos. Haga un seguimiento de estas oportunidades a medida que surjan para poder agregarlas al ámbito del proyecto.

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.

Nota

La documentación de la API REST de Power BI hace referencia a los elementos publicados como artefactos.

Sugerencia

Muchas organizaciones consideran útil extraer el inventario de inquilinos a la misma hora del día cada semana.

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.

Sugerencia

Puede usar la API Get Unused Artifacts as Admin para buscar elementos que no tengan ninguna actividad de usuario en los últimos 30 días. Sin embargo, no se puede personalizar ese período de tiempo. Por ejemplo, puede que tenga contenido crítico que solo se use trimestralmente. Al combinar el inventario de inquilinos con los datos de actividad del usuario, puede encontrar elementos no utilizados de formas que pueda personalizar.

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 La API Get Groups as Admin o el cmdlet de PowerShell Get-PowerBIWorkspace son una buena opción para los procesos de auditoría manuales. La API Get Groups as Admin o el cmdlet de PowerShell Get-PowerBIWorkspace son una buena opción para los procesos de auditoría automatizados.
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 Las API de examen de metadatos son una opción adecuada para los procesos de auditoría automatizados.

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.

Nota

La API nombrada incluye el término grupo como referencia a un área de trabajo. Ese término se originó en el modelo de seguridad original de Power BI, que se basaba en los grupos de Microsoft 365. Aunque el modelo de seguridad de Power BI ha evolucionado significativamente a lo largo de los años, los nombres de API existentes se mantienen sin cambios para evitar que las soluciones existentes dejen de funcionar.

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).

Sugerencia

Al pasar parámetros, puede usar el cmdlet de distintas formas. Esta sección se centra en recuperar un inventario de todos los inquilinos. Para obtener más información sobre el uso del parámetro -Scope, consulte Elección de una API de usuario o una API de administrador, anteriormente en este artículo.

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.

Nota

Observe cómo usan algunas personas el término API de escáner o la frase examen del inquilino. Al usar esos términos, a menudo quieren decir compilar un inventario de inquilinos, lo que se distingue de los eventos de actividad de usuario. Pueden hacer referencia literalmente, o no, al uso de las API de examen de metadatos.

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:

  • Confirmar los requisitos: clarifique las necesidades para compilar un inventario de inquilinos y los requisitos analíticos de los datos.
  • Decidir la frecuencia de extracción del inventario de inquilinos: confirme con qué frecuencia necesitará un nuevo inventario de inquilinos (por ejemplo, cada semana).
  • Decidir cómo extraer el inventario de inquilinos: confirme qué método usará para obtener los datos de inventario de inquilinos (API, cmdlet o API de examen de metadatos).
  • Completar una prueba de concepto: planee completar una pequeña prueba de concepto (POC) técnica. Úsela para validar sus decisiones sobre cómo se compilará la solución final.

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.

Nota

Cuando en este artículo se hace referencia a usuarios y grupos, el término también incluye las entidades de servicio. Este término más corto se usa para abreviar.

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

Sugerencia

Para obtener más información sobre los usuarios, las entidades de servicio y los grupos, consulte Integración con Microsoft Entra ID.

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 y a los administradores globales).

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.

Sugerencia

Recuperar miembros de grupos puede ser uno de los aspectos más difíciles al obtener datos de auditoría. Deberá realizar una búsqueda transitiva para nivelar todos los miembros anidados y los grupos anidados. Puede realizar una búsqueda transitiva para los miembros del grupo. Este tipo de búsqueda es especialmente complicado cuando hay miles de grupos en la organización. En ese caso, podría considerar mejores alternativas para recuperar los datos. Una opción es extraer todos los grupos y miembros del grupo de Microsoft Graph. Sin embargo, esto podría no ser práctico cuando solo se usa un pequeño número de grupos para la seguridad de Power BI. Otra opción consiste en precompilar una lista de referencias de grupos que se usan en cualquier tipo de seguridad de Power BI (roles de área de trabajo, permisos de aplicación, uso compartido por elemento, seguridad de nivel de fila y otros). Después, puede recorrer en bucle la lista de referencias para recuperar miembros del grupo de Microsoft Graph.

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.

Sugerencia

El registro de actividad de Power BI incluye un evento que registra cuando un usuario se suscribe a una licencia de prueba. Puede combinar ese evento con los datos de licencia de usuario (procedentes de Microsoft Entra ID) para generar una imagen completa.

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 El Probador de Graph es una buena opción para los procesos de auditoría manuales.
Programático API y SDK de Microsoft Graph Las instancias de Microsoft Graph API y los SDK son buenas opciones para los procesos de auditoría automatizados.
Programático Módulo Az de PowerShell El módulo Az de PowerShell es una buena opción para los procesos de auditoría automatizados.

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.

Nota

Tenga cuidado al leer información en línea porque muchos nombres de herramientas son similares. Algunas herramientas del ecosistema de Microsoft incluyen el término Graph en su nombre, como Azure Resource Graph, GraphQL y Microsoft Security Graph API. Esas herramientas no están relacionadas con Microsoft Graph y están fuera del ámbito de este artículo.

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.

Importante

El módulo de PowerShell de Microsoft Graph reemplaza los módulos de PowerShell de Azure AD y los módulos MSOnline (MSOL), que están en desuso. No debe crear nuevas soluciones con módulos en desuso. El módulo de PowerShell de Microsoft Graph tiene muchas características y ventajas. Para obtener más información, consulte Actualizar de Azure AD PowerShell a Microsoft Graph PowerShell.

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.

Sugerencia

Microsoft actualiza periódicamente los módulos de PowerShell de Microsoft Graph. En ocasiones, los módulos en versión preliminar están disponibles en una versión preliminar o en un punto de conexión beta. Es posible que quiera especificar la versión que le interesa al instalar y actualizar los módulos. Además, cuando revise la documentación en línea, tenga en cuenta que el número de versión actual se anexa automáticamente al final de la dirección URL (así que tenga cuidado al guardar o compartir direcciones URL).

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.

Importante

El módulo Az de PowerShell reemplaza los módulos AzureRM de PowerShell, que están en desuso. No debe crear nuevas soluciones con módulos en desuso.

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. (Microsoft Entra ID ahora se conoce como Microsoft Entra ID.)
  • 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.

Precaución

Asegúrese de confirmar el estado de cualquier API o módulo en desuso que esté usando actualmente. Para más información sobre la retirada de AzureRM, consulte este anuncio.

Para más información sobre Microsoft Entra ID y MSOL, consulte esta publicación de anuncio de retirada.

Si tiene preguntas o necesita aclaración sobre la dirección futura del acceso a datos mediante programación, póngase en contacto con su equipo de cuentas de Microsoft.

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

  • Confirmar los requisitos: aclare las necesidades de compilación de datos relacionados con usuarios, grupos y licencias.
  • Priorizar los requisitos: confirme cuáles son las prioridades principales para saber a qué dedicar tiempo primero.
  • Decidir la frecuencia para extraer datos: determine con qué frecuencia necesitará una nueva instantánea de los datos de usuarios y grupos (por ejemplo, cada semana o cada mes).
  • Decidir cómo extraer datos con Microsoft Graph: determinar qué método usará para recuperar los datos.
  • Completar una prueba de concepto: planear completar una pequeña prueba técnica de concepto (POC) para extraer datos de usuarios y grupos. Úsela para validar sus decisiones sobre cómo se compilará la solución final.

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:

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

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:

  • Obtener requisitos: compile los requisitos analíticos a medida que surjan. Realice un seguimiento de ellos en el trabajo pendiente.
  • Priorizar los requisitos: establezca prioridades para los nuevos requisitos que surgen.

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.

Diagrama de flujo que describe la Fase 2, que se centra en los requisitos previos y la configuración para crear una solución de auditoría a nivel de inquilino.

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:

  • Crear una cuenta de almacenamiento: cree o envíe una solicitud para crear una cuenta de almacenamiento. Use la configuración de almacenamiento inmutable para los datos sin procesar, siempre que sea posible.
  • Establecer permisos: determine qué permisos se deben establecer para la cuenta de almacenamiento.
  • Prueba de acceso: realice una prueba pequeña para asegurarse de que puede leer y escribir en la cuenta de almacenamiento.
  • Confirmar responsabilidades: asegúrese de que tiene claro sobre quién administrará la cuenta de almacenamiento de forma continua.

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:

  • Configurar máquinas de administrador o desarrollador: si procede, instale las herramientas necesarias que se usarán para el desarrollo.
  • Configurar servidores: si procede, instale las herramientas necesarias en cualquier servidor o máquina virtual que esté presente en la arquitectura.
  • Configuración de servicios de Azure: si procede, aprovisione y configure cada servicio de Azure. Asigne permisos para cada administrador o desarrollador que realizará el trabajo de desarrollo.

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:

  • Comprobar si existe un registro de aplicación: compruebe con el equipo de TI si un registro de aplicación está disponible para el propósito de ejecutar las API de administración. Si es así, determine si se debe usar el existente o si se debe crear uno nuevo.
  • Crear un registro de aplicación: cree un registro de aplicación cuando corresponda. Considere la posibilidad de usar un nombre de aplicación como PowerBI-AdminAPIs-EntraApp, que describe claramente su propósito.
  • Crear un secreto para el registro de la aplicación: una vez que exista el registro de la aplicación, cree un secreto para ella. Establezca la fecha de expiración en función de la frecuencia con la que pretende rotar el secreto.
  • Guardar los valores de forma segura: almacene el secreto, el identificador de aplicación (identificador de cliente) y el identificador de inquilino, ya que los necesitará para autenticarse con la entidad de servicio. Use una ubicación segura, como un almacén de contraseñas de la organización. Si necesita solicitar la creación de un registro de aplicación desde TI, especifique que necesita estos valores devueltos.
  • Cree un grupo de seguridad: cree (o solicite) un grupo de seguridad que se usará para Power BI. Considere la posibilidad de usar el nombre de grupo, como las entidades de servicio de administración de Power BI, lo que significa que el grupo se usará para acceder a los metadatos de todo el inquilino.
  • Agregar la entidad de servicio como miembro del grupo de seguridad: use el identificador de aplicación (identificador de cliente) para agregar la nueva entidad de servicio (o existente) como miembro del nuevo grupo de seguridad.
  • Actualizar la configuración del inquilino de la API de administración en Power BI: en el portal de administración de Power BI, agregue el grupo de seguridad a la configuración de inquilino Concesión de permisos a las entidades de servicio para utilizar las API de administración de Power BI de solo lectura.
  • Omitir la asignación de permisos en Azure: no delegue ningún permiso para el registro de aplicaciones (obtendrá acceso a los datos de auditoría de nivel de inquilino de Power BI mediante la configuración de inquilino de Power BI Concesión de permisos a las entidades de servicio para utilizar las API de administración de Power BI de solo lectura.
  • Decidir si el registro de la aplicación debe acceder a metadatos detallados: determine si quiere extraer información detallada sobre las tablas, columnas y expresiones de medida del modelo semántico al crear el inventario de inquilinos.
  • Actualizar la configuración detallada del inquilino de metadatos en Power BI: opcionalmente, en el portal de administración de Power BI, agregue el grupo de seguridad a la configuración de inquilino Mejorar las respuestas de la API de administración con la configuración detallada y Mejorar las respuestas de la API de administración con DAX y expresiones mashup.
  • Probar la entidad de servicio: cree un script sencillo para iniciar sesión con la entidad de servicio y pruebe que puede recuperar datos de una API de administrador.
  • Crear un proceso para administrar secretos de registro de aplicaciones: cree documentación y un proceso para rotar periódicamente los secretos. Determine cómo comunicará de forma segura un nuevo secreto a los administradores y desarrolladores que lo necesiten.

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.

Importante

Dado que esta configuración concede acceso a metadatos para todo el inquilino (sin asignar permisos directos de Power BI), debe controlarlos estrechamente.

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.

Nota

No es necesario asignar explícitamente otros administradores de Power BI a la configuración de inquilino Concesión de permisos a las entidades de servicio para utilizar las API de administración de Power BI de solo lectura porque ya tienen acceso a los metadatos de todo el inquilino.

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.

Nota:

La opción de inquilino Concesión de permisos a las entidades de servicio para utilizar las API de administración de Power BI de solo lectura está relacionada específicamente con el acceso a las API de administración. Su nombre es muy similar a la configuración del inquilino que está pensada para acceder a las API de usuario (se describe a continuación). Para más información sobre la diferencia entre las API de administrador y las API de usuario, consulte Elección der una API de usuario o una API de administrador anteriormente en este artículo.

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:

  • Comprobar que cada entidad de servicio está en el grupo correcto: confirme que el grupo de entidades de servicio de administración de Power BI incluye las entidades de servicio correctas.
  • Actualizar la configuración del inquilino de la API de administración en Power BI: agregue el grupo de seguridad a la opción Concesión de permisos a las entidades de servicio para utilizar las API de administración de Power BI de solo lectura, que permite usar las API de administración para recuperar los metadatos de todo el inquilino.
  • Actualizar la configuración detallada de los metadatos del inquilino en Power BI: si es necesario, agregue el grupo de seguridad a la configuración de inquilino Mejorar las respuestas de la API de administración con la configuración detallada y la configuración de inquilino Mejorar las respuestas de la API de administración con DAX y expresiones mashup .
  • Confirmar a qué API de usuario se accederá: compruebe si se necesitarán una o varias API de usuario (además de usar las API de administrador).
  • Actualizar la configuración de inquilino de la API de usuario en Power BI: agregue el grupo de seguridad a la configuración de inquilino Concesión de permisos a las entidades de servicio para utilizar las API de Power BI, que está pensada para las API de usuario.

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.

Diagrama de flujo que describe la Fase 3, que se centra en los requisitos previos y la configuración para crear una solución de auditoría de nivel de inquilino.

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:

  • Confirmar los requisitos y las prioridades: tenga claros los requisitos y prioridades de los datos que extraerá primero.
  • Confirmar el origen de los datos que se van a extraer: compruebe el origen de cada tipo de datos que necesite.
  • Configurar un proceso para extraer los datos y cargarlos en la zona de datos sin procesar: cree el proceso inicial para extraer y cargar los datos sin procesar en su estado original, sin ninguna transformación. Compruebe que el proceso sigue funcionando como estaba previsto.
  • Crear una programación para ejecutar los procesos: configure una programación periódica para ejecutar los procesos de extracción, carga y transformación.
  • Comprobar que las credenciales se administran de forma segura: confirme que las contraseñas, los secretos y las claves se almacenan y comunican de forma segura.
  • Confirmar que la seguridad está configurada correctamente: compruebe que los permisos de acceso a los datos sin procesar están configurados correctamente. Asegúrese de que los administradores y auditores puedan acceder a los datos sin procesar.

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).

Sugerencia

Cuando se espera que haya más de un modelo de datos, invertir en una capa de datos mantenidos centralizada es especialmente útil.

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

  • Confirmar los requisitos y las prioridades: si tiene la intención de usar una capa plata intermedia para los datos transformados, aclare los requisitos y objetivos de lo que necesita conseguir.
  • Configurar un proceso para transformar los datos sin procesar y cargarlos en la zona de datos mantenidos: cree un proceso para transformar y cargar los datos en un esquema en estrella. Compruebe que el proceso sigue funcionando como estaba previsto.
  • Crear una programación para ejecutar los procesos: configure una programación periódica para rellenar la capa de datos mantenidos.
  • Confirmar que la seguridad está configurada correctamente: compruebe que los permisos de acceso a los datos mantenidos están configurados correctamente. Asegúrese de que los desarrolladores del modelo de datos puedan acceder a los datos mantenidos.

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.

Sugerencia

Para una introducción del diseño de esquemas de estrella, consulte Descripción de un esquema de estrella e importancia para Power BI.

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:

  • Planear y crear el modelo de datos: diseñe el modelo de datos como un esquema de estrella. Valide que las relaciones funcionan según lo previsto. A medida que desarrolla el modelo, cree medidas de forma iterativa y agregue datos adicionales basándose en los requisitos analíticos. Incluya mejoras futuras en un trabajo pendiente, cuando sea necesario.
  • Configurar RLS: si tiene previsto que el modelo de datos esté disponible para otros usuarios generales, configure la seguridad de nivel de fila para restringir el acceso a los datos. Compruebe que los roles de RLS devuelven los datos correctos.

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.

Sugerencia

Resulta útil saber quiénes son los usuarios ocasionales o inactivos, especialmente cuando tienen licencias Pro o PPU (lo que implica costo). También es útil saber quiénes son los usuarios frecuentes y más activos. Considere la posibilidad de invitarlos a unirse a las horas de oficina o asistir al entrenamiento. Los creadores de contenido más activos pueden ser candidatos para unirse a la red de campeones.

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.

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.

Sugerencia

Puede calcular promedios y tendencias mediante las funciones de inteligencia de tiempo de DAX. Para obtener información sobre cómo usar estas funciones, trabaje con el módulo de aprendizaje Uso de las funciones de inteligencia de tiempo de DAX en modelos de Power BI Desktop.

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

  • Obtener consenso sobre las definiciones de clasificación: debata sobre las definiciones de clasificación con las partes interesadas pertinentes. Asegúrese de que haya acuerdo al tomar las decisiones.
  • Crear documentación: asegúrese de que las definiciones de clasificación se incluyen en la documentación para los creadores y consumidores de contenido.
  • Crear un bucle de comentarios: asegúrese de que hay una manera de que los usuarios hagan preguntas o propongan cambios en las definiciones de clasificación.

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.

Sugerencia

Aunque es tentador presentar una gran cantidad de datos, incluya solamente información sobre la que está preparado para actuar. Asegúrese de que todas las páginas del informe definan claramente su finalidad, qué acción se debe realizar y por quién.

Para aprender a crear informes analíticos, consulte la ruta de aprendizaje Diseño de informes eficaces en Power BI.

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

  • Revisar requisitos: dé prioridad a la creación de informes en función de las necesidades conocidas y las preguntas específicas que se deben responder.
  • Confirmar las audiencias: aclare quién usará los informes de auditoría y cuál será su finalidad prevista.
  • Crear e implementar informes: desarrolle el primer conjunto de informes principales. Amplíelos y mejórelos gradualmente a lo largo del tiempo.
  • Distribuir informes en una aplicación: considere la posibilidad de crear una aplicación que incluya todos los informes de auditoría y supervisión.
  • Comprobar quién tiene acceso a los informes: asegúrese de que los informes (o la aplicación) estén disponibles para el conjunto correcto de usuarios.
  • Crear un bucle de comentarios: asegúrese de que hay una manera de que los consumidores de informes proporcionen comentarios o sugerencias, o notifiquen incidencias.

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.

Sugerencia

También puede mejorar el contenido o la documentación de entrenamiento revisando las preguntas respondidas por la comunidad interna de Power BI y las incidencias enviadas al servicio de asistencia.

Seguridad

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

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:

  • Aclarar las expectativas: cree informes de auditoría con un conjunto claro de expectativas para las acciones que se esperan.
  • Aclarar quién será responsable de las acciones: asegúrese de que se asignen roles y responsabilidades.
  • Crear automatización: cuando sea posible, automatice las acciones conocidas que se pueden repetir.
  • Usar un sistema de seguimiento: use un sistema para realizar un seguimiento de una situación observada, incluidos los contactos realizados, la siguiente acción planeada, sobre quién recae la responsabilidad, la resolución y el estado.

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.

Diagrama de flujo que describe la fase 4, que se centra en mantener, mejorar y supervisar una solución de auditoría de nivel de inquilino.

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.

Sugerencia

No tiene que hacer todo lo mencionado anteriormente de una sola vez. A medida que obtenga experiencia, puede mejorar de forma incremental la solución para que se complete y sea sólida. Tenga en cuenta que la mayoría de los ejemplos que se encuentran en línea son fragmentos de código de script sencillos y únicos que podrían no ser de calidad de producción.

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

  • Evaluar el nivel de las soluciones existentes: determine si hay oportunidades para mejorar y estabilizar las soluciones de auditoría existentes que están automatizadas.
  • Establecer estándares de nivel de producción: decida qué estándares desea tener para los procesos de auditoría automatizados. Tenga en cuenta las mejoras que puede agregar de forma realista a lo largo del tiempo.
  • Crear un plan para mejorar: planee mejorar la calidad y la estabilidad de las soluciones de auditoría de producción.
  • Determinar si es necesario un entorno de desarrollo independiente: evalúe el nivel de riesgo y la dependencia de los datos de producción. Decida cuándo crear entornos de desarrollo y producción (y pruebas) independientes.
  • Considerar una estrategia de retención de datos: determine si necesita implementar un proceso de retención de datos que purgue los datos después de un período de tiempo determinado o a petición.

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:

  • Confirmar quién se espera que proporcione soporte técnico para la solución: determine quién proporcionará soporte técnico para las soluciones de auditoría que se consideran de nivel de producción (o que tienen dependencias de informes descendentes).
  • Asegurar la disposición del equipo de soporte técnico: compruebe que el equipo de soporte técnico está preparado para proporcionar soporte técnico para la solución de auditoría. Identifique si hay lagunas en la disposición que necesite abordar.
  • Organizar el entrenamiento cruzado: realice sesiones de transferencia de conocimientos o sesiones de entrenamiento cruzado para el equipo de soporte técnico.
  • Aclarar las expectativas del equipo de soporte técnico: asegúrese de que las expectativas de respuesta y resolución estén claramente documentadas y comunicadas. Decida si alguien debe atender la llamada para resolver rápidamente las incidencias relacionadas con la solución de auditoría.
  • Crear la documentación técnica: cree documentación sobre la arquitectura técnica y las decisiones de diseño.
  • Crear la documentación de soporte técnico: actualice la base de conocimiento del personal de asistencia técnica para incluir información sobre cómo admitir la solución.
  • Cree documentación para creadores de contenido: cree documentación para ayudar a los creadores de autoservicio a usar el modelo de datos. Describa las definiciones de datos comunes para mejorar la coherencia de su uso.

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.

Importante

Los cambios importantes son poco frecuentes, pero pueden producirse. Es importante que haya alguien disponible que pueda solucionar rápidamente problemas o actualizar la solución de auditoría cuando sea necesario.

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:

  • Asignar un propietario técnico: asegúrese de que haya una propiedad y una responsabilidad claras para toda la solución de auditoría.
  • Comprobar que existe una copia de seguridad: asegúrese de que haya un propietario técnico de respaldo que pueda intervenir en caso de que surja un problema urgente que el servicio de asistencia no pueda resolver.
  • Mantener un sistema de seguimiento: asegúrese de que dispone de una forma de registrar las nuevas solicitudes y de establecer las prioridades inmediatas, así como las prioridades a corto, medio y largo plazo.

Contenido relacionado

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