Plus d’infos sur la MFA obligatoire pour Azure

En cette fin juin 2024, Microsoft nous partage un peu plus d’informations sur la future MFA obligatoire à venir pour Azure à partir de juillet 2024. Plusieurs grandes étapes sont maintenant mentionnées et intégrées dans un planning qui démarre dès cet été et se terminera début 2025. De plus, Microsoft nous propose également donc quelques outils pour nous y préparer.

Mi-mai, Microsoft annonçait via le Tech Community une modification majeure à venir concernant l’authentification sur Azure : MFA pour tous ! A ce moment-là, j’avais déjà rédigé un premier article, dont voici le lien MFA pour tous les utilisateurs d’Azure à partir de juillet 2024.

Un second post sur le Tech Community est apparu hier sur ce même sujet, et nous donne quelques informations sur les 2 phases de cette obligation liée à Azure :

Phase 1 – À partir de juillet 2024 : La notification puis l’obligation de la MFA pour le portail Azure sera progressivement étendue à tous les tenants.
Phase 2 – À partir de début 2025 : La notification puis l’obligation de la MFA aux outils de commande liés à Azure : CLI, Azure PowerShell et les outils Infrastructure as Code (IaaC) sera progressivement étendue à tous les tenants.

Merci à Merill Fernando pour ce schéma :

Partant de ces informations, nous pouvons en déduire les points suivants :

Portail Azure : Le portail Azure est utilisé par les humains, il faudra alors former les utilisateurs et configurer pour chacun d’entre eux une méthode MFA.
Autres outils : D’autres outils (CLI, Cloud Shell, …) sont utilisés par les humains et certains applications. Ces dernières pourront elles faire l’objet d’une bascule vers des identités managés ou des comptes de service.
Impact progressif : Les entreprises utilisant Azure doivent se préparer à une transition progressive des tenants. Elles auront le temps d’ajuster leurs configurations et de résoudre les problèmes potentiels avant que l’implémentation complète ne soit réalisée.

Microsoft a t-il prévu de notifier les administrateurs Azure ?

Microsoft a privilégié la notification des administrateurs globaux 60 jours avant la mise en application des phases 1 et 2. Cela sans doute pour laisser les entreprises organiser les messages et notifications en interne aux personnels Azure impactés par cette mesure.

Le compte à rebours de la mise en application pour votre/vos tenant(s) ne commence pas tant que vous n’avez pas reçu cette première notification de notre part. En outre, nous enverrons des rappels périodiques aux administrateurs globaux à intervalles réguliers entre la première notification et le début de la mise en application pour votre/vos tenant(s).
Tech Community

Pourrons-nous déroger temporairement à cette règle pour un tenant ?

Les mails de notification envoyés par Microsoft devraient comporter un lien pour activer une période de grâce, afin de pouvoir gérer les imprévus :

La première notification de notre part indiquant la date de mise en application pour votre/vos tenant(s) inclura également un lien pour demander la période de grâce. Des détails supplémentaires sur les types de clients, les cas d’utilisation et les scénarios éligibles à la période de grâce seront inclus dans la notification.
Tech Community

MFA pour tout Azure, mais vraiment pour tout le monde ?

Microsoft avait déjà été clair sur ce point, j’en avais également parlé dans mon précédent article :

Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement.
Jlou.eu

Malgré cette information, une confusion a déjà pu s’installer, et c’est pour cela que ce second post de Microsoft reprécise que les utilisateurs finaux non gestionnaires d’Azure ne seront pas impactés :

Les utilisateurs finaux qui accèdent à des applications, des sites web ou des services hébergés sur Azure, mais qui ne se connectent pas au portail Azure, à la CLI ou à PowerShell, ne sont pas soumis à cette exigence de Microsoft. Les exigences d’authentification pour les utilisateurs finaux seront toujours contrôlées par les propriétaires de l’application, du site web ou du service.
Tech Community

Quid des accès conditionnels d’Entra ID ou de la sécurité par défaut ?

Microsoft a décidé d’implémenter ce contrôle MFA en amont des mesures de sécurité actuelles :

Sécurité par défaut activée : aucun changement car la MFA est déjà requise pour accéder aux outils Azure.
Accès conditionnel Azure : une police d’accès conditionnel plus restrictive et nécessitant une authentification plus forte que cette nouvelle règle sera appliquée en priorité.

Quid des comptes « brise-glace » ?

En mai dernier, Microsoft ne donnait pas encore de méthodes spécifiques pour ces comptes d’urgence. C’est maintenant chose faite :

Nous avons pris connaissance de vos questions concernant les comptes « verre cassé » ou « accès d’urgence ». Nous recommandons de mettre à jour ces comptes pour qu’ils utilisent FIDO2 ou l’authentification basée sur un certificat (lorsqu’elle est configurée en tant qu’AMF) au lieu de s’appuyer uniquement sur un mot de passe long. Ces deux méthodes satisferont aux exigences de l’AMF.
Tech Community

Existe-t-il des outils pour nous y préparer ?

Pour éviter les soucis de connexion le jour J, Microsoft propose un outil de type tableau de bord, et une commande PowerShell d’extraction sous format EXCEL. Ces deux outils donne plus de visibilité sur les utilisateurs Azure concernés et mal préparés. Voici les deux liens directs mis à disposition par Microsoft :

Voici des liens directs sur deux tests réalisés dans cet article :

Test I – Configuration du Tableau de bord Entra ID :

L’utilisation de ce tableau de bord Entra ID exige certains prérequis Microsoft :

Un tenant Microsoft avec une licence Entra ID Premium P1
Une souscription Azure valide
Un Log Analytics workspace créé sur une souscription Azure

Voici le message d’erreur si vous souhaitez accéder aux workbooks d’Entra ID si la configuration n’est pas faite :

Si cela n’est donc pas déjà fait, commencez par créer un Log Analytics workspace via le portail Azure :

Cliquer sur Créer :

Renseignez les informations de votre LAW, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre LAW :

Attendez 2 minutes que le déploiement se termine :

Retournez sur Entra ID afin d’activer ou de modifier le paramétrage de sauvegarde des journaux :

Activez l’option pour sauvegarder vers votre LAW, puis Sauvegardez :

Attendez environ 5 minutes, puis Créez un nouveau workbook :

Cliquez-ici pour ajoutez du code à votre workbook :

Rendez-vous sur la page GitHub suivante afin d’y copier le code présent :

Collez le code précédemment copié, puis cliquez sur Appliquer :

Cliquez sur Enregistrer-sous pour sauvegarder votre workbook :

Renseignez les champs, puis cliquez sur Appliquer :

Attendez quelques secondes que le workbook s’enregistre :

Retournez sur le menu suivant pour vérifiez le bon enregistrement :

Cliquez sur votre workbook afin de connaitre les connexions sans MFA de votre tenant :

Afin d’avoir plus de matière dans mes logs, voici un exemple d’un autre tenant :

Filtrez les résultats avec uniquement comme application le portail Azure :

Identifiez le ou les utilisateurs connectés sans MFA :

Terminons ces tests la seconde méthode proposée par Microsoft : le script PowerShell.

Test II – Lancement du script PowerShell Entra ID :

L’utilisation de ce script PowerShell n’exige qu’un prérequis :

Windows PowerShell en version 7.0 ou supérieure

Si besoin, installez la dernière version de PowerShell. Commencez par rechercher la version la plus récente de PowerShell :

winget search Microsoft.PowerShell

Installez PowerShell et/ou PowerShell en préversion :

winget install --id Microsoft.Powershell --source winget
winget install --id Microsoft.Powershell.Preview --source winget

Validez si besoin les droits administrateurs :

Attendez que la version soit entièrement installée :

Recherchez la version 7 de PowerShell :

Lancez le script PowerShell de Microsoft :

Install-Module MsIdentityTools -Scope CurrentUser
Import-Module MSIdentityTools

Connect-MgGraph -Scopes Directory.Read.All, AuditLog.Read.All, UserAuthenticationMethod.Read.All

Export-MsIdAzureMfaReport .\report.xlsx

Authentifiez-vous avec un compte disposants des autorisations nécessaires :

Acceptez les permissions demandées :

Une fois l’authentification terminée, fermez la fenêtre du navigateur :

Attendez que l’export Excel se termine :

Ouvrez le fichier Excel généré :

Constatez sur le premier onglet un tableau récapitulatif des utilisateurs qui se sont connectés au portail Azure, à Azure CLI ou à Azure PowerShell au cours des 30 derniers jours en interrogeant les journaux de connexion et de leur méthodes MFA enregistrées :

✅ MFA Capable + Signed in with MFA : L’utilisateur a enregistré des méthodes d’authentification MFA et s’est connecté avec succès au moins une fois à Azure en utilisant MFA.
✅ MFA Capable : L’utilisateur a enregistré des méthodes d’authentification MFA mais s’est toujours connecté à Azure en utilisant l’authentification à facteur unique.
❌ Not MFA Capable : L’utilisateur n‘a pas encore enregistré de méthode d’authentification multifacteur et ne s’est pas connecté à Azure à l’aide de MFA.

Constatez sur le second onglet un graphique et des totaux des utilisateurs prêts ou non :

Conclusion – Comment se préparer avant le jour J ?

Commencez dès à présent à créer une nouvelle règle d’accès conditionnel équivalente à la future implémentation prévue par Microsoft. Il existe un template de police d’accès conditionnel très proche du résultat attendu :

Cette police cible la gestion des ressources Azure :

La mise en place de cette police en mode Report seulement est un premier pas vers la compréhension de ce qui va se passer sur votre environnement :

Vous pourrez par la suite changer son statut sur ON :

Bon courage à tous 💪🙏😎

Azure Lighthouse prend le contrôle

Azure Lighthouse existe déjà depuis longtemps. Mais je souhaitais malgré tout en faire un article car il est très utile dans bien des cas car il facilite grandement la gestion de ressources réparties sur plusieurs tenants Microsoft. Cela s’adapte donc parfaitement aux prestataires ou fournisseurs de services Cloud.

Qu’est-ce qu’Azure Lighthouse ?

Azure Lighthouse permet une gestion multi-locataire avec de la scalabilité, une automatisation plus poussée et une gouvernance renforcée des ressources.
Microsoft Learn

En d’autres termes, Azure Lighthouse vous permet d’accéder à plusieurs tenants en simultané. Cela permet de visualiser un ensemble de ressources Azure réparties sur plusieurs tenants dans une seule et unique vue.

Grâce à Azure Lighthouse, vous allez pouvoir :

Créer une relation sécurisée entre vous et vos clients gérés.
Fournir une transparence et à la demande sur l’accès et les actions.
Permettre une gestion granulaire de l’accès à l’ensemble du parc Azure.

Vous pouvez gérer plusieurs clients dans un seul Azure Lighthouse. Vous devez simplement définir comment vos équipes accéderont aux ressources des clients :

Pourquoi utiliser Azure Lighthouse pour un client ?

Gardez le contrôle : Ajoutez, modifiez ou retirez les droits des intervenants externes à tout moment grâce à la relation fournisseur de services / client établie via Azure Lighthouse.
Conservez la sécurité : Fournissez un accès granulaires aux fournisseurs de services, à des niveaux spécifiques (souscription ou groupe de ressources), et à des groupes d’utilisateurs définis, pour un accès permanent ou temporaire.
Restez informé : Veillez à ce que vos données soient toujours sécurisées et ne quittent pas votre environnement, tout en ayant une visibilité sur les actions et les changements effectués par vos fournisseurs de services.

Comment Azure Lighthouse fonctionne ?

Pour qu’Azure Lighthouse puisse fonctionner, il est nécessaire de disposer de :

Utilisateurs, groupes ou principaux de service provenant du tenant du fournisseur.
Rôles RBAC à appliquer sur les ressources du client.

Ces 2 éléments (Rôles + identités) sont alors combinés dans un template généré au format JSON depuis le tenant du fournisseur, puis exécuté sur le tenant du client.

C’est aussi simple que cela !

Note : A la place de la génération d’un template JSON, il est aussi possible de passer par la publication d’une offre fournisseur sur la Marketplace Azure.

Combien cela coûte ?

L’utilisation d’Azure Lighthouse est gratuite pour les clients et pour les fournisseurs.

Azure Lighthouse, qui s’appuie sur la technologie de gestion des ressources déléguées d’Azure, est donc disponible sans frais supplémentaires :

Quelles sont les étapes pour mettre en place Azure Lighthouse ?

Azure Lighthouse est donc configurable de plusieurs manières :

Afin de faire au plus simple dans cet article, je vous propose, au travers d’un petit exercice, de tester la seconde méthode :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Azure Lighthouse, il vous faudra disposer de :

Deux tenants Microsoft (fournisseur / client)
Tenant fournisseur :
- Un utilisateur avec des droits d’administrateur
Tenant client :
- Une souscription Azure valide
- Un utilisateur avec rôle de Propriétaire sur la souscription Azure

Afin d’identifier plus facilement les deux tenants Azure, je vous propose de configurer les couleurs du portail Azure comme ceci :

Portail Azure clair : tenant fournisseur
Portail Azure sombre : tenant client

Commençons par la configuration du tenant du fournisseur.

Etape I – Configuration du tenant fournisseur :

Connectez-vous au tenant du fournisseur afin de créer un nouveau groupe Entra ID dédié à Azure Lighthouse :

Ajoutez dans ce nouveau groupe les membres nécessaires pour tester par la suite le bon fonctionnement de l’accès aux ressources Azure situées sur le tenant du client :

Toujours sur le tenant du fournisseur, utilisez la barre de recherche comme ceci :

Cliquez sur Créer un modèle ARM (Azure Resource Manager) :

Nommez le nom de votre template ARM, puis cliquez-ici pour ajouter des autorisations RBAC :

Recherchez le groupe créé précédemment , ajoutez une autorisation que vous accorderez à vos utilisateurs d’Azure Lighthouse, puis définissez si les droits sont permanents ou éligibles :

*Pour les droits éligibles, vous devrez configurer Lighthouse avec Azure AD PIM, qui est disponible dans la licence Entra ID Premium P2.*

Cliquez sur le bouton Voir le modèle :

Cliquez sur le bouton Télécharger :

La configuration du tenant fournisseur est maintenant terminée

Ce template au format JSON est utilisable autant de fois que nécessaire, tant que les accès aux ressources Azure des clients sont identiques.

La suite se passe maintenant sur le tenant du client.

Etape II – Configuration du tenant client :

Connectez-vous au tenant du client où se trouve la souscription ou le groupe de ressources que vous souhaitez gérer.

Avant de mettre en place Azure Lighthouse, prenez le temps de vérifier sur la souscription Azure le bon enregistrement du fournisseur de ressources suivant :

Utilisez la barre de recherche comme ceci :

Cliquez ici pour voir les offres des prestataires de services :

Dans le menu Offres des prestataires de services, cliquez sur Ajouter une offre, puis sélectionnez Ajouter par le biais d’un modèle :

Téléchargez le modèle que vous avez créé précédemment :

Sélectionnez la souscription Azure, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du lien Azure Lighthouse :

Attendez environ deux minutes :

La configuration est maintenant en place. Avant de créer une nouvelle ressource Azure, nous allons contrôler le lien établi.

Etape III – Contrôle de la configuration :

Toujours sur le tenant du client, rendez-vous dans le menu suivant afin de constater l’apparition de la délégation créée précédemment :

Retournez sur le tenant du fournisseur afin de constater l’apparition du client dans le menu suivant :

Cliquez sur le bouton de paramétrage du portail Azure afin de voir dans la liste des tenants et des souscriptions provenant du tenant du client :

Toujours sur le tenant fournisseur, vérifiez la présence de la souscription client dans la liste des souscriptions Azure, puis cliquez dessus :

Contrôlez la désactivation des fonctions d’assignation car le rôle de propriétaire n’est pas disponible via Azure Lighthouse :

L’environnement client est maintenant correctement configuré.

Afin de vérifier le bon fonctionnement, je vous propose créer une nouvelle machine virtuelle sur la souscription Azure du client, depuis le tenant du fournisseur.

Etape IV – Création d’une machine virtuelle Azure :

Encore sur le tenant fournisseur, cliquez-ici pour créer une machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM en choisissant bien la souscription Azure du tenant du client, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources :

Attendez environ 2 minutes que le déploiement se termine :

Retournez sur le portail Azure du tenant du client afin de vérifier la bonne apparition de la machine virtuelle créée depuis le tenant du fournisseur :

Contrôlez les droits RBAC présents sur cette machine virtuelle :

*Notez l’absence de droits RBAC, directs ou hérités, des utilisateurs d’Azure Lighthouse.*

La création des ressources est bien possible grâce à la mise en place d’un rôle RBAC de contributeur au travers d’Azure Lighthouse.

La suppression des ressources Azure depuis le tenant du fournisseur fonctionne elle aussi sans souci :

Etape V – Modification des ressources gérées par Azure Lighthouse :

La modification ou l’ajout des ressources gérées par Azure Lighthouse est possible depuis le tenant client, sans besoin de réutiliser le template JSON du fournisseur :

Là encore, la suppression de droits sur une souscription Azure est possible à tout moment depuis le tenant du client :

Conclusion :

En quelques clics, nous avons mis en place une délégation de ressources Azure en place. Bravo ! Bien évidemment, cette liaison d’Azure Lighthouse est aussi compatible avec Microsoft Entra Privileged Identity Management.

Enfin, voici comme toujours une vidéo de John Savill qui en parle très bien :

Optimisez votre Azure : 2/4 – La sécurité

Ce billet est le second d’une série dédiée à l’optimisation sur Azure. Le premier article était dédié aux coûts générés dans le Cloud Microsoft, et les astuces pour en diminuer sa facture. Comme le titre l’indique ici, celui-ci est dédié à la sécurité sur Azure.

L’objectif de cet article n’est pas vendre ou de démontrer la sécurité absolue, mais de mettre en lumière des réflexions, des postures ou encore des mesures de sécurité essentielles. Ces actions augmenteront la sécurité sur Azure et diminueront les risques.

Enfin, nous aborderons aussi les certifications Microsoft, spécifiquement dédiées à ce sujet.

Etape I – Importants concepts de sécurité

Pour bien situer notre sujet, il n’est pas inutile de rappeler deux notions importantes.

Notion A : Défense en profondeur

Retenez bien ceci : Quel que soit l’environnement informatique, le principe de sécurité en couche s’applique. Comme un oignon, chaque couche de sécurité apporte des mesures, passives ou actives, empêchant ou retardant l’accès à la donnée, élément critique de toute entreprise :

Une architecture Cloud n’échappe pas non plus à cette règle, il est faux de penser que les solutions d’hébergement publics sont toutes à 100% protégées. Les mesures et l’intelligence dédiée à la sécurité y seront certes plus avancées, mais elles passeront par obligatoirement par votre contribution.

Dans le cadre d’Azure, Microsoft prend à sa charge la sécurité en relation avec les premières couches, votre rôle va alors dépendre du service utilisé (IaaS, PaaS, SaaS). Il est donc important d’adapter sa stratégie selon les services déployés :

Prenons l’exemple d’une machine virtuelle sur Azure (IaaS), il est de votre responsabilité de mettre en place les correctifs, de sécuriser le système d’exploitation et d’installer les mises à jour logicielles adéquates. Il en va aussi de même pour la partie réseau de cette machine virtuelle, en y apportant des mesures de sécurité adaptées (Firewall, VPN, NSG, …)

Dans le cadre de l’utilisation d’un service (PaaS), certaines mesures de sécurité sont prises en charge par Microsoft. Par exemple, Azure se charge du système d’exploitation et de certains services comme les moteurs de base de données.

Notion B : Zéro Trust

La définition de ce concept peut se résumer en quelques mots :

Ne jamais faire confiance, toujours vérifier

Comment le comprendre ?

Considérez simplement chaque demande d’accès comme potentiellement suspecte. Pour cela, Microsoft met à disposition plusieurs ressources :

Voici une première vidéo pour aller plus loin sur Zéro Trust :

Comme pour la défense en profondeur, les identités, les périphériques, les applications, le réseau, l’infrastructure et les données sont tous des maillons critiques de la chaîne Zéro Trust. Le périmètre de contrôle est horizontal car il impacte tous ces domaines :

*Comme le montre le schéma ci-dessous, le canal d’authentification est renforcé et appliqué en tout temps et dans toutes les circonstances.*

Comment aborder la sécurité sur Azure ?

La protection de votre environnement Cloud nécessite de s’occuper des identités, des données, des applications, de l’infrastructure, …

Grâce aux outils de sécurité intégrés à Azure, mettez en œuvre une stratégie de défense en profondeur par couche, unifiez la gestion de la sécurité et générez une protection avancée contre les menaces.

Une attaque plus difficile est plus coûteuse. Le piratage reste un business : plus l’attaque nécessitera de moyens pour réussir, plus elle aura de chances d’être moins rentable et donc de ne pas aller à son terme.

Pour des questions de clarté de lecture, j’ai donc scindé les chapitres suivants dans différents articles afin de vous y retrouver plus facilement dans ce qui vous intéresse :

Etape VIII : Certifications de Sécurité Microsoft

Voici un rappel du poster des certifications Cloud proposées par Microsoft. Ce document est utile car il contient toutes les certifications disponibles dans les 4 thèmes :

Historiquement, deux certifications Sécurité étaient présentes. Chacune représentait un pan du Cloud Microsoft : Modern Work Place & Azure.

MS-500 : Les Administrateurs de la sécurité Microsoft 365 sont chargés de sécuriser de manière proactive les environnements d’entreprise et hybrides Microsoft 365, de mettre en œuvre et de gérer les solutions de sécurité et de conformité, de répondre aux menaces et de faire appliquer la gouvernance des données.

Autrement dit, le but est de maîtriser la sécurité d’un environnement Microsoft 365, au travers de tous les outils de collaboration : Teams, Outlook, SharePoint, OneDrive, … Aucun mystère, beaucoup de travail et de connaissances sont à prévoir dans les différents outils 365.

AZ-500 : Les Ingénieurs Sécurité Azure sont chargés de maintenir l’état de la sécurité, d’identifier et de corriger les vulnérabilités, d’effectuer une modélisation des menaces, de mettre en œuvre une protection contre les menaces et de répondre aux escalades des incidents de sécurité.

La racine AZ dans le nom de la certification nous indique que son périmètre se porte sur Azure. Presque tous les composants disponibles sur Azure disposent de fonctionnalités natives de sécurité, activables ou non selon les besoins. Le but de cette certification est de valider les connaissances sur la maîtrise des différents outils et mesures de sécurité.

Pourquoi créer de nouvelles certifications Microsoft dédiées à la sécurité ?

Cette approche de Microsoft fut un premier pas pour couvrir l’apprentissage des grandes mesures de sécurité sur le Cloud. Depuis, la sécurité reste une préoccupation majeure pour Microsoft comme pour tous les autres acteurs du marché.

Du côté client, un besoin d’outils toujours plus performants et des formations adaptées aux équipes de sécurité sont demandés. Pour cela, Microsoft a décidé d’étoffer son apprentissage via ces nouvelles certifications dédiées à la sécurité :

SC-900 : Certification de niveau fondamental apportant les bases et les concepts de la sécurité, de la conformité et de l’identité. Elle permet de mieux comprendre les fonctionnalités des solutions Microsoft de gestion des identités et des accès. Voici mon article sur celle-ci.
SC-400 : Certification de niveau intermédiaire, la SC-400 apporte une expertise sur les moyens de protection de l’information dans un environnement Microsoft 365. Il est question de savoir mettre en œuvre des mesures de prévention contre la perte de données, de protection d’informations sensibles et de politique de conservation des données.
SC-300 : Certification de niveau intermédiaire, la SC-300 fait la part belle à la sécurité sur Azure Active Directory (Azure AD). Autant vous dire que les sujets sont vastes, en rapport avec l’importance de la gestion identité. Probablement une des certifications les plus intéressante que j’ai eu à passer. Voici là encore mon article sur celle-ci.
SC-200 : Certification de niveau intermédiaire. La gestion, le monitoring et la réponse aux menaces fait partie du quotidien des équipes de sécurité. Les principaux outils à connaitre sont Microsoft Sentinel, Microsoft Defender for Cloud, Microsoft 365 Defender. Voici également mon article sur celle-ci.
SC-100 : Certification de niveau expert, elle est encore en version beta à l’heure où ces lignes sont écrites. Le spectre de connaissances est très large : l’ingénierie de la sécurité, notamment l’identité et l’accès, la protection des plateformes, les opérations de sécurité, la sécurisation des données et la sécurisation des applications. Les personnes certifiées doivent également être familiarisées avec la sécurité dans les environnements hybrides.

Bref que du bonheur ????

Conclusion

Microsoft nous montre encore une fois l’important de la sécurité, présente partout et en tout temps. Il est donc important de mettre en oeuvre un certain nombre de mesures, mais de former régulièrement les équipes aux évolutions des attaques pour au mieux les déjouer, ou les minimiser au pire.