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 äußere 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 außerhalb 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 außerhalb 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:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.