Seminar AWS AFO Testautomatisierung, Updates und Release-Management

Inhaltsübersicht

1. Einordnung und Einsatzkontext
2. Lernziele
3. Seminarinhalte
4. Praxislabor
5. Zielgruppe und Voraussetzungen
6. Didaktisches Vorgehen
7. Qualitätssicherung

Einordnung und Einsatzkontext

Das Seminar etabliert einen Release-Prozess für Quellcode, CDK-Stacks, Lambda-Funktionen, SSM-Dokumente, Forensik-AMI und Konfiguration. Automatisierte Prüfungen und sichere Rollbacks reduzieren Betriebsrisiken.

Der fachliche Schwerpunkt liegt auf kontrollierte Weiterentwicklung und Aktualisierung einer AFO-Installation. Die Inhalte werden an EC2- und EKS-bezogenen Vorfallszenarien, klaren Rollen, nachvollziehbaren Entscheidungen und überprüfbaren technischen Nachweisen ausgerichtet. Zwei Tage sind notwendig, weil Komponenteninventar, Teststufen, Upgradepfad, Daten- und Schnittstellenkompatibilität sowie Rollback in einer realistischen Aktualisierung geprobt werden.

Lernziele

Nach Abschluss des Seminars können die behandelten Aufgaben strukturiert vorbereitet, durchgeführt, geprüft und dokumentiert werden.

• Anforderungen und Schutzbedarf für kontrollierte Weiterentwicklung und Aktualisierung einer AFO-Installation fachlich einordnen;
• Komponenten- und Versionsinventar in einen kontrollierten AFO-Prozess überführen;
• Release-Bewertung und Änderungsrisiko mit geeigneten AWS-Diensten und Sicherheitskontrollen umsetzen;
• Build- und Prüf-Pipeline anhand definierter Eingaben, Ausgaben und Prüfkriterien verifizieren;
• Fehler, Abweichungen und Beweislücken bei Integrations- und End-to-End-Tests systematisch analysieren;
• Konfigurationen, Befunde, Entscheidungen und Wiederholungsanweisungen nachvollziehbar dokumentieren.

Seminarinhalte

1. Komponenten- und Versionsinventar

Quellcode, CDK, Abhängigkeiten, Lambda-Layer, SSM-Dokumente, AMIs, Toolversionen, Schemas und Kontexte werden eindeutig erfasst.

Arbeitsschritte

1. Ausgangslage erfassen: Für das Lernfeld „Komponenten- und Versionsinventar“ werden betroffene Konten, Regionen, Ressourcen, Rollen, Datenquellen und Abhängigkeiten vollständig aufgenommen.
2. Vorgehen planen: Der fachliche Fokus wird in konkrete Eingaben, Prüfkriterien, Berechtigungen, Schutzmaßnahmen, erwartete Ausgaben und Abbruchbedingungen übersetzt.
3. Umsetzung durchführen: Die Konfiguration oder Analyse wird in kontrollierten Trainingsressourcen schrittweise ausgeführt; jede relevante Aktion erhält Fallbezug und UTC-Zeitstempel.
4. Kontrolle vornehmen: Status, Protokolle, Artefakte, Berechtigungen, Integrität, Nebenwirkungen und Fehlerpfade werden gegen die zuvor festgelegten Kriterien geprüft.
5. Dokumentation erstellen: Entscheidungen, Befehle oder Konfigurationswerte, Ergebnisse, Abweichungen, Unsicherheiten und sichere Wiederholungs- beziehungsweise Rückfallverfahren werden festgehalten.

Prüfpunkt: Das Lernfeld gilt als bearbeitet, wenn quellcode, CDK, Abhängigkeiten, Lambda-Layer, SSM-Dokumente, AMIs, Toolversionen, Schemas und Kontexte werden eindeutig erfasst. und die zugehörigen Nachweise durch eine zweite Rolle nachvollzogen werden können.

2. Release-Bewertung und Änderungsrisiko

Funktionale Änderungen, Sicherheitskorrekturen, Breaking Changes, Regionen, Datenmodelle, Berechtigungen und Betriebsfolgen werden klassifiziert.

Arbeitsschritte

1. Ausgangslage erfassen: Für das Lernfeld „Release-Bewertung und Änderungsrisiko“ werden betroffene Konten, Regionen, Ressourcen, Rollen, Datenquellen und Abhängigkeiten vollständig aufgenommen.
2. Vorgehen planen: Der fachliche Fokus wird in konkrete Eingaben, Prüfkriterien, Berechtigungen, Schutzmaßnahmen, erwartete Ausgaben und Abbruchbedingungen übersetzt.
3. Umsetzung durchführen: Die Konfiguration oder Analyse wird in kontrollierten Trainingsressourcen schrittweise ausgeführt; jede relevante Aktion erhält Fallbezug und UTC-Zeitstempel.
4. Kontrolle vornehmen: Status, Protokolle, Artefakte, Berechtigungen, Integrität, Nebenwirkungen und Fehlerpfade werden gegen die zuvor festgelegten Kriterien geprüft.
5. Dokumentation erstellen: Entscheidungen, Befehle oder Konfigurationswerte, Ergebnisse, Abweichungen, Unsicherheiten und sichere Wiederholungs- beziehungsweise Rückfallverfahren werden festgehalten.

Prüfpunkt: Das Lernfeld gilt als bearbeitet, wenn funktionale Änderungen, Sicherheitskorrekturen, Breaking Changes, Regionen, Datenmodelle, Berechtigungen und Betriebsfolgen werden klassifiziert. und die zugehörigen Nachweise durch eine zweite Rolle nachvollzogen werden können.

3. Build- und Prüf-Pipeline

Abhängigkeitsprüfung, Linting, Unit Tests, Synthese, Template-Analyse, IAM-Kontrollen, Paketierung und unveränderliche Artefakte werden automatisiert.

Arbeitsschritte

1. Ausgangslage erfassen: Für das Lernfeld „Build- und Prüf-Pipeline“ werden betroffene Konten, Regionen, Ressourcen, Rollen, Datenquellen und Abhängigkeiten vollständig aufgenommen.
2. Vorgehen planen: Der fachliche Fokus wird in konkrete Eingaben, Prüfkriterien, Berechtigungen, Schutzmaßnahmen, erwartete Ausgaben und Abbruchbedingungen übersetzt.
3. Umsetzung durchführen: Die Konfiguration oder Analyse wird in kontrollierten Trainingsressourcen schrittweise ausgeführt; jede relevante Aktion erhält Fallbezug und UTC-Zeitstempel.
4. Kontrolle vornehmen: Status, Protokolle, Artefakte, Berechtigungen, Integrität, Nebenwirkungen und Fehlerpfade werden gegen die zuvor festgelegten Kriterien geprüft.
5. Dokumentation erstellen: Entscheidungen, Befehle oder Konfigurationswerte, Ergebnisse, Abweichungen, Unsicherheiten und sichere Wiederholungs- beziehungsweise Rückfallverfahren werden festgehalten.

Prüfpunkt: Das Lernfeld gilt als bearbeitet, wenn abhängigkeitsprüfung, Linting, Unit Tests, Synthese, Template-Analyse, IAM-Kontrollen, Paketierung und unveränderliche Artefakte werden automatisiert. und die zugehörigen Nachweise durch eine zweite Rolle nachvollzogen werden können.

4. Integrations- und End-to-End-Tests

Finding-Eingaben, Triage, Isolation, Speicher- und Datenträgererfassung, Reporting, Fehlerpfade und Cross-Account-Zugriffe werden als Regression geprüft.

Arbeitsschritte

1. Ausgangslage erfassen: Für das Lernfeld „Integrations- und End-to-End-Tests“ werden betroffene Konten, Regionen, Ressourcen, Rollen, Datenquellen und Abhängigkeiten vollständig aufgenommen.
2. Vorgehen planen: Der fachliche Fokus wird in konkrete Eingaben, Prüfkriterien, Berechtigungen, Schutzmaßnahmen, erwartete Ausgaben und Abbruchbedingungen übersetzt.
3. Umsetzung durchführen: Die Konfiguration oder Analyse wird in kontrollierten Trainingsressourcen schrittweise ausgeführt; jede relevante Aktion erhält Fallbezug und UTC-Zeitstempel.
4. Kontrolle vornehmen: Status, Protokolle, Artefakte, Berechtigungen, Integrität, Nebenwirkungen und Fehlerpfade werden gegen die zuvor festgelegten Kriterien geprüft.
5. Dokumentation erstellen: Entscheidungen, Befehle oder Konfigurationswerte, Ergebnisse, Abweichungen, Unsicherheiten und sichere Wiederholungs- beziehungsweise Rückfallverfahren werden festgehalten.

Prüfpunkt: Das Lernfeld gilt als bearbeitet, wenn finding-Eingaben, Triage, Isolation, Speicher- und Datenträgererfassung, Reporting, Fehlerpfade und Cross-Account-Zugriffe werden als Regression geprüft. und die zugehörigen Nachweise durch eine zweite Rolle nachvollzogen werden können.

5. AMI- und Toolchain-Updates

Image Builder, SIFT, LiME, Volatility, Plaso, Betriebssystempakete, Schwachstellenprüfung und Kompatibilität werden separat freigegeben.

Arbeitsschritte

1. Ausgangslage erfassen: Für das Lernfeld „AMI- und Toolchain-Updates“ werden betroffene Konten, Regionen, Ressourcen, Rollen, Datenquellen und Abhängigkeiten vollständig aufgenommen.
2. Vorgehen planen: Der fachliche Fokus wird in konkrete Eingaben, Prüfkriterien, Berechtigungen, Schutzmaßnahmen, erwartete Ausgaben und Abbruchbedingungen übersetzt.
3. Umsetzung durchführen: Die Konfiguration oder Analyse wird in kontrollierten Trainingsressourcen schrittweise ausgeführt; jede relevante Aktion erhält Fallbezug und UTC-Zeitstempel.
4. Kontrolle vornehmen: Status, Protokolle, Artefakte, Berechtigungen, Integrität, Nebenwirkungen und Fehlerpfade werden gegen die zuvor festgelegten Kriterien geprüft.
5. Dokumentation erstellen: Entscheidungen, Befehle oder Konfigurationswerte, Ergebnisse, Abweichungen, Unsicherheiten und sichere Wiederholungs- beziehungsweise Rückfallverfahren werden festgehalten.

Prüfpunkt: Das Lernfeld gilt als bearbeitet, wenn image Builder, SIFT, LiME, Volatility, Plaso, Betriebssystempakete, Schwachstellenprüfung und Kompatibilität werden separat freigegeben. und die zugehörigen Nachweise durch eine zweite Rolle nachvollzogen werden können.

6. Stufenweiser Rollout

Sandbox, Test, Pilotkonten, Produktionswellen, Wartungsfenster, Beobachtungsphase, Freigabepunkte und Kommunikationsschritte werden geplant.

Arbeitsschritte

1. Ausgangslage erfassen: Für das Lernfeld „Stufenweiser Rollout“ werden betroffene Konten, Regionen, Ressourcen, Rollen, Datenquellen und Abhängigkeiten vollständig aufgenommen.
2. Vorgehen planen: Der fachliche Fokus wird in konkrete Eingaben, Prüfkriterien, Berechtigungen, Schutzmaßnahmen, erwartete Ausgaben und Abbruchbedingungen übersetzt.
3. Umsetzung durchführen: Die Konfiguration oder Analyse wird in kontrollierten Trainingsressourcen schrittweise ausgeführt; jede relevante Aktion erhält Fallbezug und UTC-Zeitstempel.
4. Kontrolle vornehmen: Status, Protokolle, Artefakte, Berechtigungen, Integrität, Nebenwirkungen und Fehlerpfade werden gegen die zuvor festgelegten Kriterien geprüft.
5. Dokumentation erstellen: Entscheidungen, Befehle oder Konfigurationswerte, Ergebnisse, Abweichungen, Unsicherheiten und sichere Wiederholungs- beziehungsweise Rückfallverfahren werden festgehalten.

Prüfpunkt: Das Lernfeld gilt als bearbeitet, wenn sandbox, Test, Pilotkonten, Produktionswellen, Wartungsfenster, Beobachtungsphase, Freigabepunkte und Kommunikationsschritte werden geplant. und die zugehörigen Nachweise durch eine zweite Rolle nachvollzogen werden können.

7. Rollback und Nachweis

Vorversionen, Stack-Rücknahme, AMI-Pinning, Dokumentversionen, Datenkompatibilität, Abbruchkriterien und Abschlussprotokoll werden praktisch erprobt.

Arbeitsschritte

1. Ausgangslage erfassen: Für das Lernfeld „Rollback und Nachweis“ werden betroffene Konten, Regionen, Ressourcen, Rollen, Datenquellen und Abhängigkeiten vollständig aufgenommen.
2. Vorgehen planen: Der fachliche Fokus wird in konkrete Eingaben, Prüfkriterien, Berechtigungen, Schutzmaßnahmen, erwartete Ausgaben und Abbruchbedingungen übersetzt.
3. Umsetzung durchführen: Die Konfiguration oder Analyse wird in kontrollierten Trainingsressourcen schrittweise ausgeführt; jede relevante Aktion erhält Fallbezug und UTC-Zeitstempel.
4. Kontrolle vornehmen: Status, Protokolle, Artefakte, Berechtigungen, Integrität, Nebenwirkungen und Fehlerpfade werden gegen die zuvor festgelegten Kriterien geprüft.
5. Dokumentation erstellen: Entscheidungen, Befehle oder Konfigurationswerte, Ergebnisse, Abweichungen, Unsicherheiten und sichere Wiederholungs- beziehungsweise Rückfallverfahren werden festgehalten.

Prüfpunkt: Das Lernfeld gilt als bearbeitet, wenn vorversionen, Stack-Rücknahme, AMI-Pinning, Dokumentversionen, Datenkompatibilität, Abbruchkriterien und Abschlussprotokoll werden praktisch erprobt. und die zugehörigen Nachweise durch eine zweite Rolle nachvollzogen werden können.

Praxislabor

Upgrade einer bestehenden Trainingsumgebung auf einen neuen Quellstand mit AMI-Wechsel, Regressionstests und kontrollierter Rücknahme.

1. Trainingsfall anlegen, Ausgangslage protokollieren und Schutzobjekte sowie Zuständigkeiten festlegen.
2. Ereignis- oder Konfigurationsdaten prüfen, den geeigneten AFO-Pfad auswählen und Freigabepunkte dokumentieren.
3. Technische Schritte in der vorgesehenen Reihenfolge ausführen und alle Zwischenstände mit Fallkennung erfassen.
4. Mindestens einen Fehler- oder Sonderfall einspielen, Ursache eingrenzen und eine sichere Fortsetzung oder Rücknahme durchführen.
5. Artefakte, Logs, Statusdaten und Befunde auf Vollständigkeit, Integrität, Zeitkonsistenz und Zugriffsrechte prüfen.
6. Eine ausführbare Arbeitsanweisung mit Rollen, Prüfpunkten, Eskalationen und Abschlusskriterien erstellen.

Zielgruppe und Voraussetzungen

Zielgruppe: DevSecOps, Plattformengineering, Security Engineering, Cloud Operations und Release-Verantwortliche.

Voraussetzungen: Git, CI/CD, AWS CDK oder CloudFormation, automatisierte Tests, IAM und AFO-Architekturkenntnisse.

Didaktisches Vorgehen

Fachliche Erläuterungen werden unmittelbar mit Architekturarbeit, Demonstrationen, geführten Übungen, Analyseaufgaben und dokumentierter Fallarbeit verbunden. Jeder technische Schritt wird zunächst geplant, anschließend in einer isolierten Umgebung ausgeführt und danach anhand von Logs, Artefakten und Prüfkriterien bewertet.

Qualitätssicherung

• Vorbedingungen, Rollen und Berechtigungen werden vor jedem Labor geprüft.
• Alle Zeitangaben werden einheitlich in UTC dokumentiert.
• Beweis- und Konfigurationsobjekte erhalten eindeutige Kennungen und einen nachvollziehbaren Bearbeitungsstatus.
• Fehlerfälle werden nicht übersprungen, sondern mit Ursache, Auswirkung, Korrektur und Wiederholungsprüfung erfasst.
• Arbeitsanweisungen werden durch einen zweiten Prüfpfad auf Vollständigkeit und Ausführbarkeit kontrolliert.