Kategorie: Security

Infrastruktur & Security · Methode

IT-Service-Management klingt nach Konzern: Prozesse, Gremien, Rollen, ein Regelwerk mit hunderten Seiten. Der Kern dahinter ist aber banal — und im Kleinen genauso gültig: Wer betreibt was, wie erfährt man von Problemen, und wie ändert man etwas, ohne den Rest umzuwerfen.

Die Frage ist nicht, ob man Betriebsdisziplin braucht, sondern wie viel davon sich lohnt, wenn die Organisation aus einer Person besteht. Vieles ist dann Ballast. Drei Dinge sind es nicht.

Was sich lohnt

Drei Bausteine, die auch allein tragen

Diese drei greifen ineinander: Eine Störung verweist auf einen betroffenen Dienst im Verzeichnis, dessen letzte Änderung sich in der Spur findet. Erst zusammen ergeben sie mehr als drei Listen.

Was Ballast ist

Wo die Konzernfassung nicht passt

Ein großer Teil des klassischen Regelwerks löst Probleme, die aus Arbeitsteilung entstehen — Abstimmung zwischen Abteilungen, Nachweis von Zuständigkeit, Absicherung von Entscheidungen. Allein betrieben lösen sich diese Probleme von selbst und die Verfahren dagegen sind reine Kosten.

Die nützliche Frage bei jedem Baustein lautet: Welches konkrete Problem löst er hier? Fällt die Antwort nur allgemein aus — „Ordnung“, „Professionalität“ —, ist es Ballast.

Werkzeuge

Womit man die drei Bausteine führt

Der häufigste Fehler ist nicht die falsche Wahl, sondern die parallele: zwei Systeme für dieselbe Sache, weil das zweite anfangs bequemer war. Danach ist keines vollständig, und beide sind wertlos. Besser eines, das nur zu achtzig Prozent passt, aber ausschließlich benutzt wird.

Der Unterschied

Störung, Ursache, Änderung

Eine Unterscheidung aus dem großen Regelwerk lohnt sich allerdings auch im Kleinen, weil sie eine echte Falle vermeidet:

Der dritte Fehler ist der teuerste. Während einer Störung ist die Hemmschwelle niedrig und die Dokumentation lückenhaft — genau dann entstehen Zustände, die später niemand mehr erklären kann. Das Provisorium gehört deshalb ausdrücklich als solches notiert, mit dem Vorsatz, es zu ersetzen. Sonst wird es dauerhaft.

Maß halten

Nicht-Ziele aufschreiben

Der wirksamste Kniff gegen ausufernde Verfahren ist, die Grenzen ausdrücklich festzuhalten: Was wollen wir bewusst nicht? Ohne diese Liste wächst jedes Konzept, weil jede einzelne Ergänzung für sich sinnvoll klingt.

Konkret heißt das etwa: keine Hochverfügbarkeit, wo ein Ausfall von Stunden verkraftbar ist. Keine Überwachung, deren Meldungen niemand liest. Keine Automatisierung für Vorgänge, die zweimal im Jahr anfallen. Jedes dieser Nicht-Ziele spart dauerhaft Pflegeaufwand — und macht die Entscheidung nachvollziehbar, statt sie als Versäumnis erscheinen zu lassen.

Einstieg

Eine Woche, kein Projekt

1. Aufschreiben, was läuft

   Eine Liste, eine Stunde, unvollständig. Sie wird nie fertig, und das ist in Ordnung — sie muss nur existieren und beim nächsten Anfassen ergänzt werden.

2. Einen Ort für Auffälligkeiten festlegen

   Datei, Notizbuch, Ticketsystem — egal, solange es genau einer ist. Zwei Orte bedeuten null Orte.

3. Änderungen mitschreiben

   Sechs Zeilen je Änderung, im selben Arbeitsgang. Nach drei Monaten hat man etwas, das man bei der ersten Störung tatsächlich benutzt.

4. Nach einem halben Jahr durchsehen

   Was hat geholfen, was wurde nie gelesen? Das Ungelesene abschaffen. Diese Durchsicht ist der eigentliche Prozess — alles andere ist Fleißarbeit.

Infrastruktur & Security · Methode

Software wird so ausgeliefert, dass sie nach der Installation funktioniert — nicht, dass sie sicher ist. Beides gleichzeitig ginge, würde aber Rückfragen erfordern, die ein Erstinstallation nicht stellen will. Härtung ist die Arbeit, die zwischen „läuft“ und „läuft, ohne unnötig angreifbar zu sein“ liegt.

Das Missverständnis dabei: Härtung wird oft als Liste von Einstellungen verstanden, die man einmal abarbeitet. Tatsächlich ist es eine Reihe von Entscheidungen, bei denen jede etwas kostet — meist Bequemlichkeit, manchmal Funktion.

Der Kern

Weniger da, weniger erreichbar, weniger erlaubt

Fast alle Härtungsmaßnahmen lassen sich auf drei Fragen zurückführen. Sie in dieser Reihenfolge zu stellen, spart die meiste Arbeit — was gar nicht installiert ist, muss man weder erreichbar machen noch berechtigen.

1. Muss das überhaupt da sein?

   Jedes installierte Paket, jeder mitgelieferte Beispieldienst, jede Standard-Erweiterung ist Angriffsfläche, die gepflegt werden muss. Der wirksamste Schritt ist Entfernen, nicht Absichern. Was fehlt, hat keine Lücken.

2. Muss das von dort erreichbar sein?

   Ein Dienst, der nur lokal gebraucht wird, muss nicht am Netzwerk lauschen. Eine Verwaltungsoberfläche muss nicht aus dem gesamten Heimnetz erreichbar sein. Die Standardeinstellung ist fast immer „von überall“ — sie ist eine Bequemlichkeitsentscheidung des Herstellers, keine Sicherheitsentscheidung.

3. Muss das so viel dürfen?

   Dienste laufen erstaunlich oft mit vollen Rechten, weil das jede Fehlermeldung vermeidet. Ein eigenes Konto je Dienst, nur mit den Rechten, die es tatsächlich braucht, begrenzt den Schaden eines einzelnen Einbruchs auf diesen Dienst.

Die Basis

Was vor jeder Feinarbeit kommt

Vorgaben

Nicht selbst erfinden

Für die gängigen Betriebssysteme und viele Anwendungen gibt es veröffentlichte Härtungsvorgaben — von Herstellern, von Sicherheitsbehörden, von Fachverbänden. Sie sind gründlicher, als man es allein hinbekommt, und ersparen die Diskussion mit sich selbst über jede einzelne Einstellung.

Aber: Solche Kataloge sind für den strengsten denkbaren Einsatzzweck geschrieben. Wer sie ohne Prüfung vollständig anwendet, legt sich Einschränkungen auf, die im eigenen Umfeld keinen Gewinn bringen und Betrieb kosten. Der brauchbare Weg ist, den Katalog als Fragenliste zu nehmen, jede Abweichung bewusst zu treffen — und die Begründung dazuzuschreiben. Eine dokumentierte Abweichung ist Härtung; eine unbemerkte ist eine Lücke.

Werkzeuge

Was einem die Arbeit abnimmt

Für die Vorgaben selbst sind die CIS Benchmarks der verbreitetste Katalog; für den deutschsprachigen Raum kommt das IT-Grundschutz-Kompendium des BSI hinzu. Beide sind frei verfügbar und ersparen die Diskussion mit sich selbst über jede einzelne Einstellung.

Die Grenze

Wenn Härtung den Betrieb frisst

Jede Maßnahme hat einen Preis, und der wird selten mitgerechnet. Strengere Regeln erzeugen Fehlalarme, die jemand prüfen muss. Automatische Sperren treffen irgendwann den Betreiber selbst — vorzugsweise nachts und von unterwegs. Eine feingliedrige Rechtevergabe muss bei jeder Änderung nachgezogen werden, sonst zerfällt sie zu einer Sammlung von Ausnahmen.

Deshalb gilt derselbe Maßstab wie bei jeder anderen Betriebsentscheidung: Eine Maßnahme, die man nicht dauerhaft pflegen kann, ist keine Verbesserung, sondern eine Verschiebung. Sie erzeugt das Gefühl von Sicherheit und verfällt still.

Drei Maßnahmen, die man durchhält, schützen besser als dreißig, die nach dem ersten Umbau nicht mehr stimmen.

Reihenfolge

Womit anfangen, wenn nichts davon existiert

Zwischen den Schritten jeweils eine Weile nichts Neues tun und beobachten, was auffällt. Wer alles an einem Wochenende umstellt, weiß bei der nächsten Störung nicht, welche der zwanzig Änderungen sie verursacht hat.

Infrastruktur & Security · Methode

„Warum ist das so eingestellt?“ — die teuerste Frage im Betrieb einer Anlage, die man allein verwaltet. Denn die Person, die es weiß, ist dieselbe, die fragt, nur ein halbes Jahr später.

Änderungsdokumentation gilt als Bürokratie für große Organisationen. Tatsächlich löst sie ein Problem, das im Kleinen genauso auftritt und dort sogar härter zuschlägt: Es gibt niemanden, den man fragen könnte.

Der eigentliche Zweck

Nicht Rechenschaft, sondern Rekonstruktion

In Unternehmen dient das Verfahren auch der Absicherung — wer hat was genehmigt. Allein betrieben entfällt dieser Teil vollständig, und mit ihm der Ruf der Bürokratie. Übrig bleibt der nützliche Kern: die Möglichkeit, einen Zustand später zu erklären.

Drei Situationen, in denen sich das auszahlt. Nach einer Störung: Was hat sich zuletzt geändert? Ohne Aufzeichnung beginnt jede Fehlersuche bei null. Bei einer Wiederherstellung: Der zurückgespielte Stand ist älter als die letzten Anpassungen — welche fehlen jetzt? Beim Wiedersehen mit alten Entscheidungen: Eine seltsame Einstellung ist entweder ein Fehler oder die Lösung eines Problems, das man vergessen hat. Ohne Notiz ist beides gleich wahrscheinlich, und man baut den alten Fehler nach.

Was hineingehört

Sechs Zeilen genügen

Ein Eintrag, der länger dauert als die Änderung selbst, wird nicht geschrieben. Deshalb kurz — aber mit diesen Feldern:

Das Feld „Warum“ trägt den ganzen Nutzen. Was geändert wurde, lässt sich notfalls aus der Versionsverwaltung ablesen. Die Begründung existiert nur im Kopf — und dort nicht lange.

Abstufung

Nicht jede Änderung braucht dasselbe Verfahren

Wer für jeden Handgriff ein Formular ausfüllt, hört nach zwei Wochen auf. Der Ausweg ist eine Staffelung nach Risiko — und ein Katalog wiederkehrender Arbeiten, die vorab freigegeben sind:

Beispiele

Wo sich der Eintrag garantiert auszahlt

Nicht jede Änderung ist gleich riskant. Diese hier haben eines gemeinsam: Sie wirken sofort, ihre Nebenwirkungen zeigen sich später, und die Ursache ist dann schwer zu finden.

Auffällig ist das Muster: In fast allen Fällen liegt zwischen Änderung und Störung genug Zeit, dass der Zusammenhang nicht mehr auffällt. Genau diese Lücke schließt der Eintrag — er ist weniger Dokumentation als Zeitstempel.

Die Falle

Umgesetzt, ohne je freigegeben zu sein

Das häufigste Versagen ist nicht die fehlende Dokumentation, sondern die halbe: Ein Vorgang wird angelegt, die Arbeit passiert — und der Eintrag bleibt für immer im Zustand „geplant“. Nach einem halben Jahr steht in der Aufzeichnung eine Liste von Vorhaben, von denen niemand weiß, welche davon Wirklichkeit sind.

Das ist schlimmer als gar keine Aufzeichnung, weil sie Vertrauen beansprucht, das sie nicht verdient. Dagegen hilft nur eine harte Regel: Ein Vorgang wird geschlossen oder er wird zurückgenommen. Offene Einträge älter als eine gesetzte Frist sind selbst ein Befund und gehören durchgesehen.

Praktisch

Womit man das führt

Es gibt drei brauchbare Wege, alle quelloffen und alle richtig — je nachdem, was man sucht:

Die Kombination ist verbreiteter als die reine Lehre: Begründung im Commit, Entscheidung in einer Notiz, Vorgang im Ticketsystem — solange klar ist, welche Ebene wofür zuständig ist. Unklar wird es, wenn dieselbe Information an zwei Orten steht und einer davon veraltet.

Entscheidend ist nicht das System, sondern dass der Eintrag im selben Arbeitsgang entsteht wie die Änderung. Alles, was auf „später sauber nachtragen“ hinausläuft, geschieht nicht. Nicht aus Nachlässigkeit — sondern weil die Begründung bis dahin verblasst ist und der Eintrag dann tatsächlich nur noch Bürokratie wäre.

Infrastruktur & Security · Methode

Ein Wiederherstellungsplan, der nie ausprobiert wurde, ist kein Plan. Er ist eine Vermutung darüber, wie man sich im Ernstfall verhalten würde — aufgeschrieben von jemandem, der zu diesem Zeitpunkt entspannt war.

Die meisten Heimnetze und kleinen Umgebungen haben Sicherungen. Deutlich weniger haben eine geprüfte Wiederherstellung. Der Unterschied fällt erst auf, wenn er teuer wird.

Der Kern

Nicht die Sicherung zählt, sondern die Rückkehr

Eine Sicherung ist eine Behauptung: „Diese Daten sind woanders vorhanden und lassen sich zurückholen.“ Belegt wird die Behauptung erst durch einen Rückholversuch. Alles davor ist Buchhaltung.

Typische Gründe, warum die Rückkehr scheitert, obwohl die Sicherung lief: Das Archiv ist verschlüsselt und der Schlüssel liegt im ausgefallenen System. Die Sicherung enthält die Datenbankdateien, aber im laufenden Zustand kopiert und damit unbrauchbar. Es fehlt eine Kleinigkeit, die nie im Sicherungsumfang stand — eine Konfigurationsdatei, ein Zertifikat, ein Zugangstoken. Oder das Zurückspielen dauert vier Tage, weil niemand die Übertragungsdauer je hochgerechnet hat.

Zwei Zahlen

Wie viel Verlust, wie viel Stillstand

Beide Werte sind je Dienst verschieden, und das ist der Punkt. Wer sie pauschal für die ganze Anlage festlegt, sichert entweder zu viel oder zu wenig. Ein Medienarchiv und eine Passwortverwaltung haben nichts gemein außer dem Serverraum.

Der Notfallzugang

Der Weg hinein, wenn der übliche Weg tot ist

Je sauberer eine Umgebung gebaut ist, desto abhängiger ist sie von ihren eigenen zentralen Diensten. Anmeldung über einen zentralen Dienst, Geheimnisse aus einem Tresor, Namensauflösung über einen eigenen Server: Fällt eines davon aus, ist unter Umständen auch der Weg zur Reparatur versperrt.

Dagegen hilft ein bewusst außerhalb liegender Notfallzugang — ein Konto, das nicht am zentralen Anmeldedienst hängt, mit einem Zugangsweg, der ohne die ausgefallene Infrastruktur funktioniert. Dieser Zugang ist per Definition eine Schwachstelle, deshalb gehört er eingeschränkt, protokolliert und regelmäßig geprüft.

Die Probe

Was ein echter Test beinhaltet

1. Vom Sicherungsmedium, nicht vom Original

   Zurückgespielt wird aus dem Archiv — nicht aus dem noch laufenden System, dessen Daten man bequem danebenliegen hat. Sonst prüft man die Kopierfunktion, nicht die Sicherung.

2. Auf frischer Grundlage

   In eine leere Umgebung, nicht über die bestehende Installation. Nur so fällt auf, was im Sicherungsumfang fehlt und bisher unbemerkt vom Altsystem beigesteuert wurde.

3. Mit gestoppter Uhr

   Die Dauer wird gemessen und notiert. Sie ist die einzige belastbare Antwort auf die Frage, wie lange ein Ausfall dauert — und meistens deutlich länger als geschätzt.

4. Bis zur fachlichen Prüfung

   Ein Dienst, der startet, ist nicht wiederhergestellt. Erst wenn die Daten inhaltlich stimmen — letzte Einträge vorhanden, Verknüpfungen intakt, Anmeldung möglich — war der Test erfolgreich.

5. Von jemandem, der es nicht gebaut hat

   Wo möglich. Wer die Anlage errichtet hat, ergänzt unbewusst die Lücken der Anleitung aus dem Gedächtnis. Im Ernstfall steht diese Person vielleicht nicht zur Verfügung.

Rhythmus

Wie oft, ohne dass es zur Last wird

Der Rhythmus ist wichtiger als die Gründlichkeit. Ein knapper Test, der stattfindet, schlägt den vollständigen, der seit zwei Jahren geplant ist.

Werkzeuge

Womit gesichert wird — und was das für den Test bedeutet

Beispiele

Wo die Rückkehr besonders schwierig ist

Die Dokumentation

Wo der Plan liegen muss

Eine Wiederherstellungsanleitung, die im Wiki auf dem ausgefallenen Server steht, ist im Ernstfall Teil des Ausfalls. Dasselbe gilt für Zugangsdaten in einer Verwaltung, die selbst betroffen sein könnte, und für Anleitungen, die nur eine Person im Kopf hat.

Was es braucht, ist eine ausgedruckte oder offline verfügbare Fassung an einem bekannten Ort, die den Weg von einem leeren Gerät bis zum laufenden Dienst beschreibt — inklusive der Frage, wo die Sicherungen liegen und wie man an ihre Schlüssel kommt. Kurz genug, dass sie gepflegt wird; vollständig genug, dass sie trägt.

Sicherungen schützen die Daten. Getestete Wiederherstellungen schützen den Betrieb. Das ist nicht dasselbe.

Infrastruktur & Security · Methode

Zertifikate laufen ab. Das ist kein Fehler, sondern der Zweck: Ein Ausweis mit unbegrenzter Gültigkeit ist im Zweifel ein Generalschlüssel für den, der ihn gestohlen hat. Die eigentliche Frage lautet nicht, ob ein Zertifikat abläuft, sondern ob der Ablauf geplant war.

Wer eigene Zertifikate ausstellt — für Dienste im Heimnetz, für interne Weboberflächen, für die Verbindungen zwischen Programmen — tauscht ein bekanntes Problem gegen ein unbekanntes: Statt einmal im Jahr eine Verlängerung zu kaufen, betreibt man eine Ausstellungsstelle, die jederzeit funktionieren muss. Dieser Text beschreibt, woran das erfahrungsgemäß scheitert.

Warum kurz

Die Laufzeit ist eine Sicherheitsentscheidung

Ein gestohlener privater Schlüssel lässt sich nicht zurückholen. Man kann das Zertifikat für ungültig erklären — aber nur, wenn alle Beteiligten die Sperrliste auch abfragen, und genau das tun viele Programme nicht zuverlässig. Die verlässlichere Bremse ist die Uhr: Was in Stunden abläuft, ist in Stunden wertlos.

Deshalb der Trend zu kurzen Laufzeiten, im Extremfall Minuten. Der Preis dafür ist Automatik. Was jährlich erneuert wird, kann ein Mensch im Kalender führen. Was stündlich erneuert wird, muss eine Maschine übernehmen — und diese Maschine wird damit zum kritischen Teil der Anlage.

Das Ausfallmuster

Der Fehler passiert Wochen vor dem Ausfall

Zertifikatsausfälle haben eine Eigenart, die sie von anderen Störungen unterscheidet: Zwischen Ursache und Wirkung liegt die gesamte Restlaufzeit.

1. Die Erneuerung bricht ab

   Ein Zugangstoken der Automatik läuft aus, eine Berechtigung ändert sich, ein Dienst startet nach einem Neustart nicht mehr mit. Nichts fällt aus — das vorhandene Zertifikat gilt ja noch.

2. Wochen passieren

   Alles funktioniert. Niemand sucht einen Fehler, weil sich keiner zeigt. Die Restlaufzeit sinkt still.

3. Der Ausfall

   Dann fällt nicht ein Dienst aus, sondern alle, die dasselbe Ausstellungsdatum teilen — gleichzeitig. Und die Fehlermeldung zeigt auf das Zertifikat, nicht auf die Ursache von vor sechs Wochen.

Daraus folgt die wichtigste Regel: Überwacht gehört die Erneuerung, nicht der Ablauf. Ein Alarm bei „läuft in drei Tagen ab“ kommt Wochen zu spät für die Ursachensuche — er meldet ein Symptom, dessen Auslöser längst kalt ist.

Was man messen sollte

Vier Werte, die den Zustand beschreiben

Vorbereitung

Der Weg zurück, wenn nichts mehr geht

Wenn die Ausstellungsstelle nicht erreichbar ist, starten Dienste nicht mehr, die vorher jahrelang mit einer Konfigurationsdatei ausgekommen sind. Das ist der Moment, in dem sich zeigt, ob jemand vorher darüber nachgedacht hat.

Diese Antworten gehören aufgeschrieben, an einen Ort, der ohne die betroffene Anlage erreichbar ist — und einmal im Jahr durchgespielt. Ein Plan, der nur im Kopf existiert, ist im Ernstfall genau dann nicht abrufbar, wenn es darauf ankommt.

Werkzeuge

Womit man das baut

Für eine eigene Ausstellungsstelle braucht es keine Eigenentwicklung — es gibt mehrere ausgereifte, quelloffene Wege, die sich in Aufwand und Reichweite unterscheiden:

Für die Verteilung an die Dienste gilt dasselbe wie für die Ausstellung: Sie muss unbeaufsichtigt laufen. Ein Zertifikat, das erneuert, aber nicht neu eingelesen wird, sieht in jeder Statistik gut aus und nützt trotzdem nichts — viele Dienste laden es erst bei einem Neustart oder nach einem Signal.

Wo es besonders weh tut

Drei Stellen, an denen ein abgelaufenes Zertifikat mehr als eine Warnung ist

Einstieg

Wenn man klein anfangen will

Nicht alles auf einmal. Eine Reihenfolge, bei der jeder Schritt für sich schon etwas bringt: Zuerst eine Bestandsaufnahme — welche Zertifikate existieren überhaupt, wann laufen sie ab, wer erneuert sie. Allein diese Liste fördert meist Überraschungen zutage.

Dann ein einzelner Dienst auf automatische Erneuerung, mit deutlich kürzerer Laufzeit als bisher. Läuft der zwei Zyklen sauber durch, folgt der nächste. Erst danach die Überwachung der Erneuerung selbst — vorher gibt es nichts zu überwachen, und man verwechselt Einrichtungsfehler mit Betriebsfehlern.

Der zweite Zyklus ist der entscheidende. Der erste läuft fast immer, weil man dabeisteht. Der zweite läuft unbeaufsichtigt — und genau dort zeigen sich abgelaufene Zugangstoken, fehlende Berechtigungen und Neustarts, die keiner mitbekommen hat.