En este artículo se describe una arquitectura de acceso condicional que cumple los principios de Confianza cero. La arquitectura usa un enfoque basado en rol para formar un marco de acceso condicional estructurado.
Arquitectura de Confianza cero de acceso condicional
Primero debe elegir una arquitectura. Se recomienda considerar una arquitectura de acceso condicional de Confianza cero o de destino. En este diagrama se muestra la configuración correspondiente:
La arquitectura de acceso condicional de Confianza cero es la que mejor se ajusta a los principios de Confianza cero. Si selecciona la opción Todas las aplicaciones en la nube en una directiva de acceso condicional, todos los puntos de conexión están protegidos por los controles de concesión proporcionados, como un usuario conocido y un dispositivo conocido o compatible. Pero la directiva no solo se aplica a los puntos de conexión y las aplicaciones que admiten el acceso condicional. Se aplica a cualquier punto de conexión con el que interactúe el usuario.
Un ejemplo es un punto de conexión de flujo de inicio de sesión del dispositivo que se usa en varias herramientas nuevas de PowerShell y Microsoft Graph. El flujo de inicio de sesión del dispositivo proporciona una manera de permitir el inicio de sesión desde un dispositivo en el que no es posible mostrar una pantalla de inicio de sesión, como un dispositivo IoT.
Se ejecuta un comando de inicio de sesión basado en dispositivos en el dispositivo específico y se muestra un código al usuario. Este código se usa en otro dispositivo. El usuario va a https://aka.ms/devicelogin y especifica su nombre de usuario y contraseña. Después de iniciar sesión desde el otro dispositivo, el inicio de sesión se realiza correctamente en el dispositivo IoT en ese contexto de usuario.
El desafío de este inicio de sesión es que no admite el acceso condicional basado en dispositivos. Esto significa que nadie puede usar las herramientas y los comandos si aplica una directiva de base de referencia que requiere un usuario y dispositivo conocidos para todas las aplicaciones en la nube. Hay otras aplicaciones que tienen el mismo problema con el acceso condicional basado en dispositivos.
La otra arquitectura, la de destino, se basa en el principio de que solo tiene como destino las aplicaciones individuales que desea proteger en las directivas de acceso condicional. En este caso, el inicio de sesión del dispositivo para puntos de conexión cubiertos anteriormente por todas las aplicaciones en la nube, como las llamadas de grafos a Microsoft Entra ID, no está protegido por las directivas de acceso condicional, por lo que siguen funcionando.
Al usar el inicio de sesión del dispositivo como ejemplo para diferenciar las dos arquitecturas, puede autenticarse con este. El inicio de sesión del dispositivo puede permitirse para una o varias aplicaciones individuales, dado que cada aplicación es de destino y, por tanto, se puede excluir en una directiva de acceso condicional que requiera inicio de sesión basado en dispositivos.
El desafío de la arquitectura de destino es que es posible que olvide proteger todas las aplicaciones en la nube. Incluso así, elegiría todas las aplicaciones seleccionables en las directivas de acceso condicional. Deja el acceso a las aplicaciones que no se pueden seleccionar sin protección. Algunos ejemplos son el acceso al portal de Office, al portal de Azure EA (Contrato Enterprise) y al portal de información de seguridad, que son todos muy confidenciales.
Otra consideración es que el número de aplicaciones de Office 365 y Microsoft Entra ID aumenta con el tiempo a medida que Microsoft y asociados lanzan nuevas características y a medida que los administradores de TI integran varias aplicaciones con Microsoft Entra ID. El acceso a todas estas aplicaciones solo está protegido si tiene un mecanismo que detecta cualquier nueva aplicación que admita el acceso condicional y le aplique automáticamente una directiva. Crear y mantener este tipo de script puede ser difícil.
Además, el número máximo admitido de aplicaciones para cualquier directiva de acceso condicional es aproximadamente 250. Es posible que pueda agregar hasta 600 aplicaciones antes de recibir un error sobre superación de carga útil, pero ese número no se admite.
Roles de acceso condicional
Hay muchas maneras de estructurar las directivas de acceso condicional. Un enfoque es estructurar las directivas en función de la confidencialidad del recurso al que se accede. En la práctica, este enfoque puede ser difícil de implementar de forma que aún proteja el acceso a los recursos para varios usuarios.
Por ejemplo, podría definir una directiva de acceso condicional que requiera un usuario y dispositivo conocidos para el acceso a un recurso confidencial al que necesiten acceder tanto invitados como empleados. Cuando los invitados intenten acceder desde un dispositivo administrado, la solicitud de acceso no funcionará. Tendría que ajustar la directiva de acceso condicional para cumplir ambos requisitos, lo que normalmente daría lugar a una directiva cumplidora del requisito menos seguro.
Otro enfoque es intentar definir directivas de acceso en función de dónde se encuentra un usuario en la organización. Este enfoque podría dar lugar a muchas directivas de acceso condicional y podría ser imposible de administrar.
Un enfoque mejor es estructurar las directivas relacionadas con las necesidades de acceso comunes y agrupar un conjunto de necesidades de acceso en un rol para un grupo de usuarios que tienen las mismas necesidades. Los roles son tipos de identidad que comparten atributos empresariales comunes, responsabilidades, experiencias, objetivos y acceso.
Comprender cómo acceden varios roles a los recursos empresariales es fundamental para desarrollar una estrategia de Confianza cero completa.
Aquí se muestran algunos roles de acceso condicional sugeridos de Microsoft:
Microsoft también recomienda definir un rol independiente para las identidades que no forman parte de ningún otro grupo de roles. Este se denomina rol Global. Global está diseñado para aplicar directivas para identidades que no están en un grupo de roles y directivas que se deben aplicar para todos los roles.
En las secciones siguientes se describen algunos roles recomendados.
Global
Global es un rol o marcador de posición para las directivas de carácter general. Se usa para definir directivas que se aplican a todos los roles o que no se aplican a un rol específico. Úselo para las directivas que no están cubiertas por otros roles. Necesita este rol para proteger todos los escenarios pertinentes.
Por ejemplo, imagine que desea usar una directiva para bloquear la autenticación heredada para todos los usuarios. Puede convertirla en una directiva global en lugar de usar un grupo de directivas heredadas que podrían ser diferentes para varios roles.
Otro ejemplo: quiere bloquear una cuenta o un usuario determinados de aplicaciones específicas, y el usuario o la cuenta no forma parte de ninguno de los roles. Por ejemplo, si crea una identidad en la nube en el inquilino de Microsoft Entra, esta identidad no forma parte de ninguno de los otros roles porque no tiene asignado ningún rol de Microsoft Entra. Es posible que quiera bloquear el acceso de la identidad a los servicios de Office 365.
Es posible que quiera bloquear todo el acceso a las identidades que no están cubiertas por ningún grupo de roles. O bien, es posible que solo quiera aplicar la autenticación multifactor.
Administradores
En este contexto, un administrador es cualquier identidad que no sea de invitado, en la nube o sincronizada, que tenga cualquier rol de administrador de Microsoft Entra ID u otro de Microsoft 365 (por ejemplo, en Microsoft Defender for Cloud Apps, Exchange, Defender para punto de conexión o Administrador de cumplimiento). Dado que los invitados que tienen estos roles están cubiertos en un rol diferente, los invitados se excluyen de este rol.
Algunas empresas tienen cuentas independientes para los roles de administrador confidenciales en los que se basa este rol. De forma óptima, los administradores usan estas cuentas confidenciales desde una estación de trabajo de acceso con privilegios (PAW). Pero a menudo vemos que las cuentas de administrador se usan en estaciones de trabajo estándar, donde el usuario simplemente cambia de una cuenta a otra en un dispositivo.
Es posible que quiera diferenciar en base a la confidencialidad de los roles de administrador en la nube y asignar roles de Azure menos confidenciales al rol Aspectos internos en lugar de usar cuentas independientes. Después, podría usar la elevación Just-In-Time (JIT) en su lugar. En este caso, dos conjuntos de directivas de acceso condicional tienen como destino un usuario, uno para cada rol. Si usa PAW, es posible que también quiera introducir directivas que usen filtros de dispositivo en el acceso condicional para restringir el acceso, de modo que los administradores solo se permitan en PAW.
Desarrolladores
El rol Desarrolladores incluye a usuarios que tienen necesidades únicas. Se basan en cuentas de Active Directory que se sincronizan con Microsoft Entra ID, pero necesitan acceso especial a servicios como Azure DevOps, canalizaciones de CI/CD, flujo de código de dispositivo y GitHub. El rol Desarrolladores puede incluir usuarios que se consideran internos y otros que se consideran externos, pero una persona solo debe estar en uno de los roles.
Aspectos internos
Aspectos internos incluye a todos los usuarios que tienen una cuenta de Microsoft Entra ID sincronizada con Azure AD, que son empleados de la empresa y trabajan en un rol de usuario final estándar. Se recomienda agregar usuarios internos que sean desarrolladores al rol Desarrolladores.
Externos
Este rol incluye a todos los consultores externos que tienen una cuenta de Active Directory sincronizada con Microsoft Entra ID. Se recomienda agregar usuarios externos que sean desarrolladores al rol Desarrolladores.
Invitados
Invitados incluye a todos los usuarios que tienen una cuenta de invitado de Microsoft Entra que se ha invitado al inquilino del cliente.
GuestAdmins
El rol GuestAdmins incluye a todos los usuarios que tienen una cuenta de invitado de Microsoft Entra que tiene asignado cualquiera de los roles de administrador mencionados anteriormente.
Microsoft365ServiceAccounts
Este rol incluye cuentas de servicio basadas en usuario (Microsoft Entra ID) en la nube que se usan para acceder a los servicios de Microsoft 365 cuando ninguna otra solución satisface la necesidad, como el uso de una identidad de servicio administrada.
AzureServiceAccounts
Este rol incluye cuentas de servicio basadas en usuario (Microsoft Entra ID) en la nube que se usan para acceder a los servicios de Azure (IaaS/PaaS) cuando ninguna otra solución satisface la necesidad, como el uso de una identidad de servicio administrada.
CorpServiceAccounts
Este rol contiene cuentas de servicio basadas en usuario que tienen todas estas características:
- Se originan desde Active Directory local.
- Se usan desde una ubicación local o desde una máquina virtual basada en IaaS en otro centro de datos (nube), como Azure.
- Se sincronizan con una instancia de Microsoft Entra, que accede a cualquier servicio de Azure o Microsoft 365.
Este escenario debe evitarse.
WorkloadIdentities
Este rol incluye identidades de máquina, como entidades de servicio e identidades administradas de Microsoft Entra. El acceso condicional ahora admite la protección del acceso a los recursos de estas cuentas, con algunas limitaciones en lo que respecta a las condiciones y los controles de concesión disponibles.
Acceso a las tarjetas de plantilla
Se recomienda usar tarjetas de plantilla de acceso para definir las características para cada rol. Este es un ejemplo:
La tarjeta de plantilla para cada rol proporciona la entrada para crear las directivas de acceso condicional específicas para cada rol.
Guía de acceso condicional
Revise un marco de acceso condicional que incluya un enfoque estructurado para agrupar directivas basadas en los roles creados.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Claus Jespersen | Consultor principal de Id. y seguridad
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Ruta de aprendizaje: Implementación y administración de la identidad y el acceso
- ¿Qué es el acceso condicional?
- Directivas de acceso condicional habituales