Recommandation Microsoft : Politique de Nommage des Stratégies d’accès conditionnel


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

Grant

Description

MFA

Indiquez que la politique exige le MFA

Compliant

Indique que la politique nécessite un périphérique conforme tel que déterminé par Endpoint Manager, donc le périphérique doit être géré par

Endpoint Manager

CompliantorAADHJ

Indique que la stratégie requiert un périphérique conforme ou un périphérique Azure AD Hybrid Joined. Un PC d’entreprise standard qui est relié à un domaine est également relié à Azure AD Hybrid. Les téléphones mobiles et les PC Windows 10 qui sont gérés conjointement ou associés à Azure AD peuvent être conformes.

CompliantandAADHJ

Cela indique que la politique nécessite un dispositif conforme ET Azure AD Hybrid Joined

Dispositif

MFAorCompliant

Indique que la politique exige un dispositif conforme OU l’MFA s’il ne l’est pas.

MFAandCompliant

Indique que la politique exige un dispositif conforme ET une MFA pour satisfaire cette politique.

MFAorAADHJ

Indique que la politique nécessite un PC hybride Azure

AD Hybrid Joined PC ou MFA si ce n’est pas le cas.

MFAandAADHJ

Indique que la politique nécessite un PC hybride Azure

AD Hybrid Joined PC et MFA

Unmanaged

Cela indique que la politique cible des périphériques qui ne sont pas connus par Azure AD. Un exemple d’utilisation de cette politique serait d’autoriser l’accès à Exchange Online à partir de n’importe quel appareil.

 

 

Examples:

  • CA001-Global-BaseProtection-AllApps-AnyPlatforms-AADJorCompliant
  • CA002-Global-IdentityProtection-AllApps-AnyPlatforms-Block-BlockLegacy
  • CA100-Admins-BaseProtection-AllApps-AnyPlatforms-Unmanaged
  • CA101-Admins-AttackSurfaceReduction-AllApps-Unknown-Block
  • CA200-Internals-AppProtection-O365-Windows10-AADHJ
  • CA201-Internals-AppProtection-O365-Windows10-Unmanaged
  • CA202-Internals-DataProtection-O365-Windows10-Unmanaged-DLPSessioncontrol
  • CA203-Internals-AppProtection-O365-iOSAndroid-EMAppProtection
  • CA204-Internals-AppProtection-SPO-iOSAndroid
  • CA300-Externals-BaseProtection-AllApps-AnyPlatform
  • CA301-Guests-Compliance-AllApps-AllDevices-RequireTOU (TOU = Terms Of Use)
  • CA401-GuestAdmins-Compliance-AllApps-AllDevices-RequireTOU (TOU = Terms Of Use)

     

 

Votre commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s