Partager via

Configurer Microsoft Entra for Zero Trust : Protéger les systèmes d’ingénierie

Le pilier de l’Initiative d’avenir sécurisé pour la protection des systèmes d’ingénierie a été développé pour protéger les propres ressources logicielles et l’infrastructure de Microsoft. Les pratiques et les insights obtenus à partir de ce travail interne sont désormais partagés avec les clients, ce qui vous permet de renforcer vos propres environnements.

Ces recommandations se concentrent sur la garantie de l’accès au moins privilégié aux systèmes et ressources d’ingénierie de votre organisation.

Recommandations de sécurité

Les comptes d’accès d’urgence sont configurés de manière appropriée

Microsoft recommande que les organisations disposent de deux comptes d’accès d’urgence en mode cloud uniquement auxquels le rôle Administrateur général est attribué définitivement. Ces comptes hautement privilégiés ne sont pas attribués à des personnes spécifiques. Les comptes sont limités aux scénarios d’urgence ou de « secours » où les comptes normaux ne peuvent pas être utilisés ou tous les autres administrateurs sont verrouillés accidentellement.

Action de correction

L’activation du rôle Administrateur général déclenche un flux de travail d’approbation

Sans flux de travail d’approbation, les acteurs des menaces qui compromissent les informations d’identification de l’administrateur général par le biais de l’hameçonnage, des informations d’identification ou d’autres techniques de contournement d’authentification peuvent activer immédiatement le rôle le plus privilégié dans un locataire sans aucune autre vérification ou surveillance. Privileged Identity Management (PIM) permet aux activations de rôle éligibles de devenir actives en quelques secondes, de sorte que les informations d’identification compromises peuvent autoriser l’escalade de privilèges quasi-instantané. Une fois activés, les acteurs des menaces peuvent utiliser le rôle Administrateur général pour utiliser les chemins d’attaque suivants pour obtenir un accès persistant au locataire :

  • Créer des comptes privilégiés
  • Modifier les stratégies d’accès conditionnel pour exclure ces nouveaux comptes
  • Établir d’autres méthodes d’authentification telles que l’authentification basée sur un certificat ou les inscriptions d’applications avec des privilèges élevés

Le rôle Administrateur général fournit l’accès aux fonctionnalités d’administration dans l’ID Microsoft Entra et les services qui utilisent des identités Microsoft Entra, notamment Microsoft Defender XDR, Microsoft Purview, Exchange Online et SharePoint Online. Sans portes d’approbation, les acteurs des menaces peuvent rapidement passer à la prise de contrôle complète du locataire, exfiltrer des données sensibles, compromettre tous les comptes d’utilisateur et établir des portes dérobées à long terme via des principaux de service ou des modifications de fédération qui persistent même après la détection de la compromission initiale.

Action de correction

Les administrateurs généraux n’ont pas d’accès permanent aux abonnements Azure

Les administrateurs généraux disposant d’un accès persistant aux abonnements Azure étendent la surface d’attaque pour les acteurs des menaces. Si un compte d’administrateur général est compromis, les attaquants peuvent énumérer immédiatement les ressources, modifier des configurations, attribuer des rôles et exfiltrer des données sensibles dans tous les abonnements. L’exigence d’une élévation juste-à-temps pour l’accès aux abonnements introduit des signaux détectables, ralentit la vitesse de l’attaquant et route les opérations à fort impact via des points de contrôle observables.

Action de correction

La création d’applications et de principaux de service est limitée aux utilisateurs privilégiés

Si les utilisateurs non privilégiés peuvent créer des applications et des principaux de service, ces comptes peuvent être mal configurés ou accorder plus d’autorisations que nécessaire, en créant de nouveaux vecteurs pour que les attaquants obtiennent un accès initial. Les attaquants peuvent exploiter ces comptes pour établir des informations d’identification valides dans l’environnement et contourner certains contrôles de sécurité.

Si ces comptes non privilégiés reçoivent par erreur des autorisations de propriétaire d’application élevées, les attaquants peuvent les utiliser pour passer d’un niveau d’accès inférieur à un niveau d’accès plus privilégié. Les attaquants qui compromissaient les comptes non privilégiés peuvent ajouter leurs propres informations d’identification ou modifier les autorisations associées aux applications créées par les utilisateurs non privilégiés pour s’assurer qu’ils peuvent continuer à accéder à l’environnement non détecté.

Les attaquants peuvent utiliser des principaux de service pour se fusionner avec les processus et activités système légitimes. Étant donné que les principaux de service effectuent souvent des tâches automatisées, les activités malveillantes effectuées sous ces comptes peuvent ne pas être signalées comme suspectes.

Action de correction

Les applications inactives n’ont pas d’autorisations d’API Microsoft Graph hautement privilégiées

Les attaquants peuvent exploiter des applications valides mais inactives qui ont toujours des privilèges élevés. Ces applications peuvent être utilisées pour obtenir un accès initial sans déclencher d’alarme, car elles sont des applications légitimes. À partir de là, les attaquants peuvent utiliser les privilèges d’application pour planifier ou exécuter d’autres attaques. Les attaquants peuvent également conserver l’accès en manipulant l’application inactive, par exemple en ajoutant des informations d’identification. Cette persistance garantit que même si leur méthode d’accès principale est détectée, elles peuvent récupérer l’accès ultérieurement.

Action de correction

Les applications inactives n’ont pas de rôles intégrés hautement privilégiés

Les attaquants peuvent exploiter des applications valides mais inactives qui ont toujours des privilèges élevés. Ces applications peuvent être utilisées pour obtenir un accès initial sans déclencher d’alarme, car elles sont des applications légitimes. À partir de là, les attaquants peuvent utiliser les privilèges d’application pour planifier ou exécuter d’autres attaques. Les attaquants peuvent également conserver l’accès en manipulant l’application inactive, par exemple en ajoutant des informations d’identification. Cette persistance garantit que même si leur méthode d’accès principale est détectée, elles peuvent récupérer l’accès ultérieurement.

Action de correction

Les inscriptions d’applications utilisent des URI de redirection sécurisés

Les applications OAuth configurées avec des URL qui incluent des caractères génériques ou des raccourcis d’URL augmentent la surface d’attaque pour les acteurs de menace. Les URI de redirection non sécurisés (URL de réponse) peuvent permettre aux adversaires de manipuler des demandes d’authentification, des codes d’autorisation de détournement et des jetons d’interception en dirigeant les utilisateurs vers des points de terminaison contrôlés par l’attaquant. Les entrées génériques étendent le risque en autorisant les domaines inattendus à traiter les réponses d’authentification, tandis que les URL plus raccourcies peuvent faciliter le hameçonnage et le vol de jetons dans des environnements non contrôlés.

Sans validation stricte des URI de redirection, les attaquants peuvent contourner les contrôles de sécurité, emprunter l’identité des applications légitimes et élever leurs privilèges. Cette mauvaise configuration permet la persistance, l’accès non autorisé et le mouvement latéral, car les adversaires exploitent une application OAuth faible pour infiltrer des ressources protégées non détectées.

Action de correction

Les principaux de service utilisent des URI de redirection sécurisés

Les applications non Microsoft et multilocataires configurées avec des URL qui incluent des caractères génériques, localhost ou des raccourcis d’URL augmentent la surface d’attaque pour les acteurs des menaces. Ces URI de redirection non sécurisés (URL de réponse) peuvent permettre aux adversaires de manipuler des demandes d’authentification, des codes d’autorisation de détournement et des jetons d’interception en dirigeant les utilisateurs vers des points de terminaison contrôlés par l’attaquant. Les entrées génériques étendent le risque en autorisant les domaines inattendus à traiter les réponses d’authentification, tandis que les URL localhost et raccourcis peuvent faciliter le hameçonnage et le vol de jetons dans des environnements non contrôlés.

Sans validation stricte des URI de redirection, les attaquants peuvent contourner les contrôles de sécurité, emprunter l’identité des applications légitimes et élever leurs privilèges. Cette mauvaise configuration permet la persistance, l’accès non autorisé et le mouvement latéral, car les adversaires exploitent une application OAuth faible pour infiltrer des ressources protégées non détectées.

Action de correction

Les inscriptions d’applications ne doivent pas contenir d’URI de redirection de domaine déchaînés ou abandonnés

Les URI de redirection non maintenus ou orphelins dans les inscriptions d’applications créent des vulnérabilités de sécurité significatives lorsqu’ils référencent des domaines qui ne pointent plus vers des ressources actives. Les acteurs des menaces peuvent exploiter ces entrées DNS « déchaînées » en approvisionnant des ressources sur des domaines abandonnés, en prenant efficacement le contrôle des points de terminaison de redirection. Cette vulnérabilité permet aux attaquants d’intercepter les jetons d’authentification et les informations d’identification pendant les flux OAuth 2.0, ce qui peut entraîner un accès non autorisé, un détournement de session et une compromission organisationnelle plus large.

Action de correction

Permettre aux propriétaires de groupe de donner leur consentement aux applications dans Microsoft Entra ID crée un chemin d’escalade latéral qui permet aux acteurs de menace de conserver et de voler des données sans informations d’identification d’administrateur. Si un attaquant compromisse un compte propriétaire de groupe, il peut inscrire ou utiliser une application malveillante et donner son consentement aux autorisations d’API Graph à privilège élevé délimitées au groupe. Les attaquants peuvent potentiellement lire tous les messages Teams, accéder aux fichiers SharePoint ou gérer l’appartenance au groupe. Cette action de consentement crée une identité d’application de longue durée avec des autorisations déléguées ou d’application. L’attaquant maintient la persistance avec des jetons OAuth, vole des données sensibles à partir de canaux et de fichiers d’équipe, et emprunte l’identité des utilisateurs via des autorisations de messagerie ou d’e-mail. Sans l’application centralisée des stratégies de consentement des applications, les équipes de sécurité perdent de la visibilité et les applications malveillantes se répartissent sous le radar, ce qui permet d’attaquer plusieurs étapes sur plusieurs plateformes de collaboration.

Action de correction Configurez la préapprobation des autorisations de consentement (RSC) Resource-Specific.

Les identités de charge de travail ne sont pas affectées à des rôles privilégiés

Si les administrateurs attribuent des rôles privilégiés à des identités de charge de travail, telles que des principaux de service ou des identités managées, le locataire peut être exposé à un risque significatif si ces identités sont compromises. Les acteurs des menaces qui accèdent à une identité de charge de travail privilégiée peuvent effectuer une reconnaissance pour énumérer les ressources, élever les privilèges et manipuler ou exfiltrer des données sensibles. La chaîne d’attaque commence généralement par le vol d’informations d’identification ou l’abus d’une application vulnérable. L’étape suivante est l’escalade des privilèges via le rôle attribué, le mouvement latéral entre les ressources cloud et enfin la persistance via d’autres attributions de rôles ou mises à jour d’informations d’identification. Les identités de charge de travail sont souvent utilisées dans l’automatisation et peuvent ne pas être surveillées aussi étroitement que les comptes d’utilisateur. La compromission peut ensuite ne pas être détectée, ce qui permet aux acteurs de menace de maintenir l’accès et le contrôle des ressources critiques. Les identités de charge de travail ne sont pas soumises à des protections centrées sur l’utilisateur telles que l’authentification multifacteur, ce qui rend l’attribution de privilèges minimum et une révision régulière essentielle.

Action de correction

Les applications d’entreprise doivent exiger une attribution explicite ou un approvisionnement délimité

Lorsque les applications d’entreprise n’ont pas à la fois des exigences d’attribution explicites ET des contrôles d’approvisionnement délimités, les acteurs des menaces peuvent exploiter cette double faiblesse pour obtenir un accès non autorisé aux applications et données sensibles. Le risque le plus élevé se produit lorsque les applications sont configurées avec le paramètre par défaut : « Affectation requise » est définie sur « Non » et l’approvisionnement n’est pas obligatoire ou limité. Cette combinaison dangereuse permet aux acteurs de menace qui compromissent tout compte d’utilisateur au sein du locataire d’accéder immédiatement aux applications avec des bases utilisateur étendues, en développant leur surface d’attaque et en permettant un mouvement latéral au sein de l’organisation.

Bien qu’une application disposant d’une attribution ouverte mais d’une étendue d’approvisionnement appropriée (par exemple, les filtres basés sur le service ou les exigences d’appartenance au groupe) gère les contrôles de sécurité via la couche d’approvisionnement, les applications qui n’ont pas les deux contrôles créent des voies d’accès illimitées que les acteurs de menace peuvent exploiter. Lorsque les applications approvisionnent des comptes pour tous les utilisateurs sans restrictions d’affectation, les acteurs de menace peuvent abuser des comptes compromis pour effectuer des activités de reconnaissance, énumérer des données sensibles sur plusieurs systèmes ou utiliser les applications comme points intermédiaires pour d’autres attaques contre les ressources connectées. Ce modèle d’accès illimité est dangereux pour les applications disposant d’autorisations élevées ou connectées à des systèmes métier critiques. Les acteurs des menaces peuvent utiliser n’importe quel compte d’utilisateur compromis pour accéder aux informations sensibles, modifier des données ou effectuer des actions non autorisées autorisées par l’application. L’absence de contrôles d’affectation et d’étendue d’approvisionnement empêche également les organisations d’implémenter une gouvernance d’accès appropriée. Sans gouvernance appropriée, il est difficile de suivre qui a accès aux applications auxquelles l’accès a été accordé, et si l’accès doit être révoqué en fonction des modifications de rôle ou de l’état de l’emploi. En outre, les applications avec de larges étendues d’approvisionnement peuvent créer des risques de sécurité en cascade où un seul compte compromis fournit l’accès à un écosystème entier d’applications et de services connectés.

Action de correction

Limiter le nombre maximal d’appareils par utilisateur à 10

Le contrôle de la prolifération des appareils est important. Définissez une limite raisonnable sur le nombre d’appareils que chaque utilisateur peut inscrire dans votre instance Microsoft Entra ID. La limitation de l’inscription des appareils maintient la sécurité tout en permettant la flexibilité de l’entreprise. Microsoft Entra ID permet aux utilisateurs d’inscrire jusqu’à 50 appareils par défaut. La réduction de ce nombre à 10 réduit la surface d’attaque et simplifie la gestion des appareils.

Action de correction

Les stratégies d’accès conditionnel pour les stations de travail à accès privilégié sont configurées

Si les activations de rôles privilégiés ne sont pas limitées aux stations de travail d’accès privilégié dédiées(PW), les acteurs de menace peuvent exploiter les appareils de point de terminaison compromis pour effectuer des attaques d’escalade privilégiées à partir de stations de travail non managées ou non conformes. Les stations de travail de productivité standard contiennent souvent des vecteurs d’attaque tels que la navigation web illimitée, les clients de messagerie vulnérables au hameçonnage et les applications installées localement avec des vulnérabilités potentielles. Lorsque les administrateurs ont activé des rôles privilégiés à partir de ces stations de travail, les acteurs des menaces qui obtiennent un accès initial par le biais de programmes malveillants, d’exploits de navigateur ou d’ingénierie sociale peuvent ensuite utiliser les informations d’identification privilégiées mises en cache localement ou détourner les sessions authentifiées existantes pour élever leurs privilèges. Les activations de rôles privilégiés accordent des droits d’administration étendus sur l’ID Microsoft Entra et les services connectés, afin que les attaquants puissent créer de nouveaux comptes d’administration, modifier des stratégies de sécurité, accéder aux données sensibles sur toutes les ressources organisationnelles et déployer des programmes malveillants ou des portes dérobées dans l’environnement pour établir un accès persistant. Ce mouvement latéral d’un point de terminaison compromis vers des ressources cloud privilégiées représente un chemin d’attaque critique qui contourne de nombreux contrôles de sécurité traditionnels. L’accès privilégié apparaît légitime lorsqu’il provient de la session d’un administrateur authentifié.

Si cette vérification réussit, votre locataire dispose d’une stratégie d’accès conditionnel qui restreint l’accès au rôle privilégié aux appareils PAW, mais ce n’est pas le seul contrôle requis pour activer entièrement une solution PAW. Vous devez également configurer une stratégie de configuration et de conformité des appareils Intune et un filtre d’appareil.

Action de correction

  • Last updated on