Wenn Unternehmen den Lebenszyklus bei der Entwicklung ihrer Anwendungen optimieren und beschleunigen und diese dann in der Cloud bereitstellen möchten, wird die Sicherheit zu einer größeren Herausforderung. Cloud-native Anwendungen sind komplexer und weisen mehr Abhängigkeiten auf, weshalb sie auch schwieriger zu sichern sind. Traditionelle Ansätze drehen sich im Kreis: Es wird lediglich reagiert, um die Symptome eines Angriffs zu behandeln, statt die eigentliche Ursache abzuwehren. Die Sicherung cloud-nativer Anwendungen erfordert jedoch einen anderen Ansatz.

Bei der Anwendungssicherheit geht es vorrangig darum, die aus der automatisierten Informationsverarbeitung resultierenden Risiken zu bewältigen. Anwendungsdaten können durchsickern, gefälscht werden oder kaskadierende Risiken für andere Anwendungen und Systeme verursachen. Wie bei jedem Risiko gibt es drei grundlegende Methoden, damit umzugehen: Vermeidung, Minderung oder Akzeptanz.

In einem traditionellen Modell, in dem die Sicherheitsabteilung innerhalb der Organisation weitestgehend isoliert ist und so ihre laufende Arbeit kaum oder gar nicht sichtbar ist, ist Vermeidung schwierig. Bei diesem Ansatz besteht die Aufgabe des Sicherheitsteams zunächst darin, nach Abschluss der Änderungen an der Anwendung die Risiken zu bewerten. Sollten diese über ein akzeptables Maß hinausgehen, müssen die Sicherheitsfachleute sie entweder vermeiden, also die Freigabe der Anwendung verschieben, oder aber sie müssen diese Risiken mindern, indem sie die Anwendung unverändert laufen lassen. Gleichzeitig müssen sie aber den Datenverkehr auf System- und Netzwerkebene mit Hilfe spezieller Instrumente und Software filtern. Da Änderungen an der Anwendung nur bei Produktionsfreigabe einen Wert haben, wird natürlich der letztere Ansatz, nämlich die Risikominderung bevorzugt.

Kaufen oder selbst erstellen?

Die Erstellung einer eigenen Anwendung ist fast immer teurer, schwieriger und riskanter als die Beschaffung auf dem Markt. Der Hauptgrund, warum Unternehmen sich für die Entwicklung eigener Anwendungen entscheiden, ist, dass sie dadurch speziell auf sie zugeschnittene Geschäftsprozesse unterstützt und so die Anwendungen zu einem Wettbewerbsfaktor wird. Hieraus folgt allerdings auch, dass firmenspezifische Anwendungen in der Regel sehr sensible und wertvolle Daten beinhalten, die ihr Risikoprofil aufblähen, noch bevor die erste Zeile Code geschrieben wird.

Da firmenspezifische Anwendungen also meist ein Wettbewerbsfaktor sind, ist die Zeit bis zur Markteinführung ebenso wie eine Kultur regelmäßiger betrieblicher Experimente von größter Bedeutung für ihren Erfolg. Das cloud-native Modell unterstützt dies in vielerlei Hinsicht: Es verringert die für die Einführung neuer Anwendungen erforderlichen Anfangsinvestitionen, es macht die Freigabe neuer Änderungen viel einfacher und bietet Skalierbarkeit, wenn das Experiment erfolgreich ist.

Cloud-native Anwendung als Ausweg

Durch die Skalierungswirkung macht die Cloud den Betrieb der Infrastruktur kostengünstiger. Andererseits geht dies auf Kosten der Standardisierung und begrenzt die Flexibilität. Je moderner die Anwendungsarchitektur ist, desto schwieriger ist es, sie mit einer benutzerdefinierten Sicherheitsschicht zu ergänzen. So ist es etwa relativ einfach, ein Anwendungssicherheits-Gateway als virtuelle Maschine in der dem Internet zugewandten Umgebung zu implementieren. Viel schwieriger ist es jedoch sicherzustellen, dass dieses Gateway den Datenverkehr zwischen den entsprechenden Kubernetes-Pods überwacht. Bei einer serverlosen Anwendung ist dies ohne Änderungen am Anwendungscode überhaupt nicht möglich.

Externe Abhängigkeiten vergrößern die Angriffsfläche

Laut einer groß angelegten Umfrage enthalten 96 % der Unternehmensanwendungen externe Open-Source-Komponenten, die durchschnittlich 57 % der Codebasis ausmachen. Das bedeutet, dass mehr als die Hälfte der Angriffsfläche von externen Bibliotheken und System-Images abhängt, für die es in der Regel kein Sicherheitsteam gibt, das Empfehlungen veröffentlicht und an die User versendet. In der Open-Source-Welt liegt es in der Verantwortung der Benutzer, relevante Sicherheitsdaten abzufragen, zu verstehen und zu nutzen.

Quelle: GitLab

Effektive Risikovermeidung

Aber es gibt auch gute Nachrichten. Während die Risikominderung in der cloud-nativen Welt immer schwieriger wird, bietet der schnelle Änderungszyklus eine Chance zur Risikovermeidung. Die Werkzeuge für die Belieferung des Software Life-Cycle enthalten bereits automatische Pforten (Gates), welche die Codequalität bei jeder einzelnen Änderung überprüfen. Es gibt keinen Grund, warum diese Pfortenprüfungen nicht auf Code-Sicherheit, Prüfungen auf bekannte Schwachstellen, Verifizierung von Dockerbase-Images und sogar auf automatisierte Durchdringungstests ausgeweitet werden könnten. Dabei gibt es jedoch zwei äußerst schwierige Gesichtspunkte: Man muss es rechtzeitig tun und zugleich die Sichtbarkeit der aktuellen Ergebnisse für jeden beteiligten Mitarbeiter in der Organisation sicherstellen:

Frühe und häufige Tests

Die erste Herausforderung hängt überraschenderweise mit der Infrastruktur zusammen. Der klassische Ansatz für den Aufbau kontinuierlicher Integrationspipelines ist der Aufbau einer linearen Abfolge von Anwendungsumgebungen. Diese bewältigen aufeinanderfolgende Testschritte, wobei jeder einzelne Schritt das getestete System sicherer macht und es so näher an die Produktionsreife bringt. Die Sache hat allerdings einen Haken: Entwickler in einem agilen Team arbeiten nicht linear. Jeder von ihnen wählt die zu erledigende Aufgabe aus einem gemeinsamen Pool aus, versucht, sie so effizient wie möglich zu erledigen, eine Freigabe zu erhalten und danach zur nächsten Aufgabe überzugehen. Die genaue Durchführungsreihenfolge ist dabei nicht vorhersehbar. Jeder Kontextwechsel ist für die Entwickler mental aufwendig und kann sie leicht aus dem Konzept bringen. Sobald der Code zu einem Master-Zweig zusammengeführt wird, was in der Entwicklersprache soviel heißt wie, der Code ist ein potenzieller Kandidat für die Produktionsfreigabe, erfolgen spätere Änderungen auf einer höheren Schicht, was die Kosten für solche Modifikationen deutlich erhöht.

Ein Lösungsansatz hierfür ist die Durchführung einer vollständigen Testreihe in einer individuellen Testumgebung vor der Codezusammenführung. Leider ist der Betrieb einer eigenen Instanz der gesamten Anwendung für jeden einzelnen Entwickler in der Regel zu kostspielig, um in Betracht gezogen zu werden. Auch hier kann eine Cloud-native Architektur helfen. Mit Kubernetes ist es zum Beispiel einfach, automatisch eine vorübergehende Prüfanwendungs-Instanz zu erstellen, darin alle erforderlichen Tests durchzuführen und die Ergebnisse dem Entwicklungsteam dann zur Verfügung zu stellen. So kann das Team besser entscheiden, ob der Code zusammengeführt werden soll oder nicht.

Aufbau einer Sicherheitskultur

Die Informationen über Sicherheitspforten können zu einer dieser drei möglichen Entscheidungen führen: Erstens kann es sein, dass das mit der potenziellen Schwachstelle verbundene Risiko vernachlässigbar ist und keinen Einfluss auf die Entscheidung hat. In einem solchen Fall wird das Entwicklerteam diese Schwachstelle für die analysierte Codebasis wahrscheinlich nie wieder sehen. Zweitens kann es sein, dass das Risiko erheblich ist und die Schwachstelle vor Ort behoben und erneut getestet werden kann. Und schließlich kann es vorkommen, dass ein Risiko besteht, das gesondert zu betrachten ist, die laufende Arbeit aber nicht unterbrechen sollte. In einem solchen Fall müssen zukünftige Arbeiten im System erfasst werden.

Zum Aufbau einer Sicherheitskultur und für das Verständnis, dass jeder für die Anwendungssicherheit verantwortlich ist, sollte diese Entscheidung grundsätzlich an das Entwicklerteam delegiert werden. Die richtige Entscheidung erfordert demnach, dass das aktuelle Risikoprofil und die Historie der Anwendung, die offenen Sicherheitsfragen, das Projektmanagement, der jeweilige Geschäftsbereich, die IT-Entwicklung und alle anderen Beteiligten allgemein sichtbar sind – denn Sicherheit ist ein Prozess, an dem jeder beteiligt ist.

Fazit

Entwicklungsteams sollten nicht nur darüber nachdenken, wie sie die Vorteile der Cloud-Umgebung nutzen können, sondern auch über ihre Sicherheitsstrategie nachdenken. Die Auswahl des richtigen Sicherheitsprozesses ist eine Grundvoraussetzung für sichere native Cloud-Implementierungen. Die Lösung besteht darin, eine komplette Testreihe in einer individuellen Testumgebung durchzuführen, bevor der Code zusammengeführt wird. Dies war vorher nicht möglich, kann jetzt aber mit einer cloud-nativen Infrastruktur und Tools umgesetzt werden. Mit Kubernetes kann zum Beispiel automatisch eine temporäre Instanz für Testanwendungen erstellt werden, in der alle erforderlichen Tests durchgeführt werden und die Ergebnisse dann dem Entwicklungsteam zur Verfügung gestellt werden. Der richtige Prozess und die richtigen Werkzeuge bringen nicht nur unmittelbare Vorteile, indem sie das Risiko eines Verstoßes verringern. Sie erhöhen auch die Transparenz und tragen zum Aufbau eines Sicherheitsbewusstseins und einer Sicherheitskultur innerhalb der Organisation bei.

Damit Entwickler und Sicherheitsexperten näher zusammenrücken können, um cloud-native Anwendungen sicher zu machen, ist gegenseitiges Verständnis unerlässlich – schließlich bedeutet Softwareinnovation unweigerlich auch Sicherheitsinnovation.

Michal Kulakowski, Solution Architect bei GitLab.

Lesen Sie in unserem e-Book, wie die Sicherheitsteams und Programme an die Geschwindigkeit der Softwareentwicklung angepasst werden können.

445 Artikel zu „Open Source Sicherheit“

NEWS | TRENDS SECURITY | TRENDS 2016 | IT-SECURITY | LÖSUNGEN | SERVICES | TIPPS

Sicherheitsrisiko Security-Software: Angreifbar durch Open-Source-Komponenten

2. Januar 2017

Vulnerability Update listet 11 Sicherheitsprogramme; viele der Anwendungen enthalten Open-Source-Komponenten sowie deren Schwachstellen. Ein Anbieter von Lösungen für Softwarelizenzierung, Compliance, Security und Installation für Softwarehersteller und Unternehmen, hat ein neues Vulnerability Update [1] veröffentlicht. Der Report nennt die 20 Produkte mit den meisten Schwachstellen im Zeitraum von August bis Oktober 2016. Auf der Liste findet…