Seminar OWASP Amass – Betrieb, Skalierung und Troubleshooting

Der Betriebskurs richtet den Blick auf eine dauerhaft verfügbare, nachvollziehbare und kontrollierbare Amass-Umgebung. Collection Engine, Asset-Datenbank, Datenquellen, Scheduler und Ressourcenverbrauch werden als zusammenhängender Dienst betrachtet. Im Labor entstehen Betriebschecklisten, Messwerte, Fehlerbilder, Sicherungsabläufe und ein systematischer Diagnosepfad für typische Störungen.

Inhaltsübersicht

• Betriebsarchitektur und Servicegrenzen
• Kapazität, Parallelität und Ressourcensteuerung
• Monitoring und Alarmierung
• Systematischer Diagnosepfad
• Datenbank- und Persistenzprobleme
• Updates, Backup und Wiederanlauf
• Runbooks und Betriebsorganisation
• Praxisprojekt
• Arbeitsweise und Qualitätssicherung

Kompetenzziele

• Betriebszustände und Abhängigkeiten einer Amass-Plattform strukturiert überwachen
• Kapazität für parallele Scopes, Datenquellen und Datenbankwachstum planen
• Fehler in Engine, Netzwerk, Datenquellen und Datenbank schrittweise eingrenzen
• Updates, Backups und Wiederanlauf kontrolliert durchführen
• Betriebskennzahlen, Alarmgrenzen und Runbooks für den Regelbetrieb erstellen

Seminarinhalte

1. Betriebsarchitektur und Servicegrenzen

Ein stabiler Betrieb beginnt mit einem vollständigen Komponenten- und Abhängigkeitsbild. Engine, Datenbank, Konfiguration, Netzwerkpfade, Resolver und externe Datenquellen werden als Services mit klaren Verantwortlichkeiten erfasst.

1. Komponenten, Laufzeitorte, Ports, Volumes und Abhängigkeiten inventarisieren.
2. Startreihenfolge, Bereitschaftsbedingungen und Fehlerauswirkungen dokumentieren.
3. Technische und fachliche Verantwortlichkeiten je Komponente zuordnen.
4. Serviceziele für Verfügbarkeit, Aktualität und maximale Laufverzögerung festlegen.

2. Kapazität, Parallelität und Ressourcensteuerung

Enumeration erzeugt variable Last. Kapazitätsplanung berücksichtigt Scope-Größe, Datenquellen, aktive Verfahren, Datenbankzugriffe, parallele Aufträge und die erwartete Historie.

1. Referenzlauf mit definierter Scope-Größe und festem Profil durchführen.
2. CPU, Arbeitsspeicher, Netzwerk, Laufzeit und Datenbankwachstum messen.
3. Parallelität schrittweise erhöhen und Sättigungspunkte dokumentieren.
4. Betriebsgrenzen, Warteschlangenregeln und Reserven für Lastspitzen festlegen.

3. Monitoring und Alarmierung

Technische Verfügbarkeit allein reicht nicht aus. Überwacht werden auch Auftragsfortschritt, Datenquellenfehler, ungewöhnliche Ergebnismengen und Verzögerungen bei der Persistenz.

1. Gesundheits-, Ressourcen-, Auftrags- und Datenqualitätsmetriken definieren.
2. Normalbereiche aus mehreren Referenzläufen ableiten.
3. Warn- und Kritisch-Schwellen mit Reaktionszeit und Zuständigkeit versehen.
4. Alarmtests auslösen und prüfen, ob Meldung, Kontext und Eskalation vollständig sind.

4. Systematischer Diagnosepfad

Störungen werden vom sichtbaren Symptom zu Komponenten, Abhängigkeiten und Datenfluss zurückverfolgt. Ein fester Prüfpfad verhindert unkoordinierte Änderungen.

1. Symptom, betroffener Scope, Zeitpunkt und letzte bekannte Änderung erfassen.
2. Container- oder Prozessstatus, Netzwerkpfade und Bereitschaft der Datenbank prüfen.
3. Auftragsstatus, Logs und Datenquellenfehler nach einer gemeinsamen Korrelations-ID auswerten.
4. Nur eine Hypothese gleichzeitig testen und die Wirkung dokumentieren.

5. Datenbank- und Persistenzprobleme

Langsame Schreibvorgänge, Verbindungsabbrüche oder volllaufende Datenträger wirken direkt auf Erfassung und Abfragen. Diagnose und Korrektur müssen Datenintegrität erhalten.

1. Verbindungsstatus, Poolauslastung, Speicherplatz und I/O-Verhalten prüfen.
2. Lang laufende Abfragen und blockierende Transaktionen identifizieren.
3. Wachstum nach Asset-Typ, Lauf und Beobachtungszeit einordnen.
4. Korrektur mit Sicherung, kontrolliertem Wartungsfenster und fachlicher Nachprüfung durchführen.

6. Updates, Backup und Wiederanlauf

Änderungen an Engine, Datenbank oder Konfiguration werden wie produktive Releases behandelt. Versionswechsel benötigen Sicherung, Kompatibilitätsprüfung, Pilotlauf und Rückfallplan.

1. Änderungsumfang, Abhängigkeiten und Migrationsrisiken erfassen.
2. Konfiguration, Geheimnisse und Datenbank konsistent sichern.
3. Update in einer getrennten Testumgebung mit Referenzscope prüfen.
4. Produktivänderung, Wiederanlauf, Kontrollabfragen und Rückfallentscheidung dokumentieren.

7. Runbooks und Betriebsorganisation

Wiederkehrende Aufgaben werden in prüfbare Runbooks überführt. Ein Runbook enthält Auslöser, Voraussetzungen, Schritte, Kontrollpunkte, Abbruch und Eskalation.

1. Tägliche, wöchentliche und monatliche Betriebsaufgaben festlegen.
2. Runbooks für Auftragsstau, Datenquellenausfall, Datenbankengpass und fehlgeschlagenes Update erstellen.
3. Zugriffsrechte und Vier-Augen-Punkte für kritische Tätigkeiten definieren.
4. Runbook in einer Störungssimulation ausführen und anhand der Beobachtungen überarbeiten.

Praxisprojekt

Im Labor wird eine mehrkomponentige Umgebung unter kontrollierte Last gesetzt. Anschließend werden Datenquellenausfall, Datenbankengpass, Auftragsstau und ein fehlerhafter Konfigurationswechsel simuliert. Die Bearbeitung erfolgt ausschließlich über definierte Diagnose- und Rückfallpfade.

1. Betriebsarchitektur und Serviceziele für die Laborumgebung dokumentieren.
2. Referenzlast messen und eine begründete Parallelitätsgrenze festlegen.
3. Monitoring und Alarmierung mit Teststörungen verifizieren.
4. Vier Fehlerbilder anhand des systematischen Diagnosepfads bearbeiten.
5. Runbooks, Backup-Nachweis und Wiederanlaufkontrolle abschließend prüfen.

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.