Consentement aux applications : fermer la porte aux attaques par octroi de consentement illicite

Comment fonctionne le consentement

Lorsqu'une application demande à accéder à des données au nom d'un utilisateur, Entra ID affiche une page de consentement listant les autorisations demandées : lire le profil, lire les courriels, accéder aux fichiers, conserver l'accès hors connexion. Si l'utilisateur accepte, une autorisation déléguée est enregistrée dans l'annuaire et un principal de service est créé pour l'application dans le locataire.

Deux types d'autorisations coexistent :

• Délégées : l'application agit au nom de l'utilisateur connecté, dans la limite de ses propres droits. Un utilisateur peut y consentir pour lui-même si les paramètres le permettent.
• Application : l'application agit seule, sans utilisateur, sur l'ensemble du locataire. Seul un administrateur disposant du rôle adéquat peut les accorder.

Le consentement n'est donc pas un simple écran d'information : c'est un octroi de droits, enregistré, qui survit à la session qui l'a produit.

L'attaque par octroi de consentement illicite

Le scénario est connu et toujours efficace. L'attaquant enregistre une application multilocataire dans son propre locataire, lui donne un nom et un logo crédibles, puis envoie à ses cibles un lien vers la page de consentement Microsoft. La page est authentique : le domaine est bien celui de Microsoft, l'utilisateur s'authentifie normalement, MFA comprise. Il accepte des autorisations comme Mail.Read, Files.Read.All ou offline_access.

À partir de là, l'application dispose d'un jeton d'actualisation lui permettant de lire les données de l'utilisateur sans jamais connaître son mot de passe. Réinitialiser ce dernier ne change rien tant que l'autorisation existe. C'est ce qui rend l'attaque redoutable : elle contourne les défenses classiques de l'identité et laisse peu de traces visibles pour l'utilisateur.

Restreindre le consentement des utilisateurs

Les paramètres se trouvent dans Entra ID, sous Applications d'entreprise, Consentement et autorisations. Trois options principales sont proposées :

1. Ne pas autoriser le consentement des utilisateurs : toute nouvelle application nécessite un administrateur. C'est l'option la plus sûre, mais elle doit être accompagnée d'un flux de demande, sinon les équipes contourneront le dispositif.
2. Autoriser le consentement pour les applications d'éditeurs vérifiés, pour les autorisations sélectionnées : l'utilisateur ne peut consentir qu'aux autorisations classées « faible impact » par l'administrateur, et uniquement pour des éditeurs vérifiés ou des applications enregistrées dans le locataire. C'est le compromis recommandé par Microsoft.
3. Autoriser le consentement pour toutes les applications : c'est la situation que nous rencontrons encore trop souvent, et celle qu'il faut quitter.

Si vous choisissez la deuxième option, définissez soigneusement la classification des autorisations : en pratique, se limiter à openid, profile, email et User.Read couvre l'essentiel des connexions par authentification unique sans exposer de données sensibles. Les intitulés et options évoluent régulièrement : vérifiez l'état actuel dans votre locataire.

Le flux de consentement administrateur

Bloquer le consentement sans proposer d'alternative crée de la frustration et des demandes informelles. Le flux de consentement administrateur permet à l'utilisateur de demander l'accès directement depuis la page de consentement, avec une justification. Les demandes arrivent chez des réviseurs désignés, qui peuvent approuver, refuser ou bloquer l'application.

• Désignez plusieurs réviseurs, dont au moins un capable d'évaluer le risque des autorisations demandées.
• Fixez une durée d'expiration des demandes raisonnable et activez les notifications.
• Documentez des critères d'approbation : éditeur vérifié, autorisations proportionnées au besoin, existence d'un responsable métier.

Passer en revue les autorisations existantes

Restreindre le consentement ne fait rien pour le passé. Il faut inventorier les autorisations déjà accordées. Le portail permet de les consulter application par application, mais pour un inventaire complet, Microsoft Graph est plus efficace : les autorisations déléguées sont exposées par les oauth2PermissionGrants, les autorisations d'application par les attributions de rôles d'application des principaux de service.

Ce que nous recherchons en priorité :

• les applications non vérifiées disposant d'un accès à la messagerie, aux fichiers ou à l'annuaire ;
• les applications auxquelles un seul utilisateur a consenti, au nom peu explicite ou récemment apparues ;
• les consentements donnés « pour toute l'organisation » par un administrateur sans trace de validation ;
• les applications inutilisées depuis longtemps mais conservant leurs autorisations.

Le journal d'audit enregistre chaque événement « Consentement à l'application » : c'est une source à surveiller en continu, pas seulement lors d'un audit. Selon vos licences, la gouvernance des applications de Microsoft Defender for Cloud Apps peut aussi détecter des comportements anormaux d'applications OAuth.

Ce qu'un audit vérifie

• Le paramètre de consentement des utilisateurs et la classification des autorisations « faible impact ».
• L'existence et le fonctionnement du flux de consentement administrateur, avec ses réviseurs.
• L'inventaire des autorisations déléguées et d'application accordées, en particulier aux applications non vérifiées.
• Les consentements à l'échelle de l'organisation et leur justification.
• La surveillance des événements de consentement dans les journaux d'audit.
• La procédure de révocation : suppression des autorisations, révocation des sessions et désactivation du principal de service.