Cada día, más y más organizaciones están usando Power BI para ayudarles a adoptar una cultura basada en datos, donde cada persona puede obtener valor de los datos. Esto se logra por medio de los usuarios de negocio que tomarán decisiones y llevaran a cabo acciones basadas en los conocimientos que encuentran en los informes y dashboards construidos por ellos mismos o que han sido compartidos con ellos. Las organizaciones deben ser capaces de gobernar este escenario de BI de manera efectiva y al mismo tiempo cumplir con las regulaciones, como GDPR, y sus propios requerimientos de seguridad.

Vamos a ver como definir políticas de acceso condicional al servicio de Power BI que proporcionen controles contextuales a nivel de usuario o grupo, ubicación, dispositivo y aplicación. En su forma más simple, las directivas de acceso condicional son instrucciones if-then; si un usuario desea tener acceso a un recurso, deben completar una acción. Ejemplo: un responsable de nóminas desea acceder a la aplicación de nóminas y es necesario para realizar la autenticación multifactor para tener poder hacerlo.

Los administradores se enfrentan a dos objetivos principales:

    • Capacitar a los usuarios para ser productivos donde sea y cuando sea.
    • Proteger los recursos de la organización.

Mediante el uso de directivas de acceso condicional puede aplicar los controles de acceso correctos cuando sea necesario para mantener la organización segura y no interferir con los usuarios cuando no se necesita.

 

conditional access overview

 

Para ello debemos ir al portal de azure (https://portal.azure.com) y acceder a Azure Active Directory, que lo podemos encontrar en el menú lateral o preguntar por él en el buscador.

 

portal-azure-active-directoryportal-azure-active-directory2

 

Dentro de Azure Active Directory tenemos que ir a Enterprise Applications o Aplicaciones Empresariales.

 

enterprise-applications

 

Aquí se mostrarán las diferentes aplicaciones que tiene la organización y debemos de seleccionar Power BI Service. Se recomienda utilizar el buscador cuando existen muchas aplicaciones en la organización.

 

enterprise-all-applications

 

En la sección de Seguridad, accedemos a Acceso Condicional (Conditional Access).

 

security conditional access

 

Azure AD Conditional Access requiere Azure AD Premium P2 para acceder a las funciones de seguridad avanzadas.

 

Para obtener una prueba gratis de Azure AD Premium P2 tienes que seguir estos 3 pasos:

 

free-trial-azure-ad-premium-p2

 

A partir de este momento se pueden crear las diferentes políticas de acceso, en nuestro caso vamos a crear una para bloquear el acceso desde los dispositivos móviles. Para ello, pinchamos en New policy.

 

 

Asignamos un nombre reconocible a la política, ya que, cuando existen varias de ellas es más fácil identificar su función mediante el nombre. En nuestro caso, la política de acceso se llamará Restrincting Device Platforms.

A continuación, se va a explicar cada una de las opciones, así como un ejemplo de configuración de la misma.

 

Users and groups / Usuarios y grupos

 

La condición de usuarios y grupos es obligatoria en una política de acceso condicional. Podemos seleccionar Todos los usuarios o seleccionar usuarios y grupos específicos. Cuando se selecciona Todos los usuarios, la política se aplica a todos los usuarios del directorio, incluidos los usuarios invitados.

Al seleccionar usuarios y grupos, puede configurar las siguientes opciones:

    • Todos los usuarios invitados y usuarios externos (All guest and external users): Esta condición coincide con cualquier cuenta de usuario que tenga el atributo userType establecido como invitado (guest).
    • Roles de directorio: Tienen como objetivo una política basada en la asignación de roles de un usuario. Esta condición es compatible con funciones de directorio como Administrador global o Administrador de contraseñas.
    • Usuarios y grupos: Tienen como objetivo conjuntos específicos de usuarios. Por ejemplo, puedes seleccionar un grupo que contenga todos los miembros del departamento de personal.

Dirigirse a conjuntos específicos de usuarios es útil para la implementación de una nueva política. En una nueva política, se debe dirigir solo a un conjunto inicial de usuarios para validar el comportamiento de la política. En nuestro caso vamos a seleccionar un usuario para esta política. Seleccionando la opción de usuarios y grupos (users and groups).

 

 

Cloud apps and actions / Aplicaciones y acciones en la nube

 

Una aplicación en la nube es un sitio web o servicio protegido por Azure AD Application Proxy. La condición de aplicaciones o acciones en la nube es obligatoria en una directiva de acceso condicional. En la política, se puede seleccionar Todas las aplicaciones de nube o especificar aplicaciones con Seleccionar aplicaciones:

    • Todas las aplicaciones de la nube: Se utiliza esta opción para las políticas que requieren autenticación multifactor cuando se detecta un riesgo de inicio de sesión para cualquier aplicación de nube. Se aplica a todas las aplicaciones de la organización (sitios web y servicios). Esta configuración no se limita a las aplicaciones de nube que aparecen en la lista Seleccionar aplicaciones.
    • Seleccionar aplicaciones: Se dirigen a servicios específicos como por ejemplo Power BI Service.

Nos debe de aparecer la aplicación Power BI Service ya seleccionada. Aquí no debemos de hacer nada más.

 

 

Esta opción NO aplica para la política de acceso condicional de este ejemplo.

 

Conditions

 

Llegamos a uno de los puntos clave a configurar, las condiciones. En este apartado debemos de seleccionar cuales van a ser las condiciones para que se realice la acción (bloquear o permitir acceso) que definiremos más adelante. Existen 5 condiciones:

 

Sign-in Risk / Riesgo de inicio de sesión

Un riesgo de inicio de sesión es un indicador (alto, medio o bajo) de que el propietario legítimo de una cuenta de usuario no haya iniciado sesión. Azure AD calcula el nivel de riesgo de inicio de sesión durante el inicio de sesión de un usuario. Puede utilizar el nivel de riesgo de inicio de sesión calculado como condición en una política de acceso condicional.

Para utilizar esta condición, debe estar habilitada la función Azure Active Directory Identity Protection.

Los casos de uno más comunes para esta condición son las directivas que tienen las siguientes protecciones:

      • Bloquear usuarios con un alto riesgo de inicio de sesión. Esta protección evita que usuarios potencialmente no legítimos accedan a sus aplicaciones en la nube.
      • Requerir autenticación multifactor para los usuarios con riesgo de inicio de sesión medio. Al aplicar la autenticación multifactor, puede proporcionar una confianza adicional en que el inicio de sesión lo realiza el propietario legítimo de una cuenta.
Esta opción NO aplica para la política de acceso condicional de este ejemplo.

 

Device platforms / Plataformas de dispositivos

Se caracteriza por el sistema operativo que funciona en el dispositivo. Azure AD identifica la plataforma utilizando la información proporcionada por el dispositivo. Esta información no está verificada. Se recomienda que todas las plataformas tengan una política aplicada a ellas.

Para nuestra política vamos a seleccionar las plataformas de los dispositivos móviles (Android, iOS y Windows Phone)

 

Locations / Ubicaciones

 

Al utilizar las ubicaciones, puedes definir condiciones basadas en el lugar donde se intentó la conexión. Los casos de uso más comunes para esta condición son las políticas con las siguientes protecciones:

      • Requerir autenticación mutlifactor para los usuarios que acceden a un servicio cuando están fuera de la red corporativa.
      • Bloquear el acceso de los usuarios que acceden a un servicio desde países o regiones específicas.
Esta opción NO aplica para la política de acceso condicional de este ejemplo.

Client apps / Aplicaciones para clientes

 

Por defecto, una política de acceso condicional se aplica a las siguientes aplicaciones:

      • Aplicaciones de navegador: Las aplicaciones de navegador incluyen sitios web que utilizan los protocolos SAML, WS-Federation u OpenID Connect web SSO. Esto también se aplica a cualquier sitio web o servicio web que haya sido registrado como cliente confidencial OAuth. Por ejemplo, el sitio web de Office 365 SharePoint.
      • Aplicaciones móviles y de escritorio que usan autenticación moderna: Estas aplicaciones incluyen las aplicaciones de escritorio de Office y las aplicaciones para teléfonos.

Además, se puede orientar una directiva a aplicaciones de cliente especificas que no usen autenticación moderna, por ejemplo:

      • Clientes de Exchange ActiveSync: Cuando una directiva bloquea el uso de Exchange ActiveSync, los usuarios afectados reciben un único mensaje de correo electrónico de cuarentena con información sobre el motivo del bloqueo. Si es necesario, el correo electrónico incluye instrucciones para inscribir su dispositivo en Intune.
      • Otros clientes: Estas aplicaciones incluyen clientes que usan autenticación básica con protocolos de correo como IMAP, MAPI, POP, SMTP y aplicaciones de Office más antiguas que no usan autenticación moderna.

Los casos de uso más comunes para esta condición son las directivas con los siguientes requisitos:

      • Requerir un dispositivo administrado para aplicaciones móviles y de escritorio que descarguen datos en un dispositivo. Al mismo tiempo, permitir el acceso al explorador desde cualquier dispositivo. Este escenario impide guardar y sincronizar documentos en un dispositivo no administrado. Con este método, puede reducir la probabilidad de pérdida de datos si el dispositivo se pierde o es robado.
      • Requiere un dispositivo administrado para que las aplicaciones que utilizan ActiveSync accedan a Exchange Online.
      • Bloquear la autenticación heredada en Azure AD (otros clientes)
      • Bloquee el acceso desde las aplicaciones web, pero permite el acceso desde las aplicaciones móviles y de escritorio.
Esta opción NO aplica para la política de acceso condicional de este ejemplo.

 

Device state / Estado del dispositivo

La condición de estado de los dispositivos excluye los dispositivos híbridos unidos a Azure AD y los dispositivos marcados como compatibles de una política de acceso condicional. Esta condición es útil cuando una política debería aplicarse solo a un dispositivo no gestionado para proporcionar una seguridad de sesión adicional.

Esta opción NO aplica para la política de acceso condicional de este ejemplo.

 

Access Controls / Controles de acceso

La parte de controles de acceso controla cómo se aplica una política. En este bloque encontramos dos opciones:

Grant

Block Access

Bloquear el acceso hace justamente eso, bloqueará el acceso bajo las asignaciones especificadas.

Grant Access

El grant control puede desencadenar la aplicación de uno o más controles

        • Requerir autenticación multifactor (Azure Multi-Factor Authentication)
        • Requerir que el dispositivo esté marcado como conforme (Intune)
        • Requerir Hybrid Azure AD joined device (saber más)
        • Requerir una aplicación de cliente aprobada
        • Requerir una política de protección de aplicaciones (preview)

Los administradores pueden elegir entre requerir uno de los controles anteriores o todos los controles seleccionados. El valor predeterminado para los controles múltiples es requerir todos.

Para nuestra política, usaremos la opción de bloquear el acceso cuando se cumplan las condiciones que hemos especificado anteriormente (dispositivos móviles)

 

 

Sesión

Los controles de sesión pueden limitar la experiencia

      • Usar las restricciones impuestas por la aplicación
        • Actualmente funciona solo con Exchange Online y SharePoint Online.
          • Pasa la información del dispositivo para permitir el control de la experiencia otorgando un acceso completo o limitado
      • Usar el control de aplicaciones de acceso condicional
        • Utiliza las señales de Microsoft Cloud App Security para hacer cosas como:
          • Bloquear la descarga, corte, copia e impresión de documentos sensibles.
          • Requerir el etiquetado de archivos sensibles
      • Frecuencia de inicio de sesión
        • Posibilidad de cambiar la frecuencia de inicio de sesión por defecto para la autenticación moderna.
      • Sesión de navegador persistente
        • Permite a los usuarios permanecer conectados después de cerrar y reabrir la ventana del navegador
Esta opción NO aplica para la política de acceso condicional de este ejemplo.

Una vez hayamos configurado todo, habilitamos la política y le damos a guardar para crearla.

Como resumen de la política de acceso condicional, se define la respuesta (“hacer esto”) a la razón de la activación de su política (“cuando esto ocurra”). En el contexto del acceso condicional:

    • “Cuando esto ocurra” se llama condiciones
    • “Entonces haz esto” se llama controles de acceso

Por lo tanto, usando nuestra política, cuando queramos acceder al servicio de Power BI desde algún dispositivo móvil se nos bloqueará el acceso

Si quieres dar forma a tu proyecto con Power BI, en SolidQ podemos guiarte en el proceso (mentoring), ayudarte a su desarrollo mediante nuestro framework, así como formarte en aquellas áreas que necesites. Consulta todos nuestros cursos de 0 a experto con Power BI, desde nuestro curso de Power BI para usuarios de negocio hasta formación más avanzada como DAX, Data Governance o Power Query.