Das Problem mit Servern

Bisher hatte der Zugang zu einem Rechner mit Golem eine Voraussetzung: Jemand auf der anderen Seite musste den Agenten starten und mir die Verbindungszeile schicken. Am Rechner eines Anwenders funktioniert das gut, denn die Person sitzt davor und möchte, dass ich ihr helfe.

Bei Servern ist das anders. Vor einem Server sitzt niemand. Als ein Softwareunternehmen anfing, Golem mit seinen Technikern zu nutzen, erzählten sie mir als Erstes, dass sie für den Zugang zum Server eines Kunden zuerst eine Sitzung mit AnyDesk, Splashtop oder RustDesk öffneten, nur um Golem zu starten und die Zeile zu kopieren. Zwei Fernzugriffswerkzeuge für eine einzige Aufgabe, und das zweite hing vom ersten ab.

Sie baten mich um etwas wie den unbeaufsichtigten Zugriff dieser Werkzeuge, und das bringt Golem 1.4.

Warum ein Token in einer Datei nicht reichte

Die schnelle Lösung wäre gewesen, den Agenten als Dienst laufen zu lassen, mit einem festen Token auf der Festplatte, damit sich der Techniker verbinden kann, wann er will. Das habe ich sofort verworfen. Ein festes Token in einer Datei ist ein Passwort, das nie abläuft, das jedem nützt, der es kopiert, und das niemand ändert, wenn ein Techniker das Unternehmen verlässt. Auf dem Server eines Kunden, mit seinen Geschäftsdaten darauf, wollte ich so etwas nicht hinterlassen.

Deshalb geht der Entwurf von drei Ideen aus:

  • Der Server bleibt nicht offen. Er wartet und öffnet nur, wenn jemand aus dem richtigen Unternehmen anklopft.
  • Jeder Techniker meldet sich mit seiner eigenen Berechtigung an, die seinen Namen trägt und nach 30 Tagen abläuft.
  • Jede Sitzung beginnt mit einem neuen Token und schließt sich bei Untätigkeit von selbst.

So funktioniert es

Auf jedem Server wird er einmal installiert, mit jemandem vom Kunden vor Ort oder über die übliche Fernsitzung:

golem guardian install --credential C:\Golem\techniker.cred

Das hinterlässt einen Windows-Dienst, Golem Guardian, der mit dem Rechner startet, und ein Schloss neben der ausführbaren Datei. Das Schloss legt fest, von welchem Unternehmen die Berechtigungen sein müssen, die diesen Server öffnen dürfen. Die Installation gibt zwei Werte aus, die ins Inventar gehören: einen achtstelligen Platz und die Identität des Guardian, einen Fingerabdruck, der diesen Server kennzeichnet.

Sobald der Dienst registriert ist, wird die Datei .cred vom Server gelöscht. Sie wird nur für die Installation des Guardian gebraucht: Danach wird sie nicht mehr verwendet, und das Schloss behält keine Kopie. Sie dort liegen zu lassen hieße, die Berechtigung eines Technikers auf einem Rechner zu lassen, der nicht seiner ist, auch wenn sie ohne seinen Schlüssel, der nur auf seinem eigenen Rechner liegt, nichts öffnet.

Von da an meldet sich ein Techniker aus seinem Claude mit den acht Ziffern an:

golem_connect 3050 7712

Sein Client hinterlegt in meinem Portal ein Anklopfen, signiert mit dem Schlüssel seines Rechners. Der Guardian fragt das Portal jede Minute, ob jemand angeklopft hat. Findet er ein Anklopfen, prüft er die Berechtigung, ob sie zum Unternehmen im Schloss gehört, ob der Schlüssel der des Technikers ist, die Uhrzeit, ob es sich um eine Wiederholung handelt, und die Signatur. Passt alles, öffnet er eine Sitzung mit einem neuen Token und gibt sie dem Techniker verschlüsselt zurück, sodass nur dessen Rechner sie lesen kann. Auf einem Server hinter einem Router öffnet er zusätzlich einen Cloudflare-Tunnel, nur solange diese Sitzung dauert. Der Server lauscht nach außen auf nichts.

Das Portal dient als Briefkasten und kann nicht lesen, was hindurchgeht. Es speichert den Platz, einen Prüfwert für das Geheimnis dieses Platzes sowie die verschlüsselten Anklopfvorgänge und Antworten. Den Namen des Servers und seine IP kennt es nicht. Was der Guardian veröffentlicht, ist mit seiner Identität signiert, und der Client des Technikers merkt sich diese Identität beim ersten Zugang, so wie SSH es mit bekannten Servern macht: Antwortet eines Tages jemand mit einer anderen, verbindet er sich nicht.

Was der Besitzer des Servers sieht

Auch der Kunde des Softwareunternehmens muss wissen können, was auf seinem Rechner passiert. Der Guardian hält es an zwei Stellen fest:

  • In der Windows-Ereignisanzeige: die Installation, jede Sitzung, die geöffnet und geschlossen wird, mit dem Namen des Technikers, und jedes abgelehnte Anklopfen.
  • In golem-audit.log neben der ausführbaren Datei: jede Aktion jeder Sitzung, ohne Tokens und ohne Berechtigungen.

Außerdem kann er die Tür jederzeit schließen. golem guardian remove in einer Administratorkonsole entfernt den Dienst, das Schloss und das Zertifikat, und der Server ist wieder einer ohne Guardian.

Was das Unternehmen tut

Die Techniker werden im Portal unter Techniker (/portal/team) verwaltet, mit dem Konto, das die Lizenz besitzt. Jeder Techniker erzeugt auf seinem Rechner einen Schlüssel, der den Rechner nie verlässt, und das Unternehmen legt ihn mit Namen, E-Mail und dem öffentlichen Teil dieses Schlüssels an. Das Portal liefert die Berechtigung, die der Techniker auf seinem Rechner installiert. Sie erneuert sich von selbst, wenn sie weniger als sieben Tage gültig ist.

Beim Entfernen eines Technikers ist zu beachten, dass der Server die Berechtigung selbst prüft, ohne das Portal zu fragen. Das Entfernen verhindert die Erneuerung, macht die Berechtigung aber nicht sofort ungültig: Die vorhandene öffnet weiter, bis sie abläuft, höchstens 30 Tage später. Um den Zugang sofort zu sperren, führt man auf jedem Server golem guardian remove aus und installiert neu, was einen neuen Platz und eine neue Identität ergibt.

Auf echten Servern getestet

Vor der Veröffentlichung habe ich ihn auf einem echten Server getestet, gegen mein Produktivportal und mit den signierten Programmdateien. Am wichtigsten war mir der Neustart des Servers, ohne dass sich danach jemand anmeldet. Der Guardian lief und wartete zwölf Sekunden nach dem Start von Windows, und der Zugang mit den acht Ziffern gelang mit demselben Platz und derselben Identität wie vorher.

Aus diesen Tests sind Korrekturen hervorgegangen, die in 1.4.2 enthalten sind. Unter dem Guardian gibt es keinen Desktop, daher melden die Bildschirmfoto-Werkzeuge, dass kein Bildschirm vorhanden ist, und keines schlägt etwas vor, das jemanden hinauswerfen könnte, der über AnyDesk, Splashtop, RustDesk oder RDP verbunden ist. install warnt, wenn ein Fenster mit golem serve seinen Port belegt, und wenn der Dienst nicht startet, versucht Windows es von selbst erneut, und status sagt, warum.

Für wen er gedacht ist

Der Guardian ist für Unternehmen gedacht, die die Server ihrer Kunden betreuen, und er ist in der Lizenz Golem Unternehmen enthalten: unbegrenzt viele Techniker im Unternehmen, an keinen Rechner gebunden und ohne Kosten pro Server. Mit den Lizenzen für einen Techniker oder für ein Team funktioniert Golem wie bisher, mit der Verbindungszeile oder mit den zwölf Ziffern der Assistenz.

Die vollständige Dokumentation mit der Installation, den beiden Modi (hinter einem Router oder mit erreichbarer IP) und was bei jeder Meldung zu tun ist, steht im Leitfaden zum Guardian. Die Preise stehen auf der Preisseite.