Security beim Edge Computing – Teil 1
Albtraum oder kalter Kaffee
Fortsetzung des Artikels von Teil 1
Endpoint Edge Computing
Eine weitere Art des Edge Computings findet noch weiter weg von der Cloud statt – genauer gesagt auf den Geräten/Endpoints selbst. Der Endpoint kann etwa als (IoT-)Gateway für andere Geräte mit entsprechender Sensorik/Aktorik fungieren.
Aber auch Endpoints, die sowohl die Anbindung an das Netz, die Auswertung von Daten und die Anbindung von Aktorik und Sensorik vereinen, fallen unter diese Kategorie.
Was in diesem Kontext auffällt, ist, dass man grundsätzlich über die Entwicklung von Embedded-Geräten spricht. Nur wenige Edge-Computing-Geräte landen als COTS-Produkt (Common of the Shelf) im freien Markt. Viele dieser Geräte sind für spezielle Anwendungszwecke entwickelt und in (relativ) kleinen Stückzahlen ausgerollt. Daher ist es auch wichtig zu verstehen, aus welchen Komponenten ein entsprechendes Device besteht.
Da eines der Kriterien von Edge Computing auch die Verarbeitung von Daten fernab zentraler Rechenzentren ist, stellen sich zwangsläufig Fragen nach der Ablaufumgebung, APIs und der Hardwareplattform. Darüber hinaus wollen diese Geräte natürlich auch verwaltet sein, was einen ganzen Rattenschwanz an Diensten im Bereich Identity- und Access-Management, Messaging, FOTA und vieles mehr nach sich zieht. Ein Beispiel für ein Edge-Computing-„All-in-One“-Paket ist Amazons Greengrass. Es besteht aus einer ganzen Reihe von Services, die viele der immer wiederkehrenden Anforderungen von Edge Devices abdecken. Auf dem Gerät selbst stellt Greengrass zum Beispiel eine standardisierte Ablaufumgebung für kundenspezifische Logik zur Verfügung. Dies kann in Form nativer Applikationen, Docker-Containern oder auch Lambda-Funktionen erfolgen.
Zusätzlich bietet die Greengrasss-Core-Software lokal auf dem Device verschiedenste nützliche Dienste. Angefangen über Funktionen zur Verwaltung von Datenströmen, Publish/Subscribe-Mechanismen, sicherer Device Lifecycle (Identität, PKI), Firmware-Updates Over-the-Air (FOTA) bis hin zu lokalen Machine-Learning-Schnittstellen finden sich viele Funktionen, die in der einen oder anderen Art häufig dienlich sind.Entwickler sind also nicht gezwungen, diese Funktionen jedes Mail von Grund auf neu zu implementieren. Hinzu kommt, dass viele dieser Funktionen die gleichen Schnittstellen benutzen, die auch für Cloud-Instanzen bereit stehen. Das Entwicklungsteam ist also nicht gezwungen, sich bei der Programmierung oder dem Design der Abläufe noch zusätzlich Gedanken über unbekannte APIs zu machen zu. Dies hat außerdem den Vorteil, dass bei Bedarf ressourcenintensive Aufgaben transparent in die Cloud wandern können, ohne dass sich das Programmier- oder Ablaufmodell ändert.
Im Gegensatz zur klassischen Embedded-Programmierung, bei der man sich um viele dieser Aspekte immer wieder eigene und neue Gedanken machen muss, ist dies sicher ein massiver Fortschritt. Auch „Paketierung“ eigener Funktionen als Lambda-Funktion, Docker-Container etc. entspricht deutlich eher der heutigen Art und Weise, Software und Dienste zu entwickeln. Ein Großteil der (notwendigen) Basisfunktionen wird einfach von Greengrass basierend auf Best Practices übernommen.
Ein möglicher Nachteil ist die Bindung an das Amazon-Ökosystem. Ähnliche Angebote sind jedoch auch bei anderen Anbietern erhältlich. Letztendlich besteht natürlich auch die Möglichkeit, diese Infrastruktur (etwa mit Open Source) selbst aufzubauen. Ob sich dies im Einzelfall aus Sicherheits- und Wirtschaftlichkeitssicht lohnt, hängt natürlich vom Gerät ab. Nicht verschwiegen werden soll aber auch die Hardwareseite des Edge Computings bei den Geräten. Hardware-Referenzplattformen wie Nvidias Jetson kombinieren heute eine Rechen-Power auf kleinem Raum, die vor einigen Jahren nur großen Clustern vorbehalten war. Insbesondere die Hardwareunterstützung von Machine Learning in Hardware erlaubt es heute am Edge, Dienste in einer Komplexität und Geschwindigkeit anzubieten, die einige Use Cases überhaupt erst denkbar machen. Während man Rechen-Power schon lange „beliebig“ in der Cloud nutzen konnte, war dies in der Regel stets mit einer Latenz verbunden.
Bei CV-Anwendungen (Computing Vision) am Edge kommt es zum Beispiel eben nicht nur darauf an, dass ein ML-Model die Inhalte in einem Bild erkennt. Dazu würde es nämlich reichen, die Bilder aufzunehmen, in die Cloud zu schicken, dort zu verarbeiten und das Ergebnis zurückzuschicken. Vielmehr spielt die Dauer der Verarbeitung oft eine wichtige Rolle – und dabei können die 100 ms Roundtrip-Zeit zur Cloud-Instanz schon zu viel sein. Dies gilt ebenfalls für die Gefahr einer Netzwerkunterbrechung oder bei Geräten mit geringer Bandbreite (etwa über GSM).
Udo Schneider ist Security Evangelist bei Trend Micro.
- Albtraum oder kalter Kaffee
- Endpoint Edge Computing
Lesen Sie mehr zum Thema
