· privacy · Aktualisiert am
Zugriffsgrenzen und Wiederherstellung für private KI-Deployments
Private KI braucht eine betriebliche Grenze: Legen Sie fest, welche Identitäten Prompts, Quelldokumente, Embeddings, Modellgewichte, Logs, Backups und Wiederherstellungsfunktionen sehen oder verändern dürfen. Die Rollenbeispiele hier dienen als Orientierung, nicht als allgemeiner Sicherheitsstandard. Passen Sie die Rechte an Ihre Umgebung an.
Beispielhafte Rollenabgrenzung
- Nutzer des Assistenten: freigegebene Quellen abfragen; kein breiter Korpus-Export.
- Operator: redigierten Zustand und Laufstatus prüfen sowie einen vereinbarten Dienst neu starten; kein Zugriff auf Roh-Prompts und keine Egress-Änderung.
- Security- oder Plattformverantwortliche: Änderungen an Identitäten, Schlüsseln und Daten-Egress prüfen und Wiederherstellung im eigenen Zuständigkeitsbereich freigeben.
- Notfallverantwortliche: eng begrenztes, befristetes Recht für eine genehmigte Wiederherstellung erhalten, protokollieren und danach entfernen.
Alltagsbetrieb von Perimeteränderungen trennen
Beginnen Sie beim Datenfluss: Speicherort der Quellen, Retrieval-Indizes und Caches; das Modell-Endpoint; gespeicherte Diagnosedaten und der Ort für Backups. Ordnen Sie Identitäten anschließend Aufgaben zu. Wer den Assistenten nutzt, braucht vielleicht Zugriff auf freigegebene Quellen, aber keinen Korpus-Export. Ein Operator benötigt möglicherweise redigierte Zustandsdaten zum Neustart, aber keine Berechtigung, Egress- oder Identitätsregeln zu ändern. Rechte für Datenperimeter, Schlüssel und Benutzerrollen bleiben bei Security oder Plattform und einem geprüften Ablauf.
Notfallzugriff wird von täglichen Konten getrennt: einer Person zugeordnet, eng begrenzt, zeitlich befristet, freigegeben und protokolliert. Prüfen Sie, ob sich damit der Dienst wiederherstellen lässt, ohne dauerhaft alle Prompts und Dokumente lesen zu können. Entfernen Sie die Freigabe danach, rotieren Sie offengelegte Zugangsdaten und prüfen Sie das Zugriffsprotokoll.
Beispiel: einen privaten Retrieval-Index wiederherstellen
Illustratives Beispiel: Ein neuer Dokumentimport führt zu unvollständigen Antworten in einem internen Assistenten. Der Operator stoppt weitere Importe und bestimmt die betroffene Indexversion anhand redigierter Laufdaten. Ein Administrator gibt die Wiederherstellung des letzten brauchbaren Snapshots innerhalb der freigegebenen Speichergrenze frei. Der Operator baut den Index neu auf oder verbindet ihn erneut und prüft ihn mit synthetischen Fragen und zugelassenen Testdokumenten, bevor der Zugriff geöffnet wird.
Fehlt dem normalen Operator das Restore-Recht, erhält er einen separaten, protokollierten Notfallzugriff für diese Aufgabe, der danach entfernt wird. Das Team hält Snapshot, möglicherweise veraltete Inhalte und die zuständige Person für den nächsten Import fest. Die Wiederherstellung muss für den gewählten Stack entworfen und getestet werden; das Beispiel setzt keine bestimmte Technik voraus.
Checkliste für Zugriff und Wiederherstellung
- Enthält die Perimeterkarte Prompts, Quellen, Indizes, Gewichte, Logs, Caches und Backups?
- Erhält jede Rolle nur nötige Lese-, Betriebs-, Konfigurations- oder Adminrechte?
- Können Operatoren den Zustand prüfen, ohne Rohinhalte breit einzusehen?
- Ist Notfallzugriff freigegeben, befristet, nachvollziehbar und danach entfernt?
- Wurde ein brauchbarer Zustand wiederhergestellt und Aktualität geprüft?
- Sind Schlüsselrotation, alte Kopien und Zugriffsprotokolle dokumentiert?
Weitere Schritte stehen in unseren Incident Playbooks für private KI und den Grundlagen zum Schlüsselmanagement. Den Umfang finden Sie bei unseren Services für private KI.
Geschrieben vom Clutch Developer Studio in Barcelona. Fragen: info@clutchdeveloper.com