Checkliste für gehärtete Container

Hinweis: Die hier aufgeführten Anforderungen sind Empfehlungen und Best Practices und keine verbindlichen Kriterien für die Listung auf container.gov.de. Die relevanten, automatisch durchgesetzten Zugangsvoraussetzungen sind in den Technischen Zugangsvoraussetzungen definiert. Dennoch wird den Betreuern dringend empfohlen, sich an die in dieser Checkliste beschriebenen Praktiken zu halten – sie spiegeln etablierte Sicherheitsstandards wider und erhöhen das allgemeine Sicherheitsniveau der veröffentlichten Images erheblich. Die folgende Liste wurde aus dem englischen Original übersetzt.

Ein gehärteter Container erfüllt die folgenden Sicherheits- und Transparenzanforderungen:

Sicherheit des Basis-Images

• Es werden minimale Basis-Images verwendet (MUSS) - Der Container verwendet das kleinstmögliche Basis-Image (distroless, scratch oder minimal Alpine), um die Angriffsfläche zu reduzieren und die Identifizierung von Komponenten zu vereinfachen. Es sind nur die für die Anwendung erforderlichen Binärdateien und Bibliotheken enthalten. Dies reduziert die Anzahl potenzieller Schwachstellen und erleichtert die Verfolgung und Sicherung der tatsächlich in Ihrem Container enthaltenen Elemente. ^{1 2 3 4 5 6 7 8}

• Die Herkunft des Basisimages wird überprüft (MUSS) - Basisimages stammen aus vertrauenswürdigen Registern mit verifizierter Lieferkette, und ihre Signaturen und Attestations werden vor der Verwendung validiert. Dadurch werden Angriffe auf die Lieferkette verhindert, bei denen böswillige Akteure kompromittierte Basisimages in Ihren Build-Prozess einschleusen. ^{9 10 11 3 12 13 14 15}

• Es werden unveränderliche Artefaktreferenzen verwendet - Das Basisimage wird anhand eines Digest (SHA256) und nicht anhand eines veränderlichen Tags referenziert, um sicherzustellen, dass immer genau das richtige Artefakt abgerufen wird. Dadurch wird „Tag-Hijacking” verhindert, bei dem ein Angreifer ein getaggtes Image durch eine bösartige Version ersetzt. ^{9 12 13 5 6}

• Das Basisimage kann automatisch aktualisiert werden (oder nach einem festgelegten Zeitraum, um nicht Opfer eines Supply-Chain-Angriffs zu werden) (MUSS) - (Erfordert eine Herkunftsüberprüfung) Es gibt eine automatisierte Pipeline, um Aktualisierungen des Basisimages ohne manuelles Eingreifen zu erkennen, zu testen und bereitzustellen. Dadurch wird sichergestellt, dass Sicherheitspatches schnell angewendet werden, wodurch das Risiko bekannter Schwachstellen verringert wird. ^{16 12 13 17 18}

Sicherheit des Build-Prozesses

• Reproduzierbare Builds werden implementiert (SOLL) - Der Build-Prozess ist deterministisch und erzeugt aus demselben Quellcode und denselben Abhängigkeiten bitweise identische Images. Dies ermöglicht eine unabhängige Überprüfung, dass Ihr Container während des Build-Prozesses nicht manipuliert wurde. ^{19 20}

• Die Build-Umgebung ist isoliert - Builds werden in kurzlebigen, isolierten Umgebungen ausgeführt, die für jeden Build neu erstellt und anschließend zerstört werden, um eine Kreuzkontamination zu verhindern. Dadurch wird verhindert, dass bösartiger Code aus einem Build nachfolgende Builds infiziert oder Geheimnisse aus der Build-Umgebung stiehlt. ¹⁹

• Die Herkunft des Builds wird bestätigt (SOLL) - Der Build-Prozess generiert eine kryptografisch signierte Herkunftsangabe über das Artifakt, idealerweise auf SLSA-Level 2 oder höher. Dadurch entsteht ein überprüfbarer Nachweis, dass der Container aus Ihrem legitimen Build-System stammt und nicht ersetzt wurde. ^{19 11}

• Container sind signiert (SOLL) - Container-Images werden kryptografisch signiert, um ihre Authentizität und Integrität zu überprüfen und somit sicherzustellen, dass sie nicht manipuliert wurden. Dies liefert einen kryptografischen Nachweis dafür, dass der Container aus einer vertrauenswürdigen Quelle stammt und seit seiner Erstellung nicht verändert wurde. ^{9 11 3 21}

• Abhängigkeiten aus dem Entwicklungs-/Kompilierungsprozess werden entfernt - Der Build-Prozess verwendet mehrstufige Builds, um sicherzustellen, dass Entwicklungswerkzeuge, Compiler und Abhängigkeiten zur Build-Zeit aus dem endgültigen Image ausgeschlossen werden. Dadurch werden unnötige Werkzeuge eliminiert, die Angreifer ausnutzen könnten, wenn sie Zugriff auf den laufenden Container erhalten. ^{2 3}

• Öffentliche Einsicht in alle verwendeten Software-Assets (MUSS) - Informationen zur Erstellung aller Software-Assets sind öffentlich verfügbar. Dies ermöglicht reproduzierbare Builds und die Überprüfung des Build-Prozesses durch Dritte. ²²

• Release-Änderungsprotokoll wird bereitgestellt (MUSS) - Alle Releases enthalten ein beschreibendes Änderungsprotokoll, in dem funktionale Änderungen, Sicherheitskorrekturen und Aktualisierungen von Abhängigkeiten dokumentiert sind. Dadurch können Benutzer die Auswirkungen von Updates beurteilen, was bei Sicherheitsaudits und der Dokumentation der Compliance hilfreich ist. ²³

• Testverfahren werden implementiert (MUSS) - Testverfahren werden implementiert und angewendet. Dadurch wird die Codequalität sichergestellt und verhindert, dass Fehler und Schwachstellen in Produktionsumgebungen gelangen. ²⁴

• Maßnahmen zur Speichersicherheit sind implementiert (SOLL) - Das Projekt ergreift Maßnahmen, um Probleme mit der Speichersicherheit zu reduzieren oder zu vermeiden. Dadurch wird das Risiko häufiger Sicherheitslücken wie Buffer overflows, Use-after-free und anderen Angriffen auf den Speicher reduziert. ²⁵

• Codeänderungen werden einer Peer-Review unterzogen (SOLL) - Alle Änderungen am Quellcode werden vor dem merge mit dem Main-Branch einer Peer-Review unterzogen. Dies erhöht die Codequalität, erkennt Sicherheitsprobleme frühzeitig und verhindert, dass bösartiger Code in die Codebasis gelangt. ²⁶

• Quellpakete enthalten nur Repository-Inhalte (MUSS) - Veröffentlichte Quellpakete enthalten keine Inhalte, die nicht im Repository des Projekts vorhanden sind oder nicht deterministisch aus diesem Repository generiert werden können. Dadurch wird verhindert, dass kompromittierter oder nicht geprüfter Code in Releases aufgenommen wird, und die Integrität der Lieferkette wird gewährleistet. ²⁷

• Alle Laufzeitabhängigkeiten sind im Image enthalten (MUSS) - Alle Module, Bibliotheken und Abhängigkeiten, die zur Laufzeit benötigt werden, sind im Image enthalten. Das Laden von Modulen zur Laufzeit ist nicht zulässig. Dies verhindert Supply-Chain-Angriffe zur Laufzeit und stellt sicher, dass das gescannte und signierte Image genau das enthält, was ausgeführt wird. ²⁸

Komponentenverwaltung und Transparenz

• Alle Komponenten sind identifiziert (MUSS) - Jede Softwarekomponente, Bibliothek und Abhängigkeit innerhalb des Containers wird katalogisiert und dokumentiert. Dadurch können Sie genau wissen, was Sie ausführen, und Ihre Gefährdung einschätzen, wenn neue Schwachstellen entdeckt werden. ^{29 30 31}

• Komponenten-PURLs werden mit CVE-Berichten abgeglichen (optional, wenn VEX mit URL implementiert und auf dem neuesten Stand gehalten wird) - Jede Komponente verfügt über eine Paket-URL (PURL), die einen automatischen Abgleich mit CVE-Datenbanken ermöglicht. Dadurch können automatisierte Tools Sie sofort benachrichtigen, wenn eine Komponente in Ihrem Container eine bekannte Schwachstelle aufweist. ²⁹

• Komponenten-Prüfsummen werden verifiziert - Alle Komponenten verfügen über kryptografische Prüfsummen (SHA256 oder stärker), die während des Build-Prozesses verifiziert werden. Dadurch wird erkannt, ob Abhängigkeiten während des Downloads oder der Speicherung beschädigt oder böswillig verändert wurden. ¹⁹

• Für alle Komponenten oder neuesten Builds werden regelmäßig Updates bereitgestellt (SOLL) - Komponenten erhalten zeitnah Updates und Patches aus Upstream-Quellen, und Ihr Build-Prozess integriert diese Updates regelmäßig. Dadurch wird sichergestellt, dass Ihr Container vor neu entdeckten Schwachstellen in seinen Komponenten geschützt bleibt. ³⁰

• Komponenten werden automatisch zeitnah (oder nach einem festgelegten Zeitraum) aktualisiert (SOLL) - Es gibt eine automatisierte Pipeline, um Updates von Komponenten ohne manuelles Eingreifen zu erkennen, zu testen und bereitzustellen.Dadurch wird sichergestellt, dass Sicherheitspatches schnell angewendet werden, wodurch das Risiko bekannter Schwachstellen verringert wird. ^{16 30}

• Kein Fernzugriff im Image (SOLL) - Das Container-Image enthält keine Tools die einen Fernzugriff ermöglichen wie SSH, Telnet oder ähnliche Software. Dies reduziert die Angriffsfläche erheblich und verhindert, dass Angreifer integrierte Tools nutzen, um Zugriff auf den Container zu erlangen. ³²

Geheimnisse und sensible Daten

• Keine Geheimnisse in Images (MUSS) - Anmeldedaten, API-Schlüssel, Zertifikate und andere sensible Daten werden niemals in Container-Images eingebettet, sondern zur Laufzeit über Geheimnisverwaltungssysteme eingefügt. Dadurch wird verhindert, dass Geheimnisse in Image-Layern offengelegt werden, die von jedem mit Zugriff auf das Image extrahiert werden können. ^{33 34 35}

Laufzeitkonfiguration

• Ressourcenbeschränkungen sind dokumentiert (MUSS) - Die erwarteten CPU-, Speicher- und Speicheranforderungen werden als Metadaten oder in der Begleitdokumentation dokumentiert, um Informationen für das Betreiben des Images bereitzustellen. Dies kann mithilfe von Labels erfolgen:

  LABEL org.opencontainers.image.title="myapp"
  LABEL org.opencontainers.image.description="Web API for X"
  LABEL org.opencontainers.image.resource.cpu="500m"
  LABEL org.opencontainers.image.resource.memory="256Mi"
  LABEL org.opencontainers.image.resource.ephemeral-storage="1Gi"

  Dies ermöglicht eine ordnungsgemäße Ressourcenzuweisung, um Denial-of-Service-Angriffe zu verhindern, und stellt sicher, dass der Container innerhalb der erwarteten Parameter läuft. ^{36 37 38}

• Container läuft als Nicht-Root-Benutzer (MUSS) - Die Anwendung wird als nicht privilegierter Benutzer (UID > 1000) ausgeführt, um den potenziellen Schaden durch Container-Ausbrüche oder Exploits zu begrenzen. Dies schränkt die Möglichkeiten eines Angreifers ein, wenn er die Anwendung kompromittiert, und verhindert, dass er Systemdateien verändert oder seine Berechtigungen erweitert. ^{39 40 41 42}

• Das Laufzeitanwendungsprofil ist definiert (SOLL) - Sicherheitsprofile (AppArmor, SELinux, seccomp) werden erstellt und angewendet, um Systemaufrufe und Funktionen zu beschränken, die der Container zur Laufzeit nutzen kann. Dies bietet eine zusätzliche Verteidigungsebene, indem die Aktionen, die die containerisierte Anwendung ausführen kann, eingeschränkt werden, wodurch die Angriffsfläche reduziert wird. ^{43 44 45}

• Das Root-Dateisystem des Containers ist schreibgeschützt (MUSS) - Das Root-Dateisystem des Containers ist als schreibgeschützt konfiguriert; Schreibvorgänge finden nur in dedizierten Volumes statt. Dadurch wird verhindert, dass Angreifer den Container zur Laufzeit verändern oder Malware im Dateisystem des Containers dauerhaft installieren können. ⁴⁶

• Temporäre Daten verwenden kurzlebige Volumes (SOLL) - Temporäre Daten werden in dedizierte kurzlebige Volumes geschrieben, nicht in das Dateisystem des Containers. Dies ermöglicht ein zustandsloses Containerdesign, erlaubt saubere Neustarts und verhindert, dass temporäre Daten über Deployments hinweg bestehen bleiben. ⁴⁷

• Schreibgeschützte Daten verwenden schreibgeschützte Volumes (SOLL) - Daten, die nur gelesen werden, werden als schreibgeschützte Volumes gemountet. Dies verhindert versehentliche oder böswillige Änderungen an Konfigurationsdaten und setzt das Prinzip von least privilege durch. ⁴⁸

• Der Container ist für Neustarts und Node-Migrationen ausgelegt (SOLL) - Der Container ist zustandslos mit transaktionaler Verarbeitung konzipiert, sodass Neustarts und Node-Migrationen zur Laufzeit ohne Datenverlust oder Inkonsistenzen möglich sind. Dies ermöglicht Bereitstellungen ohne Ausfallzeiten, erhöht die Ausfallsicherheit und verhindert inkonsistente Zustände, die zu Sicherheitsproblemen führen könnten. ⁴⁹

• Zustandsprüfungen sind definiert (SOLL) - Es sind Lebens-, Bereitschafts- und/oder Startprüfungen definiert, um den Zustand des Containers zu überwachen. Dadurch kann die Plattform fehlerhafte oder kompromittierte Container automatisch erkennen und neu starten, was die Verfügbarkeit erhöht und die Angriffsfläche verringert. ^{50 51}

• Der Container ist nicht an bestimmte Benutzer-IDs gebunden (MUSS) - Die Ausführung der Anwendung funktioniert mit beliebigen Benutzer-IDs. Dies ermöglicht die Ausführung in Umgebungen, die Containern zufällige Benutzer-IDs zuweisen (z. B. OpenShift), und erhöht die Portabilität. ⁵²

• Der Container ist zur Laufzeit unveränderbar (MUSS) - Um Änderungen an den Konfigurationen von laufenden Containern vorzunehmen werden diese Container nicht angepasst sondern ersetzt. Dadurch wird sichergestellt, dass der laufende Container genau mit dem Image übereinstimmt, Konfigurationsabweichungen verhindert werden und reproduzierbare Bereitstellungen möglich sind. ^{53 54}

• Kein privilegierter Modus (MUSS) - Der Container läuft nicht im privilegierten Modus und verfügt über keine erweiterten Host-Rechte. Ausnahmen sind nur für Infrastruktur-Container zulässig. Dies verhindert das Angreifer aus Containern ausbrechen und schützt das Host-System davor, über den Container kompromittiert zu werden. ⁵⁵

• Container-UIDs/GIDs haben keine Host-Berechtigungen (MUSS) - Die im Container verwendeten Benutzer- und Gruppen-IDs benötigen keine Berechtigungen für die Dateien und Verzeichnisse des Hostsystems. Dadurch wird sichergestellt, dass der Angreifer selbst im Falle eines Ausbruch aus dem Container die Host-Ressourcen nicht manipulieren kann. ⁵⁶

• Anwendungsprotokollierung unterstützt forensische Analyse (SOLL) - Die Anwendung protokolliert sicherheitsrelevante Ereignisse in strukturierter Form: eingehende/ausgehende Anfragen, Authentifizierungsversuche, Autorisierungsfehler, Konfigurationsänderungen, usw. Die Protokolle enthalten keine sensiblen Daten. Dies ermöglicht eine forensische Analyse nach Sicherheitsvorfällen, unterstützt die Erkennung von Angriffsmustern und erfüllt Compliance-Anforderungen. ⁵⁷

• Alle Protokolle werden in stdout/stderr geschrieben (MUSS) - Alle Anwendungsprotokolle werden in die Standardausgabe (stdout) und die Standardfehlerausgabe (stderr) geschrieben, nicht in Protokolldateien im Dateisystem des Containers. Dies ermöglicht eine zentrale Protokollaggregation durch die Containerplattform, verhindert das Volllaufen des Dateisystems des Containers und stellt sicher, dass die Protokolle auch nach einem Neustart des Containers für forensische Analysen verfügbar bleiben. ⁵⁸

Compliance- und Schwachstellenmanagement

• SBOM ist attestiert (SOLL) - Es wird eine SBOM erstellt, die vollständig und kryptografisch attestiert ist, um den Inhalt des Containers zu bestätigen. Dies bietet eine manipulationssichere Bestandsaufnahme der Komponenten für Compliance, Lizenzmanagement, Sicherheitsscans und Incident Response. ^{29 30 3}

• Das Schwachstellenmanagement erfolgt zeitnah (SOLL) - Bekannte Schwachstellen werden bewertet, priorisiert und gemäß definierten SLAs auf der Grundlage ihres Schweregrads behoben. Dadurch wird sichergestellt, dass kritische Sicherheitsprobleme behoben werden, bevor Angreifer diese im Software-Produkt ausnutzen können. ^{16 30 3 59}

• VEX wird bestätigt (SOLL) - Es werden VEX-Dokumente (Vulnerability Exploitability eXchange) bereitgestellt und bestätigt, aus denen hervorgeht, welche Schwachstellen im spezifischen Container-Kontext ausnutzbar sind und welche gemindert wurden. Dies reduziert die sog. alert fatigue, indem dokumentiert wird, welche CVEs aufgrund von Konfigurations- oder Nutzungsmustern tatsächlich keine Auswirkungen auf Ihren Container haben. ^{16 30}

Tagging-Format

Weitere Informationen finden Sie in der Tagging-Struktur.

Referenzen