Das Argument für integrierte Anwendungs- und API-Sicherheitsstrategien
Es ist offensichtlich, dass die Sicherheit von Anwendungen und APIs spezieller geworden ist. APIs sind nicht mehr nur URI-basierte Einstiegspunkte in eine Anwendung. APIs sind gewachsen und haben sich zu einer eigenständigen Einheit mit eigenen Sicherheitsanforderungen entwickelt.
Die meisten dieser Sicherheitsanforderungen hängen mit der Art der API-Interaktionen zusammen. APIs müssen nämlich auf Transaktionsbasis autorisiert werden. Dies unterscheidet sich deutlich von Anwendungen, bei denen die Autorisierung in der Regel auf Sitzungsbasis erfolgt.
Auch die Interaktionsrate ist bei APIs höher, ebenso wie eine Reihe anderer Merkmale, die eine besondere Herausforderung für die Sicherung von APIs darstellen.
| Anwendung | API | |
|---|---|---|
| Flüssiges Nachrichtenformat | HTML, JSON, XML | ProtoBuf, JSON, GraphQL, binär, XML, Datenformate |
| Interaktionen | Statische, seltene Änderung | Dynamische, häufige Änderung |
| Daten | Strukturiert, transaktional | Un-/strukturiert, Streaming und transaktional |
| Benutzer | Mensch | Software, Mensch |
| Benutzer-Agent | Browser, Anwendungen | Software, Geräte, Skripte, Anwendungen, Browser |
| Authentifizierung | Sitzungsbasiert | Transaktionsbasiert (eher ZT-ähnlich) |
| Flüssiges Protokoll | HTTP/S, QUIC | gRPC, WebSockets, HTTP/S, QUIC |
Ein Vergleich von Anwendungen und APIs verdeutlicht die Unterschiede, die zu einem Auseinanderdriften der Sicherheitsanforderungen geführt haben.
Dennoch gibt es Sicherheitsrisiken, die sowohl für Anwendungen als auch für APIs gelten und die bei der Implementierung von Sicherheitslösungen berücksichtigt werden müssen. Die kürzlich aktualisierten Top 10 der API-Sicherheit 2023 zeigen zum Beispiel deutlich eine Teilmenge von Risiken, die auch für Anwendungen gelten:
- Schwache Authentifizierungs-/Autorisierungskontrollen
- Fehlkonfiguration
- Missbräuchliche Nutzung der Geschäftslogik (Credential Stuffing, Account Takeover)
- Serverseitige Anfragenfälschung (SSRF, Server-Side Request Forgery)
Zusätzlich zu diesen Risiken gibt es nach wie vor eine beträchtliche Anzahl von Angriffen, die auf die Verfügbarkeit abzielen, d. h. DDoS-Angriffe, die sowohl auf Anwendungen als auch auf APIs abzielen, da sie im Allgemeinen dieselben Abhängigkeiten von TCP und HTTP haben, die beide einer Vielzahl von Angriffen ausgesetzt sind, die darauf abzielen, den Zugang und die Verfügbarkeit zu stören.
Ein Ansatz zur Bewältigung der Herausforderungen bei der Sicherung von Anwendungen, APIs und der sie unterstützenden Infrastruktur besteht darin, mehrere Lösungen einzusetzen: Bot- und Betrugsabwehr, DDoS-Schutz, App-Sicherheit und API-Sicherheit. Damit werden zwar die Sicherheitsherausforderungen angegangen, aber es entstehen auch betriebliche Herausforderungen und viele sicherheitsrelevante Aufgaben wie die Verwaltung von Änderungen der Sicherheitsrichtlinien und die Reaktion auf Bedrohungen, die sich sowohl auf Anwendungen als auch auf APIs auswirken, werden dadurch komplexer. Komplexität ist nicht nur der Feind der Sicherheit, sondern auch der Feind der Geschwindigkeit.
Die Geschwindigkeit, mit der auf neue Bedrohungen reagiert werden kann, ist laut unserer jährlichen Untersuchung einer der Hauptgründe für die Einführung von Security as a Service. Jede Lösung, die einen Patch, ein Update oder die Implementierung einer neuen Richtlinie zur Abwehr einer neuen Bedrohung erfordert, kostet Zeit und erhöht die Wahrscheinlichkeit einer Fehlkonfiguration oder eines Fehlers. Die Zeit zur Abwehr einer Bedrohung nimmt also mit der Komplexität zu – vor allem, wenn ein Unternehmen in mehreren Umgebungen arbeitet (hybride IT) und Sicherheitslösungen für jede Umgebung einsetzt. Ich rechne nicht nach, ob es sich dabei um einen linearen oder exponentiellen Anstieg handelt, denn ehrlich gesagt ist alles, was die Zeit zur Reaktion auf eine drohende Bedrohung verlängert, keine gute Sache.
Deshalb ist es besser, Lösungen zu kombinieren und so das Betriebs- und Sicherheitsmanagement für Funktionen zur Bekämpfung von Bedrohungen gemeinsam zu nutzen und gleichzeitig spezifische Sicherheitsrichtlinien für die Protokolle und Nutzdaten von Anwendungen und APIs zu ermöglichen.
Dies führt zu einer integrierten Anwendungs- und API-Sicherheitsstrategie, bei der gemeinsame Funktionen mit zunehmender Granularität und Spezifität näher an der Anwendung oder API angewandt werden. Bots sind schließlich Bots, und ihre Auswirkungen auf die Datenqualität, die Kosten für die Bereitstellung und das Risikoprofil von Anwendungen und APIs sind ein gemeinsames Anliegen. DDoS ist DDoS. Der Betrieb von doppelt so vielen Diensten zur Lösung desselben Problems ist in jeder Hinsicht ineffizient.
Eine integrierte Strategie für Anwendungs- und API-Sicherheit ist betrieblich, finanziell und architektonisch sehr sinnvoll.