Conditionnal Access - Sécuriser les Accès Admins aux portails Azure ?
Quelle stratégie adopter pour sécuriser les accès Admins à Azure ?
Il existe plusieurs outils et différentes solutions à disposition dans Azure pour sécuriser les accès aux différents portails d’Azure, notamment pour les administrateurs et les rôles à privilèges.
Voyons ensemble ce qu’il est possible de faire, et essayons de dégager les bonnes pratiques.
-
Restreindre l’accès au portail Azure pour les non Administrateurs
Pour commencer, une solution simple, il est facile de limiter l’accès au portail Azure pour les non administrateur
Le résultat pour un utilisateur standard est donc celui-ci lors de l’accès au portail Azure AD:
- Noter que le portail Entra sera lui aussi affecté
Est ce qu’on est tranquille ? Non … nous avons seulement bloqué les accès via GUI, mais un utilisateur standard sera toujours capable d’utiliser les modules powershell pour interroger le Tenant.
-
Restreindre les accès Azure AD via Powershell pour les non Administrateurs
Powershell MSOnline
Ok, MSOnline n’est pas le module PS le plus récent, mais il fonctionne toujours.
Si l’on veut bloquer pour les Users standards l’utilisation de MSOnline, il est possible de vérifier certains paramètres:
et de changer ceci:
Install-Module MSOnline
Connect-MsolService
Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled $false
Powershell AzureAD
Concernant le module Powershell AzureAD, la procédure est un peu différente, Microsoft fournit un script pour nous aider à faire cela:
L’idée étant de faire un “Block PowerShell for everyone except a list of admins”:
Blocking PowerShell for EDU Tenants - School Data Sync | Microsoft Learn
Powershell & GraphAPI
Idem, pour l’accès à Graph via Powershell, un autre script sur le même principe est fourni:
-
“Conditional Access” & “Microsoft Azure Management” Application
Le "Conditional Access" d'Azure est un service de gestion des accès qui permet de contrôler l'accès aux applications et aux ressources de votre organisation en fonction de certaines conditions.
Vous pouvez définir des règles qui spécifient les conditions d'accès, telles que la localisation géographique, l'appartenance à un groupe, l'appareil utilisé, le niveau de risque de connexion, l’application utilisée, etc.
Lorsqu'un utilisateur tente d'accéder à une ressource protégée par le "Conditional Access", les conditions d'accès sont évaluées en temps réel.
Si l'utilisateur ne remplit pas les conditions définies, l'accès est refusé ou conditionné à la satisfaction des conditions.
“Microsoft Azure Management” est une application Azure qui regroupe un certain nombre de services:
Azure Resource Manager
Azure portal (+Microsoft Entra admin center)
Azure Data Lake
Application Insights API
Log Analytics API
et certaines dépendances:
Classic deployment model APIs
Azure PowerShell
Azure CLI
Azure DevOps
Azure Data Factory portal
Azure Event Hubs
Azure Service Bus
Azure SQL Database
SQL Managed Instance
Azure Synapse
Visual Studio subscriptions administrator portal
Microsoft IoT Central
il peut donc être utile de créer une CA pour bloquer ou limiter ces accès selon ses propres conditions:
Exemple: Bloquer ces Accès pour les non Admins + Nécessité d’avoir un poste “Compliant” pour les Admins
(NB: Il peut avoir plusieurs façon d’arriver au résultat souhaité)
Création d’une première CA pour bloquer les accès Users:
- Deny pour tous le monde:
- Excepté les Admins:
- Scopé sur l’Application “Azure Management”
- Grant = Bloqué:
Création d’une seconde CA pour bloquer autoriser les Admins sous certaines conditions:
- Sélection du scope des Admins:
- Scopé sur l’application “Microsoft Azure Management”
- Autoriser les accès depuis un poste Hybrid Join + Compliant + MFA
Ceci est simplement un exemple, mais il permet de démontrer ce qu’il est possible d’imaginer avec le “Conditional Access” pour protéger les accès de ses comptes à privilèges Azure.
-
“Conditional Access App Control” avec MCAS
Il est souvent demandé si MCAS peut être utilisé pour conditionner les accès aux différents portails Azure.
Si MCAS (intégré dans le portail Security maintenant) est un outil très puissant, ou il est possible d’aller assez loin dans le Conditional Access, ex:
- Ici je bloque mes utilisateurs hors de France, sans poste compliant, non membre d’un groupe “Administrators”, l’accès au portail Microsoft Admin.
- Je suis capable d’envoyer des notifications, de personnaliser mon message d’erreur.
C’est une solution idéale pour les applications que l’on veut protéger dans des scénarios avancés.
Toutefois ce n’est pas la bonne solution pour les portails d’administration Microsoft, d’abord parce qu’ils ne sont pas tous disponibles dans MCAS, ensuite, il est préférable de définir une stratégie globale pour ses administrateurs plutôt que par application.
-
Stratégie recommandée
Si chaque environnement est différent, voici une approche qui pourrait être recommandée.
Basez vous sur le “Conditional Accès” pour construire ceci:
Des baselines Users
CA - Baseline Users - Require MFA Registration from Trusted Location
- Il est nécessaire d’enroller tous les user pour MFA, mais aussi nécessaire que cela soit effectué depuis un réseau de confiance
CA - Baseline Users - Block Legacy Auth Clients (POP, IMAP and EWS)
- Il est fortement recommandé d'interdire les protocoles d’authentification legacy.
De très nombreuses attaques utilisent ceux- ci.
CA - Baseline Users - Require Compliant OR HAADJ Device
- Assurez vous que les Devices utilisés par tous vos utilisateurs soient, soit des PC joints au domaine et controler donc par GPO, soit Azure AD Join et contrôlés, flagués par intune comme Compliant
Des baselines Admins
Comme pour les utilisateurs standards, il est nécessaire pour vos Admins de contrôler encore une fois:
CA - Sensitive Roles - Require MFA Registration from Trusted Location
CA - Sensitive Roles - Block Legacy Auth Clients (POP, IMAP and EWS)
CA - Sensitive Roles - Require Compliant OR HAADJ Device
Ensuite,
CA - Sensitive Roles - Block on Any Risk
- Assurez vous que vos Admins soient automatiquement bloqués dès qu’Azure AD détecte un potentiel risque à l’authentification
CA - Sensitive Roles - Hourly Re-authentication and Block KMSI
- Assurez-vous que vos Admins ne puissent pas bénéficier du KMSI (cela fera l’objet d’un autre article) pour ne pas rendre les sessions persistantes.
- Assurez vous aussi que les sessions soient courtes, par exemple ici 1h
CA - Sensitive Roles - Ask MFA for All Apps
- Chaque accès Admins doit être validé par MFA, peu importe la condition.
Et pour finir avec cette liste de recommandation, il est nécessaire que les attributions de privilèges soient effectuées à travers PIM, mais cela fera l’objet d’un autre article.