Principios y dependencias de diseño de acceso condicional

Microsoft Entra ID
Microsoft Endpoint Manager

En este artículo, aprenderá sobre los principios de diseño y las dependencias de un escenario de acceso condicional basado en Confianza cero.

Principios de diseño

Comenzaremos con algunos principios de diseño.

Acceso condicional como motor de las directivas de Confianza cero

El enfoque Confianza cero de Microsoft incluye el acceso condicional como motor principal de las directivas. A continuación explicamos un resumen de ese enfoque:

Diagram that provides an overview of the Zero Trust model.

Descargue un archivo SVG de esta arquitectura.

El acceso condicional se usa como motor de las directivas en una arquitectura de Confianza cero que abarca tanto la definición como el cumplimiento de las directivas. En función de varias señales o condiciones, el acceso condicional puede bloquear o dar acceso limitado a los recursos, como se muestra aquí:

Diagram that provides an overview of the Conditional Access signal, decision, enforcement path.

Esta es una vista más detallada de los elementos del acceso condicional y de lo que trata:

Diagram that shows a more detailed view of Conditional Access.

En este diagrama se muestra el acceso condicional y los elementos relacionados que pueden ayudar a proteger el acceso de los usuarios a los recursos, en lugar del acceso no interactivo o no humano. En el diagrama siguiente, se describen ambos tipos de identidades.

Diagram that describes Conditional Access identity types.

El acceso condicional se ha centrado principalmente en la protección del acceso a los recursos por parte de humanos interactivos. A medida que crece la cantidad de identidades no humanas, también se deben tener en cuenta estos accesos. Microsoft ofrece dos características relacionadas con la protección del acceso a las identidades de carga de trabajo y desde ellas.

  • Protección del acceso a las aplicaciones representadas por una identidad de carga de trabajo que no se puede seleccionar en el portal de acceso condicional de Microsoft Entra. Esta opción se admite mediante atributos de seguridad. Asignar un atributo de seguridad a las identidades de carga de trabajo y seleccionarlos en el portal de acceso condicional de Microsoft Entra forma parte de la licencia P1 de Microsoft Entra ID.
  • Protección del acceso a los recursos iniciados por identidades de carga de trabajo (entidades de servicio). Una nueva característica de ‘Identidades de carga de trabajo de Microsoft Entra’ se ofrece mediante una licencia independiente que admite este escenario. Incluye la administración del ciclo de vida de las identidades de carga de trabajo, incluida la protección del acceso a los recursos con acceso condicional.

Modelo de acceso de Enterprise

Microsoft ha proporcionado anteriormente instrucciones y principios para el acceso a recursos locales en función de un modelo de organización por niveles:

  • Nivel 0: controladores de dominio, infraestructura de clave pública (PKI), servidores de Servicios de federación de Active Directory (AD FS) y las soluciones de administración que administran esos servidores
  • Nivel 1: servidores que hospedan aplicaciones
  • Nivel 2: dispositivos cliente

Este modelo sigue siendo relevante para los recursos locales. Para ayudar a proteger el acceso a los recursos en la nube, Microsoft recomienda una estrategia de control de acceso que cumpla los siguientes requisitos:

  • Sea integral y coherente.
  • Aplique rigurosamente los principios de seguridad en toda la pila de tecnología.
  • Sea lo suficientemente flexible para satisfacer las necesidades de la organización.

En función de estos principios, Microsoft creó el siguiente modelo de acceso empresarial:

Diagram that outlines the enterprise access model.

El modelo de acceso empresarial reemplaza al modelo de nivel heredado que se centraba en contener la escalación no autorizada de privilegios en un entorno de Windows Server Active Directory local. En el nuevo modelo, el nivel 0 se expande para convertirse en el plano de control, el nivel 1 consta del plano de administración y de datos, y el nivel 2 abarca el acceso de usuarios y aplicaciones.

Microsoft recomienda trasladar el control y la administración a los servicios en la nube que utilizan el acceso condicional como plano de control principal y motor de políticas, definiendo y aplicando así el acceso.

Puede extender el motor de directivas de acceso condicional de Microsoft Entra a otros puntos de cumplimiento de directivas, entre los que se incluyen:

  • Aplicaciones modernas: aplicaciones que usan protocolos de autenticación modernos.
  • Aplicaciones heredadas: a través del proxy de aplicación de Microsoft Entra.
  • Soluciones de VPN y acceso remoto: soluciones como Microsoft Always On VPN, Cisco AnyConnect, Palo Alto Networks, F5, Fortinet, Citrix y Zscaler.
  • Documentos, correo electrónico y otros archivos: mediante Microsoft Information Protection.
  • Aplicaciones SaaS.
  • Aplicaciones que se ejecutan en otras nubes, como AWS o Google Cloud (en función de la federación).

Principios de Confianza cero

Los tres principios principales de Confianza cero que define Microsoft parecen ser entendidos, especialmente por los departamentos de seguridad. Sin embargo, a veces se pasa por alto la importancia de la facilidad de uso durante el diseño de soluciones de Confianza cero.

La facilidad de uso siempre debe considerarse un principio implícito.

Principios del acceso condicional

En función de la información anterior, este es un resumen de los principios sugeridos. Microsoft recomienda crear un modelo de acceso basado en el acceso condicional que se alinee con los tres principios principales de Confianza cero de Microsoft:

Comprobación explícita

  • Traslade el plano de control a la nube. Integre aplicaciones con Microsoft Entra ID y protéjalas mediante el acceso condicional.
  • Considere que todos los clientes son externos.

Uso del acceso con privilegios mínimos

  • Evalúe el acceso en función del cumplimiento y el riesgo, incluidos el riesgo de usuario, el riesgo de inicio de sesión y el riesgo del dispositivo.
  • Use estas prioridades de acceso:
    • Acceda directamente al recurso, usando el acceso condicional para la protección.
    • Publique el acceso al recurso mediante el proxy de aplicación de Microsoft Entra, usando el acceso condicional para la protección.
    • Use una VPN basada en el acceso condicional para acceder al recurso. Restrinja el acceso al nivel de la aplicación o el nombre DNS.

Asunción de que hay brechas

  • Infraestructura de red de segmentos.
  • Minimice el uso de PKI empresarial.
  • Migre el inicio de sesión único (SSO) de AD FS a la sincronización de hash de contraseñas (PHS).
  • Minimice las dependencias de los controladores de dominio mediante KDC de Kerberos en Microsoft Entra ID.
  • Mueva el plano de administración a la nube. Administre dispositivos mediante Microsoft Endpoint Manager.

Estos son algunos principios más detallados y procedimientos recomendados para el acceso condicional:

  • Aplique los principios de Confianza cero al acceso condicional.
  • Use el modo de solo informe antes de poner una directiva en producción.
  • Pruebe escenarios positivos y negativos.
  • Use el control de cambios y revisiones en las directivas de acceso condicional.
  • Automatice la administración de directivas de acceso condicional mediante herramientas como Azure DevOps/GitHub o Azure Logic Apps.
  • Use el modo de bloqueo para el acceso general solo si es necesario y donde sea necesario.
  • Asegúrese de que todas las aplicaciones y la plataforma están protegidas. El acceso condicional no tiene ninguna acción "Denegar todo" implícita.
  • Proteja a los usuarios con privilegios en todos los sistemas de control de acceso basado en rol (RBAC) de Microsoft 365.
  • Requiera cambio de contraseña y autenticación multifactor para usuarios e inicios de sesión de alto riesgo (aplicados por la frecuencia de inicio de sesión).
  • Restrinja el acceso desde dispositivos de alto riesgo. Utilice una política de cumplimiento de Intune con una comprobación de cumplimiento en el acceso condicional.
  • Proteja sistemas con privilegios, como el acceso a los portales de administrador para Office 365, Azure, AWS y Google Cloud.
  • Evitar sesiones persistentes del explorador para administradores y en dispositivos que no son de confianza.
  • Bloque la autenticación heredada.
  • Restrinja el acceso desde plataformas de dispositivo desconocidas o no admitidas.
  • Requiera un dispositivo compatible para el acceso a los recursos, siempre que sea posible.
  • Restrinja el registro de credenciales seguras.
  • Considere la posibilidad de usar la directiva de sesión predeterminada que permite que las sesiones continúen si se produce una interrupción, siempre que se cumplan las condiciones adecuadas antes de la interrupción.

En el diagrama siguiente se muestran las dependencias y las tecnologías relacionadas. Algunas de las tecnologías son requisitos previos para el acceso condicional. Otras dependen del acceso condicional. El diseño descrito en este documento se centra principalmente en el acceso condicional y no en las tecnologías relacionadas.

Diagram that shows Conditional Access dependencies.

Guía de acceso condicional

Para obtener más información, consulte Diseño de acceso condicional basado en Confianza cero y roles.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes