wladimir1804 - stock.adobe.com
Die Identität während des Betriebs fortlaufend prüfen
Flexible Strukturen erfordern neue Security-Ansätze. Dabei wird etwa die Identität permanent auf den Prüfstand gestellt und bei Bedarf dynamisch eine Bestätigung angefragt.
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 Container–Anwendungen gemanagt. All diese neuen Ansätze erfordern aber auch eine Erneuerung der Applikationssicherheit und des Zugriffsmanagements.
Web Apps und APIs als Angriffsziele
Webapplikationen und APIs sind beliebte Ziele für Angreifer. 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 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 Unternehmen 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 Security-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 hochspezialisiertes 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 DevOps einbinden
Nutzer, ob Mitarbeiter, Lieferenten, Kunden etc. greifen auf Hunderte Microservices zu, die über unterschiedliche Standorte verteilt sind. Sie alle kommen mit verschiedenen Rollen ins Netzwerk, während Software gerade entwickelt oder 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 anschauen. 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 Schwachstellen 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 dem Testen eingesetzt werden. Die anwendungsspezifischen Sicherheitsregeln werden dabei vom Entwickler definiert.
Die Identität rückt in den Mittelpunkt
Durch die Herausforderungen von diesen stark verteilten Systemen mit Multi Cloud-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 sind und ihre Identität mittels Authentifizierung bestätigt ist.“
Gernot Bekk-Huber, Ergon Informatik
Identität schafft Vertrauen, auch in der digitalen Welt. Viele Security-Entscheidungen setzen voraus, dass der Benutzer vertrauenswürdig sind und ihre 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 Risikoempfindlichkeit ab. Der Zugriff auf besonders sensible Daten setzt ein höheres Vertrauen voraus als der Download eines öffentlichen Dokuments von der Webseite. Bei der Risiko-basierten 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 Home-Office 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.
Das Konzept des 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 Login 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 Login 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. Dadurch 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 — diesmal von der anderen Seite. Mit Continuous Adaptive Trust kann die Identität kontinuierlich und zeitabhängig auf das gerade erforderlichen Risikoniveau geprüft werden.
Fazit
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 fehleranfällig. Die gewonnene Agilität von DevOps Prozessen geht damit schnell verloren, oder die Security bleibt auf der Strecke. Lösungen, die 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.
Über den Autor:
Gernot Bekk-Huber ist Marketingmanager bei der Ergon Informatik AG.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
