Beschreibung Verfahren und Vorrichtung zur Autorisierung einer einen Zu- gang anfragenden Applikation Die Erfindung betrifft ein Verfahren und eine Anordnung zur Autorisierung einer einen Zugang anfragenden Applikation, die in einer ersten virtualisierten Software- Instanz betrieben wird, an einen Diensterbringersystem, wobei mindestens eine weitere virtualisierte Software-Instanz auf einem gemeinsamen Hostsystem betrieben wird, sowie zugehörige Vorrichtungen und ein zugehöriges Computerprogrammprodukt. Da industrielle Systeme (Steuergeräte, Industrie PCs, IoT- und Edge-Geräte, Cloud-Server) oft über einen langen Zeitraum im Feld verwendet werden, sind sie sich ständig ändernden Vo- raussetzungen und einem dynamischen Umfeld ausgesetzt. Um mit diesen Umständen umzugehen, werden vor allem neue Geräte so entwickelt, dass sie über die Nutzungszeit flexibel angepasst werden können, z.B. durch die Unterstützung von nachladbaren Applikationen bzw. Anwendungen bzw. Apps. Geeignet dafür sind virtualisierte Software-Instanzen. Hierbei wird das Gastsys- tem z.B. die Software-Instanz vom Betriebssystem eines Host- system z.B. ein industrielles Edge-System isoliert. Das Host- system stellt eine virtuelle Laufzeitumgebung für die Soft- ware-Instanz zur Verfügung. Mit anderen Worten ausgedrückt, werden virtuelle (d.h. nicht physische) Geräte oder Dienste wie z.B. Betriebssystem(e), Datenspeicher und/oder Netz- werkressourcen bereitgestellt. Bekannt sind sogenannte Con- tainervirtualisierungen. Dabei dürfen mehrere virtualisierte Software-Instanzen („als Gäste“), isoliert voneinander den Kernel eines Hostsystems nutzen. Virtualisierte Software- Instanzen sind hier im Kontext vorzugsweise Container- Instanzen. Container-Technologien, welche mit Hilfe von Container- Laufzeitumgebungen wie z. B. Docker, runC, Podman, CRI-O oder containerd erbracht werden, werden häufig im Zusammenhang mit dynamisch nachladbaren Applikationen in Linux-basierten bzw. Windows-basierten Systemen verwendet. Container gewährleisten die Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen. Ein Container-Image ist ein Abbild eines Containers. Das Image selbst kann aus mehre- ren aufeinander aufbauenden Schichten (Layern) bestehen, die geschützt (kryptographisch, speichergeschützt, etc.) werden können. Die Layer können dabei zusammen das Dateisystem einer Container-Instanz bilden. Ein Image ist normalerweise porta- bel, kann in Repositories (auch Container-Registry genannt) gespeichert und mit anderen Nutzern geteilt werden. Aus einem Image können mehrere Container-Instanzen bzw. virtualisierte Software-Instanzen gestartet werden, d.h. eine aktive „In- stanz“ eines Container-Images wird also gerade ausgeführt, d.h. eine bestimmte Applikation wird innerhalb einer Contai- ner-Instanz betrieben. Unter Laufzeitumgebung kann beispielsweise ein Gerät oder ei- ne Vorrichtung verstanden werden, die derart eingerichtet sind, einen Programmcode auszuführen. Hierzu kann das Gerät oder die Vorrichtung beispielsweise eine Prozessoreinheit (CPU) aufweisen, die den Programmcode ausführt. Die Laufzeit- umgebung kann selbst in Software oder in Hardware realisiert sein. Die Laufzeitumgebung ermöglicht dabei die Ausführung von Programmcode. Eine Laufzeitumgebung kann durch mindestens einen umgebungsspezifischen Parameter beschrieben werden, z.B. der Maschinentyp / CPU-Typ, Version des Host- Betriebssystemkernels, Linux-Distribution, installierte Pake- te, andere laufende Prozesse, etc. Unter Programmcode kann im vorliegenden Zusammenhang eine Ap- plikation (App) und/oder ein Programm und/oder Programmbefeh- le und/oder ein Container-Image verstanden werden. Linux Con- tainer, z.B. unter Verwendung von Container- Laufzeitumgebungen wie Docker oder runC, ermöglichen bei- spielsweise die Ausführung eines Container-Speicherabbilds (Container-Image) und der darin enthaltenen Applikation in einer isolierten Ausführungsumgebung, die auf eine Laufzeit- umgebung der oben beschriebenen Art aufgesetzt werden kann. Container-Instanzen können beispielsweise verwendet werden, um flexibel unterschiedliche (App-)Funktionalitäten auf einem Steuergerät bzw. Feldgerät auszuführen. Eine Container- Instanz bzw. das Container-Image werden daher auch als Con- tainer-App bezeichnet. Möchte man eine Container-Instanz starten bzw. in Betrieb nehmen, sollte überprüft werden, dass die für eine Container- Instanz gewünschten Ausführungsbeschränkungen, auch Restrik- tionen (z.B. Zugriffsberechtigungen, Speicherlimits, Lizenz- schlüssel etc.) genannt, der Ausführungsumgebungen auch tat- sächlich umgesetzt sind. Des Weiteren ist nicht sicherge- stellt, dass im IoT-Umfeld (IoT = Internet of Things) eine Container-Instanz auf dem dafür vorgesehenen Endgerät(-typ) läuft. Dies führt dazu, dass wenn eine Container-Instanz ge- startet wird, das Risiko besteht, dass eine Container- Software der Ausführungsumgebung zu viele Rechte bzw. zu we- nige Ausführungsbeschränkungen, auch Restriktionen (z.B. Zu- griffs-/Zugangsberechtigungen, Speicherlimits, Lizenzschlüs- sel…) genannt, zuweist. Bei Virtualisierungsmethoden wie Containern-Instanzen ist be- sonders kritisch, dass sich unterschiedliche, isoliert ausge- führte virtualisierte Software-Instanzen den gleichen Be- triebssystem-Kernel teilen. Bei Betriebssystem-virtualierten Lösungen wie virtuelle Maschinen (VM) ist es möglich, dass mehrere virtualisierte Betriebssysteme gemeinsame Ressourcen (z.B. persistenter Speicher, Netzwerkressourcen etc.) verwen- den und dies der anfragenden Applikation nicht bekannt ist. Bei den meisten Plattformen kommunizieren die auf den Geräten betriebenen virtualisierten Software-Instanzen in den meisten Fällen mit sogenannten Backend-Services, welche außerhalb des Gerätes auf externen service- bzw. diensterbringenden Platt- formen betrieben werden. Um mit Backend-Services kommunizie- ren zu können, ist es üblicherweise erforderlich, dass sich die virtualisierte Software-Instanz an dem Backend-service authentisiert. Es ist auch möglich, dass Daten von einem IoT- Gerät zur weiteren Analyse zu einer Cloud ausgeleitet werden. Dabei kann ein sogenanntes Zero-Trust-Verfahren (Null- Vertrauen z.B. in https://en.wikipedia.org/wiki/Zero_trust_security_model be- schrieben) eingesetzt werden, über das zusätzlich die Gra- nularität der Benutzer-Berechtigungen an Geräte-Kriterien ge- koppelt ist. In Abhängigkeit von festgelegten gerätespezifischen Kriterien (z.B. Gerätehardwareeigenschaften, ggf. detektierten Geräte- schwachstellen, Netzbandbreitenutzung, Integrität und IP- Adresse der anfragenden Applikation, welche in einer solchen virtualisierten Software-Instanz betrieben wird, werden die Berechtigungen für die Zugriffsanfrage von einem sogenannten Policy Decision Point (PDP) bestimmt und der Anfrage über ei- nen sogenannten Zero-Trust-Policy Enforcement Point (ZT-PEP) zugewiesen. Berechtigungen werden somit nicht ausschließlich an (Benutzer-)Authentisierungsinformationen (wie z.B. Identi- tät/Benutzername) gekoppelt, sondern - wie oben beschrieben - an den Kontext der anfragenden Applikation gekoppelt. Bei einer Hostvirtualisierung, die eine Betriebssystemvirtua- liesierung ausgestaltet ist, und Container-basierten Umgebun- gen sollte die anfragende Applikation jedoch nicht isoliert zu betrachtet werden. Dies geht daraus hervor, dass das Cybersecurity-Risiko für eine Virtualisierte Maschine (VM) bzw. einer Container- Instanz steigt, wenn andere, gleichzeitig in der Virtualisie- rungsumgebung laufende Virtuelle Maschinen bzw. Container- Instanzen dieselben Ressourcen (Netzwerk, Speicher, Betriebs- system-Kernel usw.) benutzen, wobei die parallel laufenden Virtuellen Maschinen bzw. oder Container-Instanzen auch in der Verantwortung von Fremdfirmen verwaltet werden können. Speziell in diesen Szenarien gibt es erhöhte Risiken der ge- genseitigen Beeinflussung von virtuellen Maschinen oder eines Einbruchs in das Host- bzw. darunterliegende Virtualisie- rungssystem. Beispielsweise besteht bei dem Anwendungsbeispiel der oben genannten industriellen Edge, welche beispielsweise in https://new.siemens.com/de/de/produkte/automatisierung/theme n felder/industrial-edge.html beschrieben wird, die Möglichkeit, dass diverse Hersteller unterschiedliche Apps bereitstellen können, welche aus mehre- ren unterschiedlichen Containern bestehen und vom Betreiber des Gerätes analog zu Smartphone Apps auf dem Gerät instal- liert werden. Bei solchen Konstellationen ist die Gefahr sehr groß, dass durch das Erteilen von Zugriffsberechtigungen für eine App bzw. eine Container-Instanz einer App an ein Diensterbringersystem (z.B. einem Backendservice, eine Cloud) durch mangelnde Isolation auf dem Gerät Daten ausgeleitet werden. Dies ist z.B. möglich indem andere hoch privilegierte Container-Instanzen anderer Apps, auf die für den berechtig- ten Container bereitgestellten Daten des Diensterbringersys- tems zugreifen. In einem sicherheitskritischen Umfeld besteht daher Bedarf an einer verbesserten Überwachung und Zugangskontrolle einer ei- nen Zugang anfragenden Applikation, die in einer ersten vir- tualisierten Software-Instanz betrieben wird. Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren und eine Vorrichtung derart auszugestalten, dass eine gegen- über dem Stand der Technik sichere Autorisierung einer Appli- kation, welche in einer virtualisierten Software-Instanz be- trieben wird, gewährleistet wird. Diese Aufgabe wird durch die Merkmale gemäß den unabhängigen Patentansprüchen gelöst. Vorteilhafte Ausführungsformen der vorliegenden Erfindung sind in den abhängigen Ansprüchen be- schrieben. Die Erfindung beansprucht ein Verfahren zur Autorisierung ei- ner einen Zugang anfragenden Applikation, die in einer ersten Container-Instanz betrieben wird, an einen Diensterbringer- system, wobei mindestens eine weitere Container-Instanz auf einem gemeinsamen Hostsystem betrieben wird, gekennzeichnet durch folgende Verfahrensschritte: a) Bereitstellen einer Laufzeitkonfigurationsdatenbank, in der zumindest ein von einer Überwachungsfunktion erfass- ter, aktueller Konfigurationszustand des Hostsystems ab- gelegt wird, wobei der Konfigurationszustand ein aktuel- len Hostsystemstatus, Berechtigungen und/oder Laufzeit- konfiguration der ersten Container-Instanz sowie Berech- tigungen und/oder Laufzeitkonfiguration der mindestens einen weiteren auf dem Hostsystem betriebenen Container- Instanz und/oder zumindest eine Kommunikationsbeziehungs- konfiguration zwischen der ersten Container-Instanz und der mindestens einen weiteren Container-Instanz und/oder deren gegenseitigen Beeinflussung durch deren jeweiligen Berechtigungen und/oder Laufzeitkonfigurationen umfasst, b) Abfragen des aktuellen Konfigurationszustand in der Lauf- zeitkonfigurationsdatenbank und Überprüfen des abgefrag- ten Konfigurationszustandes der ersten Container-Instanz durch eine Ausführungsfunktion anhand wenigstens eines konfigurierbaren Zugangskriterium auf dessen Erfüllung, c) Autorisieren der anfragenden Applikation, wenn das we- nigstens eine Zugangskriterium erfüllt ist, oder d) Einleiten einer alarmierenden oder einer einen Zugang zum Diensterbringersystem entgegenwirkenden Maßnahme, wenn eines des wenigstens einen Zugangskriteriums nicht er- füllt ist. Das Verfahren ist vorzugsweise rechner-/computergestützt bzw. computerimplementiert ausgebildet bzw. wird vorzugsweise rechner-/computergestützt bzw. computerimplementiert ausge- führt. Der Zugang kann unbeschränkt sein. Die Maßnahme kann umfas- sen, dass parallel laufende solche Container-Instanzen vo- rübergehend gestoppt werden bzw. ihnen der Zugriff auf ge- meinsame Ressourcen wie z.B. Speicherressourcen, Netzwerkres- sourcen, Prozessressourcen etc. verweigert wird. Die Maßnahme kann eine Orchestrierung der ersten Container-Instanz und der wenigstens einen weiteren Container-Instanz in derart umfas- sen, dass die erste Container-Instanz und/oder die mindestens eine weitere Container-Instanz auf einem anderen Hostsystem installiert oder auf ein anderes Hostsystem verlagert werden. Eine bekannte Ochestrierungsumgebung ist beispielsweise Ku- bernetes https://kubernetes.io/). Im vorliegenden Kontext wird unter Authentisierung das Nach- weisen einer Identität (z.B. einer Person, eines Geräts etc.) bezeichnet. Die Authentisierung stellt einen ersten Schritt zur Prüfung der Identität eines Geräts, einer Container- Instanz etc. dar. Unter Autorisierung wird im vorliegenden Kontext die Einräumung von Privilegien bzw. das Gewähren des Zugangs zu den Privilegien (z.B. welche der erfolgreich nach- gewiesenen Identität zustehen) verstanden. Privilegien sind hierbei Rechte bzw. Berechtigungen (wie z.B. Zugriff auf definierte Volumes, Netzwerkressourcen oder Gerä- te) auf dem darunterliegenden System (Laufzeitumgebung, Be- triebssystem) oder (Prozess-)-berechtigungen innerhalb der Container-Instanz. Speziell durch den Zugriff auf Netzwerkressourcen oder durch das Zuweisen von Prozessberechtigungen ist es möglich, dass unberechtigte Applikationskomponenten Daten einer anderen virtualisierten Instanz ausspähen. Demnach ist nicht allein die Integrität einer anfragenden Ap- plikation ausschließlich als Grundlage dafür hergenommen wer- den kann, welche Zugriffsberechtigungen der die Ausführungs- funktion erteilt. Vielmehr müssen neben der Integrität der Instanz auch Integritätsaspekte der darunterliegenden Virtua- lisierungsumgebung und die Co-Existenz weiterer virtueller Maschinen bzw. Container-Instanzen und deren Laufzeitkonfigu- ration bei der Authentisierung und folgenden Autorisierung eine Rolle spielen. Die Laufzeitkonfigurationsdatenbank liefert somit eine Ver- bindung zwischen den Gast-Systemen und dem Hostsystem. Es ist demnach sinnvoll, dass eine eindeutige Identifikation für die Container-Instanz zugewiesen vom Hostsystem zugewiesen wird, welche in der Laufzeitkonfigurationsdatenbank hinterlegt wird. Damit können die in der Laufzeitkonfigurationsdatenbank zu jeder Container-Instanz gespeicherten Konfigurationsstatus bzw. -zustand des Hostsystems wie Hostsystemstatus, Berechti- gungen und/oder Laufzeitinformationen eindeutig einer Contai- ner-Instanz zugeordnet werden. Der aktuelle Konfigurationszustand des Hostsystems kann er- eignisabhängig und/oder in festlegbaren zeitlichen Abständen erfasst werden. Ein Ereignis kann z.B. eine Installation von Betriebssystemkomponente, Start-/Stopp von virtuellen Contai- ner-Instanzen, Updates o.ä. sein. Wenn weitere Container- Instanzen gestartet werden, dann kann der Status der anfra- genden Applikation sich ändern und ggf. zu deren Beendigung führen. Die in der Laufzeitkonfigurationsdatenbank gespeicherten Kon- figurationszustände des Hostsystems zu jeder Container- Instanz können nach vorgebbaren Klassifikationskriterien (z.B. Safety-Anforderung bzw. Priorisierung der durch die Container-Instanz zu erledigenden Aufgaben) der Container- Instanzen sortiert und gegebenenfalls priorisiert sind. Die in der Laufzeitkonfigurationsdatenbank gespeicherten Kon- figurationszustände z.B. durch Signatur, bei symmetrischen Verfahren HMAC oder durch Techniken wie JSON-Webtoken, X.509- Zertifkate integritätsgesichert werden. Der Konfigurationszustand des Hostsystem umfasst in der Regel neben seinem eigenen Hoststatus auch die Laufzeitkonfigurati- on der einen oder mehreren Container-Instanzen, Berechtigun- gen z.B. Zugriff auf Betriebssystem-Namespace, Netzwerkres- sourcen bzw. andere Geräte/Hostsysteme bzw. Prozesse bei Pro- zess- und Speicherressourcenteilung und mögliche Schwachstel- len der Container-Instanzen etc. Eine auf dem Hostsystem betriebenen Container-Instanz kann dort installiert sein bzw. der Applikation, die in der Con- tainer-Instanz betrieben wird, kann bereits autorisiert sein, d.h. ihr kann bereits der Zugang zum Diensterbringersystem gewährt worden sein. Eine Laufzeitkonfiguration ergibt sich z.B. durch eine Deployment-Änderung, z.B. Starten/Stoppen von Container- Instanzen, durch die eingesetzte Virtualisierungssoftware bzw. Laufzeitumgebung ggf. durch Update, externe Werkzeuge zur Kontrolle von Zugriffen durch andere virtualisierte und nicht virtualisierte Container-Instanzen. Kommunikationsbeziehungskonfigurationen betreffen in der Re- gel den Datenaustausch z.B. mit Hilfe von geteilten Speicher- ressourcen bzw. Namensräume und/oder durch die virtualisierte Netzwerkkommunikation. Eine gegenseitige Beeinflussung kann durch das Starten und Stoppen der einen Container-Instanz geschehen, das eine Wir- kung auf das Starten/Stoppen der anderen Container-Instanz haben kann, z.B. Prozessprivilegien, Beeinflussung in einer Gefährdung der Datenintegrität bei gemeinsam genutzten Res- sourcen (ggf. absichtlich durch Manipulation der Daten oder unabsichtlich bei Wettbewerb um die gemeinsamen Ressourcen innerhalb eines Netzwerkes). Die Überwachungsfunktion kann als Reporting Client für die Container-Instanzen ausgestaltet sein; diese kann auf dem Ge- rät/Hostsystem integriert (z.B. Plugin/Agent), aber auch au- ßerhalb des Hostsystem auf einem Remotesystem betrieben wer- den. Das wenigstens eine Zugangskriterium kann von einer Entschei- dungsstelle, die auf Basis einer von ihr durchgeführten Aus- wertung von verfügbaren Sicherheitsrichtlinien über die An- frage der Applikation entscheidet, bereitgestellt werden. Die Entscheidungsstelle kann beispielsweise als der eingangs erwähnte Policy Decision Point (PDP) ausgestaltet sein. Die- ser ist Bestandteil eines richtlinienbasierten Zugriffskon- trollsystems, das auf Grundlage der verfügbaren Informationen Attribute) und der geltenden Sicherheitsrichtlinien entschei- det, ob die Anfrage einer Applikation genehmigt werden soll oder nicht. Analog zum obigen Verfahren ist ein weiterer Aspekt der Er- findung eine Vorrichtung mit Überwachungsfunktion, welche da- zu eingerichtet ist, zumindest einen aktuellen Konfigurati- onszustand eines Hostsystems, auf dem mehrere Container- Instanzen betreibbar sind, zu erfassen und an eine Laufzeit- konfigurationsdatenbank zu übermitteln, wobei der Konfigura- tionszustand einen aktuellen Hostsystemstatus, Berechtigungen und/oder Laufzeitkonfiguration einer ersten Container-Instanz sowie Berechtigungen und/oder Laufzeitkonfiguration mindes- tens einer weiteren auf dem Hostsystem betriebenen Contai- ner-Instanz und/oder zumindest eine Kommunikationsbeziehungs- konfiguration zwischen der ersten Container-Instanz und der mindestens einen weiteren Container-Instanz und/oder deren gegenseitigen Beeinflussung durch deren jeweiligen Berechti- gungen und/oder Laufzeitkonfigurationen umfasst. Ein weiterer Aspekt der Erfindung ist eine Vorrichtung mit Ausführungsfunktion, die dazu eingerichtet ist, einer einen Zugang zu einem Diensterbringersystem anfragenden Applikati- on, die in einer Container-Instanz betrieben wird, zumindest einen aktuellen Konfigurationszustand des Hostsystems in ei- ner Laufzeitkonfigurationsdatenbank abzufragen und anhand we- nigstens einem konfigurierbaren Zugangskriterium auf dessen Erfüllung zu überprüfen sowie die anfragende Applikation zu autorisieren, wenn das wenigstens eine Zugangskriterium erfüllt ist, oder eine alarmierenden oder eine einen Zugang zum Diensterbrin- gersystem entgegenwirkenden Maßnahme einzuleiten, wenn eines des wenigstens einen Zugangskriteriums nicht erfüllt ist. Ein weiterer Aspekt der Erfindung ist eine Vorrichtung umfas- send eine Laufzeitkonfigurationsdatenbank, welche dazu einge- richtet ist, zumindest ein von einer Überwachungsfunktion er- fasste, aktuelle Konfigurationszustand eines Hostsystems, auf dem mehrere Container-Instanzen betreibbar sind, entgegenzu- nehmen und in der Laufzeitkonfigurationsdatenbank abzulegen und von einer Ausführungsfunktion abgefragte ein oder mehrere aktuelle Konfigurationszustände an die Ausführungsfunktion zu übermitteln, wobei der Konfigurationszustand eines aktuellen Hostsystemstatus, Berechtigungen und/oder Laufzeitkonfigura- tion einer ersten Container-Instanz sowie Berechtigungen und/oder Laufzeitkonfiguration mindestens einer weiteren auf dem Hostsystem betriebenen Container-Instanz und/oder zumin- dest eine Kommunikationsbeziehungskonfiguration zwischen der ersten Container-Instanz und der mindestens einen weiteren Container-Instanz und/oder deren gegenseitigen Beeinflussung durch deren jeweiligen Berechtigungen und/oder Laufzeitkonfi- gurationen umfasst. Ein weiterer Aspekt der Erfindung ist eine Anordnung zur Au- torisierung einer einen Zugang anfragenden Applikation, die in einer Container-Instanz betrieben wird, an ein Dienster- bringersystem, wobei mehrere Container-Instanzen auf einem gemeinsamen Hostsystem betreibbar sind, aufweisend die vorge- nannten Vorrichtungen. Des Weiteren kann ein Computerprogrammprodukt eingesetzt wer- den, umfassend ein nichtflüchtiges Speichermedium, auf dem ein ladbarer und ausführbarer Programmcode gespeichert ist, welches das Verfahren nach einem der oben genannten Ausfüh- rungsformen in einer Prozessoreinheit insbesondere einer oder verteilt in mehreren Vorrichtungen nach einer der vorherge- hend beschriebenen Ausführungsformen ausführt. Zusätzlich wird eine Variante des Computerprogrammproduktes mit Programmbefehlen zur Konfiguration eines Erstellungsge- räts, beispielsweise ein 3D-Drucker, ein Computersystem oder ein zur Erstellung von Prozessoren und/oder Geräten geeignete Herstellungsmaschine, beansprucht, wobei das Erstellungsgerät mit den Programmbefehlen derart konfiguriert wird, dass die Ausführungsumgebung erstellt werden kann. Darüber hinaus wird eine Bereitstellungsvorrichtung zum Spei- chern und/oder Bereitstellen des Computerprogrammprodukts be- ansprucht. Die Bereitstellungsvorrichtung ist beispielsweise ein Datenträger, der das Computerprogrammprodukt speichert und/oder bereitstellt. Alternativ und/oder zusätzlich ist die Bereitstellungsvorrichtung beispielsweise ein Netzwerkdienst, ein Computersystem, ein Serversystem, insbesondere ein ver- teiltes Computersystem, ein cloudbasiertes Rechnersystem und/oder virtuelles Rechnersystem, welches das Computerpro- grammprodukt vorzugsweise in Form eines Datenstroms speichert und/oder bereitstellt. Diese Bereitstellung erfolgt beispielsweise als Download in Form eines Programmdatenblocks und/oder Befehlsdatenblocks, vorzugsweise als Datei, insbesondere als Downloaddatei, oder als Datenstrom, insbesondere als Downloaddatenstrom, des vollständigen Computerprogrammprodukts. Diese Bereitstellung kann beispielsweise aber auch als partieller Download erfol- gen, der aus mehreren Teilen besteht und insbesondere über ein Peer-to-Peer Netzwerk heruntergeladen oder als Datenstrom bereitgestellt wird. Ein solches Computerprogrammprodukt wird beispielsweise unter Verwendung der Bereitstellungsvorrich- tung in Form des Datenträgers in ein System eingelesen und führt die Programmbefehle aus, sodass das erfindungsgemäße Verfahren auf einem Computer zur Ausführung gebracht wird oder das Erstellungsgerät derart konfiguriert, dass es die Ausführungsumgebung erstellt werden kann. Das Verfahren, die Anordnungen, Vorrichtungen, Einheiten bzw. Geräte und Computerprogramm(-produkte), welches einen ladba- ren und ausführbaren Programmkode oder verteilt ladbare und ausführbare Programmkodemodule umfassen kann, können entspre- chend der Weiterbildungen/Ausführungsformen des vorgenannten Verfahrens und deren Weiterbildungen/Ausführungsformen und umgekehrt ausgebildet sein. Eine Ausführungsform der Erfindung sieht vor, dass eine Ein- heit bzw. Komponente bzw. Vorrichtung integrierte oder kop- pelbare Funktion als eine Software-, Firmware- bzw. Hardware- Komponente ausgebildet sein kann. Eine Komponente kann einen Prozessor umfassen. Bei einem Prozessor bzw. Prozessoreinheit kann es sich insbe- sondere um einen Hauptprozessor (engl. Central Processing Unit, CPU), einen Mikroprozessor oder einen Mikrokontroller, beispielsweise eine anwendungsspezifische integrierte Schal- tung oder einen digitalen Signalprozessor, möglicherweise in Kombination mit einer Speichereinheit zum Speichern von Pro- grammbefehlen, etc. handeln. Bei einem Prozessor kann es sich beispielsweise auch um einen IC (integrierter Schaltkreis, engl. Integrated Circuit) oder um ein Multi-Chip-Modul han- deln, insbesondere einen FPGA (engl. Field Programmable Gate Array) oder einen ASIC (anwendungsspezifische integrierte Schaltung, engl. Application-Specific Integrated Circuit), ein SoC (System on Chip) einen Grafikprozessor GPU (Graphics Processing Unit), einen Prozessor zur Auswertung eines neuro- nalen Netzes wie beispielsweise eine TPU (Tensor Processing Unit) oder einen DSP (Digitaler Signalprozessor, engl. Digi- tal Signal Processor) handeln. Der Prozessor kann eine oder mehrere Rechenkerne (multi-core) aufweisen. Auch kann unter einem Prozessor ein virtualisierter Prozessor oder eine Soft- CPU verstanden werden. Es kann sich beispielsweise auch um einen programmierbaren Prozessor handeln, der mit Konfigura- tionsschritten zur Ausführung des genannten erfindungsgemäßen Verfahrens ausgerüstet wird oder mit Konfigurationsschritten derart konfiguriert ist, dass der programmierbare Prozessor die erfindungsgemäßen Merkmale des Verfahrens oder anderer Aspekte und Teilaspekte der Erfindung implementiert. Der Pro- zessor kann einen Tamper-Schutz zum Schutz vor physikalischen Manipulationen aufweisen, z.B. Tamper-Sensoren zur Detektion physikalischer Angriffe. Ausführungsbeispiele der Erfindung Ausführungsbeispiele des erfindungsgemäßen Verfahrens und der Übertragungsvorrichtung sind in den Zeichnungen beispielhaft dargestellt und werden anhand der nachfolgenden Beschreibung näher erläutert. Es zeigt: Figur 1 eine beispielhafte Anordnung, bei der das erfindungs- gemäße Verfahren angewandt werden kann und Figur 2 ein Ablaufdiagramm des erfindungsgemäßen Verfahrens. Die Figur 1 zeigt beispielhaft eine Anordnung, bei der ein erfolgreicher Aufbau einer Verbindung zu einem Diensterbrin- gersystem DE nach einer Anfrage einer Applikation durchge- führt wird, die beispielsweise in einer Container-Instanz C1 betrieben wird. Zur Erkennung des Vertrauensstatus der Container-Instanz C1 einer anfragenden Applikation bzw. App (siehe 3) soll auch der Gerätestatus weiterer Container-Instanzen z.B. C2, also den parallel auf der Virtualisierungsplattform eines Hostsys- tems D (beispielsweise ein Gerät) betriebenen Container- Instanzenund deren zugewiesene Privilegien berücksichtigt werden. Privilegien sind hierbei Berechtigungen auf dem darunterlie- genden System (wie z.B. Zugriff auf definierte Volumes, Netz- werkressourcen oder Devices) oder (Prozess-)-berechtigungen innerhalb der Instanz. Speziell durch den Zugriff auf Netz- werkressourcen oder durch das Zuweisen von Prozessberechti- gungen ist es möglich, dass unberechtigte Applikationskompo- nenten Daten einer anderen Container-Instanz ausspähen oder zu manipulieren. Mit Hilfe einer bereitgestellten Laufzeitkonfigurationsdaten- bank TDB, die in eine Vorrichtung implementiert sein kann, soll zusätzlich auch der Gerätestatus und die Laufzeitkonfi- guration der Komponenten (z.B. eingesetzte Version der Virtu- alisierungssoftware oder Container-Laufzeitumgebung L) be- rücksichtigt werden. Neben dem Vertrauensstatus der anfragenden Applikation wird auch der Vertrauens- und Konfigurationsstatus des Hostsystems z.B. des Gerätes selbst beispielsweise mit Hilfe eines eine Überwachungsfunktion RC ausführenden Agenten bzw. Plugins in der Virtualisierungsumgebung und/oder über Remotezugriff auf eine externe Vorrichtung/Einrichtung, die die Überwachungs- funktion RC umfasst, Laufzeitkonfigurationsdaten erfasst. Hierzu werden Laufzeitkonfigurationen bei jeder Deployment- Änderung (Starten und Stoppen von Instanzen, Durchführen von Software-Updates) und Berechtigungen z.B. Zugriff auf Spei- cher/Namespace bzw. Netzwerkressourcen der Container- Instanzen in Schritt 1a erfasst und diese in die Laufzeitkon- figurationsdatenbank in Schritt 2 geschrieben. Diese Lauf- zeitkonfigurationsdatenbank beinhaltet somit die aktuelle Ge- räte- und Laufzeitkonfiguration, welche durch eine Ausfüh- rungsfunktion PEP, beispielsweise ausgebildet als Zero-Trust- Policy-Enforcement-Punkt, abgefragt werden. Es werden in Schritt 1b auch Zugriffe des Hostsystems selbst sowie der Container-Instanzen auf Betriebssystemressourcen BS wie z.B. flüchtige Speicher und Prozesse etc. erfasst. Durch die Erfassung und das Ablegen des gesamten Konfigurati- onsstatus, d.h. Hostsystemstatus, Berechtigung und der Lauf- zeitkonfiguration der gesamten Laufzeitumgebung L in der Laufzeitkonfigurationsdatenbank und der Bereitstellung dieser Daten gegenüber der Ausführungsfunktion kann dieser durch Ab- frage an die Laufzeitkonfigurationsdatenbank entscheiden, ob eine anfragende Applikation auf ein von der Ausführungsfunk- tion geschützten Service im Diensterbringersystem DE (Ba- ckendsystem) zugreifen kann oder die aktuelle Geräte- Konfiguration oder andere auf dem Hostsystem befindlichen Container-Instanzen über Privilegien verfügen, die dafür sor- gen, dass der Zugriff verhindert werden soll. Um eine Ent- scheidung treffen können, wird für eine Entscheidungsstelle PDP, die als ein Policy Definition Point ausgeprägt in eine Vorrichtung implementiert sein kann, ein entsprechendes Re- gelwerk (Policy) mit zumindest einem konfigurierbarem Zu- gangskriterium hinterlegt. Soll eine Verbindung einer Container-Instanz zugelassen wer- den, d.h. die anfragende Applikation autorisiert werden, kon- taktiert die Ausführungsfunktion in Schritt 4b zunächst die Laufzeitkonfigurationsdatenbank und fragt die aktuelle Konfi- gurationszustand des Hostsystems ab. Diese abgefragten Daten können auch lokal auf der Vorrichtung der Ausführungsfunktion für eine definierte Dauer zwischengespeichert werden. In ei- nem weiteren Schritt 5 werden vom der Ausführungsfunktion die Zugangskriterien von der Entscheidungsstelle PDP abgefragt und auf die von der Laufzeitkonfigurationsdatenbank bereitge- stellten Daten angewandt. Mit der bereitgestellten Zugangs- kriterien kann die Ausführungsfunktion in Schritt 6 als Maß- nahme entweder die Verbindung zulassen oder ablehnen und auch der anfragenden, auf dem Hostsystem betriebenen Container- Instanz die Gründe der Ablehnung mitteilen. Im Beispiel wird angenommen, dass sowohl dem darunterliegen- den Hostsystem, dem ggf. auf diesen betriebenen Agen- ten/Plugins und der Laufzeitkonfigurationsdatenbank vertraut wird. Die Laufzeitkonfigurationsdatenbank kann sowohl zyk- lisch (in zeitlichen Abständen) oder ereignisabhängig aktua- lisiert werden. Ereignisse können hierfür auf dem Gerät durchgeführte Operationen (z.B. Installation von Betriebssys- tem-Komponenten, Start und Stopp von Container-Instanzen o.ä.) sein. Zudem soll es möglich sein, dass das Dienster- bringersystem von der Laufzeitkonfigurationsdatenbank z.B. nach Unterbrechung der Verbindung zum Hostsystem eine Aktua- lisierung anfordern kann. Im Falle einer Unterbrechung zur Laufzeitkonfigurationsdaten- bank soll es möglich sein, dass Ergebnisse der Überwachungs- funktion auf dem Hostsystem temporär zwischengespeichert wer- den und diese nachträglich übertragen werden. Der Konfigura- tionszustand des Hostsystems kann von dem Hostsystem zur In- tegritätssicherung signiert werden, solange dieses einen ver- trauenswürdigen Status hat. Das darunterliegende Hostsystem kann z.B. als vertrauenswürdig angesehen werden, solange auf der Plattform keine Container-Instanzen mit besonderen Pro- zessprivilegien oder Zugriffe auf besondere Dateisysteme be- trieben werden. Bei der Aufnahme eines neuen Hostsystems soll über eine Regel hinterlegt werden, bei welchen Ereignissen der Vertrauensstatus entzogen werden kann. An die Änderung des Vertrauensstatus können auch Aktionen wie das Löschen des für die Signatur des Konfigurationszustands erforderlichen Schlüssels umfassen. Ist der Vertrauensstatus entzogen, kann dieser z.B. durch Neuinstallation des Hostsystems durch einen ausgelagerten Gesundheitsprüfung (englisch Health-Check) neu initialisiert und als gegenüber der Laufzeitkonfigurationsda- tenbank als vertrauenswürdig gekennzeichnet werden. Die Laufzeitkonfigurationsdatenbank kann die gespeicherten Konfigurationszustände bzw. Informationen über die verschie- denen Container-Instanzen klassifizieren / in Klassen eintei- len. Im einfachsten Fall können kritische Applikation, die auf einer Container-Instanz betrieben werden, z.B. aufgrund von IEC 62443 Safety Anforderungen, mit hohem Abschottungsbe- darf – von nicht kritischen Applikationen unterschieden wer- den. Verschiedene Eigenschaften von Applikationen, z.B. Kommunika- tion mit externen Netzwerkzonen, Herkunft von einer geprüften Quelle, Remote Zugriffsmöglichkeit (Fern-Zugriff) aus einem anderen Projekt oder einer Fremdfirma, das Zulassen einer eingehenden (inbound connectivity) oder nur einer ausgehenden Verbindungsmöglichkeit (outbound connectivity) können zu ei- ner solchen Klassifikation genutzt werden. Basierend darauf kann eine Regel definiert werden, welche nicht nur softwaremäßig, sondern auch fest verdrahtet ausge- staltet sein kann und die das Starten und Stoppen von Contai- ner-Instanzen in unterschiedlichen Klassen reguliert und Teil des Regelwerks in der Entscheidungsstelle PDP sein kann. Beispielsweise kann hiermit in einer Regel implementiert wer- den, dass kritische und nicht kritische Applikationen nicht gleichzeitig kommunizieren dürfen. Dies wäre auch eine Mög- lichkeit den Anforderungen von IEC 62443 zur Trennung kriti- scher und nicht-kritischer Netzwerkzonen Rechnung zu tragen. Möchte eine kritische Applikation z.B. mit dem Produktions- netz kommunizieren, dann kann dies bewirken, dass zuvor eine nichtkritische Applikation zum nächstmöglichen Zeitpunkt ge- stoppt wird, gemeinsam genutzte Ressourcen auf einen defi- nierten Ausgangszustand gesetzt werden und danach erst die kritische Applikation kommunizieren darf. Danach würde die nicht-kritische Applikation wieder hochgefahren. Dies würde das Risiko unerwünschter Wechselwirkung zwischen den kriti- schen und nichtkritischen Applikationen weitgehend verhin- dern. Damit die Ausführungsfunktion die anfragende Applikation ein- deutig zuordnen kann, ist es erforderlich, dass die Contai- ner-Instanz innerhalb der Laufzeitkonfigurationsdatenbank eindeutig identifiziert werden kann. Eine bevorzugte Registrierung an der Laufzeitkonfigurations- datenbank erfolgt über gesicherte Anmeldeverfahren wie eine zertifikatsbasierte Geräte-Authentisierung z.B. mittels OAUTH oder JSON Webtoken. Erfolgt eine Passwort-basierte Authenti- sierung an der Ausführungsfunktion, wird angenommen, dass Be- nutzername und Passwort bei der Verwendung von Container- Instanzen nicht im Instanz-Image für jede Instanz identisch hinterlegt sind, sondern diese entweder für jede Instanz oder zumindest für alle Instanzen eines Typs auf einem Gerät ein- deutig sind. Dies kann z.B. erreicht werden, indem jedes Hostsystem eigenständige Credentials (Berechtigungsnachweise) zugewiesen bekommt oder das Hostsystem vor dem Start der Con- tainer-Instanz eigenständig Zertifikate ausstellt, die von einem Geräte-Zertifikat abstammen und diese nur für die Lauf- zeit der Instanz gültig sind. Um sicherzustellen, dass die Zertifikatsschlüssel bzw. die hinterlegten Zugangsdaten nicht ausgelesen werden, wird der Vertrauensstatus des gesamten Hostsystems entzogen. Zusätzlich kann der Geräteschlüssel des Hostsystems bei einer zertifikatsbasierten Lösung auch in ei- nem Hardware Security Module (HSM) gespeichert werden, sodass verhindert wird, dass der Geräteschlüssel ausgelesen werden kann. Alternativ ist es auch möglich, dass das darunterlie- gende Hostsystem für die Container-Instanz bei einem Authen- tisierungsdienst ein für die Laufzeit gültiges Token anfor- dert und dies an die Container-Instanz übergibt. Ebenfalls besteht die Möglichkeit, dass Zugriffsdaten von der jeweili- gen Container-Instanz von einem Schlüsselverwaltungssystem (Key management system) ausgestellt werden. Hierbei wird an- genommen, dass diese ebenfalls gerätespezifisch bereitge- stellt werden und somit die Instanz dem Hostsystem zugeordnet werden kann. Immer dann, wenn eine Container-Instanz gestartet oder ge- stoppt wird, werden zu der Container-Instanz und dessen ein- deutigem Identifier auch Laufzeitkonfiguration in die Lauf- zeitkonfigurationsdatenbank geschrieben. Hierzu gehören Topo- logieinformationen wie zugewiesene Netzwerk-Bridges, lokal in die Container-Instanz eingebundenes Dateisysteme oder Pro- zessprivilegien für die Instanzen. Ebenfalls soll die Mög- lichkeit bestehen, dass Signaturinformationen der Images oder der Deployment-Informationen übertragen werden, sodass die Ausführungsfunktion beispielsweise fordern kann, dass aus- schließlich signierte Instanzen, signierte Instanzen eines definierten Herstellers oder nicht modifizierte Deployments auf dem Hostsystem betrieben werden. Bei Starten und bei jedem Communication Requests (Verbin- dungsanfrage) einer Applikation über das Netz werden die für die Zuweisung von Zugriffsrechten erforderlichen Konformi- tätskriterien durch die Ausführungsfunktion geprüft, indem dieser in Schritt 4a Anfragen an eine gegebenenfalls vorhan- dene Assetdatenbank ADB und in Schritt 4b Anfragen an die Laufzeitkonfigurationsdatenbank TDB für den gesamten Host stellt. Insbesondere wird neben der Integrität des darunter- liegenden Hostsystems (z.B. Definition bestimmter Software- stände, bestimmter Konfigurationen oder Versionen) auch über- prüft, ob andere Container-Instanzen bestimmte Konformitäts- bedingungen erfüllen. Konformitätsbedingungen können hierbei die oben beschriebenen Laufzeitparameter und Signatureigen- schaften der Images und Deployment-Informationen oder die Existenz zusätzlicher Sicherungsmaßnahmen wie z.B. die Ver- wendung einer zusätzlichen Sandbox (Laufzeitumgebung mit ab- geschottetem Bereich) oder einem zusätzlichen Tunnel für die Kommunikation sein. Abhängig von den erfüllten Kriterien wer- den die Berechtigungen vollständig erteilt oder nur in redu- ziertem oder anders modifiziertem Umfang zur Verfügung ge- stellt. Es kann als Maßnahme ebenfalls auch die Verbindungs- abfrage mit den gewünschten Privilegien abgelehnt werden. In einer erweiterten Ausführungsform kann bei der nicht- erteilten vollständigen Berechtigung seitens der Ausführungs- funktion der Überwachungsfunktion der Grund für die Ablehnung der gewünschten Berechtigungen mitgeteilt werden. Die durch die Applikation erzeugte Container-Instanz kann hierbei eine entsprechende Fehlermeldung mit Hilfe entsprechender Lognach- richten oder durch entsprechende Systemaufruf-Argumente an die Laufzeitumgebung bzw. an das darunterliegende Hostsystem übergeben. Ein in der Laufzeitumgebung hinterlegtes Plugin oder ein Agent wertet die Konformitätsanforderungen aus und kann – sofern dies in einer für das Hostsystem hinterlegte Richtline hinterlegt ist, dafür sorgen, dass die spezifischen Konformitätsanforderungen durch Maßnahmen behoben werden, in- dem die für die Konformitätsverletzung betreffenden Contai- ner-Instanzen gestoppt werden oder z.B. mit veränderten Pri- vilegien oder innerhalb einer Sandbox oder anderen Namensraum erneut gestartet werden. Sofern das Verfahren im orchestrierten (Kubernetes) Umfeld angewandt wird, ist es zudem möglich, dass der Orchestrierer die betroffene Container-Instanz, dessen Applikationsanfrage abgelehnt wurde oder die Instanzen, die die Konformitätsver- letzung ausführen auf ein anderes Gerät verlagert. Um sicher- zustellen, dass die Verbindung nicht erneut abgelehnt wird, stellt eine Orchestrierung hierbei sicher, dass die betroffe- nen Container-Instanzen nicht zusammen auf dem gleichen Host- system erneut betrieben werden. Werden während einer durch die Ausführungsfunktion autori- sierten Verbindung einer Container-Instanz auf dem Gerät wei- tere Container-Instanzen gestartet, kann sich der Konformi- tätsstatus des Hostsystems ändern. Dieser kann von der Aus- führungsfunktion entweder zyklisch durch Abfrage der Lauf- zeitkonfigurationsdatenbank überprüft werden. Alternativ kann die erneute Überprüfung ausgelöst werden, sobald die Ausfüh- rungsfunktion der Laufzeitkonfigurationsdatenbank gegenüber mitteilt, dass diese über Änderungsoperationen auf dem Host- system informiert werden möchte, wodurch eine ereignisabhän- gige Überprüfung durchgeführt werden kann. Oder die Überprü- fung der weiteren Container-Instanzen findet bei jeder Anfra- ge statt, die von der Ausführungsfunktion geprüft wird. In Figur 2 werden die wesentlichen Schritte des erfindungsge- mäßen Verfahrens in einem Ablaufdiagramm zusammengefasst. In Schritt a wird eine Laufzeitkonfigurationsdatenbank z.B. TDB bereitgestellt bzw. zur Verfügung gestellt. Mit einer Überwachungsfunktion z.B. RC wird der aktuelle Konfigurati- onszustand eines Hostsystems z.B. D erfasst und in der Lauf- zeitkonfigurationsdatenbank abgelegt. Auf dem Hostsystem kön- nen gemeinsam mehrere Container-Instanzen z.B. C1, C2 betrie- ben werden. Der Konfigurationszustand umfasst ein aktuellen Hostsystemstatus, Berechtigungen und/oder Laufzeitkonfigura- tion einer ersten Container-Instanz sowie Berechtigungen und/oder Laufzeitkonfiguration mindestens einer weiteren auf dem Hostsystem betriebenen virtualisierten Container-Instanz und/oder zumindest eine Kommunikationsbeziehungskonfiguration zwischen der ersten Container-Instanz und der mindestens ei- nen weiteren Container-Instanz und/oder deren gegenseitigen Beeinflussung durch deren jeweiligen Berechtigungen und/oder Laufzeitkonfigurationen. In Schritt b wird der aktuelle Konfigurationszustand in der Laufzeitkonfigurationsdatenbank abgefragt, wenn eine Applika- tion einen Zugang zu einem Diensterbringersystem z.B. DE an- fragt, wobei die Applikation in einer ersten Container- Instanz betriebenen wird. Dann wird der abgefragte Konfigura- tionszustandes der ersten Container-Instanz z.B. C1 durch ei- ne Ausführungsfunktion z.B. PEP anhand wenigstens eines kon- figurierbaren Zugangskriterium auf dessen Erfüllung über- prüft. In Schritt c wird die anfragende Applikation autorisiert, wenn das wenigstens eine Zugangskriterium erfüllt ist. Das Zugangskriterium kann als Teil eines Regelwerks beispielswei- se in einer Entscheidungsstelle implementiert sein. Das Re- gelwerk kann Sicherheitsrichtlinien vorhalten, die ausgewer- tet werden, um über die Anfrage der Applikation zu entschei- den. In Schritt d werden alarmierende oder ein oder mehrere Maß- nahmen eingeleitet, wenn das wenigstens eine Zugangskriterium nicht erfüllt ist. Die Maßnahme wirkt einer Zulassung eines Zugangs zum Diensterbringersystem entgegen. Es kann auch der anfragenden Applikation die Gründe der Ablehnung des ange- fragten Zugangs mitgeteilt werden. Obwohl die Erfindung im Detail durch das bevorzugte Ausfüh- rungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele einge- schränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen. Die Implementierung der vorstehend beschriebenen Prozesse oder Verfahrensabläufe kann anhand von Instruktionen erfol- gen, die auf computerlesbaren Speichermedien oder in flüchti- gen Computerspeichern (im Folgenden zusammenfassend als com- puterlesbare Speicher bezeichnet) vorliegen. Computerlesbare Speicher sind beispielsweise flüchtige Speicher wie Caches, Puffer oder RAM sowie nichtflüchtige Speicher wie Wechselda- tenträger, Festplatten, usw. Die vorstehend beschriebenen Funktionen oder Schritte können dabei in Form zumindest eines Instruktionssatzes in/auf einem computerlesbaren Speicher vorliegen. Die Funktionen oder Schritte sind dabei nicht an einen bestimmten Instruktions- satz oder an eine bestimmte Form von Instruktionssätzen oder an ein bestimmtes Speichermedium oder an einen bestimmten Prozessor oder an bestimmte Ausführungsschemata gebunden und können durch Software, Firmware, Microcode, Hardware, Prozes- soren, integrierte Schaltungen usw. im Alleinbetrieb oder in beliebiger Kombination ausgeführt werden. Dabei können ver- schiedenste Verarbeitungsstrategien zum Einsatz kommen, bei- spielsweise serielle Verarbeitung durch einen einzelnen Pro- zessor oder Multiprocessing oder Multitasking oder Parallel- verarbeitung usw. Die Instruktionen können in lokalen Speichern abgelegt sein, es ist aber auch möglich, die Instruktionen auf einem ent- fernten System abzulegen und darauf via Netzwerk zuzugreifen. Unter „rechner-/computergestützt“ bzw. „computerimplemen- tiert“ kann im Zusammenhang mit der Erfindung beispielsweise eine Implementierung des Verfahrens verstanden werden, bei dem insbesondere ein Prozessor, der Teil der (Steuerungs- /Rechen-)-vorrichtung bzw. -einheit sein kann, mindestens ei- nen Verfahrensschritt des Verfahrens ausführt. Das Verfahren kann hierbei auch in einer Rechnerwolke (Cloud) implementiert sein, die das Verfahren ausführen kann und damit Ergebnisse des Verfahrens an eine Steuerungs-/Rechen-)-vorrichtung bzw. -einheit liefern kann, die entsprechende Befehle bzw. Maßnah- men an die Vorrichtungen insbesondere der oben genannten An- ordnung richten kann. Sofern es in der nachfolgenden Beschreibung nicht anders an- gegeben ist, beziehen sich die Begriffe "abbilden", "nachbil- den", "empfangen", "anwenden", "ausgeben", "bereitstellen" und dergleichen vorzugsweise auf Handlungen und/oder Prozesse und/oder Verarbeitungsschritte, die Daten verändern und/oder erzeugen und/oder die Daten in andere Daten überführen, wobei die Daten insbesondere als physikalische Größen dargestellt oder vorliegen können. Der Begriff "Prozessor", "zentrale Signalverarbeitung", "Steuereinheit" oder "Datenauswertemittel", umfasst Verarbei- tungsmittel im weitesten Sinne, also beispielsweise Server, Universalprozessoren, Grafikprozessoren, digitale Signalpro- zessoren, anwendungsspezifische integrierte Schaltungen (ASICs), programmierbare Logikschaltungen wie FPGAs, diskrete analoge oder digitale Schaltungen und beliebige Kombinationen davon, einschließlich aller anderen dem Fachmann bekannten oder in Zukunft entwickelten Verarbeitungsmittel. Prozessoren können dabei aus einer oder mehreren Vorrichtungen bzw. Ein- richtungen bzw. Einheiten bestehen. Besteht ein Prozessor aus mehreren Vorrichtungen, können diese zur parallelen oder se- quentiellen Verarbeitung bzw. Ausführung von Instruktionen ausgelegt bzw. konfiguriert sein.