Wenn Sie heute Entwickler sind, dann lieben Sie es sicher Microservices zu verwenden. Mit Microservice-Architekturen entwickeln Sie leistungsstarke Anwendungen agil und ausfallsicher.
Aber eine Microservices-Strategie zahlt sich nur aus, wenn Sie die Risiken, die mit Microservices einhergehen, effektiv managen. In gewisser Weise sind Microservices aus Sicherheitssicht grundsätzlich anspruchsvoller als weniger komplexe monolithische Architekturen. Denn wenn Sie die Sicherheitsrisiken von Microservices nicht managen, dann könnte die Anwendung manipuliert werden und Sie könnten die Kontrolle darüber verlieren – das ist ein Problem, dass mit Agilität nicht zu lösen ist.
Aus diesem Grund ist es wichtig, die Sicherheitsrisiken, die mit Microservices einhergehen, zu identifizieren und anzupacken. Hier ist eine Liste der fünf häufigsten Sicherheitsprobleme, die Entwickler beim Schreiben von Microservice-basierten Apps berücksichtigen sollten, zusammen mit Tipps zu deren Behebung.
Wenn Sie jemals eine Microservices-App geschrieben oder verwaltet haben, wissen Sie, dass Microservices-Architekturen die Komplexität auf eine ganz neue Ebene bringen.
Sie machen das Schreiben von Anwendungen komplexer, weil Entwickler sicherstellen müssen, dass jeder Microservice andere Microservices effizient und zuverlässig finden und mit ihnen kommunizieren kann. Und sie erschweren die Verwaltung, da Administratoren mit Service Discovery, verteilten Protokolldaten, ständig hoch- und herunterfahrenden Instanzen usw. zu kämpfen haben.
Beide Herausforderungen führen zu Sicherheitsrisiken. Es ist schwieriger Schwachstellen zu erkennen, weil es schwierig ist alles zu verfolgen, was in einer Umgebung passiert. Um die Komplexität zu überwinden, benötigen Entwickler und Sicherheitsteams stärkere Tools für die Verwaltung von Quellcode und die Überwachung von Laufzeitumgebungen, als sie es beim Umgang mit monolithischen Apps benötigen würden.
Wenn Sie beispielsweise serverlose Funktionen zum Hosten von Microservices verwenden, haben Sie wenig bis gar keinen Zugriff auf das Hostsystem. Sie erhalten nur die Überwachung, Zugriffskontrolle und andere Tools, die Ihnen die serverlose Funktionsplattform bietet.
Aus Sicherheitssicht macht dies die Angelegenheit erheblich schwieriger, da Sie sich nicht auf Tools auf Betriebssystemebene verlassen können, um Ihre Microservices zu härten, sie voneinander zu isolieren oder Daten zu sammeln, die Sicherheitsprobleme aufdecken könnten. Sie müssen alle Risiken innerhalb des Microservice selbst handhaben. Das ist durchaus machbar, erfordert aber auch hier mehr Koordination und Aufwand, als es Entwickler monolithischer Apps gewohnt sind.
Microservices werden unter anderem deshalb geliebt, weil sie sich so einfach skalieren lassen und weil neue Instanzen in Sekundenschnelle gestartet werden können.
Das ist großartig, wenn Sie Ihre Microservices tatsächlich skalieren möchten. Was aber, wenn jemand mit böswilliger Absicht in Ihre Umgebung gelangt und Ihre Microservices massiv so hochskaliert, dass sie enorme Mengen an Cloud-Ressourcen verbrauchen?
Sie werden Opfer eines sogenannten Denial-of-Wallet-Angriffs, bei dem es sich um einen Angriff handelt, der darauf abzielt, das Geld der Opfer auszugeben und dabei den Dienst nicht wirklich zu stören.
Bisher bleiben Denial-of-Wallet-Angriffe rein theoretisch. Bisher wurde noch kein solcher Angriff gemeldet. Dies ist jedoch ein echtes Risiko, insbesondere für Unternehmen mit schlecht gesicherten Cloud-Computing-Konten.
In einer monolithischen Anwendung werden Daten normalerweise auf einfache und unkomplizierte Weise gespeichert. Sie befinden sich wahrscheinlich im lokalen Dateisystem des Servers, der die Daten hostet oder möglicherweise in einem mit dem Netzwerk verbundenen Speicher, der dem lokalen Speicher des Servers zugeordnet ist. Diese Daten sind einfach zu verschlüsseln und mit Zugriffskontrollen zu sperren.
Microservices verwenden normalerweise eine völlig andere Speicherarchitektur. Da Microservices normalerweise über einen Servercluster verteilt sind, können Sie sich nicht auf lokale Speicher und Zugriffskontrollen auf Betriebssystemebene verlassen. Stattdessen verwenden Sie meistens ein Scale-out-Speichersystem, das Daten von den zugrunde liegenden Speichermedien abstrahiert.
Diese Speichersysteme können in der Regel mit Zugangskontrollen gesperrt werden. Aber die Zugriffskontrollen sind oft komplexer als der Umgang mit Berechtigungen auf Dateisystemebene, was bedeutet, dass es für Entwickler einfacher ist, Fehler zu machen, die zu Sicherheitsverletzungen führen.
Darüber hinaus ist es komplex sicherzustellen, dass jeder Microservice über die erforderliche Zugriffsebene auf den Speicher verfügt. Das kann dazu führen, dass einige Entwickler keine granularen Speicherrichtlinien konfigurieren und damit allen Microservices den Zugriff auf alle Daten ermöglichen.
In jedem Fall erhalten Sie einen Speicher, der nicht so sicher ist wie der einer herkömmlichen, monolithischen App.
Die Antwort darauf ist, es muss sichergestellt werden, dass die granulare Zugriffskontrolle innerhalb der Speichersysteme voll ausgeschöpft und gleichzeitig Zugriffskonfigurationen auf potentielle Fehlerkonfigurationen gescannt werden.
Die Sicherung des Netzwerks ist für jede Art von Anwendung, die mit dem Netzwerk verbunden ist, von entscheidender Bedeutung – das heißt heute praktisch für jede Anwendung.
Durch die Verwendung von Microservices erreicht die Netzwerksicherheit eine ganz neue Komplexitätsstufe. Das liegt daran, dass Microservices nicht nur mit Endbenutzern oder Ressourcen von Drittanbietern über das Internet kommunizieren, wie es ein Monolith tun würde. Sie nutzen normalerweise auch ein komplexes Netz von Overlay-Netzwerken, um Informationen untereinander auszutauschen.
Mehr Netzwerke bedeuten mehr Möglichkeiten für Angreifer Schwachstellen zu finden und auszunutzen. Sie können beispielsweise sensible Daten abfangen, die Microservices miteinander austauschen, oder interne Netzwerke nutzen, um Sicherheitsverletzungen von einem Microservice auf andere zu eskalieren.
Alle diese Risiken können bewältigt werden. Zu sagen, dass Entwickler Microservices meiden sollten, weil sie zu komplex und anspruchsvoll sind, wäre so, als ob wir in das Zeitalter der Pferdekutschen zurückkehren sollten, weil Autos zu schmutzig und gefährlich sind.
Das bedeutet jedoch nicht, dass es nicht wichtig ist, die Risiken von Microservices zu managen. So wie kein verantwortungsbewusster Fahrer ein Auto fahren würde, ohne die angemessene Vorsichtsmaßnahme zu treffen, z.B. sich zuerst anzuschnallen, sollte kein Entwickler Microservices einsetzen, ohne Schritte zu unternehmen, um ihre inhärenten Risiken zu bewältigen.
