Blog ·
Wohin die Zugangsdaten Ihrer Panels gehören
Eine Steuerungsebene, die Ihre Hypervisor- und Panel-Zugänge speichert, ist das wertvollste Ziel im Stack. Hier ist die Alternative, und was sie nicht löst.
Von Provibr
Jedes gehostete Panel für Serverautomatisierung fragt Sie im Einrichtungsassistenten dasselbe: die Adresse Ihres Hypervisors, einen API-Token, die Root-Zugangsdaten Ihres Webhosting-Panels. Dann speichert es sie, denn es braucht sie bei jeder Anfrage.
Das ist ein vernünftiger Wunsch der Software und etwas ausgesprochen Unbehagliches, dem Sie zugestimmt haben. Sie haben gerade der Datenbank eines Dritten die Fähigkeit übergeben, jede Maschine zu löschen, die Ihnen gehört. Nicht über einen Fehler und nicht über Böswilligkeit: Das ist das normale, dokumentierte, funktionierende Verhalten des Produkts.
Es lohnt sich, genau zu benennen, was die Alternativen tatsächlich einbringen, denn „wir verschlüsseln sie im Ruhezustand“ ist die Antwort, die alle geben, und für sich allein ist sie fast bedeutungslos.
Im Ruhezustand verschlüsselt, entschlüsselt von wem
Speichert ein SaaS Ihren Hypervisor-Token verschlüsselt, muss der Schlüssel irgendwo liegen, wo derselbe SaaS ihn erreicht, denn er muss den Token in Ihrem Namen benutzen, während Sie schlafen. Verschlüsselung im Ruhezustand schützt gegen eine gestohlene Platte und ein abgeflossenes Backup. Sie schützt nicht gegen das, worüber Sie sich eigentlich Sorgen machen, nämlich dass die Plattform selbst übernommen wird.
Das ist kein Argument gegen Verschlüsselung im Ruhezustand. Es ist ein Argument dafür, dass die Frage „wo ist der Schlüssel“ die einzige Frage ist, und dass eine Steuerungsebene, die entschlüsseln kann, eine Steuerungsebene ist, die man zum Entschlüsseln bringen kann.
| Wo das Geheimnis liegt | Wer es entschlüsseln kann | Was ein Einbruch bei der Plattform einbringt |
|---|---|---|
| Im Klartext in der Datenbank der Plattform | Die Plattform | Der Hypervisor jedes Kunden |
| Dort verschlüsselt, Schlüssel ebenfalls dort | Die Plattform | Dasselbe, einen Schritt später |
| Verschlüsselt auf dem eigenen Host des Kunden | Dieser Host, und nur dieser Host | Befehlszugriff, und keine Zugangsdaten |
Die strukturelle Alternative ist die dritte Zeile: das Geheimnis überhaupt nicht zu haben. Das klingt zu leicht gesagt, bis man sich ansieht, was es kostet, das einzurichten.
Das Geheimnis dort lassen, wo die Maschine steht
Die Form, die funktioniert: Ein kleiner Agent läuft im eigenen Netz des Kunden, hält die Zugangsdaten lokal und verbindet sich nach außen zur Plattform. Die Plattform schickt Anweisungen. Der Agent hält die Schlüssel.
Das dreht den Schadensradius um. Eine Übernahme der Steuerungsebene kann jetzt Befehle absetzen, was schlimm ist und worauf wir zurückkommen, aber sie kann nicht mit einer Datei voller Hypervisor-Token für jeden Kunden davonlaufen, denn eine solche Datei gibt es nicht.
Die Teile, die das echt machen, sind unglamourös.
Der Tresor, und wogegen er ehrlicherweise schützt
Unser Agent speichert Zugangsdaten in einer lokalen Datei, verschlüsselt mit XChaCha20-Poly1305. Der Schlüssel ist nicht die Datei auf der Platte: Er wird über HKDF aus einer Schlüsseldatei abgeleitet, vermischt mit der Identität der Maschine selbst, und die zusätzlichen authentifizierten Daten binden den Geheimtext an die Formatversion und an die Agenten-ID.
Die praktische Folge ist die, für die es sich zu entwerfen lohnt. Kopieren Sie Schlüsseldatei und Tresor auf eine andere Maschine, und er öffnet sich nicht. Stellen Sie das Backup des Datenverzeichnisses vom letzten Monat auf einem anderen Host wieder her, und er öffnet sich nicht. Jeder Fehlerfall, falscher Schlüssel, anderer Agent, veränderte Bytes, erzeugt denselben ununterscheidbaren Fehler, und genau das ist der Sinn.
Hier ist der Teil, der in die Dokumentation jedes Produkts gehört, das so etwas macht, und der dort meist nicht steht. Das schützt nicht gegen root auf dem Host. Es kann es nicht, und es muss es nicht: Dem Kunden gehört der Host, und ihm gehören die Zugangsdaten. Der Tresor schützt gegen eine abgeflossene Datei, nicht gegen den Eigentümer der Maschine. Ein Anbieter, der etwas anderes andeutet, verkauft Ihnen ein Gefühl.
Die Zugangsdaten berühren die Datenbank der Plattform nie
Das ist der Teil, den man leicht falsch macht, während man glaubt, ihn richtig gemacht zu haben, denn der Code sieht so oder so in Ordnung aus.
Wenn jemand einen Hypervisor-Token in unser Panel tippt, enthält die Zeile, die in die Befehlstabelle geht, nur Feldnamen. Die Werte reisen in einer getrennten, flüchtigen Nachricht, die nicht gespeichert wird, und gehen direkt in die Zustellung an den Agenten. Der Verteiler protokolliert sie nie und speichert sie nie dauerhaft.
Wenn Sie ein Produkt daraufhin bewerten, lautet die Frage nicht „speichern Sie Zugangsdaten“. Sie lautet „was steht in Ihrem Prüfprotokoll, und was steht in Ihrer Warteschlange“. Eine Warteschlange, die das Geheimnis trägt, ist eine Datenbank, die das Geheimnis trägt, mit zusätzlichen Schritten.
Ein Geheimnis zu löschen ist ein anderes Problem als es zu speichern
Eine Integration im Panel zu entfernen muss dazu führen, dass die Zugangsdaten von einer Maschine verschwinden, die Sie nicht kontrollieren, und das ist schwerer, als es aussieht.
Die naheliegende Umsetzung ist ein Abgleich: den Agenten fragen, was er hat, mit dem vergleichen, was die Datenbank sagt, und die Differenz löschen. Das ist kürzer und es ist gefährlich, denn die Subtraktion fällt in Richtung alles ist weg aus. Ein fehlgeschlagener Lesevorgang, eine abgeschnittene Liste, und Sie haben eine Anweisung erzeugt, jede funktionierende Integration auf diesem Host zu löschen, und diese Zugangsdaten sind nicht wiederherstellbar, ohne dass der Kunde sie erneut tippt.
Die Anweisung kommt deshalb ausschließlich aus positivem Wissen: Eine Zeile existiert, weil jemand wirklich eine Integration gelöscht hat. Ein fehlgeschlagener Lesevorgang erzeugt null Zeilen und damit null Anweisungen, und das Geheimnis bleibt, wo es war, also genau in dem Zustand, in dem Sie vorher waren.
Zugestellt wird sie zweimal: sofort über den Ereignisbus und noch einmal bei jedem Sitzungs-Handshake, für den Agenten, der offline war, die Nachricht, die verloren ging, das Gateway, das neu gestartet ist. Beide Wege lesen dieselbe Tabelle, es gibt also keine zweite Wahrheit und keine zweite Reihenfolge.
Was ein gestohlenes Agentenzertifikat kann und was nicht
Wenn der Agent sich mit einem Client-Zertifikat ausweist, ist die ehrliche Frage, was passiert, wenn jemand es nimmt. Dazu konkret zu werden ist nützlicher als eine Sicherheitsseite.
Es kann genau diesen einen Agenten vortäuschen. Der Sitzungsport verlangt beidseitiges TLS, und über die TLS-Prüfung hinaus wird der Fingerabdruck des vorgelegten Zertifikats in der Agententabelle nachgeschlagen, die einen eindeutigen Index hat. Ein Fingerabdruck zeigt daher auf genau einen Agenten, und die im Handshake behauptete Identität wird damit verglichen. Ein Angreifer mit dem Zertifikat wird zu diesem Agenten und kann senden, was ein Agent senden darf: Zustandsereignisse, Ergebnisse, Telemetrie.
Es kann die Daten anderer Kunden nicht lesen. Alles ist auf die Organisation begrenzt, zu der der Agent gehört, aufgelöst aus dem Zertifikat und nicht aus irgendetwas, was der Client über sich selbst behauptet.
Es liefert die Zugangsdaten nicht von sich aus. Das Zertifikat ist die Identität, mit der man mit der Plattform spricht. Der Tresorschlüssel ist getrennt, liegt auf dem Host und ist an dessen Maschinenidentität gebunden. Wer beides hat, hat root auf der Maschine, und dann ist das Zertifikat die kleinste Sorge.
Es hört auf zu funktionieren, wenn Sie es sagen, in etwa einer Minute. Widerruf ist ein Datenbankzustand, keine CRL und kein OCSP. Eine neue Verbindung wird sofort abgewiesen. Eine bestehende Verbindung wird im Minutentakt erneut geprüft, ein bereits verbundener Angreifer hat also höchstens so lange. Schlägt die Statusprüfung selbst immer wieder fehl, wird die Sitzung nach drei aufeinanderfolgenden Fehlversuchen geschlossen, statt unbegrenzt offen zu bleiben, was den schlimmsten Fall auf ungefähr drei Minuten begrenzt.
Und der Agent räumt hinter sich auf. Beim Widerruf löscht er den Tresor, den Tresorschlüssel, seine Identität, seinen Sitzungszustand und seine Warteschlangen, in dieser Reihenfolge, die Zugangsdaten zuerst. Jeder Schritt ist ein Versuch nach bestem Bemühen und wird einzeln protokolliert, denn eine halbe Löschung ist besser als keine.
Zertifikate sind außerdem kurzlebig, neunzig Tage, automatisch auf halbem Weg erneuert mit einer stündlichen Prüfung. Das ist weniger eine Abwehr gegen Diebstahl als eine Schranke dafür, wie lange ein unbemerkter Diebstahl nützlich bleibt.
Was das nicht behebt
Drei Dinge, klar gesagt, denn ein Bedrohungsmodell ohne Restrisiko ist eine Werbeseite.
Eine übernommene Steuerungsebene kann weiterhin Befehle absetzen. Sie kann Ihre Token nicht stehlen, aber sie kann Ihrem Agenten sagen, er solle eine Maschine löschen, und der Agent tut es. Die Geheimnisse zu verschieben verschiebt den Schadensradius; es entfernt ihn nicht. Was Sie zurückbekommen: Der Schaden ist durch das begrenzt, was die API ausdrücken kann, und in einer Prüfspur sichtbar, statt dass ein Angreifer mit Ihren Zugangsdaten um drei Uhr nachts direkt gegen Ihren Hypervisor tut, was er will.
Root auf dem Agentenhost liest alles. So ist es entworfen. Ist dieser Host übernommen, haben Sie eine übernommene Maschine im eigenen Netz, und sie hat Ihre Hypervisor-Zugangsdaten, weil sie dort hingehören.
Das Löschen hängt daran, dass der Agent zurückkommt. Verbindet sich ein Host nie wieder, bleibt die Anweisung, seine Zugangsdaten zu vergessen, offen. Das ist im Panel sichtbar, statt still als erledigt markiert zu werden, was der richtige Tausch ist, aber es ist eine echte Einschränkung, die Sie kennen sollten, bevor Sie sich darauf verlassen.
Fragen, die man einem Anbieter stellen sollte
Was Sie am Ende auch kaufen, diese fünf trennen die Produkte, die darüber nachgedacht haben, von denen, die einen Absatz geschrieben haben:
- Wo liegt der Entschlüsselungsschlüssel, physisch? Lautet die Antwort „in unserer Plattform“, schützt Verschlüsselung im Ruhezustand gegen Plattendiebstahl und sonst nichts.
- Was steht im Prüfprotokoll und in der Auftragswarteschlange? Geheimnisse sickern weit häufiger dorthin als in die Tabelle, um die sich jemand gekümmert hat.
- Was passiert mit den Zugangsdaten, wenn ich eine Integration lösche, und kann ich sehen, ob es tatsächlich passiert ist?
- Wie lange dauert ein Zugriffsentzug, und gilt er auch für bereits offene Sitzungen?
- Braucht irgendetwas einen eingehenden Port? Eine Firewallregel, die den IP-Bereich eines Anbieters an die Verwaltungsschnittstelle Ihres Hypervisors lässt, ist eine zweite, leisere Fassung desselben Problems.
So haben wir es bei Provibr gebaut: Der Agent läuft auf der eigenen Hardware des Kunden, hält die Zugangsdaten lokal und verbindet sich ausschließlich nach außen.
