Configurar perfiles de entidad de servicio principal para aplicaciones multiinquilino

En este artículo se explica cómo configurar y operar perfiles de entidad de servicio después de elegirlos para una solución de Power BI Embedded embed for your customers. Los perfiles admiten la administración de contenido con ámbito de cliente y un gran número de áreas de trabajo. La separación de clientes depende del enrutamiento de aplicaciones correcto, los permisos del área de trabajo y los tokens de inserción con ámbito adecuado; Los perfiles no crean una identidad Microsoft Entra independiente ni un límite de cliente criptográfico.

Nota:

Para las nuevas soluciones de multitenencia, comience con principales de servicio de cliente dedicados, mediante la identidad administrada y las credenciales federadas cuando encajen los requisitos de hospedaje y confianza. Los perfiles siguen siendo una solución válida y opcional para las aplicaciones nuevas y existentes cuyos requisitos se ajustan a sus ventajas y limitaciones. Puede seguir usando perfiles si satisfacen sus requisitos.

Los perfiles no son identidades de Microsoft Entra y no se pueden usar con las API REST de Fabric. Si la solución requiere identidades de cliente para servicios posteriores, registros independientes de inicio de sesión de Microsoft Entra, acceso condicional de identidad de carga de trabajo o funcionalidades limitadas por el modelo de perfil, considere la posibilidad de reemplazar los perfiles de entidad de servicio por entidades de servicio.

Nota:

La palabra inquilino en Power BI a veces puede hacer referencia a un inquilino de Microsoft Entra. Sin embargo, en este artículo se usa el término multitenencia para describir una solución en la que una única instancia de una aplicación de software sirve a varios clientes u organizaciones (inquilinos) que requieren separación física y lógica de los datos. Por ejemplo, el generador de aplicaciones de Power BI puede asignar un área de trabajo independiente para cada uno de sus clientes (o inquilinos) como se describe en este artículo. Estos clientes no son necesariamente inquilinos de Microsoft Entra, por lo que no confunda el término aplicación multiinquilino que usamos aquí, con la aplicación multiinquilino de Microsoft Entra.

Un perfil de entidad de servicio es un perfil creado por una entidad de servicio. La aplicación del ISV llama a las API de Power BI mediante un perfil de entidad de servicio, tal como se explica en este artículo.

La entidad de servicio de la aplicación del ISV crea un perfil de Power BI diferente para cada cliente o inquilino. Cuando un cliente visita la aplicación ISV, la aplicación usa el perfil correspondiente para generar un token de inserción que se usa para representar un informe en el explorador.

El uso de perfiles de entidad de servicio permite que la aplicación del ISV hospede varios clientes en un único inquilino de Power BI. Cada perfil representa un cliente en Power BI. En otras palabras, cada perfil crea y administra el contenido de Power BI para los datos de un cliente específico.

Diagrama de perfiles de entidad de servicio y multiinquilino.

Nota:

Para obtener información general sobre esta alternativa, consulte Perfiles de entidad de servicio: una solución opcional multiinquilino. Los pasos de configuración siguientes se aplican después de seleccionar el modelo de perfil.

La configuración del contenido de Power BI implica los pasos siguientes:

Todos los pasos anteriores se pueden automatizar completamente mediante las API rest de Power BI.

Prerrequisitos

Para poder crear perfiles de entidad de servicio, debe:

Captura de pantalla del interruptor del portal de administración.

Creación de un perfil

Los perfiles se pueden crear, actualizar y eliminar mediante la API REST Profiles.

Por ejemplo, para crear un perfil:

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

Una entidad de servicio también puede llamar a GET Profiles REST API para obtener una lista con sus perfiles. Por ejemplo:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Permisos de perfil

Cualquier API que conceda permiso de usuario a los elementos de Power BI también puede conceder un permiso de perfil a los elementos de Power BI. Por ejemplo, la API Add Group User se puede usar para conceder un permiso de perfil a un área de trabajo.

Los siguientes puntos son importantes para comprender cuándo se usan perfiles:

  • Un perfil pertenece a la entidad de servicio que la creó y solo esa entidad de servicio puede usarla.
  • Un propietario de un perfil no se puede cambiar una vez creado.
  • Un perfil no es una identidad independiente. Necesita el token del principal del servicio de Microsoft Entra para llamar a las API REST de Power BI.

Las aplicaciones del ISV llaman a las API REST de Power BI proporcionando el token de Microsoft Entra de la entidad de servicio en el encabezado Authorization y el identificador de perfil en el encabezado X-PowerBI-Profile-Id. Por ejemplo:

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

Crear un área de trabajo

Las áreas de trabajo de Power BI se usan para hospedar elementos de Power BI, como informes y modelos semánticos.

Cada perfil debe:

  • Crear al menos un área de trabajo de Power BI

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • Conceda permisos de acceso al área de trabajo. El perfil de la entidad de servicio debe tener acceso de Administrador al área de trabajo.

  • Asignar el área de trabajo a una capacidad

    POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

Lea más sobre las áreas de trabajo de Power BI.

Importación de informes y modelos semánticos

Use Power BI Desktop para preparar informes conectados a los datos del cliente o a los datos de ejemplo. A continuación, puede usar la API Import para importar el contenido en el área de trabajo creada.

POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Use parámetros de conjuntos de datos para crear un modelo semántico que pueda conectarse a distintos orígenes de datos de los clientes. A continuación, use la API Actualizar parámetros para definir a qué datos de los clientes se conecta el modelo semántico.

Establecer la conexión del modelo semántico

Los ISV suelen almacenar los datos de sus clientes de una de estas dos maneras:

En cualquier caso, debería acabar teniendo modelos semánticos de un solo inquilino (un modelo semántico por cliente) en Power BI.

Una base de datos independiente para cada cliente

Si la aplicación del ISV tiene una base de datos independiente para cada cliente, cree modelos semánticos monousuario en Power BI. Proporcione a cada modelo semántico detalles de conexión que apunten a su base de datos coincidente. Use uno de los métodos siguientes para evitar la creación de varios informes idénticos con detalles de conexión diferentes:

  • Parámetros del modelo semántico: cree un modelo semántico con parámetros en los detalles de conexión (como el nombre de SQL Server o el nombre de la base de datos SQL). A continuación, importe un informe en el área de trabajo de un cliente y cambie los parámetros para que coincidan con los detalles de la base de datos del cliente.

  • Actualización de la API Update Datasource: cree un archivo .pbix que apunte a un origen de datos con contenido de ejemplo. A continuación, importe el archivo .pbix en el área de trabajo de un cliente y cambie los detalles de conexión mediante la API Update Datasource.

Una sola base de datos de varios inquilinos

Si la aplicación del ISV usa una base de datos para todos sus clientes, separe los clientes en modelos semánticos diferentes en Power BI de la siguiente manera:

Cree un informe mediante parámetros que solo recuperen los datos del cliente pertinentes. A continuación, importe un informe en el área de trabajo de un cliente y cambie los parámetros para recuperar solo los datos del cliente pertinentes.

Inserción de un informe

Una vez completada la instalación, puede insertar informes de clientes y otros elementos en la aplicación mediante un token de inserción.

Cuando un cliente visite la aplicación, use el perfil correspondiente para llamar a la API GenerateToken. Use el token de inserción generado para insertar un informe u otros elementos en el explorador del cliente.

Para generar un token de inserción:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

Aspectos de diseño

Antes de configurar una solución de varios inquilinos basada en perfiles, debe tener en cuenta los siguientes problemas:

Escalabilidad

Al separar los datos en modelos semánticos independientes para cada cliente, se minimiza la necesidad de modelos semánticos de gran tamaño. Cuando se sobrecarga la capacidad, puede expulsar los modelos semánticos sin usar para liberar memoria para los modelos semánticos activos. Esta optimización es imposible para un único modelo semántico de gran tamaño. Mediante el uso de varios modelos semánticos, también puede separar los inquilinos en varias capacidades de Power BI si es necesario.

Sin perfiles, un principal de servicio está limitado a 1000 áreas de trabajo. Para superar este límite, una entidad de servicio puede crear varios perfiles, donde cada perfil puede tener acceso o crear hasta 1000 áreas de trabajo. Con varios perfiles, la aplicación del ISV puede aislar el contenido de cada cliente mediante contenedores lógicos distintos.

Una vez que un perfil de entidad de servicio tiene acceso a un área de trabajo, se puede quitar el acceso de su entidad de servicio principal al área de trabajo para evitar problemas de escalabilidad.

Incluso con estas ventajas, debe tener en cuenta la posible escala de la aplicación. Por ejemplo, el número de elementos del área de trabajo a los que puede tener acceso un perfil es limitado. Hoy en día, un perfil tiene los mismos límites que un usuario normal. Si la aplicación ISV permite a los usuarios finales guardar una copia personalizada de sus informes incrustados, el perfil de un cliente tiene acceso a todos los informes creados de todos sus usuarios. Este modelo puede superar finalmente el límite.

Automatización y complejidad operativa

Con la separación basada en perfiles de Power BI, podría necesitar administrar cientos o miles de elementos. Es importante definir los procesos que se producen con frecuencia en la administración del ciclo de vida de la aplicación y asegurarse de que tiene el conjunto correcto de herramientas para realizar estas operaciones a escala. Entre estas operaciones se incluyen:

  • Adición de un nuevo inquilino
  • Actualización de un informe para algunos inquilinos o todos ellos
  • Actualización del esquema del modelo semántico para algunos inquilinos o todos ellos
  • Habilitación de personalizaciones no planeadas para inquilinos específicos
  • Establecimiento de la frecuencia de las actualizaciones del modelo semántico

Por ejemplo, crear un perfil y un área de trabajo para un nuevo inquilino es una tarea común, que se puede automatizar completamente con la API REST de Power BI.

Necesidades de Multi-Geo

La compatibilidad de Multi-Geo con Power BI Embedded significa que los ISV y las organizaciones que compilan aplicaciones con Power BI Embedded para insertar análisis en sus aplicaciones ahora pueden implementar sus datos en diferentes regiones de todo el mundo. Para admitir a diferentes clientes en diferentes regiones, asigne el área de trabajo del cliente a una capacidad en la región deseada. Esta tarea es una operación sencilla que no implica costos adicionales. Sin embargo, si tiene clientes que necesitan datos de varias regiones, el perfil de inquilino debe duplicar todos los elementos en varias áreas de trabajo asignadas a distintas capacidades regionales. Esta duplicación puede aumentar la complejidad de los costos y la administración.

Por motivos de cumplimiento, es posible que desee crear varios inquilinos de Power BI en distintas regiones. Obtenga más información sobre las zonas geográficas múltiples.

Rentabilidad

Los desarrolladores de aplicaciones que usan Power BI Embedded deben adquirir la capacidad de Power BI Embedded. El modelo de separación basado en perfiles funciona bien con capacidades porque:

  • El objeto más pequeño que puede asignar de forma independiente a una capacidad es un área de trabajo (por ejemplo, no se puede asignar un informe). Al separar los clientes por perfiles, obtiene áreas de trabajo diferentes: una por cliente. De este modo, puede obtener una flexibilidad total para gestionar cada cliente según sus necesidades de rendimiento y optimizar la utilización de la capacidad mediante el escalado hacia arriba o hacia abajo. Por ejemplo, puede administrar clientes grandes y esenciales con alto volumen y volatilidad en una capacidad separada para garantizar un nivel de servicio coherente, agrupando los clientes más pequeños en otra capacidad para optimizar los costos.

  • Las áreas de trabajo separadas implican también la separación de los modelos semánticos entre inquilinos para que los modelos de datos puedan estar en fragmentos más pequeños, en lugar de en un único modelo semántico de gran tamaño. Estos modelos más pequeños permiten administrar el uso de memoria de forma más eficaz. Los modelos semánticos pequeños y sin usar se pueden expulsar después de un período de inactividad, con el fin de mantener un buen rendimiento.

Al comprar una capacidad, debe tener en cuenta el límite del número de actualizaciones paralelas, ya que los procesos de actualización pueden requerir capacidad adicional al tener varios modelos semánticos.

Seguridad de nivel de fila

En este artículo se explica cómo usar perfiles para crear un modelo semántico independiente para cada cliente. Como alternativa, las aplicaciones del ISV pueden almacenar todos los datos de sus clientes en un modelo semántico de gran tamaño y usar la seguridad de nivel de fila (RLS) para proteger los datos de cada cliente. Este enfoque puede ser conveniente para los ISV que tienen relativamente pocos clientes y modelos semánticos pequeños a medianos porque:

  • Solo tienen que mantener un informe y un modelo semántico
  • El proceso de incorporación para los nuevos clientes se puede simplificar

Sin embargo, antes de usar RLS, asegúrese de comprender sus limitaciones. Todos los datos de todos los clientes se encuentran en un modelos semánticos de Power BI de gran tamaño. Este modelo semántico se ejecuta en una sola capacidad con su propio escalado y otras limitaciones.

Incluso si usa perfiles de entidad de servicio para separar los datos de los clientes, puede seguir usando RLS dentro del modelo semántico de un solo cliente para conceder a distintos grupos acceso a diferentes partes de los datos. Por ejemplo, podría usar RLS para impedir que los miembros de un departamento accedan a los datos de otro departamento de la misma organización.

Consideraciones y limitaciones

Evalúe los límites de autenticación, API y escala antes de elegir o ampliar el modelo de perfil.

Limitaciones de identidad y API

Revise estas limitaciones antes de adoptar perfiles o ampliar una solución basada en perfiles existente:

Limitation Lo que significa para su solución
No es una identidad de Microsoft Entra Un perfil solo existe en Power BI. No puede controlar ni revisarlo de forma independiente a través de herramientas de Microsoft Entra ni conceder permisos como identidad en los servicios posteriores. Por ejemplo, un perfil no puede ser la identidad de una conexión de Direct Lake desde un modelo semántico a una instancia de lakehouse o un warehouse.
No se admite la API REST de Fabric Los perfiles funcionan a través de la API REST de Power BI, el SDK de Power BI .NET y las interfaces XMLA/TOM compatibles. Las API REST de Fabric no las admiten y no se planea la compatibilidad.
No hay ninguna identidad de inicio de sesión independiente Las operaciones con ámbito de perfil no generan registros de inicio de sesión de Microsoft Entra independientes para cada cliente. Los registros de actividad de Power BI todavía pueden identificar perfiles.
Sin acceso condicional por perfil Un perfil no es una entidad de servicio a la que el acceso condicional de identidad de carga de trabajo puede aplicar. Las políticas para las entidades de servicio dedicadas elegibles tienen requisitos de licencias y configuración independientes.
Vinculado a la entidad de seguridad que lo creó No se pueden transferir perfiles entre entidades de servicio principales primarias. Cambiar el elemento principal requiere volver a crear perfiles, restaurar el acceso al área de trabajo y actualizar las asignaciones de clientes.
Administración solo por API Los perfiles no tienen ninguna interfaz de usuario de administración dedicada para inspeccionarlos y administrarlos. No están representados en el centro de administración de Microsoft Entra.

Si estas limitaciones restringen la solución, consulte Reemplazar perfiles de entidad de servicio por entidades de servicio. Para los clientes que eligen migrar, esa guía recomienda la identidad administrada y las credenciales federadas cuando los requisitos de hospedaje y confianza lo permitan. La autenticación directa mediante una entidad de servicio sigue siendo una alternativa.

Interfaces admitidas y límites de escalado

  • Los perfiles de entidad de servicio solo se admiten a través de la API de REST de Power BI, el SDK de Power BI .NET y a través del punto de conexión XMLA y el modelo de objetos tabulares (TOM) al usar las bibliotecas cliente de Analysis Services versión 16.0.139.27 o posteriores. Los perfiles de entidad de seguridad no son compatibles con Power BI a través del punto de conexión XMLA o el Modelo de objetos tabulares (TOM) con bibliotecas cliente anteriores.
  • Los perfiles de entidad de servicio no se admiten con Azure Analysis Services (AAS) en modo de conexión dinámica.
  • El máximo de perfiles que un único principal del servicio puede tener es de 100,000.

Limitaciones de capacidad de Power BI

Administración de entidades de servicio

Cambiar una entidad de servicio

En Power BI, un perfil pertenece a la entidad de servicio que la creó. Esto significa que un perfil no se puede compartir con otros principales. Con esta limitación, si desea cambiar la entidad de servicio por cualquier motivo, debe volver a crear todos los perfiles y proporcionar a los nuevos perfiles acceso a las áreas de trabajo pertinentes. A menudo, la aplicación del ISV debe guardar una asignación entre un identificador de perfil y un identificador de cliente para elegir el perfil correcto cuando sea necesario. Si cambia la entidad de servicio y vuelve a crear los perfiles, los identificadores también cambiarán y es posible que tenga que actualizar la asignación en la base de datos de la aplicación del ISV.

Eliminar un principal de servicio

Advertencia

Tenga cuidado al eliminar una entidad de servicio. No desea perder accidentalmente datos de todos sus perfiles asociados.

Si elimina la entidad de servicio en Active Directory, se eliminan todos sus perfiles en Power BI. Sin embargo, Power BI no elimina el contenido inmediatamente, por lo que el administrador de inquilinos todavía puede acceder a las áreas de trabajo. Tenga cuidado al eliminar una entidad de servicio que se usa en un sistema de producción, especialmente cuando haya creado perfiles con esta entidad de servicio en Power BI. Si elimina una entidad de servicio que ha creado perfiles, debe volver a crear todos los perfiles, proporcionar a los nuevos perfiles acceso a las áreas de trabajo pertinentes y actualizar los identificadores de perfil en la base de datos de la aplicación ISV.

Separación de datos

Al usar perfiles de entidad de seguridad, la aplicación debe asignar cada cliente autenticado al perfil correcto y a los recursos permitidos. Los permisos del área de trabajo y los tokens de inserción con ámbito adecuado controlan el acceso. Un perfil no es una identidad Microsoft Entra independiente y su entidad de servicio principal puede actuar a través de cualquier perfil que cree.

Tenga en cuenta las entidades de seguridad de servicio dedicadas cuando la solución requiera gobernanza de Microsoft Entra, supervisión de inicio de sesión independiente, directivas de Acceso condicional aplicables a identidades de carga de trabajo, identidades de servicios posteriores o acceso a la API REST de Fabric. También son una alternativa cuando el acoplamiento del perfil con el elemento principal o la administración solo de API crea dificultades operativas. Si los perfiles cumplen sus requisitos, puede seguir usándolos.

Los principales de servicio dedicados permiten administrar los permisos del cliente y la autenticación de forma independiente. Si usa certificados almacenados, puede rotarlos por separado para cada cliente. Sin embargo, el impacto de una pérdida de credenciales o un compromiso del entorno de ejecución depende de las credenciales del cliente o de las confianzas federadas que el tiempo de ejecución pueda usar. Ninguna de las dos arquitecturas garantiza automáticamente el aislamiento entre clientes.

Gestionar identidades dedicadas presenta límites de objetos de directorio y trabajo de gestión del ciclo de vida. Evalúe esas compensaciones y siga Reemplazar perfiles de entidad de servicio por entidades de servicio si decide migrar. Mantenga la configuración de los datos que se van a mostrar a un usuario final en el back-end al generar el token de inserción. Valide la membresía del cliente antes de seleccionar una identidad, un área de trabajo o contenido.

Un informe, varios modelos semánticos

Por lo general, tiene un informe y un modelo semántico por inquilino. Si tiene cientos de informes, tendrá cientos de modelos semánticos. A veces, es posible que tenga un formato de informe, con distintos modelos semánticos (por ejemplo, parámetros o detalles de conexión diferentes). Cada vez que tenga una nueva versión del informe, debe actualizar todos los informes de todos los inquilinos. Aunque puede automatizar este proceso, es más fácil administrar si solo tiene una copia del informe. Cree un área de trabajo que contenga el informe que quiere insertar. Durante el tiempo de ejecución de la sesión, enlace el informe al modelo semántico específico del inquilino. Lea el artículo sobre enlaces dinámicos para obtener más detalles.

Personalización y creación de contenido

Al crear contenido, tenga en cuenta cuidadosamente a quién permite editarlo. Si permite que varios usuarios de cada inquilino lo editen, es fácil superar las limitaciones del modelo semántico. Si decide proporcionar esta capacidad de edición a los usuarios, es recomendable supervisar estrechamente la generación de contenido y escalar verticalmente según sea necesario. Por las mismas razones, no se recomienda usar esta capacidad para la personalización de contenido, donde cada usuario puede realizar pequeños cambios en un informe y guardarlo por su cuenta. Si la aplicación del ISV permite la personalización de contenido, considere la posibilidad de introducir directivas de retención del área de trabajo para contenido específico del usuario. Las directivas de retención facilitan la eliminación de contenido cuando los usuarios pasan a una nueva posición, dejan la empresa o dejan de usar la plataforma.

Identidad administrada por el sistema

En lugar de una entidad de servicio, puede usar unaidentidad administrada asignada por el usuario o asignada por el sistema para crear perfiles. Las identidades administradas reducen la necesidad de secretos y certificados.

Nota:

Una identidad administrada que crea y usa perfiles no convierte esos perfiles en identidades de Microsoft Entra ni habilita su uso con Fabric API REST. Esta condición difiere del uso de la identidad administrada y las credenciales federadas para autenticarse como entidades de servicio dedicadas al cliente. Consulte Reemplazar perfiles de entidad de servicio por entidades de servicio.

Tenga cuidado al usar una identidad administrada por el sistema porque:

  • Si se desactiva accidentalmente una identidad administrada asignada por el sistema, se pierde el acceso a los perfiles. Esta situación es similar a un caso en el que se elimina un principal del servicio.
  • Una identidad administrada asignada por el sistema está conectada a un recurso de Azure (aplicación web). Si elimina el recurso, también se elimina la identidad.
  • El uso de varios recursos (diferentes aplicaciones web en regiones diferentes) da como resultado varias identidades que deben administrarse por separado (cada identidad tiene sus propios perfiles).

Debido a las consideraciones anteriores, se recomienda usar una identidad administrada asignada por el usuario.

Ejemplo

Para obtener un ejemplo de cómo usar perfiles de entidad de servicio para administrar un entorno multitenant con la inserción de Power BI y App-Owns-Data, descargue el repositorio App owns data multitenant de Power BI Dev Camp (sitio de terceros).

Contenido relacionado

  • Darrera actualització el