Autenticación con Azure AD

La autenticación es un proceso que concede o deniega el acceso a un sistema mediante la comprobación de la identidad del descriptor de acceso. Use un servicio de identidad administrada para todos los recursos con el fin de simplificar la administración global (por ejemplo, las directivas de contraseñas) y minimizar el riesgo de cometer descuidos o errores humanos. Azure Active Directory (Azure AD) es un servicio integral de administración de identidades y acceso de Azure.

Puntos clave

• Use las identidades administradas para acceder a los recursos de Azure.
• Mantiene sincronizados los directorios locales y en la nube, excepto para las cuentas con privilegios elevados.
• Use preferiblemente métodos sin contraseña u opte por métodos de contraseña modernos.
• Habilite el acceso condicional de Azure AD basado en atributos clave de seguridad al autenticar a todos los usuarios, en especial para las cuentas con privilegios elevados.

Uso de la autenticación basada en identidad

¿Cómo se autentica la aplicación durante la comunicación con los servicios de la plataforma Azure?

Las identidades administradas permiten a los servicios de Azure autenticarse entre sí sin presentar credenciales explícitas a través del código y aumentar así la seguridad.

Managed Identities for Azure Resources es una característica de Azure Active Directory. Cada servicio de Azure compatible con Managed Identities for Azure Resources está sujeto a su propia escala de tiempo. Asegúrese de revisar el estado de disponibilidad de las identidades administradas para el recurso y los problemas conocidos antes de comenzar. Esta característica proporciona a los servicios de Azure una identidad de sistema administrada automáticamente en Azure AD. Puede usar esta identidad para autenticarse en cualquier servicio que admita la autenticación de Azure AD, incluido Key Vault, sin necesidad de credenciales en el código. La característica de identidades administradas para recursos de Azure se incluye gratuitamente en Azure AD con las suscripciones de Azure, sin ningún costo adicional.

Hay dos tipos de identidades administradas:

• Las identidades administradas asignadas por el sistema se habilitan directamente en las instancias de servicio de Azure. Cuando se habilita la identidad, Azure crea una identidad para la instancia del servicio en el inquilino de Azure AD de confianza de la suscripción de la instancia. Una vez creada la identidad, las credenciales se aprovisionan en la instancia. El ciclo de vida de una identidad asignada por el sistema está vinculado directamente a la instancia de servicio de Azure en que está habilitada. Si se elimina la instancia, Azure limpia automáticamente las credenciales y la identidad en Azure AD.
• Las identidades administrada asignadas por el usuario se crean como recursos de Azure independientes. Mediante un proceso de creación, Azure crea una identidad en el inquilino de Azure AD de confianza para la suscripción que se utiliza. Una vez creada la identidad, esta puede asignarse a una o varias instancias de servicio de Azure. El ciclo de vida de una identidad asignada por el usuario no se administra junto con el ciclo de vida de las instancias de servicio de Azure a las que se asigna.

Efectúe la autenticación mediante los servicios de identidad en lugar de usar claves criptográficas. En Azure, las identidades administradas eliminan la necesidad de almacenar credenciales que podrían filtrarse involuntariamente. Cuando las identidades administradas se habilitan para un recurso de Azure, se les asigna una identidad que el usuario puede usar para obtener tokens de Azure AD. Para más información, consulte la documentación de identidades administradas de Azure AD para recursos de Azure.

Por ejemplo, un clúster de Azure Kubernetes Service (AKS) necesita extraer imágenes de Azure Container Registry (ACR). Para acceder a la imagen, el clúster debe conocer las credenciales de ACR. El enfoque recomendado consiste en habilitar las identidades administradas durante la configuración del clúster. Esa configuración asigna una identidad al clúster y le permite obtener tokens de Azure AD.

Este enfoque es seguro porque Azure se ocupa de administrar las credenciales subyacentes para el usuario.

• En el ejemplo del clúster de AKS, la identidad está vinculada al ciclo de vida del recurso. Cuando se elimina el recurso, Azure elimina automáticamente la identidad.
• Azure AD administra la rotación periódica de secretos.

Acciones sugeridas

• Revise la autenticación de la carga de trabajo e identifique las oportunidades de convertir credenciales explícitas (por ejemplo, la cadena de conexión y la clave de API) para usar identidades administradas.
• Para todas las nuevas cargas de trabajo de Azure, normalice el uso de identidades administradas cuando corresponda.

Más información

¿Qué son las identidades administradas de recursos de Azure?

¿Qué tipo de autenticación requieren las API de la aplicación?

No presuponga que las direcciones URL de API utilizadas por una carga de trabajo están ocultas y no pueden quedar expuestas a atacantes. Por ejemplo, el código JavaScript de un sitio web se puede ver. Una aplicación móvil se puede descompilar e inspeccionar. Incluso en el caso de las API internas que solo se usan en el back-end, el requisito de autenticación puede aumentar la dificultad del desplazamiento lateral si un atacante accede a la red. Entre los mecanismos habituales, se incluyen claves de API, tokens de autorización o restricciones de IP.

La identidad administrada puede contribuir a que una API sea más segura ya que reemplaza el uso de entidades de servicio administradas por el usuario y puede solicitar tokens de autorización.

¿Cómo se controla la autenticación de usuarios en la aplicación?

No use implementaciones personalizadas para administrar las credenciales de usuario. En su lugar, use Azure AD u otros proveedores de identidades administradas, como el servicio Azure B2C de la cuenta de Microsoft. Los proveedores de identidades administradas proporcionan características de seguridad adicionales, como las modernas medidas de protección con contraseña, la autenticación multifactor (MFA) y los restablecimientos. En general, el método preferido son las medidas de protección sin contraseña. Además, los protocolos actuales, como OAuth 2.0, usan la autenticación basada en tokens, con un intervalo de tiempo limitado.

¿Los tokens de autenticación se almacenan en memoria caché de forma segura y se cifran al compartir entre servidores web?

El código de la aplicación primero debe intentar obtener tokens de acceso de OAuth silenciosamente desde una memoria caché antes de intentar adquirir un token del proveedor de identidades para optimizar el rendimiento y maximizar la disponibilidad. Los tokens se deben almacenar de forma segura y administrar como las demás credenciales. Cuando sea necesario compartir tokens en los servidores de aplicaciones (en lugar de que cada servidor adquiera y almacene en caché uno propio), deberá usarse el cifrado.

Para más información, consulte Adquisición y almacenamiento en caché de tokens.

Elección de un sistema con compatibilidad multiplataforma

Use un único proveedor de identidades para la autenticación en todas las plataformas (sistemas operativos, proveedores de nube y servicios de terceros).

Azure AD puede usarse para la autenticación en Windows, Linux, Azure, Office 365, otros proveedores de nube y servicios de terceros, como los proveedores de servicios.

Por ejemplo, mejore la seguridad de las máquinas virtuales Linux en Azure con la integración con Azure AD. Para más información, consulte Inicio de sesión en una máquina virtual Linux en Azure mediante la autenticación de Azure Active Directory.

Centralización de todos los sistemas de identidad

Mantenga la identidad en la nube sincronizada con los sistemas de identidad existentes para garantizar la coherencia y reducir los errores humanos.

La coherencia de las identidades en la nube y en el entorno local reducirá los errores humanos y los riesgos de seguridad que implican. Los equipos que administran recursos en ambos entornos necesitan un origen de autoridad coherente para lograr garantías de seguridad. Para la supervisión, si se puede determinar la identidad sin un proceso de asignación intermedio, la eficacia de la seguridad mejora.

La sincronización consiste en proporcionar a los usuarios una identidad en la nube en función de su identidad local. Tanto si usan una cuenta sincronizada para la autenticación como la autenticación federada, los usuarios deben tener una identidad en la nube. Esta identidad se debe mantener y actualizar periódicamente. Las actualizaciones pueden adoptar muchas formas, desde cambios en los títulos a cambios de contraseña.

Para comenzar, evalúe la solución de identidad local de la organización y los requisitos de los usuarios. Esta evaluación es importante, ya que define los requisitos técnicos respecto a cómo se crean y mantienen las identidades de los usuarios en la nube. Para la mayoría de las organizaciones, Active Directory se establece de forma local y será el directorio local desde el que se sincronizarán los usuarios, pero esto no siempre es así.

Considere la posibilidad de usar Azure AD Connect para sincronizar Azure AD con su directorio local. En el caso de los proyectos de migración, aplique el requisito de completar esta tarea antes de que empiecen los proyectos de desarrollo y migración de Azure.

Para más información, consulte los proveedores de identidades híbridos.

Más información

Sincronización de los sistemas de identidad híbridos

Uso de la autenticación sin contraseña

Los atacantes analizan constantemente los intervalos IP de la nube pública en busca de puertos de administración abiertos. Intentan aprovechar las credenciales débiles (Difusión de contraseña) y las vulnerabilidades sin revisar en los protocolos de administración como SSH y RDP. Impedir el acceso directo a Internet a las máquinas virtuales detiene una configuración incorrecta o impide que una omisión se agrave.

Los métodos de ataque han evolucionado hasta el punto en el que las contraseñas por sí solas no pueden proteger una cuenta de forma confiable. Las soluciones de autenticación modernas, como la autenticación multifactor y sin contraseña, aumentan la posición de seguridad a través de la autenticación segura.

Elimine el uso de contraseñas siempre que sea posible. Además, solicite el mismo juego de credenciales para iniciar sesión y acceder a los recursos locales o en la nube. Este requisito es fundamental para las cuentas que requieren contraseñas, como las cuentas de administrador.

Con las características de autenticación y seguridad modernas de Azure AD, esa contraseña básica se debe complementar o reemplazar con métodos de autenticación más seguros. Cada organización tiene diferentes necesidades en cuanto a la autenticación. Microsoft ofrece las tres opciones siguientes de autenticación sin contraseña que se integran con Azure Active Directory (Azure AD):

• Windows Hello para empresas
• Aplicación Microsoft Authenticator
• Claves de seguridad FIDO2

Se recomienda seguir un plan de cuatro fases para que el proceso sea sin contraseña:

• Desarrollo de una oferta de reemplazo de contraseña
• Reducción del área expuesta de la contraseña visible para el usuario
• Transición a una implementación sin contraseña
• Eliminación de contraseñas del directorio de identidades

Los métodos de autenticación siguientes están ordenados del costo más elevado o la mayor dificultad de ataque (opciones más seguras/preferidas) al costo más bajo o la menor dificultad de ataque:

• Autenticación sin contraseña. Algunos ejemplos de este método incluyen Windows Hello o la aplicación de autenticación.
• MFA. Aunque este método es más eficaz que las contraseñas, es recomendable no confiar en la autenticación multifactor basada en mensajes de texto SMS. Para más información, consulte el artículo sobre la habilitación de Azure Active Directory MFA por usuario para proteger los eventos de inicio de sesión.
• Identidades administradas. Consulte Uso de la autenticación basada en identidad.

Los métodos afectan a todos los usuarios, pero debe aplicarse primero y con mayor rigurosidad a las cuentas con privilegios administrativos.

La implementación de esta estrategia permite habilitar el inicio de sesión único en dispositivos, aplicaciones y servicios. Al iniciar sesión una vez con una única cuenta de usuario, puede conceder acceso a todas las aplicaciones y recursos según las necesidades de la empresa. Los usuarios no tienen que administrar varios conjuntos de nombres de usuario y contraseñas. Puede aprovisionar o desaprovisionar el acceso a la aplicación automáticamente. Para más información, consulte Inicio de sesión único.

Acciones sugeridas

• Desarrolle una estrategia sin contraseña que requiera MFA para todos los usuarios sin afectar significativamente a las operaciones.
• Asegúrese de que la directiva y los procesos exijan que las máquinas virtuales restrinjan y supervisen la conectividad directa a Internet.

Más información

• Estrategia sin contraseña
• Eliminación de la conectividad directa a Internet de la máquina virtual (VM)

Uso de la protección de contraseñas moderna

Se trata de usar protecciones modernas con métodos que reducen el uso de contraseñas. Los protocolos de autenticación modernos admiten controles seguros, como MFA, y deben usarse en lugar de métodos de autenticación heredados. El uso de métodos heredados aumenta el riesgo de exposición de credenciales.

La autenticación moderna es un método de administración de identidades que ofrece una autenticación y autorización de usuario más seguras. Está disponible para implementaciones híbridas de Office 365 de servidores de Skype Empresarial locales y servidores Exchange locales, e implementaciones híbridas de Skype Empresarial de dominio dividido.

La autenticación moderna es un término genérico para hacer referencia a una combinación de métodos de autenticación y autorización entre un cliente (por ejemplo, el portátil o el teléfono) y un servidor, así como algunas medidas de seguridad que se basan en directivas de acceso con las que puede que ya esté familiarizado. Incluye:

• Métodos de autenticación: MFA, autenticación con tarjeta inteligente, autenticación basada en certificados de cliente.
• Métodos de autorización: implementación de Microsoft de Open Authorization (OAuth).
• Directivas de acceso condicional: administración de aplicaciones móviles (MAM) y acceso condicional de Azure Active Directory (Azure AD).

Revise las cargas de trabajo que no usan los protocolos de autenticación modernos y realice la conversión siempre que sea posible. Además, estandarice el uso de protocolos de autenticación modernos en todas las cargas de trabajo futuras.

En el caso de Azure, habilite las protecciones en Azure AD:

1. Configure Azure AD Connect para sincronizar los valores hash de contraseña. Para más información, consulte Implementación de la sincronización de hash de contraseñas con la sincronización de Azure AD Connect.

2. Elija si desea corregir de forma manual o automática los problemas detectados en un informe. Para más información, consulte Comprobación de los riesgos de identidad.

Para más información sobre la compatibilidad con las contraseñas modernas en Azure AD, consulte los siguientes artículos:

• ¿Qué es Identity Protection?
• Aplicación de Protección con contraseña de Azure AD local en Active Directory Domain Services
• Informe de seguridad sobre usuarios en riesgo
• Informe de seguridad sobre inicios de sesión de riesgo

Para más información sobre cómo admitir contraseñas modernas en Office 365, consulte el siguiente artículo:

¿Qué es la autenticación moderna?

Habilitar el acceso condicional

Las modernas aplicaciones basadas en la nube suelen ser accesibles a través de Internet, por lo que el acceso basado en la ubicación de la red es inflexible y las contraseñas de un solo factor son una responsabilidad. El acceso condicional describe la directiva de autenticación para una decisión de acceso. Por ejemplo, si un usuario se conecta desde un equipo corporativo administrado por InTune, es posible que no se le rete a realizar MFA cada vez, pero si el usuario se conecta de repente desde un dispositivo diferente en una ubicación geográfica diferente, se requerirá MFA.

Administre las solicitudes de acceso en función del nivel de confianza de los solicitantes y la confidencialidad de los recursos de destino.

¿Existen requisitos de acceso condicional para la aplicación?

Las cargas de trabajo pueden quedar expuestas en la red pública de Internet, y los controles de red basados en la ubicación no se aplicarán. Para habilitar el acceso condicional, debe conocer las restricciones que son necesarias para el caso de uso. Por ejemplo, se necesita MFA para el acceso remoto; y el filtrado basado en IP se puede usar para habilitar la depuración ad hoc (se prefieren las VPN).

Configure el acceso condicional de Azure AD mediante la directiva de acceso para la administración de Azure en función de sus necesidades operativas. Para más información, consulte Administración del acceso a la administración de Azure con acceso condicional.

El acceso condicional puede ser un modo eficaz de eliminar de forma progresiva la autenticación heredada y los protocolos asociados. Las directivas deben aplicarse a todos los administradores y a otras cuentas con un impacto crítico. Empiece a utilizar métricas y registros para determinar los usuarios que todavía se autentican por medio de clientes antiguos. A continuación, deshabilite los protocolos de nivel inferior que no se usen y configure el acceso condicional para todos los usuarios que no utilicen protocolos heredados. Por último, informe y proporcione directrices a los usuarios sobre la actualización antes de bloquear completamente la autenticación heredada. Para más información, consulte el artículo sobre la compatibilidad con el acceso condicional de Azure AD para bloquear la autenticación heredada.

Acciones sugeridas

Implemente directivas de acceso condicional para esta carga de trabajo.

Más información sobre Acceso condicional de Azure AD.

Siguiente

Conceda o deniegue el acceso a un sistema mediante la comprobación de la identidad del descriptor de acceso.

Vínculos relacionados

Vuelva al artículo principal: Consideraciones sobre la administración de identidades y acceso de Azure