Das Argument für integrierte App- und API-Sicherheitsstrategien
Es ist offensichtlich, dass die App- und API-Sicherheit spezialisierter geworden ist. APIs sind nicht mehr nur URI-basierte Einstiegspunkte in eine Anwendung. APIs sind gewachsen und zu einer eigenständigen Einheit mit eigenen Sicherheitsanforderungen geworden.
Die meisten dieser Sicherheitsanforderungen beziehen sich auf die Art der API-Interaktionen. APIs müssen nämlich für jede Transaktion einzeln autorisiert werden. Dies unterscheidet sich deutlich von Apps, die die Autorisierung im Allgemeinen pro Sitzung anwenden.
Auch die Interaktionsrate ist bei APIs höher, ebenso wie eine Reihe anderer Eigenschaften, die besondere Herausforderungen für die Sicherung von APIs darstellen.
| App | API | |
|---|---|---|
| Fließendes Nachrichtenformat | HTML, JSON, XML | ProtoBuf, JSON, GraphQL, Binär, XML, Datenformate |
| Interaktionen | Statisch, seltene Veränderung | Dynamischer, häufiger Wechsel |
| Daten | Strukturiert, transaktional | Un/strukturiert, Streaming und transaktional |
| Benutzer | Menschlich | Software, Mensch |
| Benutzer-Agent | Browser, Apps | Software, Gerät, Skripte, Apps, Browser |
| Authentifizierung | Sitzungsbasiert | Transaktionsbasiert (eher ZT-ähnlich) |
| Protokollkompetenz | HTTP/S, QUIC | gRPC, WebSockets, HTTP/S, QUIC |
Ein Vergleich von Apps und APIs verdeutlicht die Unterschiede, die zu unterschiedlichen Sicherheitsanforderungen geführt haben.
Allerdings gibt es bei Apps und APIs gemeinsame Sicherheitsrisiken, die bei der Implementierung von Sicherheitslösungen berücksichtigt werden müssen. So zeigt die kürzlich aktualisierte Liste „2023 API Security Top 10“ deutlich eine Teilmenge der Risiken, die mit Anwendungen geteilt werden:
- Schwache Authentifizierungs-/Autorisierungskontrollen
- Fehlkonfiguration
- Missbrauch der Geschäftslogik (Credential Stuffing, Account Takeover)
- Serverseitige Anforderungsfälschung (SSRF)
Zusätzlich zu diesen Risiken gibt es weiterhin eine beträchtliche Zahl von Angriffen, die auf die Verfügbarkeit abzielen. Das heißt, DDoS-Angriffe kommen sowohl bei Apps als auch bei APIs häufig vor, da sie im Allgemeinen dieselben Abhängigkeiten von TCP und HTTP aufweisen, die wiederum Gegenstand einer Vielzahl von Angriffen sind, die darauf abzielen, Zugriff und Verfügbarkeit zu stören.
Ein Ansatz zur Bewältigung der Herausforderungen bei der Sicherung von Apps, APIs und der sie unterstützenden Infrastruktur besteht in der Bereitstellung mehrerer Lösungen. Bot- und Betrugsabwehr, DDoS-Schutz, App-Sicherheit und API-Sicherheit. Dadurch werden zwar sicherlich die Sicherheitsprobleme gelöst, es ergeben sich jedoch auch betriebliche Herausforderungen und viele sicherheitsrelevante Aufgaben werden komplexer, beispielsweise die Verwaltung von Richtlinienänderungen und die Reaktion auf Bedrohungen, die sowohl Apps als auch APIs betreffen. Komplexität ist nicht nur der Feind der Sicherheit, sondern auch der Feind der Geschwindigkeit.
Die Geschwindigkeit, mit der auf neu auftretende Bedrohungen reagiert werden kann, ist laut unserer jährlichen Studie ein Hauptgrund für die Einführung von Security as a Service. Jede Lösung, die einen Patch, ein Update oder die Bereitstellung einer neuen Richtlinie erfordert, um einer neu auftretenden Bedrohung entgegenzuwirken, kostet Zeit und erhöht die Möglichkeit einer Fehlkonfiguration oder eines Fehlers. Daher erhöht sich mit zunehmender Komplexität auch die zur Eindämmung einer Bedrohung benötigte Zeit – insbesondere, wenn ein Unternehmen in mehreren Umgebungen arbeitet (Hybrid-IT) und umgebungsspezifische Sicherheitslösungen nutzt. Ich berechne nicht, ob es sich dabei um einen linearen oder exponentiellen Anstieg handelt, denn ehrlich gesagt ist alles, was die Reaktionszeit auf eine unmittelbare 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, während gleichzeitig spezifische Sicherheitsrichtlinien für die Protokolle und Nutzdaten gelten, die für Apps und APIs spezifisch sind.
Dies führt zu einer integrierten Anwendungs- und API-Sicherheitsstrategie, bei der gemeinsame Funktionen mit zunehmender Granularität und Spezifität geteilt werden und näher an der App oder API angewendet werden. Bots sind schließlich Bots, und ihre Auswirkungen auf die Datenqualität, die Bereitstellungskosten und das Risikoprofil für Apps und APIs sind ein gemeinsames Anliegen. DDoS ist DDoS. Der Betrieb einer doppelt so großen Anzahl von Diensten zur Lösung desselben Problems ist in jeder Hinsicht ineffizient.
Eine integrierte Anwendungs- und API-Sicherheitsstrategie ist aus betrieblicher, finanzieller und architektonischer Sicht sinnvoll.