Verfahren und Vorrichtung zur Erstellung eines Zerti fikates für die sicheren Bereitstellung von Diensten .

Die vorliegende Erfindung betri f ft ein Verfahren sowie ein System zur Bereitstellung von Diensten, insbesondere in einem industriellen Automat! sie rungs system .

Industrielle Automatisierungssysteme umfassen üblicherweise eine Viel zahl von über ein industrielles Kommunikationsnetz miteinander vernetzten Automatisierungsgeräte und dienen im Rahmen einer Fertigungs- oder Prozessautomatisierung zur Steuerung oder Regelung von Anlagen, Maschinen bzw . Geräten . Aufgrund zeitkritischer Rahmenbedingungen in industriellen Automatisierungssystemen werden zur Kommunikation zwischen Automatisierungsgeräten überwiegend Echtzeit-Kommunikationsprotokolle , wie PROFINET , PROFIBUS , Real-Time-Ethernet oder Time-Sensitive Networking ( TSN) , verwendet . Insbesondere können Steuerungsdienste bzw . -anwendungen automatisiert und auslastungsabhängig auf aktuell verfügbare Server oder virtu- alisierten Umgebungen eines industriellen Automatisierungssystems verteilt werden .

Unterbrechungen von Kommunikationsverbindungen zwischen Rechnereinheiten eines industriellen Automatisierungssystems oder Automatisierungsgeräten können zu einer unerwünschten oder unnötigen Wiederholung einer Übermittlung einer Dienstanforderung führen . Außerdem können nicht oder nicht vollständig übermittelte Nachrichten beispielsweise einen Übergang oder Verbleib eines industriellen Automatisierungssystems in einen sicheren Betriebs zustand verhindern .

In Ethernet-basierten Kommunikationsnetzen können Probleme entstehen, wenn Netzressourcen für eine Übermittlung von Da- tenströmen oder von Datenrahmen mit Echt Zeitanforderungen konkurrierend für eine Übermittlung von Datenrahmen mit großem Nutzdateninhalt ohne spezielle Dienstgüteanforderungen beansprucht werden . Dies kann schließlich dazu führen, dass Datenströme oder Datenrahmen mit Echt Zeitanforderungen nicht entsprechend einer angeforderten bzw . benötigten Dienstgüte übermittelt werden .

Mit der Edge Technologie können beispielsweise automatisierungstechnische Anwender selbst einfach und modular die von ihnen gewünschten Funktionalitäten für ihre Automatisierung in Form von Applikationen installieren, aktualisieren und erweitern . Einerseits profitieren Anwendern von zentralisierter und einfach skalierbarer Verwaltung auch vieler, im Folgenden auch Industrial Edge genannte Geräte , andererseits vom Markt , der ebenfalls Drittanbieter dieser Applikationen umfasst . Ein wesentlicher weiterer Aspekt , ist der Wunsch der Automatisierungsanwender, Applikationen unterschiedlicher Anbieter möglichst ohne zusätzlichen Integrationsaufwand einfach installieren und sofort in Betrieb nehmen zu können .

Für einen semantisch hochwertigen und sicheren Datenaustausch hat sich in der Automatisierungstechnik OPC UA ( OPC Uni fied Architecture , www . opcfoundation . org) etabliert . Applikations- Anbieter steigern die Attraktivität ihrer Applikationen, indem sie beispielsweise die von diesen berechneten Daten aus einer Produktionsdatenanalyse , Bildanalyse und dergleichen mehr, über einen integrierten OPC UA Server anderen Automatisierungs funktionen bereitstellen . Gegenüber der klassischen Gerätewelt sind nun aber in das gleiche ( Industrial Edge ) Gerät nicht nur ein klassischer Geräte-OPC-Server zu integrieren, sondern mehrere Applikationen mit OPC UA Server Funktionalität von verschiedener ( Drift- ) Anbieter . Ablaufsteuerungskomponenten sind insbesondere Software-

Container, die j eweils von anderen Software-Containern oder Container-Gruppen isoliert innerhalb der Ablaufsteuerungsumgebung auf einem Host-Betriebssystem einer Server-Einrichtung ablaufen . Grundsätzlich können für die Ablaufsteuerungskomponenten auch alternative Micro-Virtualisierungskonzepte , wie Snaps , verwendet werden .

Die Ablaufsteuerungsumgebung kann beispielsweise eine Docker Engine oder einen Snap Core umfassen, die auf einer Server- Einrichtung abläuft . Vorteilhafterweise nutzen die Software- Container j eweils gemeinsam mit anderen auf der j eweiligen Server-Einrichtung ablaufenden Software-Containern einen Kernel des Host-Betriebssystems der Server-Einrichtung . Speicherabbilder für die Software-Container können beispielsweise aus einem durch eine Viel zahl von Nutzern lesend bzw . schreibend zugrei fbaren Speicher- und Bereitstellungssystem abgerufen werden .

Auch Anwender von solchen, mittels Containervirtualisierung oder vergleichbaren Virtualisierungskonzepten realisierten, Steuerungsanwendungen für industrielle Automatisierungssysteme erwarten eine möglichst unkompli zierte Integration derartiger Anwendungen in ihre bestehende Infrastruktur .

Die Druckschri ft US 2020/ 0099656 Al beschreibt eine Connectivity Lösung (bspw . eine Cloud Lösung) für Dienste in einem Netz , bilden einen Dienst ( z . B . einen oder mehrere Workloads oder Container ) , der im virtuellen Netzwerk des Dienstanbieters ausgeführt wird, im virtuellen Netzwerk des Dienstnutzers ab . Bei der Abbildung wird ein Load Balancer verwendet , der so konfiguriert ist , dass der Dienst über eine Reihe virtueller Maschinen skaliert wird . Die Zuordnung erfolgt über Network Address Translation (NAT ) , die von der Cloud- basierten Infrastruktur durchgeführt wird .

Wird eine OPC UA Server-Applikation in einer Virtualisie- rungslösung wie beispielsweise einem ( Docker ) Container ausgeführt , dann ist die Applikation zunächst einmal frei in den von ihr belegten Netzwerkressourcen wie insbesondere TCP- Ports - hier ist insbesondere bei OPC UA der Port 4840 für einen einzelnen Server vordefiniert .

Eine manuelle Integration, wie in der bisherigen Einzelgerätewelt , ist im industriellen Umfeld zu aufwändig und fehlerträchtig, und teilweise aufgrund mangelnder Konfigurationspunkte in den OPC UA Servern sogar unmöglich . Diese Integration umfasst nicht nur die Applikationen im Gerät , sondern auch das Zusammenspiel Geräte-externer Anteile der Automatisierungs-Applikationen mit den Geräte-Applikationen .

Je nach Netzwerkanbindung und verwendeter Ablaufsteuerungsumgebung tref fen insbesondere OPC UA Server auf höchst unterschiedliche anwenderseitige Konfigurationen, die durch Entwickler von Steuerungsanwendungen bei automatisierten Konfigurationsverfahren für die Steuerungsanwendungen berücksichtigt werden müssen . Bei der Netzwerkanbindung stellen anwenderseitig knappe IP-Adress- und TCP-Portnummernbereiche besondere Heraus forderungen im Rahmen der Integration von Steuerungsanwendungen in eine bestehende Infrastruktur dar .

Die OPC UA Server-Applikationen sind j edoch ohne weitere Maßnahmen nicht von außen erreichbar, so dass der Anwender die Server-Ports zwischen der Applikations-Sicht und der Edge- Geräte-Sicht rangieren muss und dabei auf Port-Konflikte und das Einhalten möglicher Einschränkungen der Netzwerkumgebung achten muss - wie beispielsweise die begrenzte Menge der in Firewalls freischaltbaren Ports und deren konkrete Wertebereiche bzw . voreingestellte Standardregeln ohne weiteren (Konf igurations- ) Aufwand verwenden kann .

Außerdem muss der automatisierungstechnische Anwender die anderen Anteile seiner Automatisierungsapplikation mit den Servern über die konkreten Netzwerkadressierungsinformationen verknüpfen .

Stand der Technik

Anwender und Entwickler von Server-Applikationen im Ökosystem der Industrial Edge wünschen eine über die reine Konnektivität zwischen Clients und Servern hinausgehende abgesicherte Kommunikation, beispielsweise gemäß OPC UA-Standard . Die abgesicherte Kommunikation soll dabei möglichst einfach und vor allem möglichst ohne zusätzlichen Aufwand und Expertenwissen bei Einrichtung und Betrieb möglich sein . Zudem müssen mehr als nur ein einzelner UA-Server unterstützt werden können .

Die Teilnehmer am Ökosystem der Industrial Edge wünschen deshalb weitgehend automatische Integrationsmechanismen, möglichst ohne Eingri f fe in heute gängige OPC UA-Software- Stacks .

Für die im Folgenden beschriebene Verfahren ist es Voraussetzung, dass ( OPC UA- ) Server auf einem Industrial Edge/Container System, beispielsweise über einen intelligenten Proxy, für Clients auf findbar und erreichbar sind . Mögliche Lösungen für diese Aufgabe hat die Anmelderin in einer weiteren (nachveröf fentlichten) Patentanmeldung beschrieben .

Ohne weitere Maßnahmen wird der Verbindungsaufbau über den Proxy mit einem inneren Server, vom OPC UA Client bei der Prüfung des Server-Zerti fikats abgebrochen, da die im Zerti- fikat eingetragenen innerhalb des Teilnetzes gültigen Adressierungsinformationen, auch „inneren" oder internen Endpunkt- Adresse (n) (EndpointURI s , Uni form Resource Identi fier ) genannt , des Servers nicht mit den für die Clients sichtbaren (und durch den Proxy erstellten „äußeren" oder externen) EndpointURI s übereinstimmen .

Die Manipulation der Endpunkt-Adressen (EndpointURI s ) der OPC UA Server-Apps/ Instanzen durch den Proxy ist j edoch grundsätzlich erforderlich .

Die Generierung/Verwendung von Zerti fikaten mit ungültigen Netzwerkparametern (Hostname/ IP und Port ) durch den Server ist eine systembedingte Eigenschaft gängiger Virtualisie- rungslösungen (wie Containern) , da nur diese dem OPC UA Server bekannt sind .

Bei der Ablehnung des Serverzerti fikats durch den Client , handelt es sich um eine grundlegende Eigenschaft gängiger Virtualisierungslösungen (wie Containern) , da einem darin ausgeführten ( OPC UA) Server immer stets nur seine inneren Netzwerkparameter (Hostname/ IP und Port ) des virtuellen Netzwerkes bekannt sind, aber diese nicht mit den Netzwerkparametern des für den Client erreichbaren Host-Systems übereinstimmen .

Bislang führt dies zu der Schwierigkeit , dass einerseits die Entwickler von ( OPC UA) Server-Applikationen geeignete zusätzliche Konfigurationsmechanismen vorsehen müssen und andererseits industrielle Anwender bei Inbetriebsetzung von Industrial Edge-Geräten und deren ( OPC UA) Server-Applikationen die erforderlichen und für den Verbindungsaufbau geeigneten Server-Zerti fikate manuell erstellen und in die einzelnen ( OPC UA) Server-Applikationen installieren müssen . Anwender und Applikations-Entwickler wünschen sich deshalb das automatisierte Abwickeln der Schritte , um möglichst rasch und ohne Aufwand ein sicher laufendes System zu bekommen .

Durch die OPC UA-Standards sind solche Lösungen derzeit nicht erfasst .

Applikations-Entwickler wünschen sich darüber hinaus , dass sie möglichst wenig oder idealerweise keinerlei spezielle Vorkehrungen für ihre Industrial-Edge Container berücksichtigen müssen, also eine out-of-the-box-Lösung .

Damit der Server ein gültiges Zerti fikat erhält muss der Anwender heute : zunächst manuell ein Zerti fikat mit den konkreten Endpunkt- Informationen (EndpointURI s ) des Hostsystems erstellen . Diese sind erst im laufenden Betrieb sicher bekannt .

In einem zweiten Schritt muss er das Zerti fikat auf den ( OPC UA) Server laden, wobei dieses Laden abhängig vom j eweiligen ( OPC UA) Server und dessen Lade-Mechanismus ist .

Ein automatisierter Prozess kann hierfür nicht eingesetzt werden, da bei dem zugrundliegenden „Certi ficate Signing Request" ( CSR) des OPC UA Servers gegenüber einem Zerti fikatsserver ebenfalls nur die inneren Netzwerkparameter verwendet werden .

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde , eine sichere Bereitstellung von Diensten zu bieten, wobei eine automatisierte Erstellung und Einrichtung ermöglicht wird .

Diese Aufgabe wird erfindungsgemäß durch ein Verfahren mit den in Anspruch 1 angegebenen Merkmalenund durch eine Vorrichtung mit den im Anspruch 5 angegebenen Merkmalen gelöst .

Das erfindungsgemäße Verfahren wird zur Erstellung eines Zerti fikates für die sichere Bereitstellung von Diensten mittels Ablaufsteuerungskomponenten in einer Ablaufsteuerungsumgebung an einen Dienstabnehmer verwendet .

Einem Dienst ist j eweils zumindest eine Server-Komponente zugeordnet , die durch eine in die Ablaufsteuerungsumgebung ladbare und dort aus führbare Ablaufsteuerungskomponente gebildet wird .

Eine Proxy-Komponente eines die Ablaufsteuerungsumgebung umfassenden Teilnetzes nimmt Anfragen von einem Dienstabnehmer an .

Eine zentrale Verzeichnisdienst-Komponente verwaltet die innerhalb des Teilnetzes gültigen Adressierungsinformationen einer internen Endpunkt-Adresse der Server-Komponente und zugehörigen äußeren Endpunkt-Adresse , an die Proxy- Komponente übermittelt und bei der eine Registrierung der Server-Komponente mit seinen internen Endpunkt-Adresse ( end- pointURI ) erfolgt .

Ein interner Verzeichnisdienst erhält die erforderlichen Informationen über äußere und zugehörige interne Endpunkt- Adresse vom lokalen Verzeichnisdienst und erstellt das für eine spätere Verschlüsselung der Kommunikation benötigte Zerti fikat mit der ermittelten zugehörigen äußeren Endpunkt- Adresse und pusht es an die Server-Komponente , damit ein Dienstabnehmer unter Verwendung des Zerti fikats eine verschlüsselte Verbindung zu der Server-Komponente aufbauen kann .

Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen wiedergegeben .

Die bevorzugte beschriebene Aus führungs form bezieht sich auf Server und Clients , welche mittels des Protokolls OPC-UA miteinander kommuni zieren . Es handelt sich j edoch nur um eine mögliche Ausgestaltungs form, andere Ausgestaltungen, insbesondere unter Verwendung des HTTPS Protokolls sind ebenfalls denkbar . Entsprechend ist der Server dann ein https-Server und der Client ein https-Client , die generellen Mechanismen bleiben aber die gleichen .

Die hier vorgeschlagene Lösung wird in den Figuren genauer dargestellt , dabei zeigt

Figur 1 den Aufbau des Systems am Beispiel einer Industrial Edge mit einzelnen Komponenten, und

Figur 2 einen beispielhaften Ablauf des erfindungsgemäßen Verfahrens in dem in Figur 1 dargestellten Systems .

Die Figuren zeigen eine Proxy-Komponente UAP, 203 mit Local Discovery Server Funktionalität LDS , 204 . ( OPC UA) Clients UAC, 100 können die auf einem einzelnen Netzwerkgerät - wie beispielsweise einer Industrial Edge / Container Host CH, 200 - installierte Viel zahl von ( OPC UA) Servern UAS , 201a, 201b mittels des Local Discovery Server LDS , 204 auf finden .

Die OPC UA Server UAS , 201a, 201b sind über die Proxy- Komponente UAP, 203 und vorzugsweise über nur einen Port , wie dem well-known Port 4840 , ansprechbar, was die Sicherheits- Aspekte der Netzwerktopologie aus administrativer Sicht verbessert . Die administrative Sicht der Netzwerkressourcen über die Proxy-Komponente UAP, 203 ist von der internen Server- bzw . Container-Sicht entkoppelt .

Die Proxy-Komponente UAP, 203 und die Verzeichnisdienst- Komponente , Local Discovery Server LDS , 204 können dabei als eine funktionale Einheit oder als getrennte funktionale Einheiten ( Prozesse , Programme , usw . ) ausgestaltet sein . Dies ist in der Figur durch den gestrichelten Kasten 206 angedeutet .

Die vom Verzeichnisdienst , Local Discovery Server LDS bereitgestellten Informationen ermöglichen es erst der Proxy- Komponente UAP, 203 Verbindungsanforderungen von OPC UA Clients UAC, 100 korrekt weiterzuleiten und bestimmte , noch unverschlüsselten Teile ( in der Regel der Beginn) der Kommunikation zur Diensteanf orderung entweder eigenständig auf Basis der bereitgestellten Information zu beantworten oder alternativ die zugehörigen Diensteantworten (ACK) korrekt umzuschreiben .

Die beschriebene Struktur 206 , bestehend aus einem OPC UA- Proxy UAP, 203 und dem Verzeichnisdienst , Local Discovery Service LDS , 204 wird erfindungsgemäß um einen neuartigen internen Verzeichnisdienst , Internal Global Discovery Service IGDS , 205 ergänzt . Dieser internen Verzeichnisdienst , IGDS ist nur für die auf einem ( Container ) Host / Industrial Edge Gerät , CH, 200 laufenden OPC UA-Server UAS , 201a, 201b, sowie für den Verzeichnisdienst Local Discovery Server LDS 204 sichtbar .

Der internen Verzeichnisdienst , Internal Global Discovery Service IGDS , 205 konfiguriert hierbei die im Container Host UAC verfügbaren OPC UA Dienste bzw . Applikationen mit korrekten Zerti fikaten . Korrekt bedeutet in diesem Kontext , dass die vom OPC UA Server verwendeten Zerti fikate nicht mehr auf die internen EndpointURI s , sondern auf die extern für die OPC UA Clients UAC, 100 auf findbaren und zu benutzenden Endpoint URI s ausgestellt sind .

Die externen Endpoint URI s werden hierbei beispielsweise über eine ( entsprechend Standard noch, zumindest teilweise , ungesicherte ) Kommunikationsverbindung über den Verzeichnisdienst , Local Discovery Service LDS , 204 erkundet . Danach kann ein UAC ( 100 ) eine Kommunikationsverbindung zu einem der UAS ( 201a, 201b, ... ) nicht nur grundsätzlich aufbauen, sondern auch erfolgreich sichern, da das vom UAS präsentierte Zertifikat nun korrekt auf den vom Client verwendete externen End- pointURI ausgestellt ist . Der Ablauf einer Inbetriebsetzung einer neuen Applikation ist in Figur 2 dargestellt , mit folgenden Schritten;

1 . Ein Credential wird in einem zentralen Speicherort CRED hinterlegt . Credentials sind aus dem Security Umfeld bekannt . Die Credentials sind innerhalb des Container Host beim interner Verzeichnisdienst IGDS , 205 und bei den Dienstanbietern 201a, 201b bekannt . Diese können bereits vorher generiert und hinterlegt worden sein, beispielsweise bei der Proj ektierung .

2 . Eine Registrierung beispielsweise einer (neuen) Applikation auf einem OPC-UA Server UAS , 201a, 201b erfolgt .

3 . Aufgrund der Registrierung werden für die spätere Verschlüsselung benötigten Zerti fikate vom internen Verzeichnisdienst IGDS , 205 erzeugt (und beispielsweise in einer sogenannten Mapping Table im Lokalen Verzeichnisdienst LDS , 204 hinterlegt ) .

4 . Die Zerti fikate werden an den OPC-UA Server mit der Applikation gepusht , 212a, 212b .

5 . Ein Dienstabnehmer 100 baut eine Verbindung zu dem Container Host CH auf , um auf eine Applikation UAS , 201a, 201b zuzugrei fen . Die Anfrage wird an den Lokalen Verzeichnisdienst 204 von der Proxy-Komponente 203 durchgereicht .

6 . Der Diensteabnehmer bekommt die benötigten Informationen und kann danach die Verbindung mit dem Dienstanbieter 201a, 201b aufnehmen, über die Proxy-Komponente 203 , mit dem richtigen Zerti fikat und der korrekten EndpointURI s .

Der Diensteabnehmer 100 bekommt vom Routing nichts mit . Der Verzeichnisdienst , Proxy-Komponente 203 bekommt vom Lokalen Verzeichnisdienst LDS 204 die internen Verbindungsinformationen und leitet die Anfrage des Diensteabnehmer 100 an diesen Server (UAS ) weiter .

Der Server übermittelt dem Client sein Zerti fikat , dass er zuvor vom ( I ) GDS bekommen hat und dass nun die externen End- pointURI s enthält .

Der interne Verzeichnisdienst IGDS , 205 erhält die für seine korrekte Funktion erforderlichen Informationen über sowohl die äußeren als auch internen EndpointURI s vom Lokalen Verzeichnisdienst LDS , 204 . Der Lokalen Verzeichnisdienst LDS , 204 verfügt über diese Informationen, weil sich die OPC UA Server, Dienstanbieter UAS , 201a, 201b, bei ihm mit ihren internen EndpointURI s registrieren und der Lokalen Verzeichnisdienst LDS zudem mit der Proxy-Komponente UAP, 203 bezüglich der externen EndpointURI s synchronisiert ist .

Der interne Verzeichnisdienst IGDS , 205 kann für j eden OPC UA Server, Dienstanbieter UAS 201a, 201b, von einem externen Verzeichnisdienst Global Discovery Service GDS , 300 gemäß OPC UA-Standard, ein geeignet signiertes Zerti fikat 301 anfordern . Dazu übermittelt der interne Verzeichnisdienst IGDS dem externen Verzeichnisdienst Global Discovery Service GDS die zu zerti fi zierenden Informationen insbesondere mit dem korrekten externen Endpoint URI s , die der externe Verzeichnisdienst Global Discovery Service GDS anschließend signiert und dann dem interne Verzeichnisdienst IGDS 205 zurück übermittelt . Der interne Verzeichnisdienst IGDS 205 übermittelt anschließend ( 212a, 212b, ... ) diese , nun extern vom OPC UA Client , Dienstabnehmer UAC, 100 überprüfbaren und gültigen Zerti fikate an den j eweiligen OPC UA Server, Dienstanbieter UAS 201a, 201b .

Dieser ( Container Host , CH) interne Zerti fikataustausch wird über ein einzelnes nur intern benutztes Credential ( 213 ) ge- maß OPC UA-Standard abgesichert und darüber das Vertrauen zwischen den UAS und dem IGDS hergestellt .

Unter einem „Credential" versteht der Fachmann einen Berechtigungsnachweis , konkret ein Instrumentarium, das einem System die Identität eines anderen Systems oder eines Benutzers bestätigen soll .

Gegenüber einer heutigen manuellen Konfiguration ist j edoch nur ein einzelnes Geräte-internes Credential erforderlich, welches zudem nicht den Anforderungen für das Vertrauensverhältnis zwischen dem internen Verzeichnisdienst , internal Global Discovery Service IGDS 205 und einem Kunden- Verzeichnisdienst GDS 300 unterliegt . Insbesondere kann das Credential beispielsweise als „authentication token" oder auch ein Security-Token, also beispielsweise eine Hardwarekomponente zur Identi fi zierung und Authenti fi zierung von Benutzern . Eine andere Möglichkeit ist die Aus führung mittels „user/password" Eingabe , was ggf . auch rein lokal generiert und hantiert werden kann .

Weiterhin entkoppelt gegenüber der heute im OPC UA-Standard beschriebenen Systemkonfiguration ist ein lokaler/ interner Verzeichnisdienst IGDS , 205 , der die einzelnen OPC UA Server, Dienstanbieter UAS 201a, 201b vom Verzeichnisdienst GDS , 300 beispielsweise in einer Kundeninfrastruktur propagieren kann .

Ein neuartiger, in einem ( Container ) Host integrierten, 200 internen Verzeichnisdienst , internal Global Discovery Service IGDS 205 fungiert als Zwischeninstanz zwischen dem vorbekannten Verzeichnisdienst GDS , 300 , beispielsweise einer Kundeninfrastruktur, und den OPC UA-Server-Applikationen .

Der interner Verzeichnisdienst IGDS , 205 verfügt über die erforderlichen beiden Sichten auf sowohl die externen als auch internen Endpunkt-Adressen (EndpointURI s ) und damit auch die verfügbaren Host-internen OPC UA-Server UAS 201a, 201b und den darauf zur Verfügung gestellten Applikationen . Nur er kann die für die erfolgreiche abgesicherte Kommunikation zwischen den externen UA-Clients UAC, 100 und den internen UA- Servern UAS 201a, 201b erforderlichen Zerti fikate korrekt aus füllen und extern signieren lassen .

Der externe Verzeichnisdienst GDS , 300 kann erst durch den internen Verzeichnisdienst IGDS , 205 die für den externen Zugri f f über einen OPC UA Client UAC, 100 erforderlichen Zertifikate -ggf . durch Involvierung einer weiteren Registration Authority RA und/oder Certi fication Authority CA korrekt erstellen, signieren und letztlich per IGDS auf die OPC UA Server Instanzen laden .

Eine Registrierungsstelle ( engl . : registration authority, kurz RA) ist eine Instanz innerhalb einer Sicherheitsinfrastruktur ( PKI ) und dient als Registrierungsbehörde für digitale Zerti fikate .

Die Registrierungsstelle arbeitet eng mit der Zerti fi zierungsstelle ( engl . : certi fication authority, kurz CA) zusammen und ist zuständig für das sichere Identi fi zieren und Registrieren des Zerti fikatnehmers .

Durch die sogenannte „Chain-of-Trust" ist somit sogleich ein Vertrauensverhältnis mit diesen OPC UA Server Instanzen korrekt hergestellt .

Durch das vorgeschlagene Verfahren und die vorgeschlagene Vorrichtung wird eine Inbetriebsetzung der gesicherten Kommunikation mit OPC UA-Server-Applikationen für die potenziellen Nutzer sehr vereinfacht . Hier muss nicht j ede Instanz manuell und einzeln eingebunden werden, die geschieht automatisch unter Berücksichtigung aller sicherheitsrelevanter Anforderungen .

Durch die verbesserte Sicherheit und verbesserte Inbetriebsetzung von Sicherheitselementen der Edge-Geräte und deren Applikationen ( insbesondere unter Vermeidung von Hürden und Fallen für den Inbetriebsetzen) wird eine Steigerung der Attraktivität des (Industrial) Edge Ökosystems erreicht.

Mit dem vorgeschlagenen Verfahren werden die auf einem

Edge/Container System laufenden OPC UA Server Instanzen auto- matisiert mit jeweils gültigen Zertifikaten befüllt.

Ein weiterer Vorteil der Erfindung entsteht durch das entkoppelte Vertrauensverhältnisse zwischen Kundeninfrastruktur und interner Edge-Inf rastruktur : die UA-Server-Applikationen haben kein Wissen über Zertifikate und / oder Credentials der sensitiven Kunden-Inf rastruktur, insbesondere des Kunden- Verzeichnisdienst GDS, der die Zertifizierungen ausführt. Die ermöglicht auch das Anbieten von Applikationen Dritter.