Rollen und Rechte für KI aus der Benutzerverwaltung übernehmen

Warum sollte die KI keine eigenen Konten haben?

Jede Anwendung mit eigener Kontenpflege ist eine Stelle mehr, an der Austritte vergessen werden. Für eine KI-Plattform, die Zugriff auf Dokumente, E-Mails und Fachsysteme hat, wäre das ein Risiko. Das BSI fordert im IT-Grundschutz-Baustein ORP.4, Identitäten und Rechte geregelt zu vergeben, zu ändern und zu entziehen. Am einfachsten gelingt das, wenn die KI keine eigene Quelle für Identitäten ist, sondern die vorhandene Benutzerverwaltung nutzt.

Welche Standards gibt es für die Anbindung?

Standard	Wofür	Typisch bei
LDAP	Verzeichnis abfragen: Personen, Gruppen, Attribute	Active Directory, OpenLDAP
OpenID Connect (OIDC)	Anmeldung über einen zentralen Anmeldedienst, auf Basis von OAuth 2.0	Entra ID, Keycloak, viele Cloud-Dienste
SAML 2.0	Anmeldung über einen zentralen Anmeldedienst, XML-basiert	ältere Anmeldedienste, Portale der Verwaltung
SCIM	Konten und Gruppen automatisch anlegen und entfernen	Cloud-Verzeichnisse

Bei OIDC und SAML sieht die Anwendung das Passwort nie: Sie leitet zur Anmeldung an den Anmeldedienst weiter und bekommt eine signierte Bestätigung zurück, oft mit den Gruppen der Person. Ein zweiter Faktor lässt sich dort zentral erzwingen.

Wie werden aus Gruppen Rechte in der KI?

Die Benutzerverwaltung sagt, wer jemand ist und zu welchen Gruppen er gehört. Was eine Gruppe in der KI darf, legt die KI-Plattform fest. Bewährt hat sich:

• Wenige Rollen: Personen, die die KI nutzen, und Administratoren, die sie einrichten. Jede weitere Rolle muss gepflegt und geprüft werden.
• Freigaben an Gruppen: Apps, Wissenssammlungen und Modelle werden für Gruppen freigegeben, nicht für einzelne Namen. Wechselt jemand die Abteilung, ändern sich seine Freigaben mit.
• Rechte in Fachsystemen bleiben dort: Was jemand in SharePoint, im Ticketsystem oder im ERP sehen darf, entscheidet weiter dieses System. Die KI liest mit dem Zugang der Person. Rechte für KI mit Dokumenten →
• Keine neuen Profile: Die KI bildet keine eigenen Merkmale über Personen, die über das Verzeichnis hinausgehen. Das erleichtert auch die Gespräche mit Betriebs- oder Personalrat.

Was gilt bei Eintritt, Wechsel und Austritt?

1. Eintritt: Mit dem Konto im Verzeichnis kann sich die Person anmelden; Freigaben ergeben sich aus ihren Gruppen.
2. Wechsel: Neue Abteilung, neue Gruppen, neue Freigaben, ohne Handarbeit in der KI.
3. Austritt: Konto im Verzeichnis sperren, und die nächste Anmeldung an der KI scheitert. Prüfen Sie, wie lange Sitzungen laufen, und ob persönliche Schlüssel für Schnittstellen widerrufen werden.
4. Regelmäßige Prüfung: Wer ist Administrator der KI? Welche Gruppen haben welche Freigaben? Einmal im Quartal ist ein gutes Maß.

Für Österreich: Wie sich ID Austria und der Portalverbund anbinden lassen, steht in ID Austria und KI.

Wie geht das mit basebox?

Die Anmeldung an basebox läuft über Keycloak mit OpenID Connect; basebox selbst sieht nie ein Passwort. Angebunden wird jede Benutzerverwaltung, die LDAP, OIDC oder SAML spricht, zum Beispiel Active Directory, Entra ID oder WSO2. Alle melden sich mit dem Konto an, das sie schon haben; Gruppen und Rollen kommen aus Ihrer Benutzerverwaltung, und ändert sich dort etwas, gilt es auch in basebox. Ein zweiter Faktor ist als Schalter je Organisation möglich, mit einer Authenticator-App oder optional per SMS über ein Gateway, das Sie anbinden. Passwortregeln, Sitzungsdauer und Sperren nach Fehlversuchen stellt Ihr Administrator in Keycloak ein.

basebox kennt bewusst wenige Rollen: Personen und Administratoren. Ihr Administrator schaltet frei, was es gibt; wer eine App baut, gibt sie für Gruppen oder einzelne Personen frei, zum Nutzen oder zum Bearbeiten. Auch Modelle lassen sich nur für bestimmte Gruppen freigeben. Rollen kommen aus Ihrer Benutzerverwaltung, neue Profile entstehen nicht. In der Cloud hat jede Organisation eine eigene Benutzerverwaltung (Keycloak). Rechteänderungen stehen im Audit-Log.