Verfahren zum Aus führen von Workload (APP ) in einer Aus führungsumgebung und System

Die Erfindung betri f ft ein Verfahren zum Aus führen von Workload in einer Aus führungsumgebung sowie ein System mit einer zum Aus führen von Workload ausgebildeten Aus führungsumgebung .

In Aus führungsumgebungen, etwa auf Compute-Platt formen, wie Industrie-PCs oder Edge-Cloud-Compute-Servern, werden unterschiedliche und teilweise kritische Software-Komponenten ausgeführt . Insbesondere können kritische Funktionalitäten, etwa in Form von Apps und/oder Containern oder nativen Software- Komponenten, auf of fenen Compute-Platt formen realisiert sein . Allgemein können solche Apps , Container und sonstige Software-Komponenten auch als „Workload" bezeichnet werden .

Es kann j edoch nicht verhindert werden, dass kritischer Workload auf einer Compute-Platt form ausgeführt wird, die die erforderliche Vertrauenswürdigkeit nicht gewährleistet .

Es ist daher Aufgabe der Erfindung, ein verbessertes Verfahren zum Aus führen von Workload in einer Aus führungsumgebung und ein verbessertes System mit einer zum Aus führen von Workload ausgebildeten Aus führungsumgebung zu schaf fen . Insbesondere soll bei dem Verfahren und bei dem System ein Aus führen von Workload auch auf einer nicht von vornherein als vertrauenswürdig einzustufenden Aus führungsumgebung möglich sein .

Diese Aufgabe der Erfindung wird mit einem Verfahren mit den in Anspruch 1 angegebenen Merkmalen sowie mit einem System mit den in Anspruch 10 angegebenen Merkmalen gelöst . Bevorzugte Weiterbildungen der Erfindung sind in den zugehörigen Unteransprüchen, der nachfolgenden Beschreibung und der Zeichnung angegeben . Bei dem erfindungsgemäßen Verfahren zum Aus führen von Workload in einer Aus führungsumgebung wird der Workload mittels einer Zulässigkeitsliste zulässigen Workloads zum Aus führen zugelassen, wobei bei dem Verfahren eine Risikoinformation, die ein IT-Sicherheitsrisiko der Aus führungsumgebung kennzeichnet , ermittelt wird und abhängig von der ermittelten Risikoinformation die Zulässigkeitsliste zulässigen Workloads geändert wird . Besonders bevorzugt ist das Verfahren ein com- puter-implementiertes Verfahren .

Es versteht sich, dass die Zulässigkeitsliste zulässigen Workloads eine Zulässigkeitsliste von zulässigem Workload, d . h . eine Zulässigkeitsliste mit auf dieser Liste verzeichnetem zulässigen Workload, bedeutet .

Bevorzugt ist unter einem IT-Sicherheitsrisiko der Aus führungsumgebung insbesondere ein IT-Sicherheitsrisiko durch die Aus führungsumgebung für die Aus führung von Workload zu verstehen und/oder kennzeichnet zweckmäßig einen Host-Trust- Status .

Vorzugsweise wird bei dem erfindungsgemäßen Verfahren das IT- Sicherheitsrisiko der Aus führungsumgebung mittels eines softwarebasierten Integritätsprüfmoduls ermittelt . D . h . , die Integrität der Aus führungsumgebung wird bevorzugt softwarebasiert mit dem Integritätsprüfmodul geprüft und die Risikoinformation softwarebasiert anhand der geprüften Integrität ermittelt . Zweckmäßig bedeutet eine hohe Integrität ein geringes IT-Sicherheitsrisiko und umgekehrt .

Erfindungsgemäß muss also nicht von vornherein darauf vertraut werden, dass die Aus führungsumgebung vertrauenswürdig ist , sondern ein Workload wird erfindungsgemäß nur dann in der Aus führungsumgebung ausgeführt , wenn deren Vertrauenswürdigkeit ermittelt und geprüft worden ist , wenn dann eine Zu- lässigkeitsliste für zulässigen Workload abhängig von der geprüften Vertrauenswürdigkeit ausgewählt worden ist und nachfolgend der Workload in dieser Zulässigkeitsliste verzeichnet ist . Es wird also bei dem erfindungsgemäßen Verfahren vorteilhaft ein „Zero Trust"-Paradigma der Netzwerk-Security auf die Aus führung von Workload in einer Aus führungsumgebung übertragen . Folglich kann mittels des erfindungsgemäßen Verfahrens eine dem Risiko der Aus führungsumgebung und folglich eine der Vertrauenswürdigkeit der Aus führungsumgebung angepasste Zulässigkeitsliste verwendet werden . Geeigneterweise handelt es sich bei dem Workload um Software-Komponenten . Die Aus führungsumgebung ist vorzugsweise eine Compute-Platt f orm, insbesondere eine of fene Compute-Plattform . Gerade bei Ausführungsumgebungen, welche mittels of fener Compute- Plattformen gebildet sind und folglich höhere Risiken für Manipulationen oder Angri f fe beinhalten, ist mittels des erfindungsgemäßen Verfahrens vorteilhaft eine fortlaufende Anpassung der Zulässigkeitsliste an die Risikoinformation der Compute-Plattform möglich . Vorzugsweise wird bei dem erfindungsgemäßen Verfahren mit der geänderten Zulässigkeitsliste der Workload ausgeführt . Insbesondere beinhaltet der der Workload eine Steuerfunktionalität eines Fertigungs- oder Wartungsprozesses , sodass mittels des erfindungsgemäßen Verfahrens die Steuerfunktionalität ausgeführt werden kann und der Fertigungs- oder Wartungsprozess gesteuert und ausgeführt werden kann .

Bevorzugt umfasst bei dem erfindungsgemäßen Verfahren der Workload eines oder mehrere der Elemente der nachfolgend aufgeführten Liste : eine virtuelle Maschine , ein Betriebssystem- Container, insbesondere ein Linux LXC oder ein Docker- Container oder eine Container-basierte App, eine native Betriebssystem-Applikation, ein Service , insbesondere ein Unix- Dämon oder ein Windows-Service , ein Betriebssystem-Modul , vorzugsweise ein durch den Linux-Kernel dynamisch ladbares Betriebssystem-Modul .

Die vorgenannten Software-Komponenten können auf der Aus führungsumgebung zum einen selbst gespeichert , bevorzugt installiert , sein oder von einem verbundenen Netzwerkspeicher in die Aus führungsumgebung zur Aus führung geladen werden . Erfin- dungsgemäß wird eine Software-Komponente nur dann gestartet , d . h . ausgeführt und/oder in den Arbeitsspeicher geladen, wenn sie durch eine die Zulässigkeitsliste als zulässig definiert ist .

Bei dem erfindungsgemäßen Verfahren bedeutet die Risikoinformation zugleich einen Host-Trust-Status der Aus führungsumgebung . Denn j e höher das Risiko ist , das die Risikoinformation für die Aus führung angibt , umso weniger vertrauenswürdig ist die Aus führungsumgebung .

Bevorzugt wird bei dem erfindungsgemäßen Verfahren im laufenden Betrieb der Aus führungsumgebung die j eweilige Risikoinformation der Aus führungsumgebung ermittelt und davon abhängig die Zulässigkeitsliste geändert , insbesondere ausgewählt oder gebildet . In dem Fall , dass eine Zulässigkeitsliste ausgewählt wird, sind mehrere Zulässigkeitslisten vorhanden, von denen eine Zulässigkeitsliste abhängig von der Risikoinformation der Aus führungsumgebung ausgewählt wird . In dem Fall , dass die Zulässigkeitsliste gebildet wird, wird eine von der ermittelten Risikoinformation der Aus führungsumgebung abhängende Zulässigkeitsliste derart ermittelt , dass nur solcher Workload Eingang in die Zulässigkeitsliste findet , welche mit der ermittelten Risikoinformation der Aus führungsumgebung verträglich ist . So kann eine Datenbank vorgehalten werden, die für j eden Workload, d . h . für j ede Softwarekomponente , vermerkt , bei welcher Risikoinformation der Aus führungsumgebung der Workload Eingang in die Zulässigkeitsliste finden kann und bei welcher Risikoinformation nicht . Zweckmäßig umfasst die Risikoinformation einen Zahlenwert und für j eden Workload ist in der Datenbank vermerkt , ab welchem oder bis welchen Zahlenwert der Workload in die Zulässigkeitsliste aufgenommen werden kann . Auf diese Weise kann einfach eine Zulässigkeitsliste automatisiert generiert werden .

Zweckmäßig wird bei dem erfindungsgemäßen Verfahren derj enige bereits gestartete Workload oder es werden diej enigen Software-Komponenten angehalten oder beendet , wenn deren Aus füh- rung gemäß der aktualisierten Zulässigkeitsliste nicht mehr zulässig ist . Eine bereits gestartete Software-Komponente kann also davon abhängig angehalten, beendet oder auf einen anderen Host migriert werden, ob die Zulässigkeitsliste aufrechterhalten wird oder geändert worden ist .

Vorzugsweise enthält die Zulässigkeitsliste eine Berechtigungsinformation, d . h . eine Information darüber, welche Lauf zeitberechtigungen einem Workload, insbesondere einer j eweiligen Software-Komponente , gewährt werden, etwa Linux- Capabilities , Mandatory-Access-Control-Policies oder Zugri f fsberechtigung auf bestimmte Hardware-Komponenten des Compute-Servers wie insbesondere auf einen Vertrauensanker zum Speichern und Bereitstellen von kryptographischen Schlüsseln und Funktionen oder auf einen Grafikbeschleuniger oder auf einen AI-Beschleuniger .

In einer bevorzugten Weiterbildung des erfindungsgemäßen Verfahrens umfasst die Aus führungsumgebung eine Lauf zeitumgebung, insbesondere für Workload in Gestalt von Softwarekomponenten, vorzugsweise in Form von Containern und/oder Apps .

Bei dem Verfahren gemäß einer Weiterbildung der Erfindung umfasst bevorzugt die Aus führungsumgebung ein Betriebssystem und/oder mindestens ein Input-Output-Modul und/oder eine Signalverbindung und/oder einen Switch und/oder einen Router .

Bei dem erfindungsgemäßen Verfahren wird die die Risikoinformation zweckmäßig mittels der Aus führungsumgebung oder mittels einer Vorrichtung, in welcher die Aus führungsumgebung befindlich ist , oder mittels einer Software , welche in der Aus führungsumgebung läuft , ermittelt .

Die Risikoinformation der Aus führungsumgebung kann auf der Aus führungsumgebung selbst ermittelt werden, insbesondere mittels einer speziellen Software-Komponente , die insbesondere in einem „Trusted Execution Environment" , kurz als „TEE" bezeichnet , der Aus führungsumgebung ausgeführt wird, geeigne- terweise ein Intel SGX oder eine Arm-TrustZone , oder mittels eines Hardware-Erweiterungsmoduls , etwa einer Einsteckkarte wie insbesondere einer PCIe-Karte , oder mittels einer integrierten Hardware-Komponente der Aus führungsumgebung oder mittels eines Backend-/Edge-Cloud-Services . Alternativ oder zusätzlich kann die Risikoinformation der Aus führungsumgebung mittels einer mit der Aus führungsumgebung kommunikationsverbundenen Vorrichtung oder Plattform ermittelt werden .

Bei dem Verfahren ist in einer bevorzugten Weiterbildung der Erfindung die Zulässigkeitsliste eine Positivliste , d . h . es sind die zur Aus führung zugelassenen Software-Komponenten in der Zulässigkeitsliste verzeichnet .

Geeigneterweise wird bei dem erfindungsgemäßen Verfahren die Zulässigkeitsliste kryptographisch geschützt . In dieser Weiterbildung kann die Zulässigkeitsliste vorteilhaft nicht ohne Weiteres unbeabsichtigt oder infolge eines Manipulationsversuchs eines Angrei fers geändert werden . Folglich ist in dieser Weiterbildung das erfindungsgemäße Verfahren besonders sicher . Ein kryptographischer Schutz der Zulässigkeitsliste kann insbesondere mittels einer digitalen Signatur der Zulässigkeitsliste , etwa seitens eines ggf . vorhandenen Zulässig- keitslistenanpassungsmoduls , wie es unten beschrieben ist erfolgen . Auf diese Weise müssen Angrei fer, die die Zulässigkeitsliste manipulieren wollen, nicht allein die Zulässigkeitsliste manipulieren, sondern müssen auch die digitale Signatur oder das ggf . vorhandene Zulässigkeitslistenanpassungsmodul manipuliert werden . Alternativ oder zusätzlich kann die Zulässigkeitsliste mittels eines kryptographischen Schlüssels verschlüsselt vorgehalten werden, sodass die Zu- lässigkeitsliste nur bei einer gleichzeitigen Manipulation oder Kompromittierung des kryptographischen Schlüssels oder eines zum kryptographischen Schlüssel zugehörigen privaten Schlüssels erfolgen kann . Die Zulässigkeitsliste kann insbesondere mittels eines kryptographischen Prüfwerts , etwa einer kryptographischen Prüfsumme , oder mittels einer authentisie- renden Verschlüsselung geschützt sein . Die Zulässigkeitsliste liegt zweckmäßig in Form eines sogenannten „Veri fiable Credentials" oder einer „Veri fiable Presentation" vor . Alternativ oder zusätzlich kann die Zulässigkeitsliste in einer verteilten Datenbank, insbesondere in einem Distributed Ledger oder einer Blockchain, abgelegt sein oder es kann ein Prüfwert der Zulässigkeitsliste in dem Distributed Ledger oder in der Blockchain hinterlegt sein .

Alternativ oder zusätzlich ist die Zulässigkeitsliste mittels eines kryptographisch geschützten Kommunikationskanals geschützt , vorzugsweise mittels TLS und/oder HTTPS .

Beim erfindungsgemäßen Verfahren kann vorzugsweise eine erste Version der Zulässigkeitsliste beim Gerätehochlauf , insbesondere beim Booten, der Aus führungsumgebung bestimmt werden . Dazu kann die Zulässigkeitsliste insbesondere von einem nicht flüchtigen Speicher oder von einem Server geladen werden .

Im laufenden Betrieb der Aus führungsumgebung wird die Zuläs- sigkeitsliste bevorzugt wiederholt aktualisiert , d . h . das erfindungsgemäße Verfahren wird bevorzugt wiederholt ausgeführt . Dies kann insbesondere zeitgesteuert , vorzugsweise in gleichbleibenden zeitlichen Abständen, oder alternativ und ebenfalls bevorzugt bei bestimmten Ereignissen erfolgen, insbesondere bei einer Änderung der Konfiguration oder einer Änderung installierter Software , bei einer Installation eines Patches oder bei einem Anmelden oder Abmelden eines Nutzers , insbesondere eines Administrators oder privilegierten Nutzers , etwa eines Nutzers mit Root-Privilegien . Bei einem Ausbleiben einer Aktualisierung oder einem Ausbleiben einer Gül- tigkeitsbestätigung der Zulässigkeitsliste über einen festgelegten Zeitraum kann optional und vorteilhaft eine lokal gespeicherte Ersatz-Zulässigkeitsliste vorgesehen sein .

Bevorzugt kann bei dem erfindungsgemäßen Verfahren zusätzlich zur ermittelten Risikoinformation der Aus führungsumgebung eine Risikoinformation von weiteren mit der Aus führungsumgebung kommunikationsverbundenen Komponenten ermittelt und bei der Bildung der Zulässigkeitsliste der Aus führungsumgebung berücksichtigt werden . Die kommunikativ verbundenen Komponenten können insbesondere Ein-/Ausgabe-Module sein, über die eine in der Aus führungsumgebung aus führbare Steuerungs-Applikation auf physikalische Sensoren und/oder Aktuatoren direkt oder mittels eines Datennetzwerks , zweckmäßig mittels Ethernet TSN, mittels 5G-Mobil funks , HART , Profinet , OPC UA, zugrei fen kann .

Das erfindungsgemäße System mit einer Aus führungsumgebung ist zum Aus führen von Workload in der Aus führungsumgebung ausgebildet . Bei dem erfindungsgemäßen System ist eine Zulässigkeitsliste zulässigen Workloads vorhanden und das System ist zur Aus führung von Workload gemäß der Zulässigkeitsliste ausgebildet . Zusätzlich weist das erfindungsgemäße System ein Risikoermittlungsmodul zum Ermitteln einer Risikoinformation, kennzeichnend ein IT-Sicherheitsrisiko der Aus führungsumgebung, sowie ein Zulässigkeitslistenanpassungsmodul , das ausgebildet ist , die Zulässigkeitsliste zulässigen Workloads abhängig von der Risikoinformation zu ändern, auf .

Das erfindungsgemäße System bildet zweckmäßig eine einstückige oder einteilige oder einstückig oder einteilig handhabbare Vorrichtung .

Besonders bevorzugt ist das erfindungsgemäße System zur, insbesondere wiederholten oder fortlaufenden, Aus führung eines erfindungsgemäßen Verfahrens wie zuvor beschrieben ausgebildet . Das erfindungsgemäße System weist dabei die entsprechenden Vorteile , wie sie bereits zum erfindungsgemäßen Verfahren beschrieben und erläutert sind, auf .

Bevorzugt wird das erfindungsgemäße Verfahren wie oben beschrieben mit einem erfindungsgemäßen System wie vorhergehend beschrieben ausgeführt . Nachfolgend wird die Erfindung anhand eines in der Zeichnung dargestellten Aus führungsbeispiels näher erläutert . Es zeigen :

Fig . 1 ein Aus führungsbeispiel eines erfindungsgemäßen Systems zum Aus führen von Workload in einer Aus führungsumgebung zur Aus führung eines erfindungsgemäßen Verfahrens zum Aus führen von Workload in dieser Aus führungsumgebung schematisch in einer Prinzipski z ze sowie

Fig . 2 den Ablauf des erfindungsgemäßen Verfahrens schematisch in einem Ablaufdiagramm .

Bei dem in Fig . 1 gezeigten erfindungsgemäßen Automatisierungssystem weist eine of fene Compute-Platt f orm CS eine Laufzeitumgebung APPRTE auf , in welcher mehrere Apps APP, im dargestellten Aus führungsbeispiel Linux-Container oder virtuelle Maschinen, ausgeführt werden .

Die of fene Compute-Platt form CS weist zudem ein Betriebssystem OS sowie einige Hardware-Komponenten, im dargestellten Aus führungsbeispiel einen Prozessor CPU, einen Arbeitsspeicher RAM, einen Festplattenspeicher SSD, eine Netzwerkschnittstelle NWI F, einen Hardware Trust Anchor TPM, einen Grafikbeschleuniger GPU und einen AI-Beschleuniger I FE auf .

Eine der Apps APP realisiert beispielsweise eine Steuergerä- te-Funktionalität in Gestalt eines virtuellen speicherprogrammierbaren Bausteines , welche mittels eines Steuernetzwerks CN und mittels Input-Output-Modulen IOM auf Sensoren S und Aktuatoren A zugrei ft . Eine App APP kann nur dann ausgeführt , d . h . gestartet und in den Arbeitsspeicher RAM geladen, werden, wenn sie gemäß einer in der Aus führungsumgebung gespeicherten Sof twarekomponenten-Whitelist APPWL zulässig ist . Die Aus führungsumgebung wird dabei mittels der Lauf zeitumgebung APPRTE realisiert . Die App-Whitelist APPWL wird im laufenden Betrieb wiederholt abhängig von einer Risikoinfor- mation, die ein IT-Sicherheits-Risiko der Lauf zeitumgebung APPRTE angibt , aktualisiert . Die Risikoinformation gibt bei einem geringen IT-Sicherheitsrisiko zugleich eine hohe Vertrauenswürdigkeit der Lauf zeitumgebung APPRTE an . Umgekehrt gibt ein hohes IT-Sicherheits-Risiko eine geringe Vertrauenswürdigkeit der Lauf zeitumgebung APPRTE an . Insofern ist die Risikoinformation äquivalent mit einer Trust-Status- Information der Lauf zeitumgebung APPRTE .

Zusätzlich zur Risikoinformation der Lauf zeitumgebung APPRTE kann bei dem erfindungsgemäßen Automatisierungssystem eine Risikoinformation der IO-Module IOM und eine Risikoinformation der Sensoren S , sowie eine Risikoinformation der Aktuatoren A und/oder des Steuernetzwerks CN oder einzelner Netzwerkkomponenten des Steuernetzwerks CN, beispielsweise eines Switchs und/oder eines Routers und/oder einer Verkabelung und/oder eines WLAN-Access-Points und/oder einer 5G- Mobil funk-Basisstations berücksichtigt werden . Denn auch die weiteren vorgenannten Elemente gehören, zusätzlich zur Laufzeitumgebung APPRTE , zur Aus führungsumgebung der of fenen Com- pute-Platt f orm CS .

Die vorgenannten Risikoinformationen werden bei dem erfindungsgemäßen Automatisierungssystem fortlaufend ermittelt und abhängig von den Risikoinformationen wird die Sof twarekompo- nenten-Whitelist APPWL j eweils angepasst .

Dies geschieht bei der Compute-Platt f orm CS wie folgt : Mittels eines softwarebasierten Integritätsprüfmoduls HIC wird die Integrität der Compute-Platt form CS geprüft und die Risikoinformation ermittelt . Eine hohe Integrität bedeutet ein geringes IT-Sicherheitsrisiko und umgekehrt . Abhängig von der ermittelten Risikoinformation wird bei der Compute-Platt form CS die Sof twarekomponenten-Whitelist APPWL mittels eines Whi- telistanpassungsmoduls AWA angepasst . Ein Anwendungslauncher AL, der eine App APP wie vorgenannt zu starten beabsichtigt , prüft zunächst mittels einer Anfrage OK? an ein Prüfmodul AWC, ob die App APP in der Sof twarekomponenten-Whitelist APPWL als für die Aus führung in der Lauf zeitumgebung APPRTE zulässig verzeichnet ist . Das Prüfmodul AWC übermittelt die Antwort Y/N zurück an den Anwendungslauncher AL . I st die App APP in der Sof twarekomponenten-Whitelist APPWL enthalten, so wird die App APP vom Anwendungslauncher AL gestartet .

Andere kritische Apps APP, die nur abhängig vom Trust-Status des Hosts ausgeführt werden, d . h . durch die j eweils entsprechend angepasste Sof tware-Komponenten-Whitelist zugelassen werden, sind z . B . eine Verschlüsselungs-App zum Verschlüsseln oder Entschlüsseln von Daten oder einer Netzwerkübertragung, eine App zum Onboarding oder Provisionieren anderer Geräte , oder eine App zum Anlernen eines AI -Modells .

In Fig . 2 ist das Verfahren in einem Ablauf diagramm noch einmal kompakt dargestellt :

In einem Initiierungsschritt STAR wird das Verfahren angestoßen . Dieser Initiierungsschritt STAR kann beispielsweise regelmäßig in gleichbleibenden zeitlichen Abständen oder bedarfsangepasst , etwa bei Änderungen der Aus führungsumgebung oder bei Änderungen der Vorrichtung, in welcher die Aus führungsumgebung implementiert ist , erfolgen .

In einem Ermittlungsschritt DETTRU wird eine Risikoinformation der Aus führungsumgebung ermittelt , die das IT- Sicherheitsrisiko der Aus führungsumgebung quanti fi ziert , im dargestellten Aus führungsbeispiel mittels des Integritätsprüfmoduls HIC .

Abhängig von dieser Risikoinformation wird die zur Risikoinformation zugehörige Sof twarekomponenten-Whitelist APPWL von zulässigem Workload, im dargestellten Aus führungsbeispiel von zulässigen Applikationen APP, welche in der Lauf zeitumgebung APPRTE ausgeführt werden dürfen, ausgewählt . Dazu bildet die Risikoinformation im dargestellten Aus führungsbeispiel eine Risikomaß zahl , welche bei einem hohen Zahlenwert der Risikomaß zahl ein großes Risiko und bei einem kleinen Zahlenwert ein geringes Risiko angibt . Der Wertebereich der Werte , die die Risikomaß zahl annehmen kann, ist in Werteintervalle eingeteilt . Jedem Werteintervall ist eine bestimmte Softwarekom- ponenten-Whitelist APPWL zugeordnet , die somit leicht anhand der Risikomaß zahl bestimmt werden kann . Sämtliche Software- komponenten-Whitelists APPWL der unterschiedlichen Werteintervalle unterscheiden sich voneinander . Je höher die Risikomaß zahlen eines Werteintervalls sind, umso weniger Einträge weist die Sof twarekomponenten-Whitelist auf . Mit steigender Risikomaß zahl werden j eweils noch bestehende Einträge von Sof twarekomponenten-Whitelists APPWL des j eweils in ansteigender Richtung vorhergehenden Werteintervalls ausgenommen . Mittels dieser Zuordnungsvorschri ft wird nun anhand der Risikomaß zahl in einem Bestimmungsschritt DETWL die zugeordnete Sof twarekomponenten-Whitelist APPWL bestimmt .

Bei dem dargestellten Aus führungsbeispiel sind sämtliche Sof twarekomponenten-Whitelists APPWL kryptographisch geschützt und seitens eines Anwenders der Compute-Platt f orm CS zusätzlich mittels einer digitalen Signatur signiert .

Mittels der so bestimmten Sof twarekomponenten-Whitelist APPWL kann nun auf eingehende Anfragen RECREQ zur Aus führung eines Workloads adäquat reagiert werden : Bei j eder Anfrage RECREQ wird der j eweils zur Aus führung angefragte Workload mit der mittels des Bestimmungsschritts DETWL bestimmten Softwarekom- ponenten-Whitelist APPWL abgeglichen und es wird in einem Prüfschritt ADMIS geprüft , ob der angefragte Workload in der Sof twarekomponenten-Whitelist APPWL mit einem Eintrag als zulässig verzeichnet ist . Wird dies bestätigt j , so wird der angefragte Workload in einem Aus führungsschritt EXEC mittels des Anwendungslaunchers AL ausgeführt . I st der angefragte Workload mit keinem Eintrag in der Sof twarekomponenten- Whitelist APPWL als zulässig verzeichnet , so endet der Prüfschritt ADMIS mit einer Versagung n der Aus führung und das Verfahren endet mit einem Beendigungsschritt END, ohne dass der Aus führungsschritt EXEC unternommen wird . Im dargestellten Aus führungsbeispiel prüft der Anwendungs- launcher AL zusätzlich, ob die Sof twarekomponenten-Whitelist APPWL den geforderten kryptographischen Schutz aufweist und ob die digitale Signatur der Sof twarekomponenten-Whitelist gültig ist .

Es versteht sich, dass in weiteren, nicht eigens dargestellten Aus führungsbeispielen keine Sof twarekomponenten-Whitelist APPWL in der Art einer Positivliste zulässigen Workloads vor- gesehen sein muss , sondern es kann alternativ eine Blacklist von Ausnahmen von zulässigem Workload vorgesehen sein, welche abhängig von der Risikoinformation angepasst wird .