La solución de este artículo le proporciona una manera de proteger el servicio de mensajería (Outlook en la web o el Panel de control de Exchange) cuando los buzones están hospedados en Exchange Online o Exchange local.
Architecture
En esta arquitectura, dividimos la solución en dos áreas, que describen la seguridad para:
- Exchange Online, en el lado derecho del diagrama.
- Exchange local en un escenario híbrido o no híbrido, en el lado izquierdo del diagrama.
Descargue un archivo Visio de esta arquitectura.
Notas generales
- Esta arquitectura usa el modelo de identidad federada de Microsoft Entra. Para los modelos de sincronización de hash de contraseña y autenticación transferida, la lógica y el flujo son los mismos. La única diferencia está en el hecho de que Microsoft Entra ID no redirigirá la solicitud de autenticación a la instancia local de Servicios de federación de Active Directory (AD FS).
- En el diagrama se muestra el acceso al servicio web Outlook en la Web que corresponde a una ruta .../owa. El acceso del usuario del centro de administración de Exchange (o del Panel de control de Exchange) que corresponde a una ruta .../ecp sigue el mismo flujo.
- En los diagramas, las líneas discontinuas muestran interacciones básicas entre los componentes Active Directory, Microsoft Entra Connect, Microsoft Entra ID, AD FS y Proxy de aplicación web. Puede obtener más información sobre estas interacciones en La identidad híbrida requería puertos y protocolos.
- Por Exchange local, nos referimos a Exchange 2019 con las actualizaciones más recientes, el rol Buzón de correo. Por Exchange Edge local, nos referimos a Exchange 2019 con las actualizaciones más recientes, el rol Transporte perimetral. Se incluye el servidor perimetral en el diagrama para resaltar que puede usarlo en estos escenarios. No está implicado en el trabajo con protocolos de cliente que se describe aquí.
- En un entorno real, no tendrá un solo servidor. Tendrá una matriz de servidores Exchange con equilibrio de carga para ofrecer una alta disponibilidad. Los escenarios descritos aquí son adecuados para esa configuración.
Flujo de usuario de Exchange Online
Un usuario intenta acceder a Outlook en el servicio web a través de https://outlook.office.com/owa.
Exchange Online redirige al usuario a Microsoft Entra ID para la autenticación.
Si el dominio está federado, Microsoft Entra ID redirige al usuario a la instancia de AD FS local para la autenticación. Si la autenticación se realiza correctamente, se redirige al usuario a Microsoft Entra ID. Para que el diagrama sea sencillo, se ha dejado este escenario federado.
Para aplicar la autenticación multifactor, Microsoft Entra ID aplica una directiva de acceso condicional de Azure con un requisito de autenticación multifactor para la aplicación cliente del explorador. Consulte la sección de implementación de este artículo para obtener información sobre cómo configurar esa directiva.
La directiva de acceso condicional llama a Microsoft Entra para la autenticación multifactor. El usuario obtiene una solicitud para completar la autenticación multifactor.
El usuario completa la autenticación multifactor.
Microsoft Entra ID redirige la sesión web autenticada a Exchange Online y el usuario puede acceder a Outlook.
Flujo del usuario local de Exchange
Un usuario intenta acceder al servicio Outlook en la web a través de una dirección URL
https://mail.contoso.com/owaque apunta a un servidor de Exchange para el acceso interno o a un servidor proxy de aplicación web para el acceso externo.Exchange local (para el acceso interno) o Web Application Proxy (para el acceso externo) redirige al usuario a AD FS para la autenticación.
AD FS usa la autenticación Windows integrada para el acceso interno o proporciona un formulario web en el que el usuario puede escribir credenciales para el acceso externo.
En respuesta a una directiva de control de acceso de AD FS, AD FS llama a la autenticación multifactor de Microsoft Entra para completar la autenticación. Este es un ejemplo de ese tipo de directiva de control de acceso de AD FS:
El usuario obtiene una solicitud para completar la autenticación multifactor.
El usuario completa la autenticación multifactor. AD FS redirige la sesión web autenticada a Exchange local.
El usuario puede acceder a Outlook.
Para implementar este escenario para un usuario local, tiene que configurar Exchange y AD FS para la autenticación previa de solicitudes de acceso web. Para más información, consulte Uso de la autenticación de AD FS basada en notificaciones con Outlook en la Web.
También debe habilitar la integración de la autenticación multifactor de AD FS y Microsoft Entra. Para más información, consulte Configuración de Azure MFA como proveedor de autenticación con AD FS. Esta integración requiere AD FS 2016 o 2019. Por último, debe sincronizar los usuarios con Microsoft Entra ID y asignarles licencias para la autenticación multifactor de Microsoft Entra.
Componentes
Microsoft Entra ID. Microsoft Entra ID es un servicio de administración de acceso e identidades de Microsoft basado en la nube. Proporciona una autenticación moderna que se basa en EvoSTS, un servicio de token de seguridad que usa Microsoft Entra ID. Se usa como servidor de autenticación para Exchange Server local.
Autenticación multifactor de Microsoft Entra. La autenticación multifactor es un procedimiento en el que se solicita a los usuarios, durante el inicio de sesión, una forma adicional de identificación, como un código enviado a su teléfono móvil o el examen de su huella digital.
Acceso condicional de Microsoft Entra. El acceso condicional es la característica que usa Microsoft Entra ID para aplicar directivas de una organización, como la autenticación multifactor.
AD FS. AD FS permite la administración de identidades y acceso federados mediante el uso compartido de derechos y identidades digitales a través de los límites de seguridad y empresa con una seguridad mejorada. En esta arquitectura, se usa para facilitar el inicio de sesión para los usuarios con identidad federada.
Proxy de aplicación web. El Proxy de aplicación web autentica previamente el acceso a las aplicaciones web mediante AD FS. También funciona como un proxy AD FS.
Exchange Server. Exchange Server hospeda buzones de usuario de forma local. En esta arquitectura, utiliza tokens que Microsoft Entra ID emite para que el usuario pueda acceder a los buzones.
Servicios de Active Directory. Active Directory almacena información sobre los miembros de un dominio, incluidos los dispositivos y los usuarios. En esta arquitectura, las cuentas de usuario pertenecen a los servicios de Active Directory y se sincronizan con Microsoft Entra ID.
Detalles del escenario
La infraestructura de mensajería empresarial (EMI) es un servicio clave para las organizaciones. Pasar de métodos de autenticación y autorización más antiguos y menos seguros a la autenticación moderna es un desafío crítico en un mundo donde es habitual el teletrabajo. La implementación de requisitos de autenticación multifactor para el acceso al servicio de mensajería es una de las formas más eficaces de abordar ese desafío.
En este artículo se describe una arquitectura para mejorar la seguridad en un escenario de acceso web mediante la autenticación multifactor de Microsoft Entra.
Las arquitecturas de este documento describen escenarios que le ayudarán a proteger el servicio de mensajería (Outlook en la Web o el Panel de control de Exchange) cuando los buzones se hospedan en Exchange Online o Exchange local.
Para obtener información sobre cómo aplicar la autenticación multifactor en otros escenarios de mensajería híbrida, vea estos artículos:
- Infraestructura de mensajería híbrida de seguridad mejorada en un escenario de acceso de cliente de escritorio
- Infraestructura de mensajería híbrida de seguridad mejorada en un escenario de acceso móvil
En este artículo no se analizan otros protocolos, como IMAP o POP. No se recomienda usarlos para proporcionar acceso de usuario.
Posibles casos de uso
Esta arquitectura es relevante para los siguientes escenarios:
- Mejorar la seguridad de la infraestructura de mensajería empresarial.
- Adoptar una estrategia de seguridad de Confianza cero.
- Aplicar el alto nivel de protección estándar de su servicio de mensajería en el entorno local durante la transición o la coexistencia con Exchange Online.
- Aplicar requisitos estrictos de seguridad o cumplimiento normativo en organizaciones cerradas o de alta seguridad, como las del sector financiero.
Consideraciones
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Confiabilidad
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.
Disponibilidad
La disponibilidad general depende de la disponibilidad de los componentes implicados. Para obtener información sobre la disponibilidad, consulte estos recursos:
- Avance en la disponibilidad de Microsoft Entra
- Servicios en la nube en los que puedes confiar: disponibilidad de Office 365
- ¿Cuál es la arquitectura de Microsoft Entra?
La disponibilidad de los componentes de la solución local depende del diseño implementado, la disponibilidad del hardware y las operaciones y rutinas de mantenimiento internas. Para obtener información sobre la disponibilidad de algunos de estos componentes, vea los siguientes recursos:
- Configuración de una implementación de AD FS con Grupos de disponibilidad AlwaysOn
- Implementación de alta disponibilidad y resistencia de sitios en Exchange Server
- Proxy de aplicación web en Windows Server 2016
Resistencia
Para obtener información sobre la resistencia de los componentes de esta arquitectura, vea los siguientes recursos.
- Para Microsoft Entra ID: Avance en la disponibilidad de Microsoft Entra
- Para escenarios que usan AD FS: Implementación entre regiones geográficas de AD FS de alta disponibilidad en Azure con Azure Traffic Manager.
- Para la solución de Exchange local: Implementación de alta disponibilidad y resistencia de sitios en Exchange Server.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.
Para obtener información sobre la seguridad de los componentes de esta arquitectura, vea los siguientes recursos:
- Guía de operaciones de seguridad de Microsoft Entra
- Procedimientos recomendados para proteger AD FS y Web Application Proxy
- Configurar la protección de bloqueo inteligente de la Extranet de AD FS
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.
El costo de la implementación depende de los costos de licencia de Microsoft Entra ID y Microsoft 365. El costo total también incluye los costos de software y hardware para los componentes locales, las operaciones de TI, el entrenamiento y la educación, y la implementación de proyectos.
La solución requiere al menos Microsoft Entra ID P1. Para obtener información sobre los precios, vea Precios de Microsoft Entra.
Para obtener información sobre Exchange, consulte Precios de Exchange Server.
Para obtener información sobre AD FS y Web Application Proxy, vea Precios y licencias para Windows Server 2022.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad que tiene la carga de trabajo de reducirse horizontalmente de manera eficiente para satisfacer las demandas que los usuarios hayan realizado sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.
El rendimiento depende del rendimiento de los componentes implicados y del rendimiento de red de la empresa. Para obtener más información, consulte Ajuste del rendimiento de Office 365 mediante líneas de base y el historial de rendimiento.
Si desea obtener información sobre los factores del entorno local que influyen en el rendimiento en escenarios que incluyen los servicios de AD FS, vea estos recursos:
- Configurar la supervisión del rendimiento
- Ajuste de SQL y solución de problemas de latencia con AD FS
Escalabilidad
Para obtener información sobre la escalabilidad de AD FS, vea Planear la capacidad de los servidores de AD FS.
Si desea obtener información sobre la escalabilidad de Exchange Server en el entorno local, vea Arquitectura recomendada de Exchange 2019.
Implementación de este escenario
Para implementar este escenario, complete estos pasos resumidos:
- Comience con el servicio de acceso web. Mejore su seguridad mediante una directiva de acceso condicional de Azure para Exchange Online.
- Mejore la seguridad del acceso web para EMI local mediante la autenticación basada en notificaciones de AD FS.
Configuración de una directiva de acceso condicional
Para configurar una directiva de acceso condicional de Microsoft Entra que aplique la autenticación multifactor, como se describe en el paso 3 del flujo del usuario en línea anteriormente en este artículo:
Configure Office 365 Exchange Online u Office 365 como una aplicación en la nube:
Configure el explorador como una aplicación cliente:
Aplique el requisito de autenticación multifactor en la ventana Conceder:
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- Pavel Kondrashov | Arquitecto de soluciones en la nube
- Ella Parkum | Arquitecta e ingeniera principal de soluciones de clientes
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Anuncio de la autenticación moderna híbrida de Exchange local
- Introducción a la autenticación moderna híbrida y requisitos previos para su uso con servidores Skype Empresarial y Exchange locales
- Uso de la autenticación de AD FS basada en notificaciones con Outlook en la Web
- Arquitectura preferida de Exchange 2019
- Implementación de AD FS en Azure de alta disponibilidad entre regiones geográficas con Azure Traffic Manager