Seminar Kuzzle Authentifizierung, Rollen, Profile und Berechtigungen

Das Seminar entwickelt ein prüfbares Berechtigungsmodell aus Rollen, Profilen und Benutzern. Neben Login und Token-Lebenszyklus stehen Least Privilege, Datenbereichseinschränkungen, Negativtests, administrative Trennung und revisionsfähige Änderungen im Vordergrund. Theorie, Demonstration und Laborarbeit wechseln in kurzen Zyklen. Jeder technische Schritt wird durch eine Kontrollabfrage, einen Negativtest oder eine nachvollziehbare Zustandsprüfung abgeschlossen.

Inhaltsübersicht

• Zielgruppe und Voraussetzungen
• Didaktischer Zuschnitt
• Berechtigungsanforderungen und Bedrohungsmodell
• Rollen, Profile und Benutzer umsetzen
• Authentifizierung, Token und API Keys
• Berechtigungstests, Audit und Änderungskontrolle
• Praxisprojekt und Lernerfolgskontrolle

Zielgruppe und Voraussetzungen

Kapitelinhaltsverzeichnis

• Adressierte Rollen
• Erforderliche Vorkenntnisse
• Labor- und Arbeitsmittel
• Einstiegskontrolle

Zielgruppe: Security Engineering, IAM, Kuzzle-Administration, Backend-Entwicklung, technische Architektur und Revision.

Voraussetzungen: Grundkenntnisse in Authentifizierung, Autorisierung, JSON und API-Tests; Zugriff auf eine Laborumgebung mit mehreren Testidentitäten.

Zu Beginn werden Vorkenntnisse, Laborzugang, Namenskonventionen und Sicherheitsregeln geprüft. Fehlende Grundlagen werden als konkrete Vorbereitungspunkte dokumentiert; produktive Systeme und reale Zugangsdaten werden in den Übungen nicht verwendet.

Didaktischer Zuschnitt

Kapitelinhaltsverzeichnis

• Begründung der Dauer
• Arbeitsweise
• Dokumentationsstandard
• Qualitätssicherung

Begründung der Dauer: Drei Tage sind notwendig, weil Berechtigungsentwurf, technische Umsetzung und systematische Abnahme getrennt durchgeführt werden müssen. Erst die Kombination aus Modellierung, Session-Lebenszyklus und belastbaren Negativtests verhindert scheinbar funktionierende, aber zu weit gefasste Zugriffe.

Die Lerneinheiten folgen dem Muster Analyse, Aufbau, Funktionsnachweis, Fehlerfall und Wiederholung. Konfigurationen und Testdaten werden versionierbar gehalten. Entscheidungen werden mit Annahme, Alternative, Risiko und Prüfmethode dokumentiert. Dadurch entsteht neben dem fachlichen Verständnis ein direkt nutzbares Arbeitsverfahren.

1. Berechtigungsanforderungen und Bedrohungsmodell

Kapitelinhaltsverzeichnis

• Akteure und Vertrauenszonen
• Fachaufgaben und API-Aktionen
• Datenbereiche
• Missbrauchs- und Fehlkonfigurationsfälle

Dieses Kapitel verbindet Akteure und Vertrauenszonen, Fachaufgaben und API-Aktionen, Datenbereiche und Missbrauchs- und Fehlkonfigurationsfälle. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Akteure, technische Identitäten und administrative Konten vollständig erfassen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Fachaufgaben in konkret benötigte Controller-Aktionen zerlegen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Index- und Collection-Grenzen mit Mandanten- oder Organisationsgrenzen abgleichen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Missbrauchsfälle für anonyme, authentifizierte und privilegierte Zugriffe formulieren: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Eine priorisierte Berechtigungsmatrix mit Nachweisart und Verantwortlichkeit freigeben: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Akteure und Vertrauenszonen ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Fachaufgaben und API-Aktionen erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Missbrauchs- und Fehlkonfigurationsfälle lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Für einen mehrstufigen Anwendungsfall entsteht ein Bedrohungsmodell mit Berechtigungsmatrix und Testfällen. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

2. Rollen, Profile und Benutzer umsetzen

Kapitelinhaltsverzeichnis

• Rollenmodell
• Profile und Restriktionen
• Benutzerinhalte und Credentials
• Administrative Trennung

Dieses Kapitel verbindet Rollenmodell, Profile und Restriktionen, Benutzerinhalte und Credentials und Administrative Trennung. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Rollen ausschließlich aus benötigten API-Aktionen aufbauen und Wildcards begründen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Profile als wiederverwendbare Kombinationen von Rollen und Datenrestriktionen definieren: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Benutzer mit minimalen Profilzuweisungen anlegen und fachliche Zusatzdaten getrennt halten: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Verwaltungsrechte für Benutzer, Daten und Plattformbetrieb voneinander trennen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Konfigurationen exportieren, versionieren und durch Vier-Augen-Prüfung freigeben: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Rollenmodell ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Profile und Restriktionen erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Administrative Trennung lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Drei Fachrollen und zwei Administrationsrollen werden aufgebaut, dokumentiert und gegeneinander abgegrenzt. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

3. Authentifizierung, Token und API Keys

Kapitelinhaltsverzeichnis

• Login-Strategien
• Token-Lebensdauer und Erneuerung
• Logout und Sperrung
• Technische Schlüssel

Dieses Kapitel verbindet Login-Strategien, Token-Lebensdauer und Erneuerung, Logout und Sperrung und Technische Schlüssel. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Credential-Arten nach Benutzer-, Dienst- und Automatisierungszugriff unterscheiden: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Token-Lebensdauer anhand Risiko, Nutzung und Wiederanmeldung festlegen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Erneuerung, Logout und globale Abmeldung als testbare Zustandsübergänge implementieren: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – API Keys mit Zweck, Besitzer, Ablauf und Rotationsverfahren registrieren: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Kompromittierung simulieren und Sperrung sowie Wiederherstellung zeitlich messen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Login-Strategien ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Token-Lebensdauer und Erneuerung erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Technische Schlüssel lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein vollständiger Authentifizierungslebenszyklus wird für interaktive und technische Identitäten umgesetzt. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

4. Berechtigungstests, Audit und Änderungskontrolle

Kapitelinhaltsverzeichnis

• Positiv- und Negativtests
• Rechteeskalation
• Änderungsnachweis
• Regelmäßige Rezertifizierung

Dieses Kapitel verbindet Positiv- und Negativtests, Rechteeskalation, Änderungsnachweis und Regelmäßige Rezertifizierung. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Für jede Rollenanforderung mindestens einen erlaubten und einen verbotenen Test definieren: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Querschnittstests gegen fremde Collections, administrative Actions und anonyme Zugriffe ausführen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Fehlerantworten protokollieren, ohne Tokens oder Credentials offenzulegen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Änderungen an Rollen und Profilen mit Anlass, Freigabe und Rückfallversion dokumentieren: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Ein Rezertifizierungsverfahren mit Eigentümer, Intervall und Entzugsprozess festlegen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Positiv- und Negativtests ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Rechteeskalation erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Regelmäßige Rezertifizierung lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Eine Testmatrix weist nach, dass fachliche Rechte funktionieren und nicht vorgesehene Zugriffspfade geschlossen sind. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

Praxisprojekt und Lernerfolgskontrolle

Kapitelinhaltsverzeichnis

• Projektauftrag
• Zwischenprüfungen
• Fehler- und Sicherheitsnachweis
• Technische Abnahme

Das Praxisprojekt verbindet die Kapitel zu einer konsistenten Laborlösung. Vor jedem Inkrement werden Ausgangszustand, Ziel, Eingaben und Abnahmekriterien festgelegt. Nach der Umsetzung folgen Funktionsprüfung, Negativtest, kurze Dokumentationskontrolle und Rücksetzung auf einen bekannten Zustand.

1. Projektauftrag schneiden: Ein fachlich begrenzter Anwendungsfall wird in Daten, Akteure, Schnittstellen, Berechtigungen und Betriebsanforderungen zerlegt.
2. Inkremente umsetzen: Die Kapitelbausteine werden schrittweise integriert; nach jedem Inkrement bleibt die Laborlösung lauffähig.
3. Fehler nachweisen: Mindestens ein Berechtigungs-, Daten-, Verbindungs- oder Konfigurationsfehler wird kontrolliert ausgelöst und diagnostiziert.
4. Abnahme durchführen: Eine technische Checkliste prüft Funktion, Sicherheit, Wiederholbarkeit, Protokollierung und Rückfallfähigkeit.
5. Lernstand dokumentieren: Offene Vertiefungen werden als priorisierte Aufgaben mit benötigtem Nachweis festgehalten.

Die Lernerfolgskontrolle besteht aus kurzen Verständnisfragen, beobachteten Laboraufgaben, einer Fehlersuche und der technischen Abnahme des Praxisprojekts. Bewertet werden nicht nur funktionierende Ergebnisse, sondern auch Begründung, Nachweis, sichere Fehlerbehandlung und Reproduzierbarkeit.