Somewhere on your network there's an account whose password was set in 2019.
You know which one. It runs the nightly backup, or it's the bind account the whole directory authenticates against, or it's the database role three applications share because that was quicker at the time. Whoever picked the password has left. It's written down somewhere it shouldn't be. Everyone agrees it has to change, and nobody wants to be the person who changes it, because the last one who tried took a service down for forty minutes and spent the rest of that week finding the places still holding the old value.
Most estates have a handful of these. The older the company, the more of them, and the less anyone remembers about how they got there.
Ask for the credential policy and you'll get a good one. Rotate every 90 days, unique per service, no shared secrets, named owner. It's approved, it's in the ISMS, and it goes to auditors with a straight face.
Then look at what actually rotates. User passwords do, because the identity provider won't let them not. Certificates do, because they expire on their own schedule and take a website down with them if they're ignored. After that it's mostly theory. Service accounts have standing privilege, no MFA, no expiry, and nothing in the stack that forces the issue, so they sit where they are.
The gap isn't discipline. It's that the policy talks about rotation as if it were one action, when it's really a small distributed transaction spread across machines that don't know about each other.
Changing the password at the source takes a second. Everybody gets that far.
The trouble is the other six copies. A config file on three web servers. A connection pooler somebody stood up in 2021 and never wrote down. A vault entry. A cron job. An environment file next to a systemd unit. A CI variable. All of them have to be right in the same minute the source changes, and when one gets missed you usually don't find out immediately, because the service is holding open connections and carries on working. Then the pool recycles at 3am and something breaks four hours after the thing that actually caused it, which is the worst possible gap for whoever is on call.
Generating a strong password was never the hard part. Landing it everywhere at once is.
Vaults and PAM. They do the first half well: change the password on the account, store what they generated. The second half is left to you. Every consumer now has to fetch its secret from the vault instead of reading it where it has always read it, which means going into applications you may not own, adding a broker or a sidecar, and finding budget for a project. Then there's the network. Something that rotates a domain account needs a route to the domain controller. Something that rotates a database password needs a hole into that VLAN. Add a privileged account with enough rights to reach everything on the list and you've built a second crown jewel in order to look after the first one. Plenty of people make that trade, but it should at least be a deliberate one.
Ansible and friends. Config management will template a password into a file and bounce a service without complaint. It won't tell you a credential is due, it won't change it at the source, and it won't produce anything an auditor will take as evidence. What happens in practice is that each account becomes a playbook one person understands and runs by hand, and the tool needs privileged access of its own on every host, which is a version of the problem you set out to fix.
Scanners and posture tools. They'll tell you the secret is 1,400 days old. They're right, and they'll tell you again next year.
All of them stop in the same place: getting the new value onto machines nobody wants to open a path to.
This is where ManageLM has an unfair advantage, and it's got nothing to do with cryptography.
You've already got an agent on every server. It's installed, it dials out to the portal, it's trusted on the host it lives on, and it's already doing your inventory, your monitoring and your security audits. So the delivery problem, the one that sinks most rotation projects before they start, was solved a while ago for completely unrelated reasons.
Rotation runs from the inside. A domain account is reset by the agent sitting on the domain controller, so there's no bind account to look after, no LDAPS certificate, no route in from a management network. A database password changes from a host that already talks to that database, so nothing on a private VLAN has to become reachable from anywhere else. An LDAP server on your own hardware, the kind a cloud rotation service can't see at all, is simply a machine next door to one of your agents.
Nothing new gets exposed. No inbound port, no VPN for a rotation tool, no domain controller published somewhere it shouldn't be. If you've ever watched a rotation proposal die in a firewall review, that's what killed it, and it doesn't apply here.
The coverage is wide enough to be worth the trouble: Linux accounts, including the LDAP and SSSD ones the host resolves; local Windows accounts; Active Directory accounts through the DC's own agent; LDAP and AD directory entries; PostgreSQL, MySQL, MariaDB and SQL Server logins; Entra application secrets and cloud user passwords; SSH key pairs.
Every credential carries a list of targets, meaning the places the value is genuinely consumed, and a rotation isn't finished until all of them have taken it.
If you've already bought a vault, that third one is rather the point. Nobody is asking you to replace it. Your applications keep reading from it exactly as they do today, and what they find there is current.
Small detail, large consequences. A process that opened its database connection at startup is holding the old password in memory, and asking it to reload its configuration won't change that. It'll run happily on a credential that no longer exists until something forces it to reconnect, and by then nobody is going to link the failure to a password change from three weeks earlier. So a file target can name the services to restart once the value has landed, and they're restarted rather than reloaded, in order, after the write. If a rotation has burned you before, this is usually where it went wrong.
The value is generated, set at the source and delivered to its targets without ever being shown, exported or written down. There's no reveal button because there's nothing behind it. The plaintext exists for the length of one rotation and that's all.
The knock-on effects are worth more than the feature. No shared secret in a password manager that four people can open. Nothing to scramble over when somebody hands in their notice, since they never had the credential to begin with. And \"who has access to production\" stops having a second answer that nobody wrote down.
All of that assumes you know which accounts are service accounts. Most people don't, and that's what really kills rotation programmes. Compiling the list by hand across a few hundred machines is a quarter of somebody's year, it's stale before it's finished, and the entries that matter most are the ones nobody thinks to mention.
Because the agents are LLM-driven, you can just ask. From Claude, or any MCP client connected to your account, questions like these get answered by agents looking at their own hosts:
svc_backup shows up in a cron job, a systemd unit or a connection string.\"The answers come from the machines themselves rather than a CMDB somebody stopped updating in 2022, and they're immediately useful: anything named can be turned into a managed credential with its targets the same afternoon. A competitor could copy the rotation engine in a quarter. Copying this part means first getting an intelligent agent onto every one of your servers.
A rotation that half-finished is worse than one that never ran, so the failure behaviour is deliberate.
It won't start at all if one of the hosts involved is unreachable. Passwords have no overlap window, and changing the source while a consumer can't be updated is the exact outage everybody is afraid of, so the run is postponed instead. Where two values can be valid at the same time, SSH keys and Entra application secrets, the new one is added and delivered first and the old one withdrawn afterwards, so nothing authenticating with it breaks in between. If the account changed but a target refused the value, the rotation is marked failed and tells you which target, because \"done\" and \"done apart from the pooler\" are very different states to wake up to. Retries use a fresh value rather than trying to put the old one back, since the platform never knew the old one anyway, and there's a cap on them so a permanently broken target doesn't burn a new credential every night.
Each credential has its own interval in days. A sweep picks up whatever is due. Every attempt is recorded: when it ran, whether it was scheduled or manual, how many targets took the value, and what failed if anything did. The value itself never appears anywhere. Credential management is a permission of its own, off by default, and changes are attributed to whoever made them.
That changes the shape of the audit conversation. The 90-day requirement turns into a number in a field instead of two weeks of manual work beforehand, and the evidence turns into a page you already have instead of a screenshot hunt.
If what you need is session brokering, keystroke recording and just-in-time elevation for human administrators, buy a PAM product. That's a different job and the established vendors do it properly.
But plenty of the organisations signing six-figure PAM contracts are trying to fix something much narrower: a pile of machine credentials nobody rotates and nobody can fully account for. If that's the actual situation, it doesn't need a programme, an integration partner and three quarters of rollout. It needs the credentials changed on schedule, delivered where they're used, and written down afterwards. Here that comes with the platform you were already going to deploy for inventory, monitoring and security audits, instead of arriving as another silo with its own agent, its own firewall rules and its own renewal date.
Ten servers are free with nothing switched off. Past that, the paid plans add unlimited agents and the external pentests.
Start with something harmless, obviously. But have a think about the account you'd least like to touch, because that's the honest measure of where you are. If rotating it would be a project, that's the finding, and it'll be the finding again next year.
Describe it once: the account, and every place its value is used. After that it rotates on its own interval at 2am, and the first you hear about it is a line in a report.
More detail on Credential Rotation, or take ten free servers at app.managelm.com and point it at the one you've been putting off.
", "fr": "Quelque part sur votre réseau, un compte porte encore le mot de passe qu'on lui a donné en 2019.
Vous voyez lequel. Il fait tourner la sauvegarde de nuit, ou c'est le compte de liaison contre lequel tout l'annuaire s'authentifie, ou encore le rôle de base de données que trois applications se partagent parce que c'était plus rapide sur le moment. La personne qui a choisi le mot de passe est partie. Il est noté quelque part où il ne devrait pas l'être. Tout le monde convient qu'il faut le changer, et personne ne veut s'y coller : le dernier qui a essayé a mis un service à terre pendant quarante minutes, puis a passé le reste de la semaine à traquer les endroits qui gardaient l'ancienne valeur.
La plupart des parcs en comptent une poignée. Plus l'entreprise est ancienne, plus ils sont nombreux, et moins on se souvient de leur origine.
Demandez la politique de gestion des identifiants : elle sera très bien. Rotation tous les 90 jours, un secret par service, rien de partagé, un propriétaire nommé. Elle est approuvée, elle figure dans le SMSI, et elle se présente aux auditeurs sans ciller.
Regardez maintenant ce qui tourne vraiment. Les mots de passe des utilisateurs, parce que le fournisseur d'identité ne leur laisse pas le choix. Les certificats, parce qu'ils expirent à leur propre rythme et emmènent un site web avec eux si on les néglige. Au-delà, c'est de la théorie. Les comptes de service ont des privilèges permanents, pas de MFA, pas d'expiration, et rien dans la pile ne force la décision : ils restent en place.
L'écart ne vient pas de la rigueur, mais du fait que la politique parle de la rotation comme d'un geste unique, alors qu'il s'agit d'une petite transaction distribuée, éclatée sur des machines qui s'ignorent les unes les autres.
Changer le mot de passe à la source prend une seconde. Tout le monde va jusque-là.
L'ennui, ce sont les six autres copies. Un fichier de configuration sur trois serveurs web. Un pooler de connexions monté en 2021 par quelqu'un qui ne l'a noté nulle part. Une entrée de coffre-fort. Une tâche cron. Un fichier d'environnement à côté d'une unité systemd. Une variable de CI. Toutes doivent être exactes dans la minute où la source change, et l'oubli de l'une ne se voit pas tout de suite : le service tient ses connexions ouvertes et continue de fonctionner. Puis le pool se renouvelle à 3 heures du matin et quelque chose casse quatre heures après la cause réelle, soit le pire décalage possible pour la personne d'astreinte.
Produire un mot de passe solide n'a jamais été le plus dur. Le poser partout à la fois, si.
Coffres-forts et PAM. Ils font bien la première moitié : changer le mot de passe du compte, ranger ce qu'ils ont produit. La seconde moitié vous revient. Chaque consommateur doit désormais aller chercher son secret dans le coffre plutôt que le lire là où il l'a toujours lu, ce qui suppose d'entrer dans des applications dont vous n'êtes pas forcément propriétaire, d'ajouter un courtier ou un sidecar, et de dégager un budget. Reste le réseau. Faire tourner un compte de domaine exige une route vers le contrôleur de domaine ; changer un mot de passe de base de données exige une ouverture vers ce VLAN. Ajoutez un compte privilégié capable d'atteindre tout ce qui figure sur la liste, et vous avez fabriqué un deuxième joyau de la couronne pour garder le premier. Beaucoup acceptent ce marché ; encore faut-il le passer en connaissance de cause.
Ansible et consorts. La gestion de configuration pose sans broncher un mot de passe dans un fichier depuis un gabarit et relance le service. Elle ne vous dira pas qu'un identifiant arrive à échéance, ne le changera pas à la source et ne produira rien qu'un auditeur accepte comme preuve. En pratique, chaque compte finit en playbook qu'une seule personne comprend et lance à la main, et l'outil réclame son propre accès privilégié sur chaque hôte, c'est-à-dire une variante du problème que vous vouliez régler.
Scanners et outils de posture. Ils vous diront que le secret a 1 400 jours. Ils ont raison, et ils vous le rediront l'an prochain.
Tous s'arrêtent au même endroit : amener la nouvelle valeur sur des machines vers lesquelles personne ne veut ouvrir de chemin.
C'est ici que ManageLM dispose d'un avantage déloyal, et il ne doit rien à la cryptographie.
Vous avez déjà un agent sur chaque serveur. Il est installé, il appelle le portail vers l'extérieur, il est reconnu sur l'hôte qui l'héberge, et il assure déjà votre inventaire, votre supervision et vos audits de sécurité. Le problème de livraison, celui qui coule la plupart des projets de rotation avant leur démarrage, a donc été réglé il y a longtemps, pour de tout autres raisons.
La rotation s'opère de l'intérieur. Un compte de domaine est réinitialisé par l'agent installé sur le contrôleur de domaine : aucun compte de liaison à entretenir, aucun certificat LDAPS, aucune route entrante depuis un réseau d'administration. Un mot de passe de base de données change depuis un hôte qui dialogue déjà avec cette base : rien sur un VLAN privé n'a besoin de devenir joignable d'ailleurs. Un serveur LDAP sur votre propre matériel, celui qu'un service de rotation en ligne ne voit pas du tout, n'est qu'une machine voisine de l'un de vos agents.
Rien de neuf n'est exposé. Aucun port entrant, aucun VPN pour un outil de rotation, aucun contrôleur de domaine publié là où il n'a rien à faire. Si vous avez déjà vu un projet de rotation mourir en revue de firewall, c'est ce qui l'a tué, et cela ne s'applique pas ici.
La couverture est assez large pour que l'effort en vaille la peine : comptes Linux, y compris ceux que l'hôte résout via LDAP et SSSD ; comptes Windows locaux ; comptes Active Directory via l'agent du contrôleur de domaine ; entrées d'annuaire LDAP et AD ; identifiants PostgreSQL, MySQL, MariaDB et SQL Server ; secrets d'application Entra et mots de passe d'utilisateurs cloud ; paires de clés SSH.
Chaque identifiant porte une liste de cibles, c'est-à-dire les endroits où la valeur est réellement consommée. La rotation n'est finie que lorsque toutes l'ont acceptée.
Si vous avez déjà acheté un coffre-fort, cette troisième cible est tout l'intérêt de l'affaire : personne ne vous demande de le remplacer. Vos applications continuent d'y lire exactement comme aujourd'hui, et ce qu'elles y trouvent est à jour.
Petit détail, grosses conséquences. Un processus qui a ouvert sa connexion à la base au démarrage garde l'ancien mot de passe en mémoire, et lui demander de recharger sa configuration n'y change rien. Il tournera tranquillement avec un identifiant qui n'existe plus, jusqu'à ce que quelque chose l'oblige à se reconnecter, et à ce moment-là personne ne reliera la panne à un changement de mot de passe vieux de trois semaines. Une cible de type fichier peut donc nommer les services à relancer une fois la valeur posée, et ils sont relancés, pas rechargés, dans l'ordre, après l'écriture. Si une rotation vous a déjà brûlé les doigts, c'est en général là que ça s'est joué.
La valeur est produite, posée à la source et livrée à ses cibles sans jamais être affichée, exportée ni notée. Il n'y a pas de bouton « afficher », parce qu'il n'y a rien derrière. Le texte en clair vit le temps d'une rotation, pas davantage.
Les effets de bord valent plus que la fonctionnalité elle-même. Plus de secret partagé dans un gestionnaire de mots de passe que quatre personnes peuvent ouvrir. Rien à récupérer en catastrophe quand quelqu'un démissionne, puisqu'il n'a jamais eu l'identifiant entre les mains. Et « qui a accès à la production » cesse d'avoir une seconde réponse que personne n'avait écrite.
Tout cela suppose de savoir quels comptes sont des comptes de service. La plupart des équipes l'ignorent, et c'est ce qui tue réellement les programmes de rotation. Dresser la liste à la main sur quelques centaines de machines occupe quelqu'un un trimestre entier, elle est périmée avant d'être finie, et les entrées les plus importantes sont celles auxquelles personne ne pense.
Comme les agents s'appuient sur un LLM, il suffit de demander. Depuis Claude, ou n'importe quel client MCP relié à votre compte, ces questions trouvent leur réponse auprès d'agents qui regardent leur propre hôte :
svc_backup apparaît dans une tâche cron, une unité systemd ou une chaîne de connexion. »Les réponses viennent des machines elles-mêmes, pas d'une CMDB abandonnée en 2022, et elles sont exploitables tout de suite : tout compte nommé peut devenir un identifiant géré, avec ses cibles, dans l'après-midi. Un concurrent recopierait le moteur de rotation en un trimestre. Recopier cette partie-là suppose d'abord de poser un agent intelligent sur chacun de vos serveurs.
Une rotation à moitié faite est pire qu'une rotation jamais lancée ; le comportement en cas d'échec est donc délibéré.
Elle ne démarre pas si l'un des hôtes concernés est injoignable. Les mots de passe n'ont pas de fenêtre de recouvrement, et changer la source alors qu'un consommateur ne peut pas suivre, c'est exactement la panne que tout le monde redoute : l'exécution est reportée. Quand deux valeurs peuvent coexister, clés SSH et secrets d'application Entra, la nouvelle est ajoutée et livrée d'abord, l'ancienne retirée ensuite, pour que rien ne casse entre les deux. Si le compte a changé mais qu'une cible a refusé la valeur, la rotation est marquée en échec et vous dit laquelle, car « terminé » et « terminé sauf le pooler » sont deux réveils très différents. Les nouvelles tentatives repartent d'une valeur neuve plutôt que de remettre l'ancienne, que la plateforme n'a de toute façon jamais connue, et leur nombre est plafonné pour qu'une cible définitivement cassée ne consomme pas un identifiant chaque nuit.
Chaque identifiant a son propre intervalle, en jours. Un balayage ramasse ce qui arrive à échéance. Chaque tentative est consignée : quand elle s'est exécutée, si elle était planifiée ou lancée à la main, combien de cibles ont pris la valeur, ce qui a échoué le cas échéant. La valeur, elle, n'apparaît nulle part. La gestion des identifiants est une permission à part, désactivée par défaut, et chaque modification est rattachée à son auteur.
La conversation avec l'auditeur change alors de nature. L'exigence des 90 jours devient un nombre dans un champ au lieu de deux semaines de travail manuel en amont, et la preuve devient une page que vous avez déjà au lieu d'une chasse aux captures d'écran.
S'il vous faut du courtage de sessions, de l'enregistrement de frappe et de l'élévation à la demande pour des administrateurs humains, achetez un produit de PAM : c'est un autre métier, et les acteurs établis le font bien.
Mais beaucoup d'organisations qui signent des contrats PAM à six chiffres cherchent à régler bien plus étroit : un tas d'identifiants machine que personne ne fait tourner et dont personne ne peut rendre compte. Si c'est la situation, elle ne demande ni programme, ni partenaire d'intégration, ni trois trimestres de déploiement. Elle demande des identifiants changés à l'heure dite, livrés là où ils servent, et consignés ensuite. Ici, cela arrive avec la plateforme que vous alliez de toute façon déployer pour l'inventaire, la supervision et les audits de sécurité, au lieu de former un silo de plus avec son agent, ses règles de firewall et sa date de renouvellement.
Dix serveurs sont gratuits, sans rien de désactivé. Au-delà, les formules payantes ajoutent les agents illimités et les pentests externes.
Commencez par quelque chose d'inoffensif, évidemment. Mais pensez au compte que vous aimeriez le moins toucher : c'est la mesure honnête de votre situation. Si le faire tourner tiendrait du projet, voilà le constat, et ce sera encore le constat l'an prochain.
Décrivez-le une fois : le compte, et chaque endroit où sa valeur sert. Ensuite il tourne à son propre rythme, à 2 heures du matin, et la première chose que vous en saurez sera une ligne dans un rapport.
Plus de détails sur la rotation des identifiants, ou prenez dix serveurs gratuits sur app.managelm.com et pointez-la vers celui que vous repoussez depuis des mois.
", "de": "Irgendwo in Ihrem Netz trägt ein Konto noch das Passwort, das es 2019 bekommen hat.
Sie wissen, welches. Es fährt die nächtliche Sicherung, oder es ist das Bind-Konto, gegen das sich das ganze Verzeichnis authentifiziert, oder die Datenbankrolle, die sich drei Anwendungen teilen, weil das damals schneller ging. Wer das Passwort gewählt hat, ist längst weg. Es steht irgendwo, wo es nicht stehen sollte. Alle sind sich einig, dass es sich ändern muss, und niemand will es anfassen: Der Letzte, der es versuchte, legte einen Dienst vierzig Minuten lahm und suchte den Rest der Woche die Stellen, die noch den alten Wert hielten.
In den meisten Landschaften gibt es eine Handvoll davon. Je älter das Unternehmen, desto mehr, und desto weniger weiß noch jemand, wie sie entstanden sind.
Fragen Sie nach der Passwortrichtlinie: Sie wird gut sein. Alle 90 Tage wechseln, ein Geheimnis je Dienst, nichts geteilt, ein benannter Verantwortlicher. Sie ist freigegeben, steht im ISMS und geht ohne Zucken zu den Auditoren.
Sehen Sie nun nach, was sich wirklich ändert. Benutzerpasswörter, weil der Identitätsanbieter keine Wahl lässt. Zertifikate, weil sie nach eigenem Takt ablaufen und eine Website mitnehmen, wenn man sie übersieht. Darüber hinaus ist es Theorie. Dienstkonten haben dauerhafte Rechte, keine MFA, kein Ablaufdatum, und nichts im Aufbau erzwingt eine Entscheidung: Sie bleiben, wo sie sind.
Es fehlt nicht an Disziplin. Die Richtlinie spricht von Rotation wie von einem einzigen Handgriff, dabei ist es eine kleine verteilte Transaktion über Maschinen hinweg, die nichts voneinander wissen.
Das Passwort an der Quelle zu ändern dauert eine Sekunde. So weit kommen alle.
Das Problem sind die sechs weiteren Kopien. Eine Konfigurationsdatei auf drei Webservern. Ein Connection-Pooler, den 2021 jemand aufgesetzt und nirgends notiert hat. Ein Tresoreintrag. Ein Cron-Job. Eine Umgebungsdatei neben einer systemd-Unit. Eine CI-Variable. Alle müssen in derselben Minute stimmen, in der sich die Quelle ändert, und eine vergessene fällt nicht sofort auf: Der Dienst hält seine offenen Verbindungen und arbeitet weiter. Dann erneuert sich der Pool um 3 Uhr nachts, und etwas bricht vier Stunden nach der eigentlichen Ursache, der denkbar schlechteste Abstand für die Person in Rufbereitschaft.
Ein starkes Passwort zu erzeugen war nie das Schwere. Es überall gleichzeitig abzulegen, schon.
Tresore und PAM. Die erste Hälfte können sie gut: das Passwort am Konto ändern, das Erzeugte ablegen. Die zweite Hälfte bleibt bei Ihnen. Jeder Verbraucher muss sein Geheimnis nun aus dem Tresor holen, statt es dort zu lesen, wo er es immer gelesen hat. Das heißt: in Anwendungen eingreifen, die Ihnen vielleicht gar nicht gehören, einen Broker oder ein Sidecar ergänzen und Budget auftreiben. Dazu kommt das Netz. Wer ein Domänenkonto rotiert, braucht eine Route zum Domänencontroller; wer ein Datenbankpasswort ändert, ein Loch in dieses VLAN. Nehmen Sie ein privilegiertes Konto dazu, das alles auf der Liste erreicht, und Sie haben ein zweites Kronjuwel gebaut, um das erste zu hüten. Viele gehen diesen Handel ein; er sollte wenigstens bewusst geschlossen werden.
Ansible und Konsorten. Konfigurationsmanagement schreibt ein Passwort klaglos per Vorlage in eine Datei und startet den Dienst durch. Es sagt Ihnen nicht, dass ein Zugang fällig ist, ändert ihn nicht an der Quelle und erzeugt nichts, was ein Auditor als Nachweis nimmt. In der Praxis wird jedes Konto zu einem Playbook, das eine Person versteht und von Hand ausführt, und das Werkzeug verlangt auf jedem Host eigenen privilegierten Zugriff, also eine Spielart genau des Problems, das Sie lösen wollten.
Scanner und Posture-Werkzeuge. Sie sagen Ihnen, das Geheimnis sei 1.400 Tage alt. Sie haben recht, und nächstes Jahr sagen sie es wieder.
Alle hören an derselben Stelle auf: den neuen Wert auf Maschinen zu bringen, zu denen niemand einen Weg öffnen möchte.
Hier hat ManageLM einen unfairen Vorteil, und er hat nichts mit Kryptografie zu tun.
Auf jedem Server läuft bereits ein Agent. Er ist installiert, wählt ausgehend zum Portal, genießt auf seinem Host Vertrauen und erledigt schon Inventar, Monitoring und Sicherheitsaudits. Das Zustellproblem, an dem die meisten Rotationsvorhaben scheitern, bevor sie beginnen, war also längst gelöst, aus ganz anderen Gründen.
Die Rotation läuft von innen. Ein Domänenkonto setzt der Agent auf dem Domänencontroller zurück: kein Bind-Konto zu pflegen, kein LDAPS-Zertifikat, keine eingehende Route aus einem Managementnetz. Ein Datenbankpasswort ändert sich von einem Host aus, der ohnehin mit dieser Datenbank spricht: Nichts in einem privaten VLAN muss von außen erreichbar werden. Ein LDAP-Server auf eigener Hardware, die Sorte, die ein Cloud-Rotationsdienst überhaupt nicht sieht, ist schlicht eine Maschine neben einem Ihrer Agenten.
Nichts Neues wird geöffnet. Kein eingehender Port, kein VPN für ein Rotationswerkzeug, kein Domänencontroller an einer Stelle, an die er nicht gehört. Wenn Sie je erlebt haben, wie ein Rotationsvorhaben in einer Firewall-Prüfung starb, war das der Grund, und hier trifft er nicht zu.
Die Abdeckung ist breit genug, dass sich der Aufwand lohnt: Linux-Konten, auch die über LDAP und SSSD aufgelösten; lokale Windows-Konten; Active-Directory-Konten über den Agenten des Domänencontrollers; LDAP- und AD-Verzeichniseinträge; Anmeldungen für PostgreSQL, MySQL, MariaDB und SQL Server; Entra-Anwendungsgeheimnisse und Cloud-Benutzerpasswörter; SSH-Schlüsselpaare.
Jeder Zugang führt eine Liste von Zielen, also der Stellen, an denen der Wert wirklich gebraucht wird. Fertig ist die Rotation erst, wenn alle ihn übernommen haben.
Wenn Sie bereits einen Tresor gekauft haben, ist dieses dritte Ziel der eigentliche Punkt: Niemand verlangt, ihn zu ersetzen. Ihre Anwendungen lesen weiter genau wie heute daraus, und was sie finden, ist aktuell.
Kleines Detail, große Folgen. Ein Prozess, der seine Datenbankverbindung beim Start geöffnet hat, hält das alte Passwort im Speicher, und ihn zum Neuladen der Konfiguration zu bewegen ändert daran nichts. Er läuft zufrieden mit einem Zugang weiter, den es nicht mehr gibt, bis ihn etwas zum Neuverbinden zwingt, und dann verbindet niemand mehr den Ausfall mit einer Passwortänderung von vor drei Wochen. Ein Dateiziel darf deshalb die Dienste benennen, die nach dem Ablegen des Werts neu zu starten sind, und sie werden neu gestartet statt neu geladen, der Reihe nach, nach dem Schreiben. Wenn Sie sich an einer Rotation schon die Finger verbrannt haben, lag es meist hier.
Der Wert wird erzeugt, an der Quelle gesetzt und an seine Ziele geliefert, ohne je angezeigt, exportiert oder notiert zu werden. Es gibt keinen Knopf zum Anzeigen, weil dahinter nichts ist. Der Klartext lebt genau eine Rotation lang, nicht länger.
Die Nebenwirkungen sind mehr wert als die Funktion selbst. Kein geteiltes Geheimnis in einem Passwortmanager, den vier Leute öffnen können. Nichts, was hektisch eingesammelt werden muss, wenn jemand kündigt, denn der Zugang war nie in seinen Händen. Und „wer hat Zugriff auf die Produktion“ hat keine zweite Antwort mehr, die niemand aufgeschrieben hat.
All das setzt voraus, dass Sie wissen, welche Konten Dienstkonten sind. Die meisten wissen es nicht, und daran scheitern Rotationsprogramme wirklich. Die Liste über ein paar hundert Maschinen von Hand zu erstellen kostet jemanden ein Vierteljahr, sie ist veraltet, bevor sie fertig ist, und die wichtigsten Einträge sind die, an die niemand denkt.
Weil die Agenten auf einem LLM aufsetzen, können Sie einfach fragen. Aus Claude oder jedem MCP-Client, der mit Ihrem Konto verbunden ist, beantworten Agenten solche Fragen, indem sie ihren eigenen Host ansehen:
svc_backup in einem Cron-Job, einer systemd-Unit oder einer Verbindungszeichenfolge vorkommt.“Die Antworten kommen von den Maschinen selbst, nicht aus einer CMDB, die 2022 verwaist ist, und sie sind sofort brauchbar: Jedes genannte Konto kann noch am selben Nachmittag zu einem verwalteten Zugang mit seinen Zielen werden. Ein Wettbewerber baut die Rotationsmaschinerie in einem Quartal nach. Diesen Teil nachzubauen setzt voraus, zuerst einen intelligenten Agenten auf jeden Ihrer Server zu bekommen.
Eine halb fertige Rotation ist schlimmer als eine, die nie lief; das Verhalten im Fehlerfall ist deshalb bewusst gewählt.
Sie startet nicht, wenn einer der beteiligten Hosts nicht erreichbar ist. Passwörter haben kein Überlappungsfenster, und die Quelle zu ändern, während ein Verbraucher nicht nachziehen kann, ist genau der Ausfall, vor dem alle Angst haben: Der Lauf wird verschoben. Wo zwei Werte nebeneinander gelten können, bei SSH-Schlüsseln und Entra-Anwendungsgeheimnissen, wird der neue zuerst hinzugefügt und ausgeliefert und der alte danach zurückgezogen, damit dazwischen nichts bricht. Hat sich das Konto geändert, ein Ziel den Wert aber abgelehnt, gilt die Rotation als fehlgeschlagen und nennt das Ziel, denn „fertig“ und „fertig bis auf den Pooler“ sind sehr verschiedene Zustände zum Aufwachen. Wiederholungen beginnen mit einem frischen Wert, statt den alten zurückzuschreiben, den die Plattform ohnehin nie kannte, und ihre Zahl ist begrenzt, damit ein dauerhaft defektes Ziel nicht jede Nacht einen Zugang verbrennt.
Jeder Zugang hat sein eigenes Intervall in Tagen. Ein Durchlauf greift auf, was fällig ist. Jeder Versuch wird festgehalten: wann er lief, ob geplant oder von Hand, wie viele Ziele den Wert übernommen haben, was gegebenenfalls fehlschlug. Der Wert selbst taucht nirgends auf. Die Verwaltung von Zugangsdaten ist eine eigene Berechtigung, standardmäßig aus, und jede Änderung ist ihrem Urheber zugeordnet.
Damit ändert das Prüfgespräch seinen Charakter. Aus der 90-Tage-Anforderung wird eine Zahl in einem Feld statt zwei Wochen Handarbeit vorher, und aus dem Nachweis wird eine Seite, die Sie schon haben, statt einer Jagd nach Screenshots.
Wenn Sie Sitzungsvermittlung, Tastaturaufzeichnung und Rechteerhöhung auf Zuruf für menschliche Administratoren brauchen, kaufen Sie ein PAM-Produkt: Das ist eine andere Aufgabe, und die etablierten Anbieter erledigen sie gut.
Doch viele Organisationen, die sechsstellige PAM-Verträge unterschreiben, wollen etwas viel Engeres reparieren: einen Haufen Maschinenzugänge, die niemand rotiert und über die niemand Auskunft geben kann. Trifft das zu, braucht es kein Programm, keinen Integrationspartner und keine drei Quartale Einführung. Es braucht Zugänge, die planmäßig wechseln, dort ankommen, wo sie gebraucht werden, und danach festgehalten sind. Hier kommt das mit der Plattform, die Sie ohnehin für Inventar, Monitoring und Sicherheitsaudits ausrollen wollten, statt als weiteres Silo mit eigenem Agenten, eigenen Firewall-Regeln und eigenem Verlängerungsdatum.
Zehn Server sind kostenlos, ohne abgeschaltete Funktionen. Darüber hinaus bringen die bezahlten Tarife unbegrenzte Agenten und die externen Pentests.
Fangen Sie natürlich mit etwas Harmlosem an. Denken Sie aber an das Konto, das Sie am wenigsten anfassen möchten: Das ist der ehrliche Maßstab Ihrer Lage. Wäre dessen Rotation ein Projekt, ist genau das der Befund, und nächstes Jahr ist es derselbe.
Beschreiben Sie es einmal: das Konto und jede Stelle, an der sein Wert gebraucht wird. Danach rotiert es in seinem eigenen Takt, um 2 Uhr nachts, und das Erste, was Sie davon hören, ist eine Zeile in einem Bericht.
Mehr zur Rotation von Zugangsdaten, oder nehmen Sie zehn kostenlose Server auf app.managelm.com und richten Sie sie auf den Zugang, den Sie vor sich herschieben.
" } }