Compartir a través de

Resistencia mediante los procedimientos recomendados para desarrolladores

  • Artículo

En este artículo, puede beneficiarse de nuestra experiencia trabajando con clientes grandes. Puede considerar estas recomendaciones para el diseño y la implementación de los servicios.

Biblioteca de autenticación de Microsoft

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 para las aplicaciones. Estas bibliotecas están optimizadas para admitir Microsoft Identity, incluidas unas características que mejoran la resistencia de las aplicaciones.

Los desarrolladores pueden 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. En su lugar, use 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, con 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

  • Evitar las funciones de escritura en el directorio en el inicio de sesión: evite ejecutar un inicio de sesión de escritura 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. No requiera una escritura en cada inicio de sesión. Las condiciones previas en un recorrido del usuario son:

    <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. Cada operación tiene límites diferentes.

    • Una escritura durante el inicio de sesión se clasifica como POST para los nuevos usuarios, o como PUT para los usuarios actuales.
    • 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). Pruebe el sistema de Azure AD B2C y la aplicación para el tráfico máximo. Azure AD B2C puede 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 para completar la migración del usuario. Si divide el trabajo o el script de creación de usuarios con dos aplicaciones, puede usar el límite por aplicación. Asegúrese de que permanece 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 haya ninguna 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 las Restricciones y límites del servicio de Azure AD B2C.

Vigencia de los tokens

Si el servicio de autenticación de Azure AD B2C no puede completar nuevos registros e inicios de sesión, proporcione mitigación para los usuarios que han iniciado sesión. Con la configuración, los usuarios que han iniciado sesión pueden usar la aplicación sin interrupciones hasta que cierren la sesión de la aplicación o la sesión agote el tiempo de espera de la inactividad.

Los requisitos empresariales y la experiencia del usuario final dictan la frecuencia de actualización de 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 en el inicio de sesión, la aplicación depende de la cookie de la sesión para continuar ampliando la validez de la sesión. Permitir a los usuarios que mantengan la sesión iniciada mediante la implementación de tiempos de sesión graduales que se renuevan 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 como una configuración única en la aplicación. Mantenga la duración de la sesión en el máximo tiempo permitido.
  • SPA: una SPA puede depender de tokens de acceso para realizar llamadas a las API. Para las SPA, recomendamos usar el flujo de códigos de autorización con el flujo de Clave de prueba para el intercambio de códigos (PKCE) como opción para permitir que el usuario siga usando la aplicación. Si su SPA usa el flujo implícito, considere migrar al flujo de código de autorización con PKCE. Migre su aplicación de MSAL.js 1.x a MSAL.js 2.x para obtener la resistencia de las aplicaciones web. El flujo implícito no da como resultado 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 tiene una sesión activa con Azure AD B2C. En el caso de las SPA, hay algunas opciones para permitir que el usuario siga usando la aplicación.
    • Amplíe la duración de validez del token de acceso.
    • 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. 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.
    • Cambie a la opción recomendada. 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).
    • En el caso de las aplicaciones móviles, amplíe las duraciones del token de acceso y de actualización.
  • Aplicaciones de back-end o microservicios: las aplicaciones de back-end (demonio) no son interactivas y no están en un contexto de usuario, por lo que se reduce la posibilidad de robo de tokens. Nuestra recomendación es lograr un equilibrio entre la seguridad y la duración, así como establecer una duración larga de los tokens.

Inicio de sesión único

Con el inicio de sesión único (SSO), los usuarios inician sesión una vez con una cuenta y obtienen acceso a las aplicaciones: una web, un móvil o una aplicación de una sola página (SPA), independientemente de la plataforma o el nombre de dominio. Cuando el usuario inicia sesión 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 inicie 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 requiere una autenticación nueva.

Configuración del inicio de sesión único

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 para una autenticación nueva.

Procedimientos de implementación seguros

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

Protección contra 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 otros, tal como se documenta en OWASP Top 10. Implementar un firewall de aplicaciones web (WAF) para defenderse frente a puntos vulnerables comunes.

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) hace referencia al intervalo de tiempo de autorización de claves, utilizado por entidades legítimas, como un criptoperiodo. Elija la longitud necesaria de los criptoperiodos. Establezca la expiración y gire los secretos antes de que expiren.

Implementar 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 claves y certificados configurados en Azure AD B2C. Esta lista puede incluir las claves usadas en directivas personalizadas, API, token de identificador de firma y certificados para Lenguaje de Marcado para Confirmaciones de Seguridad (SAML).
  • Con CICD, rote los secretos que expiran 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 las credenciales de acceso de la API, como contraseñas y certificados.

Pruebas de API de REST

Para lograr resistencia, las pruebas de las API de REST deben incluir la comprobación de códigos HTTP, carga de respuesta, encabezados y rendimiento. No use solo las pruebas de ruta de acceso felices y confirme que la API controla los escenarios de problemas correctamente.

Plan de pruebas

Se recomienda que el plan de pruebas incluya pruebas de API completas. En el caso de los aumentos debido a una promoción o al tráfico por día festivo, revise las pruebas de carga con nuevas estimaciones. Realice pruebas de carga de API y Content Delivery Network (CDN) en un entorno de desarrollador, no en producción.

Pasos siguientes