Sicherheit sollte bei Microservices kein Fremdwort sein. Erfahren Sie mehr über die Herausforderungen der Microservices-Sicherheit und wie starkes Netzwerk-Management helfen kann.
Jede gute Sache scheint ein Problem oder Risiko in sich zu bergen. Bei der Entwicklung und Implementierung von Software sind die Risiken oft mit Sicherheit und Governance verbunden. Microservices bieten nur dann Vorteile, wenn die Verbindungen offen sind, um den Zugriff und die Kombination der Services zu unterstützen. Es besteht jedoch die Gefahr, dass ein derartiges Modell jede Vorstellung von Sicherheit oder Governance unterläuft, da die explizite Zugriffskontrolle für Microservices kompliziert ist. Können richtige Aktionen und Praktiken im Netzwerk dazu beitragen, Microservices abzusichern und dennoch ihre Flexibilität zu erhalten? Sicherheit sollte jedenfalls bei Microservices kein Fremdwort sein.
Herausforderung bei der Sicherheit von Microservices
Traditionelle Sicherheit und Governance basieren auf einer nachgewiesenen und verifizierten Identität. Anwendungen stellen an ihre Benutzer abhängig von deren Rolle bestimmte Anforderungen, damit sie darauf zugreifen können. Die Herausforderung von Microservices: Ein aus vielen Anwendungen zusammengesetzter Service kann viele unterschiedliche Zugriffsanforderungen stellen. Sie können sogar als zufällige Brücke zwischen Anwendungen dienen, deren Anforderungen sich unterscheiden.
Angenommen, ein Mitarbeiter möchte auf die Lohntabellen des Unternehmens zugreifen. Wenn er in dieser Abteilung arbeitet und über die entsprechende Berechtigung verfügt, wird ihm der Zugriff gewährt, wenn er beispielsweise seine Benutzerkennung und sein Kennwort eingibt. Wenn aber die Anwendung für die Gehaltsabrechnung in ein Dutzend Mikroservices unterteilt ist, könnte ein Benutzer möglicherweise auf einen Mikroservice der Gehaltsabrechnung zugreifen und dann Zugriff auf vertrauliche Informationen erhalten. Zwar kann jeder Microservice über eine Zugangskontrolle geschützt werden; es ist allerdings nicht ideal, wenn Benutzer für jeden Microservice erneut ihre IDs und Kennwörter eingeben müssen. Hier kann das Netzwerk beim Sichern der Microservices helfen, ohne die Kette der freien Zusammenstellung zu durchbrechen.
Das explizite Modell der Vernetzung
Es ist üblich, Anwendungen innerhalb eines privaten Subnetzes bereitzustellen und nur die externen Komponenten oder APIs freizugeben. Dies ist das explizite Modell der Container-Vernetzung; und dieses Modell hat sich mit der verstärkten Nutzung von Containern noch weiter verbreitet. Das Modell ist aus Sicht der Sicherheit von Mikroservices hilfreich, da es Schnittstellen verbirgt, die niemals außerhalb der Anwendung verwendet werden sollten. Weitere Schutzmaßnahmen können dann sogar unnötig sein.
Dieses Modell bricht zusammen, wenn Anwendungen aus Komponenten erstellt werden, um sie in mehreren Anwendungen zu nutzen. Denn werden diese wiederverwendbaren Komponenten innerhalb eines privaten Subnetzes isoliert, kann man sie nicht mehr nutzen. Das Problem ist, dass wiederverwendbare Komponenten nicht wirklich Teil einer einzelnen Anwendung sind; sie sind Teil eines Pools von Funktionen.
Es wäre sinnvoll, alle geteilten Microservices unabhängig voneinander einzusetzen, das heißt sie alle dem gleichen IP-Subnetz zuzuordnen. Dann erhalten sie entweder eine öffentliche IP-Adresse, damit Anwendungen sie nutzen können, oder sie lassen ihre privaten Adressen übersetzen, typischerweise in den Adressraum des Virtual Private Network (VPN) des Unternehmens. Dies macht sie jedoch für jedermann zugänglich, es sei denn, wir schützen sie zusätzlich.
API-Broker-Sicherheit versus netzwerkbasierte Sicherheit
Ein bewährter Weg, um zu gewährleisten, dass Microservices zugänglich und gleichzeitig sicher sind, ist die Absicherung durch einen API-Manager oder -Broker. Es gibt eine Reihe von Strategien zur Absicherung von Microservices durch einen API-Broker. Allerdings erzeugen sie jedes Mal, wenn ein Anruf an die Microservices vermittelt wird, einen Overhead. API-Broker können auch die Komplexität bei der Kombination von Microservices zu Anwendungen erhöhen. Daher sollten die IT-Teams die API-basierte Sicherheit testen und die Konsequenzen abschätzen, bevor sie sich dafür entscheiden. Es ist auch möglich, die Load-Balancing- und Discovery-Tools zu nutzen, die mit dem Zugriff auf Microservices verbunden sind, um die Sicherheit zu erhöhen. Schließlich arbeiten diese Tools mit nahezu denselben Mechanismen und lösen ähnliche Probleme.
Ein zweiter Ansatz ist netzwerkbasierte Sicherheit. Die Anwendungen, die berechtigt sind, Microservices zu nutzen, werden mit ziemlicher Sicherheit in bestimmten IP-Subnetzen ausgeführt. Und die Adressen, die von diesen Anwendungen aus Anfragen an Microservices stellen, könnten kontrolliert und bekannt sein. Wenn Unternehmen im Firmen-VPN Traffic-Routing-Regeln festlegen, um den Zugriff auf Microservices auf den spezifischen Bereich der autorisierten Anwendungsadressen zu beschränken, kann anderer Traffic die Microservices nicht erreichen.
Es ist unwahrscheinlich, dass Aktionen im Netzwerk-Management alleine den Nutzen und die Risiken von Microservices ausgleichen können. Das heißt aber nicht, dass Networking nicht helfen kann.
Jede dieser Sicherheitsstrategien könnte die Fähigkeit einschränken, Microservices dynamisch in Anwendungen zu komponieren, da Firmen ihr Sicherheits-Gateway öffnen müssten, um die Dienste zu verbinden. Prozesse des Sicherheits-Gateways können es außerdem erschweren, Änderungen über das Application Lifecycle Management (ALM) umzusetzen; denn was auch immer Firmen in der Produktion verwenden möchten, sie müssen es testen. Andernfalls bilden diese Tests keinen verlässlichen Maßstab für das Produktionsverhalten.
Sicherheit von Microservices und Load Balancing
Außerdem müssen Firmen die Auswirkungen von sicheren Microservices auf die Skalierung und Neuverteilung untersuchen, falls Fehler eintreten. Wenn ein Microservice skaliert, müssen die Lasten der zusätzlichen Instanzen verteilt werden, das heißt der Load Balancer muss für Client-Komponenten zugänglich sein, und die Microservice-Instanzen müssen beim Load Balancer registriert sein. Das alles vereinfacht sich, wenn die Client-Komponenten immer mit einer Load-Balancing-Funktion verbunden sind, da der Load Balancer dann praktisch einen virtuellen Microservice mit konstanter Adresse darstellt. Das Load Balancing sorgt auch für eine ausreichende Arbeitsteilung, so dass sich die Arbeit einfacher verwalten lässt und Serviceausfälle begrenzt werden.
Firmen können API-Broker und Load Balancing miteinander kombinieren. In diesem Fall sollten sie bevorzugt alle API-Broker und Microservices in einem gemeinsamen Subnetz platzieren, solange der Broker der aufrufenden Anwendung einen Sicherheitstoken zur Verfügung stellt. Wenn der API-Broker tatsächlich den Microservice selbst anruft, ist es sinnvoll, die Microservices in ein eigenes Subnetz zu stellen. Dann darf nur der Datenverkehr, der vom API-Broker ausgeht, auf die Microservices zugreifen.
Sicherheit hängt vom Netzwerk ab
Es ist unwahrscheinlich, dass Aktionen im Netzwerk-Management alleine den Nutzen und die Risiken von Microservices ausgleichen können. Das heißt aber nicht, dass Networking nicht helfen kann. Denn die Sicherheit von Microservices sollte immer eine netzwerkbasierte Komponente enthalten. Wenn Firmen die Vorteile von Microservices voll ausschöpfen wollen, ist es wichtig, diese Tatsache zu akzeptieren und die Sicherheit von Microservices außerhalb des Netzwerks zu optimieren.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
