Zero Trust als Sicherheitsstrategie
Jenseits von Flickwerk
Veröffentlicht in Ausgabe 10/2021 - SCHWERPUNKT
Auch wenn IT-Planer es hierzulande ungern hören: Die europäische IT steht aus einer Vielzahl von Gründen nicht unbedingt unter Verdacht, hyperinnovativ zu sein. Erfolgreiche Startups etwa entstehen in Europa viel seltener als zum Beispiel in den USA. Und das liegt nicht etwa daran, dass es diesseits des Atlantiks keine klugen Köpfe mit schlauen Ideen gäbe, sondern an den Strukturen der Branche als solcher. Im vielzitierten Bonmot der "Dinge, die wir schon immer so gemacht haben" steckt viel mehr als nur ein Fünkchen Wahrheit. Wer eine europäische IT-Firma schon einmal von innen gesehen hat, wird schnell wissen, was damit gemeint ist: Regelmäßig entsteht hier eher der Eindruck einer archäologischen Ausgrabungsstätte denn eines Technikbetriebs.
Standards aus dem letzten Jahrhundert
Ein Themengebiet, an dem sich das so gut wie bei kaum einer anderen Materie ablesen lässt, ist das der Sicherheit. Wer regelmäßig mit Partnern aus den USA oder Israel zu tun hat, stößt gerade im Rahmen einer Tätigkeit bei deutschen Großkonzernen auf ungläubiges Staunen ob der Standards im Hinblick auf Sicherheit und Compliance, die hierzulande noch immer alltäglich sind.
Dass der Zugriff auf die eigenen E-Mails am Smartphone zum Beispiel an ein mobiles VPN gekoppelt sein soll ("wegen der Sicherheit"), führt bei Beobachtern nicht selten zu Fassungslosigkeit. Ebenso lässt die Tatsache, dass in vielen europäischen Großkonzernen noch immer der regelmäßige Passwortwechsel erzwungen wird, bei manchen Beobachtern eine Augenbraue in die Höhe schießen. Verständlich, ist doch wissenschaftlich längst belegt, dass Anwender im Falle eines Falles einfach das vorhandene Passwort in nur einem Zeichen ändern.
Auch wenn IT-Planer es hierzulande ungern hören: Die europäische IT steht aus einer Vielzahl von Gründen nicht unbedingt unter Verdacht, hyperinnovativ zu sein. Erfolgreiche Startups etwa entstehen in Europa viel seltener als zum Beispiel in den USA. Und das liegt nicht etwa daran, dass es diesseits des Atlantiks keine klugen Köpfe mit schlauen Ideen gäbe, sondern an den Strukturen der Branche als solcher. Im vielzitierten Bonmot der "Dinge, die wir schon immer so gemacht haben" steckt viel mehr als nur ein Fünkchen Wahrheit. Wer eine europäische IT-Firma schon einmal von innen gesehen hat, wird schnell wissen, was damit gemeint ist: Regelmäßig entsteht hier eher der Eindruck einer archäologischen Ausgrabungsstätte denn eines Technikbetriebs.
Standards aus dem letzten Jahrhundert
Ein Themengebiet, an dem sich das so gut wie bei kaum einer anderen Materie ablesen lässt, ist das der Sicherheit. Wer regelmäßig mit Partnern aus den USA oder Israel zu tun hat, stößt gerade im Rahmen einer Tätigkeit bei deutschen Großkonzernen auf ungläubiges Staunen ob der Standards im Hinblick auf Sicherheit und Compliance, die hierzulande noch immer alltäglich sind.
Dass der Zugriff auf die eigenen E-Mails am Smartphone zum Beispiel an ein mobiles VPN gekoppelt sein soll ("wegen der Sicherheit"), führt bei Beobachtern nicht selten zu Fassungslosigkeit. Ebenso lässt die Tatsache, dass in vielen europäischen Großkonzernen noch immer der regelmäßige Passwortwechsel erzwungen wird, bei manchen Beobachtern eine Augenbraue in die Höhe schießen. Verständlich, ist doch wissenschaftlich längst belegt, dass Anwender im Falle eines Falles einfach das vorhandene Passwort in nur einem Zeichen ändern.
Vermeintlich progressive Unternehmen haben im Kampf gegen solche Passwörter die nächste Runde eingeläutet und prüfen das genutzte Kennwort gegen ein Wörterbuch oder auf bestimmte Zeichenketten. "2021" sei im Passwort nicht erlaubt, tönt dann der Passwortmanager, akzeptiert "2o21" als Eingabe aber klaglos. Auf die Suche nach der versteckten Kamera begibt der externe Beobachter sich spätestens, wenn er all diese Sicherheitsmaßnahmen des letzten Jahrtausends sieht und feststellt, dass Zweifaktor-Authentifizierung nicht vorgeschrieben ist.
Das haben wir schon immer so gemacht
Dass viele Sicherheits- und Compliance-Maßnahmen in Unternehmen der Gegenwart mehr Schein als Sein sind, manifestiert sich auch an einer anderen Stelle. Das wird etwa an der Idee des "sicheren lokalen Netzwerks" deutlich, die bei vielen Konzernen landauf und landab weiterhin unbeirrt zum Einsatz kommt. Auch dann, wenn der Vertreter einer Versicherung vor Ort beim Kunden keinen Vertrag ausstellen kann, weil die Software, die mit den zentralen Systemen im Unternehmen kommuniziert, ihre VPN-Verbindung nicht hergestellt bekommt. VPN-Verbindungen brauchen zwar keine dicken Leitungen, aber zuverlässige. Mit einer durch schlechtes EDGE behinderten oder in einem völlig überlasteten 4G-Netz beheimateten Verbindung ist kein Blumentopf zu gewinnen.
Trotzdem zwiebeln viele Unternehmen ihre Mitarbeiter mit solchen und anderen technischen Maßnahmen zweifelhaften Nutzens. Und als ob die Sache nicht schon schlimm genug wäre, scheut sich mancher Manager nicht, unverhohlen den Datenschutz als Ursache für die Malaise ins Feld zu führen. Im gegebenen Kontext ist dann nicht selten zu vernehmen, die DSGVO sei schuld – denn die schreibe ja sichere Kommunikation nach "State-of-the-Art-Prinzipien" vor, "gerade auch wegen Corona". Dass sich die 2500 Kolleginnen und Kollegen schon vor Corona und lange vor der DSGVO durch dasselbe, viel zu dünn konzipierte VPN-Gateway geschlängelt haben, fällt dabei geflissentlich unter den Tisch. Der Unsinn, der im Corporate-Security-Kontext bisweilen zu hören ist, wäre mit "entmutigend" oft noch euphorisch umschrieben.
Endpunkt als zentraler Baustein
Etwas angespannt fragt sich der Leser bei der Lektüre dieses Artikels vielleicht, was der Rant über Großkonzerne und ihr teils absurdes Sicherheitstheater mit dem Titelthema Endpoint Security zu tun hat. Die Antwort darauf mag manchen etwas verblüffen, denn sie lautet: Sehr viel. Konsequent und richtig implementierte Security auf Endgeräten ist nämlich ein riesiger Baustein auf dem Weg zur modernen Sicherheitsarchitektur im eigenen Unternehmen.
Aber damit Endpunktsicherheit effektiv funktionieren kann, braucht sie diverse andere Faktoren. Wer die Endpoint Security als einzige Instanz im Kampf gegen Angreifer betrachtet und nach der Maxime handelt, nur ein möglichst sicherer Client sei der Weisheit letzter Schluss, irrt fatal. Um das genauer auszuführen, ist allerdings ein kleiner Exkurs in Sachen sicheres Netzwerk nötig. Denn es ist zu klären, warum dieses Konzept längst ausgedient hat.
Das Prinzip "sicheres Netz"...
Zugegeben: In vielen Firmen stammt die Idee des sicheren lokalen Netzwerks noch aus einer Zeit, in der die Bedrohungslage innerhalb der IT völlig anders war als heute. Wer Ende der 90er Sicherheit für ein Unternehmen planen musste, hatte zudem nicht einmal einen Bruchteil der Werkzeuge zur Verfügung, die Admins heute zur Wahl haben. Entsprechend grobschlächtig gingen die meisten Firmen vor: Die IT-Abteilung teilte die Welt ganz einfach in Gut und Böse oder, wie das üblicherweise implementiert war, in "die" (bösen Hacker) und "wir" (Nutzer des Unternehmens).
Und diese Trennung zogen die Verantwortlichen mit aller Konsequenz auf allen Ebenen der Firmen-IT durch. Im Rechenzentrum begegnet diese Grundidee den meisten Admins noch heute. Etwa dann, wenn es eine interne Zone gibt, in der die wichtigsten Systeme stehen, die keine direkte Verbindung ins Internet haben. Hinzu kommt die DMZ, die entmilitarisierte Zone, auf die der Zugriff von außen durch Firewalls penibel geregelt ist. Das dritte Netzwerksegment, das Internet, ist böse, pfui und so weit wie möglich zu vermeiden. Größere Unternehmen und Implementierungen haben dieses Prinzip noch verfeinert, indem sie ihr Netz weiter segmentieren.
Die Server mit den besonders wichtigen Daten stehen dann etwa nicht in der internen Zone, sondern in einer "sehr internen" Zone, die ihrerseits nochmals durch eine DMZ mit integrierter Firewall von der ohnehin schon internen Zone getrennt ist. Allein einen Schönheitsfehler hat die Aufteilerei in Segmente: Wer einmal mit einem Client im "lokalen Netz" ist, bekommt Zugang zu den anderen Komponenten des Setups, und zwar auch dann, wenn die eigenen Absichten unlauter sind. Ein Client erhält in Umgebungen dieser Art allein deshalb Zugriff auf Infrastruktur, weil er sich an einem bestimmten physischen oder logischen Ort befindet.
Was im Rechenzentrum vielleicht noch gar nicht so gefährlich klingt, gerät im Kontext von Clients zu einem handfesten Problem. Weil das Prinzip des sicheren lokalen Netzes auf den ersten Blick so verführerisch ist, haben viele Unternehmen es flugs auch auf ihre Clientlandschaft angewandt. Tatkräftig unterstützt von vielen Dienstleistern, die mit entsprechenden VPN-Lösungen horrende Umsätze erzielen. Das Ergebnis: Manche Dienste eines Unternehmens sind überhaupt nicht mehr sinnvoll zu nutzen, weil sie praktisch nicht erreichbar sind. Geht der eigene Dienst-Laptop ein, ist der Kollege praktisch arbeitsunfähig, bis er Ersatzhardware bekommt, die dann wieder mit dem VPN reden darf.
...und warum es noch nie gut war
Das große Problem mit der Idee des sicheren Netzwerks ist, dass sie offensichtlich falsch ist, und schon vor Jahren und Jahrzehnten nicht gut funktioniert hat. Denn die Idee, dass ein Client jedweder Art vertrauenswürdig sei, bloß weil er Zugriff auf ein bestimmtes Netzwerksegment hat, ist Unsinn. Implizit bedingt die Regel nämlich, dass die Nutzer, die die jeweiligen Clients verwenden, wissen, was sie tun – und mit den eingeräumten Privilegien umgehen können. Das Gegenteil ist der Fall, wie verschiedene Beispiele aus der Vergangenheit beweisen.
Legendär sind etwa die Geschichten, bei denen es Sicherheitsforschern gelungen ist, über auf Betriebstoiletten postierte Disketten mit der Aufschrift "Pornos" Zugang zu den Systemen von Mitarbeitern zu bekommen – weil die Floppys natürlich einen Virus enthielten. Dann ist das gesamte Sicherheitskonzept allerdings beim Teufel, denn wenn ein Angreifer einmal Zugriff auf ein System im Innern des Setups hat, greifen die meisten Sicherheitsvorkehrungen nicht mehr.
Andere Beispiele für die Unsinnigkeit des Ansatzes des sicheren Netzwerks sind die zahllosen Fälle gehackter Docker-Container und Betriebssystem-Images, die im Netz mittlerweile unterwegs sind. Freilich: Aus Sicht des Anwenders ist es mühsam, sich aus den Quellen der Anbieter ein eigenes OS-Abbild zu bauen. Da ist die Versuchung groß, sich ein fertiges aus dem Netz zu organisieren, auch wenn das möglicherweise von zweifelhafter Provenienz ist. Mit den Ergebnissen solcher Gedankenlosigkeit kämpfen Admins jeden Tag: Enthält das vorgefertigte Abbild nämlich nicht nur das, was auf der Verpackung steht, sondern auch noch einen Virus oder einen Miner für eine Krypto-Währung, der Traffic ohne Ende produziert, ist das Thema Sicherheit schon wieder beim Teufel.
Hinzu kommt, dass moderne IT ausgesprochen komplex ist – die Firmen, die sich mit IT-Forensik beschäftigen, machen aus gutem Grund viel Geld damit. Denn in einer softwaredefinierten Umgebung die Wege nachzuvollziehen, die Angreifer nach dem illegalen Zugriff auf ein Netzwerkelement genommen haben, ist schwierig und oft sogar unmöglich. Ganze Behörden, Kliniken und Firmen gehen nach solchen Problemen tage- und wochenlang offline, bis das Netzwerk einigermaßen mühsam wieder zusammengeflickt ist.
Sicherheit bis zum IT-Stillstand
Unternehmen mit alten Sicherheitskonzepten ist das in der Regel klar. Und schon sprießen die ekeligsten Workarounds: Mailserver werden in noch tieferen internen Netzwerksegmenten versteckt, komplexe Firewallkonstrukte entstehen, die mittels hyperkomplexer Prozesse um Regeln zu erweitern sind. Am Ende des Wahnsinns steht ein großes Etwas, das die Admins eines Unternehmens in seiner Gesamtheit häufig gar nicht mehr überschauen können, auch weil zum Teil unklar ist, welche Sicherheitsmaßnahmen wann wo wie greifen. Dem Bestreben nach möglichst großer und kompletter Sicherheit fällt die Benutzbarkeit der IT-Dienste eines Unternehmens zum Opfer.
Es reift beim Administrator deshalb die bittere Erkenntnis: Der Umstand, dass sich ein Client an einer bestimmten Stelle befindet (oder eben nicht), kann kein valider Indikator für oder gegen Schutzmaßnahmen sein. Werkzeuge, die diesen Ansatz propagieren – etwa VPN-basierte Produkte – sind ein Relikt der Vergangenheit, das zweifelhafte Sicherheitskonzepte propagiert, die Benutzbarkeit von Diensten einschränkt, aber effektiv kaum Vorteile bringt.
Das ist eine unumstößliche Tatsache, die, wenn sie einmal gesickert ist, den Blick für die eigentlichen Möglichkeiten schärft. Wie das aussehen kann, hat einmal mehr Branchenprimus Google gezeigt: Hier hat das Konzept des sicheren Netzwerks bereits vor Jahren ausgedient. Stattdessen verfolgt der Konzern eine Strategie namens BeyondCorp [1]. Deren Kernaspekt: Es steht nicht mehr der einzelne Client im Vordergrund, sondern dessen Anwendungen und die Art und Weise, wie diese mit vorhandener Infrastruktur kommunizieren.
BeyondCorp heißt nicht "Keine Security"
Um einem gegen das BeyondCorp-Prinzip oft entgegengebrachten Argument gleich anfangs den Wind aus den Segeln zu nehmen: Googles Konzept heißt gerade nicht, dass die Admins auf Sicherheitsvorkehrungen vollständig verzichten. Ganz im Gegenteil: Für die Server, die Google für Dienste wie Gmail oder Google Drive betreibt, gelten explizite, sehr strenge und engmaschige Regeln. Das Ding ist viel eher: Google differenziert bei den eigenen Diensten nicht nach "internen" und "externen" Verbindungen. Stattdessen gilt jeder Client grundsätzlich als nicht vertrauenswürdig.
Ein einzelner Client bekommt also nicht schon dadurch automatisch mehr Rechte als andere, dass er eine bestimmte Netzwerkadresse hat oder an einer bestimmten physischen Location steht. Viel eher gilt: Jeder Mitarbeiter kann zu jedem beliebigen Zeitpunkt von jedem Client auf der Welt grundsätzlich auf seine Ressourcen zugreifen, wenn der Client, mit dem das geschieht, sich an ein paar Spielregeln hält – wodurch er vertrauenswürdig wird. Und jene Spielregeln sind es, die das BeyondCorp-Prinzip ausmachen.
Übrigens: Google hat mit seinem Ansatz eine Reihe weiterer Tech-Giganten inspiriert. Auch Netflix nutzt nach eigener Aussage mittlerweile eine Zero-Trust-Architektur, also ein System, in dem die Dienste des Providers dem Client grundsätzlich gar nicht vertrauen, ganz gleich, wo er ist. Netflix nennt das Prinzip "Location Independent Security Approach", kurz LISA, und hat damit zugegebenermaßen einen viel schöneren Namen erfunden als Google. BeyondCorp, LISA und die meisten Zero-Trust-Ansätze nutzen jedoch dieselben Grundprinzipien; im weiteren Verlauf unterscheiden wir zwischen den Implementierungen daher nicht mehr.
Darauf kommt es bei BeyondCorp an
Der zentrale Ansatz von BeyondCorp ist es, jeden Zugang zu jedwedem Dienst nur dann zu genehmigen, wenn dieser Zugriff mehrere Anforderungen erfüllt. Er muss grundsätzlich authentifiziert sein – der anfragende Client muss also nachgewiesen haben, dass er für die angeforderte Ressource berechtigt ist. Dabei gelten hohe Standards. Darüber hinaus muss der Zugriff autorisiert sein. In einer zentralen Rechteverwaltung muss demnach festgelegt sein, dass der Client auf die Ressource zugreifen darf, auf die er den Zugriff gerade versucht.
Die Verschlüsselung der Verbindung ist zudem obligatorisch und nicht optional. Zumindest dieser Punkt gilt aus heutiger Sicht als selbstverständlich. Versetzen wir uns aber zehn Jahre in der Zeit zurück, gab es durchaus noch Webshops, die keine SSL-Zertifikate hatten, um Bestellungen sicher abzuwickeln. Googles BeyondCorp-Konzept konnte Verbindungen ohne Verschlüsselung aber natürlich nicht erlauben. Denn das hätte geheißen, dass ein jeder Bösewicht mit Zugriff auf die Leitung zwischen Client und Server – oft mehrere Tausend Kilometer – den Datenverkehr mitlesen kann. Damit ein Client aus Sicht des Dienstes vertrauenswürdig werden konnte, musste er also verschlüsselte Verbindungen nutzen können.
Die Anforderungen an den Client und seinen Anwender sind damit aber noch nicht komplett. Denn den Zugang zu einer Ressource erhält ein Nutzer im Kontext eines BeyondCorp-Verfahrens auch nur dann, wenn es möglich ist, eine unmittelbare Verbindung zwischen ihm, seiner Umwelt und seinem technischen Client herzustellen. Was in den BeyondCorp-Richtlinien etwas verklausuliert steht, bedeutet im Alltag in aller Regel Zweifaktor-Authentifizierung (2FA).
Dadurch erschlägt Google das ewige Passwortproblem konsequent: Ist 2FA für einen Zugang aktiviert, ist es zunächst nicht relevant, wenn der Benutzername und das Passwort eines Nutzers Angreifern in die Hände fallen. Damit sie sich einloggen und auf die Daten des Clients zugreifen können, brauchen sie auch den zweiten Faktor – heute meist das Smartphone – mit passender App, über die sich die Freigabe für den jeweiligen Zugriff erteilen lässt. Zurecht ist die Authentifizierung per SMS-Code heute in Verruf geraten und Anwendungen wie Googles Authenticator bieten bessere Alternativen.
Für seine eigenen Dienste geht Google mittlerweile so weit, in den jeweiligen Apps – etwa Gmail – eine Warnung anzuzeigen, falls derselbe Account sich auf einem anderen Gerät einloggt. Bestätigt der Nutzer den Zugriff nicht auf dem eigenen Smartphone, lehnt Google diesen ab. Hilfreich: In aller Regel sind auch Smartphones nochmals gegen den Zugriff durch Fremde gesichert, etwa durch ein Entsperrmuster oder Gesichtserkennung. Das ist praktisch ein dritter Faktor – selbst wenn Bösewichte neben der Kombination aus Usernamen und Passwort auch noch das Smartphone in die Hände bekämen, könnten sie mit diesem Konglomerat noch immer nichts anfangen.
Strenges Regime für Clients
Ein großer Teil von Endpoint-Security-Produkten beginnt erst im Kontext von BeyondCorp irgendeine Form von Sinn zu ergeben. Denn nur, wenn ein Dienst anhand verschiedener Eigenschaften und Parameter des jeweiligen Endgerätes Entscheidungen über die Zulassung oder die Zurückweisung der Verbindung machen kann, bekommt der Admin echte Kontrolle über die einzelnen Clients. Was zugegebenermaßen etwas mehr bedingt als nur richtig konfigurierte Dienste.
Aus gutem Grund ist ein fixer Bestandteil sämtlicher LISA- und BeyondCorp-Umgebungen daher das Management mobiler Geräte. Geht etwa ein Smart-phone verloren, kann der jeweilige Eigentümer – etwa die Firma – das Gerät aus der Ferne löschen und unbrauchbar machen. Auf diese Weise werden sogar BYOD-Szenarien möglich: Wer sein eigenes iPad nutzen möchte, kann das tun, wenn er das Gerät unter die Fittiche des jeweiligen Compliance- und Security-Teams stellt. Das schränkt in aller Regel nicht die Funktionen ein, einen Teil seiner Souveränität über das Gerät gibt der Nutzer aber ab.
Link-Codes
[1] Webseite BeyondCorp: https://cloud.google.com/beyondcorp?hl=de/
Zero Trust ohne Alternative
Wer sich schon einmal mit den zum Teil unbenutzbaren Infrastrukturdiensten deutscher Corporate-IT herumgeschlagen hat, muss früher oder später zur Erkenntnis kommen, dass BeyondCorp eine alternativlose Notwendigkeit ist. Viele Unternehmen scheuen sich, diese Feststellung zu treffen, weil sie einen riesigen Umbau der eigenen Infrastruktur bedingt. Es ist aus diesem Grund auch nicht möglich, an dieser Stelle Tipps oder Hinweise im Hinblick auf einzelne Komponenten zu teilen.
Wer sich durchringt, ein Zero-Trust-Konzept für das eigene Unternehmen zu implementieren, fängt in der Regel am grünen Brett an und gestaltet die Landschaft seiner IT-Anwendungen neu. Das verursacht Unwohlsein und kostet Geld. Google selbst belegt mit Zahlen aus dem eigenen Unternehmen allerdings, dass sich BeyondCorp langfristig auszahlt: Höhere Effektivität bei den Mitarbeitenden, eine weniger komplexe Infrastruktur, die zu warten ist, und weniger ausufernde Prozesse im Unternehmen sind nur einige der Vorteile, die sich am Ende auch in barer Münze bemerkbar machen.
Und natürlich wäre Google nicht Google, hätte das Unternehmen BeyondCorp nicht längst zu einem fertigen Produkt geschnürt, das dem Kunden gegen Bargeld zur Verfügung steht. Sogar einen Migrationsberater stellt der Anbieter interessierten Kunden an die Seite. Der Anbieter aus Mountain View ist damit längst aber nicht mehr allein am Markt vertreten. Wer sich nicht langfristig an Googles Dienste binden möchte, die bei BeyondCorp eine große Rolle spielen, findet ähnliche Ansätze und Komplettpakete bei anderen Anbietern. Obendrein existiert mittlerweile ein Markt an Consultingfirmen, die ähnliche Konzepte mit On-Premises-Komponenten im RZ des Kunden implementieren.
Fazit
Endpoint Security kann nur funktionieren, wenn das Gerät, das der Anwender nutzt, Teil eines engen Netzwerks von Sicherheitsfunktionen ist. Einzig darauf abzustellen, dass von einem Client im VPN keine Gefahr ausgeht, ist aus heutiger Sicht grob fahrlässig. Wer sich aus Admin-Sicht mit Verfahren dieser Art herumschlagen muss, weiß zudem, dass der Betrieb ausgesprochen lästig ist.
Zwar sperren sich die meisten Firmen hierzulande noch immer gegen die Erkenntnis, dass das Prinzip des sicheren Netzes ausgedient hat. Nachhaltig ist diese Strategie jedoch nicht. Es gilt das Prinzip "Besser spät als nie": Wer sich heute dafür entscheidet, eine vergleichbare Strategie umzusetzen, hat zumindest perspektivisch die Option, von der Klappspaten-IT der Vergangenheit loszukommen. Wer sich hingegen weiterhin sträubt, wird sich einer zunehmend schwierig zu pflegenden, verkorksten Infrastruktur gegenübersehen.
(ln)