​

Wer kennt sie nicht, die Diskussionen über die Zuständigkeiten:

• Wer hat den Server bestellt?
• Wer spielt die Security Patches für die Anwendung ein?
• Wer konfiguriert die Service-Accounts?
• Welcher Depp hat mich jetzt wieder aus der Remote-Sitzung geschmissen?? 😡

Die Theorie ist ganz einfach, aber in der Praxis sieht das oft anders aus. Wenn der Server schon ein paar Jahre auf dem Buckel hat, die Verantwortlichkeiten wechseln und alles ziemlich hysterisch gewachsen ist, dann wirst du mit der harten Realität konfrontiert. Die Antwort darauf lautet dann meist: "Keine Ahnung!", oder "Nicht ich!"

Wie Server aufgebaut sind

Du kennst vielleicht solche Grafiken, die zeigen, wie Managed Services in der Cloud funktionieren. Zum Beispiel Infrastructure-, Platform- und Software-as-a-Service.

Man muss es nicht so kompliziert machen, aber die Kästchen sind praktisch, um die Verantwortlichkeiten zu verteilen – zumindest theoretisch.

Für die grobe Unterteilung im IT-Betrieb, reichen aber die folgenden drei Ebenen:

• Dienst: Das ist eine Anwendung, die auf dem Server läuft und eine Funktion bereitstellt. Das kann ein Webserver sein, eine Datenbank, ein Active Directory, ein DHCP-Server, ein File-Server und so weiter. Also quasi alles von "Applications" bis "Middleware". Container wie Docker gehören auch dazu.
• Plattform: Das ist das Betriebssystem, auf dem die Anwendung läuft. Windows, Linux, Unix, macOS, Android, embedded System und so weiter.
• Maschine: Das ist alles unterhalb des Betriebssystems, das man zur Maschine zählen kann. Wie die Virtualisierungsumgebung, die Hardware mit CPU, RAM, Storage, Netzwerk, aber natürlich auch Firmware wie UEFI.

Ein Dienst kann nicht ohne Plattform existieren, und eine Plattform kann nicht ohne Maschine existieren. Aber es gibt noch eine interessante Kehrseite:

Viele IT-Kollegen vergessen im Alltag, dass die nervigen Fachanwendungen der Grund sind, warum die Server überhaupt erst in Betrieb sind. Und die Kollegen aus den Fachabteilungen vergessen, dass ihnen für die Hochverfügbarkeit der Fachanwendung die Redundanz der Maschine nichts nützt, wenn die Plattform für ein Update neu gestartet werden muss.

Wer macht was?

"Der Bäcker bäckt die Breze, der Fleischer würgt die Kuh, der Arzt entfernt die Krätze. Mein Kind, und was machst du?"

Die EAV hat sich das in den 90ern auch schon gefragt. In vielen Firmen ist das Thema bis heute nicht geklärt. Selbst wenn wir unser Ebenen-System strikt umsetzen und die Verantwortlichkeiten den jeweiligen Teams zuweisen, gibt es immer noch sehr viele Überlappungen. Hier ein paar Beispiele:

• Ein Application-Admin benötigt Admin-Rechte auf dem Betriebssystem, um die Anwendung zu aktualisieren
• Die Windows-Härtungsrichtlinie beeinträchtigt die SQL-Datenbank und User können sich nicht mehr anmelden
• Die Anwendung bekommt eine neue Schnittstelle, die von der lokalen Linux-Firewall blockiert wird
• Ein Firmware-Update muss auf der Hardware eingespielt werden und eine Downtime des Dienstes und der Plattform ist notwendig
• Es gibt eine Security-Schwachstelle in der Webanwendung, mit der das Betriebssystem kompromittiert werden kann
• Es gibt eine Security-Schwachstelle am Hypervisor. Wird sie ausgenutzt, kann ein Plattform-Admin die unterliegende Maschine kapern

Macht-Spielchen

Nein, ich meine nicht die Herrschaften aus dem mittleren Management mit fragilen Egos. ❄️ Ich spreche von Privilege-Escalation und Angriffsvektoren!

Die letzten beiden Beispiele von oben zeigen ziemlich gut, was ich meine. Wir haben nicht nur eine Überlappung der Verantwortlichkeiten, sondern auch der Sicherheit.

Leider berücksichtigen viele IT-Sicherheitsarchitekten diese Angriffswege nicht. Die Anwendungen werden super abgesichert, die Betriebssysteme abgeschottet und die Berechtigungen werden entzogen. Aber dass der Virtualisierungs-Admin ganz locker-flockig von der gesamten Kiste einen Snapshot im Live-Betrieb zieht und sich dann unbemerkt und in Ruhe die Daten zieht, die er braucht, das bedenkt niemand.

Bei Servern mit mittlerer Kritikalität oder Vertraulichkeit hält sich der Schaden in Grenzen. Wenn es aber um hochsensible, zentrale Systeme wie ein Active Directory oder eine PKI geht, dann kann das schnell zu einem sehr großen Problem werden.

Ich habe mir deswegen schon unzählige Male den Mund fusselig geredet. Ein Tier-Konzept nur im Active Directory umzusetzen, reicht aus diesem Grund leider nicht aus. Hier sind noch ein paar Beispiele für Wege, wie Angreifer sensible Systeme hacken können:

• Lokale Agents: Wie zum Beispiel für das License-Management, oder Software-Delivery. Jedes Stück Software, das Code auf dem Betriebssystem ausführt, kann den Server kompromittieren.
• Memory Dump: Ein Maschinen-Admin kann über ein Remote-Management-Interface wie iDRAC, ILO und IPMI ein Abbild des RAMs erstellen und so die Credentials, Kennwörter und Schlüssel direkt auslesen.
• Backup: Wenn die Datenträger der Server nicht verschlüsselt sind, können gespeicherte Daten, wie die Active Directory Datenbank mit allen Password-Hashes, aus einem Backup extrahiert werden. Das Backup kann sogar 3 Jahre alt sein, denn sind wir uns ehrlich, häufiger änderst du die Passwörter der Service-Accounts sowieso nicht.

Lösungsansätze

Du siehst also, es ist alles nicht so einfach. Jede Firma hat andere Anforderungen und auch andere Arbeitsweisen, mit der sie versucht diese Probleme zu lösen.

RACI

Ich empfehle jeder IT, für ihre Aufgaben eine zentrale RACI-Matrix zu erstellen und diese auch ständig zu erweitern. RACI steht für Responsible, Accountable, Consult und Inform. Das Team, das bei der Aufgabe das R stehen hat, darf sich die Hände schmutzig machen und sie umsetzen. Mit A bekommt man die Ergebnisverantwortung und muss sicherstellen, dass die Umsetzung erfolgreich ist. Alle mit einem C dürfen ihren Senf dazugeben und beraten. Die mit dem I sind am feinsten raus, denn die werden nur über den aktuellen Stand informiert.

Das kann eine einfache Tabelle wie diese hier sein, aber auch ein komplexes ITSM-Dokument.

CMDB

Die perfekte Lösung, um übergreifende Berechtigung zwischen den Ebenen zu identifizieren, ist eine Configuration Management Database, kurz CMDB. Damit kannst du einzelne Assets miteinander verbinden. So kannst du die Anwendung mit den Servern und die Server mit der Hardware verknüpfen.

Für kleinere Umgebungen ist das zwar eine komplexe Lösung, aber für den Mittelstand lohnt sie sich auf jeden Fall.

Fazit

Gute IT-Architektur ist echt eine feine Sache. Eine gute UND sichere IT-Architektur ist noch feinerer. Aber die vorhandene IT-Architektur in eine gute und sichere umzubauen, ist ein Kraftakt. IT-Security und IT-Architektur müssen von Anfang an mit in die Planung einbezogen werden, damit sie ihre Wirkung entfalten können.