Los eventos mundiales desde marzo de 2020 han destacado uno de los principales beneficios de Office 365 y los servicios SaaS basados en la nube en general: están disponibles en cualquier momento, en cualquier lugar y en cualquier dispositivo. A medida que el mundo se vio obligado a trabajar desde casa, las aplicaciones de Office 365 como Teams, Outlook, SharePoint y OneDrive podían accederse fácilmente fuera de la red empresarial tradicional e incluso en dispositivos que no pertenecen a la empresa. De hecho, la mayoría de las suscripciones de Office 365 y Microsoft 365 permiten a los usuarios instalar y utilizar sus aplicaciones en hasta cinco dispositivos.

Una de sus principales preocupaciones como resultado de esto puede ser la prevención de pérdida de datos. Por ejemplo, de forma predeterminada, un usuario puede autenticarse en su OneDrive corporativo o en su buzón de correo en un dispositivo personal sin ninguna limitación en la capacidad de sincronizar todos los archivos y correos electrónicos alojados en ese servicio. ¿Qué sucede con las copias locales de los datos cuando ese usuario abandona la organización?

Azure Active Directory Conditional Access puede devolver el control a los administradores. Como parte de la licencia Premium P1 de Azure Active Directory, con Conditional Access se controlan las condiciones bajo las cuales un usuario recibe o se le niega el acceso a los recursos de Azure AD. Incluso si se otorga acceso, se pueden aplicar medidas adicionales, como responder a una solicitud de autenticación multifactor (MFA), o determinar cuánto tiempo debe transcurrir antes de que deban iniciar sesión de nuevo.

Cómo Conditional Access identifica los dispositivos corporativos

En nuestro escenario, utilizaremos Conditional Access para permitir que los usuarios inicien sesión en Office 365 solo en dispositivos corporativos. Esto se basa en el estado del dispositivo.

Aunque no existe un estado de dispositivo llamado “dispositivo empresarial” en Acceso condicional, podemos identificar dos cosas sobre un dispositivo e inferir a partir de ellas que este es de propiedad corporativa:

1. ¿Está el dispositivo unido a Azure AD híbrido?
2. ¿Está el dispositivo marcado como conforme?

Unión a Azure AD híbrido se refiere a un estado en el que un dispositivo está unido a su Active Directory local, pero también está sincronizado y unido al Azure AD basado en la nube. Hemos cubierto cómo llevar tus dispositivos a este estado aquí. Esto es solo adecuado para dispositivos Windows.

En la captura de pantalla a continuación, puedes ver cómo Azure AD informa sobre el tipo de unión a Azure AD híbrido.

Marcado como conforme significa que el dispositivo está inscrito en una solución de administración de dispositivos móviles, como Intune, y cumple con los requisitos de cumplimiento de esa solución de MDM, como tener un firewall activo. En muchos aspectos, este es un mejor control que solo verificar la pertenencia de dominio del dispositivo, ya que también estás asegurando un nivel de postura de seguridad, lo cual es beneficioso para una estrategia de confianza cero. Sin embargo, si solo te interesa confirmar que el dispositivo está inscrito en Intune, podrías establecer una política de cumplimiento sin requisitos de seguridad específicos. Este método se puede utilizar para las “cuatro principales” plataformas modernas: Windows 10, macOS, iOS y Android.

En la captura de pantalla a continuación, se puede ver cómo Intune informa sobre el cumplimiento del dispositivo.

Estrictamente hablando, el término correcto para un dispositivo en cualquiera de estos estados es un dispositivo administrado. Esto significa que un administrador de IT tiene cierto nivel de control sobre ese dispositivo, como la capacidad de aplicar y controlar configuraciones ya sea desde Directiva de grupo o Intune. Los dispositivos en ninguno de estos estados son considerados no administrados. Suponiendo que hemos limitado la capacidad de inscripción en Intune solo a dispositivos corporativos, razonablemente podemos usar los términos administrado y corporativo indistintamente.

Un punto importante a tener en cuenta es que Azure AD puede solicitar información de certificado a algunas plataformas y navegadores si se utiliza una política de acceso condicional basada en el estado del dispositivo. Esto suele ocurrir en plataformas no basadas en Microsoft, como las plataformas de Apple y Google. Esto se debe a que la información del estado del dispositivo se encuentra dentro de un certificado en ese dispositivo, y no todo el software lo pone automáticamente a disposición de Azure AD durante la autenticación.

Creación de la política de acceso condicional

Las políticas de acceso condicional se crean dentro de Azure AD > Seguridad > Acceso condicional. La mejor práctica es darle a su política un nombre que facilite exactamente identificar lo que la política tiene como objetivo lograr. Esto se debe a que si varias políticas coinciden con un intento de autenticación, todas se aplican, y una buena convención de nombres simplifica la resolución de problemas y la gestión.

Las políticas se dividen en asignaciones y controles de acceso. Las asignaciones son equivalentes a una lista de verificación de todo lo que debe ser cierto sobre el inicio de sesión para que la política se aplique al inicio de sesión. En la mayoría de estos ajustes, puedes incluir y excluir condiciones. Por ejemplo, incluir todos los usuarios pero excluir el personal de TI. Si la política se aplica, entonces los controles de acceso determinan si se niega o se permite el acceso y, cuando se permite, qué otros pasos y medidas deben aplicarse o ser ciertos.

Antes de sumergirse en Acceso Condicional, es importante considerar lo poderoso que es: te da la capacidad de bloquear completamente la autenticación a todas las aplicaciones. Por lo tanto, podrías configurar algo incorrectamente y bloquear a usuarios importantes de aplicaciones importantes, o incluso a todos los administradores. Deberías considerar crear excepciones para cuentas de acceso de emergencia de rompimiento de seguridad cuya actividad de inicio de sesión monitoreas. Personalmente, este es el primer paso que tomo al crear cualquier política de Acceso Condicional.

Asignaciones

Usuarios y grupos controlan a quiénes se aplicará la política. Si no estás en esta asignación, no estás sujeto a sus reglas. Para una política que bloquee el acceso a Office 365 en dispositivos no administrados, podrías desear limitarla a todos los usuarios pero excluir invitados/usuarios externos y las cuentas de acceso de emergencia. Alternativamente, incluir solo un grupo de Azure AD apropiado.

Para aplicaciones o acciones en la nube, selecciona Office 365. Puedes seleccionar más de una aplicación en la nube, por lo que es posible que desees crear una política que limite todas las aplicaciones que consideres sensibles, no solo Office 365. La aplicación de Office 365 que se muestra en Acceso Condicional es en realidad una colección de otras aplicaciones que puedes seleccionar individualmente. Por ejemplo, incluye Exchange Online y SharePoint Online, pero en teoría puedes elegir solo las aplicaciones componentes. La razón por la que deseas seleccionar Office 365 y no ninguna de sus partes componentes se debe a la naturaleza integrada del servicio. Seleccionar la plataforma unificada reduce los problemas asociados con las dependencias que tienen entre sí.

Las condiciones son donde especificas señales y propiedades de autenticación como direcciones IP, sistemas operativos y aplicaciones (que, hablando en términos generales, significa acceso web o de aplicaciones cliente). En nuestro ejemplo, bloquearemos el acceso a todos los métodos de acceso de Office 365, por lo que no especifiques ninguna condición. Esto significa que se aplican todas las condiciones. Un uso común de estas condiciones, sin embargo, es tener reglas diferentes para el acceso web y el acceso de aplicaciones de escritorio.

También notarás la condición del estado del dispositivo aquí, pero en realidad no la seleccionaremos para esta política. Sigue leyendo para ver por qué.

Controles de acceso

Ahora que hemos tratado el elemento “si esto…” de nuestra política, es hora del “entonces eso…”. Los controles de acceso se dividen en ajustes de concesión y sesión.

En el panel de concesión, selecciona conceder acceso y marca las casillas para dispositivo requerido para ser marcado como compatible y requerir dispositivo unido a Azure AD híbrido. También tendrás la opción de elegir si el dispositivo debe ser ambos, o uno u otro. La recomendación es seleccionar requerir uno de los controles seleccionados para que tanto los dispositivos unidos al dominio local como los dispositivos unidos solo a Azure AD puedan obtener acceso.

Lo que hemos hecho aquí es decir “puedes obtener acceso, pero necesitas un dispositivo gestionado”. Dicho de otra manera, también significa “no puedes obtener acceso a menos que seas un dispositivo gestionado”. Suponiendo que nuestro proceso de unión al dominio local sea seguro, y nuestra inscripción en Intune esté limitada a dispositivos corporativos, esto limita todo el acceso a Office 365 a dispositivos corporativos.

La configuración de la sesión controla lo que un usuario puede hacer una vez que se le concede acceso. Por ejemplo, en sesiones de navegador web, puedes utilizar restricciones impuestas por la aplicación para bloquear descargas desde servicios como Exchange Online y SharePoint Online. Con suerte, esto te hace pensar en las diversas formas en que puedes dar forma a tus políticas: potencialmente una para bloquear el acceso a aplicaciones completas en dispositivos no gestionados, pero otra que permita el acceso solo a aplicaciones web, imponiendo la prohibición de descargas.

Implementando la política de Acceso Condicional

Con la configuración aplicada, tu política de Acceso Condicional ahora puede estar en modo informe o activo. La intención del modo informe es permitir a los registros de inicio de sesión de Azure AD auditar lo que habría sucedido sin interrumpir el entorno de producción. Entonces puedes utilizar esta información para comprender las consecuencias de la política: por ejemplo, ¿qué interrupciones podemos esperar y, por lo tanto, qué tipo de educación debemos brindar a nuestros usuarios?

Hay una advertencia importante para el modo informe en nuestro caso. Como se mencionó anteriormente, para que Azure AD determine el estado del dispositivo, necesita consultar un certificado, y algunas plataformas no permiten esto automáticamente. Aunque estés operando en modo informe, sigue necesitando ese certificado para saber qué es lo que hubiera podido hacer. Siempre recibirás una advertencia sobre esto en las políticas si incluyes configuraciones basadas en el estado del dispositivo.

Cuando estés seguro de que tu política ha sido configurada correctamente y no afectará negativamente al negocio, simplemente cambia el estado a activo, momento en el cual la política se aplicará inmediatamente en los intentos de autenticación futuros en Azure AD.

Experiencia del usuario

Si un usuario intenta acceder a cualquier recurso de Office 365 desde un dispositivo no corporativo (cumpla con Intune o esté unido a Azure AD híbrido), Azure AD les informará que el acceso está bloqueado. Esto es válido para cualquier medio de acceso, ya sea mediante una aplicación web o una aplicación cliente completa. Nuevamente, puedes utilizar condiciones para establecer reglas diferentes para aplicaciones web y aplicaciones cliente.

En los dispositivos corporativos, el proceso de autenticación no cambia en lo que respecta al usuario: podrán ingresar directamente. La única excepción a esto es cuando esa aplicación no puede verificar el estado del dispositivo. Esto no debería ser un problema para las aplicaciones de primera parte como la suite Office 365, pero por ejemplo, puede ser un problema con los navegadores de terceros, incluso en Windows. Es posible que tus usuarios reciban un error similar al de la captura de pantalla anterior. Chrome para Windows soporta el estado del dispositivo si se utiliza la extensión Windows 10 Accounts y, como puedes imaginar, Edge basado en Chromium lo soporta de forma estándar.

Artículo relacionado:

• Por qué deberías restringir el acceso a Office 365 mediante las políticas de acceso condicional de Microsoft