10. Administration

Zielgruppe

Dieses Kapitel richtet sich an IT-Administratoren und Systemverantwortliche.

10.1 Ersteinrichtung der GovAI-Instanz

Nach der Bereitstellung durch publicplan durchlaufen Administratoren eine strukturierte Ersteinrichtung:

Schritt	Aufgabe	Details
1	Admin-Zugang absichern	Initiales Passwort ändern, 2FA aktivieren
2	Netzwerkkonfiguration	Firewall-Regeln, Proxy-Einstellungen, SSL-Zertifikate prüfen
3	SSO/IdP anbinden	Identity Provider konfigurieren (AD, Keycloak, Entra ID)
4	API-Schlüssel hinterlegen	KI-Anbieter-Keys einpflegen, Modelle aktivieren
5	Data Guard konfigurieren	Klassifizierungsregeln, Regex-Erweiterungen, Sicherheitsstufen
6	Benutzerverwaltung	Rollen und Gruppen anlegen, Nutzende einladen
7	Inhalte einrichten	Assistenten, Werkzeuge, Wissensdatenbanken konfigurieren
8	Kontingente setzen	Token-Limits, Benachrichtigungsschwellen, Empfänger
9	Audit-Webhook	Zielsystem für Audit-Logs konfigurieren
10	Testbetrieb	Systemtest mit repräsentativen Szenarien, Logs prüfen

10.2 SSO-Anbindung (Identity Provider)

Unterstützte Identity Provider

IdP	Protokoll	Status
Microsoft Active Directory On-Prem	OIDC via Keycloak	Primäre Zielumgebung
Microsoft Entra ID (Azure AD)	OIDC	Architektonisch vorbereitet
Keycloak	OIDC	Integriert
Weitere OIDC-kompatible IdPs	OIDC/SAML	Konfigurierbar

SSO-Login-Flow

1. Nicht-authentifizierte Nutzende werden beim Plattformaufruf automatisch zum konfigurierten IdP weitergeleitet
2. Nach erfolgreicher Authentifizierung erhält GovAI ein standardkonformes Token (OIDC ID-Token oder SAML-Assertion)
3. Auf Basis des Tokens wird die Nutzeridentität eindeutig bestimmt
4. GovAI prüft, ob ein provisioniertes Konto vorhanden ist
5. Kein vorhandenes oder deaktiviertes Konto → Zugriff verweigert + Hinweis

Benutzer provisionieren (Einladungsverfahren)

Da keine automatische SCIM-Synchronisierung im Standard vorgesehen ist, erfolgt die Provisionierung manuell:

1. Bereitstellung einer Nutzerliste (CSV/XLSX) durch den Auftraggeber mit: Vorname, Nachname, E-Mail, Rolle
2. Nutzende werden per E-Mail zur Organisation eingeladen
3. Ein Benutzerkonto gilt erst nach Annahme der Einladung als aktiv

SCIM-Vorbereitung

Die Architektur unterstützt eine spätere SCIM-basierte Synchronisierung (z. B. über Entra ID, Keycloak). SCIM kann gesondert beauftragt und eingerichtet werden. Bis zur Einrichtung erfolgt die Verwaltung manuell.

10.3 Benutzerverwaltung

Zugriff: Einstellungen → Organisation → Mitglieder

Nutzende einladen

1. Klicken Sie auf „Einladen"
2. E-Mail-Adresse eingeben
3. Rolle zuweisen (Mitglied / Maintainer / Besitzer / Custom Role)
4. Einladung versenden → Nutzende erhalten eine E-Mail und können beitreten

Mehrfacheinladungen

Die gleichzeitige Einladung mehrerer Nutzender ist über Kommatrennung der eingegebenen E-Mail-Adressen möglich. Alle Nutzenden werden mit der zugewiesenen Rolle eingeladen. :::

Rolle ändern

• Per Dropdown direkt in der Mitgliedertabelle
• Änderungen werden nach „Speichern" sofort wirksam
• Rollenänderungen werden im Audit-Log protokolliert

Nutzende entfernen

• Über das rote Papierkorb-Symbol Auswahl tätigen, durch Schaltfläche "Speichern" Auswahl bestätigen
• Zugang wird sofort entzogen, laufende Sitzungen werden beendet
• Der Zugang kann reaktiviert werden, indem dieselbe E-Mail-Adresse erneut eingeladen wird

10.4 Rollenmodell (RBAC) konfigurieren

Zugriff: Einstellungen → Organisation → Rollen

Standardrollen

Drei Standardrollen sind unveränderlich vordefiniert:

Rolle	Kurzbeschreibung
Mitglied	Chat, Werkzeuge, Assistenten, Community nutzen
Maintainer	Zusätzlich: Konfiguration, Werkzeuge/Assistenten verwalten
Besitzer (Owner)	Vollständige Kontrolle inkl. Nutzerverwaltung, Kontingente, Audit

Detaillierte Berechtigungsmatrix: Anlage 1 des Pflichtenhefts.

Custom Roles erstellen

1. Klicken Sie auf „+ Rolle erstellen"
2. Rollennamen vergeben
3. Basisrolle als Ausgangspunkt wählen
4. Berechtigungen per Checkbox erweitern oder einschränken
5. Speichern

Wichtig bei Rollenlöschung: Alle Nutzenden mit einer gelöschten Custom Role werden automatisch der Standardrolle „Mitglied" zugewiesen.

Berechtigungsprinzipien

• Direkte Berechtigungsvergabe an einzelne Nutzende (ohne Rolle) ist nicht möglich
• Alle Berechtigungsprüfungen erfolgen serverseitig – nicht nur durch UI
• Änderungen an Rollen/Berechtigungen werden im Audit-Log protokolliert
• Eine Person kann in verschiedenen Organisationen unterschiedliche Rollen haben

10.5 Mandantenfähigkeit

GovAI ist für mehrere Organisationen ausgelegt:

• Daten, Einstellungen, Rollen, Assistenten und Wissensdatenbanken sind pro Organisation getrennt
• Keine organisations­übergreifenden Datenzugriffe möglich
• Kontingente, Sperren und Benachrichtigungen wirken strikt organisationsspezifisch
• Nutzende können mehreren Organisationen zugeordnet sein, mit je eigenen Rollen

Anbindung weiterer Organisationen

Die Einrichtung zusätzlicher Mandanten/Organisationen ist nicht im Standard-Leistungsumfang enthalten und kann gesondert beauftragt werden.

10.6 Audit-Webhook konfigurieren

GovAI sendet Audit-Events an ein externes Zielsystem (Logging/SIEM) per Webhook:

Konfiguration: Einstellungen → Organisation → Audit-Webhook

Einstellung	Beschreibung
Webhook-URL	Endpunkt Ihres Logging-Systems (SIEM, Archiv) + REST-Methode
Request Header	ggf. notwendige Header für das Audit-System (optional)
Aktivieren/Deaktivieren	Versand ein-/ausschalten
Status	Letzter Versand: erfolgreich/fehlgeschlagen + Zeitpunkt

Ohne konfiguriertes Zielsystem kein externer Audit-Log

Wenn kein Webhook konfiguriert ist, werden Audit-Events nicht extern übertragen. Der Hinweis „Audit-Ziel nicht konfiguriert" erscheint in den Einstellungen. Für Produktivbetrieb ist ein externes Zielsystem dringend empfohlen.

Protokollierte Ereignisse:

• Admin-Aktionen (Rollenänderungen, Konfigurationsänderungen, Feature-Aktivierungen)
• Sicherheitsereignisse (Login/Logout, fehlgeschlagene Anmeldungen, abgelehnte Zugriffe)
• Datenschutzereignisse (PII-Maskierung angewendet/fehlgeschlagen)
• Policy-Updates (Änderungen an Regeln/Konfigurationen)
• Webhook-Konfigurationsänderungen selbst
• Purge-/Löschereignisse (automatisierte Löschläufe)

Mindestinhalt je Audit-Event: Zeitstempel · Organisation/Mandant · Ereignistyp · auslösende Identität + Rolle · Ergebnis (erfolgreich/fehlgeschlagen) · betroffene Ressource · eindeutige Ereignis-ID

Datenschutz im Audit-Log

Audit-Events enthalten keine Prompt-/Upload-/Antwortinhalte und keine Secrets. Benutzerbezüge sind auf das notwendige Minimum beschränkt (Nutzer-ID, nicht Klartextname).

10.7 Hosting-Modelle

Modell	Beschreibung	Eignung
SaaS (EU-Cloud)	Betrieb durch publicplan auf IONOS-Infrastruktur in Deutschland/EU	Standard; kein eigener Infrastrukturaufwand
Private Cloud	Dedizierte Cloud-Umgebung der Organisation	Mehr Kontrolle, geringerer Aufwand
On-Premise	Vollständiger Betrieb im eigenen Rechenzentrum	Maximale Sicherheit, VS-Umgebungen
Hybrid	Kombination lokaler Modelle + Cloud-Dienste	Flexible Szenarien

Hosting-Garantien (SaaS):

• Betrieb ausschließlich auf IONOS-Infrastruktur in Deutschland/EU
• ISO/IEC 27001 zertifiziertes Rechenzentrum
• Keine Drittlandübermittlungen
• Verfügbarkeit und SLAs gemäß IONOS-Leistungsbeschreibung

10.8 Branding / White-Label

GovAI unterstützt organisationsspezifisches Branding:

Zugriff: Einstellungen → Organisation → Allgemein → CSS-Datei

• Primärfarben und Akzentfarben überschreiben
• Eigenes Logo einbinden / Standardlogo ersetzen
• Weitere stilistische Anpassungen (Schriftgrößen, Abstände)
• Branding gilt organisationsspezifisch (kein Einfluss auf andere Mandanten)

Sicherheit beim Branding

Das Custom CSS wird serverseitig auf Sicherheit geprüft. Das Einbetten externer Skripte über CSS ist nicht möglich.