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.

Pour répondre à cet enjeu, Microsoft a défini l’Enterprise Access Model, offrant une nouvelle approche de la gestion des identités et des accès adaptés à la réalité du cloud. Ce modèle a pour promesse de redéfinir la manière dont les entreprises gèrent l’accès aux ressources numériques, que ce soit dans le cadre de solutions cloud comme Azure, d’applications Office 365 ou d’autres services stratégiques. 

Cet article propose une méthodologie et des exemples de mise en œuvre de ce modèle, en définissant des critères d’attribution des rôles à la Management Plane ou à la Control Plane. Il vise également à mettre en lumière les risques liés à une mauvaise implémentation du modèle, avec des exemples concrets. Enfin, il liste quelques bonnes pratiques de configuration ou de gestion du modèle d’accès, permettant de mitiger ces risques.  

Le modèle en tier, un modèle inadapté pour la gestion des accès dans le cloud ?

(Pour plus d’informations sur ce sujet, veuillez consulter notre livre blanc disponible ici)  

Le modèle de sécurité du tiering, appliqué à l’Active Directory, repose sur le principe fondamental de segmentation des comptes à privilèges en 3 différentes couches, appelés tiers. L’objectif est de garantir qu’en cas de compromission d’une ressource ou d’un compte d’un tier, les tiers de confiance supérieure demeurent préservés, évitant ainsi toute propagation potentielle de la compromission à l’ensemble du système. 

• Le tier 0 est le plus critique, il regroupe l’ensemble des composants de l’infrastructure qui gèrent les Domaines Contrôleurs AD de l’entreprise.  
• Le tier 1 se compose classiquement des applications de l’entreprise et des serveurs qui les hébergent.  
• Le tier 2 regroupe tout ce qui gravite autour de l’environnement utilisateur.  

Si le modèle de tiering permet de sécuriser l’infrastructure Active Directory, il rencontre néanmoins des défis significatifs lors de son application dans un contexte cloud. L’un des défis majeurs réside dans la nature même du cloud, pour lequel l’accès et l’administration se font généralement via des consoles exposées sur Internet, contrairement aux environnements on-premise. 

Microsoft a donc défini un nouveau modèle, « l’Enterpise Access Model » pour prendre en compte ces nouveaux défis. Nous examinerons comment ce modèle peut être mis en œuvre efficacement dans un environnement cloud Microsoft. 

Le modèle d’accès aux entreprises : un nouveau modèle adapté pour aux besoins du cloud  

L’une des caractéristiques clés de l’Enterprise Access Model est l’implémentation d’un mode d’accès privilégié pour certaines tâches critiques et la gestion d’une multitude de ressources critiques dites on-premise ou sur le Cloud.  

Source : https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model

Évolution de l’objectif et du champ d’application 

Tier 0 -> Control plane  

Le control plane comprend la gestion de tous les aspects du contrôle d’accès, la gestion des identités ainsi que tous les éléments pouvant mettre en péril le tenant. 

Tier 1 découpé en 2 morceaux  

• Management Plane : gestion du socle d’infrastructure des applications comme les serveurs ou la configuration des services PaaS (Platform as a Service). 
• Data/Workload Plane : gestion et configuration des applications, des ressources et des APIs. 

Tier 2 découpé en 2 morceaux  

• User access : inclut les scénarios d’accès B2B, B2C et public. 
• App access : permet de tenir compte de la surface d’attaque des échanges applications à applications via les API. 

Quels comptes mettre dans le control plane ? 

Pour définir les comptes du Control Plane, nous proposons une approche basée sur la criticité des rôles et l’impact qu’ils peuvent avoir sur l’environnement cloud. Si le rôle permet d’avoir un impact systémique pour l’Entreprise (destruction d’une part importante du cloud et des backups par exemple), il doit être géré dans le control plane. 

Attention à bien faire l’analyse complète, certains rôles courant comme par exemple le Helpdesk Administrator sans privilège critique sur des ressources direct ont la possibilité de prendre le contrôle de comptes qui eux en possèdent !  

Stratégie basée sur la criticité 

Optimiser la Sécurité : Appliquer l’Enterprise Access Model au Cloud Microsoft 

Au cœur de l’écosystème cloud de Microsoft se trouvent les rôles, une composante essentielle qui régit la manière dont les utilisateurs et les services interagissent avec les ressources cloud.  

Dans cette section, nous plongerons au cœur de cet aspect crucial de la gestion des identités et des accès dans le cloud. Nous expliquerons ce que sont les rôles Azure, comment ils fonctionnent, et pourquoi une bonne gestion est primordiale pour la sécurité et la performance de votre infrastructure cloud.  

Organisation des rôles dans les Cloud Microsoft: 

Les rôles sont un ensemble de permissions qui permettent de contrôler qui peut accéder aux ressources Azure et quelles actions ils peuvent effectuer. 

Les rôles dans Microsoft Cloud  

Il est important de différencier trois types de rôles : 

• Les rôles Azure qui sont dédiés à l’accès et gestion des ressources Azure. 
• Les rôles Microsoft Entra qui sont utilisés pour gérer les ressources de l’annuaire Microsoft Entra ID.  
• Les rôles Microsoft Entra qui sont utilisés pour gérer les ressources Office 365 associées. 

Il est important de souligner que ces rôles peuvent être interconnectés. 

Les rôles Azure : 

Les rôles Azure sont organisés en suivant le principe du Role-Based Access Control (RBAC), qui est une fonctionnalité intégrée de la plateforme cloud Azure de Microsoft.  

Ils sont dédiés à la gestion et à l’accès des ressources Azure et englobent des éléments tels que les machines virtuelles Azure, les bases de données SQL, les services, ainsi que les services d’application comme les Web Apps… 

L’assignation des rôles Azure est une étape clé de la mise en œuvre de la gestion des accès dans un environnement cloud. Elle détermine qui a accès à quelles ressources et quels privilèges sont accordés.  

Les « Security Principal » sur Azure font référence aux entités auxquelles des autorisations sont attribuées, que ce soient des utilisateurs, des groupes ou des services. Il existe plusieurs types de principaux de sécurité sur Azure, qui peuvent être des humains ou non. 

Security Principal 

L’étendue (scope) lors de l’attribution des rôles dans Azure est crucial pour déterminer où les autorisations s’appliquent. Il peut être spécifiée à différents niveaux comme le montre le schéma ci-dessous :  

Les étendues 

Afin de mieux comprendre l’attribution des rôles couplé à notre stratégie basé sur la criticité des rôles et de leurs impacts sur le cloud en ce qui concerne leur placement dans la Control plane nous vous proposons deux exemples concrets : 

Exemple d’application de la stratégie 

Dans l’exemple 1 nous attribuons à un User le rôle de Owner (permettant de lire, écrire et assigner des rôles à d’autres utilisateurs sur toute l’étendue sur laquelle le rôle est attribuée), sur l’étendue d’un Management group. Dans cet exemple le rôle de Owner est critique car l’étendue est très haut niveau : il aura donc les pleins pouvoirs sur toutes les Subscriptions, Resource groups et Resources de son Management group. C’est pourquoi dans ce cas nous plaçons le rôle de Owner dans la Control plane. 

Dans l’exemple 2 nous attribuons à un Group le rôle de Contributor (permettant de lire et écrire sur toute l’étendue sur laquelle le rôle est attribuée), sur l’étendue d’une Subscription. Dans cet exemple, l’impact est limité à une souscription donc probablement pas systémique pour l’Entreprise. C’est pourquoi dans ce cas nous plaçons le rôle de Contributor dans la Management plane. 

Ce qu’il faut retenir de ces exemples c’est que la criticité d’un rôle est en relation directe avec les permissions mais aussi l’étendue sur laquelle on attribue ce rôle.  

Une segmentation entre Microsoft Entra ID et Azure ? Le cas du Global Admin 

Les rôles Microsoft Entra ID et Azure sont définis de manière indépendante : respectivement dans Microsoft Entra ID et dans Azure RBAC. Cela signifie que les autorisations attribuées aux rôles Microsoft Entra ID n’offrent pas d’accès aux ressources Azure, et réciproquement. Cependant, en tant que Global Admin au sein de Microsoft Entra ID, nous avons la possibilité de nous octroyer un accès à tous les souscription et Management groups Azure associés.  

Quand le Global Admin s’accorde des accès vers Azure, le rôle d’User Access Administrator lui est attribué au niveau de l’étendue racine (Management group Root) d’Azure. Ceci lui permet de voir toutes les ressources et d’attribuer des accès dans n’importe quelle souscription ou management groupe de l’annuaire. 

Il est donc important de bien contrôler les personnes et le nombre de personnes se voyant attribuer le rôle de Global Admin, ainsi que de le gérer dans le Control Plane. 

Global Admin vers Azure 

Escalade de privilège par réinitialisation des mots de passe et MFA  

Cette méthode repose sur l’exploitation de privilèges qui autorisent la réinitialisation des mots de passe pour des comptes d’utilisateurs ou des systèmes. Les attaquants ciblent souvent des rôles spécifiques qui ont ce privilège, car une fois compromis, ils peuvent réinitialiser les mots de passe de comptes plus sensibles et donc y accéder pour prendre le contrôle de systèmes critiques.  

Le tableau ci-dessous met en avant les rôles Microsoft Entra ID pouvant réinitialiser le mot de passe de n’importe quel Owner d’une Subscription.  

A noter que certaines mesures de sécurité comme la MFA (Multi-Factor Authentication) permettent de réduire ce risque, comme nous allons le voir dans la suite de l’article.  

Un utilisateur ayant un rôle dans la colonne 1 peut-il réinitialiser le mot de passe de l’utilisateur de la ligne 1 ? 

Scénario d’attaque 1 : Escalade de privilège vers un rôle de Azure depuis un rôle Microsoft Entra ID : 

Un Helpdesk Administrator qui est un rôle est très courant en entreprise peut réinitialiser le mot de passe d’un Owner d’une Subscription et donc accéder à Azure en étant de base dans Microsoft Entra ID. De ce fait la segmentation entre les deux mondes n’est plus garantie. 

Scénario d’attaque 2 : Escalade de privilège vers un rôle de Microsoft Entra ID depuis un rôle Microsoft Entra ID : 

On observe qu’au sein même de Microsoft Entra ID une escalade de privilège d’un Helpdesk Administrator vers un Authentication Administrator est possible.  

Ces deux scénarios ne sont plus possibles si la MFA est paramétrée car le mot de passe seul ne permet pas de s’authentifier sur le compte. Cette mesure de sécurité permet dans la plupart des cas de couvrir ce type d’escalade de privilège. Cependant certains rôles ont la main mise sur les deux paramètres à savoir la réinitialisation de mot de passe et le paramétrage de la MFA et il n’est pas rare que le support utilisateur ait cette capacité. 

Un utilisateur ayant un rôle dans la colonne 1 a-t-il des droits sur la MFA ? 

Scénario d’attaque 3 : Escalade de privilège vers depuis un Authentication Administrator vers Azure ou Microsoft Entra ID : 

Ici nous prenons le cas du Authentication Administrator un rôle peut gérer et réinitialiser les méthodes d’authentification des utilisateurs qui ne possèdent pas un rôle d’administrateur. On observe donc qu’en plus de pouvoir avoir la main la MFA on a également via ce rôle la possibilité de modifier ou de réinitialiser les mots de passes d’une large partie des utilisateurs. Les tableaux ci-dessus montrent qu’il peut prendre le rôle d’un Helpdesk Administrator ou d’un Owner d’un Subscription.  

Il faut donc gérer ces rôles dans le Control plane pour éviter ces scénarios d’escalade de privilège et maintenir l’étanchéité entre Microsoft Entra ID et Azure. 

Renforcez Votre Sécurité, quelques exemples de mesures de sécurité supplémentaires 

Accorder des privilèges à une Managed Identity plutôt qu’à un utilisateur 

Afin de limiter les risques liés à l’attribution de rôles de la Control plane, il faut privilégier l’utilisation des Managed Identities comme alternatives aux autorisations accordées aux utilisateurs, ou du PIM (Privileged Identity Management) pour mieux gérer les utilisateurs à hauts privilèges. Cette approche permet de limiter les risques d’escalade de privilège. 

Les Managed Identities sont des entités d’authentification gérées par Azure pour les applications et les services. Plutôt que d’accorder des privilèges à des utilisateurs individuels, vous pouvez attribuer des autorisations aux Managed Identities associées à ces applications ou services. Cette approche présente les avantages suivants : 

1. Exposition aux Identifiants réduite : En utilisant des Managed Identities, on réduit la surface d’attaque potentielle, car les identifiants ne sont pas exposés ni partagés. 
2. Automatisation Sécurisée : Les applications et les services qui utilisent des Managed Identities peuvent automatiser des tâches sans nécessiter de comptes d’utilisateur avec des privilèges élevés. 
3. Contrôle Centralisé : La gestion des autorisations se fait de manière centralisée, ce qui facilite la gestion des privilèges à l’échelle de l’ensemble de l’environnement cloud. 

Limiter les risques avec le service Privileged Identity Management (PIM) 

Dans le cas où l’attribution de rôles à hauts privilèges ou des rôles de la Control plane et surtout à des utilisateurs, il est très important de contrôler et de surveiller l’attribution de ses rôles. L’utilisation de PIM qui est une fonctionnalité qui permet une gestion précise des privilèges d’administration peut s’avérer intéressant. PIM repose sur : 

1. L’élévation temporaire des privilèges : Les utilisateurs peuvent obtenir des privilèges d’administration de manière temporaire pour effectuer des tâches spécifiques, réduisant ainsi les risques associés à des autorisations permanentes et aux erreurs. 
2. La justification obligatoire lors d’une élévation de privilège. 
3. La mise en place un contrôle et surveillance. 
4. La création d’un workflow de validation des élévations privilège : /!\ Nécessite une maturité très forte pour pouvoir gérer la réactivité ainsi que les besoins en HNO (Heures Non Ouvrées). 

La sécurisation d’un environnement cloud est une préoccupation essentielle. Les attaques utilisant les concepts et les subtilités de la gestion du cloud augmenteront dans un futur proche, il serait dommage d’attendre que les attaquants commencent à traiter ce sujet pour commencer à traiter correctement ce sujet. 

Dans cet article, nous avons exploré divers aspects de la gestion des privilèges et de la sécurité dans le cloud, en mettant en lumière des stratégies et des pratiques fondamentales pour protéger efficacement la control plane qui regroupe des données et ressources très sensibles pour l’intégrité de l’infrastructure d’une entreprise. 

Nous avons exploré le modèle d’accès aux entreprises de Microsoft, qui repose sur le principe du « Zero Trust ». Ce modèle offre une approche flexible et sécurisée pour la gestion des accès dans un environnement cloud. 

Nous avons ensuite présenté les rôles de Microsoft Azure et certains risques d’escalade de privilège, soulignant l’importance de l’attribution précise des autorisations et de la surveillance continue pour prévenir les abus et les menaces potentielles. 

La sécurisation de la Control Plane dans un environnement cloud revêt une importance capitale pour la protection des données et des ressources sensibles d’une entreprise. En explorant les stratégies et les bonnes pratiques évoquées dans cet article, il est clair que chaque organisation doit définir avec soin son modèle de rôles, en veillant à ce que les comptes et les autorisations soient attribués de manière appropriée dans le Control Plane ou le Management Plane. Il est impératif de mettre en place des mesures garantissant l’isolation de chaque plan, tout en accordant une attention particulière à la gestion précise des autorisations et à la surveillance continue pour prévenir les abus et les menaces potentielles (notamment les escalades de privilège).  

La sécurité dans le cloud n’est plus une option, mais une nécessité absolue ! 

Cet article Protéger le Control Plane : Les Enjeux Cruciaux de la Sécurité dans le Cloud  est apparu en premier sur RiskInsight.