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 roles 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 dirigida. 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 el usuario conocido y el 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 el usuario interactúe.
Un ejemplo es un punto de conexión de flujo de inicio de sesión de 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.
Un comando de inicio de sesión basado en dispositivo se ejecuta en el dispositivo determinado 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 con este inicio de sesión es que no admite el acceso condicional basado en dispositivos. Esto significa que nadie puede usar las herramientas y comandos si aplica una directiva de línea de base que requiere un usuario conocido y un dispositivo conocido 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, el dirigido uno, se basa en el principio de que solo tiene como destino aplicaciones individuales que desea proteger en las directivas de acceso condicional. En este caso, el inicio de sesión del dispositivo para los puntos de conexión cubiertos anteriormente por todas las aplicaciones en la nube, como las llamadas de grafo a Microsoft Entra ID, no está protegido por las directivas de acceso condicional, por lo que siguen funcionando.
Al usar device-login como ejemplo para diferenciar las dos arquitecturas, puede autenticarse con device-login. El inicio de sesión de dispositivo puede permitirse para una o varias aplicaciones individuales, dado que cada aplicación se puede establecer como destino y, por tanto, se puede excluir en una directiva de acceso condicional que requiera el inicio de sesión basado en el dispositivo.
El desafío con el arquitectura de dirigida es que puede olvidarse de proteger todas las aplicaciones en la nube. Incluso así, elegiría todas las aplicaciones seleccionables en las directivas de acceso condicional. Deje acceso a las aplicaciones que no se pueden seleccionar desprotegidas. Algunos ejemplos incluyen el acceso al portal de Office, el portal de Contrato Enterprise (Contrato Enterprise) de Azure y el portal de información de seguridad, que son todos portales muy confidenciales.
Otra consideración es que el número de aplicaciones de Office 365 y Microsoft Entra aumenta a lo largo del tiempo, ya que Microsoft y los asociados lanzan nuevas características y, a medida que los administradores de TI integran varias aplicaciones con el identificador de Microsoft Entra. 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 que aplique automáticamente una directiva a ella. La creación y el mantenimiento de este script puede ser difícil.
Además, el número máximo admitido de aplicaciones para cualquier directiva de acceso condicional es de aproximadamente 250. Es posible que pueda agregar hasta 600 aplicaciones antes de obtener un error sobre la carga que se supera, pero no se admite ese número.
Roles de acceso condicional
Hay muchas maneras de estructurar las directivas de acceso condicional. Un enfoque consiste en 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 una manera que todavía protege el acceso a los recursos para varios usuarios.
Por ejemplo, podría definir una directiva de acceso condicional que requiera un usuario conocido y un dispositivo conocido para acceder a un recurso confidencial al que deben tener acceso tanto invitados como empleados. Cuando los invitados intentan 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 que cumpla los requisitos menos seguros.
Otro enfoque consiste en 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 no administrarse.
Un mejor enfoque 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 los recursos y recursos empresariales son accesibles por varios roles es integral para desarrollar una estrategia de confianza cero completa.
A continuación 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. Esto 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 marcador de posición o rol para las directivas que son generales por naturaleza. 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, supongamos que desea usar una directiva para bloquear la autenticación heredada para todos los usuarios. Puede convertirlo 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 determinada o un usuario 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 demás 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 desde identidades que no estén cubiertos por ningún grupo de roles. O bien, es posible que quiera aplicar la autenticación multifactor.
administradores
En este contexto, un administrador es cualquier identidad no invitada, en la nube o sincronizada, que tenga cualquier identificador de Microsoft Entra u otro rol de administrador de Microsoft 365 (por ejemplo, en Microsoft Defender para aplicaciones en la nube, Exchange, Defender para punto de conexión o administrador de cumplimiento). Dado que los invitados que tienen estos roles se tratan 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 entre cuentas en un dispositivo.
Es posible que quiera diferenciar en función de la confidencialidad de los roles de administrador en la nube y asignar roles de Azure menos confidenciales a la persona de internals en lugar de usar cuentas independientes. Después, podría usar la elevación Just-In-Time (JIT). En este caso, un usuario está dirigido por dos conjuntos de directivas de acceso condicional, una para cada rol. Si usa PAW, es posible que también desee introducir directivas que usen filtros de dispositivo en el acceso condicional para restringir el acceso para que los administradores solo se permitan en PAW.
desarrolladores de
El rol Desarrolladores contiene usuarios que tienen necesidades únicas. Se basan en cuentas de Active Directory que se sincronizan con el identificador de Microsoft Entra, 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 debe estar en solo uno de los roles.
internos
Los internos contienen todos los usuarios que tienen una cuenta de Active Directory sincronizada con el identificador de Microsoft Entra, que son empleados de la empresa y que trabajan en un rol de usuario final estándar. Se recomienda agregar usuarios internos que sean desarrolladores al rol Desarrolladores.
externals
Este rol contiene a todos los consultores externos que tienen una cuenta de Active Directory sincronizada con el identificador de Microsoft Entra. Se recomienda agregar usuarios externos que sean desarrolladores al rol Desarrolladores.
invitados
Los invitados contienen todos los usuarios que tienen una cuenta de invitado de Microsoft Entra que se ha invitado al inquilino del cliente.
GuestAdmins
El rol GuestAdmins contiene todos los usuarios que tienen una cuenta de invitado de Microsoft Entra asignada a cualquiera de los roles de administrador mencionados anteriormente.
Microsoft365ServiceAccounts
Este rol contiene cuentas de servicio basadas en usuarios basadas en la nube (Id. de Microsoft Entra) 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 contiene cuentas de servicio basadas en usuarios basadas en la nube (Microsoft Entra ID) 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 el usuario que tienen todas estas características:
- Se origina desde Active Directory local.
- Se usan desde el entorno 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 contiene identidades de máquina, como las entidades de servicio y las 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.
Tarjetas de plantilla de acceso
Se recomienda usar tarjetas de plantilla de acceso para definir las características de cada persona. Este es un ejemplo:
La tarjeta de plantilla para cada rol proporciona entrada para crear las directivas de acceso condicional específicas para cada persona.
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 fue escrito por los siguientes colaboradores.
Autor principal:
- Claus Jespersen | Id. de consultor principal&s
Para ver perfiles de LinkedIn no públicos, inicie sesión en LinkedIn.
Pasos siguientes
- ruta de aprendizaje de : implementación y administración de identidades y acceso
- ¿Qué es el acceso condicional?
- directivas de acceso condicional comunes