Als bekennender Filmfan sind mir einige Filmzeilen über die Jahre hinweg irgendwie im Gedächtnis geblieben. Einer davon stammt von Ridley Scott Gladiator (2000), wenn ein römischer Senator sagt: „Das schlagende Herz Roms ist nicht der Marmor des Senats, es ist der Sand des Kolosseums.“
Diese Zeile tauchte in meinem Kopf auf, als ich durch die Hallen der KubeCon/CloudNativeCon („KubeCon“) lief, der Hauptveranstaltung für Cloud Native Computing Foundation (CNCF). Für mich ist KubeCon eindeutig das Herzstück der Cloud-nativen Sicherheit.
Die diesjährige nordamerikanische Ausgabe der Veranstaltung fand letzte Woche in Detroit statt und brachte Tausende von Teilnehmern vor Ort und viele andere aus der Ferne zusammen. Zusätzlich zur dreitägigen Hauptveranstaltung hat das wachsende Interesse an bestimmten Projekten die Cloud Native Computing Foundation dazu veranlasst, vor der Hauptkonferenz verschiedene „gemeinsam stattfindende Veranstaltungen“ zu organisieren.
Für die Veranstaltung 2022 gab es nicht nur eine spezielle zweitägige CloudNativeSecurityCon-Veranstaltung, sondern auch zahlreiche Sicherheitsinhalte bei anderen Veranstaltungen, darunter Application Networking Day, EnvoyCon, Policy Day mit OPA, ServiceMeshCon und mehr, was das große Interesse an Cloud- Native Sicherheitsthemen. Interessanterweise hat sich die CloudNativeSecurityCon-Veranstaltung nun selbst zu einer eigenständigen Veranstaltung entwickelt, die im Februar separat ausgerichtet wird.
Cloud-native Sicherheit: Entwicklung vs. Betrieb
Wo ist also der aktuelle Stand der Gespräche über Cloud-native Sicherheit? Für Omdia gibt es eine starke Zweiteilung: entwicklungsorientierte Anliegen und betriebsorientierte Anliegen. Es ist nicht so hilfreich, diese „Dev“ und „Ops“ zu nennen, da die Teamstruktur in vielen Organisationen im Wandel ist: Einige verfügen möglicherweise über SRE-Teams (Site Reliability Engineering), andere nennen sie möglicherweise Operations-, Plattform-Teams und mehr.
Auf der Entwicklungsseite des Hauptbuchs sind drei Themen von Interesse: Herkunft, Lärm und Exposition.
Provenance stellt die grundlegende Frage: Können wir der Integrität der externen Komponente vertrauen, die wir in unsere Software-Pipeline integrieren? Obwohl es viele Beispiele dafür gibt, war der SolarWinds-Angriff im Jahr 2020 ein Wendepunkt für das Interesse an der Integrität der Software-Lieferkette. Auf der KubeCon gab es eine spürbare Dynamik hinter der Idee, Software-Images zu signieren: Die signstore Das Projekt wurde als allgemein verfügbar angekündigt und wird von Kubernetes und anderen Schlüsselprojekten verwendet.
Unter Lärm versteht man die Reduzierung der Anzahl der in der Umgebung vorhandenen Schwachstellen, beginnend mit der Verschlankung der verwendeten Container-Basisimages. Dies kann die Verwendung von Image-Basen wie Alpine oder Debian Slim oder die Erwägung „distroloser“ Alternativen, die noch kleiner sind, umfassen. Der Vorteil besteht darin, dass diese kleineren Bilder nur einen minimalen Platzbedarf haben und daher die Wahrscheinlichkeit, dass Schwachstellen auftauchen, geringer ist.
Gefährdung: Wie gefährdet sind wir als Organisation im Hinblick auf eine bestimmte Schwachstelle? Natürlich gibt es in der jüngeren Branchengeschichte kein besseres Beispiel dafür als Log4j. Dies ist der Bereich der Diskussionen über Software-Stücklisten (SBOMs), da es darum geht, zu wissen, wo Komponenten verwendet werden können, entweder als Images irgendwo in einer Registrierung oder in der Produktion. Interessanterweise gibt es zum Zeitpunkt der Erstellung dieses Aufsatzes eine Vorankündigung, dass Informationen über kritische Schwachstellen in OpenSSL 3.x in Kürze veröffentlicht werden, was wahrscheinlich ein weiterer guter Anwendungsfall für SBOMs sein wird – wo wird OpenSSL 3.x in unserer Organisation eingesetzt? Da die SBOM-Abdeckung noch nicht weit verbreitet ist, rechnet Omdia dieses Mal leider mit einer minimalen SBOM-Nutzung.
Betriebsteams konzentrieren sich natürlich darauf, eine immer komplexer werdende zugrunde liegende Plattform bereitzustellen und zu betreiben, und zwar auf sichere Weise. Das Wort „Plattform“ ist hier besonders relevant: Es bestand ein erhebliches Interesse daran, Kubernetes und viele der wachsenden Liste von CNCF-Projekten (140 zum Zeitpunkt dieses Schreibens, zwischen den verschiedenen Phasen der Projektinkubation: Sandbox, Inkubation, abgestuft) in einfachere zu organisieren. zu konsumierende Plattformen. Von besonderem Interesse für Sicherheitspublikum sind Projekte wie Cilium (unter Verwendung der zugrunde liegenden eBPF-Funktionalität) für Netzwerk und Beobachtbarkeit, SPIFFE/SPIRE (für die Einrichtung von Identitäten), Falco (für Laufzeitsicherheit), Open Policy Agent (für Policy-as-Code). , Cloud Custodian (für Governance) und andere sind einen Blick wert. Es wird erwartet, dass diese Projekte zunehmend mit „Observability“-Aspekten von Cloud-Native zusammenarbeiten und auch mithilfe von Praktiken wie GitOps bereitgestellt werden.
Gründe für Optimismus in Bezug auf Cloud-native Sicherheit
Was machen wir jetzt? Es war völlig klar, dass der Cloud-Native-Community die Sicherheit sehr am Herzen liegt und sie die zahlreichen Themen rund um das Thema mit Hochdruck angeht. Der Leitfaden für Sicherheitsteams besteht darin, sich schnell mit der Umsetzung dieser verschiedenen Projekte und Initiativen vertraut zu machen. Es ist wichtig zu beachten, dass dies für viele Organisationen nicht in Form einer expliziten Nutzung des Community-Projekts geschieht (obwohl einige dies tun werden), sondern vielmehr als Teil einer Paketplattform von Anbietern wie Red Hat, SUSE, Canonical und anderen. oder direkt von den Cloud-Anbietern wie AWS, Google Cloud, Azure, Oracle und anderen.
Beachten Sie, dass es im Kontext der Open-Source-Nutzung so etwas wie „kostenlos“ nicht gibt – selbst wenn man sich für die Verwendung der Vanilla-Upstream-Version von Projekten entscheidet, fallen Kosten für die Wartung dieser Pakete und die Teilnahme an der Community-Entwicklung an.
