Wenn ich in Azure-Projekten Azure-OpenAI-Dienste einführe, ist das Absichern längst mehr als ein Häkchen im Deployment. Die Debatte um KI-Sicherheit hat die Unternehmen erreicht, spätestens seit Copilot für Microsoft 365 den Arbeitsalltag prägt. Viele Organisationen stürzen sich allerdings auf Use Cases und Governance, während die technische Absicherung der Azure-OpenAI-Instanz erstaunlich rudimentär bleibt. Typisch sind der Standard-API-Key, eine offen im Netz erreichbare Instanz und kein Gedanke an Abuse Monitoring. An dieser Stelle setze ich an und zeige, wie ein tragfähiges Sicherheitskonzept für Azure OpenAI heute aussieht.

Entra ID ersetzt den lokalen API-Key bei der Authentifizierung

Ich sehe noch immer erstaunlich viele Deployments, in denen der lokale API-Key als Authentifizierungsmechanismus aktiv ist. Microsoft empfiehlt längst etwas anderes: Die lokale Authentifizierung wird deaktiviert, den Zugriff steuert man stattdessen über Microsoft Entra ID, kombiniert mit Managed Identities. Praktisch heißt das, dass jede Anwendung und jeder Nutzer eine ausdrücklich zugewiesene Rolle braucht – meist Cognitive Services OpenAI User, bei Bedarf auch feiner abgestuft. API-Keys fallen damit ebenso weg wie der übliche Wildwuchs an Service Principals. An ihre Stelle treten eindeutige Identitäten mit nachvollziehbaren Berechtigungen, was ganz nebenbei einen sauberen Audit-Trail ergibt. Wie man dabei vorgeht, ist in Microsofts Anleitung zu Managed Identities gut beschrieben.

Mein Tipp aus der Praxis: Nach der Umstellung auf Entra ID lohnt sich ein gezielter Test mit verschiedenen Managed Identities und Benutzern. Nur so fallen Lücken in der Rollenzuweisung oder fehlerhaft konfigurierte Apps rechtzeitig auf.

Die Azure-OpenAI-Rollen werden in der Zugriffssteuerung vergeben

Unter Azure-Portal → Ressourcengruppe → Azure OpenAI-Instanz → Zugriffssteuerung (IAM) weist man die Rolle Cognitive Services OpenAI User gezielt einzelnen Anwendungen (Managed Identities) oder Benutzern zu. Im selben Bereich lässt sich auch die lokale Authentifizierung abschalten. Für mich gehört diese Einstellung zu jedem neuen Deployment dazu.

Ohne private Endpunkte und sauberes DNS bleibt die Instanz angreifbar

Genauso wichtig ist es, für Azure OpenAI konsequent private Endpunkte zu nutzen. Dann ist die OpenAI-Instanz nur noch aus internen Azure-Netzen erreichbar, und den öffentlichen Netzwerkzugriff sollte man abschalten. In der Praxis stolpern viele über DNS: Fehlt eine saubere interne Namensauflösung, laufen Anfragen trotz Private Endpoint häufig ins Leere. Die häufigsten Fehlerquellen habe ich im Beitrag Private Endpoints und DNS in Azure: typische Fehler aus der Praxis zusammengetragen.

Das folgende vereinfachte Ablaufdiagramm zeigt, wie ein mit Managed Identity abgesicherter Zugriff über einen Private Endpoint funktioniert:

flowchart TD
  App["App mit Managed Identity"] --> Auth["Entra ID Authentifizierung"]
  Auth --> MI["Token für Managed Identity"]
  MI --> AI["Azure OpenAI Service"]
  AI --> PE["Private Endpoint"]
  PE --> VNet["Virtuelles Netzwerk"]

Abbildung: Autorisierter Zugriff auf Azure OpenAI über Managed Identity und Private Endpoint.

Ein Private Endpoint allein genügt allerdings nicht, solange Public Network Access noch aktiv ist. Die Einstellung muss auf „Public network access: Disabled“ stehen. Andernfalls kann jeder mit dem passenden Key von außen zugreifen, bei einer Fehlkonfiguration sogar ohne.

Content-Filter und Abuse Monitoring bremsen Missbrauch aus

Mit der Netzgrenze ist die Arbeit nicht getan. Azure OpenAI bringt eigene Content-Filter mit, die Anfragen und Antworten automatisch prüfen und bei Verstößen blockieren können. Man aktiviert und konfiguriert sie direkt in der Azure-OpenAI-Instanz unter „Content Filtering“ und kann dort Schwellenwerte und Kategorien (z. B. Hassrede, sexuelle Inhalte, Gewalt) fein einstellen. Wie die Filterung arbeitet und wie Microsoft Missbrauch erkennt, erklärt der offizielle Artikel zum Content-Filter ausführlich. Ich rate Unternehmen, die Abuse-Logs regelmäßig auszuwerten und auffälligen Mustern früh nachzugehen, etwa wenn aus einer einzigen Quelle plötzlich massenhaft Prompts eintreffen.

Datenverarbeitung und Datenresidenz gehören vor dem Go-live auf den Prüfstand

Eine Frage höre ich ständig: „Landen unsere Prompts im Training von Microsoft- oder OpenAI-Modellen?“ Nach aktuellem Stand (Oktober 2024) verwendet Microsoft Prompts und Antworten aus Kundensitzungen in Azure OpenAI weder dazu, die Modelle von Microsoft oder OpenAI zu verbessern, noch um sie zu trainieren. Genau darin unterscheidet sich Azure OpenAI deutlich von der Consumer-Variante von ChatGPT und anderen KI-Angeboten im Web.

Bei der Wahl des Modells sollte man zusätzlich auf den Bereitstellungstyp und die Datenresidenz achten. Die meisten Modelle werden standardmäßig regional oder in sogenannten „Data Zones“ bereitgestellt. Je nach Region gibt es einzelne Modelle (z. B. GPT-4 Turbo) aber nur in globalen Tenants, und dann ist die Datenresidenz nicht mehr eindeutig regional. Vor jedem Go-live prüfe ich deshalb, ob Region und Modell zusammenpassen und ob Daten womöglich außerhalb der EU landen könnten.

Azure Policy und Quotas halten Wildwuchs und Kosten im Zaum

Viele Unternehmen unterschätzen, wie leicht sich mit Azure Policy Grundregeln für Azure-OpenAI-Deployments durchsetzen lassen. Für Azure Cognitive Services gibt es inzwischen mehrere integrierte Richtlinien (Built-in Policies), die zum Beispiel Private Endpoints vorschreiben oder nur bestimmte Regionen zulassen. Man aktiviert sie im Azure-Policy-Portal auf Abonnement- oder Managementgruppenebene. Damit lassen sich Wildwuchs und Fehlkonfigurationen wirksam eindämmen.

Auch die Kosten wollen im Blick behalten werden. Azure OpenAI wird nach dem Pay-as-you-go-Prinzip abgerechnet und arbeitet mit Quotas statt mit klassischen Budgets. Im Azure-Portal legt man diese Quotas auf Service-Ebene fest, und zwar für die gesamte Instanz, aber auch pro Modell und Deployment. So kann eine versehentliche Endlosschleife in einem einzelnen Projekt oder bei einem einzelnen Benutzer keine hohen Kosten mehr verursachen.

Die Absicherung von Azure OpenAI ist kein Selbstläufer

Mit einem Haken bei „Entra ID aktiviert“ ist Azure OpenAI noch lange nicht abgesichert. Wer auf private Endpunkte, konsequente Rollenzuweisung, Abuse Monitoring und klare Quotas verzichtet, geht schnell Risiken ein, und zwar technische ebenso wie regulatorische und finanzielle. In vielen Tenants beobachte ich, dass die eigentlichen Schwachstellen genau dort entstehen, wo Netzwerk, Identität und Governance ineinandergreifen. Bei einer sauberen Umsetzung lassen sich die Vorteile von Azure OpenAI dagegen ohne schlaflose Nächte nutzen. Spätestens mit der ersten produktiven Anwendung macht sich die investierte Sorgfalt bezahlt.