Zero Trust und die Herausforderungen für Entwickler
Immer mehr Unternehmen setzen auf das Zero-Trust-Modell, um sich vor aktuellen Gefahren zu schützen. Für die Entwickler ihrer Business-Anwendungen ändert sich dadurch vieles.
Das wichtigste Grundprinzip hinter sich dem zunehmend verbreitenden Zero-Trust-Framework ist, immer alles erst zu prüfen und niemals jemandem oder etwas einfach zu vertrauen. Das ist ein komplett anderes Vorgehen als es bisher in der Welt der IT-Security üblich war. Hier gilt bislang oft noch das „Prinzip des überprüften Vertrauens“. Dabei wird zum Beispiel davon ausgegangen, dass Maschinen und alle Geschehnisse innerhalb eines Netzwerks generell als vertrauenswürdig angesehen werden können. Sie befinden sich ja innerhalb des geschützten Bereichs. In letzter Zeit mehren sich aber die Stimmen aus der IT-Security, die für einen Umstieg auf das Zero-Trust-Modell plädieren.
Ursprünglich wurde dieses Konzept von Forrester Research im Jahr 2010 entwickelt. Seitdem wurde das Zero-Trust-Modell von zahllosen Organisationen und Firmen auf der Welt übernommen, um ihre Nutzer und Daten damit effektiver und konsequenter zu schützen. Manche Firmen wie Google haben sogar bereits eine komplette unternehmensweite Zero-Trust-Architektur implementiert. Die positiven Erfahrungen, die der Konzern damit machen konnte, vermarktet er mittlerweile unter dem Dach seiner Tochtergesellschaft BeyondCorp.
Was ändert sich mit Zero Trust für Entwickler?
Was bedeutet aber Zero Trust für all jene Personen, die am Design und der Entwicklung von Anwendungen und Diensten in Unternehmen beteiligt sind? Jeder IT-Sicherheitsspezialist weiß, dass sich ein großer Teil der Nutzer und Komponenten in einer modernen IT-Infrastruktur außerhalb des traditionellen Perimeters befinden und deswegen nicht mehr direkt kontrolliert werden können. Zero Trust akzeptiert diese Tatsache, indem die Verantwortung für die Sicherheit vom traditionellen Netzwerkperimeter abgekoppelt wird. Stattdessen wird sie auf die jeweilige genutzte Anwendung ausgelagert. Sie selbst erhält alle benötigten Fähigkeiten, um Zugriffe zu prüfen und Richtlinien zu befolgen. Für Entwickler wird dadurch manches schwieriger. So können sie sich dann nicht mehr allein auf eine einzige Programmierschnittstelle (API, Application Programming Interface) verlassen, die sich sowohl um Authentifizierung als auch Autorisierung kümmert. Sie müssen stattdessen über zusätzliche Kenntnisse verfügen, um jeden einzelnen Schritt einer Interaktion zwischen ihrer Anwendung und der anfragenden Person oder Maschine genau zu verstehen und absichern zu können.
In einem Zero-Trust-Framework müssen die Entwickler also den kompletten Umfang jeder einzelnen Session einschätzen können, um das dadurch entstehende Risiko bewerten und eingrenzen zu können. Dazu müssen sie nicht nur über die Identität des Anwenders im Bilde sein, sie müssen auch den aktuellen Zustand des verwendeten Endgeräts und die für die Anfrage verwendete App kennen sowie eine Einschätzung über die Sensibilität der angeforderten Daten abgeben können. Das trifft selbst dann zu, wenn sich alle diese Elemente im weiterhin als sicher eingestuften Firmennetz befinden. Im nächsten Schritt müssen die Entwickler sicherstellen können, dass ihr Code die geltenden Sicherheitsrichtlinien einhalten kann. Abhängig können dann Zugriffe auf die angeforderten Daten erlaubt, eingeschränkt zugewiesen oder gegebenenfalls komplett blockiert werden. Dazu werden aber möglicherweise weitere Authentifizierungsschritte wie eine Multifaktor-Authentifizierung, ein mögliches Begrenzen der Funktionalität oder auch zusätzliche Compliance-Kontrollen benötigt. Oder anders gesagt, es wird ein auf Whitelists basierendes Vorgehen verwendet, wenn es um Zugriffe auf die Daten geht.
Darüber hinaus muss der Entwickler dafür sorgen, dass die Anwendung neben effektiven Methoden zur Authentifizierung und zur Autorisierung auch starke Verschlüsselungsmechanismen zum Schutz der Daten und der Verbindungen beherrscht. Außerdem sollte die Anwendung konsequenten statischen und dynamischen Application Security Tests unterzogen werden. Die mit dem Thema IT-Sicherheit befassten Teams sollten zudem Fuzzing- und Penetrationstests durchführen, um alle im Entwicklungsprozess entstandenen Schwachstellen aufspüren und entfernen zu können.
Ein Einsatz des Zero-Trust-Frameworks bedeutet aber auch, dass Plug-ins aus anderen Quellen und aus dem Open-Source-Bereich nicht per se vertraut werden darf. Es ist von größter Wichtigkeit, dass die Entwickler jederzeit genau wissen, welche Komponenten genutzt werden und wie sich Updates und Bug-Fixes überwachen und einspielen lassen. Diese Aufgabe wird am besten mit einem spezialisierten Tool zur Software Composition Analysis wie Black Duck oder WhiteHat Sentinel erledigt. Die komplette Software Supply Chain, die aus verschiedenen Elementen zur Entwicklung, zum Testen und zur produktiven Nutzung von Code besteht, sollte dabei kontinuierlich überwacht werden.
Sicherheit von Anfang an
Die Absicherung ihres Codes muss von den Entwicklern von Beginn eines Projektes an mit einbezogen werden. Das ist der beste Weg, wenn der Übergang vom bislang vorausgesetzten Vertrauen zu Prozessen vollzogen werden soll, die ausdrücklich für eine explizite Überprüfung und für ein umfassendes Management aller Identitäten und Zugriffe sorgen. Das ist einer der Gründe, warum so viele Unternehmen derzeit von DevOps zu DevSecOps wechseln. Nur dort spielt das Thema Sicherheit in jedem einzelnen Entwicklungsschritt eine entscheidende Rolle. Ein mit einem Zero-Trust-Framework entwickelte Anwendung kann selbst dann den Schutz der Daten gewährleisten, wenn Maßnahmen zur Kontrolle des Perimeters wie Firewalls, IPS-Systeme (Intrusion Prevention Systems) und DLP-Tools (Data Loss Prevention) ihre Aufgabe wegen einer fehlerhaften Konfiguration oder aus anderen Gründen nicht erfüllen können.
Der Einsatz eines Zero-Trust-Frameworks sorgt aber nicht dafür, dass nicht mehr kontinuierlich nach neuen Schwachstellen gesucht werden muss, die auch nach dem Deployment einer Anwendung entstehen können. Mit Schwachstellenscans kann sichergestellt werden, dass sowohl das Backend als auch die sich dazwischen befindenden Systeme geschützt sind und ordnungsgemäß ihre Aufgaben erfüllen. Das führt letztlich aber dazu, dass nicht mehr wie früher nahtlose und äußerst flexible Zugriffe auf Anwendungen, Systeme und Daten möglich sind. Aber das ist ein Preis, den Unternehmen für die Sicherheit der Nutzer als auch der benötigten Ressourcen zahlen müssen. Die Änderungen sollten selbst dort umgesetzt werden, wo sich die genutzten Ressourcen auch weiterhin im lokalen Data Center und innerhalb des eigenen Perimeters befinden. Außerdem werden sie bei Zugriffen auf Server in Cloud-Umgebungen oder bei von Drittanbietern gemanagten SaaS-Anwendungen (Software as a Service) benötigt.
