Here is a test you can run in ten seconds. Picture Webmin, which first shipped in 1997, back when the state of the art in server management was a Perl CGI script and a lot of nerve. Now picture whatever admin panel you actually use today. Cockpit, cPanel, Plesk, the Proxmox UI, the web interface on that appliance in rack 4.
Same thing, isn't it. A list of modules down the left. A form in the middle. Users, cron, Apache, firewall, disk. Fill in the fields, press Save.
Twenty-eight years. Better fonts.
That is not laziness on anyone's part. Some very good engineers have spent careers on those tools. The category stopped moving because it hit a ceiling that no amount of engineering could get past, and the thing needed to get past it did not exist yet. It does now, which is the only reason this post has a point.
Think about what a form in an admin panel actually is. Years ago, a developer sat down and guessed that one day you would want to do that exact thing, in roughly that way, with those options. Then they built a screen for it. Every field on every page of every control panel ever written is a guess somebody made in advance about your future Tuesday.
The good panels have thousands of these guesses. That is why they are enormous, and why the module you need at 2am is still somehow not there.
Configuration management did not escape this. It relocated it. Ansible, Puppet, Salt and the rest are very good at reaching a state you have already described, and describing it is the entire job. A playbook is a guess with a version number and a code review. It runs beautifully against the estate you wrote it for. It has nothing whatsoever to say about the machine that drifted somewhere nobody imagined, which, funnily enough, is always the machine you are staring at.
Panel for the predicted work. SSH for everything else.
And be honest about where your week actually goes. The interesting work is in the SSH half. So is the risk. So is the knowledge that lives in three people's heads and leaves with them. And that half has no record of anything: not what you tried, not what you nearly ran and thought better of, not the twenty minutes you spent proving the problem was somewhere else entirely.
Auditors ask for that record. You produce a wiki page, last edited by somebody who no longer works there.
This gap was never a tooling problem. Closing it needs software that can look at a system it has never seen before, work out what is actually going on, and decide what to do. Nobody could build that. For thirty years the honest answer was to hire someone clever and hand them root.
Most of what is being marketed as AI for operations comes in one of two shapes. Both stop short, and you generally don't notice where until you have lived with one for a month.
The first talks about your servers. Paste in a log, get an explanation and a suggested command. Then the transaction ends at the copy button. It is a very well read colleague with no hands. Genuinely useful, and it leaves the execution problem precisely where it found it: with you, at midnight, pasting.
The second runs things it doesn't understand. An automation engine with a natural language front door. You describe the job, it writes the playbook, the playbook runs. The writing is new. The engine underneath is from 2012, still needs the destination described up front, and still falls over on the server with the answer nobody predicted.
Neither is wrong. They are two halves of one job, cut along the wrong line. Because the work where you want to watch every keystroke and the work you want to hand over completely are not two different products. They are the same afternoon.
ManageLM does both, deliberately, through one enforcement path.
Assisted. Open a real terminal on any managed host straight from your browser. No SSH key, no VPN, no port 22 open to anybody, because the session rides the connection the agent already holds outbound. Underneath the terminal sits an assistant that can see what is on your screen and answer the questions you would otherwise be searching for: why that failed, what that log line means, what to check next. It executes nothing on its own. It answers in words, and it may offer one command, which Run types and executes, or Insert drops on the prompt so you can read it, distrust it, and edit it. Only what is displayed gets sent, never keystrokes, so a password you typed cannot end up in the request. Printed secrets are masked in the browser before anything leaves. A passkey is required every time, and the whole session is in the audit log.
Agentic. Describe the outcome, then stop typing. Agents choose the skills, plan the steps, inspect the live system and do the work across the whole fleet, inside the same allowlist, the same kernel sandbox and the same audit trail. On a cron schedule if you like, since the audit that runs at 3am on Sunday is the one that catches things.
The bit that matters is that these are not two products sharing a logo. Same agent, same skills, same per person and per server permissions, same log. Supervise keystroke by keystroke on the database cluster that makes you nervous. Hand over the whole job on the forty web servers that don't. Nothing about the tool, the account or the trust model changes between those two sentences.
This is the whole argument, so it is worth being exact, because \"AI powered\" has been stapled onto a great many dashboards lately.
A dashboard talks to your servers. It holds credentials, opens a connection, and sends a command somebody wrote in advance. An agent is a process on the host, with a model behind it, that can look before it decides. That sounds like a technicality until you follow it through, at which point most of the constraints this category has lived under quietly fall over.
And none of this runs on trust. Every command an agent produces is checked against an explicit allowlist written in code: 33 shipped skills, 396 named operations, 1,025 distinct permitted commands, plus as many custom skills as you care to write. Execution is boxed in by Landlock and seccomp. Secrets stay environment variables, and the model only ever sees $DB_PASSWORD, never the value. The model proposes. Ordinary deterministic software disposes. The part doing the deciding does not read English, cannot be flattered, cannot be threatened, and cannot be prompt injected, because it isn't an AI.
Once you have agents on the fleet that can be trusted to act, a set of things that used to be separate products with separate invoices become ordinary features.
Security audits that end in a fix. 28 deterministic checks on Linux, 23 on Windows. SSH config, firewall state, TLS versions and ciphers, SUID binaries, sudoers including the .d directory nobody ever greps, world writable files, privileged containers, failed logins. Severity adapts to exposure, so an internet facing box is held to a harder standard than a lab VM and your score reflects real risk instead of checklist noise. Then tick the findings and hit Remediate. The agent backs up the original config, applies the smallest change that does the job, validates it (sshd -t before it dares restart anything), and rolls itself back if validation fails. Every finding carries framework tags, so the same scan feeds compliance evidence for 13 frameworks including CIS, SOC 2, ISO 27001, PCI DSS, NIS2, DORA, NIST CSF and HIPAA. Drift alerts tell you when a control that used to pass has stopped passing, in March, rather than in November, in a meeting, in front of an auditor.
Live CVE checking with nothing extra to install. Installed packages are matched against known vulnerabilities on every audit, across all the major distributions plus Python, npm, Go, Rust, Ruby, Java, .NET and PHP dependencies. Anything on CISA's actively exploited list gets flagged Critical automatically, because \"there is a proof of concept somewhere\" and \"people are using this today\" deserve very different mornings. No scanner appliance. No credentialed scan window. No third agent fighting the other two for CPU.
Threat detection that reads the whole story. Agents watch for the shape of a compromise as it happens. A web server or database spawning a shell. A service reading /etc/shadow or an SSH key it has no business near. Reverse shell patterns. New persistence appearing overnight. A quiet outbound connection to somewhere unhelpful. A second mode judges administrator sessions against what that person is actually for: a database admin editing the SSH config, a web admin dumping audit logs, someone clearing their shell history before logging out. It evaluates the arc of a session, not isolated commands, so stopping a service to work on it and starting it again doesn't page anybody at 4am. Alerts arrive in plain English with Kill Service, Kill Session and Discard built into the email. The kernel, your SSH access and the agent itself sit on a hard refuse list that no alert action can ever touch, which is the sort of detail you only think of after the first time a security tool locks you out of your own estate.
Credential rotation that actually finishes. Everybody has the account whose password was set in 2019 by somebody who has since left. Generating a strong password was never the hard part. The hard part is that the value lives in the account, three config files, a connection pooler nobody remembers, a vault entry and a cron job, and they all have to change inside the same minute or something falls over in a way that ruins your evening. ManageLM treats a credential as one source plus its consumers. Linux and Windows accounts, domain and LDAP accounts, PostgreSQL, MySQL, MS SQL, Oracle, MongoDB, Redis and Couchbase logins, Entra app secrets, machine to machine SSH keypairs. A rotation changes the account, delivers the new value everywhere it is consumed, restarts what genuinely needs restarting, and writes down what happened. Into a file with the owner and mode you specify. Into one value inside a config your service already reads, leaving the rest of the file byte for byte identical. Into a registry key, a database row, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk, 1Password Connect. Nobody reads the value at any point. There is no reveal button, because there is nothing to reveal.
Reconfiguring things on the fly. Which is just the daily job, and also the foundation the rest of that list is built on. An agent that can inspect a live system and change it safely is not one more feature. It is the thing that makes the features possible.
The newest piece makes the argument better than anything else, because the control panel lineage cannot do it at all.
A signing key on a server is a file, and files get copied. Into a build image, a CI secret, a home directory, three backups, a laptop that later got sold. It is the one secret you cannot take back: once a copy exists somewhere you didn't intend, nothing you do afterwards stops it signing, and revoking the certificate leaves everything signed before that date perfectly valid. The industry answer is an HSM, which works, and which arrives with a purchase order, a rack, a driver and a project plan with your name on it. The cheaper answer, PKCS#11 against a software token, dies for a deeply unglamorous reason: you ship a vendor library to every host, match its version to every client, patch it forever, and hand write a config file per application pointing at slot numbers and token serials. These projects die in the packaging, not the cryptography.
The ManageLM Keystore keeps the key in the portal and never lets it touch the host. Applications reach it over the same PKCS#11 interface an HSM speaks, so Java's SunPKCS11, OpenSSL 3 through pkcs11-provider, p11-kit, jarsigner and osslsigncode talk to it without a line changed. And the module is delivered by the agent. Grant a key to an application on a host and the agent fetches the module, installs it at a fixed path and brings up its listener. Withdraw the last grant and it removes it again. Nothing to add to your build, no version to track, nothing to do on a new server beyond installing the agent you were installing anyway. That is the difference between a key management programme that ships and one still in planning next quarter, and it only works because something intelligent and trusted is already running on every box.
The rest follows from the key never having left. Authorisation is per application rather than per host, so nginx and a JVM on the same machine are different principals with different credentials, and on Linux the agent reads the caller's Unix account from the kernel, so a stolen PIN on its own gets you nowhere. Nothing is cached, so suspending a grant or disabling a key bites on the very next signature, with no restart and no propagation delay. Revoking access genuinely revokes access, because there is no copy sitting on a host still able to sign after you have finished. It holds RSA, EC up to P-521, AES, HMAC and post quantum ML-DSA in all three FIPS 204 strengths, which matters because a signature made this year gets verified in 2035.
The limits, plainly, because knowing them is what makes a feature useful: this is not an HSM. Keys are software held and encrypted at rest, with no tamper resistant hardware and no FIPS certification, and it suits signing and decryption rather than TLS termination. What you get is central custody, per application authorisation, revocation that takes effect immediately, and a record of every operation and every refusal. For most estates that is the difference between a key nobody can account for and one that is properly governed, and it took an afternoon rather than a purchase order.
The difference was never the interface. Bolt a chat box onto Webmin tomorrow and it will still only do the things somebody wrote a module for, years ago, before they met you.
The difference is where the intelligence sits. Put it on the host, behind an allowlist it cannot argue with, inside a kernel sandbox, with a log of everything, and the tool stops being a catalogue of old guesses. It starts handling the case nobody predicted, which was always the case that mattered and always the one that ended in an unlogged SSH session at half past eleven at night.
That is why this generation could not have been built in 2015, and why it isn't a nicer dashboard. The ceiling moved.
Ten servers free, every feature, no card, nobody ringing you up to call you \"champion\" in week three. Installing the agent on a machine you don't care about takes about a minute: no YAML, no playbooks to port, no model to train. Run it read only for a week and read the logs, which show every command it wanted to run and every one it was refused. If it never earns more than read access, you still walk away holding an inventory, an access map and a compliance report you didn't have before.
Start at app.managelm.com. If the answer to \"where does our data go\" has to be \"nowhere\", run the whole platform yourself with Docker and skip the conversation.
", "fr": "Voici un test qui prend dix secondes. Pensez à Webmin, paru en 1997, quand l'état de l'art en administration de serveurs se résumait à un script CGI en Perl et beaucoup de culot. Pensez maintenant au panneau d'administration que vous utilisez vraiment aujourd'hui : Cockpit, cPanel, Plesk, l'interface de Proxmox, la console web de cet équipement dans la baie 4.
C'est la même chose, non ? Une liste de modules à gauche. Un formulaire au milieu. Utilisateurs, cron, Apache, firewall, disque. On remplit les champs, on clique sur Enregistrer.
Vingt-huit ans. De plus belles polices.
Ce n'est la paresse de personne : d'excellents ingénieurs ont consacré leur carrière à ces outils. La catégorie s'est arrêtée parce qu'elle a buté sur un plafond qu'aucune quantité d'ingénierie ne pouvait percer, et que l'outil capable de le percer n'existait pas encore. Il existe désormais, et c'est la seule raison d'être de cet article.
Réfléchissez à ce qu'est un formulaire d'administration. Il y a des années, une développeuse s'est assise et a parié qu'un jour vous voudriez faire exactement cette chose, à peu près de cette façon, avec ces options. Puis elle a construit l'écran correspondant. Chaque champ de chaque page de chaque panneau de contrôle jamais écrit est un pari fait à l'avance sur votre mardi à venir.
Les bons panneaux contiennent des milliers de paris. D'où leur taille, et d'où le fait que le module dont vous avez besoin à 2 heures du matin n'y est toujours pas.
La gestion de configuration n'y a pas échappé, elle a seulement déplacé le problème. Ansible, Puppet, Salt et les autres excellent à atteindre un état que vous avez déjà décrit, et le décrire, c'est tout le travail. Un playbook est un pari muni d'un numéro de version et d'une revue de code. Il se déroule à merveille sur le parc pour lequel il a été écrit. Il n'a rien à dire sur la machine qui a dérivé là où personne ne l'imaginait, laquelle se trouve être, comme par hasard, celle que vous avez sous les yeux.
Le panneau pour le travail prévu. SSH pour tout le reste.
Et soyez honnête sur l'endroit où passent vos semaines. Le travail intéressant est du côté SSH. Le risque aussi. Et le savoir qui vit dans la tête de trois personnes et s'en va avec elles. Or ce côté-là ne garde trace de rien : ni de ce que vous avez tenté, ni de ce que vous avez failli lancer avant d'y renoncer, ni des vingt minutes passées à démontrer que le problème venait d'ailleurs.
Les auditeurs réclament cette trace. Vous leur sortez une page de wiki, modifiée pour la dernière fois par quelqu'un qui est parti depuis.
Cet écart n'a jamais été un problème d'outillage. Le combler réclame un logiciel capable de regarder un système qu'il n'a jamais vu, de comprendre ce qui s'y passe et de décider quoi faire. Personne ne savait construire ça. Pendant trente ans, la réponse honnête a été de recruter quelqu'un de brillant et de lui donner root.
Ce qu'on vend actuellement sous l'étiquette « IA pour l'exploitation » prend l'une de deux formes. Les deux s'arrêtent en chemin, et l'on ne voit généralement pas où avant d'avoir vécu un mois avec.
La première parle de vos serveurs. Vous collez un log, vous récoltez une explication et une commande suggérée. Puis tout s'arrête au bouton « copier ». C'est un collègue très cultivé, mais sans mains. Réellement utile, et qui laisse le problème de l'exécution exactement là où il l'a trouvé : chez vous, à minuit, en train de coller.
La seconde exécute ce qu'elle ne comprend pas. Un moteur d'automatisation avec une porte d'entrée en langage naturel. Vous décrivez la tâche, il écrit le playbook, le playbook s'exécute. L'écriture est neuve ; le moteur en dessous date de 2012, réclame toujours que la destination soit décrite d'avance, et trébuche toujours sur le serveur dont personne n'avait prévu la réponse.
Aucun des deux n'a tort. Ce sont deux moitiés d'un même métier, découpées au mauvais endroit. Car le travail où vous voulez surveiller chaque frappe et celui que vous voulez déléguer entièrement ne sont pas deux produits : c'est le même après-midi.
ManageLM fait les deux, délibérément, par un seul chemin d'application des règles.
En mode assisté. Ouvrez un vrai terminal sur n'importe quel hôte géré, depuis votre navigateur. Sans clé SSH, sans VPN, sans port 22 ouvert à quiconque : la session emprunte la connexion sortante que l'agent maintient déjà. Sous le terminal se tient un assistant qui voit ce qui est affiché et répond aux questions que vous seriez allé chercher ailleurs : pourquoi ça a échoué, ce que dit cette ligne de log, quoi vérifier ensuite. Il n'exécute rien de lui-même. Il répond avec des mots et peut proposer une commande, qu'Exécuter saisit et lance, ou qu'Insérer dépose sur l'invite pour que vous la lisiez, vous en méfiiez et la corrigiez. Seul ce qui est affiché part, jamais les frappes : un mot de passe tapé ne peut donc pas se retrouver dans la requête. Les secrets affichés sont masqués dans le navigateur avant que quoi que ce soit ne sorte. Une passkey est exigée à chaque fois, et toute la session figure au journal d'audit.
En mode agentique. Décrivez le résultat attendu, puis lâchez le clavier. Les agents choisissent les compétences, planifient les étapes, inspectent le système en fonctionnement et font le travail sur toute la flotte, dans la même liste blanche, la même sandbox noyau et la même piste d'audit. Sur une planification cron si vous le souhaitez, car l'audit qui tourne le dimanche à 3 heures du matin est celui qui trouve des choses.
L'essentiel : il ne s'agit pas de deux produits qui partagent un logo. Même agent, mêmes compétences, mêmes permissions par personne et par serveur, même journal. Surveillez frappe par frappe le cluster de bases de données qui vous inquiète. Déléguez l'ensemble sur les quarante serveurs web qui ne vous inquiètent pas. Entre ces deux phrases, ni l'outil, ni le compte, ni le modèle de confiance ne changent.
C'est tout l'argument, alors soyons précis : l'étiquette « pilotée par IA » a été agrafée à beaucoup de tableaux de bord ces derniers temps.
Un tableau de bord parle à vos serveurs. Il détient des identifiants, ouvre une connexion et envoie une commande écrite d'avance. Un agent est un processus sur l'hôte, avec un modèle derrière lui, capable de regarder avant de décider. Cela ressemble à un détail, jusqu'à ce qu'on en tire les conséquences : la plupart des contraintes qui pesaient sur la catégorie tombent alors d'elles-mêmes.
Et rien de tout cela ne repose sur la confiance. Chaque commande produite par un agent est confrontée à une liste blanche explicite, écrite dans le code : 33 compétences livrées, 396 opérations nommées, 1 025 commandes distinctes autorisées, plus autant de compétences maison que vous voudrez écrire. L'exécution est enfermée par Landlock et seccomp. Les secrets restent des variables d'environnement, et le modèle ne voit jamais que $DB_PASSWORD, jamais la valeur. Le modèle propose, un logiciel ordinaire et déterministe dispose. La partie qui décide ne lit pas le langage naturel, ne se laisse ni flatter, ni menacer, ni détourner par injection de prompt, pour la bonne raison qu'elle n'est pas une IA.
Dès lors que des agents dignes de confiance agissent sur toute la flotte, une série de choses qui étaient jusqu'ici des produits séparés, avec des factures séparées, deviennent de simples fonctionnalités.
Des audits de sécurité qui se terminent par une correction. 28 vérifications déterministes sous Linux, 23 sous Windows : configuration SSH, état du firewall, versions et chiffrements TLS, binaires SUID, sudoers y compris le répertoire .d que personne ne pense à parcourir, fichiers inscriptibles par tous, conteneurs privilégiés, tentatives de connexion échouées. La sévérité suit l'exposition, une machine face à Internet est jugée plus durement qu'une VM de laboratoire, et votre score reflète le risque réel plutôt que le bruit d'une liste de cases. Cochez les constats, cliquez sur Remédier : l'agent sauvegarde la configuration d'origine, applique le plus petit changement qui règle le problème, le valide (sshd -t avant d'oser redémarrer quoi que ce soit) et revient en arrière si la validation échoue. Chaque constat porte ses référentiels, si bien que le même scan alimente les preuves de conformité pour 13 cadres, dont CIS, SOC 2, ISO 27001, PCI DSS, NIS2, DORA, NIST CSF et HIPAA. Les alertes de dérive vous préviennent qu'un contrôle qui passait a cessé de passer, en mars, plutôt qu'en novembre, en réunion, devant un auditeur.
Une veille CVE permanente, sans rien installer de plus. À chaque audit, les paquets installés sont confrontés aux vulnérabilités connues, sur toutes les grandes distributions, ainsi que sur les dépendances Python, npm, Go, Rust, Ruby, Java, .NET et PHP. Tout ce qui figure sur la liste des failles activement exploitées de la CISA passe automatiquement en critique, parce qu'« il existe une preuve de concept quelque part » et « on l'exploite aujourd'hui » méritent des matinées très différentes. Aucun boîtier de scan, aucune fenêtre de scan authentifié, aucun troisième agent qui se dispute le processeur avec les deux autres.
Une détection des menaces qui lit toute l'histoire. Les agents guettent la silhouette d'une compromission pendant qu'elle se déroule : un serveur web ou une base de données qui ouvre un shell, un service qui lit /etc/shadow ou une clé SSH qui ne le regarde pas, des motifs de reverse shell, une persistance apparue dans la nuit, une connexion sortante discrète vers un endroit peu recommandable. Un second mode juge les sessions d'administration à l'aune du rôle de la personne : une administratrice de bases de données qui édite la configuration SSH, un administrateur web qui aspire les journaux d'audit, quelqu'un qui efface son historique de shell avant de partir. L'évaluation porte sur l'arc complet d'une session, pas sur des commandes isolées : arrêter un service pour y travailler puis le relancer ne réveille donc personne à 4 heures du matin. Les alertes arrivent en langage clair, avec Tuer le service, Tuer la session et Écarter directement dans l'e-mail. Le noyau, votre accès SSH et l'agent lui-même figurent sur une liste de refus stricte qu'aucune action d'alerte ne peut toucher, le genre de détail auquel on ne pense qu'après s'être fait verrouiller dehors par un outil de sécurité.
Une rotation des identifiants qui va jusqu'au bout. Tout le monde a ce compte dont le mot de passe a été choisi en 2019 par quelqu'un qui est parti depuis. Produire un mot de passe solide n'a jamais été le plus dur ; le plus dur, c'est que la valeur vit dans le compte, dans trois fichiers de configuration, dans un pooler dont personne ne se souvient, dans une entrée de coffre-fort et dans une tâche cron, et que tout cela doit changer dans la même minute sous peine de voir quelque chose tomber d'une façon qui gâchera votre soirée. ManageLM traite un identifiant comme une source plus ses consommateurs : comptes Linux et Windows, comptes de domaine et LDAP, identifiants PostgreSQL, MySQL, MS SQL, Oracle, MongoDB, Redis et Couchbase, secrets d'application Entra, paires de clés SSH de machine à machine. Une rotation change le compte, livre la nouvelle valeur partout où elle sert, relance ce qui doit vraiment l'être et consigne ce qui s'est passé. Dans un fichier, avec le propriétaire et les droits que vous indiquez. Dans une valeur unique au sein d'une configuration que votre service lit déjà, le reste du fichier revenant identique octet pour octet. Dans une clé de registre, une ligne de base de données, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk, 1Password Connect. À aucun moment personne ne lit la valeur : il n'y a pas de bouton « afficher », parce qu'il n'y a rien à afficher.
Reconfigurer les choses à la volée. C'est le travail quotidien, et c'est aussi le socle de tout le reste de cette liste. Un agent capable d'inspecter un système vivant et de le modifier sans danger n'est pas une fonctionnalité de plus : c'est ce qui rend les autres possibles.
Le morceau le plus récent défend l'argument mieux que tout le reste, parce que la lignée des panneaux de contrôle en est tout bonnement incapable.
Une clé de signature posée sur un serveur est un fichier, et les fichiers se copient : dans une image de build, dans un secret de CI, dans un répertoire personnel, dans trois sauvegardes, sur un portable revendu depuis. C'est le seul secret qu'on ne peut pas reprendre : dès qu'une copie traîne là où vous ne l'aviez pas prévu, rien de ce que vous ferez ensuite ne l'empêchera de signer, et révoquer le certificat laisse parfaitement valides toutes les signatures antérieures. La réponse du secteur s'appelle HSM : cela fonctionne, et cela s'accompagne d'un bon de commande, d'une baie, d'un pilote et d'un plan de projet à votre nom. La réponse moins chère, PKCS#11 devant un jeton logiciel, meurt pour une raison profondément prosaïque : il faut livrer une bibliothèque du fournisseur sur chaque hôte, accorder sa version à chaque client, la maintenir pour toujours, et écrire à la main un fichier de configuration par application, avec numéros de slot et numéros de série de jetons. Ces projets meurent dans l'emballage, pas dans la cryptographie.
Le Keystore ManageLM garde la clé dans le portail et ne la laisse jamais toucher l'hôte. Les applications l'atteignent par l'interface PKCS#11, celle-là même que parle un HSM : SunPKCS11 de Java, OpenSSL 3 via pkcs11-provider, p11-kit, jarsigner et osslsigncode lui parlent sans qu'une ligne change. Et c'est l'agent qui livre le module. Accordez une clé à une application sur un hôte : l'agent récupère le module, l'installe à un chemin fixe et démarre son écouteur. Retirez la dernière autorisation : il le supprime. Rien à ajouter à votre build, aucune version à suivre, rien à faire sur un nouveau serveur au-delà d'installer l'agent que vous alliez installer de toute manière. C'est la différence entre un projet de gestion de clés qui sort et un projet encore en planification le trimestre prochain, et cela ne fonctionne que parce qu'une brique intelligente et reconnue tourne déjà sur chaque machine.
Le reste découle du fait que la clé n'est jamais partie. L'autorisation se donne par application et non par hôte : nginx et une JVM sur la même machine sont deux entités distinctes, avec des identifiants distincts, et sous Linux l'agent demande au noyau le compte Unix de l'appelant, si bien qu'un code PIN volé ne mène nulle part à lui seul. Rien n'est mis en cache : suspendre une autorisation ou désactiver une clé prend effet dès la signature suivante, sans redémarrage ni délai de propagation. Révoquer un accès révoque vraiment l'accès, puisqu'il ne reste aucune copie capable de signer une fois que vous avez terminé. Le keystore accepte RSA, EC jusqu'à P-521, AES, HMAC et le post-quantique ML-DSA dans les trois niveaux de FIPS 204, ce qui compte, car une signature produite cette année sera vérifiée en 2035.
Les limites, dites franchement, car les connaître est ce qui rend une fonctionnalité utile : ce n'est pas un HSM. Les clés sont détenues par logiciel et chiffrées au repos, sans matériel inviolable ni certification FIPS, et l'ensemble convient à la signature et au déchiffrement plutôt qu'à la terminaison TLS. Ce que vous obtenez, c'est une garde centralisée, une autorisation par application, une révocation immédiate et le relevé de chaque opération comme de chaque refus. Pour la plupart des parcs, c'est la différence entre une clé dont personne ne peut rendre compte et une clé réellement gouvernée, obtenue en un après-midi plutôt qu'en un bon de commande.
La différence n'a jamais été l'interface. Greffez demain une zone de discussion sur Webmin : il ne saura toujours faire que ce pour quoi quelqu'un a écrit un module, il y a des années, avant de vous connaître.
La différence tient à l'endroit où siège l'intelligence. Posez-la sur l'hôte, derrière une liste blanche qu'elle ne peut pas discuter, dans une sandbox noyau, avec le journal de tout, et l'outil cesse d'être un catalogue de vieux paris. Il se met à traiter le cas que personne n'avait prévu, celui qui comptait depuis toujours et qui finissait depuis toujours en session SSH sans trace, à onze heures et demie du soir.
Voilà pourquoi cette génération ne pouvait pas naître en 2015, et pourquoi il ne s'agit pas d'un tableau de bord plus joli. Le plafond s'est déplacé.
Dix serveurs gratuits, toutes les fonctionnalités, pas de carte bancaire, personne pour vous appeler « champion » la troisième semaine. Installer l'agent sur une machine qui vous est indifférente prend une minute : pas de YAML, pas de playbooks à porter, pas de modèle à entraîner. Laissez-le une semaine en lecture seule et lisez les logs, qui montrent chaque commande qu'il a voulu lancer et chacune qui lui a été refusée. S'il ne mérite jamais mieux que la lecture seule, vous repartez tout de même avec un inventaire, une cartographie des accès et un rapport de conformité que vous n'aviez pas.
Commencez sur app.managelm.com. Si votre réponse à « où partent nos données » doit être « nulle part », exploitez la plateforme entière vous-même avec Docker : la conversation n'a plus lieu d'être.
", "de": "Hier ist ein Test, der zehn Sekunden dauert. Denken Sie an Webmin, erschienen 1997, als der Stand der Technik in der Serververwaltung aus einem Perl-CGI-Skript und einer Menge Mut bestand. Denken Sie nun an das Adminpanel, das Sie heute tatsächlich benutzen: Cockpit, cPanel, Plesk, die Proxmox-Oberfläche, die Weboberfläche jenes Geräts in Rack 4.
Dasselbe, oder? Links eine Liste von Modulen. In der Mitte ein Formular. Benutzer, Cron, Apache, Firewall, Festplatte. Felder ausfüllen, Speichern drücken.
Achtundzwanzig Jahre. Schönere Schriften.
Das ist niemandes Faulheit: Sehr gute Ingenieure haben ganze Laufbahnen in diese Werkzeuge gesteckt. Die Kategorie kam zum Stillstand, weil sie an eine Decke stieß, die keine Ingenieurskunst durchbrechen konnte, und weil das Werkzeug dafür noch nicht existierte. Jetzt existiert es, und nur deshalb hat dieser Beitrag einen Sinn.
Überlegen Sie, was ein Admin-Formular eigentlich ist. Vor Jahren setzte sich eine Entwicklerin hin und wettete, dass Sie eines Tages genau diese Sache tun wollen, ungefähr auf diese Weise, mit diesen Optionen. Dann baute sie den passenden Bildschirm. Jedes Feld auf jeder Seite jedes je geschriebenen Kontrollpanels ist eine Wette, die jemand im Voraus auf Ihren künftigen Dienstag abgeschlossen hat.
Die guten Panels enthalten Tausende solcher Wetten. Daher ihre Größe, und daher die Tatsache, dass das Modul, das Sie um 2 Uhr nachts brauchen, trotzdem fehlt.
Das Konfigurationsmanagement ist dem nicht entkommen, es hat das Problem nur verschoben. Ansible, Puppet, Salt und die anderen sind glänzend darin, einen Zustand herzustellen, den Sie bereits beschrieben haben, und ihn zu beschreiben ist die ganze Arbeit. Ein Playbook ist eine Wette mit Versionsnummer und Code-Review. Gegen die Landschaft, für die es geschrieben wurde, läuft es hervorragend. Über die Maschine, die irgendwohin abgedriftet ist, woran niemand dachte, sagt es nichts, und das ist komischerweise immer die Maschine, auf die Sie gerade schauen.
Das Panel für die vorhergesehene Arbeit. SSH für alles andere.
Und seien Sie ehrlich, wohin Ihre Wochen gehen. Die interessante Arbeit liegt auf der SSH-Seite. Das Risiko auch. Und das Wissen, das in den Köpfen von drei Leuten sitzt und mit ihnen geht. Diese Seite hält von nichts eine Spur fest: nicht davon, was Sie versucht haben, nicht davon, was Sie beinahe abgesetzt und dann gelassen haben, nicht von den zwanzig Minuten, in denen Sie nachwiesen, dass das Problem ganz woanders lag.
Auditoren verlangen diese Spur. Sie legen eine Wiki-Seite vor, zuletzt bearbeitet von jemandem, der längst weg ist.
Diese Lücke war nie ein Werkzeugproblem. Sie zu schließen verlangt Software, die ein nie gesehenes System ansehen, verstehen, was dort vorgeht, und entscheiden kann, was zu tun ist. Das konnte niemand bauen. Dreißig Jahre lang lautete die ehrliche Antwort: jemanden Klugen einstellen und ihm root geben.
Was heute als KI für den Betrieb verkauft wird, hat eine von zwei Formen. Beide hören zu früh auf, und man merkt meist erst nach einem Monat, wo.
Das erste redet über Ihre Server. Sie fügen ein Log ein und ernten eine Erklärung samt Befehlsvorschlag. Dann endet alles am Knopf zum Kopieren. Ein sehr belesener Kollege ohne Hände. Wirklich nützlich, und er lässt das Ausführungsproblem genau dort, wo er es fand: bei Ihnen, um Mitternacht, beim Einfügen.
Das zweite führt aus, was es nicht versteht. Eine Automatisierungsmaschine mit einer Eingangstür in natürlicher Sprache. Sie beschreiben die Aufgabe, sie schreibt das Playbook, das Playbook läuft. Das Schreiben ist neu; die Maschine darunter stammt aus 2012, verlangt weiterhin, dass das Ziel vorab beschrieben wird, und stolpert weiterhin über den Server, dessen Antwort niemand vorhergesehen hat.
Keines von beiden ist falsch. Es sind zwei Hälften einer Aufgabe, an der falschen Linie geteilt. Denn die Arbeit, bei der Sie jeden Tastenanschlag sehen wollen, und die Arbeit, die Sie ganz abgeben wollen, sind nicht zwei Produkte: Es ist derselbe Nachmittag.
ManageLM macht beides, absichtlich, über einen einzigen Durchsetzungspfad.
Assistiert. Öffnen Sie aus dem Browser ein echtes Terminal auf jedem verwalteten Host. Kein SSH-Schlüssel, kein VPN, kein Port 22 für irgendwen offen: Die Sitzung nutzt die ausgehende Verbindung, die der Agent ohnehin hält. Unter dem Terminal sitzt ein Assistent, der sieht, was auf dem Bildschirm steht, und die Fragen beantwortet, die Sie sonst gesucht hätten: warum das fehlschlug, was diese Log-Zeile bedeutet, was als Nächstes zu prüfen ist. Er führt von sich aus nichts aus. Er antwortet mit Worten und darf einen Befehl anbieten, den Ausführen eintippt und startet oder den Einfügen auf der Eingabezeile ablegt, damit Sie ihn lesen, ihm misstrauen und ihn ändern können. Gesendet wird nur das Angezeigte, nie Tastenanschläge: Ein getipptes Passwort kann also nicht in der Anfrage landen. Ausgegebene Geheimnisse werden im Browser maskiert, bevor etwas hinausgeht. Jedes Mal ist ein Passkey nötig, und die ganze Sitzung steht im Audit-Log.
Agentisch. Beschreiben Sie das Ergebnis und lassen Sie die Tastatur los. Agenten wählen die Skills, planen die Schritte, sehen sich das laufende System an und erledigen die Arbeit über die ganze Flotte, in derselben Allowlist, derselben Kernel-Sandbox und derselben Audit-Spur. Auf Wunsch nach Cron-Plan, denn das Audit, das sonntags um 3 Uhr läuft, ist das, welches etwas findet.
Wichtig dabei: Das sind nicht zwei Produkte mit demselben Logo. Derselbe Agent, dieselben Skills, dieselben Berechtigungen je Person und je Server, dasselbe Log. Überwachen Sie Tastenanschlag für Tastenanschlag den Datenbankcluster, der Ihnen Sorgen macht. Geben Sie die ganze Arbeit auf den vierzig Webservern ab, die das nicht tun. Zwischen diesen beiden Sätzen ändern sich weder Werkzeug noch Konto noch Vertrauensmodell.
Das ist das ganze Argument, also seien wir genau: „KI-gestützt“ wurde in letzter Zeit auf sehr viele Dashboards geklebt.
Ein Dashboard spricht zu Ihren Servern. Es hält Zugangsdaten, öffnet eine Verbindung und schickt einen Befehl, den jemand vorab geschrieben hat. Ein Agent ist ein Prozess auf dem Host, mit einem Modell dahinter, der hinsehen kann, bevor er entscheidet. Das klingt nach einer Spitzfindigkeit, bis man es zu Ende denkt: Dann fallen die meisten Einschränkungen, unter denen diese Kategorie litt, von selbst.
Und nichts davon beruht auf Vertrauen. Jeder Befehl, den ein Agent hervorbringt, wird gegen eine ausdrückliche, im Code hinterlegte Allowlist geprüft: 33 mitgelieferte Skills, 396 benannte Operationen, 1.025 verschiedene erlaubte Befehle, dazu so viele eigene Skills, wie Sie schreiben mögen. Die Ausführung ist von Landlock und seccomp eingeschlossen. Geheimnisse bleiben Umgebungsvariablen, und das Modell sieht immer nur $DB_PASSWORD, nie den Wert. Das Modell schlägt vor, gewöhnliche deterministische Software entscheidet. Was entscheidet, liest keine natürliche Sprache, lässt sich weder schmeicheln noch bedrohen noch per Prompt-Injection umlenken, aus dem guten Grund, dass es keine KI ist.
Sobald vertrauenswürdige Agenten auf der ganzen Flotte handeln dürfen, werden Dinge, die bisher eigene Produkte mit eigenen Rechnungen waren, zu gewöhnlichen Funktionen.
Sicherheitsaudits, die mit einer Behebung enden. 28 deterministische Prüfungen unter Linux, 23 unter Windows: SSH-Konfiguration, Firewall-Zustand, TLS-Versionen und -Chiffren, SUID-Binaries, sudoers samt dem .d-Verzeichnis, das nie jemand durchsucht, für alle beschreibbare Dateien, privilegierte Container, fehlgeschlagene Logins. Der Schweregrad folgt der Exposition, eine zum Internet offene Maschine wird strenger beurteilt als eine Labor-VM, und Ihr Wert zeigt echtes Risiko statt Checklisten-Rauschen. Befunde anhaken, auf Beheben klicken: Der Agent sichert die ursprüngliche Konfiguration, wendet die kleinste Änderung an, die die Sache löst, prüft sie (sshd -t, bevor er irgendetwas neu zu starten wagt) und nimmt sich selbst zurück, wenn die Prüfung fehlschlägt. Jeder Befund trägt seine Rahmenwerke, derselbe Scan speist also Compliance-Nachweise für 13 Rahmenwerke, darunter CIS, SOC 2, ISO 27001, PCI DSS, NIS2, DORA, NIST CSF und HIPAA. Drift-Alarme melden Ihnen im März, dass eine bestandene Kontrolle nicht mehr besteht, statt im November, im Meeting, vor einem Auditor.
Laufende CVE-Prüfung, ohne zusätzliche Installation. Bei jedem Audit werden die installierten Pakete gegen bekannte Schwachstellen abgeglichen, über alle großen Distributionen hinweg und ebenso für Abhängigkeiten aus Python, npm, Go, Rust, Ruby, Java, .NET und PHP. Alles, was auf der Liste aktiv ausgenutzter Schwachstellen der CISA steht, wird automatisch kritisch, denn „irgendwo gibt es einen Machbarkeitsnachweis“ und „das wird heute ausgenutzt“ verdienen sehr verschiedene Vormittage. Kein Scanner-Gerät, kein Fenster für authentifizierte Scans, kein dritter Agent, der mit den anderen beiden um CPU ringt.
Bedrohungserkennung, die die ganze Geschichte liest. Agenten achten auf die Gestalt einer Kompromittierung, während sie geschieht: ein Webserver oder eine Datenbank, die eine Shell öffnet, ein Dienst, der /etc/shadow oder einen SSH-Schlüssel liest, der ihn nichts angeht, Muster von Reverse Shells, über Nacht entstandene Persistenz, eine leise ausgehende Verbindung an einen zweifelhaften Ort. Ein zweiter Modus misst Administratorsitzungen an der Rolle der Person: eine Datenbankadministratorin, die die SSH-Konfiguration bearbeitet, ein Webadministrator, der Audit-Logs absaugt, jemand, der vor dem Abmelden die Shell-Historie löscht. Bewertet wird der ganze Bogen einer Sitzung, nicht einzelne Befehle: Einen Dienst zum Arbeiten anzuhalten und wieder zu starten weckt also um 4 Uhr niemanden. Alarme kommen in klarer Sprache, mit Dienst beenden, Sitzung beenden und Verwerfen direkt in der E-Mail. Der Kernel, Ihr SSH-Zugang und der Agent selbst stehen auf einer harten Ausschlussliste, die keine Alarmaktion berühren kann, die Art Detail, an die man erst denkt, nachdem einen ein Sicherheitswerkzeug einmal aus der eigenen Landschaft ausgesperrt hat.
Rotation von Zugangsdaten, die zu Ende geht. Jeder hat dieses Konto, dessen Passwort 2019 von jemandem gewählt wurde, der längst weg ist. Ein starkes Passwort zu erzeugen war nie das Schwere; schwer ist, dass der Wert im Konto lebt, in drei Konfigurationsdateien, in einem Pooler, an den sich niemand erinnert, in einem Tresoreintrag und in einem Cron-Job, und dass all das in derselben Minute wechseln muss, sonst fällt etwas um und ruiniert Ihren Abend. ManageLM behandelt einen Zugang als Quelle samt ihren Verbrauchern: Linux- und Windows-Konten, Domänen- und LDAP-Konten, Anmeldungen für PostgreSQL, MySQL, MS SQL, Oracle, MongoDB, Redis und Couchbase, Entra-Anwendungsgeheimnisse, SSH-Schlüsselpaare zwischen Maschinen. Eine Rotation ändert das Konto, liefert den neuen Wert überall dorthin, wo er gebraucht wird, startet neu, was wirklich neu starten muss, und hält fest, was geschah. In eine Datei, mit Eigentümer und Rechten nach Ihrer Vorgabe. In einen einzelnen Wert innerhalb einer Konfiguration, die Ihr Dienst ohnehin liest, wobei der Rest der Datei Byte für Byte gleich bleibt. In einen Registrierungsschlüssel, eine Datenbankzeile, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk, 1Password Connect. Niemand liest den Wert zu irgendeinem Zeitpunkt: Es gibt keinen Knopf zum Anzeigen, weil es nichts anzuzeigen gibt.
Dinge im laufenden Betrieb umkonfigurieren. Das ist die tägliche Arbeit und zugleich das Fundament für alles Übrige auf dieser Liste. Ein Agent, der ein lebendes System prüfen und gefahrlos ändern kann, ist nicht eine weitere Funktion: Er ist das, was die anderen möglich macht.
Das jüngste Stück belegt das Argument besser als alles andere, weil die Linie der Kontrollpanels dazu schlicht nicht in der Lage ist.
Ein Signaturschlüssel auf einem Server ist eine Datei, und Dateien werden kopiert: in ein Build-Image, in ein CI-Geheimnis, in ein Heimatverzeichnis, in drei Sicherungen, auf einen später verkauften Laptop. Es ist das eine Geheimnis, das man nicht zurückholen kann: Sobald eine Kopie irgendwo liegt, wo Sie sie nicht vorgesehen haben, hindert nichts sie am Signieren, und das Zertifikat zu widerrufen lässt alles davor Signierte gültig. Die Antwort der Branche heißt HSM: Sie funktioniert und bringt Bestellung, Rack, Treiber und einen Projektplan mit Ihrem Namen mit. Die billigere Antwort, PKCS#11 vor einem Software-Token, stirbt aus einem zutiefst unglamourösen Grund: Man liefert eine Herstellerbibliothek auf jeden Host, stimmt ihre Version mit jedem Client ab, pflegt sie für immer und schreibt je Anwendung von Hand eine Konfigurationsdatei mit Slot-Nummern und Token-Seriennummern. Diese Vorhaben sterben an der Verpackung, nicht an der Kryptografie.
Der ManageLM-Keystore hält den Schlüssel im Portal und lässt ihn den Host nie berühren. Anwendungen erreichen ihn über die PKCS#11-Schnittstelle, dieselbe, die ein HSM spricht: Javas SunPKCS11, OpenSSL 3 über pkcs11-provider, p11-kit, jarsigner und osslsigncode reden mit ihm, ohne dass sich eine Zeile ändert. Und das Modul liefert der Agent. Erteilen Sie einer Anwendung auf einem Host Zugriff auf einen Schlüssel: Der Agent holt das Modul, installiert es an einem festen Pfad und startet dessen Listener. Nehmen Sie die letzte Erteilung zurück: Er entfernt es. Nichts zu Ihrem Build hinzuzufügen, keine Version nachzuhalten, auf einem neuen Server nichts zu tun außer den Agenten zu installieren, den Sie ohnehin installiert hätten. Das ist der Unterschied zwischen einem Schlüsselverwaltungsvorhaben, das ausgeliefert wird, und einem, das nächstes Quartal noch in Planung ist, und es geht nur, weil auf jeder Maschine bereits ein intelligenter, vertrauter Baustein läuft.
Der Rest folgt daraus, dass der Schlüssel nie hinausgegangen ist. Autorisiert wird je Anwendung statt je Host: nginx und eine JVM auf derselben Maschine sind zwei verschiedene Beteiligte mit verschiedenen Zugangsdaten, und unter Linux erfragt der Agent beim Kernel das Unix-Konto des Aufrufers, sodass eine gestohlene PIN allein nirgendwohin führt. Nichts wird zwischengespeichert: Eine Erteilung auszusetzen oder einen Schlüssel abzuschalten greift schon bei der nächsten Signatur, ohne Neustart, ohne Verzögerung. Zugriff zu widerrufen widerruft ihn wirklich, denn danach liegt keine Kopie mehr herum, die noch signieren könnte. Der Keystore trägt RSA, EC bis P-521, AES, HMAC und das postquantensichere ML-DSA in allen drei Stärken von FIPS 204, was zählt, denn eine dieses Jahr erstellte Signatur wird 2035 geprüft.
Die Grenzen, offen gesagt, denn erst sie machen eine Funktion brauchbar: Das ist kein HSM. Die Schlüssel liegen in Software und sind im Ruhezustand verschlüsselt, ohne manipulationssichere Hardware und ohne FIPS-Zertifizierung, und das Ganze eignet sich für Signatur und Entschlüsselung, nicht für TLS-Terminierung. Sie bekommen zentrale Verwahrung, Autorisierung je Anwendung, sofortigen Widerruf und den Nachweis jeder Operation wie jeder Ablehnung. Für die meisten Landschaften ist das der Unterschied zwischen einem Schlüssel, über den niemand Auskunft geben kann, und einem ordentlich verwalteten, gewonnen in einem Nachmittag statt in einer Bestellung.
Der Unterschied war nie die Oberfläche. Schrauben Sie morgen ein Chatfenster an Webmin: Es kann weiterhin nur das, wofür jemand vor Jahren ein Modul geschrieben hat, bevor er Sie kannte.
Der Unterschied liegt darin, wo die Intelligenz sitzt. Setzen Sie sie auf den Host, hinter eine Allowlist, mit der sie nicht diskutieren kann, in eine Kernel-Sandbox, mit einem Log über alles, und das Werkzeug hört auf, ein Katalog alter Wetten zu sein. Es beginnt, den Fall zu behandeln, den niemand vorhergesehen hat, also den Fall, auf den es immer ankam und der immer um halb zwölf nachts in einer SSH-Sitzung ohne Spur endete.
Deshalb konnte diese Generation 2015 nicht entstehen, und deshalb ist sie kein hübscheres Dashboard. Die Decke hat sich verschoben.
Zehn Server kostenlos, alle Funktionen, keine Karte, niemand, der Sie in Woche drei „Champion“ nennt. Den Agenten auf einer Maschine zu installieren, die Ihnen egal ist, dauert eine Minute: kein YAML, keine Playbooks zu portieren, kein Modell zu trainieren. Lassen Sie ihn eine Woche nur lesend laufen und lesen Sie die Logs, die jeden Befehl zeigen, den er ausführen wollte, und jeden, der ihm verweigert wurde. Verdient er nie mehr als Lesezugriff, gehen Sie trotzdem mit einem Inventar, einer Zugriffskarte und einem Compliance-Bericht nach Hause, die Sie vorher nicht hatten.
Beginnen Sie auf app.managelm.com. Wenn Ihre Antwort auf „wohin gehen unsere Daten“ „nirgendwohin“ lauten muss, betreiben Sie die ganze Plattform selbst mit Docker, dann erübrigt sich das Gespräch.
" } }