Partie 1 : Définir les bases
 

• Ce premier article de blog fait partie d'une série d'articles de blog liés à la mise en œuvre de l'approche Zero Trust dans Microsoft 365.

• Cette série couvrira d'abord les bases, puis approfondira les différentes fonctionnalités telles que l'accès conditionnel Azure Active Directory (Azure AD). stratégies, Microsoft Defender pour les stratégies Cloud Apps, Information Protection et Microsoft Endpoint Manager, pour n'en citer que quelques-unes.
   

• Dans cette première partie, nous allons passer en revue les bases qui peuvent être implémentées dans un environnement Microsoft 365 pour démarrer avec Zero Trust.
   

1. Introduction

• Qu'est-ce qu'une approche de sécurité Zero Trust ?

  • Ce modèle de sécurité dit que vous ne devez jamais faire confiance à personne et que chaque demande doit être vérifiée, quelle que soit l'origine de la demande ou la ressource consultée.
  • En d'autres termes, ce modèle supposera que chaque demande provient d'un réseau non contrôlé ou compromis.
  • Microsoft fournit cette illustration pour représenter les principaux éléments qui contribuent à Zero Trust dans un environnement Microsoft 365:
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     
  • Avec les environnements cloud, les identités sont considérées comme le nouveau périmètre car ces identités peuvent être utilisées pour accéder aux portails administratifs et aux applications accessibles sur Internet à partir de n'importe quel appareil connecté à Internet.
  • De plus, même lorsque des contrôles de sécurité sont appliqués, cela ne signifie pas que l'environnement est sécurisé.

    • Il y a eu de nombreuses attaques ces derniers mois/années qui ont permis aux attaquants de contourner les contrôles de sécurité via l'ingénierie sociale et les attaques de phishing, par exemple.

    • Par conséquent, l'objectif est plus de réduire l'impact potentiel d'une faille de sécurité sur l'environnement que d'empêcher les attaques de réussir.

 

• Principes de Microsoft 365

  • Lorsqu'une organisation souscrit un abonnement à Microsoft 365, un Tenant Azure AD est créé dans le cadre des services sous-jacents.

  • Pour les exigences de résidence des données, Microsoft vous permet de choisir la région logique dans laquelle vous souhaitez déployer votre instance d'Azure AD.

  • Cette région déterminera l'emplacement du centre de données où vos données seront stockées.

  • De plus, Microsoft 365 utilise Azure AD pour gérer les identités des utilisateurs.

  • Azure AD offre la possibilité de s'intégrer à un Active Directory Domains Services (AD DS) sur site mais aussi de gérer des applications intégrées.

​

2. Fonctionnalités

 

• Paramètres de sécurité par défaut

  • La première fonctionnalité est Azure AD Security Defaults.

  • Les paramètres de sécurité par défaut sont une excellente première étape pour améliorer la posture de sécurité en appliquant des contrôles d'accès spécifiques :
     

    • Enregistrement de l'authentification multifacteur unifiée (MFA) : tous les utilisateurs du Tenant doivent s'inscrire auprès de MFA.

      • Avec les paramètres de sécurité par défaut, les utilisateurs peuvent uniquement s'inscrire à Azure AD Multi-Factory Authentication en utilisant l'application Microsoft Authenticator à l'aide d'une notification push.

      • Notez qu'une fois inscrits, les utilisateurs auront la possibilité d'utiliser un code de vérification (Global Administrator aura également la possibilité de s'inscrire pour un appel téléphonique ou un SMS comme deuxième facteur).

      • Une autre remarque importante est que la désactivation des méthodes MFA peut entraîner le verrouillage des utilisateurs du Tenant, y compris l'administrateur qui a configuré le paramètre, si les paramètres de sécurité par défaut sont utilisés.
         

    • Protection des administrateurs : étant donné que les utilisateurs disposant d'un accès privilégié ont un accès accru à un environnement, les utilisateurs qui ont été affectés à des rôles d'administrateur spécifiques doivent exécuter l'authentification multifacteur à chaque fois qu'ils se connectent.
       

    • Protection des utilisateurs : tous les utilisateurs du Tenant sont tenus d'effectuer l'authentification MFA chaque fois que nécessaire.

      • Ceci est décidé par Azure AD en fonction de différents facteurs tels que l'emplacement, l'appareil et le rôle.

      • Notez que cela ne s'applique pas au compte de synchronisation Azure AD Connect en cas de déploiement hybride.
         

    • Bloquer l'utilisation des protocoles d'authentification hérités : les protocoles d'authentification hérités font référence aux protocoles qui ne prennent pas en charge l'authentification multifacteur.

      • Par conséquent, même si une stratégie est configurée pour exiger MFA, les utilisateurs seront autorisés à contourner MFA si de tels protocoles sont utilisés.

      • Dans Microsoft 365, l'authentification héritée est effectuée à partir de clients qui n'utilisent pas l'authentification moderne, comme les versions d'Office antérieures à Office 2013 et les protocoles de messagerie tels que IMAP, SMTP ou POP3.
         

    • Protection des actions privilégiées : les utilisateurs qui accèdent au portail Azure, à Azure PowerShell ou à Azure CLI doivent effectuer l'authentification MFA.
       

  • Ces fonctionnalités permettent déjà d'augmenter la posture de sécurité en appliquant une authentification forte.

  • Par conséquent, ils peuvent être considérés comme une première étape pour notre organisation qui vient de commencer à utiliser Microsoft 365 et continue de rechercher/évaluer/les différentes possibilités.
     

  • Si nous voulons activer les paramètres de sécurité par défaut, nous allons dans le portail
    Azure > Active Azure Directory > Propriétés >
    Gérer les paramètres de sécurité par défaut :

​



















 

 

• Paramètres MFA par utilisateur
   

  • Notez que les paramètres MFA par utilisateur, également appelés authentification multifacteur héritée, seront obsolètes le 30 septembre 2024.

  • Ces paramètres peuvent être utilisés pour exiger une authentification multifacteur pour des utilisateurs spécifiques chaque fois qu'ils se connectent.

    • Cependant, certaines exceptions sont possibles en activant l'option "Mémoriser MFA sur les appareils de confiance".

    • Notez que lorsqu'il est activé, ce paramètre permet aux utilisateurs de marquer leurs propres appareils personnels ou partagés comme approuvés.

    • Les utilisateurs ne seront invités à se réauthentifier que tous les quelques jours ou semaines lors de la sélection de cette option. L'intervalle dépend de la configuration.
       

  • Nous ne recommandons généralement pas d'utiliser le paramètre "Mémoriser MFA sur les appareils de confiance", sauf si vous ne souhaitez pas utiliser les paramètres de sécurité par défaut et que vous ne disposez pas de licences Azure AD Premium.

    • En effet, ce paramètre permet à tout utilisateur de faire confiance à n'importe quel appareil, y compris les appareils partagés et personnels, pendant le nombre de jours spécifié (entre un et 365 jours).

    • Cependant, ces paramètres peuvent être configurés dans le portail https://account.activedirectory.windowsazure.com.
       

    • Dans les paramètres utilisateur, MFA peut être activé
      pour chaque utilisateur individuel.
      
      
      
      
      
      
      
      
      
      
      
      
       

  • Ensuite, dans les paramètres du service, nous pouvons autoriser les utilisateurs à créer des mots de passe d'application pour les applications héritées qui ne prennent pas en charge MFA

    • Sélectionner des méthodes d'authentification disponibles pour tous les utilisateurs

    • Autoriser ou non les utilisateurs à se souvenir de l'authentification multifacteur sur les appareils de confiance pour un période de temps donnée.

    • Notez que la fonctionnalité d'adresses IP de confiance
      nécessite une licence supplémentaire
      (Azure AD Premium P1)
      
      
      
      
      
      
      
      
      
       

​





 

3. Résumé
 

• Ces deux fonctionnalités sont assez différentes mais nous permettent d'atteindre le même objectif, imposer une authentification forte, c'est-à-dire MFA, pour tout ou partie des utilisateurs.

​

• Pour l'organisation, nous choisirons les paramètres de sécurité par défaut pour plusieurs raisons :

  • Les paramètres MFA par utilisateur peuvent rapidement devenir ingérables.

    • Cela est particulièrement vrai pour une organisation en croissance.

    • Avec plus de personnes et un environnement complexe, des exceptions seront nécessaires et il deviendra difficile de suivre la configuration et de conserver une bonne base de référence.

  • Les valeurs par défaut de sécurité, respectivement, permettent d'appliquer une ligne de base standard pour tous les utilisateurs.

• Enfin, il est important de noter que ces deux fonctionnalités ne permettent pas de configurer des contrôles plus granulaires comme nous le verrons plus loin dans cette série.

 

Partie 2 : Protégez-vous contre les utilisateurs et les applications externes
 

1. Utilisateurs invités

 

• Les utilisateurs invités peuvent être la porte d'entrée permettant aux attaquants d'accéder à l'environnement Microsoft 365.

• En effet, en compromettant un utilisateur dans l'environnement d'un partenaire, les adversaires accéderont directement à notre environnement grâce à cette relation de confiance implicite qui se met automatiquement en place lors de l'invitation d'utilisateurs invités.

• La manière dont les utilisateurs invités seront gérés est une considération importante pour une approche Zero Trust.

  • Dans notre cas, nous ne bloquerons pas simplement les invitations d'utilisateurs invités car nous pensons que la collaboration avec des parties externes est un aspect important pour notre entreprise et sera nécessaire.

  • Par conséquent, nous voulons adopter une approche proactive à ce problème en établissant une base solide avant qu'il ne soit trop tard.

• Tout d'abord, nous voulons nous assurer que personne dans l'organisation, à l'exception des utilisateurs autorisés, ne peut inviter des utilisateurs invités.

  • En effet, par défaut, tous les utilisateurs de notre organisation, y compris les utilisateurs invités, peuvent inviter d'autres utilisateurs invités.

  • Cela pourrait représenter une sérieuse faiblesse dans notre approche Zero Trust.

  • Par conséquent, nous n'autoriserons que les utilisateurs affectés à des rôles d'administrateur spécifiques à inviter des utilisateurs invités (cela inclut les rôles d'administrateurs généraux, d'administrateurs d'utilisateurs et d'invités invités).
     

• Les restrictions d'invitation d'invités sont configurées dans Azure AD.

  • Pour cela, accédez au portail Azure > Azure Active Directory > Utilisateurs > Paramètres utilisateur > Gérer les paramètres de collaboration externe sous Utilisateurs externes.

  • Le choix de l'option la plus restrictive désactive la possibilité d'inviter des utilisateurs invités.

 

• De plus, comme l'organisation travaille avec des partenaires définis, les utilisateurs ne doivent pouvoir collaborer qu'avec eux. Nous pouvons donc restreindre davantage les invitations en spécifiant des domaines dans les paramètres de restrictions de collaboration :

 

​

• Par défaut, les utilisateurs invités disposent d'autorisations étendues.

  • Si un attaquant prend le contrôle d'un compte invité, les informations auxquelles l'utilisateur invité a accès peuvent être utilisées pour des attaques avancées contre notre société.

  • Pour cette raison, nous voulons les restreindre autant que possible.

  • Il n'est peut-être pas nécessaire que les utilisateurs invités puissent énumérer des ressources dans notre locataire Azure Active Directory. 

  • Par conséquent, nous souhaitons limiter les autorisations des utilisateurs invités.

 

 

 

 

 

 

 

 

 

• Avec ces restrictions mises en place pour les utilisateurs invités, nous avons déjà réduit l'impact potentiel qu'un utilisateur invité compromis pourrait avoir dans notre environnement.

2. Applications externes

​

• Les applications peuvent être intégrées dans Azure Active Directory pour les rendre accessibles à l'utilisateur.

• Il existe de nombreux types d'applications qui peuvent être rendues accessibles via Azure AD, telles que les applications cloud, également appelées applications pré-intégrées, comme Office 365, le portail Azure, Salesforce, etc., les applications personnalisées et les applications sur site.
   

• Les utilisateurs peuvent donner leur consentement aux applications pour permettre à ces applications d'accéder aux données de l'organisation ou à une ressource protégée dans le Tenant en leur nom.

  • En effet, les applications peuvent demander des autorisations API afin qu'elles puissent fonctionner correctement.

  • Ces autorisations API incluent l'accès au profil d'un utilisateur, au contenu de la boîte aux lettres d'un utilisateur, l'envoi d'e-mails, etc.

  • Cela peut également être considéré comme une porte d'entrée permettant aux adversaires d'accéder aux informations de notre environnement.

​

• Si le consentement de l'utilisateur est autorisé dans notre tenant Azure AD, les adversaires pourraient envoyer des hameçonnages d'accord de consentement aux employés.

  • Tout d'abord, parce que des adversaires pourraient accéder à notre locataire Azure AD parce que les restrictions d'invitation d'invités n'étaient initialement pas configurées, ils pourraient rassembler une liste de nos employés ainsi que leur adresse e-mail.

  • Ensuite, ils peuvent utilisé cette liste pour créer une campagne de phishing pour un guide d'étude de la certification Microsoft Advertising.
    
    
    
    
    
    
    
    
    
     

  • Parce qu'un employé était très impatient d'essayer ce nouveau guide en édition limitée, il a cliqué sur le lien et s'est connecté avec ses informations d'identification.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     

  • Malheureusement, l'employé avait une autorisation administrative dans le Tenant et pouvait donc donner son consentement au nom de l'ensemble de l'organisation.

  • Comme le montre la capture d'écran ci-dessus, l'application, qui n'est pas vérifiée, nécessite de nombreux accès tels que l'envoi et la visualisation d'e-mails, l'accès en lecture et en écriture aux paramètres de la boîte aux lettres, et l'accès en lecture aux notes, fichiers, etc.

  • Une fois que l'utilisateur a cliqué, les adversaires peuvent récupérer des informations sur l'utilisateur ainsi que sur l'organisation. De plus, ils peuvent accéder à la boîte aux lettres de l'utilisateur, aux fichiers OneDrive et aux notes.

​

 

3. Comment se protéger contre l'hameçonnage du consentement ?
 

• Il n'existe pas de solution à l'épreuve des balles pour protéger les utilisateurs contre le phishing, à moins que vous ne désactiviez la possibilité pour les utilisateurs de recevoir des e-mails et des messages dans le monde entier, ce qui est très loin d'être idéal.

• En effet, même avec les stratégies de menace d'Office 365, telles que les stratégies anti-hameçonnage et la sensibilisation des utilisateurs, les acteurs malveillants trouvent toujours de nouvelles façons de contourner ces staratégies et de tromper les utilisateurs.

• Cependant, ce que nous pouvons faire, c'est désactiver la capacité de consentement pour les applications dans Azure AD.

  • Pour restreindre le consentement de l'utilisateur pour les applications, il est possible de désactiver ou de restreindre les applications et les autorisations auxquelles l'utilisateur peut consentir.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     

  • Ce paramètre peut être configuré dans Azure Portal > Azure Active Directory > Utilisateurs > Paramètres utilisateur > Gérer la manière dont les utilisateurs finaux lancent et affichent leurs applications sous Applications d'entreprise > Consentement et autorisations.
     

• Outre le blocage de cette fonctionnalité, il est également possible de n'autoriser les utilisateurs à consentir que pour les autorisations classées comme à faible impact.

  • Microsoft offre la possibilité de définir notre propre modèle de classification pour les autorisations d'application, allant de faible à élevé, comme indiqué ci-dessous.

  • Dans ce cas, les administrateurs peuvent sélectionner le paramètre Autoriser le consentement de l'utilisateur pour les applications des éditeurs vérifiés, pour les autorisations sélectionnées (recommandé) dans la page des paramètres de consentement de l'utilisateur :
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     

3. Conclusion
 

• Dans cet article de blog, nous avons passé en revue différents paramètres dans Azure AD qui peuvent être restreints pour empêcher l'ajout d'utilisateurs malveillants au Tenant.

• De plus, nous avons vu comment les paramètres de consentement de l'application peuvent être abusés par le biais de l'hameçonnage de consentement et comment nous pouvons nous en protéger.

​