Microservice-, Container- und (Multi-)Cloud-gerechte Security
Um Security in komplett neu gestalteten Strukturen und Architekturen von vornherein angemessen mitzubauen, kommen neben neuen Entwicklungsmodellen wie DevOps und DevSecOps auch neue Security-Ansätze zum Einsatz – allen voran risikobasierte Authentifizierung und Continuous Adaptive Trust.
Advertorial
Digitalisierung steht für Innovation, Agilität, Flexibilität, Offenheit, Geschwindigkeit und Verfügbarkeit. In diesem Zuge erlebt die Entwicklung von Apps als Kern der Digitalisierung einen grundlegenden Wandel: Klassische Webapplikation werden immer häufiger durch APIs abgelöst, um offenere Strukturen zu schaffen und mehr Flexibilität zu erreichen. Auch der Aufbau von digitalen Ökosystemen spielt dabei eine maßgebliche Rolle. Um Security in komplett neu gestalteten Strukturen und Architekturen von vornherein angemessen mitzubauen, kommen neben neuen Entwicklungsmodellen wie DevOps und DevSecOps auch neue Security-Ansätze zum Einsatz – allen voran risikobasierte Authentifizierung und Continuous Adaptive Trust.
Um höhere Agilität, Verfügbarkeit und Dynamik in den Digitalisierungsbestrebungen der Unternehmen zu gewinnen, vollzieht sich ein starker Wandel der IT-Infrastruktur – weg von On-Premises hin zu hybriden Cloud-Umgebungen mit modernen Container-Technologien und Microservices. DevOps ist hier eines der großen Schlagworte. In Verbindung mit dem Continuous-Integration- und Deployment-Modell (CI/CD) lassen sich zusätzliche Vorteile realisieren, um schnell mit neuen Entwicklungen und Services auf den Markt zu kommen. Schließlich ist die Digitalisierung ein Wettlauf, bei dem es häufig darum geht, als Erstes mit neuen Diensten zu glänzen.
Schnelligkeit ist aber nur die halbe Miete. Apps müssen auch sicher sein. Und hier haben Cloud-Umgebungen mit ihren neuen Technologien einiges grundlegend verändert: Um Applikationen, APIs und Microservices bereitzustellen, werden Container-Umgebungen eingeführt und zumeist von Kubernetes oder anderen Systemen zur Verwaltung von Containeranwendungen gemanagt. All diese neuen Ansätze erfordern aber auch eine Erneuerung der Applikationssicherheit und des Zugriffsmanagements.
Was diese Veränderungen für die Security bedeuten
Webapplikationen und APIs sind die beliebtesten Angriffsziele für Hacker. Ihre Popularität unter den Angreifern verdanken sie vor allem der Tatsache, dass sie besonders exponiert sind und weltweit in sehr hoher Zahl verwendet werden – nicht zuletzt auch im DACH-Raum (Deutschland, Österreich, Schweiz). So haben laut einer im deutschsprachigen Raum durchgeführten IDG-Studie [1] 83 Prozent der Unternehmen mehr als zehn Webapplikationen im Einsatz. Zwei Drittel der befragten Unternehmen hatten dabei mehr als 20 schutzbedürftige Apps im Einsatz.
Allein in den neuen Entwicklungsprozessen (DevOps, DevSecOps) lässt sich der geforderte Schutz der Apps nicht realisieren, denn weniger als die Hälfte (44 Prozent) der Unter-nehmen hat überhaupt einen Einfluss auf deren Entwicklung: Der größere Teil der Web-Apps sind „ältere Erbstücke“, welche die Unternehmen nicht mehr anfassen wollen, Open-Source-Web-Apps unter Copyleft-Lizenz, bei welchen die Entwicklung nicht oder kaum beeinflusst werden kann, oder proprietäre Web-Apps, bei welchen die Entwicklung grundsätzlich nicht beeinflusst werden kann.
Für den Schutz der Web-Apps sind also eigenständige Se-curity-Lösungen nötig, um gerade bei Zero-Day-Angriffen schnell mit Virtual Patching und Web Application and API Protection (WAAP) kontern zu können. Virtuelles Patching wird zunehmend als robuste Alternative zum Hersteller-Patching genutzt. Unternehmen können damit Schwachstellen in Anwendungen schnell beheben, Sicherheitsrichtlinien kurzfristig umsetzen und so ihre Anfälligkeit für Angriffe heruntersetzen. Virtuelles Patching hilft Unternehmen, Angriffe abzuwehren, indem es jederzeit vor bekannten und unbekannten Schwachstellen, einschließlich Zero-Day-Exploits, schützt. Im Gegensatz zu einer herkömmlichen Firewall ist ein WAAP ein hoch spezialisiertes Sicherheitstool, das speziell für den Schutz von Webanwendungen und APIs entwickelt wurde. Eine WAAP befindet sich am äußeren Rand eines Netzwerks, vor der öffentlichen Seite einer Webanwendung, und analysiert den eingehenden Datenverkehr. Ein WAAP konzentriert sich nur auf die Anwendungsschicht.
Der große Vorteil von Virtual Patching und WAAP: Sicherheitslücken werden zentral und vor allem schnell beseitigt – ohne dass sofort die gesamte Web-App geprüft und umgeschrieben werden muss, getreu dem Motto „Secure now, fix later“. Eine klassische Web Application Firewall (WAF) reicht dafür heute nicht mehr: Auch APIs und Microservices müssen geschützt werden und das nicht nur On-premises, sondern auch in verteilten Cloud-Umgebungen.
Security in die Entwicklungsprozesse einbinden
Nutzer, ob Mitarbeiter, Lieferanten, Kunden etc., greifen auf Hunderte Micro Services zu, die über unterschiedliche Standorte verteilt sind. Sie alle kommen mit verschiedenen Rollen ins Netzwerk, während Software gerade entwickelt, ausgerollt oder schon produktiv geschaltet ist. Die IT-Landschaft ändert sich also ständig. In einem solch dynamischen Szenario ist es nicht zielführend, am Ende noch kurz die Security anzuschauen. Es ist wichtig, dass auch Security agil wird. Agile Sicherheit bedeutet, dass es klare Prozesse gibt. Das wiederum bedeutet beispielsweise, dass standardmäßig automatisierte Tests durchgeführt werden. Ein weiterer wichtiger Aspekt von Agile Security ist Security by Design: Entscheidend ist, Security bereits beim Design zu berücksichtigen, kontinuierlich weiterzuentwickeln und damit ein Shift-Left der Security zu vollziehen. Die gesamte Infrastruktur muss regelmäßig nach Schwach-stellen durchsucht werden. Das vielleicht Wichtigste ist jedoch, schnell auf Fehler, neue Bedrohungen und neue Erkenntnisse reagieren zu können. In einem agilen Unternehmen arbeiten Entwicklung und Betrieb als ein Team zusammen (DevOps). Wo – wie dringend zu empfehlen – auch agile Security integriert ist, handelt es sich um ein DevSecOps-Team. Hier wird die Sicherheit bereits in der Entwicklung integriert. Microgateways können als eine Art kleine WAAP direkt den jeweiligen Container absichern und schon während der Entwicklung und des Testens eingesetzt werden. Die anwendungsspezifischen Sicherheitsregeln werden dabei vom Entwickler definiert.
Warum die Identität zunehmend in den Mittelpunkt rückt
Durch die Herausforderungen von diesen stark verteilten Systemen mit Multicloud-Ansätzen in heterogenen Architekturen wurde auch Zero Trust zur neuen Pflicht: Damit rückt die Identität stärker in den Mittelpunkt der Application- und API-Security. Denn wenn es um Sicherheitsentscheidungen geht, steht fast immer die Identität im Zentrum. Der Satz „Identität ist der neue Perimeter“ wurde zum neuen Security-Paradigma.
Identität schafft Vertrauen, auch in der digitalen Welt. Viele Security-Entscheidungen setzen voraus, dass der Benutzer vertrauenswürdig ist und seine Identität mittels Authentifizierung bestätigt ist. Um beispielsweise zu entscheiden, welche Berechtigungen ein Benutzer erhält, muss zuerst seine Identität geklärt werden. Langwierige und komplexe Authentifizierungsprozesse sind dabei jedoch kontraproduktiv. Die Authentifizierung muss vielmehr benutzerfreundlich in etablierte Prozesse integriert werden. Wie die Praxis zeigt, werden Nutzer ansonsten sehr kreativ, zu hohe Sicherheitsanforderungen zu umschiffen. Zur Lösung dieser Spannung – Sicherheit versus Benutzerfreundlichkeit – haben sich risikobasierte Authentifizierungsverfahren bewährt.
Risikobasierte Authentifizierung
Vertrauen ist nicht binär: Zwischen blindem Vertrauen und totalem Misstrauen gibt es beliebig viele Zwischenstufen. Welches Vertrauensniveau für einen digitalen Zugriff effektiv notwendig ist, hängt von der Risiko-Empfindlichkeit ab. Der Zugriff auf besonders sensible Daten setzt ein höheres Vertrauen voraus als der Download eines öffentlichen Dokuments von der Webseite. Bei der risikobasierten Authentifizierung (RBA) wird das Vertrauensniveau in die Entscheidung über die Häufigkeit und Stärke des Logins mit einbezogen.
Statt also bei jedem Login einen zweiten oder gar dritten Faktor vom Benutzer einzufordern, wird der Kontext eines Zugriffs analysiert und mit vergangenen Sitzungen desselben Nutzers verglichen. Dabei wird berücksichtigt, in welchem Netz sich ein Benutzer befindet, von wo er sich einloggt oder welchen Browser er nutzt. Wenn sich zum Beispiel ein Benutzer von seinem gewohnten Arbeitsplatz im Intranet oder aus seinem Homeoffice anmelden möchte, kann auf den zweiten Faktor verzichtet werden. Mittels der Remember-Me-Funktion wird zudem die Benutzeridentität im Browser hinterlegt und bei künftigen Anmeldungen wiederverwendet.
Continuous Adaptive Trust
Vertrauen ist allerdings nicht konstant über die Zeit. Auch ein Vertrauensverlust zwischen zwei Menschen kommt oft schleichend. Das Vertrauen in eine Person kann sich ändern, wenn sich diese unerwartet oder verdächtig verhält. Auch in der digitalen Welt sollte das Vertrauen nicht nur beim Log-in beurteilt werden. Stattdessen muss das Verhalten eines Benutzers analysiert und das Vertrauen bei Bedarf angepasst werden. So wird bei längerer Inaktivität oder unüblichem Verhalten das Vertrauensniveau reduziert. Falls es unter die Schwelle fällt, die für die aktuelle Anwendung festgelegt wurde, muss das Vertrauen wieder erhöht werden. Dazu braucht es eine vertrauensbildende Aktion wie einen erneuten Log-in mit zweitem Faktor oder das Lösen eines Captchas. Ein solcher „Vertrauensbeweis“ kann auch verlangt werden, wenn eine kritische Funktion aufgerufen wird. Ein Beispiel dafür ist die Transaktionsbestätigung bei der Zahlung an einen neuen Empfänger.
Continuous Adaptive Trust (CAT) analysiert das Vertrauensniveau kontinuierlich und passt es bei Bedarf an. Weil die Sicherheitsmechanismen tendenziell im Hintergrund bleiben, wird der Benutzerkomfort nicht merklich beeinträchtigt. Da-durch entsteht eine Win-win-Situation: Wenn sich ein Kunde sicher fühlt, aber nicht durch mühsame Sicherheitsmaßnahmen belästigt, dann schafft das ebenfalls Vertrauen — dieses Mal von der anderen Seite. Mit Continuous Adaptive Trust kann die Identität kontinuierlich und zeitabhängig auf das gerade erforderlichen Risikoniveau geprüft werden.
Resumée
Die Welt der Applikationssicherheit wird immer komplexer. Unternehmen müssen für einen umfassenden Schutz ihrer Apps eine Vielzahl unterschiedlicher Hersteller für WAF, API Security (WAAP), Security in Container-Umgebungen, Threat Intelligence, Access Management und starke Authentifizierung konzertieren. Dies ist mühsam, teuer und fehler-anfällig. Die gewonnene Agilität von DevOps-Prozessen geht damit schnell verloren oder die Security bleibt auf der Strecke. Lösungen, welche die einzelnen Domänen der Applikationssicherheit miteinander vereinen und verbinden können, bieten hier große Vorteile und machen Ansätze wie Continuous Adaptive Trust erst möglich. Die Komplexität wird vereinfacht und ein vollständiger Ansatz der Security wird ermöglicht.
Autor: Gernot Bekk-Huber, Senior Product Marketing Manager bei Ergon
Quellen: [1] IDG Studie Application- und API-Security im Containerumfeld 2022 https://www.airlock.com/application-und-api-security-im-container-umfeld-2022