Dans l’ère des systèmes d’informations hybrides, la sécurisation des ressources cloud est un pilier de la sécurité des entreprises. Face à l’évolution constante des menaces et à la complexité croissante des environnements informatiques, les entreprises recherchent des solutions de système d’information sur le cloud et de gestion d’accès plus efficaces et évolutives.
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 :
- 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.
- 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.
- 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 :
- 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.
- La justification obligatoire lors d’une élévation de privilège.
- La mise en place un contrôle et surveillance.
- 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 !
