Seminar Eclipse EDC – Security, OAuth 2.0, Secrets und Vault

Das Seminar behandelt die Härtung aller wesentlichen EDC-Kommunikations- und Schlüsselgrenzen. Management-, Protokoll-, Signaling- und Identity-APIs werden differenziert abgesichert; Secrets und kryptografische Schlüssel werden aus der Konfiguration entfernt und in einen kontrollierten Vault- und Rotationsprozess überführt.

Inhaltsübersicht

• Lernziele und fachliche Einordnung
• Schrittweise Seminarinhalte
• Praxisübungen und Laborszenarien
• Zielgruppe und Voraussetzungen
• Didaktik und Arbeitsweise

Lernziele

• Bedrohungen und Vertrauensgrenzen einer EDC-Plattform modellieren.
• Management-, DSP-, Signaling- und Identity-APIs getrennt absichern.
• OAuth-2.0-, TLS- und Netzwerkregeln minimal berechtigt umsetzen.
• Secrets und Schlüssel über Vault oder HSM verwalten.
• Rotation, Audit, Incident und Break-Glass-Verfahren dokumentieren.

Schrittweise Seminarinhalte

1. Bedrohungsmodell und Schutzbedarf

Schwerpunkt: Teilnehmer, APIs, Credentials, Contract Agreements, EDR, Datenquellen, Datenbanken, Vault, Administratoren und Angriffsflächen.

1. Ausgangslage, Schutzbedarf, Abhängigkeiten und Zielkriterien für den Themenblock „Bedrohungsmodell und Schutzbedarf“ erfassen.
2. Relevante Objekte, Rollen, APIs, Zustände und Vertrauensgrenzen anhand von Teilnehmer, APIs, Credentials, Contract Agreements, EDR, Datenquellen, Datenbanken, Vault, Administratoren und Angriffsflächen modellieren.
3. Die erforderliche Konfiguration oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Berechtigungen, Protokollzustände, Protokollierung und Fehlerverhalten mit definierten Positiv- und Negativfällen prüfen.
5. Als Arbeitsergebnis ein priorisiertes Bedrohungs- und Schutzbedarfsmodell dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

2. API- und Netzwerksegmentierung

Schwerpunkt: Management API, DSP API, Control API, Data Plane Public API, Signaling, Identity APIs, Ingress, Firewall, Service Mesh und Zero Trust.

1. Ausgangslage, Schutzbedarf, Abhängigkeiten und Zielkriterien für den Themenblock „API- und Netzwerksegmentierung“ erfassen.
2. Relevante Objekte, Rollen, APIs, Zustände und Vertrauensgrenzen anhand von Management API, DSP API, Control API, Data Plane Public API, Signaling, Identity APIs, Ingress, Firewall, Service Mesh und Zero Trust modellieren.
3. Die erforderliche Konfiguration oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Berechtigungen, Protokollzustände, Protokollierung und Fehlerverhalten mit definierten Positiv- und Negativfällen prüfen.
5. Als Arbeitsergebnis eine klare Kommunikations- und Vertrauenszonenmatrix dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

3. OAuth 2.0 und Dienstidentitäten

Schwerpunkt: Client Credentials, Token Issuer, Audience, Scopes, Rollen, Tokenvalidierung, Ablauf, Rotation und Fehlerfälle.

1. Ausgangslage, Schutzbedarf, Abhängigkeiten und Zielkriterien für den Themenblock „OAuth 2.0 und Dienstidentitäten“ erfassen.
2. Relevante Objekte, Rollen, APIs, Zustände und Vertrauensgrenzen anhand von Client Credentials, Token Issuer, Audience, Scopes, Rollen, Tokenvalidierung, Ablauf, Rotation und Fehlerfälle modellieren.
3. Die erforderliche Konfiguration oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Berechtigungen, Protokollzustände, Protokollierung und Fehlerverhalten mit definierten Positiv- und Negativfällen prüfen.
5. Als Arbeitsergebnis ein minimal berechtigtes Dienstidentitätsmodell dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

4. TLS und Zertifikatsbetrieb

Schwerpunkt: Server- und Clientzertifikate, Trust Stores, Hostnamen, Ketten, Erneuerung, Sperrung, mTLS-Optionen und Clock Skew.

1. Ausgangslage, Schutzbedarf, Abhängigkeiten und Zielkriterien für den Themenblock „TLS und Zertifikatsbetrieb“ erfassen.
2. Relevante Objekte, Rollen, APIs, Zustände und Vertrauensgrenzen anhand von Server- und Clientzertifikate, Trust Stores, Hostnamen, Ketten, Erneuerung, Sperrung, mTLS-Optionen und Clock Skew modellieren.
3. Die erforderliche Konfiguration oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Berechtigungen, Protokollzustände, Protokollierung und Fehlerverhalten mit definierten Positiv- und Negativfällen prüfen.
5. Als Arbeitsergebnis einen belastbaren TLS- und Zertifikatslebenszyklus dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

5. Secrets und Vault

Schwerpunkt: Secret Store, Vault API, Datenbankzugänge, API-Keys, Client Secrets, private Schlüssel, Zugriffstrennung und Cache.

1. Ausgangslage, Schutzbedarf, Abhängigkeiten und Zielkriterien für den Themenblock „Secrets und Vault“ erfassen.
2. Relevante Objekte, Rollen, APIs, Zustände und Vertrauensgrenzen anhand von Secret Store, Vault API, Datenbankzugänge, API-Keys, Client Secrets, private Schlüssel, Zugriffstrennung und Cache modellieren.
3. Die erforderliche Konfiguration oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Berechtigungen, Protokollzustände, Protokollierung und Fehlerverhalten mit definierten Positiv- und Negativfällen prüfen.
5. Als Arbeitsergebnis einen zentralen und auditierbaren Secret-Lifecycle dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

6. HSM, Schlüsselrotation und Recovery

Schwerpunkt: Signing Keys, DID Keys, Issuer Keys, HSM-Slots, Rotation, Parallelgültigkeit, Backup, Recovery und Schlüsselkompromittierung.

1. Ausgangslage, Schutzbedarf, Abhängigkeiten und Zielkriterien für den Themenblock „HSM, Schlüsselrotation und Recovery“ erfassen.
2. Relevante Objekte, Rollen, APIs, Zustände und Vertrauensgrenzen anhand von Signing Keys, DID Keys, Issuer Keys, HSM-Slots, Rotation, Parallelgültigkeit, Backup, Recovery und Schlüsselkompromittierung modellieren.
3. Die erforderliche Konfiguration oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Berechtigungen, Protokollzustände, Protokollierung und Fehlerverhalten mit definierten Positiv- und Negativfällen prüfen.
5. Als Arbeitsergebnis einen kontrollierten kryptografischen Schlüsselbetrieb dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

7. Audit, Incident und Sicherheitsabnahme

Schwerpunkt: Security Logs, privilegierte Aktionen, Fehlversuche, Credential-Missbrauch, EDR-Leaks, Alarmierung, Break Glass und Abnahmetests.

1. Ausgangslage, Schutzbedarf, Abhängigkeiten und Zielkriterien für den Themenblock „Audit, Incident und Sicherheitsabnahme“ erfassen.
2. Relevante Objekte, Rollen, APIs, Zustände und Vertrauensgrenzen anhand von Security Logs, privilegierte Aktionen, Fehlversuche, Credential-Missbrauch, EDR-Leaks, Alarmierung, Break Glass und Abnahmetests modellieren.
3. Die erforderliche Konfiguration oder Prozessfolge am Laborsystem beziehungsweise am Architekturmodell schrittweise umsetzen.
4. Funktion, Berechtigungen, Protokollzustände, Protokollierung und Fehlerverhalten mit definierten Positiv- und Negativfällen prüfen.
5. Als Arbeitsergebnis ein Security-Operations- und Abnahmerunbook dokumentieren, fachlich abnehmen und in einen wiederholbaren Standard überführen.

Praxisübungen und Laborszenarien

• Erstellung einer EDC-spezifischen Bedrohungs- und Vertrauenszonenanalyse.
• Absicherung einer Management API mit OAuth-2.0-Dienstidentitäten.
• Durchführung einer Secret- und Schlüsselrotation mit Negativtests.

Zielgruppe und Voraussetzungen

Zielgruppe: Security Architecture und Engineering, IAM, PKI- und Schlüsselmanagement, DevSecOps, EDC-Administration und Plattformbetrieb.

Voraussetzungen: OAuth-2.0-, TLS-, Netzwerk- und Kryptografiegrundlagen sowie EDC-Komponentenverständnis.

Didaktik und Arbeitsweise

Kurze Fachimpulse werden unmittelbar durch Demonstrationen, strukturierte Konfigurationsschritte, API-Arbeit, Praxisübungen und kontrollierte Fehlerfälle vertieft. Jede Übung verwendet definierte Ausgangswerte, Prüfpunkte und Dokumentationsanforderungen, damit die erarbeiteten Abläufe als technischer Standard wiederholbar bleiben.