- Cloudflare hat die Entwicklung von „Firewall für KI“ (
Firewall for AI) angekündigt, einer neuen Schutzschicht, die vor Large Language Models (LLMs) platziert wird, um Missbrauch zu erkennen
- Der Einsatz von LLMs als mit dem Internet verbundene Anwendungen führt neue Schwachstellen ein, die von böswilligen Akteuren ausgenutzt werden können
- Zusätzlich zu den Schwachstellen, die bestehende Web- und API-Anwendungen betreffen, entstehen durch die Funktionsweise von LLMs neue Bedrohungen
- Die Firewall für KI ist eine fortschrittliche Web Application Firewall (WAF), die speziell auf Anwendungen mit LLMs zugeschnitten ist, und umfasst ein Toolset zur Erkennung von Schwachstellen sowie zur Bereitstellung von Transparenz für Modellbesitzer
Warum unterscheiden sich LLMs von traditionellen Anwendungen?
- Betrachtet man LLMs als internetverbundene Anwendungen, gibt es im Vergleich zu traditionellen Web-Apps zwei wesentliche Unterschiede
- Erstens unterscheidet sich die Art und Weise, wie Nutzer mit dem Produkt interagieren. Traditionelle Apps sind deterministisch, während LLMs nicht deterministisch sind und auf natürlicher Sprache basieren
- Zweitens unterscheidet sich die Art und Weise, wie die Control Plane der Anwendung mit Daten interagiert. In traditionellen Anwendungen sind Control Plane (Code) und Data Plane (Datenbank) klar getrennt. Bei LLMs werden Trainingsdaten jedoch Teil des Modells selbst, wodurch sich die Datenweitergabe über Nutzer-Prompts nur schwer steuern lässt
OWASP-LLM-Schwachstellen
- Die OWASP Foundation hat die Top 10 Schwachstellen für LLMs veröffentlicht und bietet damit ein nützliches Framework, um über den Schutz von Sprachmodellen nachzudenken
- Einige Bedrohungen ähneln den OWASP Top 10 für Webanwendungen, es gibt jedoch auch Bedrohungen, die speziell für Sprachmodelle gelten
Bereitstellung von LLMs
- Die Risiken von LLMs unterscheiden sich je nach Bereitstellungsmodell. Derzeit gibt es drei wesentliche Ansätze für die Bereitstellung
- Internal LLM (intern): Unternehmen entwickeln LLMs, um Mitarbeitende bei der täglichen Arbeit zu unterstützen. Diese gelten als Unternehmenswerte und dürfen nicht von externen Personen genutzt werden. Beispiele sind ein KI-Copilot, der auf Vertriebsdaten und Kundeninteraktionen trainiert wurde, um personalisierte Vorschläge zu erstellen, oder ein LLM, das auf einer internen Wissensbasis trainiert wurde, die Ingenieure abfragen können
- Public LLM (öffentlich): Ein LLM, auf das auch außerhalb des Unternehmens zugegriffen werden kann. Solche Lösungen bieten oft eine kostenlose Version, die von allen genutzt werden kann, und sind häufig mit allgemeinem oder öffentlichem Wissen trainiert. Beispiele sind OpenAIs GPT oder Anthropics Claude
- Product LLM (Produkt): Aus Sicht eines Unternehmens kann ein LLM Teil eines Produkts oder einer Dienstleistung sein, die Kunden angeboten wird. In der Regel handelt es sich um eine selbst gehostete, angepasste Lösung, die als Werkzeug zur Interaktion mit Unternehmensressourcen genutzt werden kann. Beispiele sind ein Kundenservice-Chatbot oder der Cloudflare AI Assistant
- In allen Szenarien müssen Modelle vor Missbrauch geschützt, im Modell gespeicherte proprietäre Daten gesichert und Nutzer vor Fehlinformationen oder unangemessenen Inhalten bewahrt werden
Firewall für KI
- Cloudflares Firewall für KI wird wie eine traditionelle WAF bereitgestellt und scannt API-Anfragen, die sämtliche LLM-Prompts enthalten, um mögliche Angriffsmuster und Signaturen zu erkennen
- Sie kann vor Modellen eingesetzt werden, die auf der Cloudflare-Workers-AI-Plattform gehostet werden, ebenso wie vor Modellen auf Infrastruktur von Drittanbietern, und kann zusammen mit Cloudflare AI Gateway verwendet werden
Schutz vor Volumenangriffen
- Eine der von OWASP aufgeführten Bedrohungen ist Model Denial of Service
- Wie bei traditionellen Anwendungen verbrauchen DoS-Angriffe übermäßig viele Ressourcen, wodurch sich die Servicequalität verschlechtert oder die Betriebskosten des Modells steigen
- Dieses Risiko lässt sich mindern, indem Rate-Limiting-Richtlinien eingeführt werden, die die Anfragerate pro einzelner Sitzung steuern
Erkennung sensibler Informationen
- Für sensible Informationen gibt es zwei Anwendungsfälle: wenn man selbst Modell und Daten besitzt, und wenn man verhindern möchte, dass Nutzer Daten an ein öffentliches LLM senden
- Die von OWASP definierte Offenlegung sensibler Informationen tritt auf, wenn ein LLM vertrauliche Daten in Antworten unbeabsichtigt preisgibt, was zu unbefugtem Datenzugriff, Datenschutzverletzungen und Sicherheitsvorfällen führen kann
Verhinderung von Modellmissbrauch
- Modellmissbrauch umfasst verschiedene Ansätze, etwa „Prompt Injection“ oder das Absenden von Anfragen, um Halluzinationen auszulösen oder ungenaue, anstößige, unangemessene oder themenfremde Antworten zu erzeugen
- Prompt Injection ist der Versuch, ein Sprachmodell durch speziell konstruierte Eingaben zu manipulieren und so unbeabsichtigte Antworten des LLM auszulösen
Verwendung der Firewall für KI
- Unternehmenskunden, die „Application Security Advanced“ verwenden, können Advanced Rate Limiting und Sensitive Data Detection sofort nutzen
- Die Prompt-Validierungsfunktionen der Firewall für KI befinden sich derzeit in Entwicklung; eine Beta-Version soll in den kommenden Monaten für Workers-AI-Nutzer veröffentlicht werden
1 Kommentare
Hacker-News-Kommentare
Es wird zwar behauptet, Prompt Injection und Jailbreaking seien unterschiedlich, aber in dieser Debatte scheint man bereits verloren zu haben. Laut dem Cloudflare-Artikel bedeutet Model Abuse eine breitere Kategorie von Missbrauch, die auch Ansätze wie Prompt Injection umfasst. Prompt Injection tritt auf, wenn ein Entwickler den definierten Prompt mit nicht vertrauenswürdiger Benutzereingabe verknüpft. Wenn es keine Verknüpfung von vertrauenswürdiger und nicht vertrauenswürdiger Eingabe gibt, ist es keine Prompt Injection. Diese Unterscheidung ist wichtig, und mit Modellen, die auf gewöhnliche Jailbreaking-Angriffe trainiert wurden, wird sich das nur schwer erkennen lassen.
WAFs (Web Application Firewalls) waren eine Notlösung für Webservices, die Sicherheitsteams weder kontrollieren noch verstehen konnten. Wegen Performance-Problemen und der Schwierigkeit, sie so abzustimmen, dass bösartiger Traffic effektiv blockiert wird, sind sie aus der Gunst gefallen. Ein WAF-basierter Ansatz ist ein Eingeständnis von Unwissenheit und zeigt, wo die Schwachstelle liegt; der Wechsel zu Modellen ist noch unbewiesen und widerspricht Ideen wie dem reaktiven Selbstschutz der Anwendung.
Ich möchte Schutz davor, dass meine Website zum Zweck des AI-Trainings gescraped wird. Es fühlt sich schon jetzt wie ein verlorener Kampf an, aber ich habe festgestellt, dass Menschen, denen Datenschutz wichtig ist, ähnlich denken.
Wie bei den meisten Produkten von Cloudflare gilt auch hier: Je mehr Kunden es nutzen, desto nützlicher wird es und desto weniger manueller Aufwand ist pro Kunde nötig. Der Wert von Cloudflare liegt nicht in Konfiguration und Garantien, sondern in der nahezu Echtzeit-Sichtbarkeit auf Angriffe, die alle anderen gerade sehen, und in deren Verpackung.
Das Produkt wirkt wie eine sehr gute Idee. Wenn es so einfach ist, wie eine Firewall hinzuzufügen und einzuschalten, wird es leichter Aufmerksamkeit und Akzeptanz bekommen als andere Guardrail-Produkte. Ich frage mich, wie nützlich eine allgemeine LLM-Firewall sein kann und wie viel Anpassung je nach Modell und Anwendungsfall nötig und möglich ist. Aber das scheint sich leicht lösen zu lassen.
So wie ich diesen Post lese, begibt sich Cloudflare in Zensur und Kulturkampf. Die zahlenden Nutzer von Cloudflare werden Cloudflare dafür bezahlen, ihre politische Voreingenommenheit durchzusetzen, und AI-Nutzer werden Cloudflare vorwerfen, sich der Zensur anzuschließen. Cloudflare könnte sich unnötig in politische Auseinandersetzungen hineinziehen lassen.
Ihr verwendet AI, um Anfragen zu filtern? Dann wäre das ja die perfekte Kombination!
[Lehnt sich zum Mikrofon] Die geheime Zutat sind reguläre Ausdrücke.
Ich denke schon länger darüber nach, im gleichen Geist etwas für Smart Payment Credentials zu machen, wenn ein LLM Kauf-/Nichtkauf-Entscheidungen trifft, um Missbrauch von LLMs zu verhindern. Die Idee ist, Single-Use-Tokens (oder etwas Ähnliches) nur dann bereitzustellen, wenn Payment Credentials von einer legitimen Kette angefordert wurden. Falls jemand über diesen Bereich nachdenkt, würde ich mich gern austauschen.
Ich dachte lange, dass sie weiter dem nächsten großen Ding im Marketing hinterherlaufen würden. Gut so, das schafft mehr Raum für Wettbewerb im CDN/DNS/WAF-Markt für Unternehmen, die sich noch darum kümmern.