Implémentation du modèle Zero Trust dans Azure avec l'accès conditionnel

De nombreuses entreprises ont aujourd'hui migré une partie ou la totalité de leurs actifs informatiques vers le cloud. Cette solution permet de déléguer les opérations d’installation, de maintenance et de sécurité des infrastructures. Cependant, comme le montre le modèle de responsabilité (cf. figure 1), l’accès aux données et la gestion des identités sont à la charge du client, quel que soit le type de cloud.

L’entreprise doit notamment s’assurer qu’une personne externe n’a pas accès à ses données sans son consentement, contrôler les ressources accessibles par ses employés ou encore minimiser les risques liés à l’identité, comme l’usurpation d’identité. L’IAM (Identity and Access Management) est la pierre angulaire de la sécurité du cloud, d’où l’importance d’auditer ses outils.

‍

‍

L’accès conditionnel est une fonctionnalité clé d’Azure Entra ID(licence premium P1) qui permet de mettre en place un contrôle d’accès, et donc de sécuriser le cloud, les applications et les services selon des conditions spécifiques. Il s'agit d'un processus décisionnel dynamique dans lequel l'accès est accordé ou refusé en fonction de plusieurs facteurs, comme l'emplacement de l'utilisateur, l'état de son appareil ou son identité (cf. figure 2). Ce processus intervient après la première authentification de l’utilisateur (identifiant/mots de passe).

Une entreprise peut par exemple décider que ses employés ne peuvent pas accéder aux données de l'entreprise à partir de leur téléphone personnel afin de réduire les risques de fuite d’informations en cas de vol, de perte ou d'infection par un logiciel malveillant. Pour ce faire, l’entreprise met en place une politique d’accès conditionnel qui bloque tous les accès aux applications et aux données de l’entreprise depuis un téléphone qui n’a pas été enrôlé. En d'autres termes, ces politiques permettent d'appliquer un contrôle plus précis que les permissions utilisateur classiques et elles constituent un élément essentiel de la stratégie de sécurité Zero Trust, où chaque accès est vérifié en continu, indépendamment du lieu ou de l'appareil de l'utilisateur.​

Cet article explore comment Microsoft propose de structurer les politiques d'accès conditionnel pour mettre en œuvre le Zero Trust dans Azure, à travers trois axes principaux: le design, l’architecture et le cadre de mise en œuvre des politiques. Commençons toutefois par un rappel sur le Zero Trust.

‍

Le Zero Trust

Le Zero Trust est un modèle de sécurité informatique qui repose sur l'idée que rien ni personne, qu'il s'agisse d'un utilisateur, d'un appareil ou d'une ressource, ne doit être automatiquement considéré comme digne de confiance. Cette approche s'oppose au modèle traditionnel qui distinguait les éléments internes (considérés comme sûrs) des éléments externes (considérés comme non fiables) au sein d'un réseau d'entreprise.

‍

Chaque tentative d'accès à des ressources doit faire l'objet d'une vérification, d'une authentification et d'une autorisation, conformément à un ensemble de politiques de sécurité strictes. Il repose sur trois grands principes :‍

1. ‍Vérification systématique : Il s'agit de toujours vérifier l'identité et l'intégrité des utilisateurs et des appareils, indépendamment de leur emplacement ou de leur réseau.‍
2. Principe du moindre privilège : Les utilisateurs ne doivent accéder qu'aux ressources nécessaires à leur travail, avec le nombre minimum de permissions. En cas de compromission de l’utilisateur par un attaquant, alors la surface d’attaque de ce dernier sera limitée aux responsabilités de l’utilisateur.‍
3. Surveillance et audit continus : Il est crucial de surveiller en permanence toutes les activités et de réévaluer régulièrement les niveaux de confiance en fonction des comportements observés.

Le Zéro Trust repose sur six piliers (cf. figure ci-dessus), chacun d'entre eux étant abordé par une sécurité adaptative et granulaire, où la confiance est constamment évaluée, les accès sont strictement contrôlés et les menaces internes sont prises en compte autant que les menaces externes. Les termes utilisés pour décrire l'approche Zero Trust sont les mêmes que ceux utilisés pour décrire l'accès conditionnel en introduction, ce qui en fait un outil incontournable pour mettre en œuvre le Zero Trust dans Azure.

‍

Architecturer les politiques en fonction des rôles (personas)

Il est préférable d’adopter une approche structurée pour la création de politiques d’accès conditionnels, garantissant ainsi leur maintenabilité dans le temps et réduisant les risques de mauvaise configuration (cf. le chapitre « Les risques inhérents à la configuration des accès conditionnels »).Une alternative plus encadrée, comme l’utilisation des personas, permet de créer un socle de sécurité des accès documenté et adapté à l’entreprise. Cette méthodologie des personas consiste à lier chaque règle d’accès conditionnel à un persona. Un persona est une fiche d’identité mettant en avant les caractéristiques d’une typologie d’utilisateur (cf. figure4 - Carte de modèle d'accès).

-> Personas générique

Pour commencer, il faut définir des profils types qui permettent de catégoriser à haut niveau les utilisateurs. L’objectif est d’établir un socle minimal de sécurité pour l’ensemble des utilisateurs.Voici une liste de quelques personas génériques utilisés dans la plupart des entreprises aujourd’hui :

Ces personas génériques ont permis d’identifier un socle minimal de politiques d’accès conditionnels à mettre en place pour sécuriser les accès. Il s'agit là d'un point de départ, mais il reste encore loin d'un compromis sécurité et expérience utilisateur satisfaisant. Par la suite, il faudra adapter ces profils types aux contraintes et aux risques des équipes métiers de l’entreprise.

‍

-> Personas spécialisés

Les personas spécialisés jouent un rôle crucial en adaptant les personas génériques aux besoins spécifiques de l'entreprise. Prenons l'exemple du persona générique « Internals», qui peut englober diverses équipes métiers telles que les ressources humaines (RH), les équipes commerciales, les développeurs, etc.

Les besoins de chacune de ces équipes varient considérablement, tout comme les accès et les permissions nécessaires à leurs missions. Par exemple, les consultants de Cyberlift ont besoin d'accéder au Github interne, mais ils n'ont pas la nécessité d'accéder au système SIRH (Système d'Information des Ressources Humaines) utilisé par les équipes RH.

Ce processus d'identification des contraintes et des besoins spécifiques à chaque équipe métier permet d’attribuer des accès en respectant le principe du moindre privilège, ce qui réduit fortement la surface d’attaque en cas de compromission du compte. Ce travail est impossible à réaliser avec des personas génériques, qui regroupent un trop grand nombre d’équipes métiers aux responsabilités variées. Pour simplifier cette analyse, des cartes modèles d’accès (voir la figure ci-dessous) peuvent être créées. Ces cartes synthétisent toutes les caractéristiques pertinentes : contraintes, besoins, habitudes de travail, types d'accès nécessaires, etc.

Grâce à cette analyse, il devient plus facile d’évaluer les scénarios de risque associés à chaque personnage spécialisé.

‍

‍

-> Identification des scénarios de risques

Grâce au concept de persona spécialisé, il devient beaucoup plus facile d’identifier des scénarios de risque propres à chaque typologie d’utilisateur définie. En effet, la discrétisation des équipes métiers de l’entreprise, combinée à l’utilisation de cartes modèles d’accès, permet de mettre en évidence les accès sensibles et d’imaginer des scénarios de compromission associés.

Prenons l’exemple du consultant décrit précédemment. Ce dernier utilise un téléphone personnel pour accéder aux données et applications de l’entreprise. Cependant, ce téléphone n’est pas équipé d’une solution antivirus et n’est pas enregistré dans le système de gestion de l’entreprise. Autrement dit, cet appareil constitue une faille potentielle présentant un risque élevé de compromission.

Le scénario de risque identifié pourrait être celui d’un pirate informatique qui parviendrait à prendre le contrôle du téléphone du consultant, par exemple en utilisant un malware téléchargé par inadvertance ou à la suite d’un vol. Dans ce cas, l’attaquant pourrait obtenir un accès direct aux données et aux services de l’entreprise via l’utilisateur usurpé.

L’identification de ces scénarios de risque pour chaque persona est une tâche minutieuse qui peut rapidement aboutir à une liste importante de scénarios potentiels. Pour rendre cette démarche plus efficace, il est recommandé de travailler par itérations en fixant des délais précis. Par exemple, consacrer une heure à l’identification d’un maximum de scénarios de risque pour un personas pécifique. Ensuite, chaque scénario se voit, dans la mesure du possible, attribuer une politique d’accès conditionnel visant à atténuer le risque. Ces deux étapes peuvent être répétées périodiquement afin d’affiner les politiques d’accès conditionnel des personas.

Finalement, ce travail permettra d’attribuer un niveau de risque à l’utilisateur en fonction de ses caractéristiques, en plus des scénarios de risques identifiés. Ce niveau de risque global de la typologie de l’utilisateur devra être pris en compte lors de la configuration des politiques d’accès conditionnels. Par exemple, la durée de vie d’une session d’administrateur sera plus courte qu’une session d’utilisateur lambda en raison de la criticité des accès.

‍

-> Quelques politiques recommandées

• ‍BaseProtection : Politiques de protection de base pour chaque persona, comme l'authentification à plusieurs facteurs ou l'accès limité aux appareils connus.‍
• IdentityProtection : Mesures supplémentaires pour protéger les identités, par exemple en bloquant l'authentification héritée ou en exigeant plus d'authentification pour les utilisateurs à haut risque.‍
• DataProtection : Politiques pour renforcer la protection des données, comme l'application de politiques sur les sessions Azure Information Protection.‍
• AppProtection : Politiques spécifiques à des applications, par exemple permettre uniquement un accès en lecture à Exchange Online depuis des appareils non gérés.‍
• AttackSurfaceReduction : Politiques pour réduire la surface d'attaque, par exemple en bloquant les accès depuis des plateformes inconnues.‍
• Compliance : Politiques de conformité, telles que l'obligation pour les invités de lire et accepter les conditions d'utilisation.

‍

Les risques inhérents à la configuration des accès conditionnels

L'accès conditionnel, même s'il est utilisé et dispose de politiques, peut conduire à des failles de sécurité s'il est mal configuré. Lorsque l’entreprise décide d'utiliser l'accès conditionnel, elle doit désactiver les paramètres de sécurité par défaut du tenant Azure, qui, entre autres, imposent le MFA à tous les utilisateurs. De plus, le comportement par défaut de l'accès conditionnel n’impose aucune exigence supplémentaire (comme le MFA) pour toutes les demandes d'accès.

Voici quelques risques et enjeux opérationnels pouvant être liés à des configurations erronées :

• ‍Non-reprise des paramètres de sécurité par défaut : comme indiqué dans l'introduction, l'activation de l'accès conditionnel désactive les paramètres de sécurité par défaut, qui, par exemple, requièrent l'enregistrement multifacteur pour tous les utilisateurs, l'obligation pour les administrateurs d'effectuer le MFA à chaque connexion, etc. Cela signifie qu'il est important d’étudier leur pertinence dans le contexte de l'entreprise et de justifier les paramètres de sécurité par défaut qui ne sont pas repris par l'accès conditionnel.‍
• Une mauvaise gestion des exceptions : chaque règle d'accès conditionnel peut être configurée pour exclure des utilisateurs ou des groupes de son champ d'application. Ceci est utile lorsque l’entreprise souhaite appliquer une règle à tous les utilisateurs, à l'exception d'un utilisateur ou d'un groupe particulier. Cependant, ces exclusions sont parfois utilisées pour désactiver temporairement un contrôle pour un utilisateur, mais en l'absence de documentation et de procédure de re-certification, ce cas temporaire risque de devenir permanent.‍
• Blocage de l'accès au tenant : il est possible de créer des accès conditionnels qui affectent l'accès à toutes les applications Microsoft, y compris celle qui permet la configuration. Si une telle règle est mal configurée, il est possible de bloquer l'accès à toutes les applications pour tous les utilisateurs, même les administrateurs. Le seul recours sera de contacter le support de Microsoft, qui mettra plusieurs jours à débloquer l’accès.

L'accès conditionnel doit être considéré comme un pare-feu qui autorise tous les flux par défaut et où chaque règle de filtrage ajoutée peut soit améliorer la sécurité, soit la compromettre, si elle est mal configurée. Les conséquences d'une mauvaise gestion de la politique d'accès conditionnel ne se feront pas seulement sentir sur le plan de la sécurité, mais aussi sur le plan opérationnel si l'accès aux outils de l'entreprise est bloqué.

Cyberlift propose une solution d’audit des accès conditionnels permettant de repérer ces erreurs de configurations et d'identifier les axes d’amélioration pour une sécurisation optimale des accès.

‍

En bref

Pour appliquer une stratégie Zero Trust dans un environnement cloud Azure, il est essentiel de s’appuyer sur l'un des outils clés de la sécurité Azure : les accès conditionnels. Ces derniers constituent en effet la pierre angulaire de la protection des environnements cloud, en permettant une gestion granulaire et contextuelle des accès aux données et aux applications.

L’approche d’implémentation discutée dans cet article, repose sur l’identification des typologies d’utilisateurs au sein des équipes métiers d’une entreprise. Ce processus permet d'extraire des caractéristiques propres à chaque groupe, telles que leurs contraintes, objectifs, besoins, habitudes de travail, etc. Cette démarche conduit à la création de personas qui catégorisent les utilisateurs, facilitant ainsi l’identification des scénarios de risques auxquels ils sont exposés. 

En outre, la mise en lumière des caractéristiques propres à ces groupes permet également d’attribuer à chaque persona un niveau de risque en fonction de ses spécificités et de sa criticité pour l’organisation. Sur la base des scénarios de menace identifiés et des niveaux de risque associés, il devient possible de définir et de mettre en œuvre des politiques d'accès conditionnel conçues pour atténuer ces risques de manière proactive et ajuster le niveau de sécurité en fonction de la criticité de la personne.

Cependant, une fois ce travail préparatoire achevé, il est crucial de suivre un cadre méthodique pour l’implémentation des politiques afin d'éviter les risques liés à une mauvaise configuration des règles d’accès conditionnels. Il faut également rester vigilant même après la mise en œuvre. Tout au long de l’utilisation des accès conditionnels, l’entreprise devra réaliser des modifications qui pourront impacter l’écosystème de ses accès. Supprimer une règle qui était associée à une autre, par exemple, pourrait créer une faille facilitant l’accès à des entités malveillantes.

Pour détecter d'éventuelles vulnérabilités résultant d'une mauvaise mise en œuvre initiale ou d'évolutions ayant un impact mal évalué, Cyberlift propose une solution d'audit des accès conditionnels. Contactez-nous pour en savoir plus.