Partager via

Résilience grâce aux meilleures pratiques des développeurs

  • Article

Dans cet article, vous allez découvrir quelques enseignements basés sur notre expérience de travail avec des clients importants. Vous pouvez prendre en compte ces recommandations pour la conception et l’implémentation de vos services.

Diagramme des composants de l’expérience de développeur

Microsoft Authentication Library

La bibliothèque d’authentification Microsoft (MSAL) et la bibliothèque d’authentification Microsoft Identity Web pour ASP.NET simplifient l’acquisition, la gestion, la mise en cache et l’actualisation des jetons requis pour les applications. Ces bibliothèques sont optimisées pour prendre en charge Microsoft Identity, notamment les fonctionnalités qui améliorent la résilience des applications.

Les développeurs peuvent adopter les dernières versions de MSAL et rester à jour. Découvrez comment accroître la résilience de l’authentification et de l’autorisation dans vos applications. Dans la mesure du possible, évitez d’implémenter votre propre pile d’authentification. Utilisez plutôt des bibliothèques bien établies.

Optimiser les lectures et écritures dans les répertoires

Le service d’annuaire Azure AD B2C prend en charge des milliards d’authentifications par jour, avec un taux élevé de lectures par seconde.. Optimisez vos écritures pour réduire les dépendances et augmenter la résilience.

Optimisation des lectures et écritures dans les répertoires

  • Évitez les fonctions d’écriture dans l’annuaire lors de la connexion : évitez d’exécuter une écriture lors de la connexion sans précondition (clause if) dans vos stratégies personnalisées. Un cas d’usage nécessitant une écriture au moment de la connexion est la migration juste-à-temps des mots de passe utilisateur. N’exigez pas une écriture à chaque connexion. Les préconditions d’un parcours utilisateur sont les suivantes :

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

  • Comprendre la limitation : l’annuaire implémente des règles de limitation au niveau de l’application et du locataire. Il existe davantage de limites de taux pour les opérations de lecture/GET, d’écriture/POST, de mise à jour/PUT et de suppression/DELETE. Chaque opération a des limites différentes.

    • Une écriture pendant la connexion est catégorisée comme POST pour les nouveaux utilisateurs, ou comme PUT pour les utilisateurs actuels.
    • Une stratégie personnalisée qui crée ou met à jour un utilisateur à chaque connexion peut atteindre une limite de taux PUT ou POST au niveau de l’application. Les mêmes limites s’appliquent lors de la mise à jour des objets d’annuaire via Microsoft Entra ID ou Microsoft Graph. De même, examinez les lectures afin de réduire au minimum le nombre de lectures à chaque connexion.
    • Estimez le pic de charge pour prédire le taux d’écritures sur le répertoire et éviter la limitation. Les estimations des pics de trafic doivent inclure des estimations pour des actions telles que l’inscription, la connexion et l’authentification multifacteur (MFA). Testez le système Azure AD B2C et votre application pour les pics de trafic. Azure AD B2C peut gérer la charge sans limitation, lorsque vos applications ou services en aval ne le feront pas.
    • Comprenez et planifiez la chronologie de votre migration. Lorsque vous envisagez de migrer des utilisateurs vers Azure AD B2C à l’aide de Microsoft Graph, tenez compte des limites de l’application et du locataire pour calculer le temps nécessaire à la migration des utilisateurs. Si vous divisez votre travail de création d’utilisateur ou votre script en utilisant deux applications, vous pouvez utiliser la limite par application. Vérifiez qu’elle reste inférieure au seuil par locataire.
    • Comprenez les effets de votre tâche de migration sur d’autres applications. Tenez compte du trafic en direct traité par d’autres applications de confiance, afin de garantir l’absence de limitation au niveau du locataire et de privation de ressources pour votre application active. Pour plus d’informations, consultez les conseils sur la limitation de Microsoft Graph.
    • Utilisez un exemple de test de charge pour simuler l’inscription et la connexion.
    • En savoir plus sur les limites et restrictions du service Azure Active Directory B2C.

Durées de vie des jetons

Si le service d’authentification Azure AD B2C ne parvient pas à effectuer de nouvelles inscriptions et connexions, fournissez une atténuation pour les utilisateurs qui sont connectés. Avec la configuration, les utilisateurs connectés peuvent utiliser l’application sans interruption tant qu’ils ne se déconnectent pas de l’application ou que la session n’a pas expiré pour cause d’inactivité.

Vos exigences métier et l’expérience utilisateur final dictent la fréquence d’actualisation des jetons pour les applications web et les applications monopages (SPA).

Prolonger la durée de vie des jetons

  • Applications web : pour les applications web où le jeton d’authentification est validé au moment de la connexion, l’application dépend du cookie de session pour continuer à prolonger la validité de la session. Permettez aux utilisateurs de rester connectés en implémentant des durées de session continues qui renouvellent les sessions en fonction de l’activité de l’utilisateur. En cas d’interruption prolongée de l’émission de jetons, ces durées de session peuvent être augmentées en tant que configuration unique sur l’application. Maintenez la durée de vie de la session au maximum autorisé.
  • SPA : une SPA peut dépendre de jetons d’accès pour effectuer des appels aux API. Pour les SPA, nous vous recommandons d’utiliser le flux de code d’autorisation avec le flux Proof Key for Code Exchange (PKCE) comme option permettant à l’utilisateur de continuer à utiliser l’application. Si votre spa utilise un flux implicite, envisagez de migrer vers le flux de code d’autorisation avec PKCE. Migrez votre application de MSAL.js 1.x vers MSAL.js 2.x pour réaliser la résilience des applications web. Le flux implicite ne génère pas de jeton d’actualisation. La SPA peut utiliser un iframe masqué pour effectuer de nouvelles demandes de jeton auprès du point de terminaison d’autorisation si le navigateur a une session active auprès d’Azure AD B2C. Pour les SPA, il existe quelques options permettant à l’utilisateur de continuer à utiliser l’application.
    • Étendez la durée de validité du jeton d’accès.
    • Construisez votre application de manière à utiliser une passerelle API comme proxy d’authentification. Dans cette configuration, la SPA se charge sans authentification et les appels d’API sont effectués vers la passerelle API. La passerelle API fait passer l’utilisateur par un processus de connexion utilisant un octroi de code d’autorisation, en fonction d’une stratégie, et authentifie l’utilisateur. La session d’authentification entre la passerelle API et le client est maintenue à l’aide d’un cookie d’authentification. La passerelle API dessert les API en utilisant le jeton obtenu par la passerelle API, ou une autre méthode d’authentification directe telle que des certificats, des identifiants client ou des clés API.
    • Basculez vers l’option recommandée. Migrez votre SPA de l’octroi implicite vers le flux d’octroi de code d’autorisation avec la prise en charge de PKCE (Proof Key for Code Exchange) et CORS (Cross-Origin Resource Sharing).
    • Pour les applications mobiles, étendez les durées de vie des jetons d’actualisation et des jetons d’accès.
  • Applications back-end ou de microservices: les applications back-end (démon) n’étant pas interactives et n’étant pas dans un contexte utilisateur, la probabilité de vol de jetons est réduite. Nous recommandons de trouver un juste équilibre entre la sécurité et la durée de vie, et de définir une durée de vie longue pour les jetons.

Authentification unique

Avec l’authentification unique, les utilisateurs se connectent une fois avec un compte et obtiennent l’accès aux applications : une application web, mobile ou monopage (SPA), quel que soit le nom de domaine ou la plateforme. Lorsque l’utilisateur se connecte à une application, Azure AD B2C maintient une session basée sur un cookie.

Lors des demandes d’authentification suivantes, Azure AD B2C lit et valide la session basée sur un cookie, et émet un jeton d’accès sans inviter l’utilisateur à se connecter. Si l’authentification unique est configurée avec une étendue limitée au niveau d’une stratégie ou d’une application, l’accès ultérieur à d’autres stratégies et applications nécessite une nouvelle authentification.

Configurer l’authentification unique

Configurez l’authentification unique de manière à ce qu’elle s’applique à l’ensemble du locataire (par défaut) pour permettre à plusieurs applications et flux d’utilisateurs de votre locataire de partager la même session utilisateur. La configuration à l’échelle du locataire offre la meilleure résilience pour la nouvelle authentification.

Pratiques de déploiement sécurisé

Les interruptions de service les plus courantes sont les modifications de code et de configuration. L’adoption de processus et d’outils d’intégration continue et de livraison continue (CI/CD) permet un déploiement à grande échelle, et réduit les erreurs humaines pendant les tests et le déploiement. Adoptez CI/CD à des fins de réduction des erreurs, d’efficacité et de cohérence. Azure Pipelines est un exemple de CI/CD.

Protection contre les bots

Protégez vos applications contre les vulnérabilités connues, telles que les attaques par déni de service distribué (DDoS), les injections SQL, les scripts intersites, l’exécution de code à distance et autres, comme indiqué dans Les 10 principales vulnérabilités de l’OWASP. Déployez un pare-feu d’applications web (WAF) pour vous défendre contre les codes malveillants exploitant une faille de sécurité et les vulnérabilités courantes.

Secrets

Azure AD B2C utilise des secrets pour les applications, les API, les stratégies et le chiffrement. Les secrets sécurisent l’authentification, les interactions externes et le stockage. Le National Institute of Standards and Technology (NIST) appelle cryptopériode l’intervalle de temps pendant lequel une clé est autorisée à être utilisée par des entités légitimes. Choisissez la longueur nécessaire des cryptopériodes. Définissez l’expiration et faites pivoter les secrets avant leur expiration.

Implémenter la rotation des secrets

  • Utilisez des identités managées pour les ressources prises en charge afin de vous authentifier auprès d’un service qui prend en charge l’authentification Microsoft Entra. Lorsque vous utilisez des identités managées, vous pouvez gérer les ressources automatiquement, notamment la rotation des informations d’identification.
  • Effectuez un inventaire des clés et certificats configurés dans Azure AD B2C. Cette liste peut inclure des clés utilisées dans des stratégies personnalisées, des API, un jeton d’ID de signature, et des certificats pour SAML (Security Assertion Markup Language).
  • À l’aide de CI/CD, alternez les secrets qui vont expirer dans les deux mois suivant la saison de pointe prévue. La durée maximale recommandée de cryptoperiod des clés privées associées à un certificat est d’un an.
  • Surveillez et alternez les informations d’identification d’accès à l’API, telles que les mots de passe et les certificats.

Tests des API REST

Pour la résilience, les tests des API REST doivent inclure la vérification des codes HTTP, de la charge utile de réponse, des en-têtes et des performances. N’utilisez pas uniquement des tests de parcours heureux, et confirmez que l’API gère correctement les scénarios à problème.

Plan de test

Nous vous recommandons d’inclure dans votre plan de test des tests d’API complets. Pour les pics dus à une promotion ou à un trafic de vacances, révisez les tests de charge avec de nouvelles estimations. Procédez à un test de charge d’API et du réseau de distribution de contenu (CDN) dans un environnement de développement, et non en production.

Étapes suivantes