Protéger ses comptes sous Azure

Azure propose un ensemble d’outils pour sécuriser vos ressources et en particulier vos comptes utilisateurs. La tête de pont de ces outils est bien entendu Azure Active Directory (AAD) capable de  protéger tout type de ressources et pas seulement les ressources Azure. L’outil le plus connu est MFA (Multi Factor Authentification).

Dans la terminologie un facteur désigne une couche de sécurité.

L’idée est que la sécurité ne doit pas reposer sur une seule couche, mais plusieurs. Il ne suffira pas de voler votre carte bleue et son code pour l’utiliser si une confirmation depuis un smartphone est exigée.

On classe les facteurs dans 3 catégories :

• Quelque chose que je connais
  mot de passe, ID, question de sécurité par exemple
• Quelque chose que je possède
  Mon smartphone, clef cryptée, un badge par exemple
• Quelque chose que je suis
  Empreinte digitale, voix, visage…

MFA impose de choisir au moins deux facteurs ce qui ajoute une difficulté supplémentaire à l’attaquant.

Microsoft Azure propose plusieurs options (que vous retrouverez ici) certaines gratuites, d’autres payantes pour activer MFA. On notera en particulier que depuis 2019 MFA est disponible gratuitement sur tous les comptes et pas juste Global Administrator.

Nous n’allons pas entrer dans les détails ici, mais vous trouverez facilement des tutoriels qui vous aideront à la mise en œuvre pratique de MFA, comme celui-ci.

MFA est un outil puissant et représente le minimum si l’on est sérieux. Ce n’est toutefois pas la seule option.

Les versions Premium d’Azure AD ouvrent la porte vers des options très puissantes capables de gérer très finement les risques de compromissions, de surveiller les accès et les contrôler totalement.

Nous avons par exemple Azure Conditional Acces qui agit comme une fonction IF/THEN vis-à-vis d’un contexte :

Chaque accès authentifié à des données ou des applications protégées par Azure AD est analysé. Un certain nombre de signaux sont relevés : utilisateur, emplacement, application, risque… C’est le volet IF.

Selon les résultats collectés, une policy est appliquée qui se traduit par une des 2 actions suivantes (THEN) : Bloquer / Autoriser

Autoriser est une conséquence possible, mais elle peut être sous contrainte : MFA obligatoire et imitation à certains périphériques et/ou certaines zones géographique.

Azure Conditional Access offre d’autres services complémentaires comme :

• Fréquence d’authentification
  Fréquence entre deux demandes d’authentification. Il peut paraître pénible de refaire une authentification complète à chaque fois que l’on accède à une application, on peut choisir de conserver sur une certaine durée les jetons d’authentification
• Persistance d’une session
  garde-t-on la connexion après fermeture du navigateur.
• Affichage des conditions d’utilisation

Retrouvez un tutoriel complet ici

Si vous remontez un peu en arrière, vous avez peut-être remarqué qu’un des signaux analysé par Azure Conditional Access est le risque utilisateur. De quel risque parle-t-on ?

Le risque est l’évaluation faite par Azure AD Identity Protection (IdP) de votre utilisateur. Le service associe chaque utilisateur à un score lié au niveau de confiance qu’il est possible de lui attribuer : High, Medium ou Low.

Ce score peut déclencher une policy ou bien être un signal pour Azure Conditional Acces ou un outil de SIEM (Security Information and Event Management) tiers.

Microsoft ne fournit pas de détails sur l’évaluation, mais on sait que 2 types de risques sont analysés :

• Risque utilisateur
• Risque à la connexion

Typiquement on rencontrera les anomalies suivantes : connexion depuis un lieu inhabituel, IP anonyme (VPN) ou Credentials compromis. Et bien d’autres.

Un des aspects intéressants d’IdP est qu’il peut évoluer dynamiquement. IdP s’appuie sur l’analyse en continu du comportement de chaque compte. Une IA va déterminer un profil normal de connexion et d’utilisation pour construire son analyse.

Par ailleurs, Microsoft est en effet partenaire d’un certain nombre d’organisations qui aident à sécuriser le Web. En tant que fournisseur d’identité et de service Web, Microsoft dispose également d’une base de données conséquente sur la façon dont évolue les pratiques dangereuses et les attaques informatiques. Ces données peuvent aller de l’analyse comportementale effectuée par des IA à l’exploitation de bases de données publique de comptes piratés ou d’IP douteuses.

Vous connaissez sans doute le site HaveIBeenPwned qui effectue ce genre de travail.

IdP est donc un outil très puissant et très utile surtout pour des utilisateurs qui font du roaming.

Vous trouverez ici aussi un tutoriel complet sur IdP.

Votre organisation fait appel à divers prestataires et certaines ressources sont plus sensibles que d’autres ? On peut être tenté de donner à ces agents des droits très élevés pour qu’ils effectuent leur travail. De ce fait ces comptes deviennent très vulnérables.

On constate souvent que l’on a rarement le besoin d’accéder en permanence à des zones sensibles. L’accès est le plus souvent ponctuel, par exemple quelques heures.

Dans ces situations on peut penser à PIM (Azure Privileged Identity Management). PIM est un service Azure capable d’accorder des permissions à un compte sur une période seulement.

Un utilisateur (1) souhaite activer un rôle admin géré par PIM. Pour cela il se rend dans le portail PIM et réclame l’activation du rôle.

Selon les réglages effectués, on va exiger une authentification MFA (2) et/ou une validation de la demande par des approbateurs (3).

Si tout se passe bien le rôle est activé pour l’utilisateur (4) pour une durée limitée (5). Une alerte de sécurité est émise vers les personnes gérant PIM.

L’environnement PIM propose en outre des fonctions :

• D’alertes lorsqu’une élévation de privilège est demandée
• D’audit des différents événements PIM
• De reporting

On parle ici d’utilisateur. Pour l’instant PIM ne propose pas de support pour les comptes de service.

PIM définit deux types de rôles : Eligible / Actif. Au sein de ces catégories, ces rôles peuvent être permanents ou temporaires.

Pour un rôle éligible, l’élévation de privilège se produit au moment où l’utilisateur en a besoin. C’est un rôle JIT (Just in Time). La demande est explicite et s’effectue depuis le portail Azure.

Un rôle actif est toujours associé à l’entité en faisant la demande. On n’a pas besoin de l’activer comme pour le rôle éligible.

Dans tous les cas, l’activation du rôle peut être contrôlée dans le temps. Pour un rôle temporaire, on fournit une date de début et une date de fin de l’activation. Pour un rôle permanent, il n’y a pas de limite dans le temps. Selon que le rôle soit actif ou éligible, les choses se font de façon un peu différente.

Prenons par exemple le cas d’un rôle éligible temporaire :

L’utilisateur est éligible temporairement au rôle durant une période de 2 semaines max. Durant cette période il peut activer autant de fois qu’il le souhaite son rôle pour une période donnée. Au-delà des 2 semaines, il ne peut plus faire d’élévation de privilège. Notons toutefois que le portail permet de réclamer une extension, il faudra suivre un workflow d’approbations.

Observez bien qu’entre les périodes d’activation l’utilisateur n’a pas le rôle, il redevient un compte normal. Si le compte est compromis, l’attaquant ne pourra pas profiter des avantages du rôle de façon indue.

Vous pouvez retrouver un tutoriel ici qui vous donnera toutes les clefs pour comprendre plus en détail le fonctionnement de PIM.

Écrit par Frédéric DE LENE MIROUZE