Schlagwort: DIY

Regeln oder gute Vorsätze — Ausgabe 2026

Dieses Regelbuch habe ich 2012 zum ersten Mal aufgeschrieben. 14 Jahre später — nach etlichen Migrationen, Security-Incidents, Nachtschichten und dem einen oder anderen Moment in dem ich mir selbst dankbar war, dass ich damals diese Regeln aufgestellt hatte — ist es Zeit für eine Überarbeitung. Die Grundidee bleibt: Regeln aus der eigenen Praxis, kein Lehrbuch. Hinter jeder Regel steht mindestens eine Geschichte, die ich lieber nicht noch einmal erleben möchte.

Was sich geändert hat? Die Welt ist komplexer geworden. Cloud, Zero Trust, DSGVO, Supply-Chain-Angriffe, Post-Quantum-Kryptografie — das gab es 2012 so nicht oder es hat damals niemanden interessiert. Was geblieben ist? Backups sind immer noch wichtig, Dokumentation macht immer noch keinen Spaß und das tote Pferd lässt sich immer noch nicht reiten.

#01 — Nenne das Kind beim Namen!

Klare Kommunikation. Kein Weichspüler, kein Drumherum-Reden. Wenn ein System am Limit ist, dann sage ich das — und zwar so, dass es auch der Geschäftsführer versteht. Nicht um Panik zu machen, sondern damit alle die gleichen Informationen haben und bewusste Entscheidungen treffen können.

Ich habe zu oft erlebt, wie Probleme so lange schöngeredet wurden, bis niemand mehr wusste, worum es eigentlich geht. Dann passiert der Fehler und alle sind überrascht. Klare Ansage, kurze E-Mail an alle Beteiligten — fertig. Schlafen alle besser.

#02 — Nicht ohne Backup!

Diese Regel ist 14 Jahre alt und hat sich kein einziges Mal als falsch herausgestellt. Vor jeder kritischen Operation — Patch, Migration, Upgrade, Plattentausch — gibt es ein Backup. Keine Ausnahme.

Was sich geändert hat: 3-2-1-Regel ist Pflicht geworden. Drei Kopien, zwei verschiedene Medien, eine davon offsite. Und seit Ransomware zum Volkssport geworden ist, braucht mindestens eine Kopie einen Schutz gegen nachträgliche Veränderung — immutable Snapshots, Air-Gap, WORM-Storage. Wer sein Backup auf demselben System lagert wie die Produktivdaten, hat kein Backup. Der hat eine Kopie, die beim nächsten Verschlüsselungstrojaner mit draufgeht.

Die Ausnahme von 2012 gilt immer noch: Kein Backup? Dann Regel #01 — und die Entscheider unterschreiben, dass sie das Risiko tragen. Schriftlich.

#03 — Teste dein Backup!

Ein Backup das niemand getestet hat, ist eine Wette. Vielleicht klappt der Restore, vielleicht auch nicht. Und im Ernstfall willst du das nicht zum ersten Mal ausprobieren — um drei Uhr nachts, mit dem Chef im Nacken.

Also: Regelmäßig testen. Nicht nur prüfen ob der Job durchgelaufen ist, sondern tatsächlich Daten wiederherstellen. Dabei lernt man zwei Dinge — ob es funktioniert und wie lange es dauert. Beides will man vorher wissen, nicht nachher. Gehört übrigens in den DRP (Regel #15).

#04 — Wie wichtig ist das überhaupt?

Nicht jedes System ist gleich wichtig. Eine Firma kann Tage ohne die Bildergalerie im Intranet leben — aber vier Stunden ohne E-Mail oder Warenwirtschaft und es wird teuer. Das muss vorher geklärt und schriftlich festgehalten sein. Am besten mit konkreten Zahlen: Was kostet eine Stunde Ausfall? Was kostet die höhere Verfügbarkeit?

Wenn die Kosten neben der gewünschten Verfügbarkeit stehen, werden die Diskussionen plötzlich sachlich. Und wenn dann doch mal was ausfällt, gibt es keine Überraschungen — weil alle wussten, worauf sie sich eingelassen haben.

#05 — Datenschutz ist kein Feature!

2012 habe ich hier geschrieben, dass Admins entdeckte Datenschutzprobleme ansprechen sollten. Das gilt immer noch — aber die Lage hat sich massiv verändert. DSGVO, Schrems II, das ganze Programm. Datenschutz ist keine nette Empfehlung mehr, sondern Gesetz. Mit Bußgeldern, die wehtun.

Als Admin bist du oft der Einzige, der wirklich sieht, wo Daten hinfließen. Dieses Wissen verpflichtet. Wenn personenbezogene Daten in eine Cloud wandern, die unter US-Jurisdiktion fällt, oder wenn Mitarbeiterdaten unverschlüsselt über das Netz gehen — dann muss das auf den Tisch. Nicht weil man der Datenschutzbeauftragte ist, sondern weil man das als Vertrauensperson schuldig ist.

#06 — Klare Ansprechpartner!

Der Serverraum hat ein Problem — wen rufst du an? Und wenn der nicht erreichbar ist? Klingt banal, ist es nicht. Klare Zuständigkeiten mit Vertretungsregelung müssen vorher definiert sein. Ein guter Ansprechpartner hat technisches Grundverständnis und Entscheidungskompetenz. Das Schlimmste ist, wenn du um drei Uhr morgens jemanden erreichst, der zwar zuständig ist, aber nichts entscheiden darf.

#07 — Ein totes Pferd kann man nicht reiten.

Es gibt Systeme, die sind am Ende. End-of-Life Software, Hardware ohne Ersatzteile, Betriebssysteme ohne Security-Updates. Man kann noch so viel Geld und Zeit reinstecken — irgendwann hilft kein Workaround mehr. Dann muss man Nein sagen. Nicht aus Bequemlichkeit, sondern weil man für ein System, das nicht mehr zu verantworten ist, keine Verantwortung übernehmen kann.

2012 habe ich als Beispiel alte Windows-Server genannt und Debian-Systeme mit Archive-Quellen. 2026 stehen da noch ganz andere Dinge: PHP 7 im Internet, ungepatchte Log4j-Instanzen, TLS 1.0 auf dem Mailserver, CentOS 7 ohne Extended Support. Alles tote Pferde. Absteigen, neues Pferd suchen.

#08 — Workarounds dokumentieren!

Workarounds sind wie provisorische Brücken — sie helfen im Moment, aber wenn niemand sie aufschreibt, werden sie zum Dauerzustand. Und irgendwann weiß niemand mehr, warum dieser eine Cronjob jeden Dienstag um 04:17 Uhr den Apache neustartet.

Also: Jeden Workaround dokumentieren. Was ist das Problem? Was ist der Workaround? Warum keine echte Lösung? Und dann regelmäßig prüfen, ob sich die Lage geändert hat. Manchmal gibt es nach einem Update plötzlich eine richtige Lösung — aber nur wenn man noch weiß, dass da ein Workaround im Weg steht.

#09 — Es lebe die Dokumentation!

Jetzt mal unter Freunden — Dokumentation macht keinen Spaß. Hat es nie, wird es nie. Aber sie ist überlebenswichtig. Nicht für dich heute, sondern für dich in sechs Monaten, wenn du vergessen hast warum du diesen einen Parameter so gesetzt hast. Oder für den Kollegen, der deinen Dienst übernimmt während du im Urlaub bist.

Mein Ansatz: Ich dokumentiere so, dass mein zukünftiges Ich es versteht, wenn es müde und gestresst ist. Nicht mehr, nicht weniger. Und ja — dieser Blog ist ein Teil davon. Halb Dokumentation, halb Selbsttherapie.

#10 — Das richtige Werkzeug!

Wenn du mit dem falschen Schraubendreher lange genug an einer Schraube drehst, hast du am Ende eine runde Schraube und einen kaputten Schraubendreher. Gilt für Hardware, gilt für Software, gilt für Prozesse. Das richtige Werkzeug kostet manchmal Zeit zum Holen — spart aber ein Vielfaches an Reparaturzeit hinterher.

Heute heißt das auch: Nicht jedes Problem braucht eine Enterprise-Lösung. Manchmal ist ein Shell-Script besser als eine teure Plattform. Und manchmal ist die teure Plattform besser als drei zusammengestrickte Shell-Scripts. Den Unterschied zu erkennen ist die eigentliche Kunst.

#11 — Ist der Stecker drin?

Klingt dumm, ist es nicht. Systematisches Troubleshooting fängt bei den einfachsten Dingen an. Der Benutzer sagt, er habe alles probiert — trotzdem lohnt sich der eigene Blick. Zu oft war zwar der Stecker drin, aber der von der Kaffeemaschine.

Mein wichtigstes Troubleshooting-Prinzip: Nicht von der Mitte anfangen und raten, sondern systematisch von unten nach oben. Kabel, Link, IP, DNS, Dienst, Applikation. Und wenn man sich verrannt hat — zurück zum letzten Punkt, an dem noch alles funktioniert hat. Das klingt trivial, aber in der Hitze des Gefechts vergisst man es erstaunlich oft.

#12 — Jedem sein Login!

Personalisierte Accounts mit eigenen Zugangsdaten. 2012 wie heute, keine Diskussion. Nicht um jemandem etwas vorzuwerfen, sondern um nachvollziehen zu können was passiert ist und daraus zu lernen.

Was dazugekommen ist: MFA überall. Zweiter Faktor, keine Ausnahme. Am besten Hardware-Token oder Passkeys. SMS als zweiten Faktor akzeptiere ich nur noch unter Protest und mit Verweis auf Regel #01. Und geteilte Admin-Accounts? Tot. Jeder Admin bekommt seinen eigenen privilegierten Account — nachvollziehbar, sperrbar, auditierbar.

#13 — Verschlüssele alles!

Daten in Bewegung — verschlüsselt. Daten in Ruhe — verschlüsselt. Keine Ausnahme, kein „aber intern ist das ja sicher“. Intern ist gar nichts sicher, das hat uns jeder zweite Ransomware-Vorfall der letzten Jahre gezeigt.

TLS 1.3 als Minimum, Festplatten verschlüsselt, Backups verschlüsselt. Und wer heute noch Systeme ohne Transportverschlüsselung betreibt — SMTP ohne STARTTLS, HTTP ohne TLS, LDAP im Klartext — der muss sich fragen lassen, welches Jahr wir haben. Bonuspunkte für Post-Quantum-Kryptografie, denn Quantencomputer kommen schneller als man denkt.

#14 — Patch deine Systeme!

Ein ungepatchtes System ist eine offene Einladung. Das war 2012 schon so, aber heute ist die Zeit zwischen Veröffentlichung einer Schwachstelle und dem ersten Exploit auf Stunden geschrumpft. Nicht Tage, nicht Wochen — Stunden.

Patch-Management muss ein Prozess sein, kein Zufall. Regelmäßig, geplant, getestet. Und ja — Regel #02 kommt vorher. Erst Backup, dann Patch. Wenn ein Patch nicht eingespielt werden kann, weil die Software zu alt ist oder der Hersteller keinen mehr liefert — siehe Regel #07. Totes Pferd.

#15 — DRP!

Disaster Recovery Plan. Schon beim Erstellen werden einem Dinge bewusst, die man sonst übersieht. Systeme werden priorisiert (Regel #04), Verantwortliche benannt (Regel #06), Backups getestet (Regel #03). Ein DRP gibt nicht nur dem Admin Sicherheit — das ganze Unternehmen profitiert, weil es einen Plan für den Notfall gibt.

Neu seit 2012: Der DRP muss auch Cloud-Szenarien abdecken. Was passiert, wenn der Cloud-Provider ausfällt? Oder den Vertrag kündigt? Oder die Region nicht erreichbar ist? Und er muss getestet werden — nicht nur auf dem Papier, sondern als echte Übung. Einmal im Jahr den Ernstfall durchspielen. Das ist unbequem, aber es zeigt schonungslos, wo die Lücken sind.

#16 — Vertraue niemandem!

Zero Trust. Kein Gerät, kein Benutzer, kein Netzwerksegment ist automatisch vertrauenswürdig — auch nicht „das interne Netz“. Jeder Zugriff wird authentifiziert und autorisiert. Jedes Mal. Klingt paranoid, ist aber die einzige Architektur, die noch Sinn ergibt, wenn man akzeptiert, dass der Perimeter längst durchlöchert ist.

Das bedeutet nicht, dass man niemandem mehr trauen soll — aber das Vertrauen muss technisch durchgesetzt werden, nicht angenommen. Microsegmentierung, Least Privilege, kontinuierliche Verifikation. Und ja, das ist aufwendig. Aber weniger aufwendig als der nächste Incident, bei dem sich ein Angreifer lateral durch das „sichere“ interne Netz bewegt hat.

#17 — Was du nicht misst, existiert nicht.

Ein System ohne Monitoring ist wie Autofahren ohne Tacho und ohne Warnleuchten. Es läuft — bis es das nicht mehr tut, und dann weißt du nicht warum. Monitoring heißt nicht nur „ist der Server erreichbar“, sondern: Wie voll ist die Platte? Wie hoch ist die Load? Gibt es ungewöhnliche Login-Versuche? Läuft der Backup-Job durch?

Und dann brauchst du Alerting, das dich weckt, wenn etwas schiefgeht — nicht erst wenn der Benutzer anruft. Ein guter Alert ist einer, der dich aus dem Bett holt, bevor der Schaden eintritt. Ein schlechter Alert ist einer, der so oft kommt, dass du ihn ignorierst. Die Balance zu finden ist eine Kunst für sich.

Das waren 2012 dreizehn Regeln, jetzt sind es siebzehn geworden. Die Welt ist nicht einfacher geworden. Aber die Grundidee bleibt: Klartext reden, Backup machen, Dokumentation schreiben, tote Pferde rechtzeitig erkennen. Wer das beherzigt, schläft nachts besser.

Erste Fassung: März 2012 — Überarbeitet: März 2026