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 : 

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. 

Cet article Résilience Entra ID est apparu en premier sur RiskInsight.

Dans ce deuxième article, nous analyserons des scénarios d’attaque pratiques qui menacent le Control Plane, et fournirons des recommandations concrètes pour atténuer ces risques. Plus précisément, nous explorerons trois scénarios d’attaque courants qui menacent significativement le Control Plane : la compromission du support IT, du poste de travail de l’administrateur du Control Plane et du CI/CD. En comprenant ces vecteurs d’attaque et en mettant en œuvre des mesures de sécurité robustes, il est possible d’améliorer considérablement la résilience de son environnement cloud contre les compromissions potentielles. 

La compromission du support IT  

Prenons un scénario où le compte d’un membre du support IT est compromis. Cela peut découler d’une attaque par hameçonnage, d’une opération d’ingénierie sociale ou même d’une tentative d’usurpation d’identité. Ces comptes peuvent souvent réinitialiser des mots de passe, y compris ceux des utilisateurs ayant des privilèges très élevés, tels que l’administrateur d’application ou le Owner Azure au niveau root, obtenant ainsi un accès non autorisé à des ressources critiques, allant de l’Entra ID au cloud, en passant par les environnements sur site et les services SaaS. 

Ce type d’attaque illustre un point crucial que nous avons abordé dans le premier article : la nécessité de délimiter et d’isoler efficacement le Control Plane. Le service d’assistance, bien qu’essentiel pour les opérations quotidiennes, doit être rigoureusement séparé des fonctions administratives à haut privilège. L’absence d’une telle séparation peut permettre à un attaquant de passer d’un compte de service d’assistance compromis à un rôle d’administrateur global. 

Pour réduire ce risque, les organisations doivent mettre en œuvre une série de défenses stratégiques :  

• Dans un premier temps, isoler les comptes du Control Plane de ceux gérés par le support IT est essentiel. De cette façon, même si un compte du service d’assistance est compromis, il ne pourra pas accéder ou manipuler des comptes à haut privilège. Ainsi, la compromission d’un compte de service d’assistance ne permettrait pas d’accéder à des comptes à privilèges élevés ou de les manipuler. 
• Dans un second temps, utiliser exclusivement des comptes cloud dédiés aux tâches du Control Plane réduit la probabilité d’exploitation des systèmes hérités comme point d’entrée.  
• Finalement, associer ces comptes à une authentification multi-facteurs (MFA) résistante au phishing, à une administration Just-In-Time (JIT), à une gouvernance d’identité robuste et à des politiques d’accès conditionnel, ainsi qu’à une conformité stricte des postes de travail, crée une défense en couches qui diminue considérablement le risque d’une telle attaque. 

Ce scénario souligne l’importance de considérer chaque compte comme un vecteur de menace potentiel. Mettre en place une isolation stricte et des contrôles rigoureux permet de garantir la sécurité de votre Control Plane en cas de compromission d’un compte de niveau inférieur. 

Compromission d’un poste administrateur du Control Plane  

Considérons maintenant une situation où un attaquant parvient à compromettre le compte administrateur de l’Intune Mobile Device Manager (MDM). Avec cet accès, l’attaquant obtient le contrôle du portail d’administration d’Intune, lui permettant de manipuler le poste de travail d’un administrateur du Control Plane. Il peut déployer des configurations malveillantes, installer des portes dérobées ou se connecter directement à l’ordinateur de l’administrateur (Remote help. Cet accès transforme le poste de l’administrateur en un outil puissant pour une exploitation ultérieure, offrant à l’attaquant la capacité d’exécuter des commandes, d’exfiltrer des données sensibles et de manipuler des ressources cloud sans recourir à des techniques de piratage supplémentaires. 

Ce scénario nous rappelle un principe clé du premier article : la sécurité du cloud doit être abordée de manière holistique. Il ne s’agit pas seulement de sécuriser les identités, mais aussi de garantir que les appareils utilisés pour accéder au Control Plane sont sécurisés. Dans ce cas, le poste de l’administrateur du Control Plane devient un atout critique qui, s’il est compromis, pourrait compromettre les défenses cloud les plus sophistiquées. 

Compromission du CI/CD 

Les environnements Cloud reposant fortement sur l’automatisation, les pipelines CI/CD pour la gestion de l’infrastructure deviennent des cibles privilégiées pour les attaquants. Imaginons un scénario où un attaquant parvient à accéder au compte d’un ingénieur DevOps par le biais d’une attaque de phishing ou d’un vol d’identifiants. Avec cet accès, il introduit un changement malveillant d’Infrastructure as Code (IaC) dans un dépôt Git, sachant que cela déclenchera un pipeline Azure automatisé. Le pipeline valide, planifie et déploie l’infrastructure sur Azure, entraînant la destruction ou l’altération de ressources clés d’Azure, c’est-à-dire les fondations de la Landing Zone. De plus, l’attaquant modifie la configuration YAML du pipeline Azure. Ce faisant, il provoque la fuite d’un secret Service Principal dans les journaux ou la console de débogage, qui est ensuite utilisé pour effectuer des appels non autorisés à l’API Graph. En exploitant cette identité sur-privilégiée, l’attaquant peut escalader ses privilèges, compromettant ainsi les identités Entra ID ou les comptes Office 365. 

Les runners jouent également un rôle crucial dans le pipeline CI/CD. Ces agents sont responsables de l’exécution des tâches dans le pipeline et peuvent être hébergés et maintenus par le fournisseur cloud ou sur site. Comme pour tout serveur, leur compromission peut être utilisée comme point de pivot pour rebondir vers la Landing Zone (par exemple : vol de token) ou d’autres services associés. 

Ce scénario illustre l’interconnexion de la sécurité du cloud. Le pipeline CI/CD, souvent perçu comme une fonction de back-office, est en réalité profondément intégré au Control Plane. Sa compromission peut entraîner des conséquences dévastatrices et généralisées pour les fondations mêmes de vos opérations cloud. 

Pour se protéger contre une telle menace, il est crucial d’isoler le pipeline du Control Plane, dont le but est de construire la Landing Zone, des pipelines de projet. Ensuite, il convient d’appliquer le principe du moindre privilège, en veillant à ce que les comptes et les runners au sein du pipeline n’aient que les permissions nécessaires pour accomplir leurs tâches. Par exemple, pour limiter les permissions des runners, nous pouvons utiliser l’identité fédérée et demander des token OpenID Connect (OIDC), qui fournissent un accès limité et temporaire aux services cloud comme Azure. De plus, l’adoption de pratiques de sécurité automatisées telles que Configuration as Code (CaC) ou Policy as Code (PaC) peut aider à réduire les erreurs humaines et à garantir une sécurité cohérente dans vos déploiements. 

En matière de sécurité cloud, chaque processus et chaque outil doit être considéré sous l’angle du risque. Le pipeline CI/CD ne fait pas exception. En sécurisant ce composant critique, vous protégez non seulement votre Control Plane, mais vous assurez également la stabilité et la sécurité de l’ensemble de votre infrastructure cloud. Cette approche holistique de la sécurité du cloud est ce qui permettra finalement à vos opérations de fonctionner correctement, même face à des attaques sophistiquées. 

Synthèse

Dans cet article, nous avons examiné trois scénarios d’attaque qui menacent la sécurité du Control Plane dans les environnements cloud : la compromission du support IT, la compromission du poste de travail de l’administrateur du Control Plane et la compromission du pipeline CI/CD. 

Chacun de ces scénarios met en évidence l’importance d’une approche de sécurité à plusieurs niveaux, incluant des mesures techniques et organisationnelles. Nous proposons une stratégie en quatre étapes pour concevoir votre Control Plane et le sécuriser contre les attaques potentielles : 

• Étape 1 : Définir ce qui est systémique pour votre infrastructure : identifier les composants et comptes critiques au sein de votre Control Plane qui, s’ils sont compromis, pourraient entraîner une perturbation globale. 
• Étape 2 : Evaluer votre risque actuel avec un audit de sécurité : réaliser des audits de sécurité réguliers pour évaluer l’état actuel de la sécurité de votre Control Plane. Cela vous aidera à identifier les vulnérabilités et à prioriser les efforts de remédiation. 
• Étape 3 : Définir une feuille de route pour isoler et sécuriser les actifs les plus à risque : sur la base des résultats de votre audit, élaborer une feuille de route claire pour sécuriser les actifs les plus critiques. Cela devrait inclure des échéanciers, l’allocation des ressources et des actions spécifiques pour atténuer les risques identifiés. 
• Étape 4 : Se préparer aux scénarios de suppression du cloud : envisager les pires scénarios où des sections entières de votre infrastructure cloud pourraient être compromises ou désactivées. Élaborer des plans de contingence et s’assurer que les processus de sauvegarde et de reprise après sinistre sont en place. 

En suivant ces recommandations, vous pouvez construire une défense robuste contre les menaces potentielles à votre Control Plane, garantissant que votre environnement cloud reste sécurisé et résilient. 

Merci à Louis CLAVERO pour sa contribution à cet article.

Cet article Enterprise Access Model (2/2) : Quelles solutions pour sécuriser un Control Plane ?  est apparu en premier sur RiskInsight.

Aujourd’hui, la plupart des entreprises utilisent le Cloud public pour héberger de nombreuses applications, répondant à tout type de besoin allant du commercial au fonctionnel. Bien que cela apporte des avantages, le Cloud introduit également de nouveaux paradigmes, qui doivent être clairement compris afin d’être sécurisés. 

Historiquement, les entreprises s’appuient sur un modèle à 3 tiers pour sécuriser les environnements Active Directory. Ce modèle segmente le réseau en trois niveaux distincts : le tiers 0 pour les systèmes et les données les plus sensibles, le tiers 1 pour l’administration des serveurs et le tiers 2 pour les postes de travail et les terminaux utilisateurs. Bien que ce modèle se soit avéré efficace dans les environnements on-premise, le passage à des infrastructures basées sur le Cloud nécessite une réévaluation de son applicabilité. 

Ce premier article se concentre sur une tendance récente et inquiétante : la compromission globale d’Entra ID, résultant de la compromission d’un compte du support. Une telle attaque peut avoir de graves répercussions, aux impacts finalement plus larges qu’une compromission d’un administrateur de domaine AD. Nous explorerons les mécanismes à l’origine de ces attaques, leurs implications et, surtout comment nous devrions nous protéger contre ce type d’élévation de privilèges et mettre en œuvre un modèle d’administration adapté au Cloud et sécurisé. 

Comprendre Entra ID, Active Directory, et les permissions Azure  

Comme le montre la figure 1, l’Active Directory et Entra ID (anciennement Azure Active Directory) sont deux services d’identité avec des propriétés structurelles et des protocoles IAM différents. Alors qu’Entra ID se concentre sur la gestion des identités et des accès dans les environnements Cloud et on-premise, en fournissant l’authentification et la gestion des utilisateurs, les permissions Azure s’attèlent à la gestion plus large de l’infrastructure et des services Cloud. Comprendre les distinctions et les interconnexions entre ces outils est essentiel pour maintenir une sécurité robuste et un contrôle d’accès efficace dans les environnements actuels d’entreprise. 

Figure 1: Différences clés entre Active Directory et Entra ID. 

Entre Active Directory, Entra ID et Azure, chacun gère son propre modèle de permissions : 

• Active Directory utilise un modèle de permission unifié pour tous ses objets, des utilisateurs aux machines. 
• Entra ID utilise le contrôle d’accès basé sur des rôles (RBAC : Role-Based Access Control) pour gérer les objets de son tenant (par exemple : les utilisateurs, les appareils, les applications). 
• Azure Resource Manager (RM) utilise le RBAC pour gérer les ressources Azure 

Cependant, il existe un pont entre Entra ID et Azure RM grâce à la relation unique entre un tenant Entra ID et une organisation Azure : l’utilisateur Global Administrator d’Entra ID se voit attribuer par défaut le rôle User Access Administrator dans Azure. Par conséquent, il peut dès lors s’attribuer n’importe quelle permission sur le scope Azure.  

Bien qu’il existe un lien entre Azure et Entra ID, il est important de garder à l’esprit que les rôles dans Entra ID et Azure RM peuvent être attribués indépendamment l’un de l’autre. Par exemple, un utilisateur Entra ID standard avec des autorisations très limitées sur Entra ID peut détenir les privilèges les plus élevés dans Azure, ce qui constitue un point critique de vulnérabilité exploité dans les attaques. 

L’élévation de privilèges dans Entra ID peut entraîner une compromission importante d’Azure (y compris toutes les ressources et infrastructures), de Microsoft 365, des postes de travail, des serveurs Windows, des réseaux cloud, etc. 

Les rôles à plus haut privilège dans chacun de ces services sont : 

• Entra ID: Global Administrator 
• Azure RM: Owner (qui peut être restreint à un périmètre allant d’un Management Group jusqu’à une ressource) 

Ces différences significatives signifient que les concepts du modèle 3-tiers traditionnel de l’AD ne peuvent pas être appliqués directement aux environnements cloud. Nous devons repenser et adapter ces concepts pour nous assurer qu’ils sont pertinents et efficaces dans les contextes Clouds, notamment en répondant adéquatement aux exigences et aux risques spécifiques associés à ces environnements. 

Une compromission globale d’Entra ID bien réelle 

Pour se concentrer sur la compromission et l’élévation de privilèges de l’administration Cloud, quelques hypothèses initiales sont prises : 

• L’entreprise victime utilise un tenant Entra ID comme fournisseur d’identité (Identity Provider = IdP). 
• L’entreprise victime utilise Microsoft Intune pour gérer toute sa flotte de postes de travail. 
• L’entreprise victime a un abonnement Azure (Azure subscription) pour supporter ses activités liées aux VDI (Virtual Desktop Infrastructures). 
• Un compte du support a été compromis (on ne précise pas la source de l’attaque, mais il est important de noter qu’il s’agit d’un scenario très plausible pouvant être le résultat d’un hameçonnage, d’ingénierie sociale, ou encore d’une compromission du poste de travail, etc.) 

1 Compromission du compte du support 

• A la suite de nos hypothèses, nous supposons donc que l’attaquant a pris le contrôle d’un compte du support, ayant la permission de réinitialiser des mots de passe utilisateurs ainsi que des MFA (Multi-Factor Authentication)  

 2 Première tentative: Réinitialisation du mot de passe du compte Global Administrator 

• L’attaquant tente initialement de réinitialiser le compte Global Administrator, en cherchant le chemin le plus rapide pour devenir Global Administrator d’Entra ID.  

• Cette action est bloquée par défaut par Microsoft. Le rôle Global Administrator est un privileged role, et seuls d’autres privileged roles spécifiques sont autorisés à réinitialiser son mot de passe ou à modifier ses attributs. Microsoft met à jour ici sa liste de privileged roles natifs à Entra ID. 

 3 Seconde tentative: Compromission d’un compte standard Entra ID 

• L’attaquant étant restreint à la réinitialisation de mot de passe pour un utilisateur standard (non privileged), il identifie ensuite un utilisateur appelé « VDI Admin”, qui se trouve être Owner d’un abonnement Azure, utilisé pour héberger des services d’administration de postes de travail. 
• Malgré la double authentification activée, l’attaquant parvient à réinitialiser à la fois le mot de passe et le mécanisme de MFA, gagnant accès à ce compte. 

4 Recherche de l’abonnement Azure 

• Grâce à la compromission du compte « VDI Admin », l’attaquant se connecte en utilisant le mot de passe fraichement réinitialisé, et accède à l’abonnement Azure.  
• En faisant un petit peu de reconnaissance, il découvre un Key Vault contenant des identifiants et mots de passe pour un compte de service. 
• L’attaquant vérifie les permissions, et découvre que ce compte de service a le rôle « Intune Administrator » au niveau d’Entra ID. 

5 Utilisation des privilèges Intune Administrator 

• L’attaquant se connecte en tant qu’Intune Administrator, obtenant des permissions liées à l’administration des postes de travail, y compris la possibilité d’exécuter des scripts sur n’importe lequel d’entre eux. 
• Ils déploient un script sur le poste de travail du Global Administrator d’Entra ID, afin ensuite d’extraire les cookies d’authentification de son navigateur, et de pouvoir avoir accès à la console Azure. 

6 Compromission du compte Global Administrator

• L’attaquant récupère les cookies d’authentification du Global Administrator et les utilise sur son propre poste de travail pour se faire passer pour ce dernier. 

• Cela permet à l’attaquant de contrôler l’ensemble du tenant Entra ID, ce qui inclut la compromission du tenant Microsoft 365, des environnements Azure RM et de tous les autres outils cloud Microsoft reposant sur Entra ID. 

Figure 2: Chemin de compromission globale du Cloud Azure 

En suivant ces étapes, l’attaquant, au-delà de sa capacité à compromettre l’ensemble de l’infrastructure cloud, peut profondément affecter les activités d’une entreprise par un accès non autorisé aux e-mails et aux documents SharePoint, aux sauvegardes, aux postes de travail et serveurs, et au réseau de l’entreprise. Cette attaque démontre l’importance cruciale de sécuriser les comptes à privilèges élevés qui disposent de permissions susceptibles de conduire à une compromission mondiale. 

Figure 3 Impact d’une compromission du Control Plane 

Comment prévenir ce type d’attaque: Implémenter l’Enterprise Access Model, et restreindre l’accès au Control Plane 

Comme nous l’avons vu dans la première partie, les annuaires Cloud, en particulier Entra ID, présentent des différences clés par rapport à un Active Directory. Par conséquent, le modèle traditionnel 3-Tiers doit être adapté pour être pleinement efficace dans les environnements cloud. Pour relever ces défis, Microsoft a introduit un nouveau modèle d’administration spécialement conçu pour les environnements cloud : l’Enterprise Access Model (EAM) 

Figure 4: L’Enterprise Access Model 

Bien qu’il y ait quelques modifications, le concept de base reste le même : les ressources sensibles doivent être isolées pour s’assurer qu’une compromission dans d’un plane (anciennement Tiers) n’entraîne pas une compromission d’un autre. Cela nous amène à une question cruciale : comment devrions-nous définir notre Control Plane au sein de notre système d’information pour l’isoler efficacement et atténuer les risques d’une compromission globale ? 

La réponse réside dans l’identification des composants systémiques de notre système d’information, c’est-à-dire ceux dont la compromission pourrait conduire à une compromission globale. Perdre un projet d’une entité métier est bien moins critique qu’une compromission globale de l’ensemble du Système d’Information. 

Dans notre environnement cloud, de nombreux composants interagissent pour supporter les projets, de l’infrastructure CI/CD et des pipelines de déploiement aux différents outils IAM (tels que les fournisseurs d’identité comme l’AD, Entra ID ou Okta, les outils d’IGA, etc.), ainsi que les outils de sécurité transverses (tels que l’EDR, le Bastion et les outils de MDM par exemple). Bien qu’il s’agisse de composants génériques probablement présents dans de nombreux systèmes, il existe également de nombreux composants spécifiques à l’environnement à prendre en compte. 

Ensuite, Nous devons évaluer l’impact de la compromission des comptes à privilèges élevés au sein de ces composants. Par exemple, si un attaquant prend le contrôle d’un compte à privilèges élevés au sein de l’infrastructure CI/CD, il pourrait potentiellement modifier les processus CI/CD et/ou exécuter un pipeline spécifique pour déployer des modifications non autorisées dans le cloud, ce qui lui permettrait d’obtenir un accès global. Par conséquent, ces comptes CI/CD à privilèges élevés doivent faire partie du Control Plane. De même, considérons la solution EDR : si un administrateur à privilèges élevés peut exécuter des scripts sur tous les postes de travail, potentiellement en volant des cookies d’authentification, en accédant à des données critiques ou en rendant tous les postes de travail inutilisables, alors ce compte à privilèges élevés doit également être inclus dans Control Plane. 

En définissant et en sécurisant soigneusement notre Control Plane, nous pouvons réduire considérablement le risque d’une compromission globale au sein de notre système d’information. 

Synthèse 

Comme nous l’avons vu, le risque de compromission globale dans un environnement Cloud est important. Si les environnements Clouds offrent une flexibilité, une résilience et une optimisation des coûts accrues, ils introduisent également de nouveaux paradigmes et méthodologies opérationnelles qui doivent être comprises et maîtrisés pour garantir la sécurité. 

Le modèle traditionnel 3-Tiers des environnements on-premise, en particulier de l’Active Directory, n’est pas adapté à l’organisation de l’administration dans le cloud. Pour remédier à ce problème, Microsoft a introduit l’Enterprise Access Model (EAM). Ce modèle étend les 3 niveaux en cinq planes distincts, le plus critique étant le Control Plane. Cependant, tout comme pour le modèle 3-Tiers, les mesures d’isolement sont cruciales dans l’EAM, nécessitant l’identification des composants critiques et des comptes à privilèges élevés au sein de votre système d’information. C’est la priorité absolue pour assurer la sécurité globale du cloud. 

Le prochain article de cette série fournira d’autres exemples concrets de scénarios d’attaque qui peuvent conduire à une compromission globale des environnements cloud. Il comprendra également des recommandations de sécurité pour améliorer l’administration du cloud et éviter que ces risques ne se transforment en incidents de sécurité. 

Merci à Louis CLAVERO pour sa contribution à cet article.

Cet article Enterprise Access Model (1/2): Comment définir un Control Plane pour sécuriser l’administration Cloud et empêcher une compromission à grande échelle est apparu en premier sur RiskInsight.

Le Wavegame est un challenge inter-école créé en 2019 qui vise à promouvoir l’expertise cybersécurité et le métier du conseil. La compétition comporte deux volets, le premier étant réservé aux étudiants en commerce et le second aux étudiants en informatique. La partie technique consiste en 2 exercices de qualification et un événement final. Cet article aborde le deuxième exercice où, dans sa saison 2023, 33 équipes se sont affrontées autour de la sécurisation d’une infrastructure Cloud AWS. 

Sur fond d’une intrigue futuriste, les étudiants devenus consultants ont été mandatés par France Fusion, une entreprise chargée d’exploiter les premières usines à fusion nucléaire du pays. France Fusion souhaitait mettre au point une plateforme de supervision dans le Cloud. Pour ce faire, les données d’équipements industriels collectées, relevant de la propriété intellectuelle de France Fusion, devaient être analysées au travers d’une base de données ElasticSearch.  

Démarré sous la forme d’un Proof of Concept (PoC) en marge des équipes sécurité, une équipe de développeurs est parvenue à déployer une architecture fonctionnelle sur AWS. Les étudiants sont alors amenés à sécuriser l’infrastructure en respectant les politiques Cloud public de France Fusion. Le défi technique était de taille : déployer une infrastructure vulnérable en libre-service sur 33 comptes AWS. Il s’agissait également d’accorder aux étudiants un accès administrateur et les autorisations nécessaires pour effectuer des modifications directement depuis la console AWS, le tout avec un budget limité compte tenu du nombre de participants.  

Dans cet article, nous allons vous partager la recette qui a permis de faire de ce défi une réalité. 

Etape 1 : Mettre sur le papier une architecture portant une dimension pédagogique 

Avant de nous lancer dans le développement du coding game, nous avons pris en compte 4 contraintes :  

• La population cible : s’agissant d’étudiants, il est primordial de tenir compte de l’hétérogénéité en matière de connaissances Cloud. Par conséquent, nous nous sommes concentrés sur l’utilisation des services essentiels AWS (e.g., S3, EC2, Lambda), car ce sont des ressources bien documentées et parce que les étudiants sont susceptibles de les avoir abordés en classe ou dans le cadre de projets personnels. 
• Le thème : c’est un élément crucial pour immerger les étudiants dans un contexte de mission client. Nous avons donc cherché à créer une architecture aussi réaliste que possible. Ainsi, le choix de déployer une suite ELK (Elasticsearch, Logstash, Kibana) sur une instance EC2 nous a paru pertinent pour un PoC lié à de la supervision. 
• Les coûts : sachant que l’infrastructure doit être accessible par des étudiants pendant 2 semaines et qu’elle doit être répliquée sur 33 comptes AWS, nous avions tout intérêt à optimiser les coûts. Pour y parvenir, nous avons utilisé le calculateur de tarification AWS pour estimer les coûts, opté pour une région à faible coût et construit l’infrastructure autour de services « paiement à l’utilisation » tels que les fonctions Lambda. 
• Les échéances : pour faire face à un calendrier rapproché, nous avons défini des objectifs et des jalons avec une marge suffisante pour surmonter les éventuelles contraintes techniques. Les principales étapes du projet sont le développement, les tests, la création de comptes et le déploiement. 

Le schéma d’architecture « vulnérable » ci-dessous reflète ces 4 contraintes (Figure 1). L’équipement industriel est simulé par une fonction Lambda (Datalake) qui va générer des logs et les envoyer dans un bucket S3 (Datalake). Une seconde fonction Lambda (ELK) est alors déclenchée par une notification S3. Elle va récupérer le fichier de logs et l’envoyer dans la base ElasticSearch (image Docker dans une instance EC2). Enfin, l’interface Kibana est accessible depuis Internet pour l’analyse des logs.  

Figure 1 : schéma d’architecture initiale du Wavegame 2023 

Etape 2 : Concevoir une architecture sécurisée basée sur des politiques sécurité du Cloud public 

Maintenant que nous avons notre scénario initial, il s’agit de concevoir des politiques du Cloud public qui vont fixer les exigences sécurité et les critères d’évaluation. Pour cela, nous avons adapté des bonnes pratiques de sécurité mises en œuvre chez nos clients dont voici un extrait : 

• AWS-01 : Toutes les ressources AWS doivent utiliser des rôles IAM spécifiques à leurs besoins et respectant le principe du moindre privilège. 
• AWS-02 : Toutes les ressources AWS doivent être connectées et/ou attachées à un réseau privé (VPC). 
• AWS-03 : Les instances EC2 ne doivent pas être accessibles au public via Internet. 
• AWS-04 : Tous les logs d’infrastructure générés par les services AWS doivent être envoyés à CloudWatch. 
• AWS-05 : Le volume Amazon EBS racine doit être chiffré sur toutes les instances EC2. 
• AWS-06 : les données dans le bucket S3 doivent être chiffrées. 

À partir des politiques du Cloud public, nous avons élaboré l’architecture sécurisée suivante (Figure 2) : 

 Figure 2: schéma d’architecture cible du Wavegame 2023 

En résumé, l’ensemble des ressources Calcul sont positionnées dans un sous-réseau privé, le bucket S3 est accédé via un point de terminaison VPC, la plateforme de supervision ELK est accédée via une machine virtuelle de rebond. Les services Cloudwatch et CloudTrail sont activés pour le monitoring et la supervision. Des security groups sont attachés aux ressources pour n’autoriser que les communications entrantes strictement nécessaires. 

Etape 3 : passer du design au développement en Terraform 

Pour construire le coding game, nous avons créé et maintenu 2 architectures distinctes, représentées par 2 branches distinctes dans Github. La première étant l’architecture vulnérable qui sera déployée initialement, et la seconde étant la solution qui sert de garantie de faisabilité. Cette « garantie de faisabilité » signifie que 3 points obligatoires sont remplis : 

• Les permissions IAM doivent être suffisantes pour permettre au système de fonctionner correctement. 
• La configuration finale de l’infrastructure doit prendre en compte les cycles de vie des objets et leurs interactions. 
• L’expertise requise pour compléter le coding game doit être adaptée à la montée en compétence des étudiants sur une période de 2 semaines. 

Concernant le cycle de développement, plutôt que de suivre une approche linéaire, où l’on créerait d’abord le code pour l’infrastructure initiale, puis pour l’infrastructure cible, nous avons opté pour une approche agile avec la définition de blocs fonctionnels. Pour illustrer cette idée, le bloc « Lambda (ELK) -> S3 » vise à concevoir une fonction Lambda déclenchée dès qu’une notification S3 PutObject est générée, avec ou sans point de terminaison VPC. Bien que nous devions maintenir 2 configurations Terraform simultanément, cette approche nous a donné une plus grande agilité pour réévaluer nos choix techniques. Pour réduire davantage la redondance et assurer la maintenabilité, nous nous sommes aussi concentrés sur le développement de modules Terraform pour les objets Lambda et S3.   

Pour automatiser le déploiement des ressources dans notre Sandbox et dans nos comptes étudiants, nous avons créé une chaîne CI/CD simplifiée dans Github. Elle est constituée de 2 Github Actions. A travers une syntaxe YAML, les Github Actions permettent d’exécuter des tâches intégrées à AWS ou Hashicorp. Dans notre cas de figure, nous avions une tâche pour exécuter la commande terraform apply et une tâche pour appliquer la commande inverse terraform destroy.  

L’un des avantages des Github Actions est le fait de pouvoir stocker les identifiants d’accès à AWS dans Github Secrets au lieu du code source ou d’un fichier local. De plus, le stockage des états Terraform dans un bucket S3 facilite la collaboration. Un état Terraform est un fichier qui garde une trace de la configuration actuelle. Ainsi, chaque développeur configure sa clé S3 dans sa branche Github qui deviendra la référence de son état. 

Au fur et à mesure que le développement avançait, nous nous sommes rendu compte de l’ampleur de l’écart entre l’architecture initiale et l’architecture cible. La raison principale est que les logiques IAM et réseau sont très différentes. En conséquence, il est devenu essentiel d’effectuer des tests en conditions réelles, c’est-à-dire à partir de la console AWS, afin d’identifier les ruptures, les politiques bloquantes et d’évaluer la complexité. A titre d’exemple, l’un des tests nous a rappelé que le script de démarrage d’un EC2 appelé user-data n’est pas persistant après un redémarrage. Par conséquent, ce comportement a empêché la mise en œuvre de la politique de sécurité relative au chiffrement du volume racine Amazon EBS (AWS-05). 

Etape 4 : Déployer les environnements de manière sécurisée 

Dans le cadre de ce défi, nous étions sur le point d’accorder un accès privilégié à des étudiants dans un environnement pendant deux semaines pour lequel une surveillance ou une assistance individuelle constante est impossible. Bien que cette approche représente une meilleure opportunité d’apprentissage, elle soulève des scénarios de sécurité spécifiques que nous devons anticiper et atténuer. Parmi ceux-ci, le dépassement de budget était une préoccupation majeure, étant donné l’accès illimité et les ressources à leur disposition. Une autre menace importante est la possibilité pour les étudiants de s’élever au sein de l’organisation, d’obtenir des accès non prévus ou de se compromettre les uns avec les autres. Enfin, le risque de détournement des ressources à des fins non autorisées ou malveillantes n’est pas négligeable. Chacune de ces menaces doit faire l’objet d’un examen attentif afin de garantir un déploiement sûr et responsable. 

Pour ce coding game, nous avons opté pour une conception AWS multicomptes afin d’isoler les environnements de chaque équipe. Grâce à l’organisation AWS, nous avons simplifié l’administration, amélioré le contrôle des coûts et pu mettre en place des garde-fous à l’aide de politiques de contrôle de la sécurité (SCP). Dans la Figure 3, nous présentons notre organisation AWS, composée d’un compte admin et d’une Unité d’Organisation (UO) Wavegame qui héberge les comptes des équipes où l’infrastructure est déployée. Nous avons mis en place 3 SCP spécifiques pour : 

• Restreindre l’accès aux services AWS en dehors de la région désignée, us-east-1, en définissant une liste d’opérations autorisées. 
• Renforcer l’utilisation des types d’instance Amazon EC2 à du t2.micro ou t2.large (contrainte liée à l’environnement ElasticSearch). 
• Interdire aux comptes étudiants de supprimer ou de modifier une ressource dont la balise est « protected« . 

Par ailleurs, pour mieux gérer les coûts, en particulier pour une durée de deux semaines, nous avons mis en place une fonction Lambda pour fermer automatiquement les instances EC2 après 2 heures d’activité. Pour éviter toute modification non autorisée par les étudiants, cette fonction Lambda était l’une des ressources sécurisées avec la balise « protected« . 

Figure 3: Organisation AWS pour le Wavegame 2023 

Enfin, en plus de notre utilisateur IAM qui est administrateur de l’UO Wavegame via un rôle IAM, nous avons créé un utilisateur IAM avec le rôle AdministratorAccess pour chaque compte AWS, afin de donner de l’autonomie aux étudiants pendant le challenge. Ils ont notamment suffisamment de droits pour se créer des comptes nominatifs. 

Etape 5 : Se préparer au RUN et à la correction 

Une fois le coup d’envoi donné, les étudiants ont 2 semaines pour sécuriser les ressources dans leur compte AWS en suivant nos politiques sécurité du Cloud public. Avec autant de permissions, des erreurs de configuration cassantes peuvent vite survenir. Par exemple, un groupe a créé une politique S3 « Deny All« , ce qui l’a conduit à s’exclure lui-même, ainsi que toute autre personne, puisqu’aucun d’entre nous n’a les privilèges du compte racine. 

Pour faire face à ce genre de situation, nous avons mis en place le système de communication suivant : chaque équipe dispose d’un coach chargé de signaler les problèmes techniques à l’équipe organisatrice qui nous remonte ensuite les incidents. Nous avons ainsi pu enquêter et résoudre les problèmes ou communiquer rapidement avec eux sans recevoir trop de messages pour des questions simples auxquelles les coachs pouvaient répondre.  

Outre la gestion des incidents, notre rôle consistait également à surveiller les dépassements de budget. Pour ce faire, nous avons mis en place des alertes de coûts pour chaque compte AWS. Nous avons également développé un script pour suivre l’évolution du budget des équipes en temps réel. Cet outil s’est avéré très utile pour fournir une estimation du temps passé par les étudiants sur le défi et réagir en cas de dépenses anormales. Par exemple, deux jours après le début du défi, une alerte a été déclenchée en raison d’une défaillance de la fonction Lambda destinée à éteindre la machine virtuelle. 

Une fois que le défi s’est terminé avec peu d’incidents et que l’accès des étudiants a été révoqué, il était temps de procéder à l’évaluation pour déclarer les gagnants. Pour rappel, les étudiants devaient configurer leur compte AWS en conformité avec les politiques du Cloud public. Pour leur évaluation, nous avons utilisé deux mécanismes de notation : 

• Une évaluation automatique grâce au déploiement de règles gérées AWS Config à la fin du défi. Amazon fournit un ensemble de règles couvrant un pourcentage significatif des exigences. Par exemple, une règle permet de vérifier si le bucket S3 est chiffré (AWS-06). 
• Une évaluation manuelle basée sur des critères attendus et des étapes de vérification clairement documentées. 

Pour conclure, organiser un coding game est un challenge ambitieux qui nécessite des compétences Cloud public et Terraform, une organisation solide et des capacités de réaction face à des événements inattendus. Malgré les défis, c’est une opportunité exceptionnelle d’apprentissage. Pour les participants, le Wavegame offre une introduction immersive à la sécurité dans le Cloud public. Pour les organisateurs, le Wavegame est une expérience pratique sur le design, la conception et le maintien en condition opérationnelle d’une infrastructure dans le Cloud public. 

Cet article Comment construire un coding game Cloud public étape par étape ?  est apparu en premier sur RiskInsight.