Es ist offensichtlich, dass die Sicherheit von Apps und APIs zunehmend spezialisierter geworden ist. APIs sind längst nicht mehr nur URI-basierte Zugangspunkte zu einer Anwendung. Sie haben sich weiterentwickelt und sind zu eigenständigen Einheiten mit eigenen Sicherheitsanforderungen geworden.
Die meisten dieser Sicherheitsanforderungen ergeben sich aus der Art der API-Interaktionen. So müssen APIs für jede einzelne Transaktion autorisiert werden. Dies unterscheidet sich deutlich von Apps, bei denen die Autorisierung in der Regel sitzungsbezogen erfolgt.
Auch die Interaktionsrate ist bei APIs höher. Hinzu kommen eine Reihe weiterer Merkmale, die besondere Herausforderungen für die Absicherung von APIs darstellen.
App APIBeherrschung von Nachrichtenformaten HTML, JSON, XML ProtoBuf, JSON, GraphQL, Binärformate, XML, DatenformateInteraktionen Statisch, seltene Änderungen Dynamisch, häufige ÄnderungenDaten Strukturiert, transaktionsbasiert Un-/strukturiert, Streaming und transaktionsbasiertBenutzer Mensch Software, MenschUser-Agent Browser, Apps Software, Geräte, Skripte, Apps, BrowserAuthentifizierung Sitzungsbasiert Transaktionsbasiert (eher wie ZT)Protokollkenntnisse HTTP/S, QUIC gRPC, WebSockets, HTTP/S, QUIC
Ein Vergleich von Apps und APIs verdeutlicht Unterschiede, die zu unterschiedlichen Sicherheitsanforderungen geführt haben.
Allerdings gibt es Sicherheitsrisiken, die sowohl Apps als auch APIs betreffen und bei der Implementierung von Sicherheitslösungen berücksichtigt werden sollten. So zeigen beispielsweise die kürzlich aktualisierten 2023 API Security Top 10 deutlich eine Reihe von Risiken auf, die auch Anwendungen betreffen:
- Schwache Kontrollen für Authentifizierung und Autorisierung
- Fehlkonfiguration
- Missbrauch der Geschäftslogik (Credential Stuffing, Kontoübernahme)
- Server-Side Request Forgery (SSRF)
Zusätzlich zu diesen Risiken gibt es weiterhin eine beträchtliche Anzahl von Angriffen, die auf die Verfügbarkeit abzielen. Dabei handelt es sich um DDoS-Angriffe, von denen sowohl Apps als auch APIs betroffen sind, da sie in der Regel gleichermaßen von TCP und HTTP abhängig sind. Beide Protokolle sind einer Vielzahl von Angriffen ausgesetzt, die darauf abzielen, den Zugriff und die Verfügbarkeit zu beeinträchtigen.
Ein Ansatz zur Bewältigung der Herausforderungen bei der Absicherung von Apps, APIs und der zugrunde liegenden Infrastruktur besteht darin, mehrere Lösungen einzusetzen: Schutz vor Bots und Betrug, DDoS-Schutz sowie App- und API-Sicherheit. Damit lassen sich zwar die Sicherheitsherausforderungen bewältigen, doch zugleich entstehen betriebliche Herausforderungen, und viele sicherheitsrelevante Aufgaben werden komplexer – etwa 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 Geschwindigkeit.
Laut unserer jährlichen Studie ist die Geschwindigkeit, mit der auf neu auftretende Bedrohungen reagiert werden kann, einer der wichtigsten Grü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 neu auftretenden Bedrohung erfordert, kostet zusätzliche Zeit und erhöht das Risiko einer Fehlkonfiguration oder eines Fehlers. Mit zunehmender Komplexität steigt somit auch die Zeit, die zur Abwehr einer Bedrohung benötigt wird – insbesondere, wenn ein Unternehmen in mehreren Umgebungen (Hybrid-IT) arbeitet und für jede Umgebung eigene Sicherheitslösungen einsetzt. Ich werde nicht ausrechnen, ob es sich dabei um einen linearen oder exponentiellen Anstieg handelt, denn ganz ehrlich: Alles, was die Reaktionszeit auf eine unmittelbar bevorstehende Bedrohung verlängert, ist keine gute Sache.
Daher ist es besser, Lösungen zu kombinieren und so die Betriebs- und Sicherheitsverwaltung für Funktionen zur Abwehr von Bedrohungen gemeinsam zu nutzen, während spezifische Sicherheitsrichtlinien auf die besonderen Protokolle und Nutzdaten von Apps und APIs zugeschnitten werden können.
Dies führt zu einer integrierten Sicherheitsstrategie für Anwendungen und APIs, bei der gemeinsame Funktionen zentral genutzt werden, während mit zunehmender Nähe zur Anwendung oder API immer granularere und spezifischere Maßnahmen zum Einsatz kommen. Bots bleiben schließlich Bots, und ihre Auswirkungen auf die Datenqualität, die Bereitstellungskosten und das Risikoprofil von Anwendungen und APIs sind ein gemeinsames Problem. DDoS bleibt DDoS. Für dasselbe Problem doppelt so viele Dienste zu betreiben, ist in jeder Hinsicht ineffizient.
Eine integrierte Sicherheitsstrategie für Anwendungen und APIs ist aus betrieblicher, finanzieller und architektonischer Sicht sinnvoll.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.