Container-Härtung verstehen

Diese Seite erläutert, was Container-Härtung bedeutet, warum sie für die öffentliche Verwaltung von besonderer Bedeutung ist und welche Prinzipien dabei maßgeblich sind.

Was ist Container-Härtung?

Container-Härtung bezeichnet den Prozess, ein Container-Image und seine Laufzeitkonfiguration so zu gestalten, dass:

• die Angriffsfläche minimiert wird,
• Schäden im Falle eines erfolgreichen Angriffs auf ein Minimum begrenzt bleiben
• und das Image transparent und nachvollziehbar ist.

Ein gehärtetes Image enthält ausschließlich, was für den Betrieb der Anwendung zwingend erforderlich ist. Werkzeuge, Compiler, Shell-Programme, Netzwerkdienste – alle Komponenten, die nicht benötigt werden, sind nicht Bestandteil des Images.

Zielsetzung: Post-Exploit-Sicherheit

Bei Anwendungs-Images verfolgt Container-Härtung primär das Ziel der Post-Exploit-Sicherheit: Es wird davon ausgegangen, dass die im Container betriebene Anwendung – etwa durch eine ungepatchte Schwachstelle oder eine Sicherheitslücke in einer Abhängigkeit – kompromittiert werden kann. Die Härtung setzt erst nach diesem initialen Angriffseinstieg an: Sie soll sicherstellen, dass ein Angreifer, der die Anwendung erfolgreich übernommen hat, keine Möglichkeit erhält, sich von dort aus im System weiterzubewegen – sei es durch den Zugriff auf benachbarte Dienste, das Auslesen sensibler Daten, das Einschleusen von Schadcode oder den Ausbruch aus dem Container auf den Host.

Härtung ersetzt damit keine Maßnahmen zur Vermeidung der initialen Kompromittierung (Patch-Management, sichere Anwendungsentwicklung), sondern begrenzt konsequent den Aktionsradius eines Angreifers nach erfolgreichem Einbruch – im Sinne des Verteidigungsprinzips Defense in Depth.

Warum ist Härtung in der öffentlichen Verwaltung besonders wichtig?

Container-Images in der öffentlichen Verwaltung werden häufig:

• langfristig betrieben,
• in regulierten Umgebungen mit strikten Compliance-Anforderungen eingesetzt und
• von verschiedenen Behörden nachgenutzt, wodurch Sicherheit zur gemeinsam getragenen Verantwortung wird.

Die sechs Kernbereiche der Härtung

1. Basis-Image-Sicherheit

Das Basis-Image bildet die Grundlage jedes Containers und sollte so minimal wie möglich gehalten werden:

• Distroless-Images enthalten weder Shell noch Paketverwaltung – lediglich die zur Ausführung der Anwendung erforderlichen Laufzeitbibliotheken.
• Scratch-Images sind vollständig leer und damit ideal für statisch gelinkte Binärdateien.
• Minimale Alpine- oder Debian-Images bieten einen vertretbaren Kompromiss zwischen Größe und Paketverfügbarkeit.

Darüber hinaus sollte das Basis-Image aus einer vertrauenswürdigen Quelle stammen und per Digest (SHA-256) referenziert werden – nicht allein per Tag. Tags sind veränderlich und können auf ein abweichendes Image verweisen; ein Digest hingegen ist unveränderlich und eindeutig.

2. Build-Prozess

Der Build-Prozess muss sicherstellen, dass:

• Build-Abhängigkeiten nicht im finalen Image enthalten sind (Multi-Stage-Builds),
• der Build möglichst reproduzierbar ist – identische Eingaben erzeugen stets dasselbe Image,
• das Image signiert wird, damit Nutzerinnen und Nutzer die Authentizität verifizieren können.

3. Komponentenverwaltung

Alle Pakete und Bibliotheken im Image müssen vollständig bekannt und aktiv gepflegt sein:

• Ein SBOM (Software Bill of Materials) dokumentiert alle enthaltenen Komponenten.
• Sämtliche Komponenten müssen kontinuierlich auf Schwachstellen überwacht werden.
• Sicherheitsupdates sind unverzüglich einzuspielen.

4. Geheimnisse und sensible Daten

Passwörter, API-Schlüssel und Zertifikate haben in einem Container-Image keinen Platz. Images werden häufig in Container-Registries abgelegt, auf die ein breiter Personenkreis Zugriff hat oder die öffentlich zugänglich sind. Vertrauliche Informationen sind stattdessen ausschließlich zur Laufzeit über dedizierte Secrets-Management-Systeme bereitzustellen.

5. Laufzeitkonfiguration

Auch ein sorgfältig erstelltes Image kann durch eine unsichere Laufzeitkonfiguration kompromittiert werden:

6. Compliance & Schwachstellenmanagement

Auch ein heute gehärtetes Image kann durch neu entdeckte Schwachstellen angreifbar werden. Container-Härtung ist daher kein einmaliger Vorgang, sondern ein kontinuierlicher Prozess:

• Regelmäßiges Scanning auf neu veröffentlichte CVEs
• Zeitnahe Bewertung aller kritischen und schwerwiegenden Schwachstellen
• VEX-Dokumente machen Bewertungsentscheidungen nachvollziehbar und auditierbar
• Automatische Rebuilds bei aktualisierten Basis-Image-Versionen

Härtung und die Anforderungen von container.gov.de

Die Compliance-Policy von container.gov.de (vgl. Erklärung: Compliance-Policy) prüft vollautomatisch ausschließlich den Schwachstellenstatus eines Images. Die vollständige Härtungs-Checkliste stellt eine Empfehlung für Maintainer dar und ist keine technisch erzwungene Anforderung.

Dennoch gilt: Images, die gemäß der Härtungs-Checkliste erstellt wurden, weisen in der Regel deutlich weniger CVEs auf – da sie weniger Softwarekomponenten enthalten, die potenzielle Angriffsvektoren darstellen.

Härtungsansätze im Überblick

Je nach Anforderungsprofil stehen unterschiedliche Ansätze für die Erstellung gehärteter Images zur Verfügung:

Die Container-Hardening-Workbench unterstützt alle genannten Ansätze durch vorgefertigte CI-Integrationskomponenten.

Weiterführende Informationen

• Referenz: Härtungs-Checkliste – alle Anforderungen im Detail
• Tutorial (extern): DevGuard Container Hardening Guide
• Tutorial: Erstes Image veröffentlichen – praktischer Einstieg
• NIST SP 800-190 – Grundlagendokument für Container-Sicherheit
• BSI IT-Grundschutz SYS.1.6 – Anforderungen des BSI für Containerisierung