Marco y directivas de acceso condicional
En este artículo se proporciona un marco para implementar una arquitectura de acceso condicional basada en rol, como la descrita en arquitectura de la confianza cero del Acceso condicional. En este artículo, hay detalles sobre cómo crear y dar nombre a las directivas de acceso condicional. También hay un punto inicial para crear directivas.
Si no usa un marco como el que se proporciona aquí, incluido un estándar de nomenclatura, las directivas tienden a ser creadas con el tiempo por distintas personas de forma ad hoc. Esto puede dar lugar a directivas que se superponen. Si la persona que creó una directiva ya no está disponible, puede ser difícil para otros conocer el propósito de la directiva.
Seguir un marco estructurado facilita la comprender las directivas. También facilita la cobertura de todos los escenarios y la evitación de directivas en conflicto que son difíciles de solucionar.
Convenciones de nomenclatura
Una convención de nomenclatura definida correctamente ayuda a usted y a sus compañeros a comprender el propósito de una directiva, lo que permite una administración y una solución de problemas más sencillas. La convención de nomenclatura debe ajustarse al marco que se usa para estructurar las directivas.
La directiva de nomenclatura recomendada se basa en roles, tipos de directivas y aplicaciones. Su aspecto es similar a este:
<CANumber>-<Rol>-<PolicyType>-<Aplicación>-<Plataforma>-<GrantControl>-<OptionalDescription>
Los componentes de este nombre se describen aquí:
| Componente de nomenclatura | Descripción/Ejemplo |
|---|---|
| Número de CA | Se usa para identificar rápidamente el ámbito y el orden del tipo de directiva. Ejemplo: CA001-CA099. |
| Persona | Global, Admins, Internals, Externals, GuestUsers, GuestAdmins, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Tipo de directiva | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| Aplicación | AllApps, O365 (para todos los servicios de Office 365), EXO (para Exchange Online). |
| Plataforma | AnyPlatform, Unknown, WindowsPhone, macOS, iOS, Android. |
| Conceder control | Block, ADHJ, Compliant, Unmanaged (donde no administrado se especifica en la condición de estado del dispositivo). |
| Descripción | Descripción opcional del propósito de la directiva. |
Esquema de numeración
Para facilitar la administración, se recomienda este esquema de numeración:
| Grupo de rol | Asignación de números |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| CA-Persona-WorkloadIdentities | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
Tipos de directiva
Estos son los tipos de directiva recomendados:
| Tipo de directiva | Descripción y ejemplos |
|---|---|
| BaseProtection | Para cada rol, hay una protección de línea base que está cubierta por este tipo de directiva. Para los usuarios de dispositivos administrados, suele ser un usuario conocido y un dispositivo conocido. En el caso de los invitados externos, podría ser usuario conocido y autenticación multifactor. La protección base es la directiva predeterminada para todas las aplicaciones para los usuarios del rol determinado. Si una aplicación específica debe tener una directiva diferente, excluya esa aplicación de la directiva de protección base y agregue una directiva explícita que tenga como destino solo esa aplicación. Ejemplo: supongamos que la protección base de Internals es requerir un usuario conocido y un dispositivo conocido para todas las aplicaciones en la nube, pero quiere permitir Outlook en la Web desde cualquier dispositivo. Puede excluir los Exchange Online de la directiva de protección base y agregar una directiva independiente para Exchange Online, donde necesita la autenticación multifactor OR de dispositivo conocida. |
| IdentityProtection | Además de la protección base para cada rol, puede tener directivas de acceso condicional relacionadas con la identidad. Ejemplos: bloquear la autenticación heredada, requerir autenticación multifactor adicional para un alto riesgo de inicio de sesión o usuario, requerir un dispositivo conocido para el registro de autenticación multifactor. |
| DataProtection | Este tipo de directiva indica directivas diferenciales que protegen los datos como una capa adicional sobre la protección base. Ejemplos:
|
| AppProtection | Este tipo de directiva es otra adición a la protección base. Ejemplos:
|
| AttackSurfaceReduction | El propósito de este tipo de directiva es mitigar varios ataques. Ejemplos:
|
| Cumplimiento normativo | Puede usar una directiva de cumplimiento para requerir que un usuario vea las condiciones de uso de los invitados que acceden a los servicios de atención al cliente. |
Aplicación
En la tabla siguiente se describe el componente de aplicación de un nombre de directiva:
| Nombre de aplicación | Descripción y ejemplos |
|---|---|
| AllApps | AllApps indica que todas las aplicaciones en la nube están destinadas a la directiva de acceso condicional. Se tratan todos los puntos de conexión, incluidos los que admiten el acceso condicional y los que no. En algunos escenarios, el destino de todas las aplicaciones no funciona bien. Se recomienda tener como destino todas las aplicaciones de la directiva base para que todos los puntos de conexión estén cubiertos por esa directiva. Las nuevas aplicaciones que aparecen en Microsoft Entra ID también se adhieren automáticamente a la directiva. |
| <AppName> | <AppName> es un marcador de posición para el nombre de una aplicación a la que se dirige la directiva. Evite que el nombre sea demasiado largo. Nombres de ejemplo:
|
Tipo de plataforma
En la tabla siguiente se describe el componente Platform de un nombre de directiva:
| Tipo de plataforma | Descripción |
|---|---|
| AnyPlatform | La directiva tiene como destino cualquier plataforma. Normalmente, esto se configura al seleccionar Cualquier dispositivo. (En las directivas de acceso condicional, se usan la plataforma de palabras y la palabra dispositivo). |
| iOS | La directiva tiene como destino las plataformas iOS de Apple. |
| Android | La directiva tiene como destino las plataformas Android de Google. |
| Windows | Esta directiva tiene como destino la plataforma Windows. |
| Linux | Esta directiva tiene como destino las plataformas Linux. |
| WindowsPhone | La directiva tiene como destino las plataformas de Windows Phone. |
| macOS | La directiva tiene como destino las plataformas macOS |
| iOSAndroid | La directiva tiene como destino las plataformas iOS y Android. |
| Unknown | La directiva tiene como destino cualquier plataforma que no aparezca anteriormente. Normalmente, esto se configura mediante la inclusión de cualquier dispositivo y la exclusión de todas las plataformas individuales. |
Conceder tipos de control
En la tabla siguiente se describe el componente Grant Control de un nombre de directiva:
| Tipo de concesión | Descripción y ejemplos |
|---|---|
| Bloquear | La directiva bloquea el inicio de sesión |
| MFA | La directiva requiere autenticación multifactor. |
| Compatible | La directiva requiere un dispositivo compatible, determinado por Endpoint Manager, por lo que el dispositivo debe administrarse por Endpoint Manager. |
| CompliantorAADHJ | La directiva requiere un dispositivo compatible O un dispositivo híbrido unido a Microsoft Entra. Un equipo de empresa estándar unido a un dominio también está unido al dispositivo híbrido de Microsoft Entra ID. Los teléfonos móviles y los equipos con Windows 10 que están coadministrados o unidos a Microsoft Entra pueden ser compatibles. |
| CompliantandAADHJ | La directiva requiere un dispositivo compatible Y un dispositivo híbrido unido a Microsoft Entra. |
| MFAorCompliant | La directiva requiere un dispositivo compatible OR autenticación multifactor si no es compatible. |
| RMFAandCompliant | La directiva requiere un dispositivo compatible AND autenticación multifactor. |
| MFAorAADHJ | La directiva requiere un equipo híbrido unido a Microsoft Entra O la autenticación multifactor, si no es un equipo híbrido unido a Microsoft Entra. |
| MFAandAADHJ | La directiva requiere un equipo híbrido unido a Microsoft Entra híbrido Y la autenticación multifactor. |
| RequireApprovedClient | La directiva requiere una aplicación cliente aprobada. |
| AppProtection | La directiva requiere protección de aplicaciones |
| No administrados | La directiva tiene como destino los dispositivos que Microsoft Entra ID no conoce. Por ejemplo, puede usar este tipo de concesión para permitir el acceso a Exchange Online desde cualquier dispositivo. |
Ubicaciones con nombre
Se recomienda definir estas ubicaciones estándar para su uso en las directivas de acceso condicional:
- IP de confianza o redes internas. Estas subredes IP representan ubicaciones y redes que tienen restricciones de acceso físico u otros controles, como la administración del sistema informático, la autenticación de nivel de red o la detección de intrusiones. Estas ubicaciones son más seguras, por lo que la aplicación del acceso condicional puede ser relajada. Tenga en cuenta si Azure u otras ubicaciones de centros de datos (IP) deben incluirse en esta ubicación o tener sus propias ubicaciones con nombre.
- IP de confianza de Citrix. Si tiene Citrix local, puede ser útil configurar direcciones IPv4 salientes independientes para las granjas de Citrix, si necesita poder conectarse a servicios en la nube desde sesiones de Citrix. En ese caso, puede excluir esas ubicaciones de las directivas de acceso condicional si es necesario.
- Ubicaciones de Zscaler, si procede. Los equipos tienen instalado un agente ZPA y reenvía todo el tráfico a Internet hacia la nube de Zscaler o a través de esta. Por lo tanto, merece la pena definir las IP de origen de Zscaler en el acceso condicional y exigir que todas las solicitudes de dispositivos no móviles pasen por Zscaler.
- Países o regiones en los que se va a permitir hacer negocios. Puede ser útil dividir los países o regiones en dos grupos de ubicaciones: uno que represente áreas del mundo donde los empleados suelen trabajar y otro que represente otras ubicaciones. Esto le permite aplicar controles adicionales a las solicitudes que se originan desde fuera de las áreas en las que la organización opera normalmente.
- Ubicaciones donde la autenticación multifactor puede ser difícil o imposible. En algunos escenarios, requerir la autenticación multifactor podría dificultar a los empleados su trabajo. Por ejemplo, es posible que el personal no tenga el tiempo ni la oportunidad de responder a los desafíos frecuentes de la autenticación multifactor. O bien, en algunas ubicaciones, el filtrado de radiofrecuencia o las interferencias eléctricas pueden dificultar el uso de dispositivos móviles. Normalmente, usaría otros controles en estas ubicaciones o podrían ser de confianza.
Los controles de acceso basados en la ubicación se basan en la dirección IP de origen de una solicitud para determinar la ubicación del usuario en el momento de la solicitud. No es fácil realizar suplantación de identidad en la red pública de Internet, pero la protección que ofrecen los límites de red puede considerarse menos relevante de lo que alguna vez fue. No se recomienda confiar únicamente en la ubicación como condición para el acceso. Pero para algunos escenarios podría ser el mejor control que se puede usar, como si se protegía el acceso desde una cuenta de servicio desde un entorno local que se usa en un escenario no interactivo.
Directivas de acceso condicional recomendadas
Hemos creado una hoja de cálculo que contiene las directivas de acceso condicional recomendadas. Puede descargar la hoja de cálculo aquí.
Use las directivas sugeridas como punto inicial.
Es probable que las directivas cambien con el tiempo para dar cabida a casos de uso que son importantes para su empresa. Estos son algunos ejemplos de escenarios que pueden requerir cambios:
- Implemente el acceso de solo lectura a empleados de Exchange Online que usen cualquier dispositivo no administrado basado en la autenticación multifactor, la protección de aplicaciones y una aplicación cliente aprobada.
- Implemente la protección de la información para asegurarse de que la información confidencial no se descarga sin una protección mejorada proporcionada por Azure Information Protection.
- Proporcionar protección contra copiar y pegar por parte de los invitados.
Varias versiones preliminares se encuentran actualmente en versión preliminar pública, por lo que se esperan actualizaciones del conjunto sugerido de directivas iniciales de acceso condicional (CA) próximamente.
Guía de acceso condicional
Ahora que tiene un conjunto inicial de directivas de acceso condicional, debe implementarlas de forma controlada y por fases. Se recomienda usar un modelo de implementación.
Este es un enfoque:
La idea es implementar primero directivas para un pequeño número de usuarios dentro de un grupo de personas. Puede usar un grupo de Microsoft Entra asociado denominado Anillo de rol 0 para esta implementación. Después de comprobar que todo funciona, cambia la asignación a un grupo, Anillo de rol 1, que tiene más miembros, etc.
A continuación, habilite las directivas mediante el mismo enfoque basado en anillo hasta que se implementen todas las directivas.
Normalmente, los miembros del anillo 0 y el anillo 1 se administran manualmente. Un grupo de anillos 2 o 3 que contiene cientos o incluso miles de usuarios podría administrarse a través de un grupo dinámico basado en un porcentaje de los usuarios de un rol determinado.
El uso de anillos como parte de un modelo de implementación no es solo para la implementación inicial. También puede usarlo cuando se requieran nuevas directivas o cambios en las directivas existentes.
Una vez finalizada la implementación, también debe diseñar e implementar los controles de supervisión que se han analizado en los principios de acceso condicional.
Además de automatizar la implementación inicial, es posible que desee automatizar los cambios en las directivas mediante canalizaciones de CI/CD. Puede usar Microsoft365DSC para esta automatización.
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
- Directivas de acceso condicional
Recursos relacionados
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de