L’identité comme nouveau périmètre : accès conditionnel

Dans le modèle Zero Trust, l’Identity est le nouveau périmètre. Puisque les utilisateurs accèdent aux ressources depuis n’importe où — leur domicile, des cafés ou des Devices mobiles — la frontière du réseau n’a plus de sens comme ancrage de confiance. À la place, chaque décision d’accès repose sur l’identité de la personne qui fait la demande, le Device utilisé et les conditions applicables. Le fournisseur d’Identity devient le gardien de l’accès, et non le pare-feu.

Conditional Access est un moteur de Policy qui accorde ou restreint l’accès en fonction de signaux évalués au moment de l’authentification. Au lieu de simplement vérifier un nom d’utilisateur et un mot de passe, l’accès conditionnel évalue des conditions : le Device est-il compliant ? La location est-elle connue ? Le risk lié à la connexion est-il élevé ? La MFA est-elle satisfaite ? Ce n’est que lorsque les conditions sont remplies que le moteur de Policy émet un jeton d’accès. Si les conditions échouent, l’accès est refusé ou un CHALLENGE supplémentaire est déclenché.

Les politiques Conditional Access évaluent simultanément plusieurs catégories de signaux. Les signaux liés à l’utilisateur ou au groupe identifient l’auteur de la demande (administrateur, invité ou prestataire). Les signaux liés au Device vérifient l’état de conformité à partir du MDM. Les signaux liés à l’Application identifient l’App consultée (à sensibilité élevée ou faible). Les signaux de location comparent l’adresse IP aux locations nommées et aux Countries de confiance. Les signaux de risk lié à la connexion, issus du renseignement sur les menaces, signalent les schémas de connexion suspects.

Une Policy Conditional Access produit plusieurs résultats possibles. GRANT autorise l’accès, éventuellement avec des exigences telles que la MFA ou la conformité du Device. BLOCK refuse entièrement l’accès — par exemple, en bloquant tout accès depuis des Countries à risque élevé. Les contrôles de Session peuvent limiter les actions des utilisateurs après l’autorisation de l’accès : exiger une nouvelle authentification après un délai d’expiration, bloquer les téléchargements ou imposer un mode en lecture seule dans les Applications cloud.

Le Conditional Access fondé sur le risk intègre le renseignement sur les menaces à la décision d’accès en temps réel. Les fournisseurs d’Identity tels que Azure AD Identity Protection attribuent des scores de risk aux connexions en fonction de signaux comme les déplacements impossibles (connexion depuis deux Countries en quelques minutes), l’utilisation d’adresses IP connues comme malveillantes, les bases de données d’identifiants divulgués et les comportements anormaux. Les connexions présentant un risk élevé peuvent être automatiquement bloquées ou nécessiter une nouvelle vérification de l’Identity.

Conditional Access peut exiger la conformité du Device comme condition préalable à l’accès aux ressources Sensitive. Un Device compliant est inscrit dans un MDM (Intune, Jamf), exécute une version prise en charge de l’OS, dispose du chiffrement du disque et ne présente aucune vulnérabilité connue signalée par l’EDR. Les Devices non gérés ou non compliant sont redirigés vers un portail d’inscription au lieu d’obtenir l’accès, même si les identifiants de l’utilisateur sont valides.

Les locations nommées dans Conditional Access définissent des plages d’adresses IP de confiance : adresses IP des bureaux, Networks des agences ou nœuds de sortie VPN. Les politiques peuvent exiger une authentification supplémentaire (MFA) pour tout accès provenant de l’extérieur des locations nommées, ou bloquer complètement l’accès depuis certains Countries ou Networks de proxy anonymes. Cela ajoute une couche liée à la location à la vérification de l’Identity, sans revenir à une conception du périmètre fondée sur les adresses IP.

Les jetons d’accès Trad restent valides pendant leur durée de vie (souvent une heure), quelle que soit l’évolution du compte utilisateur après leur émission. La Continuous Access Evaluation (CAE) permet au fournisseur de ressources de révoquer les jetons presque en temps réel lorsque des événements critiques surviennent : compte désactivé, mot de passe modifié ou utilisateur signalé comme risqué. L’Application vérifie la validité du jeton pendant la Session, et pas uniquement lors de la connexion, ce qui comble la faille permettant à des jetons compromis de rester valides.

Les organisations doivent souvent accorder aux partenaires et aux prestataires un accès sans créer de comptes internes. L’Identity fédérée permet à un fournisseur d’Identity externe (Azure AD du partenaire, Google Workspace) d’authentifier les utilisateurs et de transmettre des attributs d’Identity vérifiés. Les politiques Conditional Access peuvent s’appliquer aux utilisateurs fédérés : exiger la MFA, restreindre les types de Devices ou limiter les Applications auxquelles ils peuvent accéder, tout en conservant le contrôle sans gérer directement leurs comptes.

Au-delà de l’autorisation ou du blocage de l’accès, Conditional Access peut appliquer des contrôles au niveau de la Session. Pour les Applications cloud intégrées à Microsoft Defender for Cloud Apps ou à des solutions CASB (Cloud Access Security Broker) similaires, les politiques peuvent imposer les restrictions suivantes : bloquer les téléchargements de fichiers sur les Devices non gérés, exiger une nouvelle authentification après 8 heures d’inactivité, afficher des avertissements lors de l’accès à des données Sensitive ou empêcher le copier-coller de contenu confidentiel en dehors de l’environnement Corporate.

Faire de l’Identity le périmètre nécessite d’intégrer plusieurs technologies : un fournisseur d’Identity (IdP) prenant en charge les protocoles modernes (SAML, OIDC), une solution MDM/EMM fournissant les données de conformité des Devices, un moteur de Policy Conditional Access et une authentification multifacteur comme niveau de référence minimal. L’objectif est de garantir qu’aucun accès n’a lieu sans vérification de l’Identity et de l’état du Device, quelle que soit la location réseau, en éliminant le concept de réseau interne de confiance.

Testez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’Identity remplace le périmètre réseau comme principal ancrage de confiance dans Zero Trust, que Conditional Access évalue plusieurs signaux (utilisateur, Device, location et risk) avant d’accorder l’accès, et que les contrôles de Session et la Continuous Access Evaluation maintiennent la sécurité pendant toute la Session d’accès, et pas uniquement lors de la connexion. Nous allons maintenant découvrir le Zero Trust Maturity Model afin de planifier son adoption à l’échelle de l’entreprise.