Viele Unternehmen fühlen sich ihrer Daten sicherer, wenn diese im eigenen Rechenzentrum liegen. Denn dort sind sie schon seit Jahren und werden von bekannten, vertrauenswürdigen Personen betreut. Wie sicher aber sind die eigenen Rechenzentren wirklich?

Zur Person

Jan Tietjen ist Security Experte mit mehr als 20 Jahren Erfahrung bei der Beratung von Wirtschafts-unternehmen und Behörden im deutschsprachigen Raum. Darüber hinaus ist er Geschäftsführer der Paranoid Security DE GmbH mit Sitz in Leverkusen.

Gregor: Wie schätzt Du als Sicherheitsexperte den Status Quo der laut Bitkom etwa 50.000 deutschen Rechenzentren ein?

Jan: In dieser Zahl der Bitkom sind sehr unterschiedliche Rechenzentren enthalten. Einige sind brandneu und enthalten nur die neuesten Cloud-Stacks, etwa von VMware. Einige andere aber leben noch in der IT-Steinzeit. Dazwischen gibt es dann ein riesiges Spektrum an Varianten mit allerlei Möglichkeiten, was da schiefgehen kann.

Zudem besitzen viele Organisationen mehrere Data Center, die sich meist sehr voneinander unterscheiden. Eines ist vielleicht sehr alt, wurde schrittweise immer erweitert. Solche Bauten kann man vergleichen mit dem Kölner Dom, an dem wird ja seit 1248 gebaut. Andere Rechenzentren kamen vielleicht über Firmenakquisitionen hinzu. Wieder weitere gleichen eher Serverschränken, welche einzelne Abteilungen sich selbst eingerichtet haben.

Wenn man sich vergegenwärtigt, dass sich die Welt der IT alle paar Jahre fast komplett umkrempelt, dann kann man sich vorstellen, was in manchen Hallen alles an Hardware schlummert. Irgendwer hat dann vor 20 Jahren ein System aufgebaut, ist aber seit letztem Jahr in Rente. Die Applikation läuft dann basierend auf einer alten Solaris-Version oder mit Windows 2012-Servern. Wenn man dann fragt „Ist das Kunst oder kann das weg?“ verfallen alle in Panik. Die Verantwortung übernehmen, dass die alte Applikation abgeschafft wird, möchte dann niemand.

"Weil du nicht weißt, was in deinem Rechenzentrum drinsteckt, weißt du auch nicht, wie unsicher du bist."

Gregor: Was ist denn das Kernproblem dieser gewachsener Rechenzentren?

Jan: Vielen IT-Organisationen fehlt die Transparenz. Sie wissen, dass sie alte Hard- und Software im Haus haben, aber sie wissen nicht, welche genau und welche Aufgaben diese erfüllen. Früher wurden diese ‚Assets‘ eben nicht gemanaged, nicht einmal im rudimentärsten Sinne. Als die Leute der ‚elektronischen Datenverarbeitung‘ (EDVler) noch nicht mit am großen Tisch saßen, behandelte man  sie wie ungeliebte Stiefkinder. Niemand schaute genau hin, sie saßen im Keller, sollten funktionieren aber nichts kosten. Genauso despektierlich ist das gelaufen.

Das Ergebnis ist dann: Niemand kennt die Komponenten, die verbaut sind.

Gregor: Welche Auswirkung hat diese mangelnde Transparenz auf die tatsächliche Sicherheit der Rechenzentren?

Jan: Jede dieser Komponenten kann Schwachstellen enthalten. CPUs, Betriebssysteme, Router, Switche, Datenbanken, Anwendungen – keine, die nicht einmal einen Bug gehabt hätte und für die es nicht regelmäßiger Updates bedarf. Was heutzutage auch akribisch dokumentiert wird, sind Netzwerk-Schnittstellen und MAC-Adressen als eindeutige Identifier. Welches Kabel geht in welchen Slot und zu welchem Switch oder welchem Patchboard?

Die einfachste Forderung von uns Sicherheits-Experten ist immer: Haltet alle Software-Stände aktuell. Nur wenn ich nicht weiß, welche Software ich wo einsetze, dann kann ich diese auch nicht patchen. Ich weiss auch nicht, für welche Software die ich nutze, es gar keine Updates mehr gibt, weil sie ‚End-of-Life‘ sind.

Daher: Viele Rechenzentren überschätzen ihre eigene Sicherheit. Die traurige Wahrheit in so einer Situation ist: Weil du nicht weißt, was in deinem Rechenzentrum drinsteckt, weißt du auch nicht, wie unsicher du bist.

Gregor: Was sollten Unternehmen dann als erstes tun?

Jan: Viele möchten sofort ein Security Operations Center (SOC) aufbauen. Das klingt cool, so nach einem zentralen Steuerungszentrum wie bei einem Raketenstart. Aber so ein Zentrum macht gar keinen Sinn, wenn Dir der Kontakt zu der Rakete fehlt, die du starten möchtest. Übertragen auf die Cybersicherheit bedeutet dies: Wenn Dir die Sicht auf deine Assets fehlt, dann kannst du sie auch nicht sichern. Die Grundlage für ein sicheres Rechenzentrum also ist sauberes ‚Visibility Management‘.

Du musst also mit der digitalen Taschenlampe durch das Rechenzentrum laufen und jede Ecke einmal anleuchten. Netzwerkscanner etwa analysieren den internen Datenverkehr und können herausfinden, welche Software sich bei Dir im Keller befindet. Sie fragen auch bei jedem Port und jeder IP-Adresse der Hardware einmal nach und sehen ob die antworten. Manchmal finden die noch OpenSSL in einer Version, die noch auf Heartbleed reagieren würde – einer Sicherheitslücke, die eigentlich schon vor 10 Jahren geschlossen wurde. Im sogenannten Vulnerability Management geht es also darum herauszufinden, wie verwundbar meine IT-Landschaft ist.

"Du musst also mit der digitalen Taschenlampe durch das Rechenzentrum laufen und jede Ecke einmal anleuchten."

Gregor: Was mache ich denn, wenn ich im Keller zu viel Ungeziefer finde?

Jan: Das schlimmste was du jetzt machen kannst, die Treppe wieder hochgehen und die Tür zumachen. Am Besten ist es, nicht überall gleichzeitig das Licht anzumachen, sondern nach Bereichen vorzugehen. Als Minimum müsste dann ein ordentliches Patch Management eingeführt werden. Das bedeutet, dass jede Komponente auf einen aktuellen Software-Stand gebracht wird.

Für einige Assets wird das nicht funktionieren. Diese ‚alten Mühlen‘ benötigen dann ein eigenes Netzwerk, einen eigenen Hühnerstall also. Drumherum gibt es dann eine Mauer (Netzwerkseparation) und einen Wachhund (Security Gateway). Letzterer passt auf, dass unter den Besuchern kein Fuchs ist (Identity und Access Management).

Der nächste Schritt ist dann das Configuration Management inklusive Härtungsmaßnahmen. In der Configuration Management Database (CMDB) wird nachgehalten, wie die Assets im Rechenzentrum konfiguriert sind. Welche Passwortlänge benötigt der Admin des Betriebssystems? Wie wurden Regeln für die Firewall gesetzt? Welche Sicherheitsbeschränkungen sind für die Ports der Switche gesetzt? Bei neueren Systemen kann die Dokumentation dieser Konfigurationen automatisch erfolgen. In den meisten alten Rechenzentren aber gibt es eklatante Unterschiede zwischen der Realität und der Dokumentationslage.

Gregor: Danach macht dann auch ein SOC Sinn?

Jan: Ja, dann kann ich darüber nachdenken. Erst Visibilität durch Asset Management, dann Patch und Vulnerability Management sowie ein möglichst automatisiertes Configuration Management. Das ist dann zwar nicht das Fort Knox der IT-Security, aber den IT-Grundschutz kann ich dann schon umsetzen.

Gregor: Würde denn solchen Unternehmen eine Migration in die Cloud helfen, ihren Sicherheitsstand zu erhöhen?

Jan: Hier spielen einige Effekte eine Rolle. Zum einen bekommst du in den Public Clouds einen besseren Überblick über Deine Assets, einfach weil sie Dir jeden davon einzeln in Rechnung stellen. Deine monatliche Cloud-Rechnung ist also deine ‚kostenlose‘ Bill-Of-Materials.

Viel spannender aber ist der Effekt, dass ich bei einer Migration in die Cloud gezwungen bin, jede Applikation einmal anzuschauen. Wer ist dafür verantwortlich? Benötige ich sie noch? Mit welchen anderen Applikationen ist sie verbunden? Wie bei einem echten Umzug in eine neue Wohnung, finde ich da viele Dinge und werfe einige von denen dann auch weg.

Als Drittes kann ich mich relativ einfach vieler Aufgaben komplett entledigen, so ich denn möchte. Beispielsweise darf man nicht unterschätzen, wie viel Aufwand es ist, ein Datenbank-Cluster hochverfügbar, global und und immer aktuell gepatched zu betreiben. In vielen Public Clouds gibt es hierfür Rundum-Sorglos-Pakete.

"Eine Cloud-Transformation läuft nicht so einfach à la ChatGPT: Vorne mein Geschwafel rein und hinten raus klinge ich wie Goethe."

Eine echte Cloud-Transformation kann also sicherheits-seitig richtig viele Vorteile bringen. Nur läuft das nicht so einfach à la ChatGPT: Vorne mein Geschwafel rein und hinten raus klinge ich wie Goethe.  Diese Transformation ist echt harte Arbeit, bei der man viel lernt. Stichwort DevOps und Agile. Achja, und die Cloud-Provider lassen sich ihre Services natürlich fürstlich bezahlen.

Gregor: Was ist Deine abschließende Empfehlung für Unternehmen, die jetzt erstmalig mit der Taschenlampe in den Keller gehen?

Jan: Ich würde auf jeden Fall nicht an zu vielen Fronten gleichzeitig mit der Arbeit beginnen. Ein guter Weg könnte sein, das eigenen Rechenzentren schrittweise zu leeren, die Applikationslandschaft aufzuräumen und mit den verbliebenen Applikationsgruppen in die Public Cloud zu ziehen. Dort hat die Organisation dann alle modernen Werkzeuge und Optionen dieser neuen Welt, um die IT-Sicherheit zu verbessern.

Theoretisch könnte eine Organisation nebenher auch ein eigenes, optimiertes Rechenzentrum auf der grünen Wiese mit einer Private Cloud aufbauen. In der Praxis aber ist das unrealistisch. Unternehmen, die ihre Reise bei einer derart geringen technologischen Reife beginnen, wird es nicht gelingen, neben der absoluten Basisarbeit in der alten IT-Landschaft, ein modernes Rechenzentrum zu konzipieren und aufzubauen.

Meine Empfehlung also ist: Erst das alte Rechenzentrum ausmisten und in die Public Cloud migrieren. Das muss ja nicht unbedingt eine US-Cloud sein. Dort dann konsequent lernen, wie Cybersecurity und moderne IT funktioniert, aber proprietäre Tools und Schnittstellen der Anbieter vermeiden. Als letzten Schritt dann, ein passgenaues und effizientes Cloud-Rechenzentrum auf der grünen Wiese neu aufbauen und dort einziehen.

Gregor: Vielen Dank für das Gespräch.