Un document nommé « Microsoft Azure AD Conditional Access principles and guidance » propose un certain nombre de recommandations sur l’implantation des Stratégies d’accès conditionnel
Une section plus particulièrement a attiré mon attention. Celle-ci porte sur la nomenclature recommandée de ces dernières. C’est cette partie que j’ai traduit.
- Document Original : Extrait de
Microsoft Azure AD Conditional Access principles and guidance. - Author: Claus Jespersen, Principal Security Consultant in Microsoft AC&AI WE
-
Twitter: @claus_jespersen
Section General Field Guidance Traduit de l’anglais
Nous voyons de nombreux clients qui ont développé leurs politiques d’AC au fil du temps par différentes personnes sans avoir une structure de dénomination cohérente ou une structure en général. Cela crée une confusion sur les politiques qui traitent de quoi et il est très difficile de comprendre les effets de la modification d’une politique.
Il est donc recommandé de commencer à utiliser un modèle de dénomination cohérent pour vos politiques d’AC.
Assurez une convention de dénomination stricte des politiques, comme <numéro d’AC>-<Personne/type d’utilisateur>-<Politique
Type>-<App>-<Platform>-<Grant>-<OptionalDescription>
Il y a eu (et il y a encore) de nombreuses façons de structurer les politiques d’AC. Une approche consiste à structurer les politiques d’AC en fonction de la sensibilité de la ressource à laquelle on accède.
Dans la pratique, cette approche s’est avérée très difficile à mettre en œuvre tout en protégeant l’accès aux ressources pour divers utilisateurs. Par exemple, on peut définir une politique d’AC qui exige un utilisateur et un dispositif connus pour l’accès à une ressource sensible à laquelle les invités et les employés doivent accéder.
Comme les invités viennent d’un appareil géré, cela ne fonctionnera pas et vous devrez ajuster la politique d’AC pour répondre aux deux exigences, ce qui se traduira généralement par une politique qui ne répond qu’au plus petit dénominateur (ce qui implique une sécurité moindre).
Une autre approche consisterait à examiner l’organisation et à essayer de définir des politiques d’accès en fonction de l’endroit où vous vous trouvez dans l’organisation. Cependant, cette approche aboutirait à un nombre beaucoup trop élevé de politiques d’accès conditionnel et semble impossible à gérer.
Une meilleure approche consiste à structurer les politiques liées aux besoins d’accès communs et à contenir un ensemble de besoins d’accès dans un persona, représentant ces besoins pour divers utilisateurs qui ont les mêmes besoins.
Les personas sont des types d’identité qui partagent des attributs d’entreprise, des responsabilités, des expériences, des objectifs et des accès communs. Nous tenons à souligner que la compréhension de la manière dont les biens et les ressources de l’entreprise sont accessibles par les différents personas fait partie intégrante du développement d’une stratégie globale de confiance zéro.
Personas
Quelques personas CA suggérés par Microsoft sont présentés dans la figure ci-dessous.
Microsoft recommande en outre de définir des persona distincts pour les comptes de type « break glass » et pour les identités qui ne font partie d’aucun groupe de persona. Les « comptes en verre » sont exclus de toute politique de l’AC et sont utilisés en cas d’urgence lorsque l’AC peut bloquer l’accès des utilisateurs.
|
Persona |
Description |
|
Global |
Global est un persona/placeholder pour les politiques qui sont de nature générale ou qui ne s’appliquent pas uniquement à un persona. Il est donc utilisé pour définir des politiques qui s’appliquent à tous les personas ou qui ne s’appliquent pas à un persona spécifique. La raison d’être de ce persona est de disposer d’un modèle permettant de protéger toutes les données pertinentes. Elle doit être utilisée pour contenir des politiques qui s’appliquent à tous les utilisateurs ou des politiques qui renforcent la protection sur des scénarios non couverts par des politiques pour d’autres personas.
Par exemple, si vous souhaitez appliquer la même politique pour bloquer l’authentification héritée pour tous les utilisateurs, vous pouvez choisir de la placer en tant que politique globale plutôt que d’avoir une politique héritée par persona qui peut être différente pour plusieurs personas.
Un autre exemple est celui où vous souhaitez bloquer un compte ou un utilisateur donné pour des applications spécifiques et où l’utilisateur/le compte ne fait partie d’aucun des personas. Par exemple, si vous créez une identité cloud dans le locataire AAD, cette identité ne fait partie d’aucun des autres personas (étant donné qu’aucun rôle Azure AD ne lui a été attribué), mais nous pouvons néanmoins vouloir empêcher cette identité d’accéder aux services Office 365. Certains clients peuvent vouloir bloquer tout accès à partir d’identités qui ne sont pas couvertes par un groupe de personas, tandis que d’autres peuvent vouloir simplement appliquer le MFA. |
|
Admins |
Dans ce contexte, nous définissons les administrateurs comme étant toutes les identités non-internautes (dans le nuage ou synchronisée) qui possède un rôle d’administrateur Azure AD ou autre Microsoft 365 (comme dans MDCA, Exchange, Defender for Endpoints ou Compliance). Comme les invités qui ont de tels rôles sont couverts dans un persona séparé, les invités sont exclus de ce persona. De nombreux clients ont encore des comptes séparés pour les rôles d’administration sensibles sur lesquels ce persona est basé. Idéalement, ils utilisent ces comptes sensibles à partir d’un poste de travail à accès privilégié (PAW), mais nous constatons souvent que les comptes d’administration sont utilisés sur des postes de travail standard où l’utilisateur final passe d’un compte à l’autre sur le même périphérique/PC. Certains clients souhaitent faire une distinction en fonction de la sensibilité des rôles d’administration du cloud et attribuer des rôles Azure moins sensibles à des utilisateurs finaux standard (internes) sans utiliser de comptes distincts pour cela et en se basant plutôt sur l’élévation JIT (Just In Time). Dans ce cas, remarquez qu’un utilisateur final sera ciblé par deux ensembles de politiques CA, un pour chaque persona. Lorsque vous utilisez des PAW, vous pouvez également introduire des politiques supplémentaires qui utilisent des filtres de périphériques dans l’AC afin de limiter l’accès des administrateurs aux seuls cas où ils utilisent le PAW. |
|
Developer |
Le persona développeur couvre les utilisateurs qui ont des besoins particuliers. Ils sont basés sur des comptes AD synchronisés avec Azure AD mais ont besoin d’un accès spécial à des services tels que Azure DevOps, les pipelines CI/CD, Device Code Flow, GitHub, etc. Le persona développeur peut couvrir des utilisateurs considérés comme internes ou externes, mais une personne ne peut faire partie que d’un seul de ces personas. |
|
Internals |
Les internes couvrent tous les utilisateurs qui ont un compte AD synchronisé avec Azure AD, qui sont des employés de l’entreprise et qui travaillent dans un rôle standard d’utilisateur final. (Il est suggéré que les internes qui ont un profil de développeur soient couverts par le persona de développeur). |
|
Externals |
Ce persona contient tous les consultants externes ayant un compte AD synchronisé avec Azure AD. (Il est suggéré que les consultants externes qui ont un profil de développeur soient couverts par le persona de développeur). |
|
Guests |
Guests contient tous les utilisateurs qui ont un compte Azure AD invité dans le locataire du client. |
|
GuestAdmins |
Le persona GuestAdmins contient tous les utilisateurs qui possèdent un compte Azure AD guest auquel est attribué l’un des rôles d’administrateur mentionnés. |
|
Microsoft365ServiceAccounts |
Ce persona couvre les comptes de service basés sur les utilisateurs du cloud (AAD) utilisés pour accéder aux services Microsoft 365 lorsqu’aucune autre solution ne peut couvrir le besoin (comme l’utilisation d’une identité de service géré). |
|
AzureServiceAccounts |
Ce persona couvre les comptes de service basés sur les utilisateurs du cloud (AAD) utilisés pour accéder aux services Microsoft Azure (IaaS/PaaS), lorsqu’aucune autre solution ne peut couvrir le besoin (comme l’utilisation d’une identité de service gérée). |
|
CorpServiceAccounts |
Ce persona couvre les comptes de service basés sur l’utilisateur provenant de l’AD sur site et utilisés sur site ou à partir d’une machine virtuelle basée sur l’IaaS dans un autre centre de données (cloud), par exemple machine virtuelle basée sur IaaS dans un autre centre de données (en nuage), tel que Azure, synchronisés à Azure AD et accédant à n’importe quel service Azure ou Microsoft 365 (à éviter) |
|
WorkloadIdentities |
Ce persona couvre les identités de machine, comme les principaux de service Azure AD et les identités gérées. CA prend désormais en charge la protection de l’accès aux ressources à partir de ces comptes. |
Pour les comptes de service, il faut prendre en compte ▪ Où le compte est domicilié/créé (généralement AD sur site ou Azure AD) ?
▪ À partir de l’endroit où le compte est utilisé, comme Azure PaaS, Azure IaaS VM ou à partir d’un serveur sur site ?
▪ Quelle ressource le compte de service cible-t-il, comme Exchange Online, SharePoint Online, Azure PowerShell, Azure AD, etc.
Ces facteurs peuvent influencer le nombre de personas que vous souhaitez couvrir pour l’accès du compte de service aux ressources protégées par Azure AD CA. Si les besoins d’accès sont différents pour les divers types de comptes de service utilisés et que le risque implicite ne permet pas de les exclure simplement des politiques d’AC existantes, vous souhaitez alors les couvrir par leur propre persona.
Même si le modèle actuel comprend un moyen de traiter les comptes de service basés sur l’utilisateur, il est utile de rappeler qu’il n’est pas recommandé d’utiliser ces comptes, comme indiqué dans le document suivant
Introduction to securing Azure Active Directory service accounts | Microsoft Docs. Il est plutôt recommandé d’utiliser les identités gérées ou les AAD Service Principals.
La protection de l’accès à l’aide de ces deux derniers n’est pas actuellement possible dans l’accès conditionnel (restez à l’écoute) mais ils sont généralement considérés comme plus sûrs car ils peuvent être utilisés sans gérer et exposer un mot de passe statique.
Un aperçu du tableau d’authentification et d’autorisation des services Azure est décrit ici : aadauth-n-z/readme.md at main – jsa2/aad-auth-n-z – GitHub (by Joosua Santasalo)
Policy Types
Les types de politiques suggérés, accompagnés de descriptions, sont présentés dans le tableau ci-dessous.
|
Policy type |
Description |
|
BaseProtection |
Pour chaque persona, nous voulons avoir une protection de base qui est couverte par ce type de politique. Pour les utilisateurs d’appareils gérés, il peut s’agir d’un utilisateur connu et d’un appareil connu, tandis que pour les invités externes, il peut s’agir d’un utilisateur connu et d’un MFA. La protection de base est la politique par défaut de toutes les applications pour les utilisateurs du persona donné. Si une application donnée doit bénéficier d’une politique autre que la politique par défaut, l’idée est d’exclure cette application de la politique de protection de base et d’ajouter une politique explicite ciblant uniquement cette application. Par exemple, si la protection de base pour les internes est d’exiger un utilisateur et un dispositif connus pour toutes les applications en nuage, mais que vous voulez autoriser Outlook sur le Web (OWA) à partir de n’importe quel dispositif, alors vous excluez Exchange Online de la politique de protection de base et ajoutez une politique distincte pour Exchange Online où vous exigez un dispositif connu OU une MFA. |
|
IdentityProtection |
En plus de la protection de base pour chaque persona, nous pouvons avoir des politiques d’AC qui se rapportent à l’identité. En voici quelques exemples : Bloquer l’authentification héritée, exiger une AMF supplémentaire en cas de risque élevé pour l’utilisateur ou la connexion, exiger un dispositif connu pour l’enregistrement de l’AMF, c’est-à-dire une carte de crédit. |
|
DataProtection |
Le type de politique indique les politiques delta qui protègent les données comme une couche supplémentaire au-dessus de la protection de base. Les exemples incluent les politiques de protection des applications pour iOS et Android où nous pouvons protéger et crypter les données sur un téléphone. (Les politiques de protection des applications comprennent également la protection des applications, de sorte qu’elles peuvent être considérées comme les deux). D’autres exemples incluent les politiques de session où les données sont protégées en utilisant la protection des informations Azure sur le flux si les données téléchargées sont considérées comme des données sensibles. |
|
AppProtection |
Ce type de politique est un autre ajout à la protection de base. Par exemple, si vous souhaitez autoriser l’accès Web à Exchange Online depuis n’importe quel périphérique. Dans ce cas, vous excluez Exchange de la politique de base et créez une nouvelle politique explicite pour l’accès à Exchange. Exchange, où vous autorisez par exemple uniquement l’accès en lecture seule à Exchange Online. Un autre exemple de politique AppProtection serait si nous avons besoin de MFA pour l’inscription à Endpoint Manager. Nous pourrions alors exclure « Intune/EM enrollment » de la politique de base et ajouter une politique d’AppProtection qui exige le MFA pour l’inscription à Endpoint Manager. |
|
AttackSurfaceReduction |
Ce type de politique vise à atténuer les diverses attaques, par exemple si un utilisateur vient d’une plateforme inconnue, l’expérience montre qu’il pourrait s’agir d’une tentative de contourner les politiques de l’AC qui exigent une plateforme donnée, d’où l’intérêt de bloquer les demandes provenant de plateformes inconnues pour atténuer ce risque. Un autre exemple serait de bloquer l’accès aux services Office 365 pour les administrateurs Azure ou de bloquer l’accès à une application pour tous les utilisateurs si l’application est connue pour être mauvaise. |
|
Compliance |
Une politique de conformité pourrait être utilisée pour exiger qu’un utilisateur prenne connaissance des « conditions d’utilisation » pour les invités accédant aux services à la clientèle. Dans ce cas, vous disposeriez d’un enregistrement d’audit prouvant que l’utilisateur invité a pris connaissance de vos conditions, qui pourraient inclure la manière dont vous utilisez les données PII liées à leur accès. C’est très important, par exemple pour le GDPR et d’autres exigences de conformité. |
|
|
|
App type policy
Le tableau ci-dessous présente les détails de la politique de type App
|
App |
Description |
|
AllApps |
Indique que « All Cloud Apps » est ciblé dans la politique CA, ce qui signifie que tous les points de terminaison sont protégés pour l’accès des utilisateurs, à la fois les points de terminaison qui prennent en charge CA et ceux qui ne le font pas. L’utilisation de AllApps a des implications dans certains scénarios qui ne fonctionnent pas bien avec cette politique. L’utilisation d’AllApps dans la politique de base est recommandée du point de vue de la sécurité, car tous les terminaux sont alors protégés par la politique de base et les nouvelles applications apparaissant dans Azure AD adhéreront automatiquement à cette politique. |
|
« AppName » |
« AppName » est juste un exemple d’une application que la politique adresse, il pourrait être « EXO » pour Exchange Online (pour ne pas rendre le nom de la politique trop long), ou SPO pour SharePoint Online. |
|
|
Platform type
Le champ Plate-forme dans le nom d’une politique de l’AC est utilisé comme indiqué dans le tableau ci-dessous
|
Platform |
Description |
||||||||||||||||||||||
|
AnyPlatform |
Cela indique que la politique doit cibler n’importe quelle plate-forme. Cela se fait généralement en sélectionnant « Any Device » (dans la politique de l’AC, le mot « platform » et le mot « device » sont tous deux utilisés). |
||||||||||||||||||||||
|
iOS |
Signifie que la politique vise les plateformes iOS d’Apple. |
||||||||||||||||||||||
|
Android |
Signifie que la politique vise les plateformes Google Android |
||||||||||||||||||||||
|
WindowsPhone |
Signifie que la politique vise les plateformes Windows Phone. |
||||||||||||||||||||||
|
macOS |
Signifie que la politique vise les plateformes MacOS. |
||||||||||||||||||||||
|
iOSAndroid |
Signifie que la politique vise à la fois les plateformes iOS et Android. |
||||||||||||||||||||||
|
Unknown |
Signifie que la politique cible les plates-formes qui ne font pas partie de celles mentionnées ci-dessus. Ceci est généralement utilisé en incluant « Tout appareil » et en excluant toutes les plateformes individuelles. |
||||||||||||||||||||||
|
|
|||||||||||||||||||||||
|
Grant field Le champ Grant dans le nom d’une politique de l’AC est utilisé comme indiqué dans le tableau ci-dessous
|
|||||||||||||||||||||||
|
Examples:
|
|||||||||||||||||||||||
Travailler ensemble 