Seminar OWASP Amass – Docker-Compose-Deployment und sichere Konfiguration

Der Deploymentkurs baut eine reproduzierbare Amass-Labor- und Betriebsumgebung mit Container-Orchestrierung und persistenter Asset-Datenbank auf. Netzwerk, Volumes, Konfigurationsdateien, Geheimnisse, Ressourcenlimits und Startabhängigkeiten werden nachvollziehbar geplant. Der Schwerpunkt liegt auf sicherer Basiskonfiguration, reproduzierbarer Bereitstellung und kontrolliertem Update.

Inhaltsübersicht

• Zielarchitektur und Voraussetzungen
• Compose-Struktur und Komponenten
• Konfiguration und Datenquellenprofile
• Geheimnisse und Härtung
• Erststart und Funktionsprüfung
• Backup, Update und Rückfall
• Praxisprojekt
• Arbeitsweise und Qualitätssicherung

Kompetenzziele

• eine containerisierte Amass-Architektur mit Engine und Asset-Datenbank planen
• Konfiguration, Datenquellenprofile, Volumes und Geheimnisse sauber trennen
• Netzwerk- und Zugriffsgrenzen für Labor und Betrieb definieren
• Bereitschaft, Persistenz und Wiederanlauf praktisch prüfen
• Update, Backup und Rückfall für die Compose-Umgebung dokumentieren

Seminarinhalte

1. Zielarchitektur und Voraussetzungen

Vor dem Deployment werden Host, Containerrollen, Datenbank, Netze, Speicher und Administrationspfade als überprüfbarer Plan festgelegt.

1. Hostvoraussetzungen, Ressourcen, Zeitquelle und Namensauflösung prüfen.
2. Engine-, Datenbank- und optionale Clientrollen in einem Netzplan darstellen.
3. Persistente und flüchtige Datenbereiche unterscheiden.
4. Administrationszugriff, Firewallgrenzen und Rückfallzugang definieren.

2. Compose-Struktur und Komponenten

Die Compose-Datei beschreibt Services, Abhängigkeiten, Netze, Volumes und Laufzeitparameter. Die Struktur bleibt klein, explizit und umgebungsspezifisch.

1. Service-Namen, Images und feste Versionsstrategie festlegen.
2. Interne Netze und nur notwendige veröffentlichte Ports definieren.
3. Volumes für Datenbank und erforderliche Konfigurationsbereiche zuordnen.
4. Startabhängigkeiten und Gesundheitsprüfungen für Engine und Datenbank ergänzen.

3. Konfiguration und Datenquellenprofile

Allgemeine Einstellungen, Scope-Definitionen und Datenquellen werden getrennt gepflegt. Die Laufzeit erhält nur die für das jeweilige Profil notwendigen Dateien.

1. Basisparameter in einer zentralen Konfigurationsdatei erfassen.
2. Datenquellen in einer eigenen, zugriffsbeschränkten Datei definieren.
3. Labor- und Betriebsprofile mit unterschiedlichen Scopes und Limits anlegen.
4. Konfiguration vor dem Start auf Syntax, Pfade und unbeabsichtigte Geheimnisse prüfen.

4. Geheimnisse und Härtung

Datenbankkennwörter und API-Schlüssel dürfen nicht in Images, Versionsverwaltung oder frei lesbare Umgebungsdateien gelangen. Containerrechte und Hostzugriff werden minimiert.

1. Geheimnisse inventarisieren und einen geschützten Bereitstellungsweg festlegen.
2. Dateirechte, Benutzerkontext und schreibbare Pfade begrenzen.
3. Nicht benötigte Capabilities, Ports und Mounts entfernen.
4. Logs und Diagnoseausgaben auf unbeabsichtigte Offenlegung prüfen.

5. Erststart und Funktionsprüfung

Der Erststart erfolgt stufenweise. Datenbankbereitschaft, Engine-Verbindung, Persistenz und ein kleiner autorisierter Referenzlauf werden getrennt geprüft.

1. Services zunächst ohne produktiven Auftrag starten und Gesundheitsstatus prüfen.
2. Datenbankverbindung und Schemaerreichbarkeit kontrollieren.
3. Kleinen Referenzscope mit festem Profil ausführen.
4. Containerneustart durchführen und Persistenz sowie Auftragsstatus erneut prüfen.

6. Backup, Update und Rückfall

Containerimages sind ersetzbar, Daten und Konfiguration nicht. Ein Updatepfad enthält Sicherung, Test, kontrollierten Versionswechsel und Rückfall.

1. Zu sichernde Volumes, Datenbankinhalte, Konfigurationen und Geheimnisreferenzen erfassen.
2. Backup erstellen und Wiederherstellung in einem getrennten Projekt prüfen.
3. Neue Version mit Referenzscope und Datenbankkontrollen testen.
4. Produktivwechsel, Erfolgskriterien und Rückfall auf die vorherige Version dokumentieren.

Praxisprojekt

Im Praxisprojekt entsteht eine vollständig dokumentierte Compose-Umgebung mit PostgreSQL, persistenter Asset-Datenbank, getrennten Konfigurationsprofilen und geschützter Schlüsselbereitstellung. Erststart, Referenzlauf, Neustart, Sicherung und kontrolliertes Update werden geprüft.

1. Architektur-, Netz- und Speicherplan für die Laborumgebung erstellen.
2. Compose-Projekt mit festen Services, internen Netzen und Volumes aufbauen.
3. Konfigurations- und Datenquellenprofile ohne eingebettete Geheimnisse bereitstellen.
4. Erststart, Datenbankverbindung, Referenzlauf und Persistenz prüfen.
5. Backup, Restore-Test und Update mit dokumentiertem Rückfallpfad durchführen.

Arbeitsweise und Qualitätssicherung

Die Durchführung kombiniert fachliche Einordnung, demonstrierte Arbeitsabläufe, geführte Laborphasen und eigenständige Kontrollaufgaben. Jeder Arbeitsschritt wird mit Scope, Eingaben, Laufparametern, Beobachtungen und Prüfpunkt dokumentiert. Wiederholbare Testläufe, Positiv- und Negativkontrollen sowie eine klare Trennung zwischen bestätigten, wahrscheinlichen und ungeklärten Assets sichern die Nachvollziehbarkeit. Alle Analysen erfolgen ausschließlich in autorisierten Übungsumgebungen oder innerhalb schriftlich freigegebener Zielbereiche.