Schlagwort-Archive: Kubernetes

Supply Chain-Angriffe im Cloud Computing vermeiden

Originalartikel von Trend Micro

Sicherheit ist einer der wichtigen Aspekte, die Unternehmen berücksichtigen müssen, wenn sie auf Cloud-basierte Technologien setzen. Ganz oben auf der Liste der zu sichernden Ressourcen stehen Netzwerke, Endpunkte und Anwendungen. Um Betriebskosten zu optimieren, verlagern einige Organisationen ihre Backend-Infrastruktur in die Cloud oder betreiben ihre eigene firmeninterne private Cloud mit Cloud-basierten Lösungen. Doch wird dieser Ansatz vom Standpunkt der Architektur oder auch die Konfigurationen nicht korrekt durchgeführt, so kann das Backend Bedrohungen ausgesetzt werden und ein leichtes Ziel für Supply Chain-Angriffe darstellen. Die Folge sind der Verlust von Daten, Reputation und Vertrauen der Kunden.

In dem Whitepaper „Supply Chain Attacks in the Age of Cloud Computing: Risks, Mitigations, and the Importance of Securing Back Ends“ liefern die Sicherheitsforscher von Trend Micro einen Überblick über verschiedene Sicherheitsrisiken und Techniken zur Minimierung der Gefahren für DevOps.

Die Analysen beziehen sich auf konkrete Beispiele wie Jenkins (quelloffener Integrationsserver für Softwarekomponenten), Docker Container, Kubernetes (Orchestrierungs-Tool) und Cloud-basierten integrierten Entwicklungsumgebungen (IDE) wie AWS Cloud9 und Visual Studio Codespaces.

Authentifizierung und Access Control Lists (ACL)

Wird keine Authentifizierung aufgesetzt oder rollenbasierte Sicherheit mit ACL nicht angewendet, hat jeder, der in das System gelangen kann, Administratorzugriff. Diese Risiken werden anhand von Jenkins als Beispiel aufgezeigt.

Jenkins

Standardkonfigurationen in Backend-Systemen stellen selbst bei Anwendung der Authentifizierung ein erhebliches Sicherheitsrisiko dar. Jenkins Primary ist standardmässig in der Lage, Build-Aufgaben durchzuführen und erlaubt es Nutzern mit geringeren Privilegien, die Jenkins-Instanz vollständig zu übernehmen, einschliesslich der vertraulichen Daten, Job-Konfiguration und Source Code. Es ist kein Authentifizierungs- oder Access Control Lists (ACLs)-Modell vorhanden. Wird die Matrix-basierte Sicherheit von Jenkins angewendet, erhalten Nutzer irrtümlich den Eindruck, mit einer sicheren Konfiguration zu arbeiten. Um die Ausführung von Jobs auf dem Primary zu deaktivieren, könnte das Plug-In Authorize Project zusammen mit der Einstellung Shell executable in /bin/false auf der Seite „Configure System“ verwendet werden.

Des Weiteren sollten Entwicklerteams die Nutzung von Community Pug-Ins überdenken. Den Sicherheits-Advisories von Jenkins zufolge stehen die meisten Sicherheitslücken in der Plattform in Zusammenhang mit Plug-Ins, wobei es sich bei den meisten um die unsichere Speicherung von vertraulichen Daten sowie Sandbox-basierte Ausbruchmöglichkeiten handelt.

Einsatz von Docker Containern

Die Verwendung von Containern ist inzwischen sehr beliebt, da sie entweder Software bieten, die sofort einsatzbereit ist oder nur einer minimalen Konfiguration bedarf. Containerisierung hilft also bei schnellen Implementierungen und sorgt für eine stabile Umgebung.

Docker ist die bei Entwicklerteams am weitesten verbreitete Container Engine. Sie wird bei der Anwendungserstellung, beim Testen, Packaging sowie bei der Bereitstellung eingesetzt. Doch seit dem Siegeszug dieser Technologie fanden die Sicherheitsforscher viele Container Images auf Docker Hub, die bösartig waren oder für verschiedene Angriffe missbraucht wurden. Allein im Jahr 2020 wurden zahlreiche bösartige Container Images für Kryptowährungs-Mining genutzt. Diese Vorfälle unterstreichen die Empfehlung, nur offizielle Docker Images zu verwenden, um potenzielle Sicherheitsrisiken zu minimieren und Bedrohungen zu verhindern.

Bild 1. Infektionsablauf in einem Docker Image

Exponierte Docker-APIs erleichtern es zudem Angreifern, die Server zu nutzen, um Krypto-Miner zu installieren. Privilegierte Docker Container und exponierte Daemon-Ports könnten ebenfalls zu Angriffsflächen werden.

Kubernetes

Kubernetes ist ein Orchestrierungs-Tool zur für die skalierbare Bereitstellung und Verwaltung von Containern. Kubernetes-Dienste werden von vielen Cloud-Anbietern wie Microsoft Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) und Google Kubernetes Engine (GKE) angeboten. Solche Managed Services tragen dazu bei, das Risiko grösserer Fehlkonfigurationsprobleme zu verringern. Da dies jedoch für einige Umgebungen keine Option darstellt, können beim On-Premise Betrieb von Kubernetes-Clustern Risiken im Zusammenhang mit Fehlkonfigurationen auftreten.

Bild 2. Skizze eines Kubernetes Clusters und dessen Komponenten (Quelle: Kubernetes.io)

Die API spielt eine wichtige Rolle für die Kubernetes-Sicherheit. Kann eine Anwendung, die innerhalb eines Clusters eingesetzt wird, mit dem API-Server interferieren, muss dies als Sicherheitsrisiko betrachtet werden. Daher sollte die API nur den Geräten zur Verfügung gestellt werden, die sie benötigen, eine Massnahme, die durch die Implementierung einer rollenbasierten Zugriffskontrolle und durch die Gewährleistung des Prinzips der geringsten Privilegien erreicht werden kann.

In einem falsch konfigurierten Szenario kann eine einzige anfällige Anwendung als Einstiegspunkt für den gesamten Cluster dienen. Benutzer sollten sicherstellen, dass nur der kube-api-server-Zugriff auf den etcd (ein verteilter Schlüsselwert-Speicher für kritische Daten) hat, da sonst unbeabsichtigte Datenlecks oder unbefugte Änderungen auftreten könnten. Zudem sollte ein Pod (eine grundlegende Bereitstellungseinheit innerhalb eines Kubernetes-Clusters) mit weniger Privilegien betrieben werden, um eine Kompromittierung von Knoten oder des gesamten Clusters zu vermeiden.

Online IDEs

Die Online Cloud-Entwicklungsumgebungen stellen eine interessante Alternative zu den Desktop-Systemen dar.

Cloud IDEs bringen alle Fähigkeiten und Tools zusammen, die ein Softwareentwickler benötigt. Zu den beliebtesten IDEs gehören AWS Cloud9 und Microsofts Visual Studio Codespaces. Visual Studio Codespaces ist eine komplette Anwendung in einer vernetzten Umgebung, während AWS Cloud9 nur Backend Services auf einer verlinkten Maschine bietet, und zusätzlich Frontend Services innerhalb der AWS Cloud.

Die interne Backend-Implementierung variiert je nach Cloud-IDE-Anbieter, aber alle bieten eine Terminal-Schnittstelle zur Umgebung des Benutzers. In den meisten Fällen haben die Benutzer die volle Kontrolle über die Umgebung und sind gleichzeitig für die Gewährleistung einer sicheren Konfiguration verantwortlich. Fehlkonfigurationen können auftreten, wenn Ports für eine erweiterte Nutzung von Anwendungen exponiert werden, sollte der Cloud Provider Timeouts einsetzen, die das verlinkte Gerät bei längerer Inaktivität abschalten.

Im Gegensatz dazu stehen für Visual Studio Codespaces eine Reihe von Erweiterungen zur Verfügung. Diese eignen sich jedoch auch als potenzielle Angriffsfläche. Beispielsweise kann eine in mit einem Backdoor versehene Erweiterung zu einer Systemkompromittierung führen aufgrund fehlender Berechtigungsprüfungen während der Installation oder Nutzung. Um solche Risiken zu mindern, sollten Entwicklungsteams nur vertrauenswürdige Plug-Ins oder Erweiterungen installieren und ihre Umgebungen auf die neueste Version aktualisieren.

Auch sind die Fälle von bösartigen Browser Plug-Ins bekannt, und ihre Funktionalität lässt sich auf Online IDE-Entwicklung erweitern. Ein Proof-of-Concept hat gezeigt, wie ein Angreifer darüber Code stehlen kann. Auch ist bekannt, dass Banking-Trojaner Browser-Funktionen nutzen, um Zugangsdaten von Nutzern zu stehlen. Eine Alternative dazu könnte Code stehlen oder auf Tokens für die IDE zugreifen.

Empfehlungen

Mit zunehmender Komplexität der im Backend verwendeten Software steigt das Risiko von Fehlkonfigurationen. Deshalb sollten Entwicklerteams sich immer dessen bewusst sein, dass es keine sichere Umgebung gibt. Folgende Best Practices können die Backend-Sicherheit verbessern helfen:

  • Umsetzung des Prinzips der Mindestprivilegien: Beschränken der Kontoprivilegien in Cloud-Diensten, vor allem wenn diese an öffentliche Cloud-Anbieter gebunden sind. Darüber hinaus sollten die Berechtigungen und der Zugriff auf Tools limitiert sein, um zu verhindern, dass Angreifer in der Computerumgebung Fuss fassen.
  • Admin-Konten nicht für alltägliche Aufgaben nutzen: Der Admin sollte nur für Continuous Integration and Continuous Deployment (CI/CD)-Tools eingesetzt werden.
  • Checks durchführen auf veraltete oder angreifbare Bibliotheken im Code: Tools wie der OWASP Dependency-Check und Lösungen etwa von Snyk liefern kostenlose Drittanbieter-Überprüfung für quelloffene Projekte.
  • Compliance zu Industriestandards: So können etwa Kubernetes-Anwender die CIS Kubernetes Benchmark vom Center for Internet Security (CIS) checken, um kritische Dateien und Verzeichnisse zu monitoren. Container-Nutzer können das Gleiche mithilfe des Application Container Security Guide vom National Institute of Standards and Technology (NIST) erreichen.

Cloud-Sicherheitslösungen

Cloud-spezifische Sicherheitslösungen wie die Trend Micro™ Hybrid Cloud Security können zum Schutz von Cloud-nativen Systemen und ihren verschiedenen Schichten beitragen. Die Software bietet schlanke, automatisierte Sicherheit für die DevOps Pipeline mit mehreren XGenTM Threat Defense-Techniken. Unterstützt wird sie von Trend Micro Cloud One™ , einer Sicherheitsdienste-Plattform für Cloud-Entwickler. Sie bietet automatisierten Schutz für die CI/CD-Pipeline und Anwendungen. Sie trägt auch dazu bei, Sicherheitsprobleme früher zu erkennen und zu lösen und die Lieferzeit für die DevOps-Teams zu verkürzen. Die Plattform umfasst:

Der vollständige Report „Supply Chain Attacks in the Age of Cloud Computing: Risks, Mitigations, and the Importance of Securing Back Ends“ steht Interessierten zur Verfügung.

Grundlagen der Sicherheit für Kubernetes Cluster

Originalbeitrag von Magno Logan, Trend Micro Research

Obwohl Kubernetes noch nicht sehr lange verfügbar ist, steht die Plattform bereits auf Platz drei bei den bei Entwicklern beliebtesten Produkten. Umso wichtiger ist das Wissen darum, wie die Sicherheit von Kubernetes, und in diesem Fall von Clustern, gewährleistet werden kann. Ein früherer Beitrag beinhaltete bereits einen Überblick über die Sicherheit für die 4 Cs (Cloud, Cluster, Container and Code) in Cloud-nativen Systemen. Jetzt geht es um die Darstellung der Massnahmen für die Sicherheit des Master-Knoten, API-Servers, etcd und für Netzwerk-Policies.

Betreibt ein Unternehmen seine Cluster als Managed Services wie etwa Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (Amazon EKS) oder Google Kubernetes Engine (GKE), so muss der Cloud-Anbieter die Kontrolle über die Sicherheit übernehmen. Dennoch ist ein besseres Verständnis der verfügbaren Sicherheitsoptionen hilfreich, um sicherzustellen, dass der Cloud-Anbieter die empfohlenen Best Practices befolgt. Betreibt eine Organisation ihre eigenen Control Planes, ist das tiefgreifende Wissen zur Sicherheit noch wichtiger.

Das Control Plane

Das Kubernetes Control Plane fungiert als Hauptknoten im Cluster und verwaltet die Worker Nodes. Damit geht es um das Gehirn, das dieses komplexe System in einem guten Zustand und am Laufen hält.

Bild 1. Skizze eines Kubernetes Clusters und dessen Komponenten (Quelle: Kubernetes.io)

Die Abbildung zeigt, dass die Hauptkomponenten für den Cluster im Control Plane sitzen und dass die gesamte Kommunikation über den kube API-Server (kube-apiserver) läuft, der letztendlich ein REST API ist, das alle Management- und Betriebsfunktionen definiert und kontrolliert. Böswillige Akteure bemühen sich um Zugriff auf den kube-apiserver und das Control Plane. Sobald diese kompromittiert sind, können sie den gesamten Cluster kompromittieren, indem sie die Pods (in denen die Container platziert sind) manipulieren, neue aufsetzen, bereits laufende bearbeiten oder sogar ganz entfernen.

Eine der grundlegenden Massnahmen zur Sicherung des Control Plane ist die Integritätsüberwachung der kritischen Kubernetes-Dateien. Auf diese Weise kommt sofort über jede Änderung der Konfiguration eine Benachrichtigung. Aus Sicht der Kubernetes-Sicherheit sind kritische Dateien diejenigen, die den gesamten Cluster beeinträchtigen können, wenn sie kompromittiert werden. Eine Liste der wichtigsten Dateien und Verzeichnisse, die das Team ständig überwachen muss, zusammen mit den empfohlenen Ownership- und Berechtigungsebenen sind in der neuesten CIS Kubernetes Benchmark v1.5.1 detailliert aufgeführt. Bei den meisten dieser Werte handelt es sich um die Standardwerte der Kubernetes-Installation. Eine Tabelle ist im Originalbeitrag aufgeführt.

Der API Server

Den API-Server der Öffentlichkeit zugänglich zu machen, ist ein kritischer Fehler, den immer noch viele machen, und es ist der häufigste Einstiegspunkt für Angreifer, die darüber den Cluster übernehmen können. Viele Angreifer und Bots suchen im Internet ständig nach offen zugänglichen Kubernetes-API-Servern.

Der einfachste Test, um festzustellen, ob der Server im Internet zugänglich ist, besteht darin, den API-Server von einer externen IP aus zu treffen. Hier hilft eine curl-Anfrage oder https://my-control-plane-ip:6443/api. Gibt es eine Antwort auf die Anfrage, so ist das API öffentlich erreichbar. In einem solchen Fall gibt es mehrere Möglichkeiten einen Fix aufzubringen, je nachdem wie der Zugriff auf das API erfolgt. Die beste und sicherste Option ist die folgende:

Entwickler sollten das Cluster API nur über das interne Netzwerk (oder Unternehmens-VPN) erreichen können. Dies lässt sich leicht erreichen, indem die entsprechenden Regeln für die Firewall oder Sicherheitsgruppen (im Fall von AWS) festgelegt werden. Hier muss allerdings darauf geachtet werden, dass in einer Notfallsituation, in der der Cluster-Administrator keinen sofortigen Zugriff auf den Firmen-Laptop oder ein VPN hat, der Zugriff auf den Cluster durch eine sichere Auflistung der IP des Cluster-Administrators gewährleistet ist, vorzugsweise auf den spezifischen API-Port.

Der Zugang auf den Cluster auf GKE lässt sich auch über die Einstellungen des Master Authorized Networks einschränken. Damit entsteht eine weitere Schutzebene für den Fall, dass jemand die Firewall-Regeln manipulieren kann. Der folgende Befehl tut dies:

gcloud container clusters create –enable-master-authorized-networks –master-authorized-networks=CIDR

Des Weiteren kann der Admin prüfen, ob der kube-apiserver die empfohlenen Sicherheitseinstellungen aufweist:

ps -ef | grep kube-apiserver

Weitere Informationen dazu umfasst der Originalbeitrag.

RBAC-Autorisierung

Mit RBAC lässt sich festlegen, wer worauf in dem Cluster zugreifen kann. Die Aktivierung der Autorisierung für RBAC im Cluster wird dringend empfohlen, insbesondere für die Produktion. Zudem kann allen Benutzern der Zugriff auf den Kube-System-Namensraum untersagt werden, wo sich alle Pods des Control Planes befinden.

Das RBAC-Autorisierungsmodul ist in den neuesten Versionen standardmässig aktiviert. Es müssen lediglich die geeigneten Rollen festgelegt und diese bestimmten Nutzern zugewiesen werden. Doch können böswillige Nutzer RBAC deaktivieren. Dies lässt sich mit demselben Befehl überprüfen, der für den Check der Kube API Serverkonfigurationen genutzt wird:

ps -ef | grep kube-apiserver

Beim Einsatz der RBAC-Autorisierung lassen sich vier Arten von API-Objekten nutzen:

  • Role: enthält Regeln, die einen Berechtigungssatz innerhalb eines Namensraums repräsentieren.
  • RoleBinding: vergibt Berechtigungen einer Role an einen oder mehrere Nutzer.
  • ClusterRole: enthält Regeln, die einen Berechtigungssatz auf Cluster-Ebene repräsentieren.
  • ClusterRoleBinding: vergibt Berechtigungen für Nutzer auf ClusterRole-Ebene.

Bild 2. Bezug der Nutzer zu Roles über RoleBindings beziehungsweise von ClusterRoles zu ClusterRoleBindings

Weitere technische Einzelheiten beinhaltet der Originalbeitrag sowie die offizielle Dokumentation.

etcd

etcd ist der Hauptspeicherort für Daten im Cluster. Alle Clusterobjekte werden hier vorgehalten. Er ist hierarchisch aufgebaut und standardisiert, daher nutzen Kubernetes-Installationen etcd für das Speichern von REST API Objekten sowie für Installationskonfigurationen. Wird etcd exponiert, so könnten kritische Daten verloren gehen. Leider kommen Fehlkonfigurationen häufig vor, wie 2.600 exponierte etcd-Services auf Shodan in diesem Jahr zeigen.

Wie bei jedem Datenspeichersystem sollten die gleichen Sicherheitsprinzipien auf etcd angewandt werden. Sowohl die Verschlüsselung im Transit als auch At-Rest sollte vorhanden sein. Derzeitige Kubernetes Standardinstallationen beinhalten bereits die geeigneten Schlüssel und Zertifikate sowie TLS-Verschlüsselung (siehe CIS Kubernetes Benchmark).

Gelingt es einem Angreifer auf irgendeine Weise, den API-Server zu umgehen und Objekte direkt in etcd zu manipulieren, so wäre es, als hätte er vollen Zugriff auf den gesamten Cluster. Er könnte Pods erstellen, Geheimnisse lesen und sensible Daten wie Anmeldeinformationen einsehen. Um dies zu verhindern, müsste nicht nur die Verschlüsselung während der Übertragung aktiviert sein, sondern auch die Verschlüsselung im Ruhezustand (At-Rest).

Das Netzwerk

Standardmässig können alle Pods in einem Cluster mit jedem anderen Pod auf demselben Cluster kommunizieren, einschliesslich Pods aus verschiedenen Namensräumen, und dies schliesst den Hauptnamensraum des Kube-Systems ein, in dem das Control Plane untergebracht ist. So legt es die Netzwerk-Policy fest, die bei der Kubernetes-Installation konfiguriert wird.

Eine Netzwerk-Policy definiert, wie Gruppen von Pods miteinander und mit anderen Netzwerkendpunkten kommunizieren. NetworkPolicy-API-Ressourcen verwenden Labels, um Pods auszuwählen und Regeln zu definieren, die angeben, welche Art von Datenverkehr für die ausgewählten Pods zulässig ist. Diese Richtlinien können helfen, den Zugriff zwischen Pods oder Namespaces einzuschränken. Der gesamte Zugriff kann über Labels in YAML-Dateien konfiguriert werden, so dass z.B. der Zugriff von Pods auf andere Pods im Namensraum des kube-Systems blockiert werden kann.

Hinweis: Es bedarf einer Netzwerklösung oder eines Container Network Interface (CNI), das das NetworkPolicy-Objekt unterstützt. Andernfalls hat dies keine Auswirkungen auf den Cluster.

Für alle aufgeführten Punkte gibt der Originalbeitrag weitere technische Informationen, und auch eine Kubernetes Security Liste auf GitHub bietet Blogs, Artikel, Tools und Videos zum Thema. In einem weiteren Beitrag werden sich die Autoren mit dem Schutz von Worker Nodes, Kubelet sowie den Pods befassen.

Sicherheit für die 4 Cs von Cloud-nativen Systemen: Cloud, Cluster, Container und Code, Teil 2

Originalbeitrag von Magno Logan, Threat Researcher

Cloud-native Softwareentwicklung baut auf quelloffene und proprietäre Software, um Anwendungen wie Microservices bereitzustellen, die in einzelnen Containern in isoliert ausführbare Prozesse verpackt sind. Da Unternehmen mehrere Container auf mehreren Hosts laufen lassen, setzen sie Orchestrierungssysteme wie etwa Kurbernetes ein, die über CI/CD-Tools mit DevOps-Methodologien bereitgestellt und verwaltet werden. Wie bei jeder Technologie, die unterschiedliche, miteinander verbundene Tools und Plattformen nutzt, spielt auch beim Cloud-nativen Computing Sicherheit eine entscheidende Rolle. Cloud-native Sicherheit unterteilt die Strategie in vier unterschiedliche Schichten. Nach der Darstellung der Sicherheitsproblematik für die Cloud an sich und für die Cluster (Teil 1) stellt dieser 2. Teil die Sicherheit für Container und Code in den Vordergrund.

Kubernetes nennt dies „The 4Cs of Cloud-native Security“.

Bild 1. Die 4 Cs der Cloud-nativen Sicherheit

Wichtig ist, Sicherheitskontrollen in jeder Schicht anzuwenden, denn jeder Layer liefert eine eigene Angriffsoberfläche und wird nicht zwangsläufig durch andere Layer geschützt. So wird etwa eine unsichere Webanwendung bei einem Angriff über SQL Injection nicht durch äussere Schichten (siehe Bild 1) dagegen geschützt, wenn keine spezielle Sicherheitssoftware vorhanden ist. Sicherheitsverantwortliche müssen jedes mögliche Szenario mit einbeziehen und Systeme auf jede Art schützen. Weitere detaillierte Empfehlungen für die sichere Container-Orchestrierung bietet der Blogeintrag zur Sicherheit von Kubernetes Container-Orchestrierung.

Container-Sicherheit

Für den Betrieb von Containern im Cluster bedarf es der Container Runtime Engines (CREs). Eine der bekanntesten ist Docker, doch Kubernetes unterstützt auch andere wie containerd oder CRI-O. In puncto Sicherheit müssen Unternehmen für diese Schicht drei wichtige Fragen klären:

  • Wie sicher sind die Images? Hier müssen Verantwortliche sicherstellen, dass die Container auf aktuellem Stand und frei von Schwachstellen, die missbraucht werden könnten, sind. Nicht nur das Basis-Image muss abgesichert sein, sondern auch die in den Containern laufenden Anwendungen müssen gescannt und verifiziert sein. Dafür gibt es einige quelloffene Tools, doch nicht alle können Schwachstellen ausserhalb der Betriebssystempakete erkennen. Dafür sollten Anwender auf Lösungen setzen, die auch Anwendungen abdecken, so etwa Deep Security™ Smart Check.
  • Sind die Container vertrauenswürdig? Wurden die Container, die im System laufen, aus den Images in der eigenen Registry erstellt? Wie lässt sich dies gewährleisten? Antworten bieten Image-Signiertools wie TUF oder Notary, mit denen die Images signiert werden können und somit ein vertrauenswürdiges System für die Inhalte der Container erstellt werden kann.
  • Laufen sie mit den geeigneten Privilegien? Hier greift das Prinzip der geringsten Privilegien. Es sollten lediglich Container laufen, wo die Nutzer nur die für ihre Aufgaben erforderlichen Betriebssystemprivilegien haben.

Ein umfassender Leitfaden zu einem höheren Schutz für Container zeigt auch die möglichen Gefahren in jeder Phase der Entwicklungs-Pipeline.

Code-Sicherheit

Hierbei geht es um Anwendungssicherheit. Es ist die Schicht, über die Unternehmen die beste Kontrolle haben. Der Code der Anwendungen stellt zusammen mit den zugehörigen Datenbanken das Kernstück der Systeme dar. Sie sind üblicherweise im Internet zugänglich und werden daher von Angreifern ins Visier genommen, wenn alle anderen Komponenten gut gesichert sind.

Deshalb müssen Unternehmen in erster Linie sicherstellen, dass jegliche Kommunikation TLS-verschlüsselt abläuft, auch wenn es sich um interne Services handelt, wie Load Balancer, Anwendungsserver und Datenbanken. Im Fall eines Orchestrierungstools wie Kubernetes lassen sich dafür Services wie Istio oder Linkerd heranziehen.

Die Angriffsfläche der Systeme kann erheblich verkleinert werden, wenn exponierte Dienste, Ports und API-Endpunkte reduziert und überwacht werden. Hier sollten auch Container Basis-Images und Systeme, auf denen die Cluster laufen, bedacht werden.

Es lassen sich verschiedene Code-Sicherheitsüberprüfungen zur Pipeline hinzufügen, um zu gewährleisten, dass der Code gesichert ist. Hier sind einige davon:

  • Statische Sicherheitsanalyse von Anwendungen. Man spricht auch von „Sicherheitsüberprüfung des Codes“ oder von „Code Auditing“. Die Methode gilt als einer der besten und schnellsten Wege, um Sicherheitsprobleme im Code zu entdecken. Unabhängig von der verwendeten Sprache sollte mindestens ein statisches Analysetool in die Pipeline integriert sein, das bei jedem Commit von neuem Code auf unsichere Kodierungspraktiken prüft. Die Open Web Application Security Project (OWASP) Foundation erstellt eine Liste mit quelloffenen und auch kommerziellen Tools für die Analyse von Quellcode und/oder kompiliertem Code.
  • Dynamische Sicherheitsanalyse von Anwendungen. Obwohl eine dynamische Analyse nur dann durchgeführt werden kann, wenn es eine laufende Anwendung gibt, gegen die getestet wird, ist es ratsam, automatisierte Scans und Checks durchzuführen, um bekannte Angriffe wie SQL Injection, Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF) aufzuspüren. Diese Tools testen auch die Widerstandsfähigkeit der Anwendung, Container und Cluster, wenn auf diese eine Reihe unerwarteter Belastungen und fehlerhafter Anfragen zukommt. OWASP hat ein dynamisches Analysetool, OWASP Zed Attack Proxy (ZAP), das Unternehmen automatisiert und in die eigene Pipeline einfügen können.
  • Analyse der Software-Komposition. 70% bis 90% aller Cloud-nativen Anwendungen umfassen Abhängigkeiten von Bibliotheken und Drittanbietern. Es geht um Codeteile, die wahrscheinlich von jemand ausserhalb des Unternehmens verfasst wurden, und die in den unternehmenseigenen Produktionssystemen laufen. Diese Codes werden im Allgemeinen während der statischen Analyse nicht überprüft. Dafür können Tools wie der OWASP Abhängigkeitscheck genutzt werden, um nach veralteten oder angreifbaren Bibliotheken im Code zu suchen. Snyk wiederum bietet kostenlos Drittanbieterüberprüfung für quelloffene Projekte.

Fazit

Die vier Schichten von Cloud-nativen Systemen sind für die Sicherheit von Anwendungen von entscheidender Bedeutung – und wenn auch nur eine von ihnen Angreifern ausgesetzt ist, kann das gesamte System kompromittiert werden.

Cloud-Sicherheitslösungen von Trend Micro

Cloud-spezifische Sicherheitslösungen wie die Trend Micro™ Hybrid Cloud Security können zum Schutz von Cloud-nativen Systemen und ihren verschiedenen Schichten beitragen. Unterstützt wird sie von Trend Micro Cloud One™ , einer Sicherheitsdienste-Plattform für Cloud-Entwickler. Sie bietet automatisierten Schutz für die CI/CD-Pipeline und Anwendungen. Sie trägt auch dazu bei, Sicherheitsprobleme früher zu erkennen und zu lösen und die Lieferzeit für die DevOps-Teams zu verkürzen. Die Plattform umfasst: