Il y a une question que chaque administrateur informatique finit par cesser de poser à voix haute, car il a accepté qu'elle n'ait pas de réponse simple.
« Pourquoi est-ce que je sais tout sur cet appareil, et presque rien sur la personne qui est assise devant en ce moment même ? »
Vous avez accès à l'état des correctifs, à la conformité, à l'inventaire des applications et à la localisation. Vous pouvez tout effacer à distance à 2 h du matin depuis votre téléphone. Mais la personne qui se connecte à 9 h ? Il s'agit toujours d'un simple accord verbal et d'un mot de passe probablement réutilisé pour trois autres comptes.
C’est pour combler cette lacune que OneIdP existe. Deux ans plus tard, voici le récit sincère des efforts déployés pour y parvenir.
Le monde dans lequel vivaient réellement les équipes informatiques
La réponse classique était déjà bien établie : acheter un outil IAM, l’intégrer à votre UEM, configurer l’authentification unique (SSO) entre les deux.
Des fournisseurs différents, des tableaux de bord différents et des endroits différents où votre politique peut se contredire discrètement dès qu'un cas particulier se présente.
Le problème plus profond était que Scalefusion Les environnements informatiques d'entreprise classiques ne sont pas conçus pour des scénarios parfaits, mais pour gérer les exceptions. Parmi celles-ci, on peut citer les appareils partagés, l'intégration à distance, les prestataires utilisant leurs ordinateurs portables personnels et les équipes réparties sur cinq fuseaux horaires.
Il ne s'agissait pas de cas particuliers à contourner, mais des conditions de fonctionnement réelles.
Pourtant, la plupart des stratégies d'accès étaient encore conçues pour un monde où tout le monde se rendait au même bureau, utilisait le même appareil, chaque jour. L'authentification devenait alors la solution miracle. On la considérait comme un problème résolu : vérifier le mot de passe, autoriser la session, et c'était tout.
La plupart des décisions d'accès étaient encore prises sans disposer de toutes les informations nécessaires. En effet, connaître l'identité d'une personne ne nous renseigne quasiment pas sur l'appareil utilisé pour se connecter : s'il est à jour, s'il appartient à l'organisation, s'il s'agit du poste enregistré au trimestre précédent ou d'un ordinateur portable personnel dans le hall d'un hôtel.
C’est cet écart que nous nous sommes efforcés de combler.
Ce que nous avons expédié le premier jour — et pourquoi ce n'était que le début
Lors du lancement de OneIdP, nous avons fait un choix délibéré que la plupart des équipes produit ne font pas : nous avons livré une plateforme de base plutôt qu’une liste de fonctionnalités.
Un annuaire cloud. Un accès conditionnel par carte magnétique. Une authentification multifacteur intégrée au tableau de bord que les équipes informatiques utilisaient déjà au quotidien. L'infrastructure a été volontairement conçue comme une base solide avant d'être enrichie de nombreuses fonctionnalités.
keycard Permet aux équipes informatiques de définir des conditions d'accès réelles : emplacements autorisés, plages d'adresses IP de confiance, réseaux Wi-Fi spécifiques et plages horaires. Pour les équipes utilisant des mots de passe partagés et des authentifications sans contexte, même cette première version représentait une méthode de travail différente.
Un terrain solide, avant même que nous commencions à construire.
Puis un événement s'est produit qui nous a confirmé que la solution avait porté ses fruits. Quelques mois plus tard, les clients ne se demandaient plus si OneIdP fonctionnait, mais réfléchissaient déjà à la suite.
- Comment intégrer leur configuration Okta ou Entra existante ?
- Comment prendre des décisions d'accès qui tiennent compte de la conformité des appareils, et pas seulement de l'identité ?
- Comment faire en sorte que cela fonctionne pour des équipes travaillant par roulement et partageant des machines tout au long d'une journée de travail complète.
Voilà la carte, et nous l'avons suivie.
Deux ans de construction pour cette réalité
La plupart des outils d'identification sont construits sur des hypothèses.
Qu'une authentification valide garantit une session sécurisée. Que les équipes informatiques reconstruiront leur annuaire pour l'adapter à la nouvelle plateforme. Qu'un expert en gestion des identités et des accès (IAM) sera disponible pour assurer la maintenance de l'ensemble du système.
Ces hypothèses sont ancrées dans la gestion des accès en entreprise depuis des années, car, tout simplement, personne ne s'est arrêté pour les remettre en question.
Nous les avons interrogés tous les trois.
1. L'identité suffit pour accorder l'accès
L'authentification unique (SSO), telle qu'elle a toujours été proposée par l'industrie, s'arrête dès que les identifiants sont vérifiés. L'utilisateur est bien celui qu'il prétend être. Session autorisée.
Ce qu'il n'a jamais demandé, c'est ce qui se cachait derrière les informations d'identification. Si l'appareil est à jour. Si la requête provient d'un emplacement plausible. Si l'application utilisée devrait même être ouverte sur cette machine à ce moment précis.
Chez Politiques d'accès étendu (XAP) poser exactement cette question.
Chaque connexion est évaluée en fonction de l'ensemble des données. Les signaux de conformité des appareils en temps réel, fournis par Veltar, sont directement intégrés à la décision d'accès. En cas d'anomalie, l'accès est bloqué avant même l'ouverture de quoi que ce soit. Aucune vérification manuelle. Aucune intervention de l'administrateur. La politique est appliquée automatiquement.
Nous avons ensuite examiné l'autre aspect du même problème.
Sur un appareil déjà reconnu et approuvé par OneIdP, demander à l'utilisateur de saisir à nouveau son mot de passe n'apporte rien. Cela ne fait qu'ajouter une friction qui indique discrètement à l'utilisateur que le service informatique ne lui fait pas confiance. L'authentification unique améliorée sur les appareils gérés élimine complètement ce problème. Le statut de conformité de l'appareil fait office d'identifiant. L'expérience devient transparente, et c'est tant mieux.
2. Vous repartirez à zéro avec une nouvelle identité
Chaque argumentaire du type « passez simplement à notre plateforme » présente le même angle mort.
Cela suppose que les équipes informatiques abandonnent des années de configuration d'annuaires, d'intégrations de fournisseurs d'identité et de politiques d'accès, pour tout reconstruire à partir de zéro dans un nouvel outil. Pour une équipe gérant 800 appareils répartis sur deux continents, la migration est loin d'être simple.
Identity Federation a été conçue pour cette réalité.
OneIdP sert de couche de gestion des accès, s'appuyant sur l'infrastructure existante. Qu'il s'agisse d'Entra, de Google Workspace, d'Okta, de PingOne ou des configurations Active Directory sur site antérieures à l'équipe informatique actuelle, tout est conservé.
Nous sommes allés encore plus loin avec SCIM Accès entrant et sortant. Lorsqu'un utilisateur rejoint l'entreprise, son accès est automatiquement provisionné. En cas de changement de rôle, son accès est adapté. À son départ, son compte est supprimé sans qu'il soit nécessaire de créer un ticket ou d'effectuer une action manuelle. La représentation des effectifs dans toutes les applications connectées reste exacte.
3. Il y aura toujours quelqu'un pour le gérer.
Le choix de l'architecture est la partie facile. C'est l'utilisation quotidienne de la plateforme qui complexifie généralement la gestion des identités.
Mots de passe d'administrateur local Voici un bon exemple de problème qui reste latent jusqu'à ce qu'il éclate au grand jour. Des identifiants identiques sur des centaines de machines, inchangés pendant des mois, car leur rotation manuelle est une tâche que personne n'a le temps d'effectuer. LAPS a automatisé ce processus. La rotation s'effectue selon un calendrier précis. Chaque identifiant est audité. Le risque disparaît sans que personne n'ait à intervenir.
Le portail utilisateur centralisait l'accès à toutes les applications autorisées. Géré par l'équipe informatique, toujours à jour, il ne laissait aucune place à l'ambiguïté quant aux applications approuvées. Un outil qui, sans susciter d'éloges, permet d'éliminer définitivement une catégorie spécifique de demandes d'assistance.
L'authentification unique (SSO) basée sur l'appareil a résolu le problème des appareils partagés qui restait sans solution depuis le lancement. Tout utilisateur inscrit sur un ordinateur géré accède à son application. Aucune réinscription n'est nécessaire entre les quarts de travail. L'accès suit l'utilisateur. L'appareil reste prêt pour le prochain utilisateur.
Les journaux d'accès SSO ont fourni à chaque RSSI la piste d'audit qu'il demandait lors de son premier audit de sécurité, automatiquement et sans que personne ne la crée manuellement dans une feuille de calcul.
Trois hypothèses. Trois décisions délibérées de construire différemment.
Mais les décisions prises sur le papier et les décisions mises en œuvre dans la production sont deux choses très différentes.
Voici comment les choses se sont réellement déroulées.
Honnêtement, le calendrier
Il est utile de voir comment cela s'est déroulé — non pas comme une feuille de route produit, mais comme une série de réponses à ce que nous apprenions :
Lancement de OneIdP
Annuaire, authentification unique, carte d'accès.
Intégrations de fournisseurs d'identité
GWS, Entra, Okta, PingOne, AD sur site, etc.
Portail utilisateur et fédération d'identités
Portail sécurisé et contrôlé par ordinateur pour chaque application approuvée.
SCIM v2.0 — Provisionnement à grande échelle
Les utilisateurs sont synchronisés. Les employés qui quittent l'entreprise sont automatiquement désactivés.
Politiques d'accès étendu (XAP)
Accorder l'accès SSO en fonction de la conformité de l'appareil, de sa localisation, de son adresse IP et de la présence de l'application
SSO basé sur l'appareil + LAPS
Autoriser les appareils gérés conformes à accéder aux applications quel que soit l'utilisateur connecté.
Attributions SSO basées sur les groupes d'utilisateurs
Ajoutez des exceptions à l'accès conditionnel dans les configurations SSO ou affectez des utilisateurs en masse aux configurations SSO à l'aide du groupe d'utilisateurs.
Clés d'accès
Connexion sans mot de passe via biométrie, clés de sécurité et appareils de confiance. Gestion centralisée par le service informatique, libre-service pour les utilisateurs.
À quoi ressemble OneIdP aujourd'hui ?
Lors du lancement, les discussions portaient sur la mise en place de fondations solides : intégrer la confiance et l’identité des appareils dans une même couche de politiques, et faire en sorte que l’accès conditionnel reflète en temps réel l’activité sur le terminal.
Aujourd'hui, les discussions portent sur les possibilités offertes par cette plateforme : des intégrations plus poussées, une couverture de flotte plus étendue, des politiques d'accès qui s'étendent à une infrastructure plus vaste, car la plateforme a été conçue pour cela.
Cette progression, de la base à la plateforme complète, correspond exactement à l'objectif que nous nous étions fixés.
OneIdP Aujourd'hui, l'identité, la confiance accordée aux appareils et les politiques d'accès sont évaluées conjointement à chaque connexion, en temps réel, sans aucun décalage entre le terminal géré et l'accès contrôlé. L'appareil et son utilisateur évoluent enfin dans le même univers de politiques.
Ce à quoi nous sommes restés fidèles tout au long du processus est un principe constamment mis à l'épreuve dans le développement de produits : « La plateforme d'accès la plus sophistiquée n'a de valeur que si l'équipe informatique est capable de la gérer efficacement. Une équipe réduite gérant un parc distribué ne devrait pas avoir besoin d'un ingénieur IAM dédié pour assurer son bon fonctionnement. »
Chaque version sortie au cours des deux dernières années a été conçue dans ce but : suffisamment puissante pour un environnement complexe, suffisamment facile à utiliser pour les personnes qui s'y trouvent réellement.
C’est cet équilibre dont nous sommes le plus fiers.
Ce qui vient
Deux années passées à travailler aux côtés d'équipes informatiques vous apprennent une chose utile : le problème est toujours plus important que celui que vous venez de résoudre.
La confiance accordée aux appareils a soulevé des questions concernant l'accès au réseau. L'accès au réseau a, quant à lui, soulevé des questions concernant l'infrastructure. La prise en charge de RADIUS dans le cloud et l'accès SSH basé sur l'identité constituent les prochaines étapes de réponse — déjà en cours d'élaboration, fruit des mêmes discussions qui ont permis de dégager tous les points précédents.
Le champ d'application de la gouvernance d'accès zéro confiance ne cesse de s'étendre, et nous avons l'intention de nous développer en même temps.
