AWS Germany – Amazon Web Services in Deutschland

Sicherheitsvorkehrungen für den Netzwerkperimeter zur Absicherung generativer KI

von Riggs Goodman III übersetzt durch Desiree Brunner

Generative KI-basierte Anwendungen haben in den letzten Jahren an Popularität gewonnen. Anwendungen, die mit großen Sprachmodellen (auf Englisch “Large Language Models”, LLMs) entwickelt wurden, haben das Potenzial, den Mehrwert den Unternehmen ihren Kunden bieten, zu erhöhen. In diesem Blogbeitrag vertiefen wir uns auf den Netzwerkperimeterschutz für generative KI-Anwendungen. Wir gehen auf die verschiedenen Bereiche des Netzwerkperimeterschutzes ein, die man berücksichtigen sollte, diskutieren, wie diese auf generative KI-Anwendungen anwendbar sind und stellen Architekturmuster vor. Durch die Implementierung des Netzwerkperimeterschutzes für Ihre generativen KI-Anwendungen erhalten Sie Kontrollen, die dabei helfen, vor unbefugter Nutzung, Kostenüberschreitungen, verteilten Denial-of-Service-Angriffen (“DoS”) sowie anderen Bedrohungsakteuren (“threat actor”) oder neugierigen Nutzern zu schützen.

Perimeterschutz für LLMs

Der Netzwerkperimeterschutz für Webanwendungen hilft bei der Beantwortung wichtiger Fragen, wie zum Beispiel:

  • Wer kann auf die Anwendung zugreifen?
  • Welche Art von Daten werden an die Anwendung gesendet?
  • Wie viele Daten darf die Anwendung verarbeiten?

In der Regel funktionieren die gleichen Methoden zur Netzwerksicherheit, die für andere Webanwendungen verwendet werden, auch für generative KI-Anwendungen. Der Hauptfokus dieser Methoden liegt auf der Kontrolle des Netzwerkverkehrs, der versucht, auf die Anwendung zuzugreifen, nicht auf den spezifischen Anfragen und Antworten, die die Anwendung erstellt. Wir konzentrieren uns auf drei Hauptbereiche des Netzwerkperimeterschutzes:

  1. Authentifizierung und Autorisierung für das Frontend der Webanwendung
  2. Verwendung einer Webanwendungs-Firewall
  3. Schutz vor DDoS-Angriffen

Die Sicherheitsbedenken bei der Verwendung von LLMs in diesen Anwendungen, einschließlich Problemen mit Prompt-Injektionen, Durchsickern sensibler Informationen oder übermäßige Entscheidungsfreiheit (auf Englisch “excessive agency”, LLM08), werden in diesem Artikel nicht behandelt.

Frontend-Authentifizierung und -Autorisierung

Bei der Konzeption des Netzwerkperimeterschutzes müssen Sie zunächst entscheiden, ob Sie bestimmten Nutzern den Zugriff auf die Anwendung basierend darauf erlauben möchten, ob sie authentifiziert (“AuthN”) und autorisiert (“AuthZ”) sind, bestimmte Fragen an die generativen KI-Anwendungen zu stellen. Viele generative KI-Anwendungen befinden sich hinter einer Authentifizierungsschicht, so dass ein Nutzer sich bei seinem Identitätsanbieter (“identity provider”, IDP) anmelden muss, bevor er auf die Anwendung zugreifen kann. Für öffentliche Anwendungen, die nicht hinter einer Authentifizierung liegen (z.B. ein Chatbot), sind zusätzliche Überlegungen in Bezug auf AWS WAF (“Web Application Firewall”) und DDoS-Schutz erforderlich, die wir in den nächsten beiden Abschnitten besprechen.

Schauen wir uns ein Beispiel an. Amazon API Gateway ist eine Option für Kunden für das Webanwendungs-Frontend und bietet das Zählen von Nutzern oder APIs mit Authentifizierung und Autorisierung an. Es handelt sich um einen vollständig verwalteten Service, mit dem Entwickler APIs bequem veröffentlichen, warten, überwachen und auf Skalierbarkeit ausrichten können. Mit API Gateway erstellen Sie AWS Lambda–Autorisierer, um den Zugriff auf APIs innerhalb Ihrer Anwendung zu steuern. Abbildung 1 zeigt, wie der Zugriff in diesem Beispiel funktioniert.

Abbildung 1: Ein API Gateway, Lambda-Autorisierer und grundlegende Filter im Signalweg zwischen Client und LLM

Der Workflow in Abbildung 1 ist wie folgt:

  1. Ein Client sendet eine Anfrage an Ihre API, die vom API Gateway bereitgestellt wird.
  2. Wenn das API Gateway die Anfrage erhält, sendet es die Anfrage an einen Lambda Autorisierer, der die Anfrage über OAuth, SAML oder einen anderen Mechanismus authentifiziert. Der Lambda-Autorisierer gibt eine AWS Identity and Access Management (IAM)-Richtlinie an das API Gateway zurück, welches die Anfrage dann zulässt oder ablehnt.
  3. Wenn die Anfrage zugelassen wird, sendet das API Gateway die API-Anfrage an die Backend-Anwendung. In Abbildung 1 ist dies eine Lambda-Funktion, die zusätzliche Funktionen im Bereich der LLM-Sicherheit bereitstellt und für komplexere Filterung steht. Zusätzlich zum Lambda-Autorisierer können Sie Drosselungen an dem API Gateway pro Kunde oder bei den Anwendungsmethoden konfigurieren, auf die Clients zugreifen, bevor der Datenverkehr die Backend-Anwendung erreicht.
  4. Drosseln kann nicht nur eine gewisse Abmilderung gegen DDoS-Angriffe, sondern auch gegen Modelklonungs- [EN, Extern] und Inversionsangriffe [EN, Extern]
  5. Schließlich sendet die Anwendung Anfragen an Ihr LLM, das auf Amazon Bedrock bereitgestellt ist.

Die Kombination aus Lambda-Autorisierer und Drosselung unterstützt mehrere Perimeterschutzmechanismen. Erstens erhalten nur autorisierte Nutzer Zugriff auf die Anwendung, was dabei hilft, Bots und die Öffentlichkeit vom Zugriff auf die Anwendung abzuhalten. Zweitens beschränken Sie für autorisierte Nutzer die Rate, mit der sie das LLM aufrufen können, um übermäßige Kosten für Anfragen und Antworten an das LLM zu vermeiden. Drittens kann die Anwendung nach der Authentifizierung und Autorisierung des Nutzers Identitätsinformationen an die Backend-Datenzugriffsschicht weitergeben, um die dem Nutzer zur Verfügung stehenden Daten entsprechend seiner Berechtigungen einzuschränken.

Neben dem API Gateway bietet AWS weitere Optionen zur Frontend-Authentifizierung und -Autorisierung an. Der AWS Application Load Balancer (ALB) unterstützt OpenID Connect (OIDC)-Funktionen, um eine Authentifizierung bei Ihrem OIDC-Anbieter vor dem Zugriff fordern. Für interne Anwendungen kombiniert AWS Verified Access sowohl Sicherheitssignale wie Benutzeridentität und Gerätesicherheitsstatus, um den Zugriff auf Ihre generative KI-Anwendung zu erlauben oder abzulehnen.

AWS WAF

Sobald die Authentifizierungs- oder Autorisierungsentscheidung getroffen wurde, ist der nächste Aspekt des Netzwerkperimeterschutzes die Anwendungsseite. Für generative KI-Anwendungen werden immer wieder neue Sicherheitsrisiken identifiziert, wie in der OWASP (Open Source Foundation for Application Security Project) Top 10 für große Sprachmodel-Anwendungen [EN, Extern]  beschrieben. Zu diesen Risiken gehören unsichere Ausgabebehandlung (LLM02), unsicheres Plugin-Design (LLM07) und andere Mechanismen, die dazu führen, dass die Anwendung Antworten gibt, die außerhalb der gewünschten Norm liegen. Beispielsweise könnte ein Bedrohungsakteur eine direkte Prompt-Injektion in das LLM vornehmen (LLM01), was dazu führt, dass sich das LLM unsachgemäß verhält. Einige dieser Risiken (unsicheres Plugin-Design) lassen sich durch die Weitergabe von Identitätsinformationen an die Plugins und Datenquellen angehen. Viele dieser Schutzmaßnahmen fallen jedoch außerhalb des Netzwerkperimeterschutzes und in den Bereich der Anwendungssicherheit. Für den Netzwerkperimeterschutz liegt der Fokus darauf, zu validieren, welche Nutzer Zugriff auf die Anwendung haben und die Unterstützung von Regeln, die Web-Anfragen vor dem Anwendungszugriff basierend auf Netzwerkregeln und -mustern auf Anwendungsebene zulassen, blockieren oder überwachen.

Darüber hinaus ist Bot-Datenverkehr ein wichtiger Aspekt für webbasierte Anwendungen. Laut Security Today [EN] stammen 47 % des gesamten Internetverkehrs von Bots. Bots, die Anfragen an öffentliche Anwendungen senden, erhöhen die Kosten für die Nutzung generativer KI-Anwendungen durch höhere Anfragelasten.

Um sich vor Bot-Verkehr zu schützen, bevor ein Nutzer auf die Anwendung zugreifen kann, können Sie AWS WAF als Teil des Perimeterschutzes implementieren. Mit AWS WAF können Sie eine Firewall bereitstellen, um die HTTP(S)-Anfragen zu überwachen und zu blockieren, die an Ihre geschützten Webanwendungsressourcen weitergeleitet werden. Diese Ressourcen befinden sich hinter Amazon API Gateway, ALB, AWS Verified Access und anderen Ressourcen. Aus Sicht der Webanwendung wird AWS WAF verwendet, um den Zugriff auf Ihre Anwendung vor dem Aufrufen Ihres LLMs zu verhindern oder einzuschränken. Dieser Aspekt ist wichtig, denn zusätzlich zum Schutz der Prompts und Completions, die zu und vom LLM gehen, möchten Sie sicherstellen, dass nur legitimer Datenverkehr auf Ihre Anwendung zugreifen kann. AWS Verwaltete Regeln oder AWS Marketplace verwaltete Regelgruppen bieten Ihnen vordefinierte Regeln als Teil einer Regelsatzgruppe.

Lassen Sie uns das vorherige Beispiel erweitern. Wenn Ihre in Abbildung 1 gezeigte Anwendung beginnt zu wachsen, entscheiden Sie sich, sie hinter Amazon CloudFront zu platzieren. CloudFront ist ein Web-Service, der Ihnen einen verteilten Ingress-Datenverkehr zu AWS bietet, indem Sie ein globales Netzwerk von Edge-Standorten nutzen. Neben dem verteilten Ingress-Datenverkehr bietet CloudFront Ihnen die Möglichkeit, AWS WAF auf verteilte Weise bereitzustellen, um sich vor SQL-Injektionen, Bots und anderen Bedrohungen mithilfe Ihrer AWS WAF-Regeln zu schützen. Sehen wir uns die neue Architektur in Abbildung 2 an.

Abbildung 2: Hinzufügen von AWS WAF und CloudFront zum Client-zu-Modell-Signalweg

Der Workflow in Abbildung 2 ist wie folgt:

  1. Ein Client sendet eine Anfrage an Ihre API. DNS leitet den Client an einen CloudFront-Standort weiter, an dem AWS WAF bereitgestellt ist.
  2. CloudFront sendet die Anfrage durch eine AWS WAF-Regel, um zu bestimmen, ob der Verkehr blockiert, überwacht oder zugelassen werden soll. Wenn AWS WAF den Verkehr nicht blockiert, sendet AWS WAF ihn an die CloudFront-Routing-Regeln weiter.

    Notiz: Es wird empfohlen, den Zugriff auf das API Gateway so zu beschränken, dass Nutzer nicht die CloudFront-Distribution umgehen können, um auf das API Gateway zuzugreifen. Ein Beispiel dafür, wie dieses Ziel erreicht werden kann, finden Sie im Blogbeitrag „Restricting access on HTTP API Gateway Endpoint with Lambda Authorizer [EN]”.

  3. CloudFront sendet den Verkehr an das API Gateway, wo er den gleichen Workflow wie in Abbildung 1 besprochen durchläuft.

Um mehr ins Detail zu gehen, konzentrieren wir uns auf Bot-Verkehr. Mit AWS WAF Bot Control können Sie Bots wie Scraper, Scanner, Crawler, Status-Monitore und Suchmaschinen überwachen, blockieren oder die Anzahl der Anfragen begrenzen. Bot Control bietet mehrere Optionen in Bezug auf konfigurierte Regeln und Inspektionsebenen. Wenn Sie zum Beispiel die gezielte Inspektionsebene der Regelsatzgruppe verwenden, können Sie Bots dazu zwingen ihre Identität zu offenbaren. Dadurch wird es für böswillige Bots schwieriger und teurer, gegen Ihre generative KI-Anwendung vorzugehen. Sie können die Bot Control verwaltete Regelgruppe allein oder in Kombination mit anderen AWS verwalteten Regelsatzgruppen und Ihren eigenen benutzerdefinierten AWS WAF-Regeln verwenden. Bot Control bietet auch eine detaillierte Sichtbarkeit auf die Anzahl der Bots, die Ihre Anwendung angreifen, wie in Abbildung 3 gezeigt.

Abbildung 3: Bot Control Dashboard für Bot-Anfragen und Nicht-Bot-Anfragen

Wie hilft Ihnen diese Funktionalität? Für Ihre generative KI-Anwendung erhalten Sie Einblicke, wie Bots und andere Datenverkehrsarten Ihre Anwendung angreifen. AWS WAF bietet Optionen, um Bot-Verkehr zu überwachen und die Handhabung von Bot-Web-Anfragen anzupassen, einschließlich der Erlaubnis bestimmter Bots oder der Blockierung von Bot-Verkehr für Ihre Anwendung. Zusätzlich zur Bot-Kontrolle bietet AWS WAF eine Reihe verschiedener verwalteter Regelgruppen, einschließlich Baseline-Regelsätzen, anwendungsfallspezifischen Regelsätzen, IP-Reputations-Regelsätzen und anderen. Weitere Informationen finden Sie in der Dokumentation zu AWS Verwaltete Regeln und AWS Marketplace verwaltete Regelgruppen.

DDoS-Schutz

Das letzte Thema, das wir in diesem Beitrag behandeln werden, ist DDoS mit LLMs. Ähnlich wie bei anderen Layer-7-Anwendungen können Bedrohungsakteure Anfragen senden, die eine außergewöhnlich hohe Menge an Ressourcen verbrauchen. Dadurch kann die Reaktionsfähigkeit des Dienstes abnehmen oder die Kosten für die Ausführung der LLMs, die die hohe Anzahl von Anfragen bearbeiten, steigen. Obwohl Drosselung helfen kann, eine individuelle Nutzer- oder Methoden-Ratenbegrenzung zu unterstützen, verwenden DDoS-Angriffe fortgeschrittenere Bedrohungsvektoren, die schwer durch Drosselung abzuwehren sind.

AWS Shield hilft dabei, Schutz vor DDoS-Angriffen für Ihre Internet nutzende Anwendungen zu bieten, sowohl auf Layer 3/4 mit Shield Standard als auch auf Layer 7 mit Shield Advanced. Zum Beispiel reagiert Shield Advanced automatisch, um Anwendungsbedrohungen abzumildern, indem es Web-Anfragen, die Teil des Exploits sind, mit Web Access Control Lists (ACLs) zählt oder blockiert, die Teil Ihres bereits bereitgestellten AWS WAF sind. Je nach Ihren Anforderungen kann Shield mehrere Schutzebenen gegen DDoS-Angriffe bieten.

Abbildung 4 zeigt, wie Ihre Bereitstellung aussehen könnte, nachdem Shield zur Architektur hinzugefügt wurde.

Abbildung 4: Hinzufügen von Shield Advanced zum Client-zu-Modell-Signalweg

Der Workflow in Abbildung 4 ist wie folgt:

  1. Ein Client sendet eine Anfrage an Ihre API. DNS (“Domain Name System”) leitet den Client an einen CloudFront-Standort weiter, an dem AWS WAF und Shield bereitgestellt sind.
  2. CloudFront sendet die Anfrage durch eine AWS WAF-Regel, um zu bestimmen, ob der Datenverkehr blockiert, überwacht oder zugelassen werden soll. AWS Shield kann eine Vielzahl bekannter DDoS-Angriffsvektoren und Zero-Day-Angriffsvektoren Je nach Konfiguration arbeiten Shield Advanced und AWS WAF zusammen, um den Datenverkehr von einzelnen IP-Adressen zu begrenzen. Wenn AWS WAF oder AWS Shield Advanced den Datenverkehr nicht blockieren, senden die Dienste ihn an die CloudFront-Routing-Regeln weiter.
  3. CloudFront sendet den Datenverkehr an das API Gateway, wo er durch den gleichen Verkehrsweg wie in Abbildung 1 besprochen verläuft.

Wenn Sie AWS Shield und Shield Advanced implementieren, erhalten Sie Schutz vor Sicherheitsereignissen und Einblicke sowohl in globale als auch in Konten-spezifische Ereignisse. Auf AWS Kontoebene erhalten Sie beispielsweise Informationen über die Gesamtzahl der auf Ihrem Konto gesehenen Ereignisse, die höchste Bit- und Paketrate für jede Ressource sowie die höchste Anforderungsrate für CloudFront. Mit Shield Advanced erhalten Sie auch Zugriff auf Benachrichtigungen über Ereignisse, die von Shield Advanced erkannt wurden, sowie zusätzliche Informationen über erkannte Ereignisse und Milderungsmaßnahmen. Diese Metriken und Daten bieten Ihnen zusammen mit AWS WAF Einblicke in den Datenverkehr, der versucht, auf Ihre generativen KI-Anwendungen zuzugreifen. Dies bietet Abmilderungsfunktionen, bevor der Datenverkehr auf Ihre Anwendung zugreift und bevor das LLM aufgerufen wird.

Überlegungen

Bei der Bereitstellung des Netzwerkperimeterschutzes für generative KI-Anwendungen sollten Sie Folgendes berücksichtigen:

  • AWS bietet mehrere Optionen, sowohl auf der Frontend-Authentifizierungs- und Autorisierungsseite als auch auf der AWS WAF-Seite, um den Perimeterschutz zu konfigurieren. Abhängig von Ihrer Anwendungsarchitektur und Ihren Datenverkehrsmustern können mehrere Ressourcen den Perimeterschutz mit AWS WAF bereitstellen und in Identitätsanbieter für Authentifizierungs- und Autorisierungsentscheidungen integriert werden.
  • Sie können auch fortschrittlichere LLM-spezifische Prompt- und Komplettierungsfilter bereitstellen, indem Sie Lambda-Funktionen und andere AWS-Dienste als Teil Ihrer bereitgestellten Architektur verwenden. Die Perimeterschutzfunktionen konzentrieren sich darauf, unerwünschten Datenverkehr davon abzuhalten, die Endanwendung zu erreichen.
  • Die meisten Netzwerkperimeterschutzmaßnahmen für LLMs ähneln den Netzwerkperimeterschutzmechanismen für andere Webanwendungen. Der Unterschied besteht darin, dass im Vergleich zu regulären Webanwendungen zusätzliche Bedrohungsvektoren ins Spiel kommen. Weitere Informationen zu Bedrohungsvektoren finden Sie in der OWASP Top 10 für Large Language Model Anwendungen [EN, Extern] und Mitre ATLAS [EN, Extern] (“Adversarial Threat Landscape for AI Systems”).

Fazit

In diesem Blogbeitrag haben wir erörtert, wie traditionelle Strategien zum Netzwerkperimeterschutz eine “Defense in Depth” (zu Deutsch: mehrschichtige Verteidigung) für generative KI-Anwendungen bieten können. Wir haben die Ähnlichkeiten und Unterschiede zwischen LLM-Workloads und anderen Webanwendungen erörtert. Wir sind durchgegangen, warum Authentifizierungs- und Autorisierungsschutz wichtig ist, und gezeigt, wie Sie Amazon API Gateway verwenden können, um über Nutzungspläne zu drosseln und über Lambda-Autorisierer zu authentifizieren. Anschließend haben wir besprochen, wie Sie AWS WAF nutzen können, um Anwendungen vor Bots zu schützen. Zuletzt haben wir erläutert, wie AWS Shield erweiterten Schutz gegen verschiedene Arten von DDoS-Angriffen im großen Maßstab bieten kann. Für weitere Informationen zum Netzwerkperimeterschutz und zur Sicherheit generativer KI-Systeme werfen Sie einen Blick auf andere Blogbeiträge im AWS Security Blog Channel [EN].

Wenn Sie Feedback zu diesem Beitrag haben, hinterlassen Sie Kommentare im Kommentarbereich unten.

Wenn Sie Fragen zu diesem Beitrag haben, wenden Sie sich an den AWS Support.

Riggs Goodman III ist Principal Partner Solution Architect bei AWS. Sein aktueller Schwerpunkt liegt auf KI-Sicherheit und Datensicherheit. Er bietet Kunden und Partner technische Anleitungen, Architekturmuster und Führung, um KI-Workloads auf AWS aufzubauen. Intern konzentriert sich Riggs darauf, die übergreifende technische Strategie und Innovation über AWS-Service-Teams hinweg voranzutreiben, um Herausforderungen von Kunden und Partnern anzugehen.