Dans le Conditional Access Framework v4, les applications sont omniprésentes. Elles figurent dans la majorité des politiques, tantôt comme cible directe, tantôt comme simple périmètre d’application. Cette présence systématique peut induire une confusion fréquente : celle d’un framework dont l’objectif serait de sécuriser les applications elles-mêmes.
Ce n’est pas la position du CAF v4. Le framework adopte une lecture strictement technique du rôle des applications dans l’accès conditionnel. Une application n’y est pas considérée comme un actif à protéger, mais comme un contexte de décision dans le processus d’accès.
Autrement dit, le framework ne cherche pas à renforcer la sécurité interne des applications. Il utilise leur périmètre pour déterminer dans quelles conditions une identité peut obtenir un accès initial, en fonction du niveau de risque associé. Cette distinction est structurante, car elle évite d’attribuer à l’accès conditionnel des responsabilités qu’il ne peut pas assumer.
C’est à partir de cette lecture que le CAF v4 construit ses politiques. Les applications servent à cadrer l’accès, pas à garantir le comportement ou la sécurité une fois l’accès accordé.
Ce que l’accès conditionnel contrôle réellement
Dans Entra ID, une application n’est pas sécurisée par l’accès conditionnel en tant que telle, mais sert uniquement à identifier la ressource pour laquelle un jeton est émis lors de l’authentification.
L’accès conditionnel s’exerce exclusivement au moment où une identité tente d’obtenir un token pour une application donnée. La décision repose sur un contexte précis, évalué à cet instant : identité, type de compte, posture de l’appareil, niveau de risque, localisation, méthode d’authentification, etc.
Une fois le token émis et accepté par l’application, le rôle de l’accès conditionnel est terminé.
Il n’intervient plus sur :
- les actions réalisées dans l’application,
- les données consultées ou modifiées,
- l’usage réel des rôles et permissions internes,
- ni les abus fonctionnels éventuels.
Le Conditional Access Framework v4 part explicitement de cette limite.
Il ne cherche pas à étendre artificiellement le périmètre de l’accès conditionnel vers des domaines qu’il ne maîtrise pas, comme la sécurité applicative, la gestion fine des autorisations ou la protection des données.
Cette posture permet d’éviter un glissement fréquent sur le terrain : considérer qu’une application « protégée par l’accès conditionnel » serait, par extension, sécurisée dans son usage. Le framework refuse cette confusion et assume une séparation claire des responsabilités.
L’accès conditionnel contrôle l’entrée, pas ce qui se passe une fois à l’intérieur.
Tout ce qui relève du comportement applicatif, de la gouvernance des rôles ou du contrôle des données doit être traité par des mécanismes dédiés, en dehors du CAF v4.
Le périmètre applicatif comme outil de réduction de surface
Dans le Conditional Access Framework v4, le périmètre applicatif ne constitue pas un mécanisme de protection fonctionnelle, mais un levier destiné à réduire la surface d’exposition lors de l’accès initial.
Le scoping applicatif permet de limiter les conséquences immédiates d’une compromission générique. Sans ce levier, un compte compromis peut souvent obtenir des tokens pour un large ensemble d’applications, y compris celles dont l’impact est élevé ou transversal. En ciblant explicitement certaines applications, le framework évite que cet accès soit automatique.
Ce point est particulièrement visible pour :
- les portails d’administration,
- les applications à fort pouvoir de modification,
- les services transverses utilisés par plusieurs équipes ou processus.
Dans ces cas, le périmètre applicatif ne vise pas à « sécuriser l’application », mais à resserrer les conditions d’accès à des points d’entrée sensibles. Il agit en amont, au moment de la délivrance du token, et uniquement à ce moment-là.
Le framework traite donc l’application comme un vecteur de risque, pas comme un espace à contrôler finement. Une fois l’accès accordé, l’accès conditionnel ne supervise ni les actions réalisées, ni l’usage réel des rôles internes. Ces sujets relèvent d’autres couches de sécurité.
Ce choix est volontaire.
Le CAF v4 utilise le périmètre applicatif comme un mécanisme de confinement et de hiérarchisation des accès, sans lui attribuer un rôle qu’il ne peut pas tenir. En faisant ce choix, il limite les effets de bord, évite les faux sentiments de sécurité et maintient une séparation claire entre contrôle d’accès et sécurité applicative.
Une limite souvent mal acceptée sur le terrain
Cette posture volontairement limitée est souvent mal comprise. Dans de nombreux environnements, le fait d’appliquer des règles d’accès conditionnel strictes à une application conduit à la qualifier abusivement de « sécurisée », alors que l’accès conditionnel ne contrôle que les conditions d’obtention du jeton, pas la sécurité intrinsèque de l’application.
L’accès conditionnel ne corrige pas :
- une application vulnérable,
- une conception défaillante des rôles internes,
- une exposition excessive des données,
- ni l’absence de journalisation ou de contrôles métier.
Son périmètre s’arrête volontairement à l’entrée. Il conditionne l’obtention d’un token, pas l’usage qui en est fait ensuite. Une fois l’accès accordé, l’application fonctionne selon sa propre logique de sécurité, pour le meilleur comme pour le pire.
Le CAF v4 ne cherche pas à masquer cette limite, ni à la compenser artificiellement.
Il repose sur un principe simple : chaque couche reste responsable de ce qu’elle contrôle réellement. L’accès conditionnel cadre l’accès initial. La sécurité applicative, la gouvernance des rôles et la protection des données relèvent d’autres mécanismes, qui ne peuvent pas être remplacés par des politiques CA, aussi strictes soient-elles.
Cette séparation est parfois frustrante sur le terrain, mais elle évite un écueil fréquent : attribuer à l’accès conditionnel des garanties qu’il n’est pas en mesure d’offrir.
Pourquoi le framework évite la micro-segmentation applicative
Sur le plan purement technique, rien n’empêcherait de définir des politiques extrêmement fines, application par application, voire scénario par scénario. Le CAF v4 choisit explicitement de ne pas aller dans cette direction.
Ce choix n’est pas dicté par une contrainte technique, mais par une réalité opérationnelle largement observée. À mesure que la granularité augmente :
- la lisibilité des politiques diminue,
- la compréhension par les équipes s’effondre,
- les exceptions se multiplient,
- et la maintenance devient fragile.
À ce stade, la complexité devient elle-même un facteur de risque.
Une règle mal comprise est rarement appliquée correctement. Une politique incompréhensible finit presque toujours par être contournée, affaiblie ou supprimée lors d’un incident.
Le framework privilégie donc des périmètres applicatifs cohérents et relativement stables, même s’ils sont imparfaits. Cette sobriété permet :
- une meilleure explicabilité des décisions d’accès,
- une évolution plus progressive du modèle,
- et une réduction du risque de dérive dans le temps.
Dans le CAF v4, le périmètre applicatif n’est pas conçu pour refléter finement chaque usage métier. Il sert à structurer des décisions d’accès compréhensibles et soutenables, en complément des autres leviers du framework, pas à les remplacer.
L’interaction entre applications, personas et niveau de risque
Dans le CAF v4, les applications ne sont jamais traitées comme un axe autonome.
Elles prennent sens uniquement lorsqu’elles sont croisées avec la persona et le niveau de risque associé à l’identité qui tente d’y accéder.
Pour les utilisateurs standards, le périmètre applicatif sert principalement à éviter des accès trop larges par défaut. Il permet de limiter l’impact d’un compte compromis en empêchant qu’un accès générique donne immédiatement accès à des applications à fort enjeu, notamment dans des contextes dégradés ou peu maîtrisés.
Pour les comptes à privilèges, la logique est différente. Le périmètre applicatif devient un mécanisme de confinement explicite. L’objectif n’est plus seulement de réduire l’exposition, mais de circonscrire strictement les surfaces accessibles lors d’une élévation ou d’une action administrative. Le même portail ou la même application peut ainsi être soumis à des exigences radicalement différentes selon l’identité qui y accède.
Cette différenciation n’est pas une sophistication inutile. Elle traduit un principe central du framework :
le niveau d’exigence découle de l’impact potentiel, pas de la nature de l’application elle-même.
Une application n’est jamais « critique » ou « non critique » en soi. Elle le devient en fonction de l’identité qui l’utilise et des capacités que cette identité peut exercer une fois le token obtenu.
Dépendances implicites avec la session et l’appareil
Les politiques applicatives n’agissent jamais seules. Leur efficacité dépend fortement des contrôles de session et des appareils qui les entourent.
Certaines exigences, comme la fréquence de réauthentification, la persistance de session ou la remise en cause dynamique via la Continuous Access Evaluation, ne produisent d’effet que si l’application ciblée supporte correctement ces mécanismes. Toutes les applications ne réagissent pas de la même manière à une invalidation de session ou à un renouvellement de token.
Le CAF v4 ne cherche pas à formaliser exhaustivement ces dépendances.
Il part du principe qu’une tentative de modélisation complète serait à la fois fragile et rapidement obsolète. À la place, le framework adopte une posture pragmatique : éviter d’imposer des contrôles incompatibles avec les usages réels des applications concernées.
Cette approche explique pourquoi certaines politiques sont volontairement limitées à des périmètres applicatifs précis. Ce n’est pas un manque de couverture, mais un choix visant à préserver la cohérence globale du modèle et à éviter des effets de bord difficilement maîtrisables.
Dans le CAF v4, l’application n’est donc jamais un point d’ancrage unique : elle est un élément de décision parmi d’autres, dont la pertinence dépend étroitement de la session, de m’appareil et de la persona impliquée.
En bref
Dans le Conditional Access Framework v4, les applications ne sont ni un mécanisme de protection interne ni une garantie de sécurité.
Elles servent à cadrer où et quand un token peut être délivré, en fonction :
- de la persona,
- du contexte de session,
- et des signaux disponibles, notamment le device.
Le périmètre applicatif permet de réduire la surface d’exposition et de structurer les décisions d’accès, mais il ne remplace ni la sécurité applicative, ni la gouvernance des rôles, ni la protection des données.
La suite de la série peut désormais s’ancrer pleinement dans l’opérationnel, en abordant l’ordre de déploiement du framework et les erreurs classiques observées lors de son implémentation.