Prinzip der geringsten Berechtigung: Bedeutung und Anwendung in KI-Systemen

Definition: Nur die erforderlichen Berechtigungen erteilen

Das Prinzip der geringsten Berechtigung, auch Prinzip der minimalen Berechtigung genannt und mit PoLP abgekürzt, besagt, dass jeder Benutzer, jeder Prozess oder jede Komponente nur über die Berechtigungen verfügen soll, die für die Ausführung ihrer zugewiesenen Aufgabe erforderlich sind. Die Regel umfasst sowohl, welche Ressourcen eine Identität erreichen kann, als auch, welche Operationen sie auf diesen ausführen darf. Ziel ist es, die Folgen von Fehlern, Missbrauch oder der Kompromittierung eines Kontos oder Prozesses zu begrenzen.

Es bedeutet nicht, dass alle Identitäten dieselben reduzierten Berechtigungen haben, sondern dass der Umfang der Funktion entsprechen muss. Ein Prozess, der eine Datei lesen muss, sollte sie nicht ändern können, wenn diese Fähigkeit nicht erforderlich ist; ein Dienst, der eine Datenbank abfragt, sollte keine Berechtigungen zur Serveradministration erhalten. Die IBM-Dokumentation zu AIX illustriert das Prinzip auf Prozessebene und erklärt, dass die Einschränkung von Berechtigungen den Schaden begrenzen kann, wenn eine Anwendung, die über Berechtigungen verfügt, ausgenutzt wird.

In einem KI-System wird das Prinzip auf die Identitäten und Ressourcen angewendet, die das Modell umgeben: das Konto, das den Dienst ausführt, der Agent, der Aktionen anfordert, die verfügbaren Werkzeuge, die Zugangsdaten, die abfragbaren Daten und die Netzwerkverbindungen. Daraus folgt nicht, dass ein Modell an sich eine Betriebssystemidentität besitzt. Diese Identität gehört in der Regel zum Prozess oder Dienst, der das Modell ausführt, oder zur Komponente, die in seinem Namen Aufrufe durchführt.

Für weiteren Kontext siehe das [Glossar](/glossary/), die Karte zum [Prinzip der geringsten Berechtigung](/glossary/principio-menor-privilegio) und den [Vergleich](/compare/).

Funktionsweise: Identitäten, Berechtigungen und Umfang

Die Anwendung beginnt mit der Identifizierung der Komponenten, die handeln können. In einer einfachen Architektur kann es eine Dienstidentität für das Backend, eine für den Datenbankzugriff und separate Zugangsdaten für ein externes Werkzeug geben. In einer Architektur mit Agenten ist es ratsam, das Modell, das eine Antwort erzeugt, den Orchestrierer, der diese Antwort interpretiert, und die Werkzeuge, die Operationen ausführen, zu unterscheiden. Die Einschränkung einer Ebene schränkt die anderen nicht automatisch ein: Jede Berechtigung muss in der Komponente angewendet werden, die sie verwendet.

Anschließend wird die Autorisierung eingegrenzt. Rollen können Berechtigungen für übliche Funktionen bündeln; spezifischere Kontrollen können Operationen nach Ressource, Aktion oder Kontext einschränken. Zum Beispiel erlaubt die Gewährung eines Lesezugriffs auf einen Satz von Tabellen nicht den Schreibzugriff auf die gesamte Datenbank. Zuweisungen müssen überprüft werden, wenn sich die Aufgabe, der Dienst oder die Sensitivität der Daten ändern.

Temporäre Berechtigungen reduzieren die Zeit, während der eine Fähigkeit verfügbar ist. Wenn eine administrative Operation nur für eine punktuelle Aufgabe unerlässlich ist, kann sie für einen begrenzten Zeitraum gewährt und danach widerrufen werden. Die Zeitlichkeit ist eine Form der Zugriffsbeschränkung, aber keine ausreichende Autorisierung an sich: Es sind weiterhin eine korrekt authentifizierte Identität, eine Politik, die die Operation erlaubt, und Kontrollen erforderlich, die verhindern, dass das Zugangszeichen außerhalb des vorgesehenen Kontexts verwendet wird.

Netzwerkeinschränkungen können ebenfalls beitragen, indem sie die Verbindungen auf die beschränken, die der Dienst durchführen muss. Sie sind jedoch nicht gleichbedeutend mit Berechtigungen für Daten oder Aktionen: Ein Server kann von Internet isoliert sein und dennoch übermäßige Berechtigungen für lokale Dateien haben. Ein effektives Design kombiniert ergänzende Kontrollen, anstatt davon auszugehen, dass eine einzelne Barriere das gesamte Prinzip umsetzt.

Drei angewandte Beispiele in KI-Systemen

Unternehmensagent mit nur-Lese-Abfrage. Wenn ein Agent Fragen auf Basis interner Informationen beantworten muss, kann das Konto, das die Daten abfragt, auf Lesezugriff und die erforderlichen Tabellen beschränkt werden. Operationen, die Datensätze ändern, sollten außerhalb dieser Identität bleiben, es sei denn, es gibt einen genehmigten Anwendungsfall, der sie erfordert. Wenn Schreibaktionen aktiviert werden, müssen sie separat autorisiert und im ausführenden Dienst verifiziert werden; eine Anweisung im Prompt ist keine Berechtigungssteuerung.

Lokaler Inferenzserver mit eingeschränktem Netzwerkzugriff. Ein Dienst, der nur lokale Verbindungen empfängt, kann so konfiguriert werden, dass er auf einer Loopback-Adresse wie 127.0.0.1 lauscht, anstatt Verbindungen auf allen Schnittstellen zu akzeptieren. Das reduziert, wer den Port aus dem Netzwerk erreichen kann, bestimmt aber nicht, welche Dateien der Prozess lesen kann, welche Befehle er ausführen kann oder ob eine andere lokale Komponente ihn aufrufen kann. Die Adressierung des Lauschens ist ein Beispiel für eine Expositionseinschränkung, keine vollständige Umsetzung des PoLP.

KI-API mit begrenztem Geltungsbereich. Eine Anwendung, die einen Anbieter oder einen internen Dienst aufruft, kann ein Zugangszeichen verwenden, das für die Operation und die Ressource autorisiert ist, die sie benötigt. Wenn das System temporäre Zugangszeichen unterstützt, kann deren Dauer begrenzt werden; wenn nicht, können Geltungsbereich, Berechtigungen und Widerrufsmöglichkeit je nach verfügbaren Funktionen eingeschränkt werden. Ein Einweg-Token ist keine universelle Anforderung des Prinzips: Es sollte nur dann behauptet oder implementiert werden, wenn der Dienst es unterstützt und der Ablauf es benötigt. Das Zugangszeichen sollte auch nicht dem Modell ausgesetzt werden, wenn es es im Backend behalten und verwenden kann.

Was es nicht ist: Authentifizierung, Isolation oder Guardrails

Authentifizierung und geringste Berechtigung lösen unterschiedliche Probleme. Die Authentifizierung prüft eine Identität oder validiert Zugangsdaten; die Autorisierung entscheidet, was diese Identität tun darf. Eine starke Authentifizierung kann die Wahrscheinlichkeit verringern, dass eine nicht autorisierte Person ein Konto verwendet, korrigiert aber keine übermäßige Berechtigungsvergabe. Umgekehrt beweist eine restriktive Berechtigungsrichtlinie nicht allein, wer das Konto verwendet.

Netzwerkisolation oder Air-Gapping sind auch keine Synonyme für PoLP. Eine Umgebung, die von externen Netzen getrennt ist, kann bestimmte Zugangswege begrenzen, aber die laufenden Prozesse können weiterhin mehr lokale Fähigkeiten haben, als erforderlich sind. Isolation und geringste Berechtigung können sich ergänzen: Eines begrenzt Kanäle oder Kommunikationsdomänen; das andere schränkt die Berechtigungen jeder Identität ein.

Guardrails sind Kontrollen, die darauf abzielen, Eingaben, Ausgaben und Aktionen eines KI-Systems zu steuern oder zu begrenzen. Sie können nützlich sein, um unerwünschte Antworten oder Nutzungen zu reduzieren, ersetzen aber nicht die Autorisierung, die auf Datenbanken, Dateien, Werkzeuge oder APIs angewendet wird. Wenn ein Modell eine verbotene Aktion vorschlägt, muss die entscheidende Kontrolle im Werkzeug oder Dienst überprüft werden, der sie ausführt; es ist nicht ratsam, sich ausschließlich darauf zu verlassen, dass das Modell eine Anweisung befolgt.

Zero Trust ist ein breiterer architektonischer Ansatz, der die Verifizierung von Anfragen und Zugriffssteuerungen einbezieht. PoLP kann Teil dieses Ansatzes sein, indem die gewährten Fähigkeiten reduziert werden, aber die Begriffe sind nicht austauschbar. Die Trennung von Aufgaben verteilt Aufgaben oder Genehmigungen, damit eine einzelne Identität nicht alle relevanten Fähigkeiten konzentriert. Sie kann mit der geringsten Berechtigung koexistieren, adressiert aber ein anderes Risiko.

Operative Grenzen bei Agenten und dynamischen Systemen

In einem traditionellen System ist die Aufgabe eines Prozesses in der Regel relativ abgegrenzt. Ein Agent hingegen kann Werkzeuge auswählen und Schritte basierend auf der Anfrage und den Zwischenergebnissen verketteten. Das erschwert die vorab Entscheidung, welche minimale Berechtigungsmenge erforderlich ist, macht das Prinzip aber nicht anwendbar: Es zwingt dazu, die autorisierten Aufgaben zu definieren, Fähigkeiten zu trennen und jede Aktion am Ausführungspunkt zu validieren.

Eine zu breite Berechtigung erhöht den möglichen Einfluss, wenn der Dienst kompromittiert wird oder eine unvorhergesehene Aktion auftritt. Eine zu enge kann eine legitime Aufgabe blockieren, Fehler verursachen oder operative Umgehungen anregen, wie die Wiederverwendung eines Kontos mit mehr Zugriff. Das Gleichgewicht besteht nicht darin, eine perfekte Konfiguration zu erraten: Es erfordert das Testen repräsentativer Abläufe, das Protokollieren von Ablehnungen, das Verständnis ihrer Ursache und das Anpassen der Berechtigungen mit Überprüfung.

Das nicht deterministische Verhalten des Modells ändert die Definition des Prinzips nicht. Es beeinflusst jedoch die Art, wie Barrieren gestaltet werden: Es darf nicht angenommen werden, dass ein Modell immer das richtige Werkzeug wählt oder alle Anweisungen befolgt. Die Autorisierung muss außerhalb der Textgenerierung angewendet werden, in den Diensten, die Daten und Operationen steuern. Es ist auch ratsam zu begrenzen, was eine einzelne Anfrage tun kann, damit eine falsche Entscheidung nicht automatisch unbegrenzte Fähigkeit erhält.

Die hier verfügbaren Beweise legen allgemeine Grundlagen der geringsten Berechtigung und Beispiele für Berechtigungen nach Prozess, Rolle und Berechtigung fest. Sie dokumentieren nicht direkt eine universelle Konfiguration für KI-Agenten, lokale Inferenz oder KI-APIs. Diese Fälle sollten als technische Anwendungen des Prinzips verstanden werden, deren Machbarkeit von den konkreten Fähigkeiten des Betriebssystems, der Plattform, des Anbieters und des Anwendungsentwurfs abhängt.

Entscheidungskriterien und verwandte Konzepte

IAM, oder Identitäts- und Zugriffsmanagement, bündelt Praktiken zur Verwaltung von Identitäten, Authentifizierung und Autorisierungen. PoLP ist ein Entwurfskriterium, das über diese Mechanismen angewendet werden kann; es ist kein Produkt oder eine einzelne Technik. Das rollenbasierte Zugriffssteuerung kann die wiederholbare Zuweisung von Berechtigungen erleichtern, obwohl eine schlecht definierte Rolle zu viel gewähren kann. Daher ist es wichtig, neben dem Rollennamen zu überprüfen, welche effektiven Operationen sie erlaubt.

Die Trennung von Aufgaben verlangt, dass bestimmte Aufgaben oder kritische Phasen nicht von einer einzigen Person oder Identität abhängen. Zum Beispiel kann eine Identität eine Änderung vorbereiten und eine andere sie genehmigen. PoLP begrenzt individuelle Fähigkeiten; die Trennung verteilt Fähigkeiten oder Entscheidungen. Eine solide Politik kann beide kombinieren, wenn Risiko und Prozess es rechtfertigen.

Bei der Bewertung einer KI-Integration fragen Sie, welche Identität jeden Aufruf durchführt, welche Ressource sie erreicht, welche Operationen ihr erlaubt sind und was passiert, wenn der Prozess unerwartet handelt. Prüfen Sie auch, ob Berechtigungen widerrufen werden können, ob Zugangsdaten außerhalb des Modellkontexts bleiben und ob Ablehnungen diagnostiziert werden können, ohne allgemeinen Zugriff zu gewähren. Die Antworten hängen von der Implementierung ab und sollten nicht aufgrund der Etiketten „sicherer Agent“ oder „Zero Trust“ vorausgesetzt werden.

Das Prinzip wird immer dann verwendet, wenn eine Identität auf geschützte Ressourcen zugreifen kann und ihre Fähigkeit auf die vorgesehene Arbeit begrenzt werden soll. Die praktische Entscheidung besteht darin, das Minimum zu gewähren, das es erlaubt, eine autorisierte Aufgabe zuverlässig abzuschließen und zu betreiben, dies im System zu verifizieren, das die Aktion ausführt, und es zu überprüfen, wenn sich Aufgabe, Daten oder Architektur ändern.

Verwandte Begriffe