Seminar Antora – Sicherheit, private Repositories und Compliance

Beschreibung

Das Seminar entwickelt eine Sicherheits- und Compliance-Baseline für Antora-basierte Dokumentationsplattformen. Bedrohungsmodell, private Git-Quellen, Zugangsdaten, Abhängigkeiten, Erweiterungen, Container, Build-Isolation, Ausgabeschutz, Protokollierung, Nachweise und Incident-Prozesse werden in einer Referenzpipeline umgesetzt. Der Schwerpunkt liegt auf technischen und organisatorischen Kontrollen, die sich wiederholbar prüfen lassen.

Inhaltsübersicht

1. Bedrohungsmodell und Schutzbedarf
2. Private Quellen und Secret-Management
3. Abhängigkeiten und Software-Lieferkette
4. Build-Isolation und Ausgabeschutz
5. Datenschutz, Protokollierung und Compliance-Nachweise
6. Incident Response und regelmäßige Sicherheitsprüfung

Lernziele

• Bedrohungen und Schutzbedarfe einer Antora-Pipeline systematisch bewerten.
• Private Quellen und Geheimnisse mit minimalen, rotierbaren Rechten anbinden.
• Abhängigkeiten, Erweiterungen und Build-Laufzeit gegen Lieferkettenrisiken absichern.
• Compliance-Nachweise und Incident-Abläufe reproduzierbar etablieren.

1. Bedrohungsmodell und Schutzbedarf

Sicherheitsmaßnahmen werden aus Datenflüssen, Vertrauensgrenzen und realistischen Angriffspfaden abgeleitet.

Schritt-für-Schritt: Ein Bedrohungsmodell für die Dokumentationspipeline erstellen

1. Quell-Repositories, CI-Plattform, Paketquellen, Erweiterungen, Build-Worker und Veröffentlichungsziel erfassen.
2. Schützenswerte Inhalte, Zugangsdaten, Konfigurationen und Artefakte klassifizieren.
3. Vertrauensgrenzen und privilegierte Übergänge im Datenfluss markieren.
4. Bedrohungen wie manipulierte Quellen, Abhängigkeitsangriffe, Secret-Leaks und unbefugte Veröffentlichung bewerten.
5. Kontrollen nach Prävention, Erkennung und Reaktion zuordnen.
6. Restrisiken, Eigentümer und Prüffristen in einem Sicherheitsregister dokumentieren.

Praxisaufgabe

Für eine Pipeline mit privaten Repositories entsteht ein priorisiertes Bedrohungs- und Maßnahmenmodell.

2. Private Quellen und Secret-Management

Zugangsdaten werden kurzlebig, minimal berechtigt und ohne Offenlegung im Build verwendet.

Schritt-für-Schritt: Private Repositories sicher anbinden

1. Benötigte Leserechte pro Repository und Pipeline-Stufe bestimmen.
2. Geeignete Plattformidentität, Deploy Key oder kurzlebiges Token auswählen.
3. Secret ausschließlich über geschützte Laufzeitmechanismen bereitstellen.
4. Maskierung und Protokollverhalten mit absichtlich fehlerhaften Abrufen testen.
5. Rotation, Entzug und Notfallersatz ohne Codeänderung durchspielen.
6. Positiv- und Negativzugriffe mit Zeit, Identität und Ergebnis dokumentieren.

Praxisaufgabe

Eine private Inhaltsquelle wird angebunden, das Secret rotiert und der alte Zugang nachweislich unwirksam gemacht.

3. Abhängigkeiten und Software-Lieferkette

Node.js-Pakete, UI-Bundles, Erweiterungen und Container sind Teil der vertrauenswürdigen Lieferkette.

Schritt-für-Schritt: Build-Abhängigkeiten kontrollieren

1. Direkte und transitive Pakete sowie externe Build-Artefakte inventarisieren.
2. Versionen und Integritätsinformationen über Sperrdateien oder feste Referenzen sichern.
3. Schwachstellen-, Lizenz- und Herkunftsprüfungen als Pipeline-Gates einrichten.
4. UI-Bundles und Erweiterungspakete vor Nutzung auf erwarteten Inhalt prüfen.
5. Aktualisierung, Ausnahmefreigabe und Rücknahme kompromittierter Versionen definieren.
6. Einen Build mit manipulierter oder nicht freigegebener Abhängigkeit kontrolliert blockieren.

Praxisaufgabe

Eine Software-Stückliste und ein Freigabeprozess für Antora-, UI- und Erweiterungsabhängigkeiten werden erstellt.

4. Build-Isolation und Ausgabeschutz

Unvertrauenswürdige Inhalte und Werkzeuge werden in einer begrenzten Laufzeit verarbeitet.

Schritt-für-Schritt: Den Build und seine Artefakte isolieren

1. Build-Worker mit minimalen Dateisystem-, Netzwerk- und Plattformrechten konfigurieren.
2. Schreibzugriffe auf notwendige Arbeits- und Ausgabeverzeichnisse begrenzen.
3. Netzwerkziele für Git- und Paketabrufe möglichst einschränken.
4. Build-Prozess ohne dauerhafte Zugangsdaten und ohne privilegierten Container ausführen.
5. Ausgabe auf vertrauliche Inhalte, Debugdaten und unerwartete Dateien prüfen.
6. Veröffentlichung nur aus einem freigegebenen, unveränderlichen Artefakt erlauben.

Praxisaufgabe

Eine gehärtete Build-Laufzeit wird gegen unerlaubte Datei-, Netzwerk- und Veröffentlichungszugriffe getestet.

5. Datenschutz, Protokollierung und Compliance-Nachweise

Protokolle und Artefakte müssen einerseits prüfbar, andererseits frei von unnötigen personenbezogenen oder geheimen Daten sein.

Schritt-für-Schritt: Nachweisführung datensparsam gestalten

1. Erforderliche Auditdaten für Build, Freigabe und Veröffentlichung festlegen.
2. Personenbezug, Geheimnisse und Inhaltsfragmente in Protokollen minimieren.
3. Aufbewahrungsfristen und Zugriffsrechte für Protokolle, Artefakte und Quellmanifeste definieren.
4. Build-Identität, Quellstände, Abhängigkeiten und Freigaben in einem Nachweis bündeln.
5. Lösch- und Auskunftsanforderungen für gespeicherte Daten berücksichtigen.
6. Einen vollständigen Nachweis aus einem Testrelease erzeugen und auf Vollständigkeit prüfen.

Praxisaufgabe

Ein revisionsfähiger, datensparsamer Build- und Veröffentlichungsnachweis wird erstellt.

6. Incident Response und regelmäßige Sicherheitsprüfung

Sicherheitsvorfälle müssen mit klarer Isolation, Ursachenanalyse, Wiederherstellung und Nachweisführung behandelt werden.

Schritt-für-Schritt: Einen Incident-Ablauf erproben

1. Auslöser für Secret-Leak, manipulierte Quelle, schadhafte Abhängigkeit und falsche Veröffentlichung definieren.
2. Build, Zugangsdaten und Veröffentlichungsweg in der richtigen Reihenfolge isolieren.
3. Betroffene Builds, Quellstände und Artefakte anhand der Nachweise bestimmen.
4. Secrets rotieren, schadhafte Versionen sperren und eine saubere Baseline wiederherstellen.
5. Neuaufbau und Veröffentlichung mit zusätzlichen Kontrollen durchführen.
6. Erkenntnisse in Kontrollverbesserungen, Prüffristen und Verantwortlichkeiten überführen.

Praxisaufgabe

Ein vorbereiteter Secret- und Lieferkettenvorfall wird anhand eines Incident-Runbooks bearbeitet.

Zielgruppe und Voraussetzungen

Zielgruppe: Informationssicherheit, DevSecOps, Plattformbetrieb, Git-Administration, Documentation Engineering, Compliance, Datenschutz und technische Architektur.

Voraussetzungen: Grundkenntnisse in Antora-Builds, Git, CI/CD und Secret-Management; Verständnis grundlegender Sicherheitsprinzipien.

Methodik und Arbeitsweise

Die Inhalte werden durch strukturierte Erläuterungen, Demonstrationen, schrittweise Konfigurations- und Analyseaufgaben sowie kontrollierte Fehlerfälle vertieft. Jede Übung verwendet definierte Ausgangswerte, Prüfpunkte und Dokumentationsanforderungen, damit die erarbeiteten Abläufe im späteren Projekt- und Betriebsalltag reproduzierbar bleiben.