Gestern ging das VPN noch

Der Anruf kam an einem Nachmittag.

„Heute haben wir ein kontrolliertes Wartungsfenster. Kannst du bitte jetzt das fällige Firewall-Update machen?“

Klar. Genau dafür ist ein Wartungsfenster schließlich da.

Das Update war ohnehin fällig und der Zeitpunkt passte. Während ich mich um die Firewall kümmerte, aktualisierte der Kunde selbst seinen Domaincontroller.

Also eigentlich eine ziemlich normale Wartungsaktion: Backup, System aktualisieren, anschließend die wichtigsten Funktionen prüfen. Da sah alles gut aus.

Am nächsten Tag klingelte wieder das Telefon.

„Bei uns kommt keiner mehr ins VPN. Kannst du mal schauen, was da los ist?“

Na prima.

Was wurde gestern geändert?

Bei solchen Fehlern ist eine der ersten Fragen fast immer:

Was wurde zuletzt geändert?

Normalerweise ist das ein ziemlich guter Ausgangspunkt für die Fehlersuche.

Diesmal gab es allerdings gleich zwei Antworten.

Die Firewall hatte ein Update bekommen. Und der Domaincontroller ebenfalls.

Da das VPN über die Firewall lief, lag der erste Verdacht natürlich nahe: Gestern Firewall aktualisiert, heute VPN kaputt - also wird das Update wohl etwas damit zu tun haben.

Ganz falsch war dieser Gedanke nicht.

Aber anders, als zunächst vermutet.

Denn das Update hatte das VPN nicht kaputtgemacht.

Es hatte dafür gesorgt, dass etwas auffiel, das schon vorher nicht in Ordnung war.

Die Anmeldung funktionierte plötzlich genauer

Die Benutzer des Unternehmens authentisierten sich beim Aufbau ihrer VPN-Verbindung gegen einen internen Server. Vereinfacht gesagt: Wer sich von außen mit dem Firmennetz verbinden wollte, musste dort nachweisen, dass er tatsächlich ein berechtigter Benutzer ist.

Mit dem Update war für diesen Vorgang eine zusätzliche Sicherheitsprüfung hinzugekommen.

Nun wurde nicht mehr nur geprüft, ob Benutzername und Kennwort stimmen. Es wurde auch genauer hingesehen, ob der Server, der diese Authentisierung übernimmt, tatsächlich der Server ist, für den er sich ausgibt.

Und dafür gibt es Zertifikate.

Bei der Fehlersuche landeten wir deshalb irgendwann beim Zertifikat des Authentisierungsservers.

Und siehe da:

Das Zertifikat war abgelaufen.

Nicht gestern.

Nicht durch das Update.

Es war schon länger ungültig.

Es war vorher nur nie aufgefallen.

Das Update hatte nichts kaputtgemacht

Das war der interessante Moment an dieser Geschichte.

Natürlich hätte man sagen können: Vor dem Update funktionierte das VPN, danach nicht mehr. Also ist das Update schuld.

Technisch bestand da sogar ein Zusammenhang.

Nur war die Schlussfolgerung falsch.

Die neue Version prüfte etwas, das vorher nicht in dieser Form geprüft worden war - und stellte dabei fest, dass ein längst abgelaufenes Zertifikat verwendet wurde.

Das Update hatte also nichts kaputtgemacht.

Es hatte entdeckt, dass vorher schon etwas nicht in Ordnung war.

Das ist ein kleiner, aber wichtiger Unterschied.

Denn „gestern hat es noch funktioniert“ ist in der IT kein Beweis dafür, dass gestern alles richtig konfiguriert war.

Manchmal bedeutet es nur, dass ein vorhandenes Problem bislang keine sichtbaren Auswirkungen hatte.

Zertifikate? Haben wir davon noch mehr?

Das VPN-Problem ließ sich lösen.

Damit hätte die Geschichte eigentlich zu Ende sein können.

Aber genau an solchen Stellen lohnt es sich manchmal, noch eine Frage weiterzugehen.

Wenn ein wichtiges Zertifikat unbemerkt ablaufen konnte:

Wo werden bei diesem Kunden eigentlich sonst noch Zertifikate eingesetzt?

Die spontane Antwort darauf ist bei vielen IT-Umgebungen wahrscheinlich:

Mehr Stellen, als man zunächst denkt.

Zertifikate begegnen einem nicht nur beim Aufruf einer verschlüsselten Webseite im Browser. Sie werden auch intern eingesetzt, um Server und Dienste eindeutig zu identifizieren, Verbindungen abzusichern oder Systeme gegeneinander zu authentisieren.

Und vieles davon läuft jahrelang völlig unauffällig.

Bis ein Zertifikat abläuft.

Also haben wir uns die Zertifikatslandschaft des Kunden genauer angesehen.

Erst erfassen, dann aufräumen

Dabei ging es nicht darum, gleich die komplette Zertifikatsinfrastruktur neu zu bauen.

Eine interne Zertifizierungsstelle war vorhanden und funktionierte. Es gab keinen vernünftigen Grund, sie nur deshalb anzufassen, weil wir gerade über Zertifikate sprachen.

Stattdessen haben wir zunächst erfasst:

• Wo werden Zertifikate eingesetzt?

• Wofür werden sie gebraucht?

• Welche davon sind noch gültig?

• Passen die vorhandenen Zertifikate überhaupt zu ihrem jeweiligen Einsatzzweck?

Anschließend wurde aufgeräumt.

Zertifikate wurden dort, wo es erforderlich war, erneuert oder passend zu ihrem tatsächlichen Einsatzzweck eingerichtet.

Keine große PKI-Revolution.

Einfach erst einmal Ordnung schaffen und wissen, was vorhanden ist.

„Und woher weiß ich das beim nächsten Mal?“

Im Gespräch stellte der Kunde dann eine ausgesprochen sinnvolle Frage:

„Woher weiß ich denn in Zukunft, wann ein Zertifikat ausläuft?“

Darauf gibt es tatsächlich mindestens zwei Antworten.

Man kann Zertifikate automatisiert überwachen. Man kann ein Monitoring einrichten, Warnmeldungen erzeugen und das gesamte Zertifikatsmanagement mit entsprechenden Systemen und Prozessen versehen.

Das kann absolut sinnvoll sein.

Bei einer überschaubaren IT-Infrastruktur darf die Antwort aber auch etwas kürzer ausfallen.

Kalender.

Die relevanten Zertifikate sind jetzt bekannt. Ihre Ablaufdaten ebenfalls.

Also werden rechtzeitig vorher Termine gesetzt.

Nicht besonders spektakulär. Keine neue Software. Kein zusätzliches System, das anschließend ebenfalls gepflegt und überwacht werden muss.

Aber für diese Umgebung eine Lösung, die ihren Zweck erfüllt.

Und genau darum geht es am Ende.

Nicht jede Sicherheitsmaßnahme muss technisch kompliziert sein.

Manchmal beginnt bessere IT-Sicherheit einfach damit, genauer hinzusehen, aufzuräumen - und einen Termin in den Kalender zu schreiben.