Seminar EBSI und swiyu – Betrieb, Sicherheit und Schlüsselmanagement

Der produktive Betrieb mehrerer Trust-Infrastrukturen verlangt klare Zuständigkeiten, getrennte Schlüsselrollen, kontrollierte Änderungen und belastbare Überwachung. Das Seminar entwickelt ein gemeinsames Betriebs- und Sicherheitsmodell für EBSI- und swiyu-Komponenten.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• Betriebsverantwortung und Sicherheitszonen für beide Ökosysteme eindeutig festlegen
• Schlüssel-, Secret- und Token-Lebenszyklen mit Rotation und Notfallverfahren organisieren
• Monitoring, Statusprüfung, Registry-Abhängigkeiten und Incident Response zusammenführen
• Änderungen, Updates, Backup, Wiederanlauf und Auditnachweise reproduzierbar gestalten

Zielgruppe

Plattformbetrieb, DevOps, Security Operations, PKI- und HSM-Verantwortliche, technische Anwendungsbetreuung, Auditoren und Service Management.

Voraussetzungen

Kenntnisse in Linux- oder Containerbetrieb, TLS, OAuth, Schlüsselmanagement, Logging und Monitoring. Grundverständnis von EBSI und swiyu ist erforderlich.

Seminarinhalte

1. Schritt 1: Betriebsobjekte und Servicegrenzen inventarisieren

   Issuer, Verifier, Wallet-Schnittstellen, Datenbanken, DID-Resolver, Registries, Statusdienste, Reverse Proxies und Verwaltungs-APIs werden mit Owner, Kritikalität und Wiederanlaufziel erfasst.

2. Schritt 2: Sicherheitszonen und Zugriffspfade festlegen

   Öffentliche Protokollendpunkte, interne Management-APIs, Administrationszugänge, Datenbanken und Schlüsselkomponenten werden segmentiert. Maschinenidentitäten und minimale Rechte ersetzen pauschale Netzwerkfreigaben.

3. Schritt 3: Schlüsselrollen trennen

   DID-Update-, Assertion-, Authentication-, Credential-, Statuslisten- und Protokollsignaturschlüssel werden nach Zweck, Algorithmus, Aufbewahrung, Zugriff und Rotationsintervall unterschieden.

4. Schritt 4: Secrets und Tokens kontrollieren

   Client Secrets, Refresh Tokens, Zugriffstokens, Datenbankkennungen und HSM-Zugänge erhalten sichere Ablage, Ausgabeprozesse, Ablaufüberwachung und dokumentierte Erneuerung.

5. Schritt 5: Status- und Registry-Abhängigkeiten betreiben

   Auflösung, Caching, Time-outs, Verfügbarkeit, Versionswechsel und Konsistenz von DID-, Trust-, Schema- und Statusinformationen werden mit definierten Degradationsregeln behandelt.

6. Schritt 6: Monitoring und Protokollierung aufbauen

   Technische Verfügbarkeit, Latenz, Fehlerraten, abgewiesene Flows, Signaturprobleme, Schlüsselereignisse und Statuslistenänderungen werden korreliert, ohne unnötige personenbezogene Daten zu protokollieren.

7. Schritt 7: Backup und Wiederanlauf testen

   Datenbanken, Konfigurationen, DID-Logs, Metadaten, Statuslistenverwaltung und verschlüsselte Schlüsselbackups werden nach Wiederherstellbarkeit und Reihenfolge geprüft. Nicht exportierbare Schlüssel erhalten alternative Wiederanlaufverfahren.

8. Schritt 8: Änderungen und Profilversionen steuern

   Komponentenupdates, API- oder Profilwechsel, neue Algorithmen und Registry-Änderungen werden über Testumgebung, Kompatibilitätsmatrix, Freigabe und Rückfallplan kontrolliert ausgerollt.

9. Schritt 9: Incident Response durchführen

   Kompromittierter Schlüssel, fehlerhafte Credentials, falscher Status, Registry-Ausfall, Token-Missbrauch und Datenabfluss werden mit Eindämmung, Rotation, Sperrung, Kommunikation und Nachweis behandelt.

10. Schritt 10: Betriebshandbuch und Prüfnachweise konsolidieren

    Runbooks, Schichtübergaben, Alarmwege, Wartungsfenster, regelmäßige Kontrollen und Audit-Evidenzen werden in einer einheitlichen Betriebsstruktur zusammengeführt.

Praxisübungen

• Schlüssel- und Secret-Inventar mit Rotation, Owner und Notfallmaßnahme erstellen
• Monitoring- und Alarmkonzept für eine Dual-Stack-Issuer-/Verifier-Landschaft entwickeln
• Wiederanlauf nach Ausfall von Registry-Zugriff und Datenbank durchspielen
• Incident-Szenario mit kompromittiertem Credential-Signaturschlüssel bearbeiten

Methodik

Fachvortrag, Betriebsdesign, Threat- und Failure-Szenarien, Runbook-Arbeit, Demonstrationen und Tabletop-Übungen. Drei Tage sind erforderlich, um Schlüsselbetrieb, technische Verfügbarkeit und organisatorische Reaktion zu einem belastbaren Gesamtprozess zu verbinden.