Enjeux et trajectoires de transformation

Livre Blanc

Sécurisation de l’Active Directory et d’Azure AD

2

IntroductionDepuis plus de 20 ans qu’il existe, le service Active Directoryest devenu un standard du marché, présent dans quasimenttous les systèmes d’information des organisations. Deuximportantes tendances l’ont remis sur le devant de la scèneces dernières années.

La première découle de la forte exposition de ce composant àla menace cyber. S’agissant de la pierre angulaire du systèmed’information en matière de droits et de comptes à privilèges,l’Active Directory constitue une cible prioritaire pour lesattaquants, qui cherchent à obtenir un accès large au systèmed’information en le compromettant. Ils peuvent ainsi l’utiliserpour déployer des logiciels malveillants ou encore pouraccéder à des informations, avant de les faire fuiter. De vastesprojets de remédiation ont ainsi été lancés ces dernièresannées, par de nombreuses organisations, pour y faire face.

La seconde découle de l’accroissement de l’usage de servicescollaboratifs, brusquement accéléré par l’explosion durecours au télétravail. Pour déverrouiller tous les nouveauxusages du modern workplace, la gestion des utilisateurs aétendu son champ d’action pour intégrer le périmètre dans lecloud, grâce à Azure AD. Dans la majorité des cas, il ne s’agitpas d’une bascule d’un tout on-premises vers un tout cloud,mais plutôt d’une extension de l’existant au traversd’architectures hybrides. Ce mouvement nécessite une priseen compte des enjeux de sécurité, pour ne pas exposerl’organisation.

Microsoft et Wavestone se sont associés pour analyser lestendances observées sur le terrain, lister les réflexions àmener et donner quelques clés et bonnes pratiques pourconduire les changements structurants.

Sommaire1

2

3

Quelle est la maturité rencontrée sur le terrain ?

Quelles trajectoires pour améliorer la situation ?

Comment faire face à une cyberattaque ?

Quelles architectures et quel bilan de la maturitécybersécurité ?

Retour d’expérience sur des attaques rencontrées par leCERT-W

Enterprise Access Model

Sécuriser le Tier 0 et mettre en œuvre le plan de contrôle

Connaitre les difficultés de la reconstruction d’Active Directorypour mieux anticiper la crise

Ne pas se contenter d’une simple reconstruction de l’AD

Sécuriser sa souscription Azure AD

Migrer d’Active Directory vers Azure Active Directory

Améliorer sa posture de sécurité

4

5

11

19

20

25

Conclusion

33

43

52

55

59

60

54

Ce chapitre vise à présenter le niveau actuelde sécurité rencontré pour l’Active Directoryet Azure AD.Nous reviendrons dans un premier temps surles grands types d’architecture rencontrés etles enjeux de sécurité, puis nous partageronsles enseignements tirés des attaquesrencontrées par le CERT Wavestone (CERT-W).

Quelle est la maturité rencontrée sur le terrain ?

5

Quelles architectures et quel bilan de la maturité cybersécurité ?Trois grands types d’architecturepeuvent être rencontrées :

Architecture AD on-premisesArchitecture historique de moinsen moins rencontrée chez lesclients (<10%). Il s’agitgénéralement de clients ayantdes enjeux forts de souveraineté.

Architecture hybride AD/AzureADCette architecture tirée parl’essor d’Office 365 estaujourd’hui majoritaire chez lesclients (80 à 95%). Des variationsd’implémentation existentcependant, en particulier sur lasynchronisation ou non des hashsde hashs des mots de passe.

Architecture 100% Azure ADPrésente uniquement pour denouvelles entités construites avecun prisme 100% numérique(<5%). Elle nécessite d’avoir unsystème d’information qui répondà un certain nombre de prérequis.

Active Directory on-premises ou le poids de l’histoire

L’Active Directory est organiséautour de domaines regroupés enune ou plusieurs forêts. Il n’estpas rare, pour des grandesorganisations, d’avoir plus de 100domaines ou forêts.Cette architecture complexes’explique par le poids del’histoire et les multiplestransformations subies parl’entreprise : fusions, acquisitions,réorganisations, etc.L’Active Directory n’étant pas vucomme une application« apportant de la valeur aumétier », l’intégration desnouveaux périmètres a étéréalisée en minimisant lesévolutions (moyen le moins cheret le plus rapide), sans réflexionglobale sur l’optimisation del’architecture. Des relations deconfiance entre domaines ouforêts ont été ajoutées, pourpermettre à un utilisateur d’êtrereconnu partout dans le SI.

Un faible niveau de sécuritéDans la majorité desorganisations, le maintien encondition de sécurité de l’ADpasse souvent uniquement parl’application des correctifs desécurité et le traitement del’obsolescence de l’OS.

« Seules 25% des authentifications sont encore réalisées on-premises »

« Le SI est compromis en moins de 24h dans 80% des audits réalisés » Wavestone, audits AD 2020

6

Les mises à jour fonctionnellessont quant à elles peu mises enœuvre, généralement parméconnaissance ou par craintedes impacts possibles suite àl’extension du schéma. Lesorganisations ne profitent doncpas des nouvelles fonctionnalités,permettant de limiter les risquesde sécurité (par exemple la miseen œuvre du groupe protectedusers, Authentication Silos etKerberos Armoring). De la mêmefaçon, trop rares sont lesorganisations à désactiver lesprotocoles obsolètes.

Il n’est pas rare d’avoir desorganisations avec des centainesde comptes Administrateurs dedomaine ou d’entreprise alorsque les bonnes pratiques etl’application du principe demoindre privilège signifieraientde les limiter à moins de 5. Cettesituation s’explique par ladifficulté à assurer la conduite duchangement (retirer des droitspeut être vu comme unerétrogradation ou unedépossession). Mais aussi lademande de comptes de servicesavec des droits excessifs pourfaciliter l’intégration d’unenouvelle application.

Les évolutions de l’architecture,en particulier la mise en œuvrede relations de confiance, ont étédéfinies uniquement sous leprisme fonctionnel sans évaluerles risques de propagation d’uneattaque entre les domaines et lesforêts. Wavestone rencontrerégulièrement pendant des auditsun domaine abandonné avec unerelation de confiancebidirectionnelle. Et c’est bien lui

qui définit le niveau global desécurité !De la même façon, la mise enœuvre d’Azure AD a visé àrépondre à des besoinsfonctionnels sans considérationde sécurité. Rares sont lesorganisations à avoir défini unprocessus de gestion descomptes à privilèges adapté auxparticularités d’Azure AD. Autreexemple, seuls 30%(*) descomptes administrateur général(ou Global Administrator) ontl’authentification multi-facteur(MFA) activée, alors que lafonctionnalité est native etgratuite.(*) Microsoft août 2021

Une prise de conscience récente des enjeux de sécuritéDans le contexte actueld'explosion des attaquesexploitant des défauts deconfiguration de l’AD, il n’est plusrare de voir le COMEX interrogerle DSI ou le RSSI sur le niveau desécurité de l’AD et valider desenveloppes de plusieurscentaines de milliers voiremillions d’euros pour mener desprojets de refonte et desécurisation.

« 53% des grandes entreprises ont un projet de sécurisation de l’AD » Baromètre CESIN 2021

7

Les projets de sécurisation del’AD sont lancés pour la vastemajorité mais les audits menéspar Wavestone, nous montrentque :

En effet, bien que les pratiquesd’administration aient pu évoluer,il reste bien souvent des défautsde configuration qui permettentde remonter au Tier 0 (conceptdétaillé dans le chapitre 2). Deschemins de compromission etd’élévation de privilèges peuventpar exemple se cacher dans desdroits d’accès (ACL) dangereusesconfigurées sur les objets du Tier0, ou subsister du fait de mauvaisusages des comptes à hautsprivilèges. Le modèle de sécuritéAD est détaillé au chapitre 2..

Une architecture 100% Azure AD, la cible pour tous ?Aucune grande organisation n’estaujourd’hui en mesure deremplacer totalement son AD on-premises par un service 100%porté par l’Azure AD. Peud’organisations sont en mesured’avoir un SI qui remplissel’ensemble des prérequistechnologiques pour faire cettetransformation (postes de travailgérés avec un MDM (MobileDevice Management) et AzureAD, absence d’applications

utilisant une authentificationNTLM (NT Lan Manager),Kerberos ou LDAP (LightweightDirectory Access Protocol),création des utilisateurs dans lecloud, etc.). L’usage d’un serviced’AD managé pourrait être uneoption pour assurer larétrocompatibilité sans avoir àgérer le Tier 0.

L’usage du cloud peut être vucomme une délégation àMicrosoft de la maitrise desrisques, mais elle n’est quepartielle. Les clients restentresponsables de la configurationde la plateforme, des identités etdes données. Malheureusement laprise de conscience reste faible.Pour rappel, un nouvelabonnement à la solution Teamss'accompagne de la créationd'une souscription Azure AD.

Il est important que lesorganisations prennentpossession des outils proposéspour piloter leur sécurité et quin’existaient pas on-premises (ilspeuvent néanmoins nécessiterdes niveaux de licence avancés).Le Secure Score (détaillé dans unfocus ci-après) - cible visé par lesorganisations - devrait être auminimum entre 60 et 70.

« Moins de 10% des clients ont correctement implémenté les bonnes pratiques de sécurité » Wavestone, audit AD 2020

32/100Secure score moyen34,6 score le plus élevé pour le secteur technologie24 score à la création d’une souscription Office 365 E3

88

Azure AD : un annuaire cloud

Azure Active Directory (AzureAD), lancé en novembre 2011, estune solution d’Identity as aService (IDaaS).

Azure AD, fournit auxorganisations les fonctionnalitéspour gérer l'authentification desapplications modernes (SAML etWS-Federation, OAuth2, OpenIDConnect et FIDO2).

Il ne s’agit pas d’Active Directorydans le Cloud mais bien d’unenouvelle solution.

Azure AD a été conçue sur unearchitecture cloud, basée sur desmicro-services, répartie surplusieurs zones géographiques.

Un tenant Azure AD estautomatiquement créé lorsqu'uneorganisation souscrit à un servicecloud de Microsoft, tel qu'Azureou bien Office 365.

Graph APIPour interroger et mettre à jourles objets de l'annuaire, Azure ADpropose une ApplicationProgramming Interface (API) quise nomme Graph API.

Graph API est une passerelleunifiant de nombreuses autres APIREST telles que celles d’ExchangeOnline, OneDrive, EndpointManager ou bien Security Graph.

Un remède miracle?Bien que la majorité des attaquescourantes cible aujourd’hui l’AD,

une migration vers Azure ADn’est pas pour autant un remèdemiracle. Azure AD simplifie lamise en œuvre del’authentification forte sans motde passe ou bien le contrôled’accès conditionnel basé sur lesrisques, cependant les comptes àprivilèges doivent toujours êtrefortement encadrés.

Il est impératif de mener à bienun projet de sécurisation pourmaitriser cette nouvelle brique etprofiter de la transformation pourpasser à des pratiquesd’administration à l’état de l’art.

En particulier, il est recommandé:/ D’auditer la configurationd’Azure AD, de validerrégulièrement les membres desrôles privilégiés ainsi que lesapplications autorisées à interagiravec Azure AD ;/ De développer des scénariosde détection spécifiques pourlimiter le temps pendant lequelles intrus demeurent invisiblesdans le SI.

FO

CU

S

345 MillionsAzure AD gère plus de 345 millions d'utilisateurs actifs chaque mois, avec une moyenne de 30 milliards de demandes d'authentification par jour.

99

NTLM, toujours le talon d'Achille de la sécurité ? NTLM (NT LAN Manager) estutilisé par les applications pourauthentifier les utilisateurs et,éventuellement, pour fournir unesécurité de session lorsquel'application le demande.Les protocoles NTLM sont desprotocoles d'authentificationobsolètes qui utilisent uneméthode de défi et réponse pourque les clients puissent prouvermathématiquement qu'ilspossèdent le condensat de motde passe, le hash NT. Les versionsactuelles et passées de Windowsprennent en charge plusieursversions de ce protocole, dontNTLMv2, NTLM ainsi que leprotocole LM.

Depuis Windows 2000, leprotocole Kerberos est leprotocole d'authentification pardéfaut. Cependant, si le protocoleKerberos n'est pas négocié pourune raison quelconque, alors lesapplications reliées à ActiveDirectory tenteront d’utiliser undes protocoles NTLM, sidisponible.Toutes les versions de NTLM sontvulnérables à des attaqueslargement documentées. Pourcette raison, le protocole NTLMn’est pas supporté dans AzureActive Directory, peut êtredésactivé dans Azure AD DS ainsique dans Active Directory.Au-delà d’un supportcryptographique faible, l'absenced'authentification du serveurpeut permettre à un attaquantd’usurper l’identité d’un serveur.Ainsi, les applications utilisantNTLM peuvent être vulnérables à

une attaque par « réflexion » : unattaquant peut détournerl’échange d'authentification d'unutilisateur vers un serveurlégitime et l'utiliser pours’authentifier sur un autreordinateur, voire sur l’ordinateurde l'utilisateur.

La suppression complète deNTLM dans un environnementaméliore indéniablement lasécurité en éliminant les attaquesde type PtH (Pass-The-Hash).Cependant, cela ne permet pasd’éliminer d’autres classesd’attaques, comme le vol de motsde passe en clair ou bien le vol detickets Kerberos, Ticket GrantingTicket (TGT).

Les organisations sontencouragées à mettre en œuvreKerberos ou à utiliser desprotocoles d’authentificationmodernes (OpenID Connect,SAML, etc.) pour leursapplications existantes, carMicrosoft ne prévoit aucuneamélioration du protocole NTLM.

Pourquoi NTLM est-iltoujours utilisé ?

NTLM est encore largementutilisé du fait d’applicationshistoriques qui n’ont pas évolué,mais aussi en raison demauvaises configurationsd’applications qui supportentpourtant Kerberos.

Le protocole NTLM n’est pas supporté dans Azure Active Directory.

NTLMNTLMv1NTLMv2 LM

FO

CU

S

1010

En finir avec NTLM – 4 étapes

Identifier tous les cas d’utilisation de NTLM

Activer le blocage global de NTLM avec une

stratégie d’exception

Isoler les applications ne pouvant évoluer et durcir la configuration de NTLM

Préparer les applications à utiliser le package

Negociate

21

34

Recenser les appareils et lesapplications liés à NTLM, lesclassifier et déterminer ce quidevra potentiellement être traitédans une stratégie d’exception.

Résoudre les problèmes decompatibilité (dont leremplacement de matériels et delogiciels), configurer lesapplications pour utiliser lepackage de sécurité Negociatepour laisser l’OS utiliser le meilleurprotocole d’authentificationdisponible et mettre en œuvre lesprérequis (Kerberos ou autres)

Bloquer l’utilisation de NTLM saufpour les applications et matérielsqui ne peuvent pas évoluer et quidevront être traités dans unestratégie d’exception (étape 4).

Isoler les appareils et lesapplications avec une logique desegmentation réseau. Durcir laconfiguration de NTLM etsuperviser les authentifications encontinue.

Il est déconseillé de bloquer sans discernement l’utilisation de NTLM, sansavoir au préalable cartographié les applications existantes et conduit uneanalyse d’impact.

FO

CU

S

Retour d’expérience sur des attaques rencontrées par le CERT-W

L’AD, au cœur de la menace rançongiciel et du mode opératoire des attaquantsAu cœur de la sécurité dessystèmes d’information, l’AD estaujourd’hui la cible privilégiéedes attaquants lors d’attaquesinformatiques d’envergure.Le benchmark 2020 du CERTWavestone est sans équivoque.

Ce constat est par ailleurspartagé par l’Agence Nationalede la Sécurité des Systèmesd’Information (ANSSI): L'analyse

des modes opératoires desattaques récentes met enévidence une recrudescence duciblage des annuaires ActiveDirectory. Ce constat s’expliquepar le rôle central joué par l’ADau sein des SI d’entreprise.L’obtention de privilèges ADélevés permet bien souvent à unattaquant de prendre le contrôlede l’ensemble de l’écosystèmeWindows, voire de rebondir surd’autres environnements autravers des postes de travail dedéveloppeurs etd’administrateurs. Suite à cettecompromission, des donnéessensibles peuvent être exfiltréesou les activités et servicesmétiers perturbés durablement,au travers d’attaques parrançongiciels notamment.Les années 2019 et 2020 ont defait été marquées par unaccroissement sans précédentdes attaques par rançongiciel.

11

« L’AD a été compromis dans 95% des crises cyber traitées par le CERT-W »

La grande majorité desinterventions de crise du CERT-W sur l’année 2020, toussecteurs confondus, visait àrépondre à des déploiements derançongiciels.

Constat partagé par l’équipe deréponse à incidents Microsoft(Detection and Response Teamou DART).Fait relativement récent, une partimportante des demandes de

paiement de rançons estaujourd’hui doublement axée surla restauration des donnéeschiffrées et la non-divulgation dedonnées exfiltrées. Cettecombinaison de blocage du SI etde la fuite de données s'estdéveloppée progressivement dufait des actions du groupe Mazeen Amérique du Nord.

Les possibilités d’exécution decode distribué offertes par l’AD,comme les stratégies de groupe(GPO) ou les droitsd’administration locaux sur lesmachines jointes à l’AD, sontexploitées par les attaquantspour déployer les chargesentraînant le chiffrement dessystèmes. Parfois employéessimultanément, les GPO et lesaccès directs aux systèmes viades outils d’administrationlégitimes, permettent unchiffrement de l’ensemble duparc Windows en l’espace dequelques heures.

Les sauvegardes sont-elles à l’abri des attaquants ?

S'il est encore rare que les infrastructures de sauvegarde soient cibléesspécifiquement, elles peuvent faire partie des dommages collatéraux desattaques. En l’absence d’une infrastructure de sauvegarde dédiée et nonintégrée à la forêt AD de production, le déploiement de la chargechiffrante à l’échelle du parc entraîne un chiffrement des systèmes desauvegarde.

Uniquement pour une minorité des attaques investiguées par le CERT-W,les groupes d’attaquants ont explicitement ciblé les sauvegardes, que cesoit au niveau des socles systèmes des serveurs de sauvegarde ou autravers des consoles d’administration implémentant une authentificationunique avec l’AD.

Cette tendance, permettant de maximiser les chances de paiement de larançon, devrait s’accentuer dans les mois et années à venir.

192Le nombre d’attaques parrançongiciels affectant leterritoire national portéesà la connaissance del’ANSSI en 2020, enhausse de 255% parrapport à 2019.

12

13

L’attaque présentée est inspiréed’une intervention du CERT-Wfaisant suite au déploiement d’unrançongiciel sur un parc deplusieurs dizaines de milliers demachines. Présentant lesvulnérabilités et défauts deconfiguration communémentexploités, l’analyse met enlumière les Tactics, Techniquesand Procedures (TTP) d’unopérateur de rançongiciel. Toutesles informations permettantd’identifier les parties ont étéanonymisées.

Les élévations de privilèges ausein des environnements ActiveDirectory, suite à lacompromission initiale d’unepremière ressource, font ainsipartie intégrante des modesopératoires des groupesd’attaquants. Une absence detechniques d’attaques avancéesest constatée dans la majoritédes attaques par rançongiciels, etnotamment dans le cadred'attaques selon le modèle duRansomware-as-a-Service. Dansce modèle, des cybercriminelssont affiliés à un fournisseur derançongiciel, afin de bénéficier del'agent chiffrant et des servicesliés (infrastructure de paiementet de contact, site depublications, etc.) en échanged'une part des gains desopérations. Les groupesd’attaquants agissent ainsiprincipalement sur opportunité etavec des objectifs de retour surinvestissement à court terme. Au

moins une des phases de lachaîne d’attaque aurait engénéral pu être évitée au traversd’un meilleur respect des bonnespratiques de base en matière decyber-hygiène et de sécuritéinformatique.

Au-delà des attaques non cibléeset opportunistes, des groupesd’attaquants par rançongicielsfont toutefois usage de moyenset compétences plus avancésdans la réalisation de leursopérations. Cette tendance,dénommée « Big GameHunting », permet aux groupescybercriminels de cibler desorganisations disposant d’unniveau de sécurité informatiqueplus élevé.

Étude d’une attaque par rançongiciel, basée sur une intervention du CERT-W en 2020

14

Schéma de principe de l’attaque étudiée

15

L’attaquant s’introduit sur le SI,suite à la compromission initialed’un compte de domaine, via uneinfrastructure de bureaux virtuelsexposée sur Internet. Uneréutilisation des identifiantscompromis est de fait possible enl’absence d’authentification multi-facteurs.

Si le hameçonnage etl’exploitation de vulnérabilitéscritiques se maintiennent commeles principaux vecteursd’infection, les rejeuxd’identifiants sur des servicesd’accès distants exposés sansauthentification multi-facteurs

représentent près de 1 cas sur 5des compromissions initialesinvestiguées par le CERT-W. Onpeut notamment citer le cas desattaques par force brute sur lesservices Remote DesktopProtocol (RDP) exposés surInternet.Suite à cet accès, unéchappement du bureau restreint(via un interpréteur decommandes exécuté au traversd’un logiciel autorisé) permet àl’attaquant d’obtenir un accès ausystème et d’entamer une phasede reconnaissance active. Faitcourant, un délai a été constatéentre le premier accès malveillantet le début de la phase dereconnaissance active. Ce délaipeut s’expliquer par la revente del’accès, obtenu par un grouped’attaquants spécialisés dans ledomaine, à l’opérateur derançongiciel.

L’exposition de service d’accès sur Internet sans MFA expose le SI à des accès illégitimes par rejeux d’identifiants

Accès initial

16

Des rebonds depuis le serveurcompromis à l'aide du compteadministrateur local, dont le motde passe est mutualisé avec lescomptes de multiples autresserveurs, permettent ensuite àl’attaquant d’élever ses privilèges.

Un premier compte de domaineprivilégié est ainsi compromispuis des tentatives demouvements latéraux à largeéchelle sur plusieurs milliers demachines sont réalisés avec cecompte jusqu'à la compromissiond'un compte administrateur dedomaine.

L’absence de déploiement de la solution LAPS1 facilite les mouvements latéraux

L’exploitation d'une vulnérabilitécritique sur un serveur Windows2003 (en fin de support et nerecevant plus de correctifs desécurité) permet à l’attaquant deprendre le contrôle du serveur àdistance et d’établir un camp de basesur le serveur.

Les serveurs obsolètes doivent être isolés et ne pas dégrader le niveau de sécurité de l'ensemble du SI

1. La solution logicielle Microsoft LAPS (Local Administrator Password Solution) fournit une capacité de gestion automatisée des mots de passe des comptes locaux des machines intégrées à l’AD et permet de garantir l’unicité du mot de passe d’un compte local par machine.

Latéralisation et élévation de privilèges

17

Bien qu'une solution antivirale(par signatures) était déployéesur les systèmes ciblés, desutilitaires présents nativementsur les systèmes Windowspermettent d'exfiltrer la mémoiredu processus LSASS (quicontient les secretsd’authentification des utilisateursconnectés).L’usage de comptes disposantdes privilèges d’administrateurdu domaine pour des tâchescourantes rend possible uneélévation de privilèges via desmouvements latéraux successifs.

Suite à la compromission dudomaine, une phase de post-exploitation est entamée parl’attaquant, dans le butd’identifier et exfiltrer lesdonnées sensibles de l’entreprise.Les privilèges d’administrateur dudomaine permettent ainsi unaccès très large aux ressourcesenrôlées (partages de fichiersréseau, boîtes de messageries,etc.).

En dernière étape, la chargemalveillante est déployée à la foispar stratégie de groupe et unprocessus automatique, exécutédepuis un contrôleur de domaine,pour permettre une rapidepropagation au sein du SI de lavictime.

En sus du chiffrement desmachines compromises, l’agentchiffrant efface les journaux deWindows hébergés sur lesmachines et les éventuellescopies conservées localement.

L’absence de mise en œuvre d’une administration structurée par niveau (modèle de tiering) expose le domaine AD à des élévations de privilèges

Déploiement du rançongiciel

18

Au-delà des vecteurs decompromission plus communs,les attaques dites par supply-chain représentent un vecteurd'infection en croissance. Bienque documentées depuisplusieurs années déjà, lesattaques réalisées via desfournisseurs et prestataires deservices se sont multipliées, ennombre et en ampleur ces deuxdernières années. Cettecroissance peut notamments'expliquer par l'amélioration duniveau de sécurité informatiquedes infrastructures d’entreprise,obligeant ainsi les attaquants àcompromettre des tiers pouratteindre leurs cibles finales.

Les attaques par supply-chainprésentent de plus un retour surinvestissement particulièrementattractif pour les groupesd’attaquants : la compromissiond'une première entité mènepotentiellement à l’obtention d’unpoint d’accès chez un grandnombre de ses clients. Réservées

aux attaquants dotés decapacités techniques les plusavancées, ces attaques ont aussibien été employées par lesopérateurs de rançongiciels, àdes fins de gains financiers, quepar les groupes étatiques, dansune optique d'espionnage.

En 2020, l'attaque SolarWinds amarqué les esprits. Cette attaquedémontre l’ampleur que peuventprendre les attaques par supply-chain, avec 18 000 des clients deSolarWinds impactés. Trèssophistiquée dans son modeopératoire d’intrusion (injectiond’une charge à la compilation,déploiement d’infrastructuresdédiées pour chaque cible finale,etc.), cette attaque fait aussi étatde techniques de latéralisationclassiques et repose, en partie,sur des vulnérabilités ordinaires.

L’attaquant a créé trèsrapidement des portes dérobées,a ouvert discrètement descanaux de communication, acamouflé et caché ses tracesalors qu'il cherchait des moyensd'obtenir des privilèges élevés.Mais il a également utilisé destechniques connues telles que laréutilisation de mots de passecompromis ou le déplacementlatéral avec des comptesadministrateurs identiques surl’ensemble de machines.

Les privilèges accordés sur l’annuaire AD aux solutions tierces, souvent requis trop élevés par les éditeurs par soucis de simplicité, peuvent se révéler désastreux en cas d’attaque par supply-chain.

Une tendance émergente : les attaques par supply-chain

Ce chapitre vise à expliquer le nouveaumodèle de sécurité AD Enterprise AccessModel puis à proposer des recommandationsde sécurisation pour l’AD on-premises etAzure AD, ainsi qu’une trajectoire pour unemodernisation vers Azure AD.

Quelles trajectoires pour améliorer la situation ?

Enterprise Access Model

Microsoft a introduit en 2012, lemodèle d’administration en tiersdont l’objectif est de partitionnerles secrets d’authentification ausein d’un environnement ActiveDirectory.

Le principe d’implémentation estde créer un cloisonnement entreles administrateurs en fonctiondes ressources qu'ils gèrent. Celaaide à protéger les secretsd’authentification et éviter qu'unecompromission d'un niveau demoindre confiance ne se propageà un niveau de plus grandeconfiance.

Ce modèle définit trois niveauxpour séparer l'administration desressources en fonction de leurcriticité. Ainsi, les administrateursqui contrôlent les postes detravail des utilisateurs sontséparés de ceux qui gèrent lesserveurs et de ceux qui gèrent leréférentiel d’identités de

l’entreprise, ici l’Active Directory.Les documents Mitigating Pass-the-Hash and Other CredentialTheft, version 1 and 2 détaillentce modèle d'administrationassocié à un Environnementd'administration à sécuritérenforcée (Enhanced SecurityAdmin Environment - ESAE)communément appelé « forêtd’administration » ou bien encore« hardened forest ».

En décembre 2020, Microsoft àfait évoluer ce modèled’administration pour prendre encompte les environnements cloudet hybride. Ce nouveau modèled’accès entreprise (EnterpriseAccess Model) est une évolutiondu précédent modèle : le conceptde modèle en tiers demeure, bienqu'il soit remanié avec uneterminologie qui évolue.

L’approche ESAE a étésupprimée des recommandationsgénérales, car complexe etcoûteuse à implémenter. La miseen œuvre d’une forêtd’administration peut néanmoinsrester pertinente dans certainscas, notamment pour lesenvironnements déconnectés.

20

Ce concept se fonde sur le modèle de Bell LaPadula, introduit dans les années 1970.

21

Comprendre les principes dumodèle de tiering estfondamental pour bienappréhender les bonnespratiques de sécurité dans unenvironnement Microsoft.

Des moyens techniques sontappliqués pour assurer l'isolationentre les tiers.

Le Tier 0 est le niveau le plusprivilégié et comprend lescomptes, les groupes, lescontrôleurs de domaine et lesressources qui ont contrôle directou indirect sur Active Directory.On placera donc dans ce niveau0, les serveurs liés à l’ActiveDirectory (contrôleurs dedomaine) mais également lesautres composants ayant uneinteraction forte tels que lesserveurs de fédération, serveursde mises à jour WSUS, dedéploiement des applications, PKIinterne, ou bien encore Azure ADConnect.

Les administrateurs du Tier 0peuvent gérer et contrôler lesressources de tous les niveaux(au sens AD), mais ne doiventinteragir qu’avec les ressourcesdu Tier 0. Pour ce faire, ilsdoivent utiliser une stationd’administration à sécuritérenforcée (appartenant à ceniveau).

Le Tier 1 désigne les serveurs etles applications qui sontmembres du domaine AD ainsique les ressources qui gravitentautour. Les comptes quicontrôlent ces ressources ontpotentiellement accès à desdonnées sensibles. Lesadministrateurs de niveau 1peuvent accéder aux ressourcesdu Tier 1 et ne peuvent gérerdans l’Active Directory que lesressources du Tier 1.

Le Tier 2 concerne les appareilsdes utilisateurs (postes de travail,imprimantes, etc.). Par exemple,le support téléphonique (leservice d'assistance, fait partie dece niveau). Les administrateursdu Tier 2 ne peuvent seconnecter qu’aux ressources duTier 2 et ne gérer que les actifsdu Tier 2 dans l’annuaire ActiveDirectory.

Comprendre le modèle précédent, en tiers

22

Le nouveau modèle d'accèsd'entreprise (Enterprise AccessModel) a été créé pour lesorganisations hybrides, qui ontdes applications on-premisesmais également multi-cloudsuivant les principes de sécuritédu Zero Trust.

Dans ce nouveau modèle, lecontrôle de la sécurité n’est plusopéré exclusivement à partird’Active Directory, maiségalement depuis Azure ActiveDirectory.

Les termes évoluent mais lesprincipes de séparation enniveaux de privilèges (tiering)demeurent.Ainsi, on ne parle plus de Tier 0,mais de plan de contrôle (ControlPlane). La gestion du plan decontrôle doit être étroitementencadrée et limitée à desappareils de très forte confiance.Le plan de contrôle évolue ets’élargit : au-delà des ressourcesde l’ancien Tier 0, on y ajouteAzure AD, mais aussi lessolutions cloud comme les outilsde gestion d’appareils de type

MDM ou bien les solutions dedéveloppement commeGitHub/Azure DevOps.

La notion des couches de gestionest introduite à travers lemanagement plane et ledata/workload plane qui sont làpour gérer les applications et lesdonnées, ce qui s’appelaitauparavant le Tier 1. Enfin, il y ales utilisateurs et les autresapplications qui consomment lesservices (applications etdonnées) – il peut s'agird'utilisateurs internes, departenaires, de clients, etc.

L’Enterprise Access Model nementionne pas explicitement lespostes de travail des utilisateursqui étaient situés auparavantdans le Tier 2. À la place, le plande contrôle d’Azure AD est utilisépour déterminer quels typesd’appareils peuvent se connecterà tel service ou application. C’estce qui se nomme le contrôled’accès conditionnel et constituela pierre angulaire d’unearchitecture dite Zero Trust.

Un nouveau modèle pour l’entreprise hybride

23

Au travers du guide SecuringPrivileged Access, Microsoft apartagé une implémentation deréférence qui illustre le modèled’accès entreprise introduitprécédemment.

L’objectif est de limiterstrictement la capacité àeffectuer des actions privilégiéessur des chemins autorisés, touten perturbant le retour surinvestissement des attaquants.

Au-delà de la prévention, onsurveille de près ces cheminsd’accès en détectant lesanomalies et les comportementsdéviants.

La stratégie est d'encourager lesorganisations à d'abord utiliserles nombreuses fonctionnalitésnativement présente dans lecloud.

Dans le guide proposé parMicrosoft, l’implémentations’appuie sur les solutions desécurité disponibles dansMicrosoft 365 Entreprise E5.C’est un point de départ pour lamise en œuvre d’une architectureZero Trust en environnementMicrosoft.

Le contrôle d’accès conditionnelet l’authentification forte sontgénéralisés pour tous lesutilisateurs. La solution MicrosoftCloud App Security, couplée àIdentity Protection, est utiliséepour la supervision des sessions.

Securing Privileged Access «mode d'emploi »

24

On restreint ici explicitementl'utilisation des comptes àprivilèges (qui sont marquéscomme sensibles) à des appareilsspécifiques avec le contrôled’accès conditionnels avec AzureAD Premium.

Sur les postes de travail, un EDR(Endpoint Detection andResponse) est déployé, il s’agitde Microsoft Defender forEndpoint qui est capabled’interagir avec Azure AD, àtravers le MDM, pour remonterl’état de santé des appareils.

La gestion des postes de travailet le déploiement des profils desécurité est faite avec le MDMMicrosoft Endpoint Manager.

Sur les profils de postes «spécialisé » et « administration »,l’utilisateur de l’appareil n’est plusadministrateur de son poste.De plus, la liste des applicationsautorisées à s’exécuter estrestreinte.

Enfin, les principes de moindreprivilège et le just-in-time access(élévation temporaire) des droitsd’administration avec Azure ADPremium est mis en œuvre.

Cette implémentation deréférence permet icid’administrer les ressources dansle cloud mais également les actifscritiques comme l’ActiveDirectory au traversd’intermédiaires (VPN, serveur derebond, etc.).

24

Sécuriser le Tier 0 et mettre en œuvre le plan de contrôleQuelle que soit la raison quiamène à lancer un projet derenforcement de la sécurité del’AD (plan d’action consécutif àun incident de sécurité majeur,résultats de tests d’intrusion oud’exercice de red team, etc.), uneimportante phase préparatoireest nécessaire avant le lancementd’un aussi vaste programme. Ilapparaît prioritaire de se focalisersur le Tier 0 et tenir compte auvu des transformations du SI surles autres Tiers (utilisation ducloud et Azure AD).

Étape 1 : se préparer - 1 à 6 moisMême si les grandes lignes sontglobalement connues endémarrant un projet desécurisation de l’AD, il estindispensable de délimiter lescontours du projet.La durée de la phase de cadragedépend bien sûr, en premierfacteur, de la complexité del’environnement. Du cas simpled’une unique forêt AD avec unseul domaine, exploitée par uneéquipe centrale, au cas déjà pluscomplexe d’une grandeorganisation, présente sur toutesles plaques géographiques, ayantvécu de nombreuses acquisitions

qui ont conduit à la création derelations d’approbation entre detrès nombreuses forêts, lesenjeux de chaque projet sontuniques.

Les trois principaux objectifs dela phase de cadrage sont :

1. Dresser une cartographie del’environnement existant (forêtset relations d’approbationassociées) et identifier lesvulnérabilités présentes.

2. Déterminer la cible de sécurité àatteindre et l’échéance (e.g.périmètres prioritaires, niveau dedurcissement à la cible, caractèredédié des infrastructures, forêtsdont le décommissionnement estpossible, élimination desadhérences entre le système desauvegarde de l’AD et l’AD lui-même, etc.).

3. Définir la structure projetpermettant d’atteindre lesobjectifs fixés dans le planningdéfini.

25

La sécurisation du Tier 0 est nécessaire, le travail mené ne sera en rien perdu, même en cas de transformation cloud

26

C’est également dans ces phasesque l’on prend en compte lesplans d’action préexistants(rapports de l’InspectionGénérale, audits réalisés, bilan dered team, etc.) pour les réintégrerdans ce projet désormais global.

Pour établir la cartographie,l’approche repose sur :

/ des outils reconnus du marché(e.g. PingCastle, BloodHound,OAADS, etc.) ou des frameworks(e.g. points de contrôle del’ANSSI) ;

/ des entretiens avec les relais dansles métiers ou les géographies,permettant d’identifier desinfrastructures Active Directoryautonomes et potentiellement nonrepérées par les outils.

Une fois tous les élémentsrassemblés, les objectifs duprojet de transformation sontdéfinis et les trajectoires pour yparvenir établies. Ce type deprojets se décomposehabituellement en plusieurs sous-chantiers.

Rationaliser les infrastructures(forêts et domaines à

décommissionner ou à migrer) etles relations d’approbationlorsque cela est possible.

Durcir et corriger lesvulnérabilités identifiées : mise àjour des actifs dont l’OS n’estplus supporté, durcissementsystème et AD, applicationrégulière des correctifs desécurité, etc.

Mettre en œuvre le modèle enTiers (prioritairement le Tier 0),et déploiement des modificationsd’architecture à apporter(cloisonnement, déploiementd’actifs dédiés au Tier 0,implémentation de postesd’administration dédiés, recours àdes silos d’administration…).

Définir le RACI et le modèled’administration : activités deséquipes, type de comptes àprivilèges qui leur seront fourniset cinématiques d’administration.

Préparer la reconstruction, avecl’externalisation des sauvegardessur des systèmes sans adhérenceavec Active Directory, tests dereconstruction, etc.

Préconisations pour l’utilisation d’outils publics

De nombreux scripts ou outils open-source sont disponibles sur Internetpour évaluer le niveau de sécurité d’un environnement Active Directory /Azure AD. Il convient cependant de respecter quelques règles deprudence avant de les exécuter :1. Revoir le code source de l’outil, pour s’assurer de son comportement (quand

cela est possible).2. Exécuter l’outil avec le minimum de privilèges requis, selon le principe du

moindre privilège, et dans un environnement restreint (machine virtuelledédiée par exemple).

3. Limiter les flux sortants selon les besoins (pas de flux vers Internet pour unerevue de configuration Active Directory, uniquement vers les ressourcesMicrosoft pour une revue Azure AD)

26

27

Faut-il mettre en place uneforêt d’administration ?Comme expliqué précédemment,ce modèle n’est plusrecommandé par Microsoft, saufcas particuliers décrit ici, carcomplexe et coûteux à mettre enœuvre.

Quid de l’administration de l’infrastructure de virtualisation hébergeant les actifs du Tier 0?La criticité de l’infrastructurehébergeant les actifs du Tier 0impose qu’elle soit dédiée et queson administration soit intégréeau Tier 0. En effet, l’utilisationd’une plateforme mutualisée faitnaître un risque de mauvaisemaîtrise des accès à cesmachines virtuelles.Cependant, la mise à dispositiond’une infrastructure dédiée peutêtre assez longue dans certainesorganisations. Pour réduire lerisque plus rapidement, l’onpourra utiliser une infrastructuremutualisée existante de manièretactique, afin de débuter sanstarder la mise en œuvre desactions de sécurisation décritesdans la partie suivante.

Une migration sur l’infrastructuredédiée cible, quelques mois plustard, achèvera de couvrir lerisque résiduel mentionnéprécédemment.

Étape 2 : mettre en œuvre le tier 0-6 à 24 moisAu démarrage de cette étape, lesderniers ateliers de réflexion sontmenés, pour affiner les cibles àatteindre sur la base du cadrage,embarquer les équipes etprésenter le séquencement desactions.L’identification des différenteséquipes d’administration del’organisation (e.g. support IT,équipes AD, équipes serveurs,équipes postes de travail, etc.),de leurs responsabilités etactivités, des droits qu’ellesdoivent avoir pour les réaliser(principes du moindre privilège).Cela permet de définir un RACIclair et de préparer les futurscomptes qui seront utilisés, enlien avec le modèle de délégationdu Tiering.

28

Ensuite, viennent les étapescentrales : application de lastructure en Tiers dans l’ActiveDirectory, création des comptesd’administration propres àchaque Tier, déplacement desobjets dans les bonnesOrganizational Units (OU).L’étape finale consiste à interdire

la connexion à l’aide d’un compted’un Tier donné, sur un actif d’unTier inférieur (comme illustré surle schéma ci-dessous). Cela peutêtre mis en place, dans unpremier temps, grâce à des GPOdites de « deny logon », puis demanière plus pérenne au traversd'Authentication Policy Silos.

Le déploiement d'une GPO «deny logon » permet d'empêchertechniquement les connexionsdes comptes Tier 0 aux machinessur lesquelles la GPO estappliquée (Tier 1 & 2). Toutefois,les GPO sont des éléments deconfiguration client, quipourraient être désactivéslocalement par un attaquant(dans le but de piéger unadministrateur Tier 0 et induireune connexion sur une machinecompromise par exemple). LesGPO « deny logon » protègentdonc des erreurs d’administrationmais présentent des défautspouvant les rendre vulnérables encas d’attaque.Les Authentication Policy Silospermettent de n’autoriserl’authentification de certainscomptes (typiquement lescomptes d’administration du Tier0) que depuis certaines machines

(typiquement les postesd’administration). Comparé aumécanisme de blocage par GPO,les Authentication Policy Silos nereposent plus sur uneconfiguration client mais sur unmécanisme imposé par lesservices Active Directory. Cemécanisme permet de plus decouvrir le risque de rejeud’identifiants du Tier 0 (ticketsKerberos) ailleurs que sur unposte d’administration (devantdonc lui aussi être compromis).Cependant, la plus grandecomplexité de mise en œuvre decette méthode par rapport à celledes GPO peut inviter à procéderpar étape : à court terme,implémenter les GPO, à moyenterme, mettre en oeuvre lesAuthentication Policy Siloscomme une façon de renforcerencore le niveau de sécurité.

29

Enfin, cette étape doit égalementinclure la définition et ledéploiement du posted’administration (PAW, PrivilegedAccess Workstation). Ce poste detravail, ne doit avoir commeunique possibilité que de seconnecter au actifs du Tier 0pour y effectuer les actionsd’administration. Il peut donc êtredurci selon les meilleursstandards, et ne comporter aucunlogiciel autre que celui quipermet la connexion à distance.Ainsi, aucun accès à Internet(exception faite de l’accès auportail cloud Azure dans uninfrastructure hybride parexemple) ni à la messagerie nedoit être possible, afin de limiterl’exposition de ce poste. En casde besoin, il faudra prévoir lamise en place d’une zoned’échange entre lesenvironnements bureautique etd’administration.

Les sujets épineux : l’adhérenceavec le bastion d’administrationpréexistant dans l’organisation,avec son modèle déjà établi estparfois source de complexité, endépit des avantages qu’il offre(c.a.d. facilité d’implémentationde l’authentification multi-facteurs, enregistrement desactions).

DurcissementCette partie revient à appliquerles mesures de sécurité partoutoù cela est possible, pourrenforcer le niveau de sécurité.Couvrir le durcissement des actifsdu Tier 0 : formalisation etapplication d’un guide dedurcissement, limitation au strict

minimum du nombre d’agents surles actifs du Tier 0, puisqu’ilspeuvent constituer un vecteur decompromission. Idéalement, seulsdes logiciels natifs de Microsoft(antivirus, sauvegarde intégrée,transmission des évènementsgrâce à WEF(1), agent desupervision MDI(2), ApplicationControl, etc.) doivent êtreprésents.

Il faut également veiller àmodifier les configurations de cesactifs, pour utiliser les systèmesde MCO/MCS dédiés au Tier 0(supervision, mises à jour des OS,déploiement de logiciels, etc.).C’est également dans cette étapeque les actions de remédiationconcernant les comptes àprivilèges doivent être menées :remplacement des comptesmembres des groupes Built-Inpar des comptes avec droitsrespectant le principe du moindreprivilège, cartographie descomptes de services, recours àMSA/gMSA (Managed ServiceAccount) lorsque cela estpossible, identification et mise enquarantaine des comptes inactifs,activation de LAPS, etc. Pour seguider, on pourra s’appuyer sur laliste des points de contrôleActive Directory mis à disposition

D’un strict point de vue de la réductiondes risques, la mise en œuvre dumodèle en Tiers est prioritaire sur ledurcissement, même si elle est pluscomplexe en raison de son impact surles pratiques d’administration.

(1) Windows Event Forwarding (2) Microsoft Defender for Identity

30

par l’ANSSI, afin de rehausser leniveau de sécurité par paliers.

Les sujets épineux : les comptesde services de certaines solutionsqui exigent, souvent parsimplicité, d’être membre desgroupes Domain Administratorsou Enterprise Administrators. Lescomptes dont on ne connaît pasl’appartenance et dont on a dumal à estimer l’impact en cas decoupure. La mise en œuvre d’unprocessus fiable de traitementdes comptes inactifs, au-delà dutraitement manuel et en masseau moment du projet.

SauvegardeLa sauvegarde et la restaurationdes machines est un sujetglobalement maîtrisé dans lesorganisations. Pourtant, il estnécessaire de réétudier cettequestion à la lumière de lamenace actuelle et du scénariodu pire : la compromission etdestruction totale de l’ActiveDirectory et de ses sauvegardes.Bien souvent, l’infrastructure desauvegarde est elle-même liée audomaine AD qu’elle sauvegarde.Malgré ce programme desécurisation, il est important derester modeste et de toujoursenvisager qu’une compromissionest possible (« Assume breach »).Ainsi, il s’agit de compléter ledispositif de sauvegarde enplace, que l’on conservera poursa performance de son temps derestauration, par un dispositif desauvegarde externalisé etdécorrélé de l’AD.

DétectionUne fois le modèle en Tiers enplace, les modes d’administrationétant connus et normés, l’on peutmettre en place des scénarios dedétection pour identifier lespratiques qui s’écartent dumodèle (e.g. ajout de comptedans les groupes built-in,modification de configurationssensibles et normalement stablesde l’AD, utilisation de comptesd’urgences, etc.). Enfin, la mise enœuvre de scénarios de détectionde techniques d’attaque (e.g.récupération de hashs, nombreimportant de demandes detickets Kerberos dans un laps detemps court, etc.). Microsoftfournit une liste de based’évènements AD à collecter.Évidemment, des processus detraitement des alertes et desincidents doivent être décrits etopérationnels.

Les sujets épineux : la méthodede collecte (utilisation de WEF)qui peut être différente dustandard défini par le SOC(collecte par agent installé surl’actif) et nécessiter desadaptations.

RationalisationEn parallèle de ces actions desécurisation, il convient de suivrele bon déroulement du plan dedécommissionnement ou demigration défini dans la phase decadrage.

31

Un décalage de planning setraduirait immédiatement en unrisque important, dans la mesureoù aucune action de sécurisationne serait menée sur cespérimètres. Et d’autant plus s’ilspossèdent des relationsd’approbation avec les autresforêts.

Les sujets épineux : l’incertitudedes impacts précis lors lacoupure des relationsd’approbation et dudécommissionnement.

Pilotage du programme,conduite du changement etreporting.Pour être exhaustif, il apparaîtindispensable de mentionnertoutes les activités transversesinhérentes au pilotage duprogramme. La planification, lasynchronisation des équipes et lacommunication aux partiesprenantes sont des éléments clés,compte tenu du nombreimportant d’actions techniques àmettre en œuvre, de leurinterdépendance et de leurimpact potentiel.

Par ailleurs, le changementimportant dans les pratiquesd’administration (e.g. utilisationde comptes d’administrationdistincts par Tier, utilisation d’unPAW) imposé par la mise enplace du modèle en Tiers, induitd’apporter une attention touteparticulière à la conduite duchangement, pour éviter deperturber les activités.

Enfin, il est essentiel de s'assurerque la communication et lereporting sur l'avancement du

programme soient suffisammentsimplifiés et expliqués pour éviterde susciter des frustrations et desincompréhensions au sujet desinévitables points de blocages etdemandes d'arbitrages.

Les sujets épineux : la difficultéde faire le lien entre la réalisationd’actions techniques et lacouverture des risques,l’importante mobilisation qui estdemandée aux équipes en chargedu run de l’AD pour mettre enœuvre les actions techniques.

Etape 3 : garantir la pérennité – 1 à 3 moisPlus que n’importe quel autrecomposant du SI, la sécurité del’AD ne peut se réduire à unprogramme limité dans le temps,mais doit se transformer en unprocessus régulier de contrôle duniveau de sécurité global. Celui-cidoit être exécuté régulièrement,et les écarts identifiés doivent setraduire par des actionscorrectrices à court terme et deprévention à moyen terme.

32

SYNTHÈSE : Sécuriser le Tier 0

Ce plan de contrôle peuts’appuyer sur diverses sources :des scripts, des outils du marchécomplémentaires , le service ADS(Active Directory Security) del’ANSSI, des vérificationsmanuelles (lorsqu’elles nepeuvent pas facilement êtreautomatisées). Aussi, l’on pourraaussi s’appuyer sur des audits etdes exercices de red teamannuels, pour vérifier que le Tier0 ne peut plus être compromis.

Enfin, en plus de vérifier que lessauvegardes de l’infrastructure

Active Directory réussissentsystématiquement, il convient,comme dans toute approche decontinuité, de tester larestauration complète depuis unesauvegarde.Ces tests réguliers permettrontaussi de mesurer le délainécessaire à la restaurationcomplète. Celui-ci pourra êtrecommuniqué aux responsablesde la continuité et constitueraégalement un indicateur que l’oncherchera à optimiser, test aprèstest.

Maintenir les composants en condition de sécuritéAppliquer les correctifs de sécurité et durcir les configurations.

Mettre en œuvre le Tier 0Cloisonner l’Active Directory, pour le risque de compromission.

Sauvegarder et s’entrainer à restaurerMettre les sauvegardes hors de portée et se tenir prêt à reconstruire.

Rationaliser et décommissionnerFocaliser le travail sur les périmètres pérennes et décommissionner le reste.

Centraliser les logs et mettre en œuvre la détectionSurveiller et détecter les signaux faibles, pour réagir rapidement.

Piloter les actions et conduire le changementSuivre et déployer rigoureusement ce plan d’action.

32

33

Sécuriser sa souscription Azure AD

L’Identity Secure Score,unepremièreétapeLe degré de sécurisation (ouIdentity Secure Score) est unindicateur natif permettant decomparer la posture del’organisation vis-à-vis desbonnes pratiques de Microsoftconcernant la sécurisation desidentités.

Ce score a été Introduit en 2020,sur base du Microsoft SecureScore présenté fin 2017.

Les principes du calcul sont lessuivants :/ Pourcentage de mise en place

des contrôles proposés parMicrosoft

/ Les contrôles mesurésdépendent de l’architecture del’identité et des licencesdisponibles (cf. tableau ci-dessous)

/ Une seule licence de sécuritéactive l’apparition du contrôle

Si tous les contrôles sont

disponibles pour l’organisation, larépartition du score est lasuivante à l’heure actuelle :/ 61 points sur les identités cloud

(Paramétrage Azure AD, Accès Conditionnel, Réinitialisation du mot de passe en libre service, Azure AD Identity Protection)

/ 58 points sur les identités locales (avec Microsoft Defender for Identity)

Deux cas peuvent expliquer uneévolution : la modification de laposture de l’organisation ou lamodification des contrôles parMicrosoft.

Il est possible d’en suivre lesraisons en regardant leschangements affectant leMicrosoft Secure Score dans leCentre de Sécurité Microsoft 365.

A noter, le Microsoft SecureScore ne reprend pas tous lescontrôles de l’Identity SecureScore.

Dans le cas d’une organisation hybride, sans licence Microsoft Defender for Identity, les contrôles sont les suivants :

Gratuite (P1 ou P2) : Besoin d’avoir une licence premium pour personnaliser les mesures de sécurité

34

L’Identity Secure Score donneune métrique de la posture del’organisation par rapport à desbonnes pratiques de Microsoft,non exhaustives maisindispensables.

Il est en outre primordial des’assurer que l’ensemble desparamétrages d’Azure AD soientcohérents avec les enjeux del’organisation (e.g. domainesautorisés pour les invités).Quelques heures sont suffisantespour les passer en revue etdéfinir des axes d’améliorationconcrets.

Au-delà des configurations de laplateforme, il est plus que

recommandé de mettre en placeun plan de contrôle permanentafin de suivre les objets qui nevont pas manquer de semultiplier (applications cloud ouon-premises, utilisateurs interneset externes, politiques d’accèsconditionnel, etc.).

Ce plan de contrôle permettrad’assurer le maintien en conditionopérationnelle et de sécuritéd’Azure AD au même titre que lesplans existants pour les ADlocaux.Au programme, ces contrôlesdevront reprendre les sujetssuivants :

Administrateurs : / Listes et droits utilisés/ Utilisation des comptes

bris de glace

Applications Azure AD : / Personnes habilitées à

enregistrer une application/ Gestion des propriétaires,

secrets et des permissions pour chaque application

Accès conditionnel : / Evolution dans les

politiques d’accès/ Gestion des exceptions

Utilisateurs internes : / État de l’enrôlement des

facteurs d’authentification/ Listes et droits utilisés/ Rattachement à une entité

Appareils : / Conformité des appareils/ Nombre d’appareils

par utilisateur

Utilisateurs invités : / Légitimité du compte/ Droits et permissions

associés

Aller plus loin que le Secure Score

35

Les rôles Azure AD constituentun élément important dans ledispositif de sécurité du cloudMicrosoft. Il existe plus de 70rôles intégrés qui s’appliquentaussi bien à la gestion desressources de l’annuaire AzureAD mais également à certainsservices Microsoft 365(SharePoint Online, ExchangeOnline, Teams, AIP…) et Azure(Azure DevOps…). Pour aller plusloin, il est envisageable de créerses propres rôles avec les rôlespersonnalisés.

Le diagramme suivant illustre lesrôles propres à Azure AD, ainsique des rôles s’appliquant àd’autres services Microsoft 365.

Par défaut, les ressources AzureAD et Azure sont sécurisées defaçon indépendante les unes desautres. Néanmoins, unadministrateur général Azure ADpeut élever son accès pour gérertous les abonnements etressources dans Azure.

Cet accès plus élevé, à travers lerôle administrateur de l’accèsutilisateur (ou User AccessAdministrator) lui permetd’interagir avec tous lesabonnements Azure faisantconfiance à son tenant Azure AD.Ainsi, avec ce rôle unadministrateur général peutdonner à d'autres utilisateurs unaccès aux ressources Azure.

Compréhension des rôles ayant des droits au-delà d’Azure AD

Comprendre les rôles dans Azure AD

Azure ADApp Admin, User Admin,

Groups Admin, Auth Admin, ...

Exchange

ExchangeAdmin

ExchangeAdmin

Intune

Security Admin

Security Reader

MCAS

TeamsTeams Admin, Teams Devices Admin, Teams

Comm Admin, ...

36

Parmi les identités gérées dansAzure AD, les applicationsreprésentent un point essentiel àappréhender et sont trèsdifférentes de ce qui existait on-premises.

Inscription d’une applicationUne application qui souhaiteexternaliser l'authentification versAzure AD doit être déclarée dansAzure AD (via applicationregistration), qui enregistre etidentifie de manière uniquel'application (AppId) dansl'annuaire à travers la notiond’objet d’application (ouapplication object).

Cette inscription (ou applicationregistration) se fait dans le tenantdu propriétaire de l’application.(e.g. Exchange Online est inscritdans le tenant de Microsoft) .Le propriétaire de l’applicationpeut ensuite déclarer des API quiseront utilisées par l’application(e.g. lire et écrire un mail dansExchange Online).

En fonction de sa configuration,l’application pourra ensuite êtreutilisée soit dans son tenant soitdans un tenant externe.Pour cela, l’objet application estutilisé en tant que modèle pourcréer un ou plusieurs objetsprincipal de service. Un principalde service est créé dans chaquelocataire dans lequel l’applicationest utilisée.

Il est important de noter qu’un

administrateur du tenant danslequel est inscrite l’applicationpeut ajouter des authentifiants(secrets ou certificats).

Une personne en possession desauthentifiants pourra utiliser lespermissions de l’application.

Une application est représentéedans Azure AD par 2 classesd'objets :/ Objet d’application : stocke les

informations relatives à l'application

/ Objet Service Principal : représente une instance de l'application.

Service PrincipalAfin de consommer desressources protégées par AzureAD, il est nécessaire des’authentifier soit via unutilisateur ou une application,également appelé principal deservice (ou service principal).

Les principaux de service sont untype d'objet qui existe dansAzure AD pour représenter uneapplication.

En particulier, un principal deservice est généralement créélorsque vous avez uneapplication ou un code qui doitaccéder à des ressources ou lesmodifier, ce qui ne peut êtrefacilité que par une identitédisposant des autorisationsnécessaires. La création d'uneidentité pour une applicationpermet aux administrateurs de luiattribuer des rôles et desautorisations.

Comprendre les applications dans Azure AD

37

Il existe trois types de principalde service :

/ Application : Instanciationd’une application faite par unadministrateur ou par unutilisateur en cas deconsentement aux permissionsdemandées.

Lorsque l’app est déclarée enmulti-tenant , alors un principalde service est créé danschaque tenant ajoutantl’application (avec unidentifiant ObjectId propredifférent).

Ceci permet d’appliquer despolitiques et permissionsspécifiques mais aussil’authentification etautorisation propre a chaquetenant.Ce SP dans chaque autretenant est crée après leconsentement.

Un propriétaire d’une instancede l’application a la possibilitéd’ajouter des authentifiants.

/ Identité gérée (ou ManagedIdentity) : Identité utilisée par un service Azure pour obtenir un jeton Azure AD sans avoir à manipuler de secret d’authentification.

/ Hérité : Principal de servicehistorique similaire auxapplications, mais ne pouvantêtre présent que dans untenant (non recommandé).

Il est nécessaire de revoir régulièrementles applications d’entreprises inscrites,les permissions consenties et lesauthentifiants associés

Application et principal de service

Adatum tenant

Application RHService principal

Application RH (objet d’application)

Service principal

Application RHService principal

Application RHService principal

Contoso

Fabrikam

Clés de l’application RH

Contient un ensemble de clés

utilisées par l’application RH

Lorsqu'un administrateur donneson consentement aux permissionsdemandées, un service principal estcréé dans le tenant à partir del'objet d'application présent dans letenant source

1

2

3

38

Un défi courant lors de lacréation d'applications Cloud estde savoir comment gérer lesauthentifiants dans le code.Idéalement, ils ne sont jamaismanipulés sur les postes desdéveloppeurs et ne sont pasprésents dans le code source desapplications.

Il existe trois types de compte deservice dans Azure AD :/ Managed Identity :

recommandé si le service est natif à Azure

/ Application : recommandé si le service n’est pas natif à Azure ou est multi-tenant

/ Compte utilisateur dédié : non recommandé (si l’application supporte OAuth)

Recommandations communesQuel que soit le type choisi, ilconvient de définir un cycle devie (création, revue etsuppression) et suivre le principedu moindre privilège :/ Préférer les permissions

OAuth2 (e.g. lire les fichiers)plutôt que les rôles natifsAzure AD (e.g. administrateurSharePoint Online)

/ Utiliser des comptes deservices différents pour despermissions différentes

/ Dans le cas d’Exchange Onlineet SharePoint Online, il estégalement recommandé delimiter par élément lesapplications autorisées.

Protéger les authentifiants desapplications

Étant donné que les serviceprincipals ne supportent pasl’accès conditionnel à l’heureactuelle, le risque est que lesauthentifiants tombent dans demauvaises mains.

Pour s’en prémunir, il faut :/ Utiliser uniquement des

applications créées dans sontenant

/ Stocker les secrets dans AzureKey Vault

Deux types de Managed IdentityUne identité gérée attribuée parle système est activéedirectement sur une ressourceAzure. Lorsque la ressource estactivée, Azure crée une identitépour la ressource dans le tenantAzure AD. Une fois l'identitécréée, les informationsd'identification sontprovisionnées sur la ressource. Lecycle de vie d'une identitéattribuée par le système estdirectement lié à la ressourceAzure.

Une identité gérée et attribuéepar l'utilisateur est créée commeune ressource Azure autonome.Azure crée une identité dans letenant Azure AD qui estapprouvé par l'abonnementauquel la ressource est associée.Après la création de l'identité,elle peut être affectée à une ouplusieurs ressources Azure. Lecycle de vie d'une identitéattribuée par l'utilisateur est géréséparément du cycle de vie desressources Azure associées.

Sécuriser les comptes de services

3939

(1) Il est possible de mettre en place un accès conditionnel via un fournisseurd’identité tierce, mais celui-ci ne permettra d’avoir une granularité pour lesdifférentes applications Azure AD ou de gérer les durées de vie des sessions(2) Protection des identités : Stratégie de risque utilisateur ou en matière de risqueà la connexion et Politiques d’accès conditionnel basé sur le risque(3) Gouvernance des identités : Azure AD PIM, Révisions d’accès, Gestion depackages d’accès

Comprendre les licences Azure AD et leurs apports sécuritéIl n’est pas possible de parler de la sécurité des identités dans unenvironnement Microsoft sans évoquer les différents niveaux de licences.

Les éditions Azure AD Premium ajoutent des fonctions d'administrationavancées, le contrôle d’accès conditionnel, les groupes dynamiques, laprotection des identités, des fonctions en libre-service pour les utilisateurset également un niveau de service plus élevé (99,99% garanti depuis2021).

Une autre fonctionnalité d’Azure AD Premium est Application Proxy. Ceservice permet aux organisations de raccorder des applications intranettraditionnelles à Azure AD. Ce raccordement se fait via la jonction entredes protocoles modernes (basés sur des revendications d’identités) et desanciens protocoles comme Kerberos ou NTLM.

Pour bénéficier des principales fonctionnalités de sécurité, un utilisateurinterne doit avoir une licence comme indiqué ci-dessous :

AZURE AD GRATUITE / O365

AZURE AD PREMIUM P1

AZURE AD PREMIUM P2

Security defaults

Intégration avec MIPRéinitialisation de mot de passe

en libre serviceProtection des mots de passe

Azure MFAAccès conditionnel (1)

Protection des identités (2)

Gouvernance des identités (3)

FO

CU

S

4040

Microsoft a introduit en 2019, les Security Defaults, des politiques desécurité prédéfinies par Microsoft permettant d’assurer une posture desécurité minimale, sans condition de licence :

Pour personnaliser ces politiques, des licences Azure AD Premium Plan 1ou 2 sont nécessaires.

Il est à noter que les Security Defaults ne peuvent pas être activés enmême temps que des politiques d’accès conditionnel.

Security Defaults : un niveau de sécurité minimal accessible à tous

Pour les administrateurs activation d’une authentificationmulti-facteur à chaque connexion1

Pour les utilisateurs activation d’une authentification multi-facteur en cas de connexion risquée2

Pour tous les utilisateurs enregistrement d’un facteur MFAdans les 14 jours suivant leur première connexion3

Désactivation des protocoles hérités4

Accès au portail Azure AD seulement pour lesadministrateurs5

40

FO

CU

S

414141

Quelle gouvernance pour AzureActive Directory ?

Dans un certain nombre d’organisations, la responsabilité de l’AzureActive Directory tombe dans un no man’s land. Cela est en grandepartie dû à l’absence de cible :/ Simple annuaire technique pour Office 365/Teams ou futur

référentiel d’identité pour les applications de l’organisation ?/ Référentiel d’identité pour les applications cloud uniquement ou

également pour les applications hébergées en interne ?

Quels acteurs aujourd’hui ?

Dès que l’on parle administration d’Azure AD, trois acteurs sontgénéralement présents :

/ L’équipe Identité pour la mise en place de la synchronisation etla fédération ou pour le raccordement d’une application.

/ Habitués à avoir des droits à importants sur l’Active Directory,ils héritent d’un rôle Global Administrator, bien qu’ils nepossèdent pas encore les compétences requises pour ce rôle.

/ L’équipe Digital Workplace pour la configuration des servicescollaboratifs. Cette équipe a souvent étendu son périmètre au-delà d’Exchange ou de SharePoint Online par opportunité. Bienque la gestion de l’identité ne soit pas historiquement de leurressort, il s’agit souvent de la seule équipe avec lescompétences pour gérer des sujets liés à la collaboration (e.g.invités, accès conditionnel ou applications tierces)

/ L’équipe Sécurité pour la définition des politiques de sécuritéet le contrôle des configurations en place.

Quels principes pour la gouvernance sur Azure AD ?

La logique est similaire pour Active Directory comme pour AzureActive Directory. Le modèle opérationnel doit suivre deux principesfondamentaux : ségrégation des droits et moindre privilège. En somme,tout ce qui est délégable doit être délégué.

En revanche, Azure AD ne permet pas le même niveau de délégationque sur Active Directory (où tout peut être délégué en modifiant leschéma), bien que Microsoft ait introduit plusieurs évolutions en cesens récemment.

FO

CU

S

424242

Quelles possibilités de délégation ?

Il convient tout d’abord de différencier le contenant (Azure AD et lesbriques d’infrastructure de synchronisation et fédération sous-jacentes) et le contenu (identités utilisateurs, applicatives et liées à desterminaux).Microsoft propose un modèle RBAC (Rôle Based Access Control) avecdes rôles natifs. Parmi ces rôles, on retrouve des rôles d’administrationdu tenant Azure AD, des services Office 365 ou des différentesidentités. A noter, seul le rôle administrateur général peut être utilisépour modifier certains paramètres généraux, comme la chartegraphique de la page de connexion.

Microsoft a introduit en 2019 la possibilité de faire des rôlespersonnalisés en s’appuyant sur les API. Pour l’instant, seules lesactions liées à l’administration des applications sont utilisables lors dela définition d’un de ces rôles.Il sera également indispensable de garder en tête qu’Azure AD est aujourd’hui pensé comme une organisation centralisée, même si Microsoft a publié en 2021 les unités d’administration, équivalent des Unités Organisationnelles (UO) locales, afin de limiter le champ d’action d’un administrateur.

Quels scénarios possibles pour la gestion d’Azure AD ?

Afin de respecter les principes ci-dessus, il est nécessaire d’identifierdes équipes avec chacune des responsabilités et des droits qui lui sontpropres.Pour la gestion des contenus, cela n’est pas très compliqué si l’on metde côté le caractère centralisé de la plateforme. Les équipes DigitalWorkplace seront par exemple logiquement en charge des services etdonnées Office 365. La gestion du contenant reste LA questioncentrale.

Une équipe centrale devra être définie avec les droits d’administrateurgénéral. Elle aura pour mission de réaliser toutes les tâchesd’administration à très hauts privilèges, qui pourront sortir dupérimètre strict de l’identité./ Cette équipe devra être dimensionnée et formée/ Des processus avec des SLAs devront être mis en placeL’équipe centrale n’étant pas en mesure de définir toutes lesfonctionnalités accessibles par tel niveau d’administration, laresponsabilisation des bonnes équipes sera clé (e.g. la communicationpour la charte graphique).Etant donné que ces droits ne seront utilisés que rarement, il estessentiel de maîtriser qui peut y accéder et quand (via un bastion ouAzure AD PIM).Un scénario pourrait être de confier cette responsabilité à l’équipeidentité afin de maintenir une cohérence avec la gestion des identitéset la qualité des données. Un autre pourrait être de former une équipecentrale garante des applications à portée Groupe.

FO

CU

S

43

Migrer d’Active Directory vers Azure Active DirectoryDans une stratégie demodernisation, larecommandation de Microsoftest, à terme, de réduire ActiveDirectory au fur et à mesure queles applications et les ressourcesinternes seront disponiblesdepuis le cloud, que ce soit sousla forme d’applications SaaS oubien tout simplementd’applications existantes.

Alors que les identités vontmigrer dans Azure AD, les postesde travail vont quitter ActiveDirectory pour être gérés depuisun service MDM dans le cloud.Cette bascule va avoir pour effetde progressivement limiter sonexposition aux attaques.

La gestion des identités avec unservice cloud comme Azure ADest plus simple à appréhender(moins de concepts à maîtriser etpas de composantsd’infrastructure à mettre à jour).

En migrant vers Azure ActiveDirectory, il est plus simple debénéficier de l'analyse centraliséedes événements de connexion,facilitant ainsi la détection desattaques à faibles volumes etégalement des anomalies deconnexion.

Pourquoi joindre unappareilàAzureAD?Il y a plusieurs intérêts à joindreun appareil à Azure AD :/ Renforcer le contrôle d’accès

conditionnel en se basant surl’état de santé de l’appareil oul’emplacement géographique ;/ Accéder de manière simple etsécurisée aux applications cloudavec une expérience SSO àtravers l’obtention d’un PRT(Primary Refresh Token) ;/ Gérer les appareils à l’aided’une solution de MDM ;/ Déployer l’authentificationsans mot de passe de typeWindows Hello for Business ouFIDO2.

Qu’est-ce qu’Azure AD DS ?Azure AD DS (Azure ActiveDirectory Domain Services) estl’annuaire AD sous la forme d’unservice cloud proposé parMicrosoft comme il peut existerchez d’autres fournisseurs cloud.De manière simplifiée, le Tier 0est ici géré par Microsoft, tandisque les autres tiers sont géréspar l’organisation. Azure AD DSfournit un sous-ensemble defonctionnalités Active Directorycomme la jonction de domaine,les stratégies de groupe (GPO),le protocole LDAP etl’authentificationKerberos/NTLM.

C’est une solution à envisagerpour les serveurs Windows quel’on migre en lift-and-shift dans lecloud ou bien que l’on souhaiteretirer de la forêt AD deproduction.

4444

Aucun compte ActiveDirectory ne doitdisposer

deprivilèges élevés sur le cloud

Gérer les appareils desadministrateurs àpartir du

cloud

Protéger le cloud d’une compromission de l’AD

44

1 3

3 4

Isoler complètement lescomptes administrateurs

Microsoft 365et Azure AD

Les comptes administrateurs doiventêtre :/ Créés depuis Azure AD;/ Authentifiés avec l'authentification

multi-facteurs (MFA);/ Contrôlés par l'accès conditionnel

d'Azure AD;/ Accessibles uniquement en utilisant

des postes de travail gérés dansAzure;

/ Activés sur une plage de tempslimitée avec Azure AD PIM.

2

Assurez-vous que ces comptes, ycompris les comptes de service, nesont pas inclus dans les rôles ougroupes privilégiés du cloud et que lesmodifications apportées à ces comptesne peuvent pas avoir d'impact surl'intégrité de votre environnementcloud. Les éléments on-premises duTier 0 ne doivent pas être en mesured'avoir un impact sur les comptes ourôles privilégiés deMicrosoft 365.

Utiliser Azure AD Join et la gestion desappareils de type MDM dans le cloudpour éliminer les dépendances àl’infrastructure de gestion des appareilson-premises, qui peuventcompromettre les mesures de sécuritédes appareils servant à administrer lecloud.

Utiliser l'authentificationAzure AD pouréliminer les

dépendances vis-à-vis de l’AD

Utiliser toujours une méthoded’authentification forte, telle queWindows Hello for Business, FIDO2 ouMicrosoft Authenticator.Passer à une méthoded’authentification sans mot de passe etenvisager de supprimer les mots depassesurces comptes.

FO

CU

S

45

Lorsque l’on évoque, un projet demigration vers Azure AD, il estnaturel de se poser la questionsuivante : « Quand Azure ADpourra-t-il remplacercomplètement ActiveDirectory » ? Bien qu’il soittentant de chercher une dateprécise, il faut garder à l’espritqu’Azure AD n’est pas « ActiveDirectory dans le cloud » et que,de ce fait, il ne faut pas chercher

à retrouver les mêmesfonctionnalités.

Cette transition devrait prendreplusieurs années, tant du côtédes organisations que pourMicrosoft. À l'heure actuelle,toutes les technologies ne sontpas encore disponibles pourpasser à un déploiement « 100 %cloud Azure AD ».

Pour ne pas tomber dans le pièged’attendre qu’une solutionparfaite soit disponible (couvranttous les cas de figure), le mieuxest d’aborder ce voyage versAzure AD dès maintenant, et defaçon pragmatique sans chercherà couvrir tous les cas.

Schématiquement, un annuaireActive Directory contient desappareils, des applications et desutilisateurs. La trajectoire demigration va prendre en compte

ces trois éléments, afin de lesdéplacer au fur et à mesure dansAzure AD.

Les organisations ayant un existant fort avec Active Directory auront une trajectoire de migration vers Azure AD qui sera plus ou moins rapide, en fonction du nombre d’objets à migrer mais également de la complexité de l’environnement AD comme le nombre de forêts existantes.

Le voyage vers Azure AD

4646

Se moderniser sur trois piliers

Appareils

Placer les postes de travailWindows 10 existants, enmode Hybrid Azure ADJoin

Joindre nativement à AzureAD, les nouveaux postesWindows 10/Windows 11 àl’aide deWindowsAutopilot

Applications

Migrer, dans la mesure du possible, l’authentification des applications dans Azure AD

Migrer les serveurs de fédération AD FS vers Azure AD

Migrer vers Azure AD DS les applications trop anciennes basées sur NTLM et ne pouvant migrer sur des protocoles plus modernes

Utilisateurs

Généraliser l’authentification forte et sans mot de passe pour tous les utilisateurs

Déployer le nouvel outil Azure AD Connect Cloud Syncqui simplifie la gestion en centralisant la configuration dans Azure AD, facilite les déploiements en haute disponibilité et donne accès aux nouveaux scénarios comme le support des environnements multi-forêts AD en mode déconnecté

FO

CU

S

47

Pour les organisations qui fontchoix de la modernisation vers leCloud, la transition vers Azure ADest progressive, par étapes : ensynchronisant les utilisateurs, enmigrant les postes de travail, enintégrant les applications dansAzure AD puis en migrant lesserveurs d’application éligiblesdans le cloud.

Au fur et à mesure, le contenu del’Active Directory est réduit etsimplifié. La priorité est de migrerrespectivement le Tier 2 et leTier 1 dans Azure AD et Azure ADDS.

Le centre de gravité se déplacevers Azure AD qui devient le plande contrôle Zero Trust etl’environnement où lesressources sont d’abord crééespuis synchronisées si besoin enlocal vers Active Directory.

L’Active Directory est isoléprogressivement pour serviruniquement les scénarioscritiques et les applications quine peuvent pas migrer vers lecloud. Le seul investissementpérenne est la mise en place duTier 0 et le durcissement de laconfiguration Active Directory.

Dans cette transformation, lesappareils ne sont plus présentsdans Active Directory mais

directement intégrés dans AzureActive Directory et gérés par dessolutions modernes de typeMDM.En intégrant les applications dansAzure AD, l’approche sécurité semodernise : notamment enpubliant les applications IaaS eton-premises qui n’ont pas encoremigré vers le cloud, à traversAzure AD Application Proxy.

Rendre les applicationsaccessibles depuis Internet demanière sûre, sans recourir à unréseau privé virtuel (VPN), est unchangement majeur pour denombreuses organisations mêmesi le split-tunneling est uneapproche de plus en pluscourante.

Pour les applications qui ont unedépendance forte à ActiveDirectory, une piste à privilégierest de migrer ces applicationsvers Azure AD Domain Services.

Azure AD devient l’annuaire deréférence depuis lequel lesidentités sont synchronisées versles référentiels tiers, comme l’ADen local.

Au fil du temps, l’Active Directorydevient une préoccupation moinsimportante, avec la diminution dunombre d’actifs gérés.

47

…

Quelle trajectoire de modernisation ?

48

Les étapes en détailsLa progression d’un projet detransformation Active Directoryvers Azure AD peut se mesurer àl’aide des étapes suivantes :1. Premiers pas vers le cloud

et utilisation d’Azure AD2. Généralisation du mode

hybride3. Investissements centrés

sur le cloud4. AD isolé et réduit au

minimum5. 100% cloud – Azure AD

Premierspas

Pour accéder à Office 365 et plusglobalement aux services ducloud Microsoft, les organisationspossèdent un tenant Azure ADqui contient a minima les objetsutilisateurs.

Il s’agit de l’état de touteorganisation ayant commencé àutiliser le cloud Microsoft : unannuaire Active Directory on-premises ; des appareils joints àAD dont la configuration est faiteà l’aide de stratégies de groupes(GPO); des applications on-premises utilisantl’authentification intégrée ADpour contrôler l’accès desutilisateurs; et enfin des

utilisateurs qui sont créés dansl’AD à partir de systèmes RH puissont synchronisés d’AD versAzure AD à l’aide de l’outil AzureAD Connect.

ModeHybride

La prochaine étape, que denombreux clients explorentactuellement, consiste à devenirhybride et à tirer parti desservices de sécurité disponiblesdans Azure AD dans la versionde base mais également dans lesversions Premium commel’authentification sans mot depasse, le contrôle d’accèsconditionnel, la gestion desidentités privilégiées ou bien laréinitialisation du mot de passeen libre-service pour lesutilisateurs.

Les appareils Windows existantssont déclarés dans Azure AD àl’aide du mode Hybrid Azure ADJoined, (ce qui facilite le SSO).

Certaines applications sontmigrées vers le cloud sur uneinfrastructure IaaS, en s'intégrantà Azure AD Domain Services.

49

D’autres applications existantessont toujours hébergées sur sitemais sont publiées pour lesutilisateurs en télétravail àtravers Azure AD App Proxy.Cela permet de donner un accèsexterne sans VPN tout enprotégeant l’accès avec AzureActive Directory.

Êtrecentrésur lecloud

Durant cette phase, la décisionest prise de ne plus ajouter denouveaux appareils ou denouvelles applications dansActive Directory. Lesinvestissements sont en prioritéfaits dans le cloud. Les projetsd’intégration avec ActiveDirectory sont ralentis afind’arrêter d'étendre la dettetechnique.

La priorité est ici de migrer leTier 2 et le Tier 1 dans AzureAD.

Les organisations cessent danscette phase d’intégrer lesnouveaux appareils dans ActiveDirectory et vont à la placejoindre les nouveaux postes detravail directement à Azure ADavec Autopilot et une assurer unegestion par un MDM commeMicrosoft Endpoint Manager. LesGPO ne sont plus utilisées pourgérer les nouveaux appareils.

Les applications fédérées sontmigrées progressivement versAzure AD. Elles sont hébergéesdans le cloud et utilisent AzureAD pour l'authentification. Lesapplications existantes sontpubliées progressivement àtravers Application Proxy (et, sinécessaire migrées dans AzureAD Domain Services). Lesapplications nécessitant d’avoirdes profils utilisateurs àsynchroniser utilisent leconnecteur ECMA.

Les applications existantesutilisent Azure AD DS et sontpubliées à travers App proxy.

Les partages de fichiers et lesserveurs d’impression sontmigrés progressivement vers lecloud. Les services Azure Files etUniversal Print sontprogressivement utilisés.

50

En cible de cette étape, ActiveDirectory doit être réduit àl’administration des ressourcesinternes n’ayant pas vocation àmigrer dans le cloud (parexemple, systèmes industriels)avec des stationsd’administration renforcées, unesegmentation réseau et dessystèmes de détection garants dela sécurité sur un périmètredésormais excessivementrestreint. Si cela n’a pas étéréalisé auparavant, la priorité estalors de mettre en place le Tier 0et de durcir la configurationActive Directory.

Au fur et à mesure, les utilisateurssont créés et gérés uniquementdans Azure AD avec unestratégie « Cloud-first » et sontsynchronisés vers ActiveDirectory uniquement sinécessaire à travers lafonctionnalité de Write-back.

Le passage à cette étapenécessite de moderniser lesapplications existantes : enmettant à jour la configuration, lecode des applications ou en lesremplaçant avec une versioncloud équivalente.Lorsqu’Azure AD intègrera lacapacité d’émission de tickets deservice Kerberos, il sera alorspossible de continuer à prendreen charge les applicationsexistantes compatibles Kerberos,et ceci sans avoir besoin decomptes utilisateurs dans ActiveDirectory. De plus, les servicesAD managés comme Azure ADDS aident à supporter lesapplications existantes sur desserveurs IaaS en proposant leservice AD dans le cloud.

50

Isolement de l’AD

51

Enfin, l'étape 5 est celle du« 100% Cloud Azure AD », oùl’organisation n’a plus aucuneempreinte Active Directory. A cestade, il n’y a plus de contrôleursde domaine Active Directory etAzure AD fournit tous les outilsde gestion des identités.

Les applications authentifient lesutilisateurs à travers Azure ADavec des protocoles modernes ouà travers le support de Kerberosavec Azure AD DS et Azure AD.Bien entendu, à ce stade tous lesappareils sont joints uniquementà Azure AD et gérés avec unMDM compatible.

Principaux sujets à adresser pour passer en 100% Azure AD

NTLM

Kerberos /OpenID Connect

GPO

Stratégie MDM

AD Join

Azure AD join

FREIN

CIBLE

COMPLEXITÉ

FullCloud

52

Améliorer sa posture de sécurité

Vous avez dit «ZeroTrust» ?Aborder la cybersécurité sousl’angle de l’identité est une destendances de fond que lesorganisations tentent d’adresserà travers l’approche « Zero Trust». Le principe ? ne jamais faireconfiance, toujours vérifier.

A chaque demande deconnexion, le contexte d’accèsest analysé pour évaluer le niveaude confiance que l’on peutaccorder à l’utilisateur, à sonappareil mais également auxapplications.

Cette approche de la sécuritéprotège les organisations enaccordant l'accès sur la based'une vérification continue desidentités et de la posture desécurité des appareils.

La fin du VPN avec le ZeroTrust ?Une idée fausse et très répandueest que le passage à unearchitecture « Zero Trust »signifie qu’il est possible desupprimer tous les accès VPNpour l’accès à distance auxressources de l’entreprise.

La réponse n’est pas aussi simple.Par exemple, si les postes detravail sont Hybrid Azure AD Join,alors ces appareils doivent avoirde temps à autre uneconnectivité vers un contrôleurde domaine, car ils sont joints àActive Directory et Azure AD.

L’autorité de référence signant levérificateur des secretsd’authentification sur l’appareil,pour ouvrir une session en modedéconnecté, est Active Directory.Si le cache des crédentités estvidé ou désynchronisé pour avoirde nouvelles crédentités encache, l’appareil doit dialogueravec un contrôleur domaine. Celadoit se faire à l'aide d'uneconnexion VPN ou sur le réseaude l’organisation.

Autre exemple: lorsquel’utilisateur oublie son mot depasse et demande à le réinitialiserou le fait lui-même à travers unservice de type libre-service, sonappareil doit pouvoir joindre uncontrôleur de domaine ActiveDirectory pour utiliser le nouveaumot de passe et déverrouillerl’ordinateur.

La même exigence deconnectivité on-premises estvalable lors de la premièreconfiguration de Windows Hellofor Business sur un appareilHybrid Azure AD Join : l’appareildoit avoir une connectivité versun contrôleur de domaine pourfinaliser la configuration deWindows Hello for Business(définition du code PIN, premièreouverture de session avecWindows Hello for Business).

Ces contraintes n’existent pasavec un appareil Azure AD Joinqui ne nécessite pas deconnectivité vers ActiveDirectory contrairement auxscénarios précédents.

53

La technologie « Always OnVPN » , nativement présente àpartir de Windows 10, est trèsutile pour établir un tunnel VPNavant même que l’utilisateurn’ouvre une session et assurerainsi cette exigence deconnectivité interne.La modernisation du VPN versune approche plus flexible detype Split-Tunneling augmenteles chances de succès à longterme lors de la mise en œuvred’une architecture Zero Trust.

Encadrer les mots de passeLe password spraying(pulvérisation de mots de passe),une attaque qui donne lieu à untiers des compromissions decomptes, consiste à testerquelques mots de passe faiblessur un très grand nombre decomptes utilisateurs, plutôt quede nombreux mots de passecourants. La dangerosité de cetteattaque est liée au fait que lesmesures de sécurité habituelles(blocage des comptes outemporisation entre des essaissuccessifs) sont inefficaces.

L’utilisation d’Azure AD, permetde détecter les modèlesd’attaque de type passwordspraying en examinant lestentatives de connexionéchouées pour des millionsd’organisations dans le mondeentier. Cette protection peut êtreétendue à Active Directory àtravers un agent à installer sur lescontrôleurs de domaine et ensuivant les instructions du guidede déploiement.

Se diriger vers l’authentification sans mot de passeOn observe un engouementimportant pour l’authentificationsans mot de passe. Riend’étonnant quand on sait que lesmots de passe sont responsablesde 80% des portes d’entrée pourles pirates et qu’on estime que ledéploiement de l’authentificationmulti-facteur réduit le risque decompromission de 99,9%.

L’authentification s’appuie surune caractéristique biométriquetelle qu’un visage, une empreintedigitale, ou un code confidentielpropre à un appareil et qui n’estpas transmis sur le réseau. Vousaurez le choix entre l’utilisationde votre ordinateur Windowsavec biométrie et/ou code PIN, laconnexion par clé de sécuritéFIDO2 ou l’application MicrosoftAuthenticator pour les appareilsmobiles.

Selon une enquêteréalisée par Microsoftauprès de responsablesinformatiques deplusieurs pays ayantentamé leur voyageZero Trust, il ressort que76% ont implémenté enpremier lieu uneauthentification forte et60% l’accèsconditionnel basé surdes politiques.

Ce chapitre partage les principales difficultéspour reconstruire un Active Directory etpropose des actions à mener pour se préparerà une cyberattaque.

Comment faire face à une cyberattaque ?

55

Connaitre les difficultés de la reconstruction d’Active Directory pour mieux anticiper la crise

Des effets de bord difficiles à prévoir et à traiter dans de très courts délaisDeux méthodes dereconstruction AD peuvent êtremises en œuvre suite à unecompromission : unereconstruction à partir de zérodes contrôleurs de domaine et del’annuaire ou une reconstructiondes contrôleurs de domaine maisavec réplication de l’annuaireexistant.

La première option permet des’assurer de la bonne suppressiondes éventuels moyens depersistance de l’attaquant maisrequiert d’importants efforts dereconstruction et uneinterruption de serviceimportanteÀ l’inverse, la seconde possibilitépermet une reprise du service ADplus rapide, tout en negarantissant pas de manièrecertaine l’intégrité de l’annuaire.

Des effets de bordsopérationnels, pouvant fortementvarier selon l’environnement, sontà prévoir en cas dereconstruction. Lors d’unereconstruction Active Directory àla suite d’une attaque, parexemple de type ransomware,des actions de durcissement etremédiation sont prises : cesactions sont souvent mises enœuvre sans phase d’analyse et detests. Ils peuvent notamment êtreà l’origine d’effets de bordsopérationnels.Les effets de bords notablessuivants peuvent notamment êtrecités :/ rupture du Secure Channel

entre les machines et Active Directory suite à la réinitialisation / restauration de comptes ordinateurs ;

/ dysfonctionnement d’applications reposant sur des comptes de service dont le mot de passe a été réinitialisé ;

/ invalidation des droits d’accès (ACL) sur les partages de fichiers réseau (en cas de reprise from scratch invalidant les SID définis sur les ressources) ;

/ nécessité de migrer des serveurs obsolètes ne pouvant plus s’authentifier suite à la désactivation des protocoles d’authentification legacy.

Par ailleurs, une absence devision d'ensemble sur le Systèmed’Information peut grandementcomplexifier la

La reconstruction consécutive àun incident cyber majeur, estsouvent l’opportunité pour lamise en place à marche forcéede mesures de sécurité, paropposition à la méthode « despetits pas » employée dans lecadre d’un projet standard pourne pas perturber les activités.

56

reconstruction (documentsnumériques détruits, copiesphysiques obsolètes,connaissances résiduellespartielles, ...). Le tempsd’indisponibilité ne dépendra pasuniquement de la complexité desmanipulations mais aussi de lacapacité à mobilisersuffisamment d’experts et de lapriorité donnée à lareconstruction AD (mobilisantdes acteurs par ailleurs sollicitéspour le maintien d’un éventuelmode dégradé).

Les ressources internes sont biensouvent mobilisées sur la mise enœuvre d’un mode dégradé, audétriment des efforts dereconstruction. De plus, lapossibilité d’un renfort departenaires n’est pas garantiedans les délais de la crise : peud’acteurs disposent aujourd’huidu niveau d’expertise pouraccompagner opérationnellementles reconstructions AD.

De multiples moyens de persistance discretsEn parallèle de la remise enproduction du SI, il est nécessairede s’assurer d’éliminerles moyens de persistance del'attaquant, pour empêcher unenouvelle compromission del'environnement.Les techniques de persistance

Active Directory sontnombreuses et difficilementvérifiables dans leurexhaustivité. Si certainestechniques de persistance sontbien connues, et leur remédiationoutillée, comme lerenouvellement des secrets ducompte « krbtgt », d’autres sontplus complexes à détecter etcorriger. C’est par exemple le casdes persistances réalisées autravers de permissions et droitsétendus spécifiques ou lespersistances locales sur lescontrôleurs de domaine.

Une reconstruction complète dela forêt Active Directory, bienqu’incompatible avec une reprised’activité rapide, est souvent leseul moyen permettant des'assurer de l'éliminationcomplète des moyens depersistance AD de l’attaquantsuite à la compromission d'undomaine.Au-delà des contrôleurs dedomaine et des annuaires AD entant que tels, les ressources etserveurs auxquels les contrôleursde domaine adhérèrent, tels queles serveurs de mises à jour oul’infrastructure de gestion de clés,ou les serveurs T1, peuvent aussiavoir été compromis parl’attaquant et servir de moyensde persistance.

« Au moins une semaine est en moyenne nécessaire pour reconstruire le cœur AD sans préparation »

Le CERT-W référence de nombreuses techniques pouvant être utilisées par un attaquant pour maintenir une persistance AD après compromission

57

Ces différents éléments, composant le cœur de confiance du SI, doivent faire l’objet d’un plan d’action adapté selon la connaissance de l’attaque apportée par les investigations numériques.

Azure AD peut-il aider lors de la reconstruction?Certainement, en mettant enservice des solutions SaaS pourrétablir certains services deproductivité.

Néanmoins, Azure AD ne serapas utile dans les cas suivants :

/ La grande majorité desapplications utilisées dans lesorganisations sont liées à l’AD.Les autorisations sontgénéralement attribuées surdes comptes basés sur l'ActiveDirectory on-premises et lesapplications ne savent mêmepas ce qu'est Azure AD

/ Les organisations ne peuventjoindre (nativement) que lespostes de travail (Windows10/Windows 11) à Azure ADmais pas les serveurs

C’est pourquoi, il reste essentield’avoir une sauvegarde régulièreet déconnectée d’ActiveDirectory, pour être en mesured’être résilient après une attaquede type ransomware.

57

585858

Préparer la reconstructionde l’Active Directory

Sauvegarde de l’AD résiliente aux scénarios decyberattaques retenus et protégéeWindows backup chiffré et hébergé sur un espace immuable

Incontournables

Environnement de confiance pour reconstruireInfrastructure et réseau indépendants

Recommandés

Savoir mobiliser les bonnes personnesÉquipes d’audit, de réponse à incidents, de gestion de crise,opérationnelles

Accéder aux applications du SI sans Active DirectoryAzure AD standalone pour Office 365, comptes locaux

Disposer de procédures d’assainissement et dereconstruction de l’Active DirectoryFormaliser, automatiser et s’entrainer

Accéder au SI sans dépendances à l’ADPoste d’administration sain, by-pass du NAC, VPN sans AD

Anticiper l’opportunité de s’appuyer sur Azure AD pourreconstruirePoste de travail en Azure AD join

À étudier

FO

CU

S

Ne pas se contenter d’une simple reconstruction de l’AD

La reconstruction d’un SI suite àune Cyberattaque est un sprintnécessitant la mobilisation detous. Le risque est cependant depenser que la course s’arrête là.Dans ce cas, il n’est pas rare desubir quelques mois ou annéesaprès une nouvelle attaque.

Ne pas se limiter à la crise mais transformer le SI La reconstruction du SI permetde faire face au plus urgent et depasser un premier palier en termede sécurité. La compromission duSI est, cependant, bien souvent,le symptôme d’une dette sécuritéde plusieurs années. Il ne sera,

par exemple, pas possiblependant la gestion de crise dequelques semaines, detransformer son modèle desécurité ni de traiter toutes lesobsolescences : le chemin decrète doit être défini pour rendreau plus vite le service au Métier.

La gestion de la crise doit êtrevue comme la première partie dela course permettant àl’entreprise de passer un cap enterme de maturité sécurité. Il estalors nécessaire de définir unprogramme de transformation duSI pour traiter la dette et biensouvent changer de modèle desécurité pour le réaligner avec lesbesoins du métier : un vraimarathon !

59

« Un programme sur plusieurs années est nécessaire pour transformer son modèle de sécurité »

« 80% des Entreprises ayant payées une rançon subissent une seconde Cyberattaque »Cybereason

60

Conclusion

La sécurité des référentiels d’identité est souvent abordéeavec de nombreux détails techniques, où les experts parlentaux experts.

Pour autant, il est possible de garder une approchepragmatique en se posant les bonnes questions : Commentest administré l’Active Directory ? Depuis quels postes detravail ? Les services ayant une relation forte avec cesserveurs, ces postes de travail sont-ils bien sécurisés ? Lavision doit être élargie et prendre en compte dorénavant lasécurité d’Azure AD, qui n’est pas une simple extensiond’Active Directory dans le cloud.

Il est nécessaire de définir une cible (court et moyenterme), en cohérence avec la stratégie de transformationde l’organisation.

La sécurité est une question d’arbitrage, il est primordial deconnaître les vulnérabilités qui exposent l’organisation touten ayant conscience du risque et des bénéfices associés.Cela aide à mieux décider de sa trajectoire demodernisation et de ses priorités.

Le modèle d’administration évolue et prend en compte lesnouvelles dimensions de l’entreprise étendue à travers cesaspects hybride et multi-cloud.

Tout au long de cette transformation, les organisationsdevront rester concentrées sur l’essentiel, avec l’identitécomme pierre angulaire de la sécurité des systèmesd’information.

Le système d’identité des organisations est dorénavanthybride et cette nouvelle réalité doit être embrassée.

61

RemerciementsAUTEURS

THOMAS DIOTSenior Consultant,

Wavestone

Photo

ARNAUD JUMELETNational Security Officer,

Microsoft France

THIBAULT JOUBERTManager,

Wavestone

CONTRIBUTEURS

PIERRE AUDONNET Principal Customer Engineer, Microsoft Canada

FLORENT BENOITPartner Technology Strategist, Microsoft France

RÉMI ESCOURROUManager, Wavestone

JEAN-YVES GRASSETChief Security Advisor, Microsoft France

BENOÎT MARIONSenior Manager, Wavestone

GREGORY SCHIROCompromise Recovery Security Practice, Microsoft

JULIEN ROUSSON Manager, Wavestone

ÉTIENNE LAFORESenior Manager,

Wavestone

ALEXANDRE LUKATManager,

Wavestone

62

Liens utilesANSSI - ACTIVE DIRECTORY CONTROL PATHShttps://github.com/ANSSI-FR/AD-control-paths

ANSSI - LE SERVICE ACTIVE DIRECTORY SECURITY (ADS)https://www.ssi.gouv.fr/administration/actualite/le-service-active-directory-security-ads-accompagner-la-securisation-des-annuaires-active-directory-des-acteurs-critiques/

ANSSI - POINTS DE CONTRÔLE ACTIVE DIRECTORYhttps://www.cert.ssi.gouv.fr/uploads/guide-ad.html

ANSSI - RECOMMANDATIONS DE SÉCURITÉ RELATIVES À ACTIVE DIRECTORYhttps://www.ssi.gouv.fr/guide/recommandations-de-securite-relatives-a-active-directory

M365INTERNALS - INCIDENT RESPONSE IN A MICROSOFT CLOUD ENVIRONMENT (HUY KHA)https://m365internals.com/2021/04/17/incident-response-in-a-microsoft-Cloud-environment/

MICROSOFT - APPENDIX L: EVENTS TO MONITORhttps://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor

MICROSOFT - AZURE ACTIVE DIRECTORY SECURITY OPERATIONS GUIDEhttps://docs.microsoft.com/en-us/azure/active-directory/fundamentals/security-operations-introduction

MICROSOFT - BEST PRACTICES FOR AZURE AD ROLEShttps://docs.microsoft.com/en-us/azure/active-directory/roles/best-practices

MICROSOFT – DÉTAILS DES LICENCES AZURE AD https://www.microsoft.com/en-us/security/business/identity-access-management/azure-ad-pricing

MICROSOFT - ENTERPRISE ACCESS MODELhttps://docs.microsoft.com/en-us/security/compass/privileged-access-access-model

MICROSOFT - SECURING AZURE ENVIRONMENTS WITH AZURE ACTIVE DIRECTORYhttps://aka.ms/AzureADSecuredAzure

63

MICROSOFT – OBJETS D’APPLICATION ET PRINCIPAL de SERVICEhttps://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals

MICROSOFT - AZURE DEFENSES FOR RANSOMWARE ATTACKhttps://azure.microsoft.com/en-us/resources/azure-defenses-for-ransomware-attack/

MICROSOFT – QU’EST-CE QU’IDENTITY SECURE SCORE ?https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/identity-secure-score

MICROSOFT – SECURISATION DES COMPTES DE SERVICE AZUREhttps://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-introduction-azure

MICROSOFT – DOCUMENTATION SUR LES IDENTITES EXTERNEShttps://docs.microsoft.com/fr-fr/azure/active-directory/external-identities/

MICROSOFT – MICROSOFT AZURE AD ASSESSMENThttps://github.com/AzureAD/AzureADAssessment

64

Microsoft s’engage en faveur d’un numérique de confiance,inclusif et durable. Sa mission est de donner à chaqueindividu et chaque organisation les moyens de réaliser sesambitions, à l’ère du Cloud intelligent et de l’intelligentedge.

Catalyseur de l’innovation dans l’Hexagone depuis près de40 ans, Microsoft France est présidée par Corine de Bilbaodepuis juillet 2021. Avec plus de 1 800 collaborateurs et 10500 partenaires économiques, technologiques, acteurs dusecteur public, chercheurs ou start-ups, Microsoft Francecontribue au développement de l’économie et descompétences numériques sur l’ensemble du territoirefrançais

6565

Dans un monde où savoir se transformer est la clé dusuccès, Wavestone s’est donné pour mission d’éclairer etguider les grandes entreprises et organisations dans leurstransformations les plus critiques avec l’ambition de lesrendre positives pour toutes les parties prenantes. C’est ceque nous appelons « The Positive Way ».

Parmi les leaders indépendants du conseil en Europe,Wavestone rassemble plus de 3 000 collaborateurs dans 8pays dont plus de 600 consultants en cybersécurité. Cesderniers accompagnent des organisations sur tous lesenjeux de cybersécurité, des plus stratégiques à la mise enœuvre opérationnelle, en passant par la réponse à incidentet l’investigation numérique.Wavestone est coté sur Euronext à Paris.

Plus d’informations sur www.wavestone.com/fr/@Wavestone_@RiskInsight

T +33 (0)1 00 00 00 00 | M +33 (0)6 00 00 00 00

firstname.lastname@wavestone.com

First Name LAST NAMELevel (Partner…)

T +33 (0)1 00 00 00 00 | M +33 (0)6 00 00 00 00

firstname.lastname@wavestone.com

First Name LAST NAMELevel (Partner…)

T +33 (0)1 00 00 00 00 | M +33 (0)6 00 00 00 00

firstname.lastname@wavestone.com

First Name LAST NAMELevel (Partner…)

www.wavestone.comwww.microsoft.com