Marco de acceso condicional y directivas
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 formar y asignar un nombre a las directivas de acceso condicional. También hay un punto de partida para crear directivas.
Si no usa un marco como el que se proporciona aquí, incluido un estándar de nomenclatura, las directivas tienden a crearse a lo largo del tiempo por diferentes 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 que otros sepan el propósito de la directiva.
Seguir un marco estructurado facilita la comprensión de las directivas. También facilita la cobertura de todos los escenarios y evita las directivas en conflicto que son difíciles de solucionar.
Convenciones de nomenclatura
Una convención de nomenclatura definida correctamente le ayuda a usted y a sus compañeros a comprender el propósito de una directiva, lo que facilita la administración de directivas y la solución de problemas. La convención de nomenclatura debe ajustarse al marco que usa para estructurar las directivas.
La directiva de nomenclatura recomendada se basa en personas, tipos de directiva y aplicaciones. Tiene este aspecto:
<CANumber>-<Persona>-<PolicyType>-<Aplicación>-<Plataforma>-<GrantControl>-<OptionalDescription>
Los componentes de este nombre se describen aquí:
| Componente de nomenclatura | Descripción o 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, Administradores, Internos, Externos, UsuariosInvitados, AdministradoresInvitados, CuentasDeServicioMicrosoft365, CuentasDeServicioAzure, CuentasDeServicioCorporativas. |
| Tipo de directiva | ProtecciónBase, ProtecciónDeAplicaciones, ProtecciónDeDatos, ProtecciónDeIdentidad, ReducciónDeLaSuperficieDeAtaque, Cumplimiento. |
| 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 personas | 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 persona, hay una protección básica que está cubierta por este tipo de póliza. Para los usuarios de dispositivos administrados, esto generalmente significa usuario conocido y dispositivo conocido. En el caso de los invitados externos, podría ser usuario conocido y autenticación multifactor. La protección básica es la política predeterminada para todas las aplicaciones de los usuarios de la persona dada. 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 para 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 Exchange Online de la directiva de protección base y agregar una directiva independiente para Exchange Online, donde requiera autenticación de dispositivo reconocido o multifactor. |
| Protección de Identidad | Además de la protección base para cada persona, 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 usuario o inicio de sesión, requerir un dispositivo conocido para el registro de autenticación multifactor. |
| Protección de Datos | Este tipo de directiva indica directivas delta 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:
|
| Conformidad | Puede usar una directiva de cumplimiento para requerir que un usuario vea los términos de uso para los invitados que acceden a los servicios de cliente. |
Aplicación
En la tabla siguiente se describe el componente App de un nombre de política:
| Nombre de la 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 lo hacen. En algunos escenarios, el destino de todas las aplicaciones no funciona bien. Se recomienda dirigirse a 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 el identificador de Entra de Microsoft 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 política. Evite hacer que el nombre sea demasiado largo. Nombres de ejemplo:
|
Tipo de plataforma
En la tabla siguiente se describe el componente Plataforma de un nombre de directiva:
| Tipo de plataforma | Descripción |
|---|---|
| AnyPlatform | La política apunta a cualquier plataforma. Normalmente, para configurar esto, seleccione Cualquier dispositivo. (En las directivas de acceso condicional, se usan la palabra plataforma y la palabra dispositivo). |
| Ios | La política tiene como destino las plataformas de Apple iOS. |
| Androide | La política tiene como destino las plataformas Google Android. |
| Windows | Esta directiva tiene como destino la plataforma Windows. |
| Linux | Esta directiva tiene como destino las plataformas Linux. |
| WindowsPhone | La política está dirigida a 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. |
| Desconocido | La directiva tiene como destino cualquier plataforma que no aparezca anteriormente. Normalmente lo configuras incluyendo Cualquier dispositivo y excluyendo todas las plataformas individuales. |
Tipos de control de concesión
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 la autenticación multifactor. |
| Compatible | La directiva requiere un dispositivo compatible, determinado por Endpoint Manager, por lo que el dispositivo debe administrarse mediante Endpoint Manager. |
| CompliantorAADHJ | La política 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 Windows 10 que están administrados conjuntamente 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 política requiere un dispositivo compatible o, si no es compatible, autenticación multifactor. |
| MFAandCompliant | La directiva requiere un dispositivo compatible Y la 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 administrado | La directiva apunta a 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 usarlas en las directivas de acceso condicional:
- Direcciones IP de confianza y 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 el cumplimiento del acceso condicional se puede relajar. Tenga en cuenta si Azure u otras ubicaciones de centros de datos (direcciones IP) deben incluirse en esta ubicación o tener ubicaciones propias con nombre.
- IP de confianza de Citrix. Si tiene Citrix local, puede resultar ú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 a o a través de la nube de Zscaler. Por lo tanto, vale la pena definir direcciones IP de origen de Zscaler en el acceso condicional y requerir que todas las solicitudes de dispositivos que no son móviles pasen por Zscaler.
- Países o regiones con los que permitir el negocio. Puede ser útil dividir países o regiones en dos grupos de ubicaciones: uno que representa áreas del mundo donde los empleados suelen trabajar y otro que representa otras ubicaciones. Esto le permite aplicar controles adicionales a las solicitudes que se originan desde fuera de las áreas en las que su organización opera normalmente.
- Ubicaciones en las que la autenticación multifactor puede ser difícil o imposible. En algunos escenarios, requerir la autenticación multifactor podría dificultar que los empleados realicen su trabajo. Por ejemplo, es posible que el personal no tenga el tiempo o la oportunidad de responder a los desafíos frecuentes de autenticación multifactor. O bien, en algunas ubicaciones, la detección de RF o la interferencia eléctrica 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 ubicación dependen de 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 la suplantación de identidad en la Internet pública, pero la protección que ofrecen los límites de red podría considerarse menos relevante de lo que lo era antes. No se recomienda confiar únicamente en la ubicación como condición para el acceso. Sin embargo, en algunos casos, podría ser el mejor control disponible, como cuando se asegura el acceso de una cuenta de servicio local utilizada en un escenario no interactivo.
Directivas de acceso condicional recomendadas
Hemos creado una hoja de cálculo que contiene directivas de acceso condicional recomendadas. Puede descargar la hoja de cálculo aquí.
Use las directivas sugeridas como punto de partida.
Es probable que las directivas cambien con el tiempo para dar cabida a los casos de uso que son importantes para su negocio. Estos son algunos ejemplos de escenarios que pueden requerir cambios:
- Implemente el acceso de solo lectura a Exchange Online para los empleados 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 descargue sin una protección mejorada proporcionada por Azure Information Protection.
- Proporcionar protección contra la copia y pegada por invitados.
Varias versiones preliminares están entrando actualmente en vista previa pública, por lo que se esperan pronto actualizaciones en el conjunto sugerido de políticas iniciales de acceso condicional (CA).
Guía de acceso condicional
Ahora que tiene un conjunto de inicio 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 políticas en un pequeño número de usuarios dentro de un grupo de personas. Puede usar un grupo de Microsoft Entra asociado llamado Persona Ring 0 para esta implementación. Después de comprobar que todo funciona, cambia la asignación a un grupo, Persona Ring 1, que tiene más miembros, etc.
Después, habilite las directivas mediante el mismo enfoque basado en anillos 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 requieren 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 fue escrito por los siguientes colaboradores.
Autor principal:
- Claus Jespersen | Consultor principal de Id. y seguridad
Para ver perfiles de LinkedIn no públicos, 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