Erste Schritte mit gehärteten Images

Was sind gehärtete Images?

Gehärtete Images sind VM- oder OCI-Container-Images, die speziell dafür entwickelt oder vorkonfiguriert wurden, bestimmte Sicherheitsstandards einzuhalten. Der Prozess der Image-Härtung umfasst das Entfernen unnötiger Hilfsprogramme und Bibliotheken, die Implementierung von Konfigurations-Baselines, das Scannen nach Schwachstellen und das Einspielen von Patches.

Gehärtete Images geben Ihnen die Gewissheit, dass Ihre Workload von Anfang an bewährte Sicherheitsmethoden (Best Practices) einhält. Sie können darauf vertrauen, dass ein gehärtetes Images Ihre Angriffsfläche und bekannte Schwachstellen zum Zeitpunkt der Veröffentlichung minimiert. Gehärtete Images werden vor der Verteilung gründlich gegen CVE-Datenbanken gescannt, obwohl im Laufe der Zeit neue Schwachstellen auftreten können – weshalb kontinuierliches Scannen und Patchen so wichtig ist. Einige Anbieter, darunter Wiz, garantieren SLAs für die Behebung von Schwachstellen in ihren Angeboten an gehärteten Images, wodurch sie die Last des Patching übernehmen, damit Kunden ihren Sicherheitsstatus aufrechterhalten können.

Denken Sie daran: Es ist einfacher, Probleme von Anfang an zu verhindern, als Schwachstellen zu beheben, wenn Container und VMs bereits in der Produktion laufen. Aus diesem Grund bringen gehärtete Images greifbare Vorteile: Das frühzeitige Entfernen von Schwachstellen reduziert das Schwachstellen-Rauschen, die Exposition und das Risiko einer Sicherheitsverletzung.

Sicherheitsrelevante Bilder 101

Sichern Sie Ihr Container-Ökosystem mit diesem leicht verständlichen digitalen Poster, das alles Wissenswerte zur Sicherheit von Container-Images übersichtlich erklärt.

Arten von gehärteten Images und wo man sie findet

Es gibt zwei verschiedene Arten von gehärteten Images, kategorisiert nach ihrer Architektur und wie sie mit Ihrer Host-Umgebung interagieren.

Gehärtete VM-Images

Gehärtete VM-Images sind in sich geschlossene Artefakte, die das gesamte Betriebssystem, einen dedizierten Kernel und alle notwendigen Treiber enthalten. Die Härtung dieser Images beinhaltet die Reduzierung des Betriebssystems auf seine wesentlichen Dienste und die Anwendung strenger Konfigurations-Benchmarks – wie CIS Benchmarks oder STIGs. Sie sind so konzipiert, dass sie auf einem Hypervisor (wie Hyper-V oder KVM) ausgeführt werden, um eine starke Isolierung auf Hardwareebene zu gewährleisten.

Gehärtete Container-Images

Gehärtete Container-Images sind leichtgewichtige Artefakte, die nur die Anwendung und ihre User-Space-Abhängigkeiten enthalten; sie teilen sich zur Laufzeit den Kernel des Hosts. Die Härtung konzentriert sich hier auf die Reduzierung der Image-Größe und die Verwendung minimaler Basis-Images, um unnötige Binärdateien zu eliminieren. Indem Sie das Image auf das funktionale Minimum reduzieren, verringern Sie die Angriffsfläche. Die Härtung von Container-Images konzentriert sich zudem auf das Entfernen von Schwachstellen. „Gesicherte“ Images gehen bei der Image-Härtung noch einen Schritt weiter, indem sie Garantien für die CVE-Behebung bieten. Diese gesicherten Images werden unter SLAs, die von einem Anbieter unterstützt werden, kontinuierlich mit nahezu null CVEs gewartet.

Sobald Sie Ihre Architektur festgelegt haben, können Sie Images aus verschiedenen Kanälen beziehen:

Marktplätze von Cloud-Dienstanbietern: Alle gängigen Cloud-Plattformen hosten Marktplätze, auf denen Sie vorab gehärtete Images erhalten können, die kontinuierlich gewartet werden. Denken Sie daran, dass deren Nutzung zusätzliche Kosten verursachen kann, die pro Stunde VM-Nutzung oder pro Instanz pro Monat abgerechnet werden.
Private Anbieter von gehärteten Images: Anbieter wie das Center for Internet Security (CIS Benchmark-konforme Images) bieten vorab gehärtete Images aus öffentlichen oder privaten Registern an.
Anbieter von gesicherten Images / verwalteten gehärteten Images: Anbieter wie Wiz erstellen und warten gehärtete Images mit strengen, vom Anbieter unterstützten SLAs für die CVE-Behebung. Dies geht noch einen Schritt weiter als herkömmliche gehärtete Images, indem es den Kunden die Last des Patching und der Wartung abnimmt und ihnen hilft, ihren gehärteten Sicherheitsstatus über die Zeit hinweg aufrechtzuerhalten.
Selbst erstellen: Wenn Sie die vollständige Kontrolle über den gesamten Härtungsprozess behalten möchten, können Sie selbst ein gehärtetes Image erstellen. Dies ist die arbeitsintensivste Option. Abgesehen vom Erstellungsprozess müssen Sie auch Aufwand in die Wartung Ihres gehärteten Images investieren, um mit der sich entwickelnden Bedrohungslandschaft Schritt zu halten.

Aufbau einer sicheren Image-Pipeline von der Quelle bis zur Bereitstellung

Betrachten wir als Nächstes einen allgemeinen Ablauf für den Aufbau einer sicheren Image-Pipeline. Auch wenn Ihre genauen Schritte von der Art des zu erstellenden Images und seinem Verwendungszweck abhängen, helfen Ihnen diese schrittweisen Tipps dabei, erfolgreich zu sein:

Entwickeln

Definieren Sie Ihre Anforderungen und Ziele.
Wählen Sie ein gutes Basis-Image –entweder minimal (für VMs und Container) oder Distroless (nur für Container) – aus vertrauenswürdigen, zuverlässigen Quellen. Distroless-Images besitzen keine Shells, Paketmanager und gängigen Hilfsprogramme, sind jedoch nicht automatisch gehärtet – sie erfordern dennoch Sicherheitskonfigurationen und Scans.
Konfigurieren Sie interne Sicherheitsmechanismen und -tools , die zum Framework Ihrer Wahl passen (z. B. CIS Benchmarks oder DISA STIG).
Verringern Sie die Angriffsfläche weiter durch architekturspezifische Kontrollen:
Für VMs: Konfigurieren Sie Host-Firewalls (iptables, nftables), um eine „Standard-Verweigern“-Richtlinie (Default-Deny) zu implementieren und sicherzustellen, dass nur absolut notwendige Ports geöffnet sind.
Für Container: Vermeiden Sie ein „Aufblähen“ von Images durch Firewalls im Container. Konfigurieren Sie den Container stattdessen so, dass er mit einem schreibgeschützten Root-Dateisystem ausgeführt wird. Dies ist eine der effektivsten Methoden, um zu verhindern, dass ein Angreifer Malware herunterlädt oder Persistenz erlangt, falls er sich initialen Zugriff verschafft.
Für beide: Schalten Sie den Standardbenutzer auf Nicht-Root um, entfernen Sie unnötige Linux-Funktionen (wie CAP_NET_RAW oder CAP_SYS_ADMIN), und stellen Sie sicher, dass Sicherheitsprofile (wie AppArmor oder Seccomp) verwendet werden, um die Angriffsfläche des Kernels einzuschränken.

Profi-Tipp

Bewahren Sie Ihre Geheimnisse in dieser Phase sicher auf! Das Festkodieren im Image untergräbt all die Mühe, die Sie bisher in den Härtungsprozess gesteckt haben.

Erstellen

Verwenden Sie CI/CD zum Erstellen von Images: Automatisiertes Hardening verringert den Arbeitsaufwand erheblich, spart viel Zeit und liefert Ihnen eine frische Quelle gut getesteter Images.

Verwenden Sie für Container aktuelle, sicherheitsbewusste Build-Tools (z. B. BuildKit oder Buildpacks).
Kodieren Sie für VMs den Build-Prozess mit Packer oder Cloud-nativen Tools (wie dem Azure Image Builder).
Stellen Sie sicher, dass die Build-Pipeline selbst sicher ist!

Scannen

Scannen Sie das Image und dessen gesamter Inhalt auf Schwachstellen und ersetzen Sie fehlerhafte Pakete und Bibliotheken durch vertrauenswürdige, sichere Versionen (oder Alternativen).

Tools wie Trivy, Grype oder Wiz können in dieser Phase nützlich sein.
Da jeden Tag neue Schwachstellen entdeckt werden, sollten Sie bereits erstellte Images regelmäßig erneut scannen, um sicherzustellen, dass sie widerstandsfähig bleiben.

Herkunft hinzufügen

Die Ermittlung des Ursprungs, der Änderungshistorie und der für das Image geltenden Standards ermöglicht spätere einfache Sicherheits- und Compliance-Prüfungen und verhindert zudem Manipulationen.

Generieren Sie eine SBOM, um den genauen Inhalt Ihres Basis-Images nachzuverfolgen. SBOMs gibt es in verschiedenen Formaten – SPDX (von der Linux Foundation) und CycloneDX (von OWASP) sind die beiden Industriestandards. Stellen Sie sicher, dass Sie ein Format wählen, das mit dem Rest Ihres Sicherheits-, Compliance- und Lieferkettenschutz-Ökosystems kompatibel ist.
Signieren Sie das Image , um spätere Integritätsprüfungen zu ermöglichen. Sie können Images mit Lösungen wie Sigstore Cosign, Notary oder Docker Content Trust signieren. Auch Cloud-native Dienste wie AWS Signer können helfen. Hier ist ein Beispiel: Mit Cosign können Sie ein Container-Image mit einem einzigen Befehl signieren: cosign sign --key <private key> <image>. Diese Signatur kann später verifiziert werden mit cosign verify --key <public key> <image>.
Attestieren Sie das Image, indem Sie kryptografisch signierte Erklärungen (unter Verwendung von SLSA-Provenienz oder in-toto-Attestationen) über den Build-Ursprung, SBOM-Inhalte und Sicherheitsscannergebnisse erstellen. Diese signierten Attestationen ermöglichen es nachgelagerten Verbrauchern zu überprüfen, ob das Image nicht manipuliert wurde und Sicherheitsrichtlinien erfüllt.

Verifizieren

In diesem Schritt blicken Sie auf all die geleistete Arbeit zurück.

Validieren Sie das Image anhand Ihrer gewählten Benchmarks. Untersuchen Sie Ihre Scans, rechtfertigen Sie Ausnahmen und berichten Sie über das Endergebnis.
Testen Sie, ob das Image wie erwartet funktioniert. Einige Sicherheitsmaßnahmen, insbesondere die strengsten, können Dinge beschädigen. Beispielsweise könnte eine sehr gründliche Minimierung Bibliotheken entfernen, die Sie eigentlich benötigt haben. Der Verifizierungsschritt ist Ihre letzte Chance sicherzustellen, dass alles ordnungsgemäß funktioniert, bevor Ihr Image für das Deployment vorbereitet wird.

Promoten und deployen

Das Image ist fertig. Nun kann es Teil Ihrer Umgebungen werden – natürlich nach bestandenen Prüfungen auf der Zielgeraden.

Konfigurieren Sie Promotion-Gates, um nur Images zuzulassen, die Richtlinienschwellenwerte erfüllen – zum Beispiel keine kritischen oder schwerwiegenden CVEs mit verfügbaren Fixes, obligatorische Image-Signaturen und -Attestationen sowie die Einhaltung von CIS-Benchmarks. Definieren Sie Risikoakzeptanz-Workflows für Schwachstellen ohne Patches.
Richten Sie die Zulassungskontrolle (Admission Control) mit OPA Gatekeeper, Kyverno oder Kubernetes Pod Security Admission (PSA) ein, um nur signierte, attestierte, getestete und konforme Container-Images als Deployment-Kandidaten zu akzeptieren. Beispielsweise kann eine Kyverno-Richtlinie Cosign-Signaturen verifizieren und unsignierte Images zum Zeitpunkt des Deployments blockieren.

Sicherheitsteams kämpfen oft mit fragmentierten Tools – ein Scanner für CI, ein anderer für Registries, ein dritter für die Laufzeit –, jedes mit anderen Richtlinien und Schwellenwerten stattdessen. Erwägen Sie stattdessen die Implementierung einer einzigen Richtlinien-Engine. Streben Sie nur eine einzige Richtlinie für den gesamten Workflow an: von der Entwicklung über CI und Umgebungs-Promotions bis hin zur Zulassung. Auf diese Weise können Sie eine einheitliche, konsistente und robuste Sicherheitslage ohne unnötige Tool-Fragmentierung und den damit verbundenen Mehraufwand aufrechterhalten.

12-Min.-Demo ansehen

Wiz identifiziert exponierte Container, visualisiert den vollständigen Angriffsfad und behebt das Problem direkt im Code.

Häufige Fallstricke beim Härtungsprozess, die Cloud-Operationen stören

Unsichere Konfigurationen

Einer der wichtigsten Teile der Härtung? Sichere Konfiguration. Probleme mit Images rühren häufig von einfachen Fehlern her. Wir sprechen von übrig gebliebenen permissiven Firewall-Konfigurationen, deaktivierten integrierten Sicherheitstools und Fehlkonfigurationen von SELinux/AppArmor/seccomp auf dem VM-/Container-Host. Leider beeinträchtigen diese Fehler die Zuverlässigkeit des resultierenden Images erheblich.

Abhängigkeiten und Ergänzungen

Gehärtete Images sind so konzipiert, dass sie von Haus aus sicher sind, aber das bedeutet nicht, dass sie immer sicher bleiben werden. Wenn Sie ein gehärtetes Image als Basis-Image für Ihre Anwendung verwenden, können dessen Abhängigkeiten und der Build-Prozess Schwachstellen einführen (oder erneut einführen). Wenn Sie einem gehärteten Image in irgendeiner Form etwas hinzufügen, müssen Sie es erneut scannen.

Laufzeit-Fehlkonfigurationen

Laufzeit-Fehlkonfigurationen wie überprivilegierter Zugriff oder ausgelassene kritische Software-Updates und -Patches machen selbst ein gut gehärtetes Image anfällig für Probleme. Dies gilt insbesondere für Container; das Ausführen im privilegierten Modus, die Verwendung des Root-Benutzers im Container, übermäßige Kernel-Fähigkeiten oder Schreibberechtigungen für das Root-Dateisystem können genau der Hebel sein, den ein böswilliger Akteur für einen Container-Ausbruch benötigt.

Der Versuch, all diese Fallstricke ohne tiefen, spezifischen Kontext (z. B. Internetexposition + privilegierter Container + sensible Daten) zu beseitigen, wird Ihr Team dazu zwingen, Rauschen hinterherzulaufen. Konzentrieren Sie sich stattdessen auf einen Risiko-Graphen-Ansatz, um das Wesentliche zu priorisieren und zielgerichtete, präzise Korrekturen bereitzustellen.

Schritt-für-Schritt-Leitfaden für die Implementierung gehärteter Images

Wenn Sie Shift Left praktizieren möchten (und glauben Sie uns, das wollen Sie), implementieren Sie gehärtete Images ganz am Anfang Ihres Projekts. Und so geht's:

Wählen Sie Standards und Richtlinien aus, die am besten zu Ihrem Unternehmen passen. Wenn Sie sich nicht sicher sind, können CIS Benchmarks ein großartiger Ausgangspunkt sein.
Identifizieren Sie die Workloads, die gehärtet werden müssen, und legen Sie Prioritäten fest. Einige Workloads sind wichtiger als andere. Wählen Sie also sorgfältig aus, welche Ihre Aufmerksamkeit am meisten benötigen. Um den Rest können Sie sich später kümmern.
Entscheiden Sie sich für den geeigneten Ansatz zur Behebung. Möchten Sie ein Image selbst erstellen, ein Basis-Image verwenden und die Anwendung oben draufsetzen oder sich für eine vollständig vorgefertigte Lösung entscheiden?
Integrieren Sie die Images Ihrer Wahl in Ihre Workflows. Passen Sie Ihre CI/CD-Pipelines so an, dass sie eine wichtige Rolle im Prozess spielen: Konfigurieren Sie beispielsweise periodische Scans oder automatische Builds, wenn ein Patch verfügbar wird.
Überwachen Sie Ihre Umgebung und wahren Sie den goldenen Standard – überprüfen Sie Ihre Sicherheitsposition regelmäßig, überwachen Sie kontinuierlich auf neue Schwachstellen und bewerten Sie die Qualität Ihrer Images neu, um sie sauber und sicher zu halten.
Streben Sie eine bidirektionale Rückverfolgbarkeit an: Wenn ein Problem in der Cloud gefunden wird, sollten Sie es mühelos auf das Basis-Image und die Pipeline zurückführen können, die es erzeugt haben; wenn Sie Fehler im Code/Build beheben, validieren Sie die Abweichung in der betroffenen Cloud. Das automatische Erfassen zusätzlicher Kontexte verkürzt die durchschnittliche Behebungszeit (MTTR) von Tagen auf Stunden, da manuelle Untersuchungen und Ticket-Übergaben entfallen. Hier sind die Kontexte, die Sie erfassen sollten:
Cloud-Ressource: ECS-Task, Kubernetes-Pod, VM-Instanz
Container-Image: Registry, Tag, Digest, Build-Zeitstempel
CI/CD-Pipeline: Jenkins-Job, GitHub Actions-Workflow, GitLab-Pipeline
Quellcode: Repository, Dockerfile, Commit-SHA, Autor
Besitzer: Team-Slack-Channel, On-Call-Rotation, JIRA-Projekt

Wie Wiz Möglichkeiten für gehärtete Images identifiziert und priorisiert

Die Beschaffung gehärteter Images ist erst der Anfang einer langen Reise zum Schutz Ihres Unternehmens. Zum Glück müssen Sie nicht alle Schritte, Hindernisse und den ständigen Kampf um Sicherheit ganz alleine bewältigen. Es gibt einen besseren, einfacheren Weg: Wiz.

WizOS-Images bieten eine sichere, produktionsbereite Grundlage für containerisierte Anwendungen und zeichnen sich durch gehärtete, minimalistische Images mit einem CVE-Profil nahe Null aus. Jedes Release ist signiert und enthält eine SBOM zur Sicherstellung der Herkunft. Images werden von Wiz kontinuierlich im Rahmen einer SLA verwaltet, sodass Ihre Entwickler von der Behebung entlastet werden.
Der Wiz Security Graph korreliert Image-CVEs mit Netzwerkexposition, Identitäten und Datensensibilität, sodass Sie unsichere Images auf einen Blick erkennen und die dringendsten Korrekturen zuerst priorisieren können. Die bidirektionale Code-to-Cloud-Nachverfolgbarkeit bietet alles, was Ihr Team benötigt, um festzustellen, welche Dienste das Image erstellen, wem es gehört und wie Richtlinien vor der Bereitstellung durchgesetzt werden.
Das Container-Image-Inventar von Wiz sorgt dafür, dass jedes Image in all Ihren Codes, Clouds und Registern erfasst wird. Teams können die anfälligsten Images schnell identifizieren und für die Migration auf eine gehärtete Alternative wie WizOS priorisieren.

Möchten Sie mehr erfahren? Registrieren Sie sich für eine Demo und überzeugen Sie sich selbst davon, wie Wiz alles schützen kann, was Sie in der Cloud erstellen und ausführen!

Eine Container-Sicherheits-Demo anfordern

Erleben Sie aus erster Hand, wie Wiz Ihre Container nach Schwachstellen durchsucht und wie WizOS-Basisimages Ihre CVE-Anzahl auf nahezu Null senken können.