Les événements mondiaux depuis mars 2020 ont mis en avant un des principaux avantages de Microsoft Office 365 et de services SaaS basés sur le cloud : ils sont accessibles en tout temps et en tout lieu, sur n’importe quel appareil. Lorsque le monde a dû travailler à domicile, les applications Office 365 telles que Teams, Outlook, SharePoint et OneDrive pouvaient facilement être accédées en dehors de la chaîne traditionnelle de l’entreprise, et même sur des appareils non liés à l’entreprise. En fait, la plupart des abonnements à Office 365 et Microsoft 365 autorisent les utilisateurs à installer et à utiliser leurs applications sur jusqu’à cinq appareils.

L’un de vos principaux sujets d’inquiétude en conséquence peut être la prévention de la perte de données. Par exemple, par défaut, un utilisateur peut s’authentifier sur leur propre OneDrive ou boîte de réception professionnelle à l’aide d’un appareil personnel sans aucune limitation sur la capacité de synchronisation de tous les fichiers et courriels hébergés dans ce service. Que se passe-t-il avec les copies locales des données quand cet utilisateur quitte l’organisation ?

Azure Active Directory Conditional Access permet aux administrateurs de reprendre le contrôle. Il fait partie de la licence Azure Active Directory Premium P1, avec Conditional Access, vous contrôlez les conditions sous lesquelles un utilisateur est autorisé ou bloqué à accéder aux ressources d’Azure AD. Même si vous autorisez l’accès, vous pouvez imposer des mesures supplémentaires, telles que répondre à un déclencheur d’authentification à plusieurs facteurs (MFA) ou déterminer combien de temps il faut avant qu’ils ne doivent se connecter à nouveau.

Comment Conditional Access identifie les appareils commerciaux

Dans notre scénario, nous utiliserons Conditional Access pour permettre aux utilisateurs de se connecter à Office 365 uniquement sur les appareils commerciaux. Nous le faisons en se basant sur l’état de l’appareil.

Bien qu’il n’y ait aucun état de périphérique appelé « périphérique d’entreprise » dans l’Accès conditionnel, nous pouvons identifier deux choses à propos d’un périphérique et en déduire qu’il appartient à l’entreprise :

1. Le périphérique est-il joint à Azure AD hybride ?
2. Le périphérique est-il marqué comme conforme ?

La jonction hybride à Azure AD fait référence à un état où un périphérique est joint à votre annuaire Active Directory sur site, mais aussi synchronisé et joint à Azure AD basé sur le cloud. Nous avons expliqué comment mettre vos périphériques dans cet état ici. Ceci est uniquement approprié pour les périphériques Windows.

Sur la capture d’écran ci-dessous, vous pouvez voir comment Azure AD rapporte le type de jonction hybride Azure AD.

Marqué comme conforme signifie que le périphérique est inscrit dans une solution de gestion des appareils mobiles, telle qu’Intune, et répond aux exigences de conformité de ce MDM, comme avoir un pare-feu actif. À bien des égards, cela est un meilleur contrôle que de vérifier uniquement l’appartenance au domaine du périphérique, car vous garantissez également un niveau de posture de sécurité, ce qui est bénéfique pour une stratégie de confiance zéro. Cependant, si vous souhaitez uniquement confirmer que le périphérique est inscrit dans Intune, vous pourriez définir une politique de conformité sans exigences de sécurité spécifiques. Cette méthode peut être utilisée pour les « 4 grands » plateformes modernes : Windows 10, macOS, iOS et Android.

Dans la capture d’écran ci-dessous, vous pouvez voir comment Intune signale le conformité de l’appareil.

Strictement parlant, le terme correct pour un appareil dans l’un ou l’autre de ces états est un appareil géré.  Cela signifie qu’un administrateur informatique a un certain niveau de contrôle sur cet appareil, par exemple la capacité à appliquer et à gérer les paramètres soit via une Stratégie de groupe, soit via Intune.  Les appareils qui ne sont pas dans l’un ou l’autre de ces états sont considérés comme non gérés.  Supposons que nous ayons limité la capacité à s’inscrire à Intune aux appareils d’entreprise seulement, nous pouvons raisonnablement utiliser les termes gérés et d’entreprise comme des synonymes.

Il est important de noter qu’Azure AD peut demander des informations sur les certificats à certaines plateformes et navigateurs si une stratégie d’accès conditionnel basée sur l’état du dispositif est utilisée.  Il s’agit généralement de plateformes non Microsoft, telles que les plateformes Apple et Google.  Il le fait parce que les informations sur l’état de l’appareil sont stockées dans un certificat sur l’appareil, et tous les logiciels ne le signalent pas automatiquement à Azure AD lors de l’authentification.

Création de la stratégie d’accès conditionnel

Les stratégies d’accès conditionnel sont créées dans Azure AD > Sécurité > Accès conditionnel.  La meilleure pratique est de donner à votre stratégie un nom qui facilite l’identification précise de ce que la stratégie vise à accomplir.  C’est parce que si plusieurs stratégies correspondent à une tentative d’authentification, elles s’appliquent toutes, et une bonne convention de nommage simplifie le dépannage et la gestion.

Les politiques sont divisées en attributions et contrôles d’accès. Les attributions correspondent à une liste de tout ce qui doit être vrai concernant la connexion pour que la politique s’applique à la connexion. Pour la plupart de ces paramètres, vous pouvez inclure et exclure des conditions. Par exemple, inclure tous les utilisateurs mais exclure le personnel informatique. Si la politique s’applique, alors les contrôles d’accès déterminent si l’accès est refusé ou autorisé, et, en cas d’autorisation, quelles autres étapes et mesures doivent s’appliquer ou être vraies.

Avant de plonger dans l’Accès conditionnel, il est important de considérer sa puissance : il vous donne la possibilité de bloquer complètement l’authentification à toutes les applications. Par conséquent, vous pourriez mal configurer quelque chose et bloquer des utilisateurs importants pour des applications importantes, voire tous les administrateurs. Vous devriez envisager de créer des exceptions pour les comptes d’accès d’urgence pour lesquels vous surveillez l’activité de connexion. Personnellement, c’est la première étape que je prends lors de la création de toutes les politiques d’Accès conditionnel.

Utilisateurs et groupes définissent à qui la politique s’appliquera. Si vous n’êtes pas dans cette attribution, vous n’êtes pas soumis à ses règles. Pour une politique qui bloque l’accès à Office 365 sur des appareils non gérés, vous pouvez souhaiter étendre à tous les utilisateurs mais exclure les invités/utilisateurs externes et les comptes d’accès d’urgence. Sinon, inclure uniquement un groupe approprié d’Azure AD.

Pour les applications ou actions cloud, sélectionnez Office 365. Vous pouvez sélectionner plus d’une application cloud, vous voudrez donc peut-être créer une politique qui limite toutes les applications que vous jugez sensibles, pas seulement Office 365. L’application Office 365 répertoriée dans l’Accès conditionnel est en réalité une collection d’autres applications que vous pouvez sélectionner individuellement. Par exemple, elle inclut Exchange Online et SharePoint Online, mais vous pouvez théoriquement choisir les applications composantes. La raison pour laquelle vous voulez sélectionner Office 365 et non ses parties composantes est due à la nature intégrée du service. Le choix de la plateforme unifiée réduit les problèmes liés aux dépendances qu’elles ont entre elles.

Les conditions sont l’endroit où vous spécifiez les signaux et les propriétés d’authentification telles que les adresses IP, les systèmes d’exploitation et les applications (qui, en termes généraux, signifie l’accès via une application web ou cliente). Dans notre exemple, nous allons bloquer l’accès à toutes les méthodes d’accès Office 365, donc ne spécifiez aucune condition. Cela signifie que chaque condition s’applique. Une utilisation courante de ces conditions est cependant d’avoir des règles différentes pour l’accès web et l’accès aux applications de bureau.

Vous remarquerez également la condition de l’état du périphérique ici, mais nous ne la sélectionnerons pas pour cette politique. Lisez la suite pour comprendre pourquoi.

Contrôles d’accès

Maintenant que nous avons traité l’élément « si ceci… » de notre politique, il est temps pour le « alors cela… ». Les contrôles d’accès se divisent en paramètres de validation et de session.

Dans le volet accorder, sélectionnez accorder l’accès et cochez les cases pour marquer les périphériques requis comme conformes et exiger un périphérique joint à Azure AD hybride. Vous aurez également la possibilité de choisir si le périphérique doit être les deux à la fois, ou l’un ou l’autre. La recommandation est de sélectionner exiger l’une des commandes sélectionnées afin que les périphériques joints au domaine sur site et uniquement joints à Azure AD puissent accéder.

Ce que nous avons fait ici, c’est dire « vous pouvez accéder, mais vous avez besoin d’un périphérique géré ». En d’autres termes, cela signifie également « vous ne pouvez pas accéder à moins d’être un périphérique géré ». En supposant que notre processus de jointure au domaine sur site est sécurisé et que notre inscription à Intune est limitée aux périphériques d’entreprise, cela limite l’accès à Office 365 à des périphériques d’entreprise.

Les paramètres de session contrôlent ce qu’un utilisateur est autorisé à faire une fois qu’il a accès. Par exemple, dans les sessions du navigateur Web, vous pouvez utiliser les restrictions imposées par l’application pour bloquer les téléchargements à partir de services tels qu’Exchange Online et SharePoint Online. J’espère que cela vous amène à réfléchir aux différentes façons dont vous pouvez façonner vos stratégies : potentiellement une pour bloquer l’accès aux applications complètes sur les périphériques non gérés, mais une autre qui permet seulement l’accès aux applications Web, en imposant l’interdiction des téléchargements.

Déploiement de la stratégie d’accès conditionnel

Avec les paramètres tous appliqués, votre stratégie d’accès conditionnel peut maintenant être soit en mode rapport uniquement ou activé. L’objectif du rapport uniquement est de permettre aux journaux de connexion Azure AD d’auditer ce qui aurait pu se produire sans interrompre l’environnement de production. Vous pouvez ensuite utiliser ces informations pour comprendre les conséquences de la politique : par exemple, quelle perturbation pouvons-nous attendre, et donc quel type de formation devrions-nous fournir à nos utilisateurs?

Il y a un avertissement important en place pour le mode rapport uniquement dans notre cas. Comme mentionné précédemment, pour qu’Azure AD puisse déterminer l’état de l’appareil, il doit interroger un certificat, et certaines plateformes ne le permettent pas automatiquement. Même si vous fonctionnez en mode rapport uniquement, il a quand même besoin de ce certificat pour savoir ce qu’il aurait pu faire. Vous serez toujours averti de cela dans les politiques si vous incluez des paramètres basés sur l’état de l’appareil.

Lorsque vous êtes confortable que votre politique a été configurée correctement et n’affectera pas négativement l’entreprise, il suffit de changer l’état à activé, à ce moment-là la politique est immédiatement appliquée lors des prochaines tentatives d’authentification Azure AD.

Expérience utilisateur

Si un utilisateur tente maintenant d’accéder à une ressource Office 365 sur un appareil non d’entreprise (conforme à Intune ou hybride Azure AD join), Azure AD les informera que l’accès est bloqué. Cela est vrai pour tous les moyens d’accès, que ce soit en utilisant une application web ou une application client complète. Encore une fois, vous pouvez utiliser des conditions pour avoir des règles différentes pour les applications web et les applications client.

Sur les appareils professionnels, le processus d’authentification ne change pas autant pour l’utilisateur : ils iront directement dessus. L’exception à cela est lorsque l’application ne peut pas vérifier l’état de l’appareil. Cela ne devrait pas poser de problème pour les applications internes telles que la suite Office 365, mais par exemple cela peut être un problème avec les navigateurs tiers, même sous Windows. Vos utilisateurs peuvent rencontrer une erreur similaire à celle dans la capture d’écran ci-dessus. Chrome pour Windows prend en charge l’état de l’appareil en utilisant l’extension Comptes Windows 10 et comme vous pouvez l’imaginer, le navigateur Edge basé sur Chromium le prend en charge de manière standard.

Article associé :

• Pourquoi vous devriez restreindre l’accès à Office 365 en utilisant les politiques d’accès conditionnel de Microsoft