Revue de sécurité informatique indépendante
Pour bien des organisations, l’identité infonuagique dépend encore d’une infrastructure sur site. La revue considère les règles de synchronisation d’Azure AD Connect, les contrôleurs de domaine et les serveurs ou machines virtuelles qui les hébergent comme faisant partie du parcours de connexion - pas comme le problème de quelqu’un d’autre.
Le filtrage, le flux d’attributs et la méthode d’authentification d’Azure AD Connect déterminent quels comptes sur site atteignent Microsoft 365 et comment ils prouvent leur identité. Une installation par défaut faite il y a des années prend encore cette décision aujourd’hui.
Confirmer quelles unités organisationnelles, quels groupes et quels attributs sont réellement dans le périmètre, et si une ancienne règle de filtrage exclut ou expose silencieusement des comptes qu’elle ne devrait pas.
Distinguer la synchronisation de hachage de mot de passe, l’authentification directe (pass-through) et la fédération, car chacune change ce qui arrive à la connexion si un composant sur site tombe en panne.
Examiner l’écriture inversée des mots de passe et la direction du flux d’attributs pour qu’un changement fait dans un sens n’écrase pas silencieusement une valeur voulue dans l’autre.
Les contrôleurs de domaine et le serveur Azure AD Connect lui-même se trouvent en amont de chaque connexion hybride. Si cette couche est fragile, l’identité infonuagique bâtie par-dessus l’est aussi - peu importe la qualité de la configuration de l’accès conditionnel.
Vérifier le niveau de correctifs, l’état de la réplication et la synchronisation de l’heure, car des erreurs d’authentification en amont peuvent apparaître comme un problème de connexion à Microsoft 365.
Confirmer si un seul serveur Azure AD Connect constitue l’unique voie de synchronisation et d’écriture inversée, et ce qui arrive aux nouvelles connexions pendant qu’il est hors service.
Vérifier si un serveur de préproduction existe et est réellement testé, plutôt qu’installé une fois et jamais promu ni validé.
Lorsque les contrôleurs de domaine et le serveur Azure AD Connect fonctionnent comme machines virtuelles, l’état de l’hyperviseur, la couverture de sauvegarde et le temps de récupération font partie de la discussion sur l’identité - pas d’un sujet d’infrastructure distinct.
Identifier sur quel hôte ou grappe fonctionnent les machines virtuelles critiques pour l’identité, et si cet hôte présente lui-même un point unique de défaillance.
Confirmer que les contrôleurs de domaine et le serveur Azure AD Connect sont réellement inclus dans le périmètre de sauvegarde, plutôt que présumés couverts par une tâche générale de sauvegarde de serveurs.
Comparer le temps réaliste de restauration d’un contrôleur de domaine ou d’un serveur de synchronisation au temps pendant lequel l’organisation peut fonctionner sans nouvelles connexions à Microsoft 365.
Un constat dans ce domaine peut mener à une correction de règle de synchronisation, à une remédiation touchant un contrôleur de domaine ou un hyperviseur, ou à une réflexion plus large sur le passage à une identité infonuagique seule. Chacune de ces voies a un responsable et un échéancier différents.
Distinguer un changement de configuration dans Azure AD Connect d’un changement de serveur, d’hyperviseur ou de sauvegarde qui exige sa propre fenêtre de changement.
Lorsque la dépendance à l’infrastructure sur site constitue elle-même le constat, documenter ce qu’exigerait un passage vers une identité infonuagique seule, et ce que cela éliminerait.
Coordonner la remédiation de l’infrastructure hybride avec tout changement d’accès conditionnel ou de rôle privilégié déjà planifié, car les deux touchent le même parcours de connexion.
Prochaine étape
Commencez avec le déclencheur, la décision et les limites connues. N’envoyez aucun mot de passe, code de récupération ni export du locataire.