Au-delà du périmètre : mise en œuvre d’une gestion des identités et des accès (IAM) « zero-trust » dans les environnements hybrides et multicloud

Les environnements modernes s’appuient sur des plateformes cloud, des applications SaaS et des infrastructures hybrides, rendant ainsi obsolètes les frontières réseau. L’identité constitue le point de contrôle le plus cohérent pour l’ensemble des services, applications et environnements. 

On parle de prolifération des identités lorsque les comptes, les identifiants et les autorisations sont répartis sur des plateformes déconnectées les unes des autres, ce qui crée des angles morts et affaiblit la gouvernance. 

Les identités machines se multiplient plus rapidement que celles des humains et ne bénéficient souvent ni d’une gestion du cycle de vie, ni d’une rotation, ni d’une surveillance, ce qui rend leur protection manuelle difficile. 

En unifiant les systèmes d’identité, en imposant une authentification forte, en vérifiant en permanence les accès et en éliminant la confiance implicite entre les systèmes. 

En dressant l’inventaire de toutes les identités, en consolidant les plateformes, en imposant l’authentification multifactorielle (MFA), en automatisant la gouvernance, en segmentant les accès et en appliquant des politiques de vérification continue.

Veuillez visionner la vidéo ici pour consulter la transcription horodatée

Bonjour à tous, bienvenue à « Beyond the Perimeter ».

Je trouve que cette session a un titre génial.

C’est un excellent titre pour un film, mais euh… dans cette session, nous n’allons pas parler de
cinéma.

Nous allons parler de votre système IAM et expliquer comment le modèle Zero Trust peut vous
aider à sécuriser vos systèmes IAM et à renforcer la sécurité de vos réseaux.

Voici quelques-uns des principaux objectifs que nous allons aborder au cours de cette présentation.

Nous allons expliquer pourquoi l’identité constitue désormais le nouveau périmètre de sécurité.

Nous aborderons également les principes fondamentaux de l’IAM Zero Trust qui, selon nous, sont les plus importants pour
votre système de gestion des identités et des accès.

Et nous aborderons certaines stratégies que nous pouvons mettre en œuvre pour unifier, renforcer
et vérifier les accès au sein de votre système de gestion des identités et des accès.

À la fin, je vous présenterai également une feuille de route qui, je l’espère, vous
fournira des conseils concrets et des mesures pratiques à mettre en œuvre pour déployer le modèle « Zero Trust » dans votre

système IAM et qui vous aidera réellement à vous lancer et à remporter de premiers succès, peut-être même dès la semaine prochaine
, alors que vous réfléchirez à vos projets « Zero Trust ».

Je m’appelle Ron Robbins et je suis chef de produit senior chez Commvault. Je travaille dans
le domaine de la résilience des identités et j’aide les clients

à relever les défis liés à la résilience des identités au sein de leur organisation.

Allons-y et entrons dans le vif du sujet.

Ce que j’ai surtout retenu en préparant cette présentation,
et ce qu’il est selon moi essentiel de garder à l’esprit, c’est que

l’identité est le nouveau périmètre.

Auparavant, notre sécurité se limitait au pare-feu, n’est-ce pas ?

Nous étions habitués aux modèles de réseau traditionnels où

nous mettions en place des pare-feu, que nous configurions des VPN, et que nous considérions que notre réseau ou notre centre
de données était protégé par ces pare-feu et ces VPN.

Ce n’est plus le cas.

Vous savez, nous avons ajouté de nouvelles charges de travail, de nouvelles applications SaaS.

Nous avons intégré de nouvelles plateformes cloud à notre environnement.

Et comme l’a dit John Hawley dans un article du magazine CSO de 2012, nos centres de données
sont de plus en plus fragmentés.

Ils débordent du périmètre de sécurité rassurant des pare-feu et des VPN, ce qui, je
pense, est une excellente image pour réfléchir à la situation dans laquelle nous nous trouvons tous

aujourd’hui, où nous ne disposons plus de ce réseau traditionnel sur site où nous étions
protégés par un pare-feu et un VPN.

Mais nous nous sommes étendus bien au-delà de cela.

Par exemple, la plupart d’entre nous se trouvent dans cette situation hybride où nous disposons d’une solution sur site

et où nous utilisons également de nombreuses plateformes cloud.

Euh… Nos déploiements de messagerie instantanée sont vraiment mis à rude épreuve par cela, et Geoff Cairns soulève ce point dans un
article qu’il a rédigé pour annoncer le rapport « Forrester Wave™ ».

Il explique que les déploiements de messagerie instantanée d’aujourd’hui se caractérisent par une prolifération des identités, de multiples comptes utilisateurs
et identifiants répartis dans des systèmes cloisonnés, et que cela se traduit par une mauvaise gestion des identités

.

Et c’est vraiment un défi que nous devons relever, d’autant plus que ce phénomène ne cesse de
prendre de l’ampleur de jour en jour.

De plus, si l’on ajoute à l’équation le problème de l’IA génétique, on assiste à une explosion
de ce que l’on appelle les identités non humaines (NHI).

Dans une étude de contexte réalisée en 2025, CyberArk a constaté que les identités de machines recensées chez ses
clients

dépassent désormais les identités humaines dans un rapport stupéfiant de 82 pour 1, ce qui est tout
simplement incroyable.

Le nombre d’agents utilisant ces identités et le nombre de comptes de service qui les exploitent
.

Auparavant, nous avions cette conception d’un réseau où il n’y avait qu’une seule identité par personne.

Et nous ne gérions autrefois qu’un petit nombre d’identités.

Aujourd’hui, nous devons
gérer des milliers et des milliers de comptes de service

portant des noms tels que « compte de service 01 », « compte de service 02 », et cela devient tout simplement un énorme
problème pour nous : un véritable défi que de gérer cette explosion d’identités et d’assurer

de maintenir une bonne hygiène dans l’ensemble de cet environnement.

C’est pourquoi, aujourd’hui plus que jamais, je pense sincèrement que nous avons besoin d’une stratégie de type « zéro confiance » pour
notre environnement IAM.

Voyons donc un peu plus en détail à quoi ressemble
le défi du cloud hybride et du multicloud.

Je me demande combien d’entre vous ont mis en place une stratégie multicloud ?

Si vous n’utilisiez qu’AWS, l’actualité récente vous a peut-être montré qu’une stratégie
multicloud est quelque chose que vous devriez envisager d’adopter, où vous devez disposer d’applications réparties

sur plusieurs plateformes, sur plusieurs clouds, ou au moins de disposer d’une bascule entre
les clouds, si possible.

Nous intégrons donc ces plateformes cloud à notre organisation pour garantir la résilience.

Et nous avons alors découvert que chacune de ces plateformes cloud dont notre organisation
avait besoin disposait de ses propres systèmes IAM.

Et ces systèmes IAM ont chacun leur propre langage.

Par exemple, si vous prenez Active Directory et que vous essayez d’y
ajouter un rôle, la procédure est totalement différente de celle consistant à ajouter un rôle dans AWS IAM.

Je veux dire, certains concepts sont similaires, n’est-ce pas ?

Mais le langage et la procédure à suivre dans Active Directory et dans
AWS IAM

sont deux choses totalement différentes.

Ce que je veux dire par là, c’est qu’AWS IAM s’apparente davantage à un langage de script permettant d’accéder à un rôle ou d’y
ajouter un rôle qu’à Active Directory.

Ainsi, au-delà de l’interface utilisateur, c’est beaucoup plus complexe et cela manque de cohérence
d’un système IAM à l’autre.

Cela nous pose donc un véritable problème lorsque nous voulons faire respecter certaines règles et appliquer
des politiques cohérentes sur toutes les plateformes et dans toutes les applications.

De plus, les fusions et acquisitions aggravent ce problème.

Nous sommes donc constamment confrontés à des fusions et acquisitions ou à l’arrivée de nouvelles entreprises au sein de notre
organisation, qui peuvent disposer de leurs propres comptes et de leurs propres

comptes que nous devons gérer.

Et cela peut s’accompagner de problèmes de gestion des identités auxquels nous n’avions même pas pensé
auparavant.

Je travaillais auparavant pour une organisation — et, soit dit en passant, je ne citerai aucun nom ici afin
de protéger les responsables.

Mais je travaillais pour une organisation qui réalisait de nombreuses fusions et acquisitions.

Nous avons procédé à un audit « zero trust » et nous avons découvert qu’il existait de nombreux comptes cloud
qui n’étaient tout simplement pas gérés, dont nous n’avions tout simplement pas tenu compte en raison du nombre

d’acquisitions qui avaient eu lieu au cours de l’année précédente.

Nous avons découvert que nous avions 12 comptes cloud dont nous ignorions même l’existence.

Et au sein de chacun de ces 12 comptes cloud, nous avions des comptes administrateur attribués

à un utilisateur individuel.

Ainsi, un seul utilisateur pouvait disposer de 12 comptes administrateur différents sur l’ensemble de ces 12
plateformes cloud.

Cela nous a donc posé un véritable problème.

De plus, lorsque ces utilisateurs quittaient l’entreprise, cela créait de nombreux comptes orphelins.

Il y avait donc des comptes administrateurs orphelins, ce qu’il vaut vraiment mieux éviter au
sein de son organisation.

La gestion des identités devient donc un véritable casse-tête lorsque l’on commence à prendre en compte

le nombre de plateformes cloud et d’applications SaaS
qui entrent en ligne de compte.

Nous avons donc plus que jamais besoin d’une stratégie concernant nos systèmes d’identité.

Et je pense qu’il existe certains principes issus du modèle Zero Trust que nous pouvons appliquer à nos systèmes IAM
pour renforcer la sécurité.

Le premier est : ne jamais faire confiance et toujours vérifier.

Chaque utilisateur, chaque appareil,

chaque élément qui accède à votre réseau, vous devez vous assurer qu’il prouve son identité.

Vous devez vous assurer qu’il prouve son identité et qu’il s’agit d’un élément
digne de confiance, autorisé à accéder à votre réseau et à y effectuer des opérations.

De plus, vous devez appliquer le principe du « privilège minimal » à vos identités.

Ainsi, les utilisateurs ne doivent disposer que des droits d’accès nécessaires à l’exécution d’une tâche ou de leurs fonctions professionnelles, et
rien de plus.

Ainsi, s’ils ont accès à quoi que ce soit qui dépasse le cadre de leurs fonctions,

leur compte dispose alors de privilèges excessifs.

Imaginez ce qui pourrait se passer si un acteur malveillant s’emparait de ce compte, parvenait à s’y
connecter et effectuait des opérations qu’il n’est pas censé faire au sein de votre organisation.

De plus, vous devez mettre en place une authentification forte et l’authentification multifactorielle (MFA) partout où ce n’est pas déjà le cas.

L’authentification repose sur trois éléments.

Elle repose sur quelque chose que vous connaissez, quelque chose que vous possédez et quelque chose que vous êtes.

Il est donc important qu’une authentification forte inclue ces trois éléments, ou au moins
deux d’entre eux si vous ne pouvez pas les mettre en œuvre tous les trois à ce stade sur votre réseau.

C’est très important.

Les décisions d’accès doivent être fondées sur le contexte et la posture.

Qu’est-ce que cela signifie ?

Imaginons qu’une personne accède au réseau avec un ordinateur portable et qu’elle
se soit connectée quelque part dans la région du New Jersey.

Elle commence alors à effectuer des opérations sur le réseau et, tout à coup, cinq minutes plus tard,

l’adresse IP de son ordinateur change pour correspondre à une adresse IP située
, disons, en Californie, et elle commence à effectuer des opérations sur le réseau depuis la Californie.

Or, il est impossible que cette personne ait pu traverser le pays en cinq
minutes.

C’est un déplacement impossible.

Et si vous détectez cela au cours de cette session, vous devrez soit mettre fin
à cette session, soit demander une nouvelle authentification pour vous assurer qu’il s’agit bien de la personne

qu’elle a déclaré être lors de son authentification.

C’est pourquoi la vérification de l’état de l’appareil

et de vérifier le contexte revêt une importance capitale.

Et la vérification continue va de pair avec cela.

Il s’agit de s’assurer que la personne que vous avez authentifiée une première fois continue de faire preuve de fiabilité
tout au long de la session.

Ainsi, si elle commence à adopter des comportements à risque, si elle accède à des comptes auxquels elle n’est pas
autorisée à accéder, si elle supprime des données ou commet des actes destructeurs, vous devez

la revérifier ou

mettre fin à la session si cela représente un risque.

Un autre avantage majeur du modèle « zero trust » est qu’il faut toujours partir du principe qu’une violation a eu lieu ou adopter cet
état d’esprit de « violation présumée », n’est-ce pas ?

Vous devez concevoir votre réseau comme s’il y avait déjà des acteurs malveillants à l’intérieur.

Et je pense qu’un exercice stimulant, voire amusant pour certains d’entre vous
qui aiment jouer les enquêteurs, serait de partir du principe que quelqu’un a déjà pénétré

votre réseau chaque jour.

Allez vérifier les sessions, observez les actions des utilisateurs, essayez de

déterminer si quelqu’un commet des actes malveillants sur votre réseau chaque jour, et essayez de surprendre
les acteurs malveillants en pleine action.

Si vous partez toujours du principe qu’il y a une intrusion, vous resterez toujours vigilant, vous prendrez
toujours des précautions et vous surveillerez toujours ce qui se passe sur votre réseau

et dans vos systèmes d’identité.

Quelles sont donc les stratégies que nous pouvons mettre en œuvre pour appliquer certaines de ces politiques « zero trust » ?

Eh bien, la première chose que nous pouvons faire, je pense, c’est d’unifier l’identité, l’authentification et
l’accès.

Et qu’est-ce que j’entends par là ?

Eh bien, euh

avec toutes ces plateformes cloud, avec toutes ces applications SaaS que nous avons mises en place,
nous nous retrouvons face à des silos d’identité.

J’aime les appeler des « îlots d’identité », ces îlots d’identité qui existent un peu partout.

Et la solution la plus simple pour les maîtriser toutes consiste à briser ces silos ou
à faire tomber les barrières entre toutes ces « îles d’identité » pour les regrouper.

Mettez en place une source unique de vérité pour vos identités.

Parfois, dans la plupart des organisations, il peut s’agir d’un système RH : lorsque les personnes sont embauchées, elles
saisissent leurs informations dans ce système.

Cela peut constituer la source unique de vérité et c’est peut-être à partir de là que vous créez des comptes.

Il peut également s’agir d’un système d’identité en tant que service, comme par exemple Entra AD, Ping ou Octa
, quelque chose de ce genre.

L’essentiel ici est de parvenir à une identité unique par utilisateur.

Il est bien plus facile de gérer les utilisateurs et leurs identités lorsque chaque utilisateur dispose d’une identité unique.

De plus, il est plus facile de fédérer cette identité sur plusieurs systèmes et services lorsque l’on dispose d’une identité unique
par utilisateur.

Et c’est la prochaine étape.

Ce qu’il vous faut faire, c’est fédérer cette identité.

J’ai un bon exemple tiré d’une ancienne organisation avec laquelle j’ai travaillé.

Je vous promets que ce ne sera pas la même organisation, mais encore une fois, il s’agit d’une organisation anonyme.

Nous avions déployé un service FTP.

Ce service FTP ne pouvait pas être intégré

avec notre stratégie de fédération habituelle.

Il disposait donc de son propre magasin d’identités.

Il disposait également de son propre composant d’authentification multifactorielle (MFA).

À l’époque, nous n’étions pas vraiment à l’aise avec la fédération entre notre environnement
d’entreprise et notre environnement cloud.

Ainsi, une personne souhaitant accéder à ce service FTP dans le cloud devait d’abord se connecter au
VPN d’entreprise à l’aide d’un compte utilisateur et d’un identifiant, puis passer un test d’authentification à deux facteurs (MFA).

Elle devait ensuite se connecter à notre plateforme cloud

à l’aide d’un compte utilisateur d’entreprise, d’un identifiant et d’un mot de passe, ainsi que d’une authentification multifactorielle.

Enfin, elle devait se connecter au service FTP à l’aide d’un identifiant, d’un mot de passe et d’une
authentification à deux facteurs.

Et toutes ces identités portaient le même nom.

Du coup, chaque fois qu’une personne appelait le service d’assistance pour un problème d’identité ou lié
à l’un de ses comptes d’authentification multifactorielle, nous ne pouvions pas déterminer de quel élément il s’agissait.

En gros,

de deviner et de déterminer lequel posait problème, et les utilisateurs n’étaient pas en mesure de
nous expliquer clairement de quel compte il s’agissait.

Du coup, parfois leurs problèmes étaient résolus, parfois non, et nous n’avions vraiment aucune
idée de l’origine des problèmes d’identité sur ce système en particulier.

Il est donc très important de parvenir d’une manière ou d’une autre à cette identité unique par utilisateur.

De plus, le fait de disposer d’une identité unique facilite considérablement l’unification des politiques et des modèles d’accès basés sur les rôles d’une plateforme à
l’autre.

De même, lorsqu’il s’agit d’automatiser le provisionnement et la gouvernance tout au long du cycle de vie des
utilisateurs, cela s’avère bien plus simple avec une identité unique et un environnement d’identité consolidé.

Parlons maintenant du renforcement de la sécurité des accès privilégiés.

C’est également très important.

L’une des mesures à prendre consiste à considérer vos administrateurs comme les identités
présentant le plus grand risque au sein de votre organisation.

Ce sont les comptes les plus dangereux et ce sont eux qui sont les plus

ciblés en cas de violation.

Ce sont eux qui présentent la plus grande valeur pour les cybercriminels, n’est-ce pas ?

Aucun membre de votre organisation ne devrait disposer en permanence de droits élevés.

Aucun administrateur ne devrait disposer en permanence de droits élevés.

Ils n’en ont tout simplement pas besoin.

Ils n’en ont pas besoin pour naviguer sur Internet ou pour lire les actualités sur ce qui se passe dans le monde.

Vous devez mettre en place un système d’élévation de privilèges « juste à temps »

, dans lequel les administrateurs ne reçoivent des comptes dotés de droits élevés que pendant la durée nécessaire à
l’exécution de l’action qu’ils souhaitent effectuer.

Si vous combinez cette approche avec le principe du « zero trust », vous obtiendrez un
compte administrateur qui ne disposera d’un accès que pendant le temps nécessaire pour effectuer ce qu’il doit faire.

Et il n’aura accès qu’aux fonctions spécifiques auxquelles nous l’avons limité
.

Cela rend donc vos comptes administrateurs beaucoup plus sécurisés.

Vous devriez également définir une sorte de comptes d’urgence surveillés.

J’ai une anecdote très révélatrice à ce sujet.

Je me demande, posez-vous simplement la question : combien d’entre vous ont un Bob dans leur environnement ?

Vous voyez de qui je parle, vous connaissez Bob.

Bob, c’est ce type qui est le seul à pouvoir accéder à ce serveur poussiéreux,
rangé dans une vieille armoire de câblage quelque part sur le site de votre organisation

et il est le seul à pouvoir s’y connecter.

Et si Bob venait à quitter l’entreprise ou si, Dieu nous en préserve, il venait à décéder, vous
perdriez l’accès à ce serveur.

Vous ne pourriez plus vous y connecter.

Vous ne pourriez plus effectuer de sauvegardes ni de restaurations.

Vous ne pourriez plus le mettre à jour.

Et Bob le sait, et Bob sait qu’il est indispensable.

Vous devez donc vous assurer d’éliminer ce genre de personnes de votre environnement.

Vous souhaitez disposer de comptes « d’urgence » que vous pouvez activer, auxquels vous pouvez recourir en
cas de besoin, si l’impensable venait à se produire, en cas de catastrophe, et qui soient

des sessions surveillées et contrôlées, des comptes que vous pouvez « retirer » et « rendre » pour effectuer
les actions les plus sensibles, comme par exemple un accès root dans un compte cloud dont vous pourriez être propriétaire.

Une autre mesure importante pour renforcer la sécurité et limiter les privilèges consiste à exiger une double validation pour les actions à fort
impact.

Qu’est-ce que j’entends par là ?

Imaginons qu’un administrateur doive se connecter et modifier 50 comptes.

Il ne le fait généralement jamais, mais vous savez, c’est une action aux conséquences très importantes.

Ce serait très préjudiciable s’il surveillait 50 comptes, s’il gérait 50
comptes en même temps et effectuait une modification ayant un impact significatif sur votre organisation.

Vous souhaitez disposer d’un mécanisme exigeant une double authentification ou
une double validation pour cette action spécifique, de sorte que lorsque Bob effectue cette modification,

il doive obtenir l’approbation d’une autre personne, peut-être un supérieur hiérarchique
qui devrait également valider cette action.

Et c’est donc très important.

Si un acteur malveillant s’emparait du compte de Bob ou de celui de n’importe qui d’autre – écoutez, je prends juste
Bob comme exemple –, il lui faudrait disposer d’un deuxième compte pour pouvoir effectuer ces

actions destructrices ou ayant un fort impact.

De plus, chaque session privilégiée, chaque session d’administrateur, doit
être enregistrée.

Assurez-vous qu’elles soient toutes surveillées et contrôlées.

Et informez ensuite vos collaborateurs que ces sessions sont auditées et enregistrées.

Je constate que les administrateurs sont beaucoup plus prudents s’ils savent que leurs actions sont surveillées.

Ils veillent beaucoup plus à ne pas commettre d’erreurs et à ne pas adopter de
comportements qu’ils ne devraient pas adopter… euh… s’ils savent que leurs sessions sont

surveillées et qu’elles font l’objet d’un audit.

Je pense donc que ce sont là des éléments importants pour renforcer la sécurité des accès privilégiés.

Ajoutons ensuite la vérification continue.

La vérification continue s’apparente en quelque sorte au modèle « zero trust », mais il s’agit d’un « zero trust » en temps réel.

Concrètement, nous validons en permanence les utilisateurs et vérifions s’ils disposent ou non de
l’accès nécessaire pour effectuer les tâches qui leur incombent.

Vous savez, il est très important de garder à l’esprit que le simple fait d’avoir
authentifié un utilisateur une première fois ne signifie pas qu’il est considéré comme fiable pendant toute la durée de sa

en ligne ou tant que sa session est active.

Les jetons de session

peuvent être volés et les sessions peuvent être détournées ; celles-ci peuvent être prises en main par des acteurs malveillants, qui peuvent alors effectuer des actions
à risque.

Il est donc important de vérifier en permanence ce que fait l’utilisateur au cours de sa session et d’analyser
l’état de sécurité de l’appareil.

Si l’appareil qui accède à la session est un appareil d’entreprise ou s’il s’agit, par exemple, de
son appareil personnel susceptible d’introduire des logiciels malveillants dans votre

réseau, il est très important d’en assurer le suivi.

Vous devez disposer d’un système d’authentification renforcée pour les actions à risque.

Ainsi, si quelqu’un se connecte et souhaite élever ses droits d’accès ou créer un
compte administrateur, une authentification renforcée doit être exigée.

Un bon exemple est celui de la connexion à votre banque : lorsque vous vous connectez à
votre compte bancaire avec votre identifiant et votre mot de passe, et éventuellement via une authentification multifactorielle (MFA) si vous êtes client d’une

bonne banque, et que vous vous connectez simplement pour consulter votre compte ou vos transactions,

, mais que vous souhaitez ensuite transférer une somme importante vers un autre compte, ce que vous ne faites jamais d’habitude
.

La banque peut alors vous demander une authentification multifactorielle supplémentaire ou vous envoyer un e-mail vous demandant de
saisir le code qu’elle vient de vous envoyer par e-mail afin de confirmer cette transaction.

C’est un exemple d’authentification renforcée.

Il s’agit d’une mesure facile à mettre en place au sein de votre organisation, notamment pour
les opérations à risque.

Vous devez surveiller les sessions afin de détecter d’éventuelles anomalies.

Assurez-vous que, si une anomalie survient au cours d’une session, vous demandiez à l’utilisateur de s’authentifier
à nouveau.

Ainsi, si un utilisateur n’accède généralement pas aux données financières dans SharePoint et qu’il commence à y accéder
ou à demander un accès à celles-ci, il est peut-être temps de procéder à une nouvelle authentification ou d’examiner cette

session et de vérifier que l’accès est toujours valide pour cet utilisateur.

De plus, vous devriez ajuster le niveau de risque de manière dynamique en fonction du risque

ou de ce qu’il est en train de faire.

Prenons par exemple le cas des déplacements impossibles.

Imaginons par exemple qu’un utilisateur, au cours de sa session, commence à effectuer des actions à risque à 2
heures du matin

du matin, alors que ses horaires de travail habituels sont de 9 h à 17 h.

Dans ce cas, vous voudrez peut-être vous assurer que la session de cette personne n’a pas été piratée ou
que son jeton n’a pas été volé et réutilisé ailleurs par quelqu’un à l’étranger ou par quelqu’un

qui, euh, tente de commettre des actes malveillants au sein de votre réseau.

Vous devez disposer d’une méthode ou d’un moyen de détecter et de mettre fin immédiatement aux sessions
compromises dès que vous constatez qu’il y a un risque ou que

des acteurs malveillants sont impliqués.

Bon, maintenant que la stratégie est définie, parlons de quelques mesures
concrètes que vous pourriez mettre en œuvre dès maintenant au sein de votre organisation pour appliquer le modèle « zero trust » à vos systèmes IAM.

Je sais que ces mesures ne s’appliqueront pas à toutes les organisations.

J’ai essayé de rester à un niveau général tout en restant concret.

Mais voici quelques pistes de réflexion qui, je l’espère, vous donneront des idées pour réussir
au sein de votre organisation et mettre en œuvre certaines des politiques « zero trust » dans votre

organisation.

Ainsi, au cours des 30 premiers jours, je pense que l’une des meilleures priorités est de généraliser l’authentification multifactorielle (MFA
).

Si vous ne disposez pas encore de l’authentification multifactorielle (MFA), c’est une mesure qui porte ses fruits très rapidement.

Si vous pouvez mettre en place un système d’authentification multifactorielle (MFA) au sein de votre organisation, un système qui demande aux utilisateurs de saisir un
code, ou si vous disposez déjà d’une MFA généralisée, vous pourriez peut-être

envisager de passer à une authentification multifactorielle résistante au phishing, conforme à la norme FIDO2 ou à une norme
similaire.

C’est également une excellente mesure, facile à mettre en œuvre au sein de votre organisation, et qui
rendra vos comptes bien plus sûrs.

Commencez également à cartographier vos silos d’identité.

Déterminez où se trouvent toutes vos identités, sur quelles « îles » elles sont situées, où
se trouvent vos applications cloud, quelles plateformes cloud vous utilisez et quels silos d’identités se trouvent

au sein de celles-ci.

Essayez de localiser tous ces éléments et dressez un inventaire très complet.

Ensuite, vous devrez sécuriser vos comptes administrateurs et vos comptes de service.

C’est une mesure qui peut être mise en place dès le premier jour.

Renforcez leur sécurité, quelle que soit la méthode utilisée, même si ce n’est que de manière minimale.

Commencez par de petites mesures progressives pour renforcer la sécurité de ces comptes administrateurs et ne laissez
personne disposer en permanence de privilèges pour agir au sein de votre organisation.

Au cours des 30 premiers jours, il est important de remporter des victoires.

Il est important de justifier

l’importance de ce projet « Zero Trust ».

Au cours des 90 jours suivants, efforcez-vous d’assurer la cohérence du système.

Lancez votre plan de consolidation des identités.

Commencez à mettre en œuvre une consolidation des identités.

Regroupez tous vos « îlots d’identité », fusionnez vos silos.

Veillez à ce qu’il n’y ait qu’une seule identité par personne.

Définissez à quoi ressemblera votre cadre de politique.

Même si vous ne le mettez pas encore en œuvre, il est important de commencer à le définir, parallèlement à la gestion du
cycle de vie.

À quoi ressemblera votre processus de cycle de vie ?

Comment les utilisateurs intègrent-ils votre organisation ?

Comment quittent-ils l’organisation ?

Comment gérez-vous les départs au sein de votre organisation ?

Comment supprimez-vous leurs comptes ?

Il est important de définir cela dès le départ afin de pouvoir mettre
en place une automatisation au fur et à mesure que votre organisation se développe.

Mettez également en place une politique de sécurité des appareils.

Si ce n’est pas déjà le cas, il est important d’examiner vos appareils pour vous
assurer qu’ils sont fiables et que les personnes qui les utilisent

disposent d’appareils fiables, éventuellement équipés d’une image d’entreprise ou répondant à une
norme spécifique à l’entreprise, et de signaler ces appareils comme présentant un risque s’ils ne sont pas

à cette norme.

Ensuite, créez ces comptes de classe de rupture.

Nous ne voulons pas que Bob décède, nous ne voulons pas que Bob quitte l’entreprise, et nous ne voulons
pas perdre l’accès à ce serveur rangé dans ce placard poussiéreux auquel seul Bob a accès.

Veillez donc à mettre en place ces comptes de classe « break » assez rapidement.

Ensuite, visez la maturité à long terme.

Élargissez votre périmètre de consolidation.

Veillez à disposer d’une source unique de vérité, qu’il s’agisse du système ER ou d’un
système IDAS.

Passez à une méthode d’authentification plus avancée.

Il pourrait s’agir pour vous d’une authentification sans mot de passe basée sur une norme telle que FIDO2.

J’adore vraiment l’authentification.

Je pourrais en parler pendant 30 minutes d’affilée.

Mais l’authentification sans mot de passe est une fonctionnalité que vos utilisateurs apprécieront vraiment et qui
, à mon avis, renforce considérablement votre sécurité.

Les mots de passe ne constituent tout simplement pas une méthode sûre pour authentifier l’utilisateur.

Veillez à intégrer une surveillance comportementale à votre processus de vérification ou à votre vérification continue
.

Comme je l’ai mentionné, il s’agit par exemple de comportements tels que l’accès au réseau à 2 heures du matin,

alors que vous travaillez habituellement de 9 h à 17 h.

C’est un exemple de surveillance comportementale que vous pouvez intégrer à vos sessions pour renforcer
votre sécurité.

Intégrez l’automatisation à la gouvernance de votre cycle de vie et à

cycle de vie de vos identités.

Ainsi, lorsqu’un utilisateur rejoint l’organisation, il se voit immédiatement accorder l’accès dont il a besoin.

Et lorsqu’il quitte l’organisation, il perd complètement les droits d’accès dont il disposait, ce
qui vous permet de vous assurer qu’il n’y a pas de comptes orphelins et de protéger votre

réseau.

Appliquez ensuite vos politiques sous forme de code pour garantir une application cohérente.

Considérez vos politiques comme du code.

Disposez d’un référentiel de politiques, pour ainsi dire.

Veillez à tester vos politiques de temps à autre.

Veillez à mettre en place un contrôle de version pour vos politiques et assurez-vous qu’elles soient traitées comme du code, c’est-à-dire
qu’elles soient enregistrées et extraites lorsqu’elles sont modifiées.

J’espère donc que cela vous a fourni suffisamment d’informations pour comprendre comment mettre en œuvre une politique « zero trust »
pour vos systèmes IAM et rendre votre réseau véritablement plus sûr.

Il y a deux ou trois points que je voudrais que vous reteniez de cette session.

Je tiens à ce que vous gardiez à l’esprit qu’il est important d’améliorer votre « hygiène des identités ».

Le nombre d’identités explose,

les identités au sein du « New Perimeter », et assurez-vous de disposer d’un plan permettant d’apporter
des améliorations, qu’il s’agisse de consolidation, de nettoyage de ces silos et de ces

, ou simplement d’appliquer des politiques et des pratiques cohérentes à l’échelle de votre
organisation.

Essayez toujours de mettre en place des mesures qui vous donneront l’avantage, au cas où un acteur
malveillant viendrait à s’emparer de l’une de vos identités.

Et s’il y a une chose qu’il est vraiment important de retenir de toute cette présentation, c’est que

la confiance n’est pas quelque chose que l’on accorde une seule fois lorsque l’utilisateur s’authentifie.

C’est quelque chose qui doit être vérifié en permanence, à la lumière de ses actions et
de ce qu’il fait au sein de votre organisation.

C’est donc un élément qui doit faire l’objet d’une surveillance constante.

J’espère donc que cela vous aura été utile.

Si je devais vous recommander quelques étapes suivantes, je vous conseillerais
notamment d’écouter un podcast à la demande.

Nous proposons un podcast ou un webcast consacré à la résilience des identités Active Directory.

C’est un excellent webcast que je vous recommande vivement de regarder.

Vous pouvez également en apprendre davantage sur la cyber-résilience et sur la manière dont Commvault y contribue en vous inscrivant à un atelier sur la cyber-résilience ou en suivant une formation sur la préparation à la
cyber-résilience

, dont les liens d’accès s’affichent à l’écran.

Je tiens à vous remercier sincèrement pour le temps que vous m’avez consacré aujourd’hui et pour votre
attention.

J’espère sincèrement que cela vous aidera dans votre transition vers un modèle « zero trust » pour vos systèmes de messagerie
instantanée à l’avenir.

Un grand merci pour votre présence aujourd’hui et merci beaucoup d’avoir participé.