Seminar Alternative Trust-Architekturen – Entscheidungsworkshop

Die Wahl einer Vertrauensarchitektur darf nicht aus Modebegriffen oder Produktpräferenzen entstehen. Entscheidend sind Kontrollmodell, Schlüsselverwaltung, Governance, Verfügbarkeit, Datenschutz, Interoperabilität, Betriebsfähigkeit und die Art der zu beweisenden Aussagen.

Inhaltsübersicht

• Seminarprofil
• Zielgruppe
• Lernziele
• Seminarinhalte
• Praxisanteile
• Voraussetzungen

Seminarprofil

Der Workshop liefert keine pauschale Siegertechnologie. Stattdessen wird ein belastbares Entscheidungsverfahren aufgebaut, das Architekturvarianten anhand gewichteter Kriterien, Risiken, Migrationsaufwand und Zielbetriebsmodell bewertet.

Zielgruppe

Enterprise- und Security-Architekten, IAM-Verantwortliche, CISO-Organisationen, Plattformteams, technische Entscheider, Compliance- und Beschaffungsverantwortliche.

Lernziele

• Trust-Anforderungen in messbare Architekturmerkmale überführen
• administrative und kryptographische Vertrauensanker unterscheiden
• PKI, KERI, DID/VC, Federation, Registries und Workload Identity vergleichen
• hybride Zielbilder und Übergangsarchitekturen entwerfen
• eine dokumentierte Entscheidung mit Risiken und nächsten Schritten treffen

Seminarinhalte

Schritt 1: Entscheidungsraum abgrenzen

Der konkrete Use Case wird nach Subjekten, Ressourcen, Aussagen, Transaktionen und Vertrauensdomänen zerlegt. Unterschieden wird zwischen Identifizierung, Authentifizierung, Autorisierung, Attestierung und Nachweisführung.

• Stakeholder und Kontrollgrenzen erfassen
• Schutzbedarf und Ausfallfolgen bestimmen
• Muss- und Kann-Anforderungen trennen

Schritt 2: Vertrauensanker vergleichen

Hierarchische CAs, föderierte Metadaten, verteilte Registries, selbstzertifizierende Identifikatoren und attestierte Workload-Identitäten werden gegenübergestellt. Für jedes Modell werden Vertrauensannahmen und Kompromittierungspfade sichtbar gemacht.

• Root of Trust benennen
• Delegation und Widerruf prüfen
• Abhängigkeit von zentraler Infrastruktur bewerten

Schritt 3: Schlüssel- und Lebenszyklusmodell bewerten

Inception, Enrollment, Rotation, Recovery, Revocation, Ablauf und Schlüsselverlust werden für jede Variante durchgespielt. Besondere Aufmerksamkeit gilt der Frage, wer nach einer Kompromittierung welche Aussage noch verlässlich treffen kann.

• Rotation und Recovery unterscheiden
• Offline- und Online-Abhängigkeiten erfassen
• Kryptoagilität und HSM-Einsatz bewerten

Schritt 4: Interoperabilität und Protokolle prüfen

Datenmodelle und Austauschprotokolle werden getrennt betrachtet. So wird verhindert, dass die Wahl eines Credential-Formats automatisch eine ungeeignete Transport-, Wallet- oder Federation-Architektur erzwingt.

• Format und Protokoll entkoppeln
• Resolver, Registries und Metadaten vergleichen
• Gateways und Übersetzungskosten kalkulieren

Schritt 5: Betrieb, Governance und Compliance einordnen

Rollen, Zulassungsregeln, Audit, Haftung, Service Levels, Datenschutz und Incident Handling werden als gleichwertige Architekturkomponenten behandelt. Technische Dezentralität wird nicht mit fehlender Governance verwechselt.

• Governance Owner festlegen
• Prüf- und Nachweispflichten zuordnen
• Betriebs- und Supportmodell bewerten

Schritt 6: Entscheidungsmatrix erstellen

Die Varianten werden anhand gewichteter Kriterien bewertet. Sensitivitätsanalysen zeigen, welche Annahmen das Ergebnis treiben und wo Pilotierung statt Papierentscheidung erforderlich ist.

• Kriterien gewichten
• Knock-out-Bedingungen definieren
• Unsicherheiten und Beweisbedarf dokumentieren

Schritt 7: Zielbild und Migrationspfad planen

Aus der Entscheidung entsteht ein stufenweises Zielbild mit Pilot, Integrationsgrenzen, Rückfalloption und Abnahmekriterien. Bestehende PKI-, IAM- und API-Strukturen werden soweit sinnvoll weiterverwendet.

• Koexistenz statt Big Bang planen
• Pilotumfang und Erfolgsmetriken bestimmen
• technische Schulden und Exit-Strategie erfassen

Praxisanteile

• Anforderungskatalog für einen eigenen Use Case erstellen
• Trust-Annahmen in Angriffs- und Ausfallszenarien testen
• gewichtete Entscheidungsmatrix aufbauen
• hybrides Zielbild mit Pilot- und Migrationsstufen entwerfen

Voraussetzungen

Erfahrung mit IAM, PKI, digitalen Signaturen oder verteilten Systemen. Konkrete Anwendungsfälle und Randbedingungen der eigenen Organisation erhöhen den Nutzen.