Security beim Edge Computing – Teil 1

Albtraum oder kalter Kaffee

17. August 2021, 7:00 Uhr | Udo Schneider/jos

Edge Computing ist einer der Begriffe, die aktuell beim Marketing-Buzzword-Bingo hoch im Kurs stehen. Aber was ist Edge Computing überhaupt? Und welche Rolle kann und muss Security dort spielen? Ein genauer Blick lohnt sich in jedem Fall.

Als Erstes die schlechte Nachricht. Das eine „wahre“ Edge Computing gibt es nicht. Unter dem Begriff tummeln sich verschiedene Techniken, Plattformen und Infrastrukturen. Vereinfacht gesagt kann „Edge“ alles nach der „Cloud“ in Richtung Device sein, wobei selbst dann die Trennschärfe nicht zu 100 Prozent gegeben ist, also ähnlich wie beim Thema Cloud: Dort haben sich im Lauf der Jahre zwar einige Begriffe wie SaaS, PaaS und IaaS etabliert – auch dort kommen jedoch täglich neue „aaS“-Varianten hinzu.

Daher empfiehlt es sich, beim Edge Computing genauer nachzufragen, welche Art denn genau gemeint ist. Es lohnt sich, insbesondere auf drei Spielarten von Edge Computing und deren Auswirkungen auf die Security zu fokussieren.

Network Edge Computing: CDN

Content Delivery Networks (Akamai, Cloudflare, Amazon CloudFront, Google Cloud CDN, Microsoft Azure CDN) gibt es in der einen oder anderen Form seit mehr als zwanzig Jahren. Allen gemein ist die ursprüngliche Idee, Inhalte näher an den Verbraucher (oder dessen Browser) zu bringen. Anstatt zum Beispiel einen europäischen Benutzer dazu zu zwingen, die langsame Überseeleitung zum Rechenzentrum in den USA zu nutzen, sind Inhalte in regionalen Servern vorgehalten, meist direkt bei großen Providern oder Peering Points. Verschiedene Techniken wie (Global) Load Balancing oder IP und DNS Multicast sorgen dann dafür, dass die Benutzer automatisch die ihnen nächste Server-Farm verwenden. Dies funktioniert am einfachsten mit statischen Inhalten, die sich von der Quelle spiegeln lassen. Moderne CDNs beherrschen jedoch neben der Beschleunigung von dynamischen Inhalten vieles andere mehr, etwa Video-(Live-)Streams zu verteilen. Man kann heute davon ausgehen, dass die überwiegende Mehrheit der großen Web-
sites über CDNs ausgeliefert wird.

Dank der einfachen Konfiguration und Nutzung von CDNs im Rahmen von Stand-alone- oder Cloud-Angeboten werden aber inzwischen immer mehr kleinere Websites über CDNs ausgeliefert. Neben der Schnelligkeit stehen dort oft Argumente wie Verfügbarkeit (das CDN liefert gecachte Inhalte selbst dann aus, wenn der Origin-Server Probleme macht) oder Verschlüsselung im Vordergrund (der Origin-Server läuft „versteckt“ mit HTTP, die Edge-Server des CDN liefern den gleichen Inhalt transparent/gecacht via HTTPS aus).

Die CDN-Anbieter betreiben also bereits eine komplexe und verteilte Infrastruktur von Servern, die „nicht in der Cloud“ und „näher am Client“ sind. Sie sorgen dafür, dass Clients automatisch zu denen ihnen netzwerktechnisch „nächsten“ Servern gelangen, die dann ihre gecachten Inhalt ausliefern, was Antwortzeiten minimiert. Der Schritt, anstelle gecachter Daten dann auf den Edge-Servern direkt Code auszuführen, ist dann nur noch ein ganz kleiner. Wie beim Serverless Computing in der Cloud (die Grenzen sind fließend) laufen bei dieser Form des Edge Computings Funktionen auf den Servern. Die Ähnlichkeit geht sogar soweit, dass etwa Amazon seinen Amazon-Lambda-Dienst (Serverless) als Amazon Lambda@Edge anbietet. Dabei enthält Lambda@Edge nicht die volle Lambda-Funktionalität. Es bietet vielmehr „nur“ die Möglichkeit, Anfragen an Amazon Cloudfront (Amazons CDN-Dienst) und deren Antworten auf den Edge-Servern zu bearbeiten. Im Gegensatz zum gewöhnlichen Lambda mit seinem umfangreichen Support für JavaScript, Python, Ruby, Java, Go, C# und Powershell unterstützt Lambda@Edge „nur“ JavaScript und Python. Dennoch ist die Herkunft sowohl aus dem CDN als auch Serverless-Umfeld unverkennbar.

Einen anderen Ansatz verfolgt beispielsweise Cloudflare mit seinem Cloudflare-Workers-Dienst. Im Gegensatz zu Lambda@Edge steht dort eine komplette Serverless-Funktionalität zur Verfügung. Serverless-Funktionen können nicht nur CDN-Anfragen/Antworten bearbeiten, sondern komplett eigene Funktionen und Inhalte bereitstellen. Dazu stehen im Hintergrund Bibliotheken wie HTTP-Clients, Key-Value-Stores, Scheduler und vieles mehr zur Verfügung. Auch beim Support von Programmiersprachen geht Cloudflare einen anderen Weg und setzt voll auf
JavaScript und WebAssembly. JavaScript impliziert natürlich auch transpilierte Dialekte wie etwa TypeScript.

Deutlich interessanter ist der Support für WebAssembly. WebAssembly ist ein plattformagnostischer Assembler-Dialekt, der zum Beispiel in JavaScript VMs sehr schnell und effizient ablaufen kann. Das direkte Schreiben von Assembler-Code ist sicher nicht jedermanns Sache; soll es jedoch auch nicht sein. Vielmehr dient WebAssembly als ein kleiner gemeinsamer Nenner, gewisssermaßen als standardisierte Ablaufplattform. Quellcode in Programmiersprachen wie Rust, C, Cobol, Kotlin, Dart, Python, Scala, Reason/OCaml, Perl, PHP und FSharp lässt sich als WebAssembly-Ausgabe kompilieren. All diese Programmiersprachen lassen sich damit auch grundsätzlich zur Entwicklung von Cloudflare-Worker-Diensten nutzen – zur Not auch gemischt. Dies erleichtert unter anderem die Nutzung von vorhandener Business-Logik im Edge- Computing-Umfeld. Man kann also bestehende (bewährte und getestete) Business-Logik übernehmen und vermeidet das Risiko von (neuen) Fehlern im Rahmen einer Portierung.

Sowohl Amazon Lambda@Edge als auch Cloudfront Workers stellen somit ein Beispiel für Edge Computing dar, das sich aus dem klassischen CDN-Umfeld entwickelt hat – auch wenn die angebotenen Features und angestrebten Use Cases sich im Einzelnen unterscheiden.

Anbieter zum Thema

zu Matchmaker+

  1. Albtraum oder kalter Kaffee
  2. Endpoint Edge Computing

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu TREND MICRO Deutschland GmbH

Weitere Artikel zu Bedrohungsabwehr

Weitere Artikel zu Dögel IT-Management

Weitere Artikel zu Hisense Germany

Weitere Artikel zu bar pneumatische Steuerungssysteme GmbH

Matchmaker+