Think about what your system administrators are carrying right now. A root password in a password manager. An SSH private key in ~/.ssh, on a laptop, and probably on a second laptop too. A VPN profile. A domain admin account. Possibly the break-glass credential from the last incident, in a note somebody meant to delete.
Every one of those outlives the reason it was issued. Every one of them works from a hotel lobby at two in the morning. And when one of them hands in their notice, offboarding becomes a list of places to go and take things back, which is why it never quite finishes.
Now picture the same administrators with none of it. No root password, because nobody ever told them one. No keys on any laptop. No VPN. No domain accounts. What each of them has is a ManageLM account, a passkey, and a page listing the servers they're allowed to open.
A privileged access vault exists for one reason: the human must not hold the credential. So the vault holds it, rotates it, and injects it into a session brokered by a proxy. The checkout workflow, the connection components, the proxy farm sized for concurrent sessions, the network arranged so the proxy is unavoidable: all of that machinery is there to keep one promise.
It's a good promise, and the serious products keep it. CyberArk and Wallix both do this properly, the recording holds up in an audit, and the paperwork is done. If you've spent two years and a large budget getting there, nobody sensible is telling you to throw it away. But look at the shape of it: an entire infrastructure whose job is to stand between a person and a secret that still exists.
ManageLM doesn't have that secret. The agent is already running on the server, with local authority, holding an outbound connection to the portal. When an operator opens a session, nothing is fetched, injected or typed, because there's nothing to inject. The agent opens a shell and streams it. The credential a vault would be protecting was never created in the first place. Wallix called its product Bastion, and that isn't marketing shorthand, it's the architecture, honestly labelled.
The other half of it is the network, and that's the half a firewall review usually kills. The agent dials out, and the platform itself needs nothing listening: no inbound rule, no port opened onto a management network, no RDP published, no appliance in a DMZ waiting to be somebody's way in. Nothing new to scan, nothing new to brute-force, and no VPN service of your own to keep patched.
So an operator doesn't have to be on your network to administer it. They open a browser, confirm a passkey, and they're on the host. No VPN profile to issue, no client to install on a contractor's laptop, no concentrator seat to buy, and nobody sitting in an airport waiting for a tunnel to come up before they can look at an alert.
The awkward hosts stop being awkward, too. A machine behind NAT in a branch office, a box in a cloud account your VPN never reached, a server on a customer site: if the agent can reach the portal outbound, the console works there exactly as it does on the rack next door.
Operators live on one page: every server they're allowed to open, grouped by site, with a star for the handful they touch daily. No safe to navigate, no account to check out, no connection component to choose, no vault path to paste. It's built to be bookmarked, which matters more than it sounds, because a link to one particular shell stops working the day that host is rebuilt, and today's incident is never on the machine you bookmarked last month.
A terminal. A real root shell in the browser, in its own window, fullscreen if you want it. No SSH client, no key, and no port opened for it anywhere.
A file browser. Browse the filesystem, drag a file from your desktop onto it to upload, drag a whole directory down and get a zip, open a config in a real editor in the browser and save it back, rename, chmod, delete. Downloads up to a gigabyte. No SFTP exposed to anybody, no copy of the file parked on a jump host on the way through, no separate tool to authorise. Every file that moves lands in the audit trail.
A Windows desktop. The full desktop in a browser tab, with no RDP port published anywhere. The agent is the only thing that touches the host's own loopback RDP port, and the browser receives drawing instructions rather than the RDP stream. Windows won't give up an existing account's password, so the agent keeps a dedicated account and mints it a fresh random password for each session, then disables it again on teardown. The operator gets an administrator desktop. What they never get is a password they could use tomorrow evening, from home, when nothing is recording.
That last sentence is the whole product in miniature. A vault's best case is that the human never sees the credential. Here the credential lasts one session and then stops existing.
And the fourth way in, the one nobody is giving up. Plenty of engineers will still want a real SSH client, and that path is governed from the same place rather than left to itself. Keys are pushed out per person from the portal, the session is recorded and locks on the same idle window as the browser ones, and one switch lifts a leaver's access off every host at once. More on that below. The short version is that the old door is managed rather than merely tolerated.
Under the terminal sits an assistant that reads what's on the screen and answers questions about it: why that command failed, what that log line means, what to check next. It has no shell of its own and executes nothing. It can offer a single command, and a person presses Run to execute it or Insert to put it on the prompt and edit it first. Only displayed output ever reaches it, never keystrokes, so a typed password can't be in the context, and printed secrets are masked in the browser before anything leaves it. Acting on a suggestion is written to the audit log. The file browser has the same panel, reading the listing you're standing in, so \"what's eating the space in here\" is a question you can just ask.
The model can be one on your own network, resolved per server, per site or per account, so the contents of a session need never leave the building.
And when you'd rather describe the outcome than drive it, the same agents do the work themselves across the fleet, under an allowlist enforced in code rather than in a prompt: the model proposes, and anything outside the list is refused whatever the model had in mind. Those tasks are drawn on the session map beside the humans, with the same audit trail and a revert. Your bastion has no concept of an AI agent working on a host. This treats it as one more thing that has to be granted, watched and recorded.
Opening a session takes about four seconds and a passkey. It's confirmed at every open, even though the same passkey signed them in that morning, with a fresh challenge that's spent on use and a ticket that lives thirty seconds. An account with no passkey enrolled is refused rather than warned, because a second factor you can skip by never setting one up isn't a second factor. Compare the usual shape: MFA once, at the VPN, at nine in the morning, and everything for the rest of the day inherits it, including the session token sitting in an unlocked browser on somebody's laptop.
The unit of access is the server, not the segment. A VPN or a jump host hands somebody a network, and after that what they can reach is a routing question rather than a policy one. Here the grant is per host or per group, and no role carries it: an account owner has no shell anywhere until somebody grants one. Authorisation is re-tested every minute while a session is open, so withdrawing a grant shuts a window somebody already had open inside a minute, and the screen locks on an idle window you set, enforced in the portal rather than in the page so a tampered client doesn't get round it.
Then the part that's easy to miss: the browser console isn't a new door beside the old ones. Open one person's row on a server or a group and you see the lot. Whether they can open a console, a file browser and a desktop there. Whether their SSH key goes into root's authorized_keys. Whether they get passwordless sudo. Three independent switches on the row, and the push of each person's key into their own local account set once on the host or the group.
The SSH half matters, because it's where most estates actually live. A member registers their public key once, in their own profile, and the portal pushes it into a managed block inside the right local account on the hosts they're assigned to, matched by a username an administrator sets, so directory-backed accounts work as well as local ones and nothing outside that block is touched. Every key the platform syncs also carries a forced command that sits between the client and the shell, so a plain SSH login is recorded and locks on the same idle window, releasing on a ManageLM password or a passkey confirmed through a link the lock screen prints. There's still no shared root password anywhere in this story.
Which makes leavers boring, and that's the point. Disable a member and their browser sessions, their API keys and their MCP connections stop at once, while the same change lifts their keys and their sudoers line off every host they were assigned to. One switch, both directions, no list of places to visit.
The second portal is for whoever answers for the fleet. It draws who is connected to your servers right now: people down one side, hosts down the other, a line between them for every live session, coloured by how they got in. It draws sessions rather than your fleet, so four people working across five hundred servers draw four lines, and it stays readable on a second screen all week.
Five kinds of line. Four the platform opened itself: terminals, file browsers, desktops and AI tasks. The fifth is the interesting one, where somebody logged in directly and the platform had nothing to do with it. Those come from the machine itself, Linux agents reporting the host's own login records and Windows agents enumerating Terminal Services sessions, which covers RDP, the physical console and the Windows OpenSSH server alike. Where the local account maps to a member, the login appears on that person's node with their name and role, beside whatever browser consoles they have open, so one card is one human however many ways they got in. Where it doesn't map, it stays a hollow avatar with the account and the source address, which is all a direct login honestly tells anybody.
Then the part worth the trial on its own. Every session carries a state saying whether ManageLM is holding it. A login through a key the platform manages is wrapped, recorded and lockable. One that isn't gets flagged on the card and counted in the header of the page.
That header count is the number a bastion structurally cannot produce. There are analytics add-ons that infer some of it from directory traffic and SIEM feeds, separately bought and separately licensed, and inference isn't the same as watching. \"How much of my privileged access is going around the thing I bought to control it\" stops being a project with a workshop attached and becomes a figure on a screen. If the only thing you own is the corridor, the only thing you can see is who walked down it.
Recording is decided per server, or set on a group to cover everything in it, and a group can only switch it on, never off, which is what makes it usable as a policy. For the portal's own sessions there's nothing to install: every byte already goes through one place on its way to the browser, so recording is a tee there. Direct SSH logins are recorded on the host by the agent instead, on Linux, attributed by the fingerprint of the key that authenticated, which is the thing that still works when half a dozen people's keys share root's authorized_keys.
Categories rather than a scorecard, because the products inside each column differ and the honest comparison is architectural. The middle two both do their own job well. The rightmost column is what falls out of already having an agent on every server.
| Vault and proxy PAMCyberArk, Wallix, BeyondTrust | Modern access proxyTeleport, StrongDM | ManageLM | |
|---|---|---|---|
| Reaching a server | VPN, then the proxy | Client or browser to the proxy | A browser tab |
| Inbound port on the host | SSH or RDP, open to the proxy | None in agent mode | None |
| What you deploy first | Vault, proxy farm, HA pair | A proxy cluster and its CA | The agent you wanted anyway |
| Standing credentials | Vaulted, rotated, checked out | Short-lived certificates | None to hold |
| Second factor | Usually once, at the perimeter | Per session | Every session, by passkey |
| Sessions it did not open | Not visible; add-on analytics infer | Not visible | Drawn, flagged and counted |
| Session recording | A licensed component | Included | Same switch, into your bucket |
| File transfer | A separate workflow | Through the proxy | Drag it onto the window |
| In-session AI help | No | No | Reads the screen, runs nothing |
| Agentic fleet work | No | No | Allowlisted, same audit trail |
| Onboarding a server | Firewall, target account, connector | Install or route to it | Install the agent |
| Time to the first session | A quarter, optimistically | Days | An afternoon |
Nothing here asks you to switch your bastion off. Your vault carries on doing what it does, and credential rotation here delivers into HashiCorp Vault, Conjur, Key Vault and the rest rather than competing with them. Put agents on a slice of the estate for the inventory and security audits you'd want anyway, then open the sessions map and count how many lines on it never went near the proxy.
If the answer is none, you run an unusually tight estate and you've lost an afternoon. If it isn't none, you've found the gap your current console was never in a position to show you, without a migration, a firewall change or a procurement cycle.
Two things it deliberately doesn't do, so the first week holds no surprises. There's no request and approve workflow: an admin grants access per server and revokes it the same way, so if your control needs a ticket and a named approver before a shell opens, that isn't here today. And it's an audit trail rather than a containment boundary, since somebody with root on a server can stop a recorder running on that server. If you need sessions that can't go unrecorded, make the portal console the only way in and let the fail-closed switch do the rest.
Install the agent on one production host, approve it, confirm a passkey, open a root shell in a browser tab. There's nothing to build first, and you'll notice you never typed a password anywhere in that sentence. Turn recording on, do a real piece of work, drag a file across, then replay the session afterwards.
Then, and this is usually the part that decides it, open the sessions map, leave it on a second screen for a week, and count the lines nobody is recording. If that number surprises you, it was going to surprise an auditor eventually.
Ten servers are free, permanently, with nothing switched off. More detail on Privileged Access, the AI-Assisted Console and Credential Rotation, or take ten free servers at app.managelm.com and point it at the host you'd least like to explain to an auditor.
", "fr": "Pensez à ce que vos administrateurs système transportent en ce moment. Un mot de passe root dans un gestionnaire de mots de passe. Une clé privée SSH dans ~/.ssh, sur un portable, et sans doute sur un second portable aussi. Un profil VPN. Un compte d'administration du domaine. Peut-être l'identifiant de secours du dernier incident, dans une note que quelqu'un comptait effacer.
Chacun survit à la raison qui l'a fait naître. Chacun fonctionne depuis le hall d'un hôtel à deux heures du matin. Et quand l'un d'eux s'en va, le départ devient une liste d'endroits où aller récupérer des choses, ce qui explique qu'il ne s'achève jamais tout à fait.
Imaginez maintenant les mêmes administrateurs sans rien de tout cela. Pas de mot de passe root, puisque personne ne leur en a jamais donné. Aucune clé sur aucun portable. Pas de VPN. Pas de comptes de domaine. Chacun dispose d'un compte ManageLM, d'une passkey et d'une page listant les serveurs qu'il a le droit d'ouvrir.
Un coffre-fort d'accès à privilèges existe pour une seule raison : l'humain ne doit pas détenir l'identifiant. Le coffre le détient donc, le fait tourner et l'injecte dans une session courtée par un proxy. Le circuit d'emprunt, les composants de connexion, la ferme de proxys dimensionnée pour les sessions simultanées, le réseau arrangé pour que le proxy soit incontournable : toute cette mécanique existe pour tenir une seule promesse.
C'est une bonne promesse, et les produits sérieux la tiennent. CyberArk et Wallix le font correctement, l'enregistrement résiste à un audit, le dossier est bouclé. Si vous y avez consacré deux ans et un gros budget, personne de sensé ne vous dira de tout jeter. Mais observez la forme de l'ensemble : une infrastructure entière dont le métier est de se tenir entre une personne et un secret qui, lui, existe toujours.
ManageLM n'a pas ce secret. L'agent tourne déjà sur le serveur, avec l'autorité locale, et maintient une connexion sortante vers le portail. Quand un opérateur ouvre une session, rien n'est récupéré, injecté ni saisi, parce qu'il n'y a rien à injecter : l'agent ouvre un shell et le diffuse. L'identifiant qu'un coffre protégerait n'a jamais été créé. Wallix a appelé son produit Bastion : ce n'est pas un raccourci marketing, c'est l'architecture, nommée honnêtement.
L'autre moitié du sujet, c'est le réseau, et c'est celle qui meurt d'ordinaire en revue de firewall. L'agent appelle vers l'extérieur, et la plateforme n'a besoin de rien en écoute : aucune règle entrante, aucun port ouvert sur un réseau d'administration, aucun RDP publié, aucun boîtier en DMZ qui attend de devenir le point d'entrée de quelqu'un. Rien de neuf à scanner, rien de neuf à attaquer en force, et aucun service VPN à vous à tenir à jour.
Un opérateur n'a donc plus besoin d'être sur votre réseau pour l'administrer. Il ouvre un navigateur, confirme une passkey, et il est sur l'hôte. Aucun profil VPN à délivrer, aucun client à installer sur le portable d'un prestataire, aucun siège de concentrateur à acheter, et personne qui patiente dans un aéroport que le tunnel monte avant de pouvoir regarder une alerte.
Les hôtes pénibles cessent d'être pénibles. Une machine derrière du NAT dans une agence, une instance dans un compte cloud que votre VPN n'a jamais atteint, un serveur chez un client : si l'agent joint le portail en sortie, la console y fonctionne exactement comme sur la baie d'à côté.
Les opérateurs vivent sur une seule page : tous les serveurs qu'ils ont le droit d'ouvrir, groupés par site, avec une étoile sur la poignée qu'ils touchent quotidiennement. Pas de coffre à parcourir, pas de compte à emprunter, pas de composant de connexion à choisir, pas de chemin de coffre-fort à coller. Elle est faite pour être mise en favori, ce qui compte plus qu'il n'y paraît : un lien vers un shell précis cesse de fonctionner le jour où cet hôte est reconstruit, et l'incident du jour n'est jamais sur la machine que vous aviez mise en favori le mois dernier.
Un terminal. Un vrai shell root dans le navigateur, dans sa propre fenêtre, en plein écran si vous voulez. Pas de client SSH, pas de clé, et aucun port ouvert pour cela où que ce soit.
Un explorateur de fichiers. Parcourez l'arborescence, déposez un fichier depuis votre bureau pour l'envoyer, faites glisser un répertoire entier pour le récupérer en zip, ouvrez une configuration dans un véritable éditeur et enregistrez-la, renommez, changez les droits, supprimez. Téléchargements jusqu'à un gigaoctet. Aucun SFTP exposé, aucune copie du fichier abandonnée au passage sur un rebond, aucun outil distinct à autoriser. Chaque fichier qui bouge atterrit dans la piste d'audit.
Un bureau Windows. Le bureau complet dans un onglet, sans aucun port RDP publié nulle part. L'agent est la seule chose qui touche le port RDP en boucle locale de l'hôte, et le navigateur reçoit des instructions de dessin, pas le flux RDP. Windows ne rend pas le mot de passe d'un compte existant : l'agent conserve donc un compte dédié et lui forge un mot de passe aléatoire à chaque session, puis le désactive à la fermeture. L'opérateur obtient un bureau d'administrateur. Ce qu'il n'obtient jamais, c'est un mot de passe réutilisable demain soir, depuis chez lui, quand rien n'enregistre.
Cette dernière phrase résume tout le produit. Le meilleur cas d'un coffre-fort, c'est que l'humain ne voie jamais l'identifiant. Ici, l'identifiant vit une session, puis cesse d'exister.
Et la quatrième entrée, celle à laquelle personne ne renonce. Beaucoup d'ingénieurs voudront toujours un vrai client SSH, et ce chemin-là est gouverné depuis le même endroit au lieu d'être laissé à lui-même. Les clés sont poussées par personne depuis le portail, la session est enregistrée et se verrouille sur le même délai d'inactivité que les sessions du navigateur, et un seul interrupteur retire l'accès d'un partant sur tous les hôtes à la fois. Détails plus bas. En résumé : l'ancienne porte est gérée, pas simplement tolérée.
Sous le terminal se tient un assistant qui lit ce qui est affiché et répond aux questions qui s'y rapportent : pourquoi cette commande a échoué, ce que dit cette ligne de log, quoi vérifier ensuite. Il n'a pas de shell et n'exécute rien. Il peut proposer une commande, qu'une personne lance avec Exécuter ou dépose sur l'invite avec Insérer pour la retoucher. Seule la sortie affichée lui parvient, jamais les frappes : un mot de passe tapé ne peut donc pas entrer dans le contexte, et les secrets affichés sont masqués dans le navigateur avant que quoi que ce soit n'en sorte. Donner suite à une suggestion est inscrit au journal d'audit. L'explorateur de fichiers a le même panneau, qui lit le répertoire où vous vous trouvez : « qu'est-ce qui mange la place ici » devient une question qu'il suffit de poser.
Le modèle peut vivre sur votre propre réseau, choisi par serveur, par site ou par compte : le contenu d'une session n'a jamais besoin de quitter vos murs.
Et quand vous préférez décrire le résultat plutôt que le conduire, les mêmes agents font le travail eux-mêmes sur toute la flotte, sous une liste blanche appliquée par le code et non par un prompt : le modèle propose, tout ce qui sort de la liste est refusé, quelles que soient ses intentions. Ces tâches se dessinent sur la carte des sessions à côté des humains, avec la même piste d'audit et un retour arrière possible. Votre bastion n'a aucune notion d'un agent d'IA travaillant sur un hôte ; ici, c'est une chose de plus à autoriser, surveiller et enregistrer.
Ouvrir une session prend quatre secondes et une passkey. Elle est confirmée à chaque ouverture, même si la même passkey a servi à se connecter le matin, avec un défi neuf consommé à l'usage et un ticket qui vit trente secondes. Un compte sans passkey enrôlée est refusé, pas averti : un second facteur qu'on évite en ne l'activant jamais n'est pas un second facteur. Comparez à l'usage courant : une authentification forte le matin, au VPN, et tout le reste de la journée en hérite, y compris le jeton de session posé dans un navigateur déverrouillé sur le portable de quelqu'un.
L'unité d'accès est le serveur, pas le segment. Un VPN ou un rebond remet un réseau entre les mains de quelqu'un, et ce qu'il atteint ensuite relève du routage plutôt que de la politique. Ici, l'autorisation se donne par hôte ou par groupe, et aucun rôle ne la porte : le propriétaire d'un compte n'a de shell nulle part tant que personne ne lui en accorde un. L'autorisation est revérifiée chaque minute pendant qu'une session est ouverte, si bien qu'un droit retiré ferme en moins d'une minute une fenêtre déjà ouverte, et l'écran se verrouille sur le délai d'inactivité que vous fixez, appliqué dans le portail et non dans la page, pour qu'un client altéré ne le contourne pas.
Vient ensuite la partie facile à manquer : la console du navigateur n'est pas une porte de plus à côté des anciennes. Ouvrez la ligne d'une personne sur un serveur ou un groupe, et vous voyez tout. Si elle peut y ouvrir une console, un explorateur de fichiers et un bureau. Si sa clé SSH entre dans le fichier authorized_keys de root. Si elle obtient sudo sans mot de passe. Trois interrupteurs indépendants sur la même ligne, et la poussée de la clé de chacun dans son propre compte local réglée une fois pour l'hôte ou le groupe.
La moitié SSH compte, car c'est là que vivent réellement la plupart des parcs. Un membre enregistre sa clé publique une fois, dans son profil, et le portail la pousse dans un bloc géré, à l'intérieur du bon compte local, sur les hôtes qui lui sont attribués, l'appariement se faisant par un nom d'utilisateur que fixe un administrateur : les comptes issus d'un annuaire fonctionnent donc aussi bien que les comptes locaux, et rien en dehors de ce bloc n'est touché. Chaque clé synchronisée par la plateforme porte en plus une commande forcée, placée entre le client et le shell : une connexion SSH ordinaire est donc enregistrée et se verrouille sur le même délai d'inactivité, la levée se faisant par un mot de passe ManageLM ou une passkey confirmée depuis un lien qu'affiche l'écran de verrouillage. Et il n'y a toujours aucun mot de passe root partagé dans cette histoire.
Les départs en deviennent ennuyeux, et c'est exactement le but. Désactivez un membre : ses sessions navigateur, ses clés d'API et ses connexions MCP s'arrêtent aussitôt, tandis que le même geste retire ses clés et sa ligne de sudoers de tous les hôtes qui lui étaient attribués. Un interrupteur, dans les deux sens, sans liste d'endroits à visiter.
Le second portail s'adresse à qui répond de la flotte. Il dessine qui est connecté à vos serveurs en ce moment : les personnes d'un côté, les hôtes de l'autre, une ligne entre les deux pour chaque session vivante, colorée selon la manière dont elle est entrée. Il dessine des sessions et non votre flotte : quatre personnes réparties sur cinq cents serveurs tracent quatre lignes, et la page reste lisible sur un second écran toute la semaine.
Cinq sortes de lignes. Quatre que la plateforme a ouvertes elle-même : terminaux, explorateurs de fichiers, bureaux, tâches d'IA. La cinquième est la plus intéressante : quelqu'un s'est connecté directement, sans que la plateforme y soit pour quoi que ce soit. Celles-là viennent de la machine, les agents Linux rapportant les enregistrements de connexion de l'hôte et les agents Windows énumérant les sessions Terminal Services, ce qui couvre aussi bien RDP que la console physique et le serveur OpenSSH de Windows. Quand le compte local correspond à un membre, la connexion apparaît sur le nœud de cette personne, avec son nom et son rôle, à côté des consoles qu'elle a ouvertes : une carte, un humain, quel que soit le nombre de portes empruntées. Sans correspondance, il reste un avatar creux avec le compte et l'adresse source, ce qui est tout ce qu'une connexion directe apprend honnêtement à quiconque.
Vient alors la partie qui justifie l'essai à elle seule. Chaque session porte un état qui dit si ManageLM la tient. Une connexion passée par une clé que la plateforme gère est encadrée, enregistrée et verrouillable ; celle qui ne l'est pas est signalée sur la carte et comptée dans l'en-tête de la page.
Ce compteur est le chiffre qu'un bastion ne peut structurellement pas produire. Il existe des modules d'analyse qui en déduisent une partie à partir du trafic d'annuaire et des flux SIEM, achetés et licenciés à part, et déduire n'est pas voir. « Quelle part de mes accès à privilèges contourne ce que j'ai acheté pour les contrôler » cesse d'être un projet avec atelier en annexe et devient un chiffre à l'écran. Si vous ne possédez que le couloir, vous ne voyez que ceux qui l'ont emprunté.
L'enregistrement se décide par serveur, ou se règle sur un groupe pour couvrir tout ce qu'il contient, et un groupe ne peut que l'activer, jamais le désactiver : c'est ce qui en fait une politique utilisable. Pour les sessions du portail, il n'y a rien à installer, puisque chaque octet passe déjà par un même point en route vers le navigateur : l'enregistrement y est une simple dérivation. Les connexions SSH directes sont enregistrées sur l'hôte par l'agent, sous Linux, attribuées par l'empreinte de la clé qui a authentifié, la seule chose qui fonctionne encore quand les clés d'une demi-douzaine de personnes se partagent le fichier authorized_keys de root.
Des catégories plutôt qu'un tableau de notes, car les produits d'une même colonne diffèrent et la comparaison honnête est architecturale. Les deux colonnes du milieu font très bien leur métier. Celle de droite est ce qui découle du fait d'avoir déjà un agent sur chaque serveur.
| PAM à coffre et proxyCyberArk, Wallix, BeyondTrust | Proxy d'accès moderneTeleport, StrongDM | ManageLM | |
|---|---|---|---|
| Atteindre un serveur | VPN, puis le proxy | Client ou navigateur vers le proxy | Un onglet de navigateur |
| Port entrant sur l'hôte | SSH ou RDP, ouvert au proxy | Aucun en mode agent | Aucun |
| Ce qu'il faut déployer d'abord | Coffre, ferme de proxys, paire redondante | Un cluster de proxys et son autorité | L'agent que vous vouliez déjà |
| Identifiants permanents | En coffre, mis en rotation, empruntés | Certificats de courte durée | Aucun à détenir |
| Second facteur | En général une fois, au périmètre | Par session | À chaque session, par passkey |
| Sessions qu'il n'a pas ouvertes | Invisibles ; un module d'analyse les déduit | Invisibles | Dessinées, signalées, comptées |
| Enregistrement des sessions | Un composant sous licence | Inclus | Le même interrupteur, vers votre bucket |
| Transfert de fichiers | Un circuit à part | À travers le proxy | Glissez le fichier sur la fenêtre |
| Aide IA pendant la session | Non | Non | Lit l'écran, n'exécute rien |
| Travail agentique sur la flotte | Non | Non | Sous liste blanche, même piste d'audit |
| Raccorder un serveur | Firewall, compte cible, connecteur | L'installer ou router vers lui | Installer l'agent |
| Délai avant la première session | Un trimestre, en étant optimiste | Quelques jours | Un après-midi |
Rien ici ne vous demande d'éteindre votre bastion. Votre coffre continue son travail, et la rotation des identifiants livre chez HashiCorp Vault, Conjur, Key Vault et les autres plutôt que de leur faire concurrence. Posez des agents sur une portion du parc pour l'inventaire et les audits de sécurité que vous vouliez de toute façon, puis ouvrez la carte des sessions et comptez les lignes qui ne sont jamais passées près du proxy.
Si la réponse est aucune, votre parc est exceptionnellement rigoureux et vous aurez perdu un après-midi. Sinon, vous venez de trouver l'angle mort que votre console actuelle n'était pas en mesure de vous montrer, sans migration, sans changement de firewall et sans cycle d'achat.
Deux choses qu'il ne fait délibérément pas, pour que la première semaine ne réserve aucune surprise. Il n'y a pas de circuit de demande et d'approbation : un administrateur accorde l'accès par serveur et le révoque de la même façon ; si votre contrôle exige un ticket et un approbateur nommé avant l'ouverture d'un shell, cela n'existe pas ici aujourd'hui. Et c'est une piste d'audit, pas une frontière de confinement : qui détient root sur un serveur peut arrêter un enregistreur qui y tourne. S'il vous faut des sessions impossibles à laisser sans enregistrement, faites de la console du portail la seule entrée et laissez l'échec bloquant faire le reste.
Installez l'agent sur un hôte de production, approuvez-le, confirmez une passkey, ouvrez un shell root dans un onglet. Il n'y a rien à construire d'abord, et vous remarquerez que vous n'avez tapé aucun mot de passe dans cette phrase. Activez l'enregistrement, faites un vrai travail, glissez un fichier, puis rejouez la session.
Ensuite, et c'est en général ce qui emporte la décision, ouvrez la carte des sessions, laissez-la une semaine sur un second écran et comptez les lignes que personne n'enregistre. Si ce nombre vous surprend, il aurait fini par surprendre un auditeur.
Dix serveurs sont gratuits, définitivement, sans rien de désactivé. Plus de détails sur l'accès à privilèges, la console assistée par IA et la rotation des identifiants, ou prenez dix serveurs gratuits sur app.managelm.com et pointez-les vers l'hôte que vous aimeriez le moins avoir à expliquer à un auditeur.
", "de": "Denken Sie daran, was Ihre Systemadministratoren gerade mit sich herumtragen. Ein Root-Passwort im Passwortmanager. Einen privaten SSH-Schlüssel in ~/.ssh, auf einem Laptop und vermutlich auch auf einem zweiten. Ein VPN-Profil. Ein Konto für die Domänenverwaltung. Womöglich den Notfallzugang vom letzten Vorfall, in einer Notiz, die jemand löschen wollte.
Jedes davon überlebt den Grund seiner Ausgabe. Jedes funktioniert um zwei Uhr nachts aus einer Hotellobby. Und wenn eine dieser Personen geht, wird der Austritt zu einer Liste von Orten, an denen man Dinge zurückholt, und deshalb wird er nie ganz fertig.
Stellen Sie sich nun dieselben Administratoren ohne all das vor. Kein Root-Passwort, weil ihnen nie eines genannt wurde. Keine Schlüssel auf irgendeinem Laptop. Kein VPN. Keine Domänenkonten. Jede Person hat ein ManageLM-Konto, einen Passkey und eine Seite mit den Servern, die sie öffnen darf.
Ein Tresor für privilegierten Zugriff existiert aus einem einzigen Grund: Der Mensch darf den Zugang nicht halten. Also hält ihn der Tresor, rotiert ihn und spielt ihn in eine Sitzung ein, die ein Proxy vermittelt. Der Ausleihvorgang, die Verbindungskomponenten, die für gleichzeitige Sitzungen ausgelegte Proxy-Farm, das so gebaute Netz, dass am Proxy kein Weg vorbeiführt: Diese ganze Mechanik hält ein einziges Versprechen.
Es ist ein gutes Versprechen, und die ernsthaften Produkte halten es. CyberArk und Wallix machen das ordentlich, die Aufzeichnung hält einem Audit stand, die Unterlagen sind fertig. Wenn Sie zwei Jahre und ein großes Budget hineingesteckt haben, rät Ihnen niemand bei Verstand, das wegzuwerfen. Betrachten Sie aber die Form des Ganzen: eine komplette Infrastruktur, deren Aufgabe darin besteht, zwischen einem Menschen und einem Geheimnis zu stehen, das es weiterhin gibt.
ManageLM hat dieses Geheimnis nicht. Der Agent läuft ohnehin auf dem Server, mit lokaler Autorität, und hält eine ausgehende Verbindung zum Portal. Öffnet eine Operatorin eine Sitzung, wird nichts geholt, eingespielt oder getippt, weil es nichts einzuspielen gibt: Der Agent öffnet eine Shell und streamt sie. Der Zugang, den ein Tresor schützen würde, wurde nie erzeugt. Wallix hat sein Produkt Bastion genannt: kein Marketingkürzel, sondern die Architektur, ehrlich benannt.
Die andere Hälfte ist das Netz, und daran stirbt der Vorschlag üblicherweise in der Firewall-Prüfung. Der Agent wählt hinaus, und die Plattform braucht nichts Lauschendes: keine eingehende Regel, keinen Port zu einem Managementnetz, kein veröffentlichtes RDP, kein Gerät in der DMZ, das darauf wartet, jemandes Weg hinein zu werden. Nichts Neues zu scannen, nichts Neues durchzuprobieren, und kein eigener VPN-Dienst, den Sie aktuell halten müssen.
Eine Operatorin muss also nicht mehr in Ihrem Netz sein, um es zu verwalten. Sie öffnet einen Browser, bestätigt einen Passkey und ist auf dem Host. Kein VPN-Profil auszustellen, kein Client auf dem Laptop eines Dienstleisters, kein Konzentrator-Platz zu kaufen, und niemand wartet am Flughafen auf den Tunnel, bevor er einen Alarm ansehen kann.
Die sperrigen Hosts hören auf, sperrig zu sein. Eine Maschine hinter NAT in einer Filiale, eine Instanz in einem Cloud-Konto, das Ihr VPN nie erreicht hat, ein Server beim Kunden: Erreicht der Agent das Portal ausgehend, funktioniert die Konsole dort wie im Rack nebenan.
Operatoren leben auf einer Seite: alle Server, die sie öffnen dürfen, nach Standort gruppiert, mit einem Stern auf der Handvoll, die sie täglich anfassen. Kein Safe zu durchsuchen, kein Konto auszuleihen, keine Verbindungskomponente zu wählen, kein Tresorpfad einzufügen. Sie ist zum Setzen eines Lesezeichens gebaut, was mehr zählt, als es klingt: Ein Link auf eine bestimmte Shell funktioniert an dem Tag nicht mehr, an dem dieser Host neu aufgesetzt wird, und der heutige Vorfall liegt nie auf der Maschine, die Sie letzten Monat mit einem Lesezeichen versehen haben.
Ein Terminal. Eine echte Root-Shell im Browser, in einem eigenen Fenster, auf Wunsch im Vollbild. Kein SSH-Client, kein Schlüssel, und nirgends ein dafür geöffneter Port.
Ein Dateibrowser. Durch den Verzeichnisbaum gehen, eine Datei vom Schreibtisch darauf ziehen und hochladen, ein ganzes Verzeichnis herunterziehen und als ZIP bekommen, eine Konfiguration in einem echten Editor öffnen und zurückschreiben, umbenennen, Rechte ändern, löschen. Downloads bis zu einem Gigabyte. Kein offenes SFTP, keine Kopie, die unterwegs auf einem Sprunghost liegen bleibt, kein separates Werkzeug zu genehmigen. Jede bewegte Datei landet in der Audit-Spur.
Ein Windows-Desktop. Der vollständige Desktop in einem Tab, ohne irgendwo veröffentlichten RDP-Port. Der Agent ist das Einzige, was den lokalen RDP-Port des Hosts berührt, und der Browser bekommt Zeichenanweisungen, nicht den RDP-Strom. Windows rückt das Passwort eines bestehenden Kontos nicht heraus: Der Agent hält daher ein eigenes Konto vor und prägt ihm für jede Sitzung ein frisches Zufallspasswort, das beim Beenden wieder deaktiviert wird. Die Operatorin bekommt einen Administrator-Desktop. Was sie nie bekommt, ist ein Passwort, das morgen Abend von zu Hause noch funktioniert, wenn nichts aufzeichnet.
Dieser letzte Satz ist das ganze Produkt im Kleinen. Der beste Fall eines Tresors ist, dass der Mensch den Zugang nie sieht. Hier lebt der Zugang eine Sitzung lang und hört dann auf zu existieren.
Und der vierte Weg hinein, auf den niemand verzichtet. Viele Ingenieure wollen weiterhin einen echten SSH-Client, und dieser Weg wird von derselben Stelle aus geregelt, statt sich selbst überlassen zu bleiben. Schlüssel werden je Person aus dem Portal ausgerollt, die Sitzung wird aufgezeichnet und sperrt nach demselben Leerlauffenster wie die im Browser, und ein Schalter entzieht einer scheidenden Person den Zugang auf allen Hosts gleichzeitig. Einzelheiten weiter unten. Kurz: Die alte Tür wird verwaltet, nicht bloß geduldet.
Unter dem Terminal sitzt ein Assistent, der liest, was angezeigt wird, und Fragen dazu beantwortet: warum dieser Befehl fehlschlug, was diese Log-Zeile sagt, was als Nächstes zu prüfen ist. Er hat keine Shell und führt nichts aus. Er darf einen Befehl anbieten, den ein Mensch mit Ausführen startet oder mit Einfügen auf die Eingabezeile legt, um ihn zu überarbeiten. Nur die angezeigte Ausgabe erreicht ihn, nie Tastenanschläge: Ein getipptes Passwort kann also nicht in den Kontext geraten, und ausgegebene Geheimnisse werden im Browser maskiert, bevor etwas hinausgeht. Einem Vorschlag zu folgen steht im Audit-Log. Der Dateibrowser hat dieselbe Leiste, die das Verzeichnis liest, in dem Sie stehen: „was frisst hier den Platz“ wird zu einer Frage, die man einfach stellt.
Das Modell kann in Ihrem eigenen Netz stehen, ausgewählt je Server, je Standort oder je Konto: Der Inhalt einer Sitzung muss Ihr Haus nie verlassen.
Und wenn Sie das Ergebnis lieber beschreiben als steuern, erledigen dieselben Agenten die Arbeit selbst über die ganze Flotte, unter einer Allowlist, die der Code durchsetzt und nicht ein Prompt: Das Modell schlägt vor, alles außerhalb der Liste wird abgelehnt, ganz gleich, was es vorhatte. Diese Aufgaben erscheinen auf der Sitzungskarte neben den Menschen, mit derselben Audit-Spur und einer Rücknahme. Ihr Bastion-Host kennt keinen KI-Agenten auf einem Host; hier ist er eine weitere Sache, die erteilt, beobachtet und aufgezeichnet wird.
Eine Sitzung zu öffnen dauert vier Sekunden und einen Passkey. Er wird bei jedem Öffnen bestätigt, auch wenn derselbe Passkey am Morgen die Anmeldung getragen hat, mit einer frischen Aufgabe, die bei Gebrauch verfällt, und einem Ticket, das dreißig Sekunden lebt. Ein Konto ohne hinterlegten Passkey wird abgewiesen, nicht gewarnt: Ein zweiter Faktor, den man umgeht, indem man ihn nie einrichtet, ist keiner. Vergleichen Sie das mit der üblichen Praxis: eine starke Authentifizierung am Morgen, am VPN, und alles Weitere des Tages erbt sie, einschließlich des Sitzungstokens in einem unversperrten Browser auf irgendeinem Laptop.
Die Einheit des Zugriffs ist der Server, nicht das Segment. Ein VPN oder ein Sprunghost übergibt jemandem ein Netz, und was danach erreichbar ist, entscheidet das Routing statt der Richtlinie. Hier wird je Host oder je Gruppe erteilt, und keine Rolle bringt es mit: Wer ein Konto besitzt, hat nirgends eine Shell, bis jemand eine erteilt. Während eine Sitzung offen ist, wird die Berechtigung jede Minute neu geprüft, ein entzogenes Recht schließt also binnen einer Minute ein bereits offenes Fenster, und der Bildschirm sperrt nach dem Leerlauffenster, das Sie setzen, durchgesetzt im Portal und nicht in der Seite, damit ein manipulierter Client nicht daran vorbeikommt.
Dann der leicht zu übersehende Teil: Die Browser-Konsole ist keine weitere Tür neben den alten. Öffnen Sie die Zeile einer Person auf einem Server oder einer Gruppe, und Sie sehen alles. Ob sie dort eine Konsole, einen Dateibrowser und einen Desktop öffnen darf. Ob ihr SSH-Schlüssel in die authorized_keys von root wandert. Ob sie sudo ohne Passwort bekommt. Drei unabhängige Schalter in derselben Zeile, und das Ausrollen des jeweiligen Schlüssels in das eigene lokale Konto einmal für den Host oder die Gruppe eingestellt.
Die SSH-Hälfte zählt, denn dort leben die meisten Landschaften tatsächlich. Ein Mitglied hinterlegt seinen öffentlichen Schlüssel einmal im eigenen Profil, und das Portal schreibt ihn in einen verwalteten Block innerhalb des richtigen lokalen Kontos auf den zugewiesenen Hosts, zugeordnet über einen Benutzernamen, den eine Administratorin festlegt: Verzeichnisgestützte Konten funktionieren also ebenso wie lokale, und nichts außerhalb dieses Blocks wird angefasst. Jeder von der Plattform synchronisierte Schlüssel trägt zusätzlich einen erzwungenen Befehl zwischen Client und Shell: Eine gewöhnliche SSH-Anmeldung wird damit aufgezeichnet und sperrt nach demselben Leerlauffenster, aufhebbar mit einem ManageLM-Passwort oder einem Passkey, bestätigt über einen Link, den der Sperrbildschirm anzeigt. Und noch immer kommt in dieser Geschichte kein geteiltes Root-Passwort vor.
Austritte werden damit langweilig, und genau darum geht es. Deaktivieren Sie ein Mitglied: Seine Browser-Sitzungen, seine API-Schlüssel und seine MCP-Verbindungen enden sofort, und derselbe Handgriff entfernt seine Schlüssel und seine sudoers-Zeile von allen zugewiesenen Hosts. Ein Schalter, in beide Richtungen, ohne Liste der zu besuchenden Orte.
Das zweite Portal ist für alle, die für die Flotte geradestehen. Es zeichnet, wer gerade mit Ihren Servern verbunden ist: Menschen auf der einen Seite, Hosts auf der anderen, für jede lebende Sitzung eine Linie dazwischen, eingefärbt danach, wie sie hereinkam. Gezeichnet werden Sitzungen, nicht Ihre Flotte: Vier Personen auf fünfhundert Servern ergeben vier Linien, und die Seite bleibt eine Woche lang auf einem zweiten Bildschirm lesbar.
Fünf Arten von Linien. Vier hat die Plattform selbst geöffnet: Terminals, Dateibrowser, Desktops, KI-Aufgaben. Die fünfte ist die interessante: Jemand hat sich direkt angemeldet, ohne Zutun der Plattform. Diese kommen von der Maschine selbst, Linux-Agenten melden die Anmeldesätze des Hosts, Windows-Agenten zählen Terminaldienste-Sitzungen auf, was RDP, die physische Konsole und den Windows-OpenSSH-Server gleichermaßen abdeckt. Lässt sich das lokale Konto einem Mitglied zuordnen, erscheint die Anmeldung am Knoten dieser Person, mit Namen und Rolle, neben den Konsolen, die sie offen hat: eine Karte, ein Mensch, über wie viele Türen er auch kam. Ohne Zuordnung bleibt ein hohler Avatar mit Konto und Quelladresse, und mehr verrät eine direkte Anmeldung ehrlicherweise niemandem.
Dann kommt der Teil, der den Test für sich allein rechtfertigt. Jede Sitzung trägt einen Zustand, der sagt, ob ManageLM sie hält. Eine Anmeldung über einen Schlüssel, den die Plattform verwaltet, ist eingefasst, aufgezeichnet und sperrbar; eine, die es nicht ist, wird auf der Karte markiert und im Kopf der Seite gezählt.
Diese Zahl kann ein Bastion-Host strukturell nicht liefern. Es gibt Analysemodule, die einen Teil davon aus Verzeichnisverkehr und SIEM-Daten ableiten, getrennt gekauft und lizenziert, und Ableiten ist nicht Sehen. „Wie viel meines privilegierten Zugriffs läuft an dem vorbei, was ich zu seiner Kontrolle gekauft habe“ hört auf, ein Projekt mit angehängtem Workshop zu sein, und wird eine Zahl auf einem Bildschirm. Wenn Ihnen nur der Korridor gehört, sehen Sie nur, wer ihn entlanggegangen ist.
Die Aufzeichnung wird je Server entschieden oder an einer Gruppe gesetzt, um alles darin abzudecken, und eine Gruppe kann sie nur einschalten, nie ausschalten: Erst das macht sie als Richtlinie brauchbar. Für die Sitzungen des Portals gibt es nichts zu installieren, denn jedes Byte läuft auf dem Weg zum Browser ohnehin durch dieselbe Stelle: Die Aufzeichnung ist dort eine Abzweigung. Direkte SSH-Anmeldungen zeichnet unter Linux der Agent auf dem Host auf, zugeordnet über den Fingerabdruck des Schlüssels, der authentifiziert hat, das Einzige, was noch funktioniert, wenn sich die Schlüssel eines halben Dutzends Menschen die authorized_keys von root teilen.
Kategorien statt einer Bewertungstabelle, denn die Produkte einer Spalte unterscheiden sich, und der ehrliche Vergleich ist ein architektonischer. Die beiden mittleren Spalten machen ihre Sache sehr gut. Die rechte ist das, was herauskommt, wenn ohnehin auf jedem Server ein Agent läuft.
| PAM mit Tresor und ProxyCyberArk, Wallix, BeyondTrust | Moderner Zugriffs-ProxyTeleport, StrongDM | ManageLM | |
|---|---|---|---|
| Einen Server erreichen | VPN, dann der Proxy | Client oder Browser zum Proxy | Ein Browser-Tab |
| Eingehender Port am Host | SSH oder RDP, zum Proxy offen | Keiner im Agentenmodus | Keiner |
| Was zuerst auszurollen ist | Tresor, Proxy-Farm, redundantes Paar | Ein Proxy-Cluster und seine CA | Der Agent, den Sie ohnehin wollten |
| Dauerhafte Zugangsdaten | Im Tresor, rotiert, ausgeliehen | Kurzlebige Zertifikate | Keine zu halten |
| Zweiter Faktor | Meist einmal, am Perimeter | Je Sitzung | Bei jeder Sitzung, per Passkey |
| Sitzungen, die es nicht geöffnet hat | Unsichtbar; ein Analysemodul leitet ab | Unsichtbar | Gezeichnet, markiert, gezählt |
| Sitzungsaufzeichnung | Eine lizenzierte Komponente | Enthalten | Derselbe Schalter, in Ihren Bucket |
| Dateiübertragung | Ein eigener Ablauf | Durch den Proxy | Datei aufs Fenster ziehen |
| KI-Hilfe in der Sitzung | Nein | Nein | Liest den Bildschirm, führt nichts aus |
| Agentische Flottenarbeit | Nein | Nein | Unter Allowlist, dieselbe Audit-Spur |
| Einen Server anbinden | Firewall, Zielkonto, Konnektor | Installieren oder dorthin routen | Den Agenten installieren |
| Zeit bis zur ersten Sitzung | Ein Quartal, optimistisch | Einige Tage | Ein Nachmittag |
Nichts hier verlangt, Ihren Bastion-Host abzuschalten. Ihr Tresor macht weiter, und die Rotation von Zugangsdaten liefert in HashiCorp Vault, Conjur, Key Vault und die übrigen hinein, statt mit ihnen zu konkurrieren. Setzen Sie Agenten auf einen Teil der Landschaft, für das Inventar und die Sicherheitsaudits, die Sie ohnehin wollten, öffnen Sie dann die Sitzungskarte und zählen Sie die Linien, die nie in die Nähe des Proxys kamen.
Lautet die Antwort keine, führen Sie eine ungewöhnlich straffe Landschaft und haben einen Nachmittag verloren. Andernfalls haben Sie die Lücke gefunden, die Ihre bisherige Konsole Ihnen gar nicht zeigen konnte, ohne Migration, ohne Firewall-Änderung, ohne Beschaffungszyklus.
Zwei Dinge, die es bewusst nicht tut, damit die erste Woche keine Überraschungen bringt. Es gibt keinen Antrags- und Genehmigungsablauf: Eine Administratorin erteilt den Zugriff je Server und entzieht ihn ebenso; verlangt Ihre Kontrolle ein Ticket und einen benannten Genehmiger, bevor sich eine Shell öffnet, gibt es das hier heute nicht. Und es ist eine Audit-Spur, keine Eindämmungsgrenze: Wer auf einem Server root hat, kann einen dort laufenden Rekorder anhalten. Brauchen Sie Sitzungen, die nicht ohne Aufzeichnung bleiben können, machen Sie die Portal-Konsole zum einzigen Weg hinein und lassen Sie den blockierenden Schalter den Rest erledigen.
Installieren Sie den Agenten auf einem Produktionshost, geben Sie ihn frei, bestätigen Sie einen Passkey, öffnen Sie eine Root-Shell in einem Tab. Es gibt nichts vorher zu bauen, und Ihnen wird auffallen, dass Sie in diesem Satz kein Passwort getippt haben. Schalten Sie die Aufzeichnung ein, erledigen Sie ein echtes Stück Arbeit, ziehen Sie eine Datei hinüber und spielen Sie die Sitzung danach ab.
Und dann, das gibt meist den Ausschlag, öffnen Sie die Sitzungskarte, lassen Sie sie eine Woche auf einem zweiten Bildschirm und zählen Sie die Linien, die niemand aufzeichnet. Überrascht Sie diese Zahl, hätte sie irgendwann einen Auditor überrascht.
Zehn Server sind dauerhaft kostenlos, ohne abgeschaltete Funktionen. Mehr zum privilegierten Zugriff, zur KI-gestützten Konsole und zur Rotation von Zugangsdaten, oder nehmen Sie zehn kostenlose Server auf app.managelm.com und richten Sie sie auf den Host, den Sie einem Auditor am wenigsten erklären möchten.
" } }