Entra ID (anciennement Azure AD) est une solution de gestion des identités et des accès. Celle-ci permet d’administrer le cycle de vie des différentes identités, allant d’utilisateurs à des appareils en passant par des applications. Contrairement à Microsoft Active Directory, Entra ID étend ses capacités d’authentification et d’autorisation au-delà du réseau de l’entreprise pour couvrir les applications SaaS, les workloads on-premises et Cloud utilisant des appareils appartenant à l’entreprise ou BYOD. Ces nouvelles fonctionnalités et connexions sont obtenues grâce à des protocoles basés sur le web comme SAML et une structure d’identité simplifiée (forêt AD vs locataire Entra ID).
Dans cet article, nous mettrons en lumière le défi de la cyber-résilience d’Entra ID, expliquerons pourquoi les fonctionnalités natives sont des solutions incomplètes et présenterons le résultat d’un PoC mené sur un outil open-source, Microsoft 365 DSC, pour sauvegarder et récupérer les données d’Entra ID.
La résilience cyber dans les services Cloud managés
Avec Entra ID, la stratégie de gestion des répertoires est conforme au paradigme de l’informatique dématérialisée. Cela signifie que les différentes couches de réseau, de stockage, de calcul, de système d’exploitation et d’application sont gérées par Microsoft, ce qui permet au client de se concentrer uniquement sur ses données d’identité.
Cette différence fondamentale a un impact sur la résilience du service. En effet, la création de snapshots pour sauvegarder l’intégralité du système, qui est une pratique courante sur l’Active Directory (AD), n’est pas native sur un service managé tel qu’Entra ID. Ainsi, pour faire face à un scénario de reprise après sinistre lié à des activités malveillantes, nous ne pouvons compter que sur les fonctionnalités natives de Microsoft : le modèle de cycle de vie de l’identité, le modèle d’administration RBAC et les capacités d’importation/exportation.
Le modèle incomplet de soft deletion
Pour garantir la résilience, les services Cloud utilisent largement un mécanisme de soft delete, ou suppression logique. Son objectif principal est de pouvoir récupérer les données en cas de suppression accidentelle. Par exemple, dans le coffre-fort d’Azure Recovery Service, la suppression logique est la dernière mesure de protection en cas de suppression intentionnelle ou non intentionnelle du coffre-fort. Combiné aux paramètres d’immuabilité, le coffre-fort ne peut pas être effacé, quelles que soient les autorisations de l’administrateur.
Dans Entra ID, le concept de suppression logique existe mais est insuffisant pour assurer la résilience des données pour deux raisons. D’une part, il n’y a pas de distinction de rôle entre la suppression logique et la suppression définitive, ni de rôle de récupération, c’est-à-dire que les autorisations requises pour supprimer un objet sont suffisantes pour permettre une suppression permanente. D’autre part, le cycle de vie des objets dans Entra ID (créer, gérer, supprimer) est régi par le même rôle :
- Le rôle d’administrateur utilisateurs permet de créer et de supprimer un utilisateur.
- Le rôle d’administrateur applicatif en nuage permet d’enregistrer une application, de configurer tous les aspects de l’application et de supprimer définitivement l’application.
- Le rôle d’administrateur Cloud Device permet d’ajouter un appareil, d’en configurer tous les aspects et de le désenregistrer.
L’impact d’une suppression sur Entra ID
La conception actuelle d’Entra ID rend les rôles d’administrateur utilisateurs, d’authentification privilégiée, d’application (on-premises ou Cloud), Intune et Windows 365 d’autant plus critiques, car leur compromission peut entraîner la perte permanente des données d’identité. L’impact d’une telle suppression peut être une perte d’accès aux applications et aux données, une perte de permissions et une incapacité à administrer.
Bien que la suppression des utilisateurs hybrides synchronisés avec un AD on-premises soit réversible, des informations telles que l’attribution de rôles seront perdues, ce qui menace le modèle de droits et d’accès. Ce n’est pas le cas pour les identités dans le Cloud, qui font généralement partie du plan de contrôle. Dans le cadre du modèle d’accès de l’entreprise, le plan de contrôle comprend les accès les plus sensibles, ce qui peut entraîner la compromission globale d’un système d’information.
Dans un scénario de reprise après sinistre, certains actifs sont plus critiques que d’autres et doivent être sauvegardés en priorité. Il s’agit notamment des éléments suivants :
- Utilisateurs du Plan de contrôle, groupes and roles assignés
- Applications d’entreprise (service principal) avec des autorisations critiques sur Azure ou Microsoft 365
- Postes de travail
Comparaison des méthodes de sauvegarde open-source
Afin de réduire la probabilité d’un risque de perte de données Entra ID à des fins malveillantes, la mise en place d’une solution de sauvegarde semble indispensable, au moins pour le plan de contrôle afin de garder le contrôle sur le système d’Information et le reconstruire. Nous avons donc analysé 3 méthodes open-source permettant d’assurer la sauvegarde des données :
- Microsoft Graph PowerShell : une bibliothèque PowerShell pour les API Microsoft Graph. Vous pouvez créer vos propres scripts pour exporter et importer les attributs des objets Entra ID qui correspondent aux besoins de votre organisation.
- Microsoft Entra Exporter : un module PowerShell qui exporte une copie locale de certains attributs Entra ID (utilisateurs, applications, applications d’entreprise, rôles, etc.) dans un fichier JSON.
- Microsoft 365 Desired State Configuration (DSC) : un module PowerShell pour la configuration déclarative, le déploiement et la gestion des services Microsoft 365.
Sauvegarde des objets Entra ID avec Microsoft 365 DSC
Dans cette partie, nous allons expliquer comment nous avons testé la solution open source Microsoft 365 DSC et partager les résultats et conclusions obtenus.
Notre PoC
Microsoft 365 DSC permet de gérer la configuration et l’état des services Microsoft 365 selon une approche déclarative. En définissant l’état souhaité plutôt que les étapes spécifiques, il simplifie la gestion de configurations cloud complexes et assure la cohérence de l’environnement.
Dans le cadre d’un PoC, la population test déployée dans notre tenant est la suivante :
- 30 utilisateurs Cloud Only (générés aléatoirement par Microsoft lors de la création du tenant de test)
- 10 groupes de sécurité (attribués aléatoirement aux utilisateurs)
L’objectif de ce PoC est d’identifier les avantages et les limites de la solution à travers une série de cas d’usage testés et documentés :
|
Utilisateurs |
||
|
Cas d’usage |
Résultats |
|
|
Que se passe-t-il si l’on supprime un utilisateur puis que l’on restaure une sauvegarde ? |
L’utilisateur revient-il avec toutes ses données ? |
Tous les attributs liés aux utilisateurs supprimés ne sont pas restaurés. Toutefois, leur mot de passe est remplacé par un mot de passe par défaut. En cas d’incohérence, une erreur non-bloquante est générée dans le script, empêchant l’attribution d’attributs pointant vers des objets inexistants. |
|
Que se passe-t-il si un utilisateur est désactivé alors qu’il est actif dans la sauvegarde ? |
Est-il réactivé? |
Il n’est pas possible de connaître l’état (actif ou désactivé) d’un utilisateur depuis la sauvegarde.
“Présent” : l’utilisateur est considéré comme actif et sera déployé. |
|
Que se passe-t-il si un utilisateur est actif mais qu’il est désactivé dans la sauvegarde ? |
Est-il désactivé ? |
|
|
Que se passe-t-il si un utilisateur est ajouté, mais non présent dans la sauvegarde ? |
Est-il supprimé ? Ses données sont-elles conservées ? |
Aucun impact observé sur le nouvel utilisateur. |
|
Que se passe-t-il si on effectue une sauvegarde sans modifier l’utilisateur ? |
Si rien ne change, que se passe-t-il ? Si seul un attribut (ex. un groupe) est supprimé, que se passe-t-il ? Si un attribut est ajouté ? Si un attribut est modifié (mot de passe) ? Si un groupe auquel l’utilisateur appartenait est supprimé ? Qu’en est-il des licences assignées si la sauvegarde est faite avant modification ? Que se passe-t-il si le rôle de l’utilisateur est modifié avant la sauvegarde ? |
Le nom d’utilisateur sert à associer les attributs : s’il change, l’utilisateur ne peut plus être retrouvé dans la sauvegarde (sauf si modifié aussi dans celle-ci). Les attributs présents dans la sauvegarde écrasent ceux existants. Le reste sera inchangé. Ainsi, tout attribut non inclus dans la sauvegarde reste inchangé. |
|
Groupes |
||
|
Cas d’usage |
Résultats |
|
|
Que se passe-t-il si je supprime un groupe puis restaure une sauvegarde ? |
Le groupe est-il restauré avec toutes ses données ? Les membres sont-ils réintégrés ? La sauvegarde contient-elle les liens membres/groupe ? Tous les groupes sont-ils sauvegardés ? Les droits internes au groupe sont-ils conservés ? |
Seuls les groupes de sécurité et les groupes Microsoft 365 avec le bon label de confidentialité sont sauvegardés. La sauvegarde contient les membres et le propriétaire, mais pas les droits internes au groupe. Il faut refaire la sauvegarde car le groupe recréé n’aura pas le même ID. La sauvegarde considère alors que le groupe n’existe pas. |
|
Que se passe-t-il si je sauvegarde un groupe déjà existant mais dont certains attributs ont été modifiés ? |
Que se passe-t-il si le nom a changé ? Si un utilisateur a quitté le groupe après la sauvegarde ? Si de nouveaux utilisateurs ont été ajoutés ? |
La sauvegarde écrase les anciens attributs à l’exception du nom. |
|
Que se passe-t-il si un groupe existe dans le tenant mais pas dans la sauvegarde ? |
Est-il supprimé ou impacté lors de la restauration ? |
Aucun impact observé, hormis pour les informations définies dans le fichier de configuration. |
Le processus a nécessité la configuration d’un compte de service avec les autorisations appropriées (User.ReadWrite.All, Group.ReadWrite.All) sur Entra ID afin d’interagir avec l’API Microsoft Graph pour l’export et l’import des données.
Ces autorisations ont permis au compte de service de récupérer les configurations et données nécessaires depuis Entra ID et de les réimporter.
RÉSULTATS DU POC MICROSOFT 365 DSC
À l’issue des tests, nous avons pu rassembler des informations sur les atouts et les limites de la solution.
Points positifs :
- Sélection granulaire des configurations : La solution permet de cibler précisément les configurations à sauvegarder.
- Restauration sans suppression : Les utilisateurs et groupes actuels sont conservés lors de la restauration, évitant les suppressions accidentelles.
- Écrasement des attributs obsolètes : Les attributs sauvegardés remplacent les anciens.
- Format de stockage des données : Les données sont enregistrées en JSON, ce qui facilite leur manipulation.
- Automatisation possible : Une fois les outils installés, la solution est facilement automatisable.
- Supervision et alertes : Microsoft 365 DSC permet de surveiller la cohérence des données et de déclencher des alertes en cas de changements suspects.
- Gestion des versions de snapshots : Il est possible de gérer plusieurs versions de snapshots de manière simple.
- Journalisation détaillée : La solution permet de générer des journaux très détaillés, facilitant l’audit et le suivi.
Limites identifiées :
- Données incomplètes dans la sauvegarde : Tous les attributs ne sont pas capturés, entraînant une possible perte d’informations.
- Limite de taille de sauvegarde : La taille est limitée à 11 Mo, ce qui peut être insuffisant pour des environnements plus vastes.
- État de désactivation non enregistré : Les statuts de désactivation ne sont pas sauvegardés, pouvant entraîner la réactivation d’utilisateurs désactivés.
- Données et identifiants non chiffrés : Les fichiers de sauvegarde contiennent des données sensibles non chiffrées.
- Perte des IDs objets : Lors de l’import, les IDs sont perdus, ce qui peut générer des doublons lors d’imports ultérieurs.
- Service Principal privilégié : Le service principal utilisé possède des droits étendus, ce qui peut poser des risques de sécurité si mal géré
Il est important de noter que cet outil ne permet pas véritablement une “restauration” : il est possible de recréer les objets, mais pas de restaurer les services associés. En effet, les liens entre les nouveaux objets ID et les applications ne sont pas restaurables, ce qui constitue une limitation propre à Entra ID.
NOTRE AVIS SUR MICROSOFT 365 DSC
Microsoft 365 DSC est un excellent outil pour des usages de base et pour la documentation, grâce à sa simplicité de prise en main et de déploiement dans des environnements de test. Il est également efficace comme outil de supervision grâce à sa gestion de version et ses journaux détaillés.
Cependant, il n’est pas adapté aux environnements de grande taille, en raison de ses limitations en termes de scalabilité, d’expérience utilisateur et de sécurité (notamment pour les configurations et les identifiants). Il peut également générer des incohérences ou des duplications, car les IDs objets, qui peuvent être référencés ailleurs, sont irrécupérables.
Des solutions complémentaires peuvent s’avérer nécessaires, comme des scripts pour le traitement des fichiers de configuration et pour garantir la cohérence des modifications, ainsi que des processus clairs de chiffrement et de sauvegarde.
Nous recommandons donc de toujours évaluer précisément les besoins, de planifier les développements complémentaires nécessaires, et d’utiliser principalement la solution à des fins de supervision et de tests.
Compte tenu des limites des outils open source de Microsoft, il peut être pertinent d’examiner les offres de fournisseurs tiers, tels que Semperis ou Quest, spécialistes du domaine. Ces alternatives pourraient répondre aux défis de scalabilité, de fiabilité et de sécurité, et offrir des options mieux adaptées à des environnements complexes. Il est important de rester ouvert à ces solutions et de les évaluer selon les besoins spécifiques de votre organisation.
