Lynx Software

Wenn Edge und Cloud verschmelzen

13. Dezember 2022, 8:54 Uhr | Ian Ferguson
Wenn Edge und Cloud verschmelzen
© Quelle: Shutterstock

Es wird immer schwieriger, Funktionen, die in der Cloud stattfinden, von Funktionen, die am Edge ausgeführt werden, zu trennen – beide Welten werden zusehends vollständig abhängig voneinander. Welche Sicherheitsrisiken entstehen dadurch und wie lassen sie sich beseitigen?

Lokale System in der Fertigung werden häufig mit der Cloud verbunden. Beispielsweise, wenn die lokale Applikation vom kontinuierlichen Zugriff auf fortschrittliche Algorithmen der künstlichen Intelligenz und Datenanalysepaketen in der Cloud profitieren soll. Da diese Systeme für den Fertigungsprozess von entscheidender Bedeutung sind, müssen sie gegen Hackerangriffe und Fehlfunktionen eines anderen Programms, das auf derselben Hardware läuft, geschützt werden. Wie lässt sich dies erreichen?

Der aktuelle Sicherheitskontext

Die Virtualisierungstechnologie, bei der sich mehrere Betriebssysteme auf gemeinsam genutzter Hardware ausführen lassen, ist wohlbekannt und sehr gut verstanden, auch wenn sie etwas ineffizient in der Nutzung der Ressourcen ist. Noch vor wenigen Jahrzehnten verwendete jeder virtuelle Maschinen (VM), um die Infrastruktur zu hosten und zu verwalten. In jüngster Zeit haben sich die Branchen auf die Verwendung von Containern mit Systemen wie Docker und Kubernetes verlagert.

Das ursprüngliche System der Virtualisierungsarchitektur basierte auf der Implementierung einer Reihe von VMs. Jede virtuelle Maschine muss ihre eigene Instanz eines Betriebssystems ausführen, was zu einer Verdoppelung der Verantwortung führt. Außerdem ist es schwierig, eine solche Infrastruktur zu verwalten, da es mehrere Server gibt, die allesamt unabhängige virtuelle Maschinen sind.

Container versuchen, das gleiche Konzept wie virtuelle Maschinen zu erreichen, vermeiden aber doppelten Aufwand zwischen Maschinen. Anstatt ein komplettes Betriebssystem für eine Anwendung zu laden, können Docker-Container den Kernel des Host-Betriebssystems verwenden und gleichzeitig anwendungsspezifische Bibliotheken und Programme nachladen. Durch die Anpassung des Containers und seines Images ist es möglich, die spezifischen Bibliotheken und die Konfiguration, die die jeweilige Anwendung verwenden wird, fein abzustimmen. Dies führt zu Leistungssteigerungen ohne den Overhead eines kompletten Betriebssystems.

Eine moderne Anwendung besteht aus vielen Containern. Sie in der Produktion zu betreiben, ist die Aufgabe von Kubernetes. Da Container leicht zu replizieren sind, können Anwendungen automatisch skaliert werden: Die Verarbeitungskapazitäten werden entsprechend den Anforderungen der Benutzer erweitert oder verringert.

Eine der Herausforderungen bei Containern ist die Sicherheit, denn die Container müssen mit einem Zero-Trust-Ansatz effektiv nutzbar gemacht werden. Folglich erfordert ihr Einsatz in unternehmenskritischen Umgebungen einen „Least Privilege“-Ansatz, bei dem den Anwendungen nur ein Minimum an Systemressourcen zur Verfügung steht, die für die Ausführung ihrer Aufgabe erforderlich sind, sowie eine starke Isolierung zwischen den Anwendungen, damit die Betriebs- oder Anlagenleiter darauf vertrauen können, dass die Lösung die OT-Anforderungen an Sicherheit, Verfügbarkeit und Leistung erfüllt.

Einführung von Google Anthos

Die Plattform Lynx Mosa.ic unterstützt nun die Bereitstellung von Google Anthos Bare Metal. Dies schafft eine Lösung, die es ermöglicht, jeden containerisierten Dienst an den aufgabenkritischen „Rand“ zu bringen, ohne die Sicherheit oder Leistung zu beeinträchtigen. So können jetzt zum Beispiel Software-Dienste aus der Cloud wie der Google Cloud Visual Inspection AI Service implementiert werden, um eine validierte Lösung für eine sichere, videobasierte Qualitätsprüfung in Industrie- und Energieanlagen zu realisieren.

Der Einsatz von Anthos Bare Metal bedeutet, dass jetzt ein ganzer Kubernetes-Cluster lokal auf nur einem Hardwaresystem am Rande ausgeführt werden kann – mit Kubernetes- und Workload-Management in Unternehmensqualität, vollständig verwaltetem Service-Mesh mit integrierter Transparenz und einer konsistenten Entwicklungs- und Betriebserfahrung für On-Premise- und On-Cloud-Bereitstellungen. Lynx ermöglichte eine virtuelle Luftlochspaltung, die für eine Isolierung zwischen den verschiedenen Teilen des Systems sorgt.

In der Vergangenheit stellte die Verschmelzung der Welten der Betriebstechnologie (Operational Technology, kurz: OT) und der IT – das Trainieren von KI- und maschinellen Lernmodellen in der Cloud und die Bereitstellung von Cloud-basierten Workloads am Netzwerkrand – eine Herausforderung für die Sicherheit in unternehmenskritischen industriellen Umgebungen dar. Lynx stellt zum Beispiel sicher, dass die drei Funktionen – Bilderfassung (Kamera), Einblicke über die Inferenzmaschine (Anthos) und die Aktion mit einem übergeordneten Controller – vollständig in einer Sandbox untergebracht sind, mit der Möglichkeit, sichere Einwegverbindungen (Datendiode) zwischen ihnen herzustellen.

Bei einer visuellen Inspektions-Applikation (VI) beispielsweise, könnte die Modellerstellung ein On-Cloud-Dienst sein. Vorklassifizierte Daten würden vor Ort generiert und an den VI-Modellerstellungsdienst in der Cloud weitergeleitet. Alternativ ließe sich ein hybrider Cloud-Dienst einsetzen, bei dem das in der Cloud generierte VI-Modell in einer lokalen Anthos-Umgebung verankert ist, um die Bildinferenzierung am Edge durchzuführen. Es besteht auch die Möglichkeit einer reinen Vor-Ort-Lösung, bei der sowohl die VI-Modellgenerierung als auch die Bildinferenzdienste vor Ort bereit stehen.

Das Anthos-Bereitstellungsmodell

Anbieter zum Thema

zu Matchmaker+
Wenn Edge und Cloud verschmelzen
Bild 1. Ein eigenständiger Anthos-Cluster, der auf LynxSecure, einem Separation Kernel Hypervisor, läuft.
© Quelle: Lynx

Die Lösung nutzt Anthos als verwaltete Anwendungsplattform, die es Unternehmen ermöglicht, Kubernetes und die damit verbundenen Workloads über mehrere öffentliche Clouds, Hybrid-Clouds und On-Premise-Compute-Cluster hinweg auszuführen. Wie sieht der Einsatz dieser Plattform am unternehmenskritischen Randbereich aus? Zu den primären Bausteinen einer typischen einsatzkritischen Edge-Bereitstellung gehören:

  • Die Plattform -Software – sie wird auf den Zielsystemen (oder -knoten) bereitgestellt und ermöglicht das Hosten mehrerer Arbeitslasten auf den Zielsystemen;
  • Die Controller-Software – sie wird (meist) vor Ort eingesetzt, um verschiedene Knotenpunkte zu verwalten;
  • Das Anwendungs-Framework – es sorgt für eine einheitliche Kontrollebene für Endbenutzer-Workloads (entweder als eigenständige Anwendungen oder als Container);
  • Die Workloads: Software, die Endnutzer auf dem oben genannten Anwendungsrahmen einsetzen.

Anthos-Cluster auf Bare Metal unterstützen drei Bereitstellungsmodelle, um unterschiedlichen Anforderungen gerecht zu werden: Standalone-Cluster-Einsatz, Multi-Cluster-Einsatz und Hybrid-Cluster-Einsatz. Obwohl alle drei Bereitstellungsmodelle von Anthos für den unternehmenskritischen Bereich relevant sind, konzentrieren sich dieser Artikel auf die eigenständige Standalone-Cluster-Bereitstellung, bei der ein einzelner Kubernetes-Cluster sowohl die Admin- als auch die Nutzer-Cluster-Funktionen unterstützt. Ein Anthos-Nutzer-Cluster ist ein Kubernetes-Cluster, der Nutzer-Workloads ausführt, während ein Admin-Cluster Nutzer-Cluster verwaltet.

Für ein eigenständiges Bereitstellungsmodell sind sowohl die Steuerebene als auch die Arbeitsknoten erforderlich.

Das Blockdiagramm (Bild 1) bietet einen Überblick über einen eigenständigen Anthos-Cluster, der auf einem Separation Kernel Hypervisor, LynxSecure, innerhalb des Mosa.ic Software Frameworks läuft.

Fünf VMs sind für die Erledigung bestimmter Aufgaben eingerichtet:

° Vier Anthos-Cluster-VMs.

  • 1 Kubernetes-Cluster-Knoten der Steuerungsebene (als VM) - keine Unterstützung für hohe Verfügbarkeit
  • 2 Worker-Kubernetes-Cluster-Knoten (als VMs) - mit Unterstützung für hohe Verfügbarkeit
  • 1 Workstation-VM - wird für die Bereitstellung der Steuerebene und der Arbeitsknoten verwendet

° Eine fünfte VM für das Gerätemanagement, die die eingehenden Managementanfragen bearbeitet. In der Regel wird dies in Verbindung mit einer Verwaltungs -Software verwendet (entweder die unternehmenseigene Backend-Infrastruktur oder eine Technologie eines Drittanbieters wie ServiceNow).

Wenn Edge und Cloud verschmelzen
Der Autor: Ian Ferguson ist Vice President of Sales & Marketing bei Lynx Software Technologies.
© Lynx Software

Aufgrund der strikten Isolierung durch den Separation Kernel LynxSecure arbeiten die einzelnen VMs in ihren eigenen Fehlerzonen. Die Cluster-VMs - Control Plane und Worker Nodes - und die Workstation-VM sind über virtuelle Ethernet-Links (implementiert über ein verwaltetes Shared-Memory) verbunden. Obwohl die VM, die das Gerätemanagement hostet, Zugang zum Lynx Management Center hat, hat sie keine interne Verbindung zu den Cluster-VMs. Diese Anordnung in Verbindung mit den strengen Isolationsgarantien des LynxSecure Separation Kernel Hypervisor stellt sicher, dass die Anthos-Workloads praktisch von den Aktivitäten der Verwaltungsebene getrennt sind.


Das könnte Sie auch interessieren

Verwandte Artikel

Lynx Software Technologies Europe

Edge & Cloud Computing - Applications

Safety & Security