Autrefois, il était normal que les utilisateurs Windows soient administrateurs locaux de leurs machines, pour une raison en particulier : ces droits d'administrateur étaient nécessaires pour exécuter des logiciels dans l'écosystème de développement de Microsoft Windows. L'introduction dans Windows 7 du contrôle du compte de l’utilisateur ou User Account Control (UAC), dont l’objectif à long terme était de supprimer cette obligation pour les développeurs, n’avait pas été très bien accueillie. Depuis, les gens comprennent mieux pourquoi il n’est plus possible de faire fonctionner ses machines avec des droits d'administrateur.

Un récent message posté sur Twitter par Sean Metcalf, fondateur et consultant en sécurité principal de Trimarc Security, offre de bons arguments pour expliquer aux récalcitrants pourquoi on ne peut plus faire fonctionner ses machines Windows avec des droits d'administrateur :

- Il est plus facile pour un attaquant de prendre pied sur un tel système en compromettant simplement ce compte. L'attaquant dispose alors de droits d'administrateur local et peut décharger le service LSASS (Local Security Authority Subsystem Service) et le SMA (Local Service Management Automation) pour récupérer plus d’identifiants.

- Cela rend la journalisation plus compliquée. Si tous les utilisateurs n'ont pas de droits d'administrateur local, on peut surveiller les activités suspectes d'accès privilégié en utilisant l'événement « authentifié comme administrateur local » (événement 4672). Si tous les utilisateurs sont des administrateurs, la surveillance de cet événement et des événements connexes ne sert à rien.

- Quand l'utilisateur a des droits d'administrateur local, un ransomware peut disposer de tous les accès dont il a besoin pour bloquer totalement le système.

- Si tous les postes de travail partagent le même mot de passe d'administrateur local, alors la compromission d'un seul compte d'utilisateur suffit pour compromettre tous les postes de travail. Et cela, en quelques minutes. La mise en place d’un mot de passe d'administrateur local ou Local Administrator Password Solution (LAPS) permet de résoudre ce problème.

Problèmes de sécurité de l'UAC

Cependant, compter sur l'User Account Control (UAC) sous Windows 7 et Windows 10 ne suffit pas. Les attaquants peuvent utiliser des outils comme l'UACMe pour accéder à un système. L'UACMe abuse de la porte dérobée intégrée de Windows AutoElevate. L'UAC n'est pas une barrière de sécurité. Comme l'a fait remarquer Raymond Chen, « l'UAC n'est pas un dispositif de sécurité. C'est un dispositif de commodité qui oblige les développeurs de logiciels à accorder leurs violons ». L'objectif de l’UAC était de faire en sorte que l’écosystème n’ait plus besoin de demander aux développeurs de disposer de droits d'administrateur. Car il faut toujours avoir à l’esprit que les attaquants sont plus aguerris que vous pour exploiter les faiblesses d’un système.

Sur Azure également, il est important de contrôler et de protéger les administrateurs. Au lieu de désigner des administrateurs locaux sur les postes de travail, il faut contrôler l’usage et la protection des administrateurs globaux. En août 2019, Microsoft avait constaté que seuls 8 % des comptes des administrateurs globaux étaient protégés par une authentification à plusieurs facteurs (MFA). Sans cette authentification, un attaquant peut mener une attaque par vaporisation de mots de passe pour s'approprier des privilèges d'administrateur global. Une autre préoccupation liée aux attaques est l'élévation des droits d'un administrateur global d'Office 365. Comme l'a écrit Sean Metcalf dans son blog, si un compte d’administrateur global Office 365 est compromis, l'attaquant peut basculer dans un rôle dit de « Gestion de l'accès aux ressources Azure ». Le fait de basculer cet accès dans la console d'administration ajoute le compte au rôle d'administrateur de l'accès utilisateur au modèle d’habilitation Azure RBAC (Role Based Access Control) à la racine (lequel contrôle tous les abonnements du tenant).

Pour mieux protéger le rôle d'administrateur global, il faut surveiller les changements apportés au rôle d'administrateur global d'Azure AD et appliquer une authentification à plusieurs facteurs (MFA) à tous les comptes ayant le rôle d'administrateur global. Il faut également s’assurer de disposer de la licence appropriée. Une licence Azure AD Premium 2 est nécessaire pour ajouter la gestion d'identité privilégiée ou Privileged Identity Management (PIM) Azure AD. On peut également obtenir un accès PIM avec une licence E5.

Activer la gestion d'identité privilégiée ou Privileged Identity Management (PIM)

Le PIM ajoute les protections de gestion d'accès privilégié ou Privileged Access Management (PAM) suivantes aux comptes d'administrateur global :

- Fournit un accès privilégié « Just in Time » (JiT) aux ressources AD et Azure.

- Attribue un accès limité dans le temps aux ressources en utilisant des dates de début et de fin.

- Exige une approbation pour activer les rôles avec privilèges.

- Applique le MFA pour activer n'importe quel rôle.

- Utilise une justification pour comprendre pourquoi les utilisateurs s'activent.

- Envoie des notifications quand les rôles avec privilège sont activés.

- Effectue des contrôles d'accès pour s'assurer que les utilisateurs ont toujours besoin de rôles.

- Télécharge l'historique des audits pour l'audit interne ou externe.

Comme l'indique Microsoft, « la gestion des accès privilégiés est activée en configurant des politiques qui spécifient un accès JiT pour les activités basées sur des tâches chez le tenant. Elle peut contribuer à protéger l’entreprise contre les violations qui pourraient exploiter les comptes d'administrateur avec privilèges existants avec un accès permanent aux données sensibles ou un accès aux paramètres de configuration critiques. Par exemple, il est possible de configurer une politique de gestion des accès privilégiés en exigeant une autorisation explicite pour accéder aux paramètres de la boîte aux lettres de votre tenant et les modifier ».

Pour activer PIM :

- Lancer le portail Azure.

- Aller à « Gestion d'identité privilégiée ».

- Aller dans « Rôles Azure AD Directory - Aperçu » et cliquer sur « Wizard ». L’assistant vous guidera tout au long du processus.

Il faut considérer PIM comme un processus d'approbation automatisé. Votre système doit s'assurer que seules les personnes qui devraient avoir accès à un processus y accèdent réellement. Chaque sous-administrateur d'un processus sera mandaté pour obtenir l'accès par le biais d'un processus d'approbation.

Définir les rôles dans PIM

Lors de la mise en place de la procédure d'approbation de gestion « Just in Time », il convient de vérifier le temps pendant lequel l'activation de l'accès restera en place. Maintenez cette durée à un niveau bas, mais pas trop, pour laisser le temps à vos administrateurs d'accomplir leurs tâches sans se dépêcher. Le PIM permet de suivre les utilisateurs avec des privilèges d’administration dans Azure AD, Office 365 et Microsoft Intune.

Configurer un MFA pour les utilisateurs Office 365

Enfin, il faut activer le MFA pour tous les utilisateurs Office/Microsoft 365, qu'ils aient ou non des droits d'administrateur ou d'administrateur global. Vous pouvez mettre en œuvre une authentification à deux facteurs avec différents outils comme des porte-clés ou des jetons physiques, une messagerie SMS, le rappel de numéros de téléphone ou une application d'authentification. Vous pouvez utiliser l'application d'authentification de Microsoft ou de Google comme jeton virtuel préféré. La clé devrait vous permettre de mettre en œuvre une authentification à plusieurs facteurs. Avec le MFA, votre compte a moins de 99,9 % de chances d'être compromis. Ce n’est pas infaillible, mais toute authentification à plusieurs facteurs vous met hors de portée de la plupart des attaques.