Was sind die wichtigsten Vorteile von Kaspersky Container Security Standard Base?
Zentrale Konsole – Eine Webkonsole für alle verbundenen Registries.
Registry-Scan – Überprüft Images in Docker Hub, Harbor und Artifactory.
Pipeline-Integration – Blockiert fehlgeschlagene Builds in Jenkins und TeamCity.
Bedrohungsabdeckung – Schwachstellen, Malware und vertrauliche Daten in einem einzigen Scan.
IaC-Prüfungen – Konfigurationsdateien werden vor der Bereitstellung auf Fehler überprüft.
Wichtiger Hinweis – Für den Laufzeitschutz ist die Advanced-Stufe erforderlich.
Verwaltungskonsole – Weboberfläche für Scans, Richtlinien und Befunde.
Registry-Integration – Docker Hub, Harbor, Artifactory, Nexus, Quay, ECR.
Image-Scans – Schwachstellen, Malware und vertrauliche Daten wie Schlüssel und Tokens.
IaC-Scans – Konfigurationsdateien werden auf Fehler und schlechte Praktiken überprüft.
CI/CD-Integration – Jenkins, TeamCity und CircleCI können fehlgeschlagene Builds blockieren.
Wichtig – Laufzeitschutz und Cluster-Prüfungen erfordern die „Advanced“-Stufe.
Kaspersky Container Security ist eine spezielle Plattform für containerisierte Anwendungen mit eigener Web-Verwaltungskonsole und gehört neben Kaspersky Hybrid Cloud Security zur Produktreihe „Kaspersky Cloud Workload Security“. „Standard“ ist die Scan-Stufe dieser Plattform: Sie deckt Image-Registerst, CI/CD-Pipelines und Infrastructure-as-Code-Dateien ab – also die Phase, bevor etwas den Cluster erreicht.
Befunde vor der Bereitstellung – Probleme werden bereits beim Build erkannt, nicht erst in der Produktion.
Erkennung vertraulicher Daten – Findet Passwörter, Zugriffsschlüssel und Tokens in Images.
Zwei Quellen für Schwachstellen – NIST- und Kaspersky-Datenbanken speisen denselben Scan.
Build-Gate – Die Pipeline-Phase schlägt fehl, wenn eine Richtlinie verletzt wird.
Eigene Infrastruktur – Lässt sich in einem öffentlichen oder privaten Unternehmensnetzwerk installieren.
Benachrichtigungsziele – Syslog an SIEM, LDAP, E-Mail, Telegram, Webhook.
Entscheidend ist nicht die Mitarbeiterzahl, sondern ob Ihre Entwickler eigene Container-Images erstellen und veröffentlichen. Ein Softwarehaus mit zwölf Mitarbeitern, das über eine GitLab-Pipeline und ein Harbor-Registry verfügt, hat mehr Nutzen von dieser Stufe als ein Hersteller mit 300 Mitarbeitern, der nur fertige Software kauft. Die Standard-Stufe setzt voraus, dass jemand für den Build-Prozess verantwortlich ist und bei einem fehlgeschlagenen Scan Maßnahmen ergreifen kann.
| Voraussetzung | Kleines Unternehmen | Mittelständisches Unternehmen | Großunternehmen |
|---|---|---|---|
| Meldepflicht in der Schweiz | Selten | Nach Branche | Häufig |
| NIS 2 in der Europäischen Union | Selten | Nach Sektor | Häufig |
| Sicherheitsfragebogen von Großkunden | Manchmal | Häufig | In der Regel |
| Eigenentwickelte Container-Images | Manchmal | Häufig | Meistens |
| Dieses Produkt eignet sich | Nur mit eigenen Builds | ✓ | Fortgeschrittene in der Regel |
Kein Produkt erfüllt diese Anforderungen von sich aus, und dieses Produkt deckt nur einen Teil des Gesamtbildes ab. Gemäss dem revidierten Informationssicherheitsgesetz gilt die Meldepflicht seit dem 1. April 2025: Betreiber kritischer Infrastrukturen müssen einen meldepflichtigen Cyberangriff innerhalb von 24 Stunden nach dessen Entdeckung dem Bundesamt für Cybersicherheit (BACS) melden und haben bis zu 14 Tage Zeit, um den Bericht zu vervollständigen. Was die „Standard“-Stufe zu diesem 14-Tage-Zeitraum beiträgt, ist die Dokumentation: Der Scan-Verlauf und das Meldesystem zeigen, welche Image-Version welche Schwachstelle aufwies und wann diese gemeldet wurde – was in der Regel der zeitaufwendigste Teil bei der Rekonstruktion eines Vorfallsberichts ist. Was die „Standard“-Stufe nicht leistet, ist die Erkennung selbst, da sie keine laufenden Container überwacht und Sie daher nicht durch das System darüber informiert werden, dass ein Angriff im Gange ist. Dieser Text stellt keine Rechtsberatung dar; ob Ihre Organisation der Meldepflicht unterliegt, sollten Sie mit einem Fachmann klären.
Keine Software macht eine Organisation konform, da sich die NIS-2-Richtlinie auf Managementprozesse und nicht auf Produkte bezieht. Zu den von der Richtlinie geforderten Maßnahmenkategorien gehören Risikomanagementrichtlinien, Vorfallbearbeitung, Geschäftskontinuität, Lieferkettensicherheit sowie Sicherheit bei der Beschaffung, Entwicklung und Wartung von Netzwerk- und Informationssystemen, einschließlich des Umgangs mit Schwachstellen. Die Stufe „Standard“ deckt zwei dieser Bereiche ab: den Umgang mit Schwachstellen während der Entwicklung und die Sicherheit der Lieferkette, da das Scannen eines Basisimages eines Drittanbieters, bevor es in die eigene Anwendung integriert wird, eine Maßnahme zur Kontrolle der Lieferkette darstellt. Die Stufe deckt weder den Umgang mit Vorfällen, die Geschäftskontinuität, die Zugriffskontrolle, die Kryptografie noch die Mitarbeiterschulung ab und liefert für keinen dieser Bereiche Nachweise. Organisationen, die dokumentierte Konfigurationsprüfungen anhand anerkannter Benchmarks benötigen, werden diese in dieser Stufe nicht finden.
Zwei veröffentlichte Maßnahmen betreffen diesen Anbieter, und beide sind weiterhin in Kraft. Die Bundesamt für Informationssicherheit in Deutschland warnt seit dem 15. März 2022 vor der Nutzung von Kaspersky-Virenschutzsoftware und empfiehlt, solche Anwendungen durch alternative Produkte zu ersetzen; die Warnung ist nach wie vor veröffentlicht, und Kaspersky weist sie als nicht auf einer objektiven technischen Analyse beruhend zurück und drängt weiterhin auf deren Rücknahme. Unabhängig davon erließ das US-Handelsministerium im Juni 2024 eine endgültige Entscheidung, die die Lieferung von Kaspersky-Cybersicherheits- und Antivirenprodukten an US-Personen verbietet, wobei neue Verträge ab dem 20. Juli 2024 und Updates ab dem 29. September 2024 untersagt sind; Kaspersky erklärt, die Entscheidung spiegele eher das geopolitische Klima wider als eine Bewertung seiner Produkte, und auf der eigenen Produktseite wird bestätigt, dass Testversionen und Downloads für US-Kunden nicht verfügbar sind. In der Schweiz wurde kein vergleichbares Verkaufsverbot veröffentlicht. In der Praxis ist dies vor allem für Ausschreibungen im öffentlichen Sektor, für Lieferanten deutscher Behörden sowie für Unternehmen von Bedeutung, deren Kunden in ihren Lieferkettenanforderungen Bedingungen hinsichtlich der Herkunft der Anbieter vorschreiben; bei einer rein internen Entwicklungspipeline ohne solche Bedingungen liegt die Entscheidung bei Ihnen.
Teilweise, und zwar nur im Bereich der Softwareentwicklung. Es liefert Ihnen eine dokumentierte Antwort auf Fragen zum Scannen von Container-Images auf bekannte Schwachstellen, zum Erkennen fest codierter Anmeldedaten und Tokens in Build-Artefakten, zur Überprüfung von „Infrastructure-as-Code“ vor der Bereitstellung, zur Durchsetzung eines Sicherheits-Gateways in der CI/CD-Pipeline sowie zur Weiterleitung von Ereignissen an ein SIEM. Es liefert Ihnen keinerlei Antwort auf Fragen zur Erkennung und Reaktion während der Laufzeit, zum Endgeräteschutz, zu Nachweisen für das Patch-Management, zur Festplattenverschlüsselung, zur Multi-Faktor-Authentifizierung, zur Datensicherung oder zu dokumentierten Konfigurationsprüfungen des Clusters selbst. Wenn der Fragebogen, der einen Vertrag blockiert, nach Laufzeitüberwachung oder benchmarkbasierten Konfigurationsnachweisen fragt, schließt die „Advanced“-Stufe desselben Produkts diese Punkte ab und ist in der Regel kostengünstiger als die Hinzunahme einer Plattform eines zweiten Anbieters neben dieser. Beachten Sie, dass in Fragebögen zunehmend gefragt wird, wo der Hauptsitz des jeweiligen Sicherheitsanbieters liegt – dies ist eine separate Frage, die dieses Produkt nicht für Sie beantworten kann.
Die Trennlinie liegt darin, ob der Container bereits läuft. „Standard“ arbeitet mit Artefakten vor der Bereitstellung: Images in Registries, Images und IaC-Dateien in der Pipeline sowie die Risikobewertung der Ergebnisse dieser Scans. „Advanced“ ergänzt dies um alle Aspekte, die Live-Workloads und die ihnen zugrunde liegende Plattform betreffen, einschließlich des Scannens von bereits in einem Cluster vorhandenen Images, der Steuerung, welche Container gestartet werden dürfen, der Verhaltensanalyse, des Scannens von Knoten-Betriebssystemen sowie der Konfigurationsanalyse im Hinblick auf regulatorische Anforderungen. „Advanced Pro“ geht noch einen Schritt weiter und bietet zusätzlich die Integration mit einem in Ihrer eigenen Infrastruktur bereitgestellten KI-Assistenten sowie Sicherheits-Benchmarks, die Sie an Ihre eigenen Standards anpassen können. Kasperskys eigene Lizenzierungsbeispiele verdeutlichen die Unterscheidung: Einem Kunden, der ausschließlich Container-Images absichern möchte, wird „Standard“ angeboten, während einem Kunden, der zusätzlich Laufzeit- und Compliance-Prüfungen wünscht, „Advanced“ angeboten wird.
| Funktionsumfang | Standard | Advanced | Advanced Pro |
|---|---|---|---|
| Registry- und CI/CD-Image-Scan | ✓ | ✓ | ✓ |
| Scannen von IaC-Konfigurationen | ✓ | ✓ | ✓ |
| Benachrichtigungen über SIEM, LDAP, E-Mail und Webhooks | ✓ | ✓ | ✓ |
| Scannen von Images, die sich bereits in einem Cluster befinden | ✕ | ✓ | ✓ |
| Steuerung des Container-Starts | ✕ | ✓ | ✓ |
| Analyse des Laufzeitenverhaltens | ✕ | ✓ | ✓ |
| Überprüfung des Betriebssystems der Knoten | ✕ | ✓ | ✓ |
| Konfigurationsanalyse zur Einhaltung gesetzlicher Vorschriften | ✕ | ✓ | ✓ |
| Cluster-Ereignisprotokoll wird direkt an SIEM gesendet | ✕ | ✓ | ✓ |
| Integration eines KI-Assistenten | ✕ | ✕ | ✓ |
| Maßgeschneiderte Sicherheits-Benchmarks | ✕ | ✕ | ✓ |
Der häufigste Grund für einen Nachkauf ist die Lücke in der Laufzeitüberwachung: Teams kaufen zunächst die Standard-Version, um ihre Images zu bereinigen, stellen dann fest, dass die Container während des Betriebs nicht überwacht werden, und wechseln noch im selben Jahr zur Advanced-Version. Zudem gibt es eine regionale Einschränkung, da die Plattform für US-Kunden nicht verfügbar ist; daher kann ein Schweizer oder europäischer Konzern mit einer US-Tochtergesellschaft sie nicht einheitlich an allen Standorten einführen. Die Plattformabdeckung beschränkt sich auf Containerumgebungen – Kubernetes, Red Hat OpenShift, Azure AKS und Amazon ECS, wobei AWS, Microsoft Azure und Google Cloud Platform als unterstützte öffentliche Clouds gelten –, sodass Windows-Workstations, Dateiserver, E-Mail-Postfächer und mobile Geräte vollständig außerhalb des Anwendungsbereichs liegen und ein separates Produkt erfordern. Standard scannt zudem nicht das Betriebssystem der Knoten selbst, was Käufer überrascht, die erwarten, dass eine Sicherheitsplattform in einem Cluster auch die darunter liegenden Hosts abdeckt.
Nein. „Base“ ist die Bezeichnung für eine Einzelhandelslizenz, die Kaspersky in seinem gesamten Produktportfolio für einen Erstkauf verwendet, im Gegensatz zu einer „Renewal“-Liste für eine bestehende Lizenz desselben Produkts. Die Plattform läuft eigenständig mit einer eigenen Verwaltungskonsole und erfordert weder „Kaspersky Hybrid Cloud Security“ noch ein anderes Kaspersky-Produkt, obwohl sie im Sortiment von „Kaspersky Cloud Workload Security“ neben „Hybrid Cloud Security“ positioniert ist.
Nein, und die beiden sind nicht austauschbar. Diese Plattform scannt Container-Images, Bereitstellungsartefakte und Konfigurationsdateien und identifiziert dabei Schwachstellen, Malware, vertrauliche Daten und Fehlkonfigurationen innerhalb dieser Artefakte. Laptops, physische und virtuelle Server, E-Mail-Postfächer und mobile Geräte fallen in keiner Stufe in den Anwendungsbereich und erfordern ein separates Endpoint- oder Workload-Produkt.
Die Plattform wird in Ihrer eigenen Umgebung installiert – entweder in einem öffentlichen oder einem privaten Unternehmensnetzwerk – und über eine Webkonsole bedient, auf die Sie mit Chrome, Edge, Safari oder Firefox zugreifen können. Sie kann auf externe Datenbank- und Speichersysteme verweisen, die Sie bereits betreiben, darunter PostgreSQL, ClickHouse und MinIO, sodass der Scanverlauf und die Ergebnisse in der von Ihnen kontrollierten Infrastruktur verbleiben. Dies ist für Käufer von Bedeutung, die in einem Fragebogen angeben müssen, wo Sicherheitstelemetriedaten verarbeitet werden.
| Betriebssysteme | CentOS 8.2.2004 oder höher: Linux-Kernel 4.18.0-193 oder später Ubuntu 18.04.2 oder später: Linux-Kernel 4.18.0 oder neuer Debian 10 oder neuer: Linux-Kernel 4.19.0 oder später Astra Linux SE 1.7.*: Linux-Kernel 6.1.50-1-generic und CONFIG_DEBUG_INFO_BTF=y RHEL 9.4 oder später: Linux-Kernel 5.14 oder höher Red Hat Enterprise Linux CoreOS 416.94.202408200132-0: Linux-Kernel 5.14.0-427.33.1.el9_4.x86_64 RED OS 7.3 oder höher: Linux-Kernel 6.1 oder später / CRI CRI-O / CNI Calico Sber Linux 8.9 / 9.3: Linux-Kernel 5.14 / CRI CRI-O / CNI Calico / Cilium |
| Orchestrierungsplattformen | Kubernetes 1.21 oder höher / OpenShift 4.8 / 4.11 oder höher / DeckHouse 1.70.17 oder 1.71.3 / Platform V DropApp 2.1 / Shturval 2.10 |
| Linux Kernel | Linux-Kernel 4.18 oder höher für Laufzeitüberwachung mit Container-Laufzeitprofilen |
| Container Runtime Interface | containerd / CRI-O |
| Container Network Interface | Flannel / Calico / Cilium |
| Package Manager | Helm 3.10.0 oder höher |
| Architektur | x86 |
| Cluster-Ressourcen | Drei Arbeitsknoten mit drei Scanner-Pods und einer maximalen Bildscangröße von 10 GB: mindestens 12 Prozessorkerne / mindestens 20 GB RAM / 40 GB freier Festplattenspeicher / mindestens 1 Gbit/s Bandbreite zwischen den Clusterkomponenten |
| Agent Ressourcen | Baseline pro Arbeitsknoten: 0,2 Prozessorkerne / 200 MB RAM / 15 GB freier Festplattenspeicher / Alle Agentenfunktionalitäten aktiviert: 2 Prozessorkerne / 4 GB RAM |
| Datenbankunterstützung | ClickHouse 25.x / PostgreSQL Postgres Pro Standard Enterprise 15 / 17 / Pangolin 6.2.0 |
| Bildregistrierungen | Amazon Elastic Container Registry / Azure Container Registry API 2023-01-01-preview / Docker Hub v2 API / Docker Registry v2 API / GitLab Registry 14.2 oder höher / Google Artifact Registry / Harbor 2.x / JFrog Artifactory 7.55 oder später / Red Hat Quay 3.x / Sfera 2.0 / Sonatype Nexus Repository OSS 3.43 oder später / Yandex Registry |
| Netzwerkunterstützung | IPv4 / IPv6 |
| Cloud-Plattformen | Yandex Cloud / Amazon AWS EKS / Microsoft Azure AKS |
| Benutzerarbeitsplatz | Ständige Internetverbindung für öffentliche Unternehmensnetzwerke / Zugriff auf die Management Console Seite im Unternehmensnetzwerk / Kommunikationskanäle mindestens 10 Mbit/s |
| Unterstützte Browser | Google Chrome 140 oder höher / Mozilla Firefox 143 oder höher |