An Statistiken zur (Un-)Sicherheit von APIs mangelt es nicht. Eine oberflächliche Suche im Internet liefert Ihnen so ziemlich jede gewünschte Sichtweise auf das Thema. Es genügt zu sagen, dass (a) API-Angriffe zunehmen und (b) einige dieser Angriffe erfolgreich sind.
Häufig wird auch darauf hingewiesen, dass Unternehmen bereits Schwierigkeiten damit haben, überhaupt alle in ihrer Organisation verborgenen APIs zu finden. Das liegt nicht nur daran, dass diese APIs über Core-, Cloud- und Edge-Umgebungen verteilt sind. Vielmehr gibt es abgesehen von der bekannten OpenAPI Specification (OAS) keine echten „Standards“, auf die man sich bei der Definition – geschweige denn bei der Suche – von APIs stützen könnte.
Das bedeutet nicht, dass wir sie brauchen. Schließlich hatten wir SOAP, WSDL und UDDI. Und nun ja: Auch wenn sie noch immer genutzt werden und XML weiterhin als Datenformat dient, ist der Großteil der Welt inzwischen zu REST, JSON, GraphQL und gRPC übergegangen.
Selbst wenn wir Standards hätten, würde das nichts daran ändern, dass APIs schwer abzusichern sind.
Das liegt daran, dass der Begriff API ein Oberbegriff ist. Die OpenTelemetry-API ist beispielsweise einfach eine Möglichkeit auszudrücken: „Wir stellen Entwicklern die Funktionen von OpenTelemetry zur Verfügung.“ Es gibt nicht etwa eine Sicherheitsrichtlinie, die „die“ OpenTelemetry-API abdecken kann. Das wäre ideal und würde vieles erheblich vereinfachen. Doch so ist es nicht. Stattdessen gibt es Sicherheitsrichtlinien, die die Endpunkte der OpenTelemetry-API abdecken.
Sehen wir uns das einmal genauer an, ja?
APIs und Endpunkte
Nehmen wir für unser Beispiel die OpenAI-API, denn derzeit sind alle ganz aus dem Häuschen wegen generativer KI.
Als Erstes werden Sie feststellen, dass es zwar nur „eine“ API gibt, diese aber über viele Endpunkte verfügt. Wie viele? Diese Zahl ändert sich jedes Mal, wenn neue Funktionen hinzukommen.
Hier ist eine (nicht vollständige) Liste:
- https://api.openai.com/v1/chat/completions
- https://api.openai.com/v1/audio/speech
- https://api.openai.com/v1/audio/transcriptions
- https://api.openai.com/v1/audio/translations
- https://api.openai.com/v1/embeddings
- https://api.openai.com/v1/fine_tuning/jobs
- https://api.openai.com/v1/files
Multimodale generative KI erweitert die Liste der Inhaltstypen um Medien – Audio und Video –, führt jedoch auch neue Endpunkte für die Verarbeitung von Anfragen ein. Zusätzliche Funktionen, wie etwa der Einsatz von Tools, können die Anzahl der Endpunkte ebenfalls erhöhen. Jeder Fortschritt – jede neue Funktion, die uns begeistert – fügt der API in der Regel einen weiteren Endpunkt hinzu.
Außerdem fällt Ihnen bei diesen Endpunkten sicherlich die Angabe „v1“ auf. Das bedeutet, dass bei der Veröffentlichung von v2 ein weiterer Satz von Sicherheitsrichtlinien erforderlich sein wird, um diese Endpunkte abzudecken. Einige dieser Richtlinien müssen zudem an die jeweiligen Änderungen am eigentlichen Endpunkt angepasst werden.
Dies gilt auch für den IT-Stack, in dem die Automatisierung über Geräte-APIs erfolgt. Die Anzahl der Endpunkte hängt weitgehend von Ihrer Umgebung ab. Je mehr Geräte Sie verwalten, desto mehr Endpunkte müssen Sie verwalten und absichern. Und vergessen wir nicht, dass keine zwei Geräte dieselbe API verwenden. Das wäre ja auch verrückt, oder? Fast so, als würden sich zwei Cloud-Anbieter darauf einigen, dieselbe API zu verwenden. Das ist wahrscheinlich der Grund, warum „Komplexität“ nach wie vor am häufigsten als Grund dafür genannt wird, eine Vielzahl betrieblicher Aufgaben nicht zu automatisieren. Zu viele Tools und APIs erschweren die Automatisierung und machen die Absicherung noch schwieriger.
Aber die API-Sicherheit muss all diese Endpunkte abdecken, denn über sie verschaffen sich Angreifer Zugang. Und jeder Endpunkt erfordert andere Parameter, die als JSON-Objekte (oder XML-, GraphQL- bzw. <insert format here>-Objekte) in die Nutzlast einfließen. Es müssen Grenzen dafür festgelegt werden, was die einzelnen Parameter enthalten dürfen: Sind alphanumerische Zeichen zulässig? Bestimmte Zeichen? Ein Wertebereich? Wie lang darf der Inhalt sein? Welche Zeichen sind nicht zulässig? All diese Informationen werden in eine Richtlinie übertragen, die Vorgaben für den Inhalt durchsetzt und so verhindert, dass sich Angriffe unbemerkt einschleichen.
Allein die Erstellung einer Richtlinie für die Open AI API wird einige Zeit in Anspruch nehmen. Und dabei handelt es sich nur um eine einzige API. Laut unserer demnächst erscheinenden Studie für 2024 verfügen die meisten Unternehmen über durchschnittlich 442,8 APIs, und bei sehr großen Unternehmen steigt diese Zahl sprunghaft an. Wenn man bedenkt, wie viele Endpunkte – und Versionen von Endpunkten – das bedeuten kann, wird sehr schnell klar, warum API-Sicherheit so verdammt schwierig ist.
Und warum Angreifer damit so erfolgreich sind, dass sie diese weiterhin ins Visier nehmen.
Ü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.