Passer au contenu principal

État

Vous devez vous assurer que votre équipe des opérations sait comment surveiller l’état du service Auth0 et qu’elle a mis en place un moyen de s’abonner aux mises à jour sur l’état d’Auth0. Le tableau de bord d’état d’Auth0, ainsi que le tableau de bord de disponibilité d’Auth0, affichent l’état actuel et l’historique du service Auth0 dans un format en langage clair. Si des alertes de surveillance se déclenchent, votre équipe des opérations devrait, dans un premier temps, consulter le tableau de bord d’état pour vérifier s’il y a une panne en cours. La page d’état du cloud public permet aussi de s’abonner aux notifications de panne. Nous vous recommandons également de vérifier l’état de tout service externe tiers dont vous dépendez, comme les fournisseurs sociaux. Avoir cette information à portée de main peut aider à écarter rapidement certaines causes possibles lors du dépannage d’un problème et devrait figurer en tête de la liste de vérification de dépannage, autant pour les développeurs que pour le personnel du centre d’assistance.

Bonne pratique

Les renseignements expliquant comment vérifier l’état d’Auth0 ainsi que celui des services dont vous dépendez (comme les fournisseurs sociaux) devraient figurer en tête d’une liste de vérification de dépannage, autant pour les développeurs que pour le personnel du centre d’assistance. Nous vous recommandons également de vous abonner à la page d’état d’Auth0 afin de recevoir des notifications sur toute mise à jour de l’état.
En cas de panne du service de cloud public, Auth0 effectue une analyse de la cause fondamentale (RCA) et publie les résultats sur la page d’état d’Auth0. Après une panne, Auth0 mène une enquête approfondie — y compris pour déterminer la cause fondamentale, les facteurs contributifs et les moyens d’éviter que le problème ne se reproduise —; par conséquent, la publication d’un document RCA peut prendre quelques semaines.

Configuration du fournisseur de courriel

Vous devriez vérifier de nouveau que vous avez configuré votre propre fournisseur de courriel pour prendre en charge les volumes de courriels de production susceptibles d’être envoyés aux clients pour l’inscription, la validation du courriel, la récupération de compte, etc. Auth0 envoie des courriels aux utilisateurs pour des événements comme le message de bienvenue à l’inscription, la validation du courriel, la détection d’un mot de passe compromis et la réinitialisation du mot de passe. Vous pouvez personnaliser les modèles de courriel pour chaque type d’événement, et il est aussi possible de personnaliser de façon avancée le traitement des courriels. Auth0 fournit un fournisseur de courriel de test à capacité limitée pour les tests de base, mais vous devez configurer votre propre fournisseur de courriel pour une utilisation en production, et la personnalisation des modèles de courriel ne fonctionnera pas tant que vous n’aurez pas configuré votre propre fournisseur.

Bonne pratique

Le fournisseur de courriel par défaut d’Auth0 ne prend pas en charge l’envoi de volumes de courriels de production ni la personnalisation des modèles de courriel. Vous devriez donc configurer votre propre fournisseur de courriel avant le déploiement en production.

Infrastructure

Pare-feu

Si du code personnalisé exécuté dans Auth0 (par exemple dans une Action, une Rule, un Hook ou des scripts de base de données personnalisés) appelle un service à l’intérieur de votre réseau, ou si vous configurez un fournisseur SMTP sur site dans Auth0, vous devrez peut-être configurer votre pare-feu pour autoriser le trafic entrant provenant d’Auth0. Les adresses IP à autoriser dans le pare-feu sont propres à chaque région et figurent dans les écrans de configuration des Rules, des Hooks, des scripts de base de données personnalisés et du fournisseur de courriel dans votre .

NTP

Si votre environnement d’hébergement ne s’en charge pas automatiquement, vous devriez disposer de scripts qui redémarrent automatiquement NTP (Network Time Protocol) en cas de panne, ainsi que d’alertes pour avertir quelqu’un si NTP ne fonctionne pas. Les transactions d’authentification dépendent d’une heure système précise, car les peuvent être considérés comme expirés au moment de leur réception s’il y a un décalage horaire entre les systèmes d’envoi et de réception.

Délais d’expiration du répartiteur de charge vérifiés

Si vous utilisez le connecteur AD/LDAP, vous devriez vérifier les paramètres du répartiteur de charge dans votre environnement pour voir s’ils interrompent les connexions longues inactives. Si c’est le cas, vous pouvez modifier les paramètres de connexion AD/LDAP d’Auth0 pour utiliser le paramètre LDAP_HEARTBEAT_SECONDS afin d’envoyer périodiquement des messages de pulsation et de maintenir la connexion ouverte.

Configuration du répartiteur de charge

Si votre application conserve l’état du serveur au point de dépendre d’un équilibrage de charge avec persistance de session pour acheminer les utilisateurs vers un serveur précis, il peut être utile de revérifier que toutes les configurations du répartiteur de charge sont correctes. Un répartiteur de charge dans un groupe qui n’est pas synchronisé peut entraîner des erreurs intermittentes difficiles à diagnostiquer. Une vérification rapide de la configuration du répartiteur de charge peut éviter ce genre de problème dès le départ.

Journaux

Vous devriez vérifier que vous avez mis en place la collecte des données de journal, que les journaux sont couverts par votre stratégie de conservation des données et que vous disposez de mécanismes pour faire respecter les limites de conservation des journaux. Vous devriez également vous assurer que vos équipes de développement, d’assistance et de sécurité savent comment accéder aux données de journal à des fins de dépannage et d’informatique judiciaire. L’exportation des fichiers journaux vers des services offrant des analyses complètes peut vous aider à repérer des tendances, comme les tendances d’utilisation et les erreurs. Auth0 offre de solides capacités de journalisation des événements, ainsi que d’analyse des journaux pour détecter les anomalies d’événements (consultez la documentation sur les journaux pour plus de détails). La période de conservation standard des journaux Auth0 est déterminée par le niveau d’abonnement; la plus courte est de deux jours et la plus longue n’est que de 30 jours. Grâce à la prise en charge par Auth0 de l’intégration avec des services de journalisation externes, vous pourrez conserver les journaux au-delà de cette période et aussi agréger les journaux à l’échelle de votre organisation.

Pratique exemplaire

Vous devriez tirer parti de l’une des solutions de diffusion de journaux pour envoyer les données de journal à un service externe d’analyse de journaux. Cela vous permettra de conserver les données plus longtemps et de bénéficier d’analyses avancées des données de journal.
Vous devriez examiner la période de conservation des données de journal pour votre niveau d’abonnement, et mettre en place un service d’exportation des données de journal afin de les envoyer à un service externe d’analyse de journaux. Vous pouvez utiliser l’une de nos solutions de diffusion de journaux dans Auth0 Marketplace. Les équipes de développement peuvent utiliser les fichiers journaux pour le dépannage et la détection d’erreurs intermittentes qui peuvent être difficiles à repérer au moyen de tests d’AQ. Les équipes de sécurité voudront probablement avoir accès aux données de journal au cas où des données d’informatique judiciaire seraient un jour nécessaires. L’exportation des fichiers journaux vers des services offrant des analyses complètes peut vous aider à repérer des tendances, comme les tendances d’utilisation et les déclencheurs de la .

Limites de taux et autres erreurs

Auth0 fournit un code d’erreur unique pour les erreurs signalées lorsque la limite de taux est dépassée. Vous devriez mettre en place une analyse automatique des journaux afin de repérer les erreurs liées aux limites de taux, pour pouvoir traiter de façon proactive l’activité qui atteint ces limites avant qu’elle ne cause trop de problèmes à vos utilisateurs. Auth0 publie aussi des codes d’erreur pour d’autres types d’erreurs, et il est également utile d’analyser les journaux pour repérer les erreurs d’authentification ainsi que les erreurs provenant des appels à l’API d’Auth0 (les codes d’erreur de la Management API sont affichés sous chaque appel dans le Management API Explorer).

Bonne pratique

Appeler la Management API pour récupérer les informations de profil d’un utilisateur à partir d’une Rule est une cause fréquente d’erreurs de limite de taux, car ces appels d’API peuvent s’exécuter à chaque connexion, ainsi que lors des vérifications périodiques de session.

Surveillance

Assurez-vous de mettre en place une surveillance proactive du service Auth0, ainsi qu’une surveillance de bout en bout de l’authentification dans votre application. Vous devriez mettre en place des mécanismes de surveillance de vos implémentations Auth0, afin que votre équipe de soutien ou d’exploitation reçoive rapidement l’information nécessaire pour gérer les interruptions de service de façon proactive. Auth0 fournit des points de terminaison de surveillance qui peuvent être intégrés à votre infrastructure de surveillance. Ces points de terminaison sont conçus pour fournir une réponse adaptée aux services de surveillance. Notez toutefois qu’ils ne fournissent des données que sur Auth0. Pour une surveillance complète de bout en bout, essentielle pour vérifier si les utilisateurs peuvent se connecter, nous vous recommandons de mettre en place une surveillance des transactions synthétiques. Cela vous donnera une granularité accrue et vous permettra de détecter les interruptions non liées à Auth0 ainsi que les baisses de performance, afin de réagir de façon plus proactive.

Bonne pratique

Vous devriez prévoir l’envoi de transactions de connexion synthétiques afin de faciliter la surveillance de bout en bout de l’authentification. Vous pouvez le faire au moyen d’une application simple qui utilise le Resource Owner Password Grant en combinaison avec un utilisateur de test sans privilèges, et n’oubliez pas non plus les politiques de limitation du débit d’Auth0.

Notifications d’Auth0

Vous devez vous assurer que votre équipe surveille tous les canaux de communication suivants d’Auth0 afin de rester au fait des annonces et des changements importants. Auth0 envoie plusieurs types de notifications que vous devriez surveiller, car elles contiennent des renseignements importants qui pourraient avoir une incidence sur vos locataires et votre projet.
Auth0 envoie les notifications de sécurité proactives et les autres annonces opérationnelles aux administrateurs de l’Auth0 Dashboard. Vous devez vous assurer que les personnes qui doivent recevoir ces messages sont des administrateurs de l’Auth0 Dashboard.

Notifications dans l’Auth0 Dashboard

De temps à autre, Auth0 peut envoyer une annonce importante concernant votre locataire. Ces annonces au sujet de votre service seront envoyées dans votre Auth0 Dashboard et, selon leur gravité, par courriel aux administrateurs enregistrés de l’Auth0 Dashboard. Vous devriez prendre l’habitude de vous connecter régulièrement à l’Auth0 Dashboard et de vérifier l’icône en forme de cloche en haut de la page pour repérer tout avis important. De plus, vous devriez consulter rapidement les courriels d’Auth0, car ils peuvent contenir des renseignements importants sur des changements ou des mesures que vous devez prendre.

Bulletins de sécurité d’Auth0

Auth0 effectue régulièrement divers tests de sécurité et, si des problèmes sont détectés, identifie et avise de manière proactive les clients qui doivent apporter des modifications liées à la sécurité. Toutefois, en raison de la nature extensible du produit Auth0, il se peut qu’Auth0 ne puisse pas identifier tous les clients concernés. Vous devriez donc consulter régulièrement les bulletins de sécurité d’Auth0. Assurez-vous qu’une personne-ressource en sécurité pour votre organisation est indiquée dans le Support Center.

Bonne pratique

Il est recommandé de consulter périodiquement la page des Security Bulletins d’Auth0 et de prendre les mesures recommandées si vous êtes concerné par l’un de ces bulletins de sécurité.

Journal des modifications

Auth0 fournit de l’information sur les changements apportés au service dans le journal des modifications d’Auth0. Vous devriez prendre l’habitude de consulter régulièrement les journaux des modifications d’Auth0 afin de rester au fait des changements. Les équipes de support qui analysent un problème peuvent trouver utile de consulter le journal des modifications pour déterminer si des changements récents pourraient être en cause, surtout s’il s’agit de changements avec rupture de compatibilité. Les équipes de développement voudront aussi consulter les journaux des modifications pour repérer de nouvelles fonctionnalités qui pourraient être utiles. De plus, vous devriez consulter périodiquement la page des migrations d’Auth0 pour vous tenir au courant des dépréciations à venir qui pourraient obliger votre équipe à apporter des changements.

Déploiement automatisé et contrôle de version

Bien que ce ne soit pas obligatoire, il est fortement recommandé de mettre en place une automatisation du déploiement. Si vous avez automatisé le déploiement et le rétablissement des changements dans les environnements de développement, de test et de production, vous pourrez réagir plus efficacement si vous devez apporter des modifications après le lancement. En plus d’adopter de bonnes pratiques de gestion des changements et d’AQ, les clients qui réussissent intègrent aussi la gestion des composants Auth0 à un processus de déploiement automatisé. Comme indiqué dans la section Architecture sous prise en charge du SDLC, vous devez veiller à configurer des locataires Auth0 distincts pour les environnements de développement, de test et de production, et à ce que cette configuration soit presque identique d’un locataire à l’autre. L’automatisation du déploiement aide à garantir cette cohérence : chaque locataire d’environnement est configuré de la même façon, ce qui réduit le risque de bogues causés par des configurations divergentes entre les environnements.

Pratique exemplaire

Quelle que soit la façon dont vous configurez l’automatisation du déploiement, nous vous recommandons d’effectuer des tests unitaires de vos Rules, scripts de base de données personnalisés et Hooks avant le déploiement, puis d’exécuter également des tests d’intégration sur votre locataire après le déploiement. Pour en savoir plus à ce sujet, consultez les recommandations sur l’assurance qualité.
Auth0 prend en charge plusieurs approches d’automatisation du déploiement, et celles-ci peuvent être utilisées ensemble au besoin :
  • L’outil Auth0 Deploy CLI fournit un script facile à utiliser qui peut vous aider à l’intégrer à votre pipeline existant d’intégration continue et de déploiement continu (CI/CD).
  • Si vous ne pouvez pas intégrer directement un pipeline CI/CD, ou si pour une raison quelconque vous n’en avez pas, les Source Control Extensions d’Auth0 peuvent fournir un processus d’automatisation de base facile à configurer et nécessitant très peu de maintenance.
Notez que l’outil Deploy CLI et les extensions de contrôle de code source peuvent tous deux entraîner des changements destructifs : les changements manuels effectués directement dans l’Auth0 Dashboard entre des déploiements automatisés pourraient être perdus! Pour cette raison, si l’un ou l’autre est utilisé, tous les changements doivent être déployés à partir du sous-système de contrôle de code source référencé par l’outillage et non effectués manuellement.
Chaque environnement peut aussi nécessiter une configuration qui lui est propre — les et les de l’application seront différents d’un locataire Auth0 à l’autre, par exemple — vous aurez donc besoin d’un moyen d’y faire référence dynamiquement plutôt que d’utiliser des valeurs codées en dur. Auth0 prend en charge la gestion des renseignements de configuration propres à l’environnement au moyen de l’une des deux approches suivantes :

Variables propres au locataire

Auth0 vous permet de configurer des variables accessibles dans votre extensibilité personnalisée; elles peuvent être considérées comme des variables d’environnement pour votre locataire Auth0. Plutôt que d’encoder en dur des références qui changent lorsque vous déplacez du code entre des environnements de développement, de test et de production, vous pouvez utiliser un nom de variable configuré dans le locataire et utilisé par le code d’extensibilité personnalisé. Il devient ainsi plus facile d’utiliser le même code personnalisé, sans modification, dans différents locataires, puisque le code peut faire référence à des variables qui seront renseignées avec des valeurs propres au locataire au moment de l’exécution :
  • Pour utiliser des variables dans les Actions, consultez Write Your First Action pour apprendre à configurer des secrets dans l’éditeur
  • Pour utiliser des variables dans les Rules, voyez comment configurer des valeurs
  • Pour utiliser des variables dans les Hooks, voyez comment configurer des secrets dans l’éditeur
  • Pour utiliser des variables dans les scripts de base de données personnalisés, consultez les paramètres de configuration

Bonne pratique

Il est recommandé d’utiliser des variables pour stocker des valeurs propres au locataire ainsi que tous les secrets sensibles qui ne devraient pas être exposés dans votre code personnalisé. Si votre code personnalisé est déployé dans GitHub/GitLab/Bitbucket/VSTS, l’utilisation d’une variable propre au locataire permet d’éviter l’exposition de valeurs sensibles dans votre dépôt.

Sauvegarde / Restauration

Vous devriez disposer d’un plan et d’un mécanisme pour prendre en charge toute fonctionnalité de sauvegarde et de restauration nécessaire à votre projet. Cela peut se faire au moyen du Management API d’Auth0 pour les données, ainsi que des capacités de déploiement automatisé décrites dans la section sur le déploiement automatisé pour la configuration d’Auth0. Comme indiqué dans la stratégie de restauration des données du locataire d’Auth0 et la stratégie de transfert des données, Auth0 ne restaure pas les locataires supprimés et ne déplace pas les données entre locataires. Auth0 fournit le Management API d’Auth0 afin d’offrir aux clients une capacité entièrement flexible de sauvegarder, restaurer et déplacer des données selon leurs besoins. Les clients peuvent écrire des scripts pour extraire des données d’Auth0 à des fins de sauvegarde et, de la même façon, écrire des scripts à utiliser avec la capacité de déploiement automatisé pour restaurer tout aspect de leur configuration Auth0.

Versions à jour

Vous devriez revérifier que toutes les technologies de la pile de votre application, ainsi que les versions des navigateurs utilisés par vos utilisateurs, sont bien à jour, car cela peut avoir une incidence sur la capacité d’Auth0 à fournir du support si des problèmes surviennent.

Plan de rotation des certificats

Les certificats peuvent être utilisés dans les déploiements d’identité. Pour éviter qu’une expiration de certificat ne vous prenne au dépourvu, vous devriez avoir une liste des certificats de votre environnement, avec leurs dates d’expiration, la façon dont vous serez avisé à l’approche de l’expiration et le déroulement du processus de rotation des certificats.

Connexions SAML

Pour les connexions , vous obtenez un certificat auprès de l’ et vous le téléversez dans la connexion SAML de cet IdP dans votre Auth0 Dashboard. Lorsqu’un de ces certificats est sur le point d’expirer, Auth0 enverra un courriel aux administrateurs de l’Auth0 Dashboard pour les avertir de l’expiration prochaine. Vous pouvez obtenir le nouveau certificat et le téléverser à l’aide de l’écran de configuration de la connexion.

Connexions WS-Fed

Pour les connexions , si vous les configurez en indiquant une URL ADFS, toute modification sera prise en compte lors de la mise à jour quotidienne. Vous pouvez déclencher une mise à jour manuellement en accédant à la page de configuration de la connexion dans l’Auth0 Dashboard et en enregistrant. Si un certificat est modifié chez l’IdP distant, Auth0 peut être mis à jour par ces mécanismes ou en téléversant un nouveau fichier de métadonnées dans le même écran de configuration de la connexion.

Plan de reprise après sinistre / plan de continuité des activités en place

Bien que ce ne soit pas une exigence absolue avant le lancement, il est utile d’avoir en place un plan de reprise après sinistre afin d’assurer la continuité des activités en cas de différents types de sinistres, notamment des pannes de système et des catastrophes naturelles touchant une région où se trouve du personnel essentiel.

Processus documentés

Un autre point, sans être une exigence absolue, est aussi recommandé : veiller à ce que tous les processus liés à Auth0 soient documentés. Cela peut inclure les éléments suivants :
  • Gestion des changements de configuration
  • Déploiement des nouvelles modifications et de tout mécanisme de déploiement automatique utilisé, ainsi que la manière de rétablir une version antérieure en cas de problème
  • Processus de rotation des certificats, s’il y a lieu
  • Ajout ou suppression de nouveaux fournisseurs d’identité, s’il y a lieu
  • Modifications de la structure du profil utilisateur dans Auth0 ou dans les répertoires à partir desquels Auth0 extrait les données
  • Ajout ou suppression d’applications ou d’API
  • Collecte et exportation des journaux
  • Processus de sauvegarde et de restauration que vous avez mis en place
  • Gestion des utilisateurs (mot de passe oublié, téléphone perdu)
  • Analyse de la cause profonde après un incident

Guide de planification du projet

Nous offrons un guide de planification au format PDF que vous pouvez télécharger et consulter pour obtenir plus de détails sur les stratégies que nous recommandons. Guide de planification du projet IAM B2C