Seminar Kuzzle IoT Multi-Tenancy und Mandanten-Governance

Das Seminar übersetzt organisatorische Mandanten- und Untermandantenstrukturen in Gruppen, Profile, Datenräume und delegierte Administration. Isolation, standardisierte Berechtigungspakete, Onboarding, Wechsel, Offboarding und Rezertifizierung werden mit automatisierten Negativtests abgesichert. 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
• Mandantenmodell und Verantwortungsgrenzen
• Berechtigungspakete und Delegation
• Daten- und Realtime-Isolation testen
• Onboarding, Wechsel, Offboarding und Audit
• Praxisprojekt und Lernerfolgskontrolle

Zielgruppe und Voraussetzungen

Kapitelinhaltsverzeichnis

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

Zielgruppe: IoT-Plattformarchitektur, Security Engineering, Service Provider, Plattformadministration, Compliance und technische Produktverantwortung.

Voraussetzungen: Grundkenntnisse zu Kuzzle-Rollen und Profilen, Mandantenmodellen, APIs und automatisierten Berechtigungstests.

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 Governance- und Delegationsmodell, technische Implementierung und Isolationstests voneinander abhängen, aber getrennt geprüft werden müssen. Die Dauer erlaubt außerdem einen vollständigen Mandantenlebenszyklus statt einer reinen Erstkonfiguration.

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. Mandantenmodell und Verantwortungsgrenzen

Kapitelinhaltsverzeichnis

• Tenant und Subtenant
• Organisation und Servicegrenzen
• Datenbesitz
• Governance-Rollen

Dieses Kapitel verbindet Tenant und Subtenant, Organisation und Servicegrenzen, Datenbesitz und Governance-Rollen. 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 – Organisationen, Verträge und technische Servicegrenzen in ein Mandantenmodell überführen: 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 – Untermandanten nur bei eigener Verantwortlichkeit oder Isolation begründen: 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 – Datenbesitz, gemeinsame Stammdaten und globale Funktionen eindeutig zuordnen: 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 – Tenant-Administration, Plattformbetrieb und Support als getrennte Governance-Rollen definieren: 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 – Grenzfälle wie Fusion, Aufteilung und temporären Zugriff bereits im Modell berücksichtigen: 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 Tenant und Subtenant ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Organisation und Servicegrenzen erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Governance-Rollen lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein mehrstufiges Betreiber-Kunden-Modell wird mit Verantwortungs- und Datenbesitzmatrix beschrieben. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

2. Berechtigungspakete und Delegation

Kapitelinhaltsverzeichnis

• Standardrollen
• Profilvorlagen
• Gruppen
• Delegierte Administration

Dieses Kapitel verbindet Standardrollen, Profilvorlagen, Gruppen und Delegierte Administration. 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 – Wiederverwendbare Rollen für Lesen, Bearbeiten, Geräteverwaltung und Reporting 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 – Profile mit Mandantenrestriktionen aus standardisierten Rollen zusammensetzen: 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 – Gruppen und Namensräume so anlegen, dass Eigentümerschaft erkennbar bleibt: 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 – Delegierte Administration auf klar begrenzte Aktionen und Zielobjekte beschränken: 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 – Ausnahmen zeitlich befristen, begründen und gesondert überwachen: 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 Standardrollen ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Profilvorlagen erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Delegierte Administration lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein Tenant-Administrator verwaltet eigene Benutzer und Geräte, ohne globale Konfiguration oder fremde Daten zu erreichen. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

3. Daten- und Realtime-Isolation testen

Kapitelinhaltsverzeichnis

• API-Zugriffe
• Suche und Aggregationen
• Subscriptions
• Administrative Querschnittsfunktionen

Dieses Kapitel verbindet API-Zugriffe, Suche und Aggregationen, Subscriptions und Administrative Querschnittsfunktionen. 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 – Positivtests für erlaubte Tenant-Funktionen automatisieren: 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 – Direkte Dokumentzugriffe auf fremde Identitäten und Collections negativ testen: 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 – Suche, Aggregationen und Exporte auf unbeabsichtigte Querschnittsdaten prüfen: 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 – Realtime-Filter und Notifications mit fremden Geräteereignissen angreifen: 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 – Administrative Actions und Fehlermeldungen auf Informationsabfluss untersuchen: 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 API-Zugriffe ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Suche und Aggregationen erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Administrative Querschnittsfunktionen lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Eine automatisierte Isolationstestsuite prüft Daten, Suche, Realtime und Administration zwischen zwei Mandanten. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

4. Onboarding, Wechsel, Offboarding und Audit

Kapitelinhaltsverzeichnis

• Provisionierung
• Konfigurationsvorlagen
• Organisationsänderung
• Rezertifizierung und Nachweis

Dieses Kapitel verbindet Provisionierung, Konfigurationsvorlagen, Organisationsänderung und Rezertifizierung und Nachweis. 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 – Onboarding aus genehmigten Vorlagen mit eindeutigen Eigentümern automatisieren: 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 – Erstzugänge, Standardprofile, Gruppen und Datenräume vollständig prüfen: 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 – Mandantenwechsel oder Aufteilung mit Daten- und Rechteinventar planen: 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 – Beim Offboarding Zugänge entziehen, Daten behandeln und delegierte Schlüssel rotieren: 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 – Regelmäßige Rezertifizierung und unveränderlichen Änderungsnachweis organisieren: 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 Provisionierung ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Konfigurationsvorlagen erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Rezertifizierung und Nachweis lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein Mandant wird angelegt, organisatorisch verändert und anschließend kontrolliert außer Betrieb genommen. 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.