Azure AD : Si vous n’avez pas implanté ces 18 mesures de sécurité : vous être potentiellement à risque.



L’Agence pour la cybersécurité et la sécurité des infrastructures (CISA) a rédigé en octobre 2022, 18 mesures qui nous devrions tous prendre en considération pour sécuriser les accès aux ressources Azure Active Directory et M365. Si le Microsoft Sécure Score est un outil intéressant et que vous avez peut-être déjà utilisé, je vous invite à lire attentivement ces 18 points de sécurité.

A propos de CISA

La Cybersecurity and Infrastructure Security Agency (CISA) dirige l’effort national américain visant à comprendre, gérer et réduire les risques pour les infrastructures physiques et cybernétiques. Ils mettent en relation les parties prenantes de l’industrie et du gouvernement entre elles et avec des ressources, des analyses et des outils pour les aider à renforcer leur propre sécurité et leur résilience en matière de cybercommunications et d’infrastructures physiques.

Bonne introspection 
Laurent TERUIN

Pour une meilleure lecture le document en PDF

 

Descriptions

Stratégies

Licences
Requises

1

L’authentification héritée DOIT être bloquée.

Bloquez les protocoles d’authentification existants à l’aide d’une politique d’accès conditionnel. L’authentification traditionnelle ne prend pas en charge l’authentification multifactorielle (MFA), qui est nécessaire pour minimiser l’impact du vol des informations d’identification des utilisateurs.

L’authentification traditionnelle DOIT être bloquée

N/A

2

Les utilisateurs à haut risque DOIVENT être bloqués

Azure AD Identity Protection utilise divers signaux pour détecter le niveau de risque de chaque utilisateur et déterminer si un compte a probablement été compromis. Les utilisateurs qui sont considérés comme présentant un risque élevé doivent être bloqués pour accéder au système via l’accès conditionnel jusqu’à ce qu’un administrateur remédie à leur compte. Une fois qu’une politique d’accès conditionnel respective avec un blocage est mise en œuvre, si un utilisateur à haut risque tente de se connecter, il reçoit un message d’erreur avec des instructions pour contacter l’administrateur afin de réactiver son accès.

Les utilisateurs détectés comme présentant un risque élevé DOIVENT être bloqués.
– Une notification DOIT être envoyée à l’administrateur lorsque des utilisateurs à haut risque sont détectés.

Nécessite une licence AAD P2 [Azure Active Directory].

3

Les connexions à haut risque DOIVENT être bloquées

Azure AD Identity Protection utilise différents signaux pour détecter le niveau de risque de chaque connexion d’utilisateur. Les ouvertures de session détectées comme présentant un risque élevé doivent être bloquées via l’accès conditionnel.

Les inscriptions détectées comme étant à haut risque DOIVENT être bloquées.

Nécessite une licence AAD P2.

4

Phishing-Resistant Multifactor Authentication SHALL Be Required for All Users

L’authentification multifactorielle résistante au phishing protège contre les attaques de phishing sophistiquées. Conscient du risque important que représentent ces attaques, l’Office of Management and Budget (OMB) demande aux agences fédérales de mettre en place une authentification résistante au phishing.
Cependant, l’AMF (Authentification Muli Factorielle) résistante au phishing n’est pas toujours immédiatement disponible, en particulier sur les appareils mobiles. Lorsque l’AMF résistante au phishing n’est pas encore disponible, l’organisation doit adopter une méthode d’AMF parmi la liste ci-dessous. Les organisations doivent passer à une méthode AMF résistante au phishing dès que possible afin de se conformer à cette politique et de faire face à la menace de sécurité critique que représentent les attaques de phishing modernes.

Le MFA DOIT être requis pour tous les utilisateurs.
– Un MFA résistant au phishing DOIT être utilisé pour tous les utilisateurs.
o Méthodes résistantes au phishing :


Carte fédérale de vérification d’identité personnelle (PIV) (authentification basée sur un certificat [CBA] d’Azure AD).
Clé de sécurité FIDO2.
Windows Hello for Business.
Carte PIV fédérale (fédérée à partir de l’Active Directory de l’agence ou d’un autre fournisseur d’identité).

– S’il n’est pas possible d’utiliser une méthode MFA résistante au phishing, une méthode MFA de la liste ci-dessous DOIT être utilisée en attendant :

o Microsoft Authenticator (notifications push).
o Microsoft Authenticator (Phone Sign-in) (également appelé Passwordless Sign-in).


Lors de l’utilisation de Microsoft Authenticator :
– La correspondance des numéros DOIT être activée.
– Les contextes supplémentaires DOIVENT être activés.
o Jetons logiciels – Mot de passe à usage unique (OTP) – Cette option est généralement mise en œuvre à l’aide d’applications d’authentification par téléphone mobile.
o Jetons matériels OTP.
SMS ou voix comme méthode MFA NE DOIT PAS être utilisé.

N/A

5

Les journaux d’Azure AD DOIVENT être collectés

Configurez Azure AD pour envoyer les journaux critiques au SIEM (Security Information and Event Management) centralisé de l’agence et au système d’analyse central du CISA afin qu’ils puissent être audités et interrogés. Configurez Azure AD pour envoyer les journaux à un compte de stockage et les conserver pour le cas où une réponse à un incident serait nécessaire.

Les journaux critiques suivants DOIVENT être envoyés au minimum : AuditLogs, SignInLogs, RiskyUsers, UserRiskEvents, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ADFSSignInLogs, RiskyServicePrincipals et ServicePrincipalRiskEvents.
– Si des identités gérées sont utilisées pour les ressources Azure, incluez également le type de journal ManagedIdentitySignInLogs.
– Si le service d’approvisionnement Azure AD est utilisé pour fournir des utilisateurs à des applications de type logiciel-service ou à d’autres systèmes, inclure également le type de journal ProvisioningLogs.
– Les journaux DOIVENT être envoyés au centre d’opérations de sécurité [SOC] de l’agence à des fins de surveillance.

N/A

6

Seuls les administrateurs doivent être autorisés à enregistrer des applications tierces.

Assurez-vous que seuls les administrateurs peuvent enregistrer les applications tierces qui peuvent accéder au Tenant.

Seuls les administrateurs DOIVENT être autorisés à enregistrer des applications tierces.

N/A

7

Les utilisateurs non administrateurs DOIVENT être empêchés de donner leur consentement à des applications tierces.

Assurez-vous que seuls les administrateurs peuvent consentir à des applications tierces et que seuls les administrateurs peuvent contrôler les autorisations accordées. Un workflow de consentement de l’administrateur peut être configuré dans Azure AD ; sinon, les utilisateurs seront bloqués lorsqu’ils essaieront d’accéder à une application qui nécessite des autorisations pour accéder aux données de l’organisation. Développez un processus d’approbation et de gestion des applications tierces.

Seuls les administrateurs DOIVENT être autorisés à consentir à des applications tierces.

– Un flux de travail pour le consentement des administrateurs DOIT être configuré.

– Les propriétaires de groupes NE DOIVENT PAS être autorisés à consentir à des applications tierces.

N/A

8

Les mots de passe NE DOIVENT PAS expirer

Veillez à ce que les mots de passe des utilisateurs n’expirent pas. Le National Institute of Standards and Technology (NIST) et Microsoft mettent tous deux l’accent sur l’AMF car ils indiquent que les changements de mot de passe obligatoires rendent les comptes des utilisateurs moins sûrs.

Les mots de passe des utilisateurs NE DOIVENT PAS expirer.

N/A

9

La durée de la session DOIT être limitée

Pour réduire le risque de vol d’informations d’identification pendant les sessions des utilisateurs, configurez la fréquence de connexion à une période de temps limitée.

La fréquence de connexion DOIT être configurée à 12 heures.

N/A

10

Les sessions du navigateur NE DOIVENT PAS être persistantes.

Pour réduire le risque de vol d’informations d’identification pendant les sessions des utilisateurs, interdisez les sessions persistantes du navigateur.

Les sessions de navigation NE DOIVENT pas être persistantes.

N/A

11

Le nombre d’utilisateurs ayant les rôles de privilèges les plus élevés DOIT être limité.

L’administrateur global est le rôle privilégié le plus élevé dans Azure AD, car il fournit un accès illimité au locataire. Par conséquent, si le justificatif d’identité d’un utilisateur disposant de ces autorisations devait être compromis, cela présenterait de graves risques pour la sécurité du locataire. Limitez le nombre d’utilisateurs qui se voient attribuer le rôle d’administrateur global. Attribuez aux utilisateurs des rôles administratifs plus fins dont ils ont besoin pour accomplir leurs tâches au lieu de leur attribuer le rôle d’administrateur global.

Un minimum de deux utilisateurs et un maximum de quatre utilisateurs DOIVENT être dotés du rôle d’administrateur global.

N/A

12

Les comptes d’utilisateurs hautement privilégiés DOIVENT être réservés au cloud.

Affectez les utilisateurs qui doivent effectuer des tâches à haut niveau de privilège à des comptes Azure AD dans le nuage uniquement, afin de minimiser les dommages collatéraux d’une compromission d’identité sur site.

Les utilisateurs qui doivent être affectés à des rôles Azure AD hautement privilégiés DOIVENT être approvisionnés en comptes cloud-only distincts de l’annuaire sur site ou d’autres fournisseurs d’identité fédérés.
– Les rôles Azure AD intégrés suivants sont considérés comme hautement privilégiés au minimum. D’autres rôles intégrés qui sont considérés comme hautement privilégiés dans l’environnement de l’agence peuvent être ajoutés à cette liste :

Global Administrator
o Privileged Role Administrator
o User Administrator
o SharePoint Administrator
o Exchange Administrator
o Hybrid Identity Administrator
o Application Administrator
o Cloud Application Administrator

N/A

13

L’authentification multifactorielle DOIT être exigée pour les rôles hautement privilégiés.

Exiger que les utilisateurs effectuent un MFA pour accéder aux rôles hautement privilégiés. Cette configuration fournit une politique de secours pour appliquer l’AMF aux utilisateurs hautement privilégiés au cas où la politique principale d’accès conditionnel – qui exige l’AMF pour tous les utilisateurs – serait désactivée ou mal configurée.

Le MFA DOIT être requis pour l’accès des utilisateurs aux rôles hautement privilégiés.

o Reportez-vous à la déclaration de base Highly Privileged User Accounts SHALL be Cloud-Only pour obtenir une liste minimale recommandée de rôles intégrés Azure AD considérés comme hautement privilégiés.
Il est également possible de désigner des rôles intégrés supplémentaires qui sont considérés comme hautement privilégiés dans l’environnement de l’agence, en fonction de sa tolérance au risque.

N/A

14

Les utilisateurs assignés à des rôles hautement privilégiés NE DOIVENT PAS avoir de permissions permanentes.

N’affectez pas les utilisateurs à des rôles hautement privilégiés en utilisant des affectations de rôle actives permanentes. Au lieu de cela, affectez les utilisateurs à des affectations de rôles éligibles dans un système PAM et prévoyez une période d’expiration pour les affectations actives exigeant que les utilisateurs privilégiés réactivent leurs rôles hautement privilégiés à l’expiration. Remarque : bien que le système Azure AD PIM soit référencé dans les instructions de mise en œuvre, un service PAM tiers équivalent peut être utilisé à la place.

Les affectations actives permanentes de rôles NE DOIVENT PAS être autorisées pour les rôles hautement privilégiés. Les affectations actives DOIVENT avoir une période d’expiration.

o Reportez-vous à la déclaration de base, Highly Privileged User Accounts SHALL be Cloud-Only, pour obtenir une liste minimale recommandée de rôles intégrés Azure AD considérés comme hautement privilégiés. Il est également possible de désigner des rôles intégrés supplémentaires qui sont considérés comme hautement privilégiés dans l’environnement de l’agence, en fonction de sa tolérance au risque.
– Le provisionnement des utilisateurs dans des rôles hautement privilégiés NE DOIT PAS se faire en dehors d’un système PAM, tel que le service Azure AD PIM, car cela contourne les contrôles fournis par le système PAM.

 
15

L’activation de rôles hautement privilégiés devrait nécessiter une approbation.

Exiger l’approbation d’un utilisateur pour activer un rôle hautement privilégié, tel que celui d’administrateur global. Cela rend plus difficile pour un attaquant d’exploiter les informations d’identification volées d’utilisateurs hautement privilégiés et garantit que l’accès privilégié est surveillé de près.
Remarque : bien que le service Azure AD PIM soit mentionné dans les instructions de mise en œuvre, un service PAM tiers équivalent peut être utilisé à la place.

L’activation de rôles hautement privilégiés DEVRAIT être approuvée.

 
16

L’attribution et l’activation de rôles hautement privilégiés DOIVENT être surveillées.

Étant donné que de nombreuses cyberattaques s’appuient sur les accès privilégiés, il est impératif de surveiller de près l’attribution et l’activation des rôles hautement privilégiés pour détecter les signes de compromission. Créez des alertes qui se déclenchent lorsqu’un rôle hautement privilégié est attribué à un utilisateur et lorsqu’un utilisateur active un rôle hautement privilégié.

Remarque : bien que le service Azure AD PIM soit référencé dans les instructions de mise en œuvre, un service PAM tiers équivalent peut être utilisé à la place.

Les attributions de rôles hautement privilégiés éligibles et actifs DOIVENT déclencher une alerte.
o Reportez-vous à la déclaration de base Highly Privileged User Accounts SHALL be Cloud-Only pour obtenir une liste minimale recommandée de rôles intégrés Azure AD considérés comme hautement privilégiés. Il est également possible de désigner des rôles intégrés supplémentaires qui sont considérés comme hautement privilégiés dans l’environnement de l’agence, en fonction de sa tolérance au risque.
– L’activation par l’utilisateur du rôle d’administrateur global DOIT déclencher une alerte.
– L’activation par l’utilisateur d’autres rôles hautement privilégiés DEVRAIT déclencher une alerte.
o Remarque : des alertes peuvent également être configurées pour l’activation par l’utilisateur d’autres rôles hautement privilégiés, mais notez que si les utilisateurs activent fréquemment ces autres rôles, cela peut entraîner un nombre important d’alertes. Par conséquent, pour ces autres rôles, il peut être prudent de configurer une boîte aux lettres de surveillance distincte de celle configurée pour les alertes associées au rôle d’administrateur global. Cette boîte aux lettres distincte serait conçue pour stocker les alertes à des fins de « révision si nécessaire » par rapport à la boîte aux lettres configurée pour le rôle d’administrateur global, qui devrait être surveillée de près puisque ce rôle est sensible.

 
17

Les dispositifs gérés devraient être requis pour l’authentification.

Exiger que les utilisateurs se connectent à M365 à partir d’un périphérique géré à l’aide d’un accès conditionnel. Les agences qui mettent en œuvre un environnement hybride Azure AD utiliseront probablement l’option de contrôle d’accès conditionnel nommée Hybrid Azure AD joined, tandis que les agences qui utilisent des appareils qui se connectent directement au cloud et ne rejoignent pas un AD sur site utiliseront l’option de contrôle d’accès conditionnel nommée Require device to be marked as compliant.


Note sur l’accès des utilisateurs invités : cette politique d’accès conditionnel aura un impact sur l’accès des invités au Tenant car les utilisateurs invités devront s’authentifier à partir d’un appareil géré, comme les utilisateurs Azure AD ordinaires.
Pour les utilisateurs invités, l’organisation qui gère leur Tenant d’origine est responsable de la gestion de leurs appareils et le locataire de ressources doit être configuré pour faire confiance aux demandes d’appareils du Tenant d’origine, sinon les utilisateurs invités seront bloqués par la politique.

Les dispositifs gérés DEVRAIENT être requis pour l’authentification.

 
18

L’accès des utilisateurs invités devrait être limité

Assurez-vous que seuls les utilisateurs disposant de privilèges spécifiques peuvent inviter des utilisateurs invités au Tenant et que les invitations ne peuvent être envoyées qu’à des domaines externes spécifiques. Assurez-vous que les utilisateurs invités ont un accès limité aux objets de l’annuaire Azure AD.

Seuls les utilisateurs ayant le rôle d’invité devraient être en mesure d’inviter des utilisateurs invités.
– Les invitations ne devraient être autorisées que pour des domaines externes spécifiques, autorisés par l’agence à des fins commerciales légitimes.
– Les utilisateurs invités devraient avoir un accès limité aux objets de l’annuaire Azure AD.

 

Votre commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s