Seminar Keylime – Intensivseminar Integritätsrichtlinien und Vertrauensentscheidungen

Überblick

Das Seminar behandelt die vollständige Kette von authentifizierter Attestation über Boot- und Runtime-Policy bis Secret-Freigabe und Reaktion. Theorie, Konfiguration und technische Prüfung werden in einem durchgängigen Szenario verbunden, sodass aus einzelnen Funktionen ein nachvollziehbarer Betriebs- oder Sicherheitsprozess entsteht.

Fünf Tage bilden die zulässige Maximaldauer und sind erforderlich, um die gebündelten Einzelthemen ohne reine Überblicksvermittlung in einer durchgängigen Referenzumgebung umzusetzen, negativ zu testen und betriebsfähig zu dokumentieren. Im Mittelpunkt stehen reproduzierbare Arbeitsschritte, positive und negative Testfälle sowie eine dokumentierte technische Abnahme.

Inhaltsübersicht

1. Tag 1: mTLS, Rollen und Autorisierung umsetzen
2. Tag 1: Pull- und Push-Kommunikationsmodell vergleichen
3. Tag 2: PCRs, UEFI Event Logs und Measured Boot analysieren
4. Tag 2: Bootpolicy-Lebenszyklus gestalten
5. Tag 3: IMA Runtime Integrity Monitoring aktivieren
6. Tag 3: Runtime-Verletzung bis zur Datei verfolgen
7. Tag 4: Keylime-Policy signieren und releasen
8. Tag 4: Secure Payload provisionieren und rotieren
9. Tag 5: Revocation, Webhook und Quarantäne automatisieren
10. Tag 5: Wiederfreigabe und End-to-End-Prüfung durchführen

Lernziele

• Die vollständige kette von authentifizierter attestation über boot- und runtime-policy bis secret-freigabe und reaktion fachlich einordnen und für ein konkretes Einsatzszenario planen.
• Tag 1: mTLS, Rollen und Autorisierung umsetzen.
• Tag 1: Pull- und Push-Kommunikationsmodell vergleichen.
• Tag 2: PCRs, UEFI Event Logs und Measured Boot analysieren.
• Tag 2: Bootpolicy-Lebenszyklus gestalten.
• Positive und negative Prüfergebnisse technisch bewerten, Fehler schichtweise lokalisieren und die Betriebs- oder Freigabeentscheidung dokumentieren.

Seminarinhalte Schritt für Schritt

Schritt 1: Tag 1: mTLS, Rollen und Autorisierung umsetzen

CA-Struktur, Dienst- und Agentenzertifikate, minimale Rechte, Rotation und negative Zugriffstests werden eingerichtet. Der resultierende Sollzustand wird mit einer Kontrollabfrage bestätigt und als Ausgangspunkt für den nächsten Arbeitsschritt festgehalten.

Schritt 2: Tag 1: Pull- und Push-Kommunikationsmodell vergleichen

Enrollment und Pull-Attestation werden durchgeführt; anschließend wird ein agenteninitiierter Push-Pilot mit Sitzung und Besitznachweis aufgebaut. Konfiguration, erwartete Werte und tatsächliches Ergebnis werden versioniert dokumentiert; ein gezielter Negativtest prüft die Wirksamkeit.

Schritt 3: Tag 2: PCRs, UEFI Event Logs und Measured Boot analysieren

PCR-Endwerte werden mit Ereignisprotokollen, Systemklassen, Secure-Boot-Bezug und kontrollierter Bootänderung verbunden. Die Umsetzung erfolgt in einer Laborumgebung und wird anhand von Statusdaten, Dienstprotokollen und einem reproduzierbaren Prüffall abgenommen.

Schritt 4: Tag 2: Bootpolicy-Lebenszyklus gestalten

Pilotierung, Hardwareklassen, Firmwareupdate, parallele Policy-Versionen und Rückfall werden als Freigabeprozess umgesetzt. Fehlerbilder werden nicht pauschal behoben, sondern der verursachenden Identitäts-, Netzwerk-, Policy-, TPM- oder Betriebsschicht zugeordnet.

Schritt 5: Tag 3: IMA Runtime Integrity Monitoring aktivieren

Kernelvoraussetzungen, Messpolicy, Messliste und PCR-Bezug werden für ausgewählte kritische Dateien eingerichtet. Der resultierende Sollzustand wird mit einer Kontrollabfrage bestätigt und als Ausgangspunkt für den nächsten Arbeitsschritt festgehalten.

Schritt 6: Tag 3: Runtime-Verletzung bis zur Datei verfolgen

Referenzhashes und Signaturschlüssel werden in eine Runtime-Policy überführt; eine Änderung wird bis zum Messlisteneintrag analysiert. Konfiguration, erwartete Werte und tatsächliches Ergebnis werden versioniert dokumentiert; ein gezielter Negativtest prüft die Wirksamkeit.

Schritt 7: Tag 4: Keylime-Policy signieren und releasen

Runtime- und Boot-Policies werden reproduzierbar erzeugt, signiert, validiert, versioniert und über CI sowie Pilotgruppe freigegeben. Die Umsetzung erfolgt in einer Laborumgebung und wird anhand von Statusdaten, Dienstprotokollen und einem reproduzierbaren Prüffall abgenommen.

Schritt 8: Tag 4: Secure Payload provisionieren und rotieren

Eine verschlüsselte Nutzlast wird an den positiven Vertrauenszustand gebunden, sicher abgelegt und mit negativer Freigabeprüfung rotiert. Fehlerbilder werden nicht pauschal behoben, sondern der verursachenden Identitäts-, Netzwerk-, Policy-, TPM- oder Betriebsschicht zugeordnet.

Schritt 9: Tag 5: Revocation, Webhook und Quarantäne automatisieren

Verletzungen werden klassifiziert und über einen authentifizierten, idempotenten Webhook an abgestufte Reaktionen übergeben. Der resultierende Sollzustand wird mit einer Kontrollabfrage bestätigt und als Ausgangspunkt für den nächsten Arbeitsschritt festgehalten.

Schritt 10: Tag 5: Wiederfreigabe und End-to-End-Prüfung durchführen

Bereinigung, neue Policy oder Identität und aktuelle positive Attestation bilden die kontrollierte Rückkehr in den Regelbetrieb. Konfiguration, erwartete Werte und tatsächliches Ergebnis werden versioniert dokumentiert; ein gezielter Negativtest prüft die Wirksamkeit.

Praxisübungen

• mTLS- und Autorisierungsbaseline mit Negativtests umsetzen.
• Pull- und Push-Attestation für unterschiedliche Netze testen.
• Measured-Boot- und IMA-Policy erstellen, signieren und versionieren.
• Secure Payload provisionieren und bei negativem Nachweis sperren.
• Revocation, Quarantäne und Wiederfreigabe durchspielen.

Abgedeckte Themenbereiche

• Authentifizierung, mTLS und Autorisierung
• IMA Runtime Integrity Monitoring
• Keylime-Policy für Runtime und Measured Boot
• Measured Boot und UEFI Event Logs
• Pull-Modell, Enrollment und Tenant-CLI
• Push-Modell für Edge, IoT und NAT
• Revocation, Webhooks und Reaktionsketten
• Secure Payloads und Secret Provisioning

Einordnung in den Lernpfad

Dritter Intensivblock. Gemeinsam mit den beiden anderen Intensivseminaren werden alle Einzel- und Kompaktthemen abgedeckt.