Resistencia mediante los procedimientos recomendados para desarrolladores

  • Artículo

En este artículo, compartimos algunos aprendizajes que se basan en la experiencia que tenemos de trabajar con clientes de gran tamaño. Puede tener en cuenta estas recomendaciones en el diseño y la implementación de los servicios.

Image shows developer experience components

Uso de la Biblioteca de autenticación de Microsoft (MSAL)

La Biblioteca de autenticación de Microsoft (MSAL) y la biblioteca de autenticación web de Microsoft Identity para ASP.NET simplifican la adquisición, administración, almacenamiento en caché y actualización de los tokens que requiere una aplicación. Estas bibliotecas están optimizadas específicamente para admitir Microsoft Identity, incluidas unas características que mejoran la resistencia de las aplicaciones.

Los desarrolladores deben adoptar las versiones más recientes de MSAL y mantenerlas actualizadas. Consulte el artículo sobre cómo aumentar la resistencia de la autenticación y la autorización en las aplicaciones. Siempre que sea posible, evite implementar su propia pila de autenticación y utilice bibliotecas bien establecidas.

Optimización de lecturas y escrituras en el directorio

El servicio de directorio de Azure AD B2C admite miles de millones de autenticaciones al día. Está diseñado para una alta tasa de lecturas por segundo. Optimice las escrituras para minimizar las dependencias y aumentar la resistencia.

Optimización de lecturas y escrituras en el directorio

  • Evite las funciones de escritura en el directorio en el inicio de sesión: No ejecute nunca una escritura en el inicio de sesión sin una condición previa (cláusula if) en las directivas personalizadas. Un caso de uso que requiere una escritura en un inicio de sesión es la migración Just-in-Time de las contraseñas de usuario. Evite cualquier escenario que requiera una escritura en cada inicio de sesión. Las condiciones previas en un recorrido del usuario tendrán el siguiente aspecto:

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Descripción de la limitación: el directorio implementa reglas de limitación tanto en el nivel de aplicación como de inquilino. Existen más límites de frecuencia para las operaciones de lectura/GET, escritura/POST, actualización/PUT y eliminación/DELETE, y cada operación tiene límites diferentes.

    • Una escritura en el momento del inicio de sesión entrará en un POST para los nuevos usuarios o un PUT para los usuarios existentes.
    • Una directiva personalizada que crea o actualiza un usuario en cada inicio de sesión, puede alcanzar un límite de frecuencia de PUT o POST de nivel de aplicación. Los mismos límites se aplican al actualizar objetos de directorio mediante Microsoft Entra ID o Microsoft Graph. Examine igualmente las lecturas para mantener al mínimo el número de lecturas en cada inicio de sesión.
    • Calcule la carga máxima para predecir la frecuencia de escritura de directorios y evitar la limitación. Las estimaciones de tráfico máximo deben incluir estimaciones de acciones como registro, inicio de sesión y autenticación multifactor (MFA). Asegúrese de probar el sistema de Azure AD B2C y la aplicación para el tráfico máximo. Es posible que Azure AD B2C pueda administrar la carga sin limitación, cuando sus aplicaciones o servicios de bajada no puedan hacerlo.
    • Comprenda y planee la escala de tiempo de migración. Al planear la migración de usuarios a Azure AD B2C mediante Microsoft Graph, tenga en cuenta los límites de la aplicación y del inquilino a fin de calcular el tiempo necesario para completar la migración de los usuarios. Si divide el trabajo o el script de creación de usuarios con dos aplicaciones, puede usar el límite por aplicación. Aún así, debe permanecer por debajo del umbral por inquilino.
    • Comprenda los efectos del trabajo de migración en otras aplicaciones. Tenga en cuenta el tráfico dinámico atendido por otras aplicaciones de confianza para asegurarse de que no se produce una limitación en el nivel de inquilino y el colapso de los recursos para la aplicación activa. Para más información, consulte Guía de limitación de Microsoft Graph.
    • Utilice un ejemplo de prueba de carga para simular el registro y el inicio de sesión.
    • Obtenga más información sobre los límites y restricciones del servicio de Azure Active Directory B2C.

Ampliación de las duraciones de tokens

En el caso improbable de que el servicio de autenticación de Azure AD B2C no pueda completar nuevos registros e inicios de sesión, aún puede proporcionar una mitigación para los usuarios que hayan iniciado sesión. Con configuración, puede permitir que los usuarios que ya hayan iniciado sesión sigan utilizando la aplicación sin que perciban interrupción alguna hasta que el usuario salga de la aplicación o se agote el tiempo de espera de la sesión por inactividad.

Sus requisitos empresariales y la experiencia del usuario final que desee determinarán la frecuencia de actualización de los tokens para aplicaciones web y de página única (SPA).

Ampliación de las duraciones de tokens

  • Aplicaciones web En el caso de las aplicaciones web en las que el token de autenticación se valida al principio del inicio de sesión, la aplicación depende de la cookie de la sesión para continuar ampliando la validez de la sesión. Permita a los usuarios que mantengan la sesión iniciada mediante la implementación de tiempos de sesión graduales que seguirán renovando las sesiones en función de la actividad del usuario. Si hay una interrupción de emisión de tokens a largo plazo, estos horarios de sesión pueden aumentarse aún más como una configuración única en la aplicación. Mantenga la duración de la sesión en el máximo tiempo permitido.
  • Aplicación de página única (SPA) : Una SPA puede depender de los tokens de acceso para realizar llamadas a las API. Una SPA utiliza tradicionalmente el flujo implícito que no produce un token de actualización. La SPA puede usar un iframe oculto para realizar nuevas solicitudes de tokens en el punto de conexión de autorización si el explorador aún tiene una sesión activa con Azure AD B2C. En el caso de las SPA, hay algunas opciones disponibles que permiten al usuario seguir utilizando la aplicación.
    • Amplíe la duración de validez del token de acceso para satisfacer sus necesidades empresariales.
    • Compile la aplicación para que utilice una puerta de enlace de API como proxy de autenticación. En esta configuración, la SPA se carga sin autenticación, y las llamadas API se realizan en la puerta de enlace de API. La puerta de enlace de API envía el usuario a un proceso de inicio de sesión mediante una concesión de código de autorización basada en una directiva y autentica al usuario. Después, la sesión de autenticación entre la puerta de enlace de API y el cliente se mantiene mediante una cookie de autenticación. Las API se atienden desde la puerta de enlace de API mediante el token obtenido por la puerta de enlace de API (u otro método de autenticación directo, como certificados, credenciales de cliente o claves de API).
    • Migre la SPA desde una concesión implícita a un flujo de concesión de código de autorización con la clave de prueba para el intercambio de códigos (PKCE) y la compatibilidad con el uso compartido de recursos entre orígenes (CORS). Migre su aplicación de MSAL.js 1.x a MSAL.js 2.x para obtener la resistencia de las aplicaciones web.
    • En el caso de las aplicaciones móviles, se recomienda ampliar las duraciones de actualización y de token de acceso.
  • Aplicaciones de back-end o de microservicios: Dado que las aplicaciones de back-end (demonio) no son interactivas y no están en un contexto de usuario, la perspectiva de robos de tokens se reduce considerablemente. La recomendación es lograr un equilibrio entre la seguridad y la duración, así como establecer una duración larga de los tokens.

Configuración del inicio de sesión único

Con el inicio de sesión único (SSO), los usuarios inician sesión una vez con una sola cuenta y obtienen acceso a varias aplicaciones. La aplicación puede ser una aplicación web, de móvil o de página única (SPA), sea cual sea la plataforma o el nombre de dominio. Cuando el usuario inicia sesión por primera vez en una aplicación, Azure AD B2C conserva una sesión basada en cookies.

En las solicitudes de autenticación posteriores, Azure AD B2C lee y valida la sesión basada en cookies y emite un token de acceso sin pedir al usuario que vuelva a iniciar sesión. Si el inicio de sesión único se configura con un ámbito limitado en una directiva o una aplicación, el acceso posterior a otras directivas y aplicaciones requerirá una autenticación nueva.

Configuración del inicio de sesión único (SSO)

Configure SSO de forma que sea para todo el inquilino (opción predeterminada) y permitir que varias aplicaciones y flujos de usuario del inquilino compartan la misma sesión de usuario. La configuración de todo el inquilino proporciona la mayor resistencia a una autenticación nueva.

Procedimientos de implementación seguros

Las interrupciones más comunes del servicio son los cambios en el código y la configuración. La adopción de procesos y herramientas de integración continua y entrega continua (CICD) contribuye a una implementación rápida a gran escala y reduce los errores humanos durante las pruebas y la implementación en producción. Adopte CICD para lograr la reducción de errores, eficacia y coherencia. Azure Pipelines es un ejemplo de CICD.

Protección frente a bots

Proteja sus aplicaciones frente a puntos vulnerables conocidos como ataques de denegación de servicio distribuido (DDoS), inyecciones de SQL, scripts entre sitios, ejecución remota de código y muchos otros, tal como se documenta en OWASP Top 10. La implementación de Firewall de aplicaciones web (WAF) puede proteger frente a puntos vulnerables comunes.

Cambio de secretos

Azure AD B2C usa secretos para las aplicaciones, las API, las directivas y el cifrado. Los secretos protegen la autenticación, las interacciones externas y el almacenamiento. El National Institute of Standards and Technology (NIST) llama al intervalo de tiempo durante el cual una clave específica está autorizada para su uso por parte de entidades legítimas un período criptográfico. Elija la longitud adecuada del período criptográfico para satisfacer sus necesidades empresariales. Los desarrolladores tienen que establecer manualmente la expiración y rotar los secretos con antelación a su expiración.

Implementación de la rotación de secretos

  • Utilice identidades administradas para recursos admitidos a fin de autenticarse en los servicios que admiten la autenticación de Microsoft Entra. Al utilizar identidades administradas, puede administrar los recursos de forma automática, incluida la rotación de credenciales.
  • Realice un inventario de todas las claves y certificados configurados en Azure AD B2C. Es probable que esta lista incluya las claves usadas en directivas personalizadas, API, token de identificador de firma y certificados para SAML.
  • Con CICD, rote los secretos que van a expirar en un plazo de dos meses desde el período máximo previsto. El período criptográfico máximo recomendado de las claves privadas asociadas a un certificado es de un año.
  • Supervise y rote de forma proactiva las credenciales de acceso de la API, como contraseñas y certificados.

Prueba de API REST

En el contexto de resistencia, las pruebas de las API REST deben incluir la comprobación de: códigos HTTP, carga de respuesta, encabezados y rendimiento. La prueba no debe incluir solo las pruebas de la ruta de acceso superadas, sino también comprobar si la API administra los escenarios problemáticos correctamente.

Procedimientos para probar API

Se recomienda que el plan de pruebas incluya unas pruebas de API completas. Si está planeando realizar un aumento en breve debido al tráfico que generan las promociones o los períodos de vacaciones, debe revisar las pruebas de carga con las nuevas estimaciones. Realice pruebas de carga de las API y Content Delivery Network (CDN) en un entorno de desarrollo y no en producción.

Pasos siguientes