Erweiterte Integritätsüberwachung eines Containerabbildes

Die Erfindung betrifft ein Verfahren sowie ein System zu er weiterten Integritätsüberwachung eines Containerabbilds, bei dem das Containerabbild mindestens zwei Schichten, ein Basis abbild und mindestens eine Anwendungsschicht, die mindestens eine Änderungsoperation auf dem Basisabbild ausführt, ent hält.

Computerimplementierte Dienste oder Anwendungen können mit tels virtueller Container auf einer speziellen Ausführungsum gebung eines Gerätes bereitgestellt werden. Ein Gerät kann dabei beispielsweise ein Server in einer zentralen, von meh reren Nutzern gemeinsam verwendeten Serverumgebung, aber auch ein dezentral, am Rand eines Netzwerks angeordnetes Randgerät oder ein Endgerät sein, dass einem einzelnen Nutzer zugeord net ist. Dem Server oder Gerät wird dabei ein Containerabbild bereitgestellt, aus dem zur Laufzeit des Dienstes ein oder mehrere Container-Instanzen generiert werden, die die Funkti onen der Anwendung ausführen. Das Containerabbild kann bei spielsweise in einem von der Open-Container-Initiative (OCI) definierten Format aus einzelnen Schichten, sogenannten Lay- ern, aufgebaut sein. Eine erste Schichte enthält üblicher weise Ressourcen, wie beispielsweise Bibliotheken und Pro gramme oder auch ein Paketmanager und wird Basisabbild be zeichnet. Das Containerabbild umfasst des Weiteren mindestens eine Anwendungsschicht, die eine oder mehrere Änderungsopera tionen auf dem Basisabbild ausführt und dadurch die Anwendung bereitstellt.

Um die Integrität einer computerimplementierten Anwendung zu überwachen sind Container-Integritätsüberwachungssysteme be kannt, mit deren Hilfe Richtlinien für Container-Instanzen erstellt werden können, bei deren Verletzung beispielsweise eine Alarmierung ausgelöst wird, gewisse Aktionen blockiert werden oder die ganze Containerinstanz gestoppt wird. In die- sen Richtlinien können mehrere unterschiedliche erlaubte oder verbotene Aktionen definiert sein. Des Weiteren kann konfigu riert werden, welche Programme innerhalb der Containerinstanz erlaubt oder verboten sind.

US 2020/012818 Al beschreibt ein Verfahren zur Aufrechterhal tung der Integrität eines aus Schichten aufgebauten Contai nerabbilds. Integritätsregeln stellen dabei die Integrität des Containerabbilds dadurch sicher, dass ein geladenes Con tainerabbild nur aus einem vertrauensvollen Abbild zusammen gebaut oder Abbildschichten nur von vertrauensvollen Nutzern bereitgestellt werden.

US 2018/349610 Al offenbart ein Verfahren, bei dem eine Ver trauenswürdigkeit und Sicherheit einer über Software Contai ner bereitgestellten Anwendung während dem Start der Anwen dung auf einem Rechner überprüft werden.

US 2018/314846 Al offenbart ein Verfahren, bei dem jeder Gast-Laufzeitzeitumgebung eine Sicherheits-Policy zugeordnet wird. Die Gast-Laufzeitumgebung kann dabei als Virtualisie- rungscontainer ausgebildet sein, der als Prozess auf dem Gast-Betriebssystem ausgeführt wird. Objekte können im soge nannten „Namespace" des Containers als erlaubt oder einge schränkte spezifiziert werden.

Problematisch ist hierbei, dass diese Richtlinien üblicher weise vom Betreiber einer Herstellungsplattform für das Con tainerabbild in einem „Trial and Error"-Verfahren erstellt werden. Dies erfordert ein aufwendiges und vollständiges Tes ten der Anwendung. Dabei wird das in Schichten aufgebaute OCI-Format von Containerabbildern nicht unterstützt wird, so- dass Containerinstanzen, die nicht vollständig bis zur letz ten Schicht gestartet werden, nicht optimal geschützt werden können.

Es ist somit die Aufgabe der vorliegenden Erfindung, die Be reitstellung von Richtlinien für die Integritätsüberwachung effizienter und einfacher zu gestalten und insbesondere eine vollständige Integritätsüberwachung auch für schichtbasierte Containerabbilder zu ermöglichen.

Die Aufgabe wird durch die in den unabhängigen Ansprüchen be schriebenen Maßnahmen gelöst. In den Unteransprüchen sind vorteilhafte Weiterbildungen der Erfindung dargestellt.

Ein erster Aspekt der Erfindung betrifft ein Verfahren zur erweiterten Integritätsüberwachung eines Containerabbilds und daraus erzeugter Containerinstanzen, bei dem das Containerab bild mindestens zwei Schichten, ein Basisabbild und mindes tens eine Anwendungsschicht, die mindestens eine Ände rungsoperation auf dem Basisabbild ausführt, enthält, mit folgenden Schritten:

- bei einem Zusammenbauen des Containerabbilds, Zuordnen ei ner für die Schicht spezifische Integritätsregel zu dieser Schicht, für mindestens eine der Schichten des Containerab bilds,

- Bereitstellen des Containerabbilds und der zugeordneten In tegritätsregeln an einen Gastrechner, und während der Lauf zeit der Containerinstanz auf dem Gastrechner,

- Erzeugen der Containerinstanz basierend auf dem Contai nerabbild durch eine Laufzeitumgebung des Gastrechners,

- Überprüfen jeder einzelnen Schicht gegenüber der zugeordne ten Integritätsregel bei der Ausführung der Container instanz auf der Laufzeitumgebung, und

- Ausführen der Schicht, abhängig von der zugeordneten Schicht-spezifischen Integritätsregel.

Somit werden bereits beim Erstellen des Containerabbildes In tegritätsregeln definiert und der jeweiligen Schicht zugeord net. Die Integritätsregel für eine Schicht kann eine einzige Regel aber auch mehrere Regeln enthalten, die unterschiedli che Aspekte für die Schicht spezifizieren. Somit können die Integritätsrichtlinien bereits bei ihrer Erstellung von einem Entwickler oder Integrator, der die Container-basierte Anwen dung genauestens kennt, erstellt und beim Zusammenbauen des Containerabbilds, einem sogenannten Build-Prozess, integriert werden. Durch die Schichten-basierte Definition von Integri tätsregeln ist es des Weiteren möglich Integritätsüberprüfun gen so zu definieren, dass diese für die gestarteten Schich ten der jeweiligen Instanz angepasst sind. Es können somit auch Containerinstanzen, in denen nicht alle Schichten ge startet werden, in ihrer Ausführung vollständig überprüft werden.

In einer vorteilhaften Ausführungsform wird mindestens einer Basisschicht eine Basisschicht-spezifische Integritätsregel zugeordnet, wobei das Basisabbild mindestens eine Basis schicht enthält.

Somit können nicht nur die Anwendungsschichten und deren Än derungsoperationen auf Integrität überprüft werden, sondern auch das Basisabbild selbst, das wiederum aus mehreren Basis schichten aufgebaut sein kann, bezüglich Integritätsregeln überwacht werden kann.

In einer vorteilhaften Ausführungsform wird bei einem Basis abbild mit mindestens zwei Basisschichten und mindestens zwei zugeordneten Basisschicht-spezifischen Integritätsregeln, beim Zusammenbau des Containerabbildes geprüft, ob sich die Abfolge von Basisschicht-spezifischen Integritätsregeln ge genseitig ausschließen und, falls dies der Fall ist, ledig lich die in ihrer Abfolge erste oder letzte Basisschicht spezifische Integritätsregel gekennzeichnet und dem Basisbild als Ganzes zugeordnet.

Somit kann zu jeder einzelnen Basisschicht eine Integritäts regel erstellt und zugeordnet werden. Die Integritätsregel für die Basisschicht kann somit schnell und unkompliziert mo dular abhängig von der enthaltenen Basisschicht erstellt wer den. Durch das Überprüfen der Basisschicht-spezifischen In tegritätsregeln beim Zusammenbauen des Containerabbilds wird frühzeitig und insbesondere vor der Erstellung einer Contai nerinstanz ein Konflikt zwischen den Basisschicht- spezifischen Integritätsregeln erkannt und eine Lösung dafür gefunden werden.

In einer vorteilhaften Ausführungsform wird durch eine Konfi gurationseinstellung für das Zusammenbauen des Containerab bildes vorgegeben, ob die erste oder die letzte Basisschicht spezifische Integritätsregel dem Basisabbild als Ganzes zuge ordnet wird.

Eine Konfigurationseinstellung kann somit bereits beim Er stellen des Containerabbildes hinterlegt werden. Dadurch ist es möglich Integritätsregeln zu definieren, die bei bestimm ten, in nachfolgenden Schichten spezifizierten Operationen eine Integritätsverletzung erzeugen. Somit wird festgelegt, welche Integritätsregel bei einem Konflikt zwischen Integri tätsregeln gültig sein soll. Eine solche Operation ist bei spielsweise eine Installation eines entsprechenden Programmes oder ein Starten eines Prozesses oder ein Öffnen eines dezi dierten Netzwerk-Ports. Dadurch kann beispielsweise ein Ent wickler des Containerabbildes überprüfen, ob nachfolgende Schichten gemäß einer vom Hersteller des Basisabbilds vorge gebenen Richtlinie spezifiziert sind. Operationen, die unter einem bestimmten Nutzer durchgeführt werden oder auf Bereiche im Dateisystem erfolgen, können somit zu einer Integritäts verletzung führen. Der bestimmte Nutzer kann beispielsweise ein sogenannter „root" sein. Das Basisabbild wird in der Re gel von einem Basisabbild-Hersteller an den Erzeuger des Con tainerabbilds bereitgestellt, wobei der Hersteller des Basis abbildes und der Erzeuger des Containerabbildes unterschied liche Parteien sind. Insbesondere ist der Hersteller des Ba sisabbildes mit dem Hersteller der Laufzeitumgebung, auf der die containerbasierte Anwendung ausgeführt werden soll, ver bunden. Beispielsweise werden die Laufzeitumgebung und das Basisabbild vom gleichen Hersteller vertrieben oder die Bei den sind vertraglich miteinander verbunden. In einer vorteilhaften Ausführungsform werden beim Zusammen bauen des Containerabbildes die Schicht-spezifischen Integri tätsregeln in einer eigenständigen Datei angeordnet.

Bevorzugt wird eine beim Zusammenbauen für jede Schicht er mittelte Schichtkennung als Zuordnungskennung, mit der für die jeweilige Schicht hinterlegte Integritätsregel verknüpft. Insbesondere wird die Schichtkennung der Schicht der entspre chenden Schicht-spezifischen Integritätsregel zugeordnet. So mit können die Schicht-spezifischen Integritätsregeln ge trennt vom Containerabbild abgespeichert bzw. dem Gastrechner bereitgestellt werden. Dies ermöglicht es beispielsweise zwei oder mehr Sätze an Schicht-spezifischen Integritätsregeln für ein Containerabbild zu erstellen und den gesamten Satz, der dann als Datei vorliegt, flexibel dem Containerabbild zuzu ordnen.

In einer vorteilhaften alternativen Ausführungsform werden beim Zusammenbauen des Containerabbildes die Schicht spezifischen Integritätsregeln in eine Metainformation zu den Schichten des Containerabbilds angeordnet werden.

Dies ermöglicht eine enge Kopplung zwischen Schicht und Schicht-spezifischer Integritätsregel. Dadurch wird eine Ma nipulation der Schicht-spezifischen Richtlinie erschwert. Insbesondere Modifikationen an mehreren Schicht-spezifischen Integritätsregeln werden dadurch aufwendig und erschweren ei ne gezielte Manipulation.

In einer vorteilhaften Ausführungsform ist eine Art des wei teren Zusammenbaus des Containerabbilds konfigurierbar, wenn beim Zusammenbau des Containerabbilds eine Verträglichkeit zwischen der Schicht und der Schicht-spezifischen Integri tätsregel der vorherigen Schicht überprüft und eine Unver träglichkeit festgestellt wird.

Eine Unverträglichkeit wird festgestellt, wenn bei der Ver- träglichkeitsprüfung ermittelt wird, dass die Schicht nicht mit der Schicht-spezifischen Integritätsregel der vorherigen Schicht verträglich ist. So ist beispielsweise konfigurier bar, dass bei einer festgestellten Unverträglichkeit das Zu sammenbauen des Containerabbilds mit einer Fehlermeldung ab bricht. Alternativ kann bei einer festgestellten Unverträg lichkeit beispielsweise das Zusammenbauens ohne Auswertung der Integritätsregel fortgesetzt werden. Die Arten des weite ren Zusammenbaus sind nicht auf die beiden genannten Beispie le beschränkt. Die Art des Zusammenbauens kann insbesondere im Erstellungsprozess das Containerabbild konfiguriert wer den. Die Konfigurierbarkeit ist insbesondere vorteilhaft, wenn diese nur auf Produktionsumgebungen durchgesetzt werden auf Testumgebungen keine Integritätsverletzungen durchgesetzt werden, sondern nur eine Alarmierung stattfinden soll und.

In einer vorteilhaften Ausführungsform erfolgt das Überprüfen jeder einzelnen Schicht gegenüber der zugeordneten Schicht spezifischen Integritätsregel mittels einer Auswertung von Ereignis-basierten Systemaufrufen durch die Containerinstanz während der Laufzeit.

Mit der Überprüfung von Ereignis-basierten Systemaufrufen kann überprüft werden, welche Aktivität bzw. Operationen eine Containerinstanz während der Laufzeit ausführt und diese Ak tivität dann mit den hinterlegten Schicht-basierten Integri tätsregeln abgleichen.

In einer vorteilhaften Ausführungsform wird zum Überprüfen jeder einzelnen Schicht gegenüber der zugeordneten Schicht spezifischen Integritätsregel in zeitlich zyklischen Abstän den ein Hashwert über die aus dem Containerabbild erstellte Containerinstanz ermittelt und als Integritätswert einer Re ferenzdatenbank bereitgestellt und mit mindestens einem vor gegebenen Integritätswert in der Referenzdatenbank vergli chen.

Dabei werden Hashwerte über die einzelnen Dateien und Ver zeichnisse des Containerabbilds, insbesondere ein Container- Dateisystem, gebildet. Es muss für jede modifizierte oder hinzukommende Datei in einer Schicht definiert werden, für welche Schicht dieser Integritätswert gilt. Bei einer hohen Frequenz von durch die Containerinstanz generierten Ereignis basierten Systemaufrufen werden häufig nicht alle Systemauf rufe zeitnahe ausgewertet oder Systemaufrufe teilweise ver worfen. Durch das zeitlich zyklische Ermitteln von Integri tätswerten ist die Überprüfung der Integrität der Schichten unabhängig von Systemaufrufen, sodass auch bei einer hohen Frequenz von Ereignis-basierten Systemaufrufen die Integri- tätsüberwachung durchgeführt wird.

In einer vorteilhaften Ausführungsform werden die vorgegebe nen Integritätswerte und die Referenzdatenbank beim Zusammen bauen des Containerabbildes erstellt.

Dies hat den Vorteil, dass auch nicht signierte Containerab bilder zuverlässig mittels Integritätswert auf Integrität ge prüft werden können. Da die vorgegebenen Integritätswerte be reits beim Zusammenbauen des Containerabbildes erstellt wer den können Veränderung des Containerabbildes zwischen dem Zu sammenbauen und dem Ausführen auf der Laufzeitumgebung bei der Überprüfung festgestellt werden. Somit wird die Integri tät des Containerabbildes auch zwischen dem Zusammenbauen und dem Ausführen der daraus abgeleiteten Containerinstanz si chergestellt bzw. eine Manipulation kann festgestellt und da rauf reagiert werden. Daraus ergibt sich aber auch ein Vor teil für die Integritätsüberwachung für signierte Contai nerabbilder. Eine Überprüfung der Signatur des Containerab bilds ist nur möglich, solange das Containerabbild nicht aus geführt wird, da die Signatur über das nicht ausgeführte Con tainerabbilds berechnet wird und über die Laufzeit hinweg auf der Instanz Modifikationen durchgeführt werden können. Somit kann die Integrität nicht über den kompletten Lifecycle mit Hilfe von Signaturen bestimmt werden. Wenn die Integritätsre geln beim Build-Prozess mit definiert werden, ist eine durch gängige Integritätsüberwachung, insbesondere auch zur Lauf zeit der Containerinstanz, möglich. In einer vorteilhaften Ausführungsform wird die Referenzda tenbank beim Start des Containerabbilds auf der Laufzeitumge bung des Gastrechners erstellt.

Diese Variante wird bevorzugt für signierte Containerabbilder verwendet. Dabei wird die Integrität des Containerabbilds selbst durch die Signatur des Containerabbilds überprüfbar.

In dieser Variante können vorteilhafterweise umgebungsspezi fische Parameter der Laufzeitumgebung berücksichtigt werden, beispielsweise Variablen zur Laufzeit-konfigurierbare Log- Dateien.

In einer vorteilhaften Ausführungsform wird eine Basis- Referenzdatenbank für das Basisabbild vor Ausführung der min destens einen Anwendungsschicht an die Laufzeitumgebung des Gastrechners bereitgestellt und für jede nachfolgende Schicht ein Unterschiedswert zur vorhergehenden Schicht innerhalb der Basis-Referenzdatenbank ermittelt wird.

Dies ermöglicht eine vereinfachte Erstellung der Schicht basierten Integritätsregeln und insbesondere der vorgegebenen Integritätswerte. Des Weiteren können einfache Integritäts werte für unterschiedliche Basisabbilder angepasst werden.

In einer vorteilhaften Ausführungsform ist eine maximale An zahl von Systemaufrufen festlegbar, ab der von einer Überprü fung mittels der Auswertung von Ereignis-basierten Systemauf rufen zu einer Überprüfung mittels Erstellens von Hashwerten gewechselt wird.

Dies ermöglicht es insbesondere bei einer hohen Anzahl von Systemaufrufen, die oftmals mit einem fehlerhaften Bearbeiten der Systemaufrufe oder gar einem Verwerfen von Systemaufrufen verbunden ist, die Integritätsüberwachung dennoch optimiert beibehalten werden kann. Ein zweiter Aspekt der Erfindung betrifft ein System zur er weiterten Integritätsüberwachung eines Containerabbilds mit mindestens zwei Schichten und daraus erzeugter Container instanzen, umfassend eine Zusammenbau-Vorrichtung und einen Gastrechner mit einer Laufzeitumgebung, wobei die Zusammen bau-Einrichtung derart ausgebildet ist,

- bei einem Zusammenbauen des Containerabbildes, eine für die Schicht-spezifische Integritätsregel dieser Schicht zuzuord nen,

- das Containerabbild und die zugeordnete Integritätsregeln an den Gastrechner bereitzustellen und der Gastrechner derart ausgebildet ist,

- eine Containerinstanz basierend auf dem Containerabbild durch eine Laufzeitumgebung des Gastrechners zu erzeugen, während der Laufzeit der Containerinstanz auf dem Gastrech ner,

- jede einzelne Schicht gegenüber der zugeordneten Integri tätsregel bei der Ausführung der Containerinstanz auf der Laufzeitumgebung zu überprüfen und

- die Schicht abhängig von der zugeordneten Schicht spezifischen Integritätsregel auszuführen.

Das System ermöglicht es, bereits beim Erstellen bzw. Zusam menbauen des Containerabbilds Integritätsregeln aufzustellen. Dies kann insbesondere für Containerabbilder, die in einem schichtbasierten OCI-Format erstellt werden, Integritätsre geln aufzustellen.

Ein dritter Aspekt der Erfindung betrifft ein Computerpro grammprodukt, umfassend ein nicht flüchtiges computerlesbares Medium, das direkt in einem Speicher eines digitalen Compu ters ladbar ist, umfassend Programmcodeteile, die dazu geeig net sind, die Schritte des Verfahrens durchzuführen.

Sofern es in der nachfolgenden Beschreibung nicht anders an gegeben ist, beziehen sich die Begriffe „Bereitstellen, Er zeugen, „Überprüfen", „Ausführen" und dergleichen vorzugswei se auf Handlungen und/oder Prozesse und/oder Verarbeitungs- schritte, die Daten verändern und/oder erzeugen und/oder die Daten in andere Arten überführen, wobei die Daten insbesonde re als physikalische Größen dargestellt werden oder vorliegen können, beispielsweise als elektrische Impulse. Das beschrie bene System und darin enthaltenen Vorrichtungen bzw. Rechner bezeichnen elektronische Geräte mit Datenverarbeitungseigen schaften, die mindestens einen Prozessor zur Datenverarbei tung umfassen. Die genannten „Vorrichtungen", beispielsweise die Zusammenbauvorrichtung oder der Gastrechner, können Hard ware-technisch und/oder auch Software-technisch implementiert sein. Bei einer Hardware-technischen Implementierung kann die jeweilige Einheit als Vorrichtung oder als Teil einer Vor richtung, z. B. als Mikroprozessor ausbildet sein. Bei einer Software-technischen Implementierung kann die jeweilige Ein heit als Computerprogrammprodukt, als eine Funktion, als eine Routine, als ein Teil eines Programmcodes oder ausführbares Objekt ausgebildet sein.

Ein Computerprogrammprodukt, wie beispielsweise ein Computer programmmittel, kann beispielsweise als Speichermedium oder auch in Form einer herunterladbaren Datei von einem Server in einem Netzwerk bereitgestellt oder geliefert werden.

Ausführungsbeispiele des erfindungsgemäßen Verfahrens sowie des erfindungsgemäßen Systems in den Zeichnungen beispielhaft dargestellt und werden anhand der nachfolgenden Beschreibun gen näher erläutert. Es zeigen:

Figur 1 ein Ausführungsbeispiel des erfindungsgemäßen Ver fahrens als Flussdiagramm;

Figur 2 ein Beispiel einer Zuordnung zwischen einem schicht basierten Containerabbild und den zugeordneten Schicht-spezifischen Integritätsregeln in schemati scher Darstellung;

Figur 3 ein erstes Ausführungsbeispiel eines erfindungsgemä ßen Systems und der von den Systemkomponenten ausge- führten Verfahrensschritten in schematischer Dar stellung; und

Figur 4 ein zweites Ausführungsbeispiel des erfindungsgemä ßen Systems in Blockdarstellung.

Einander entsprechende Teile sind in allen Figuren mit dem gleichen Bezugszeichen versehen.

Mittels Container bereitgestellte Anwendungen werden übli cherweise als Dateisystem erstellt, beispielsweise über Soft wareprodukte wie Docker. Im nachfolgenden Ausführungsbeispiel des erfindungsgemäßen Verfahrens wird gelegentlich auf die Bereitstellung eines Containerabbildes mittels Docker als beispielhafte Bereitstellungsmöglichkeit beschrieben, aber nicht darauf beschränkt. Beliebige andere Bereitstellungs software zur Container-Virtualisierung kann ebenfalls verwen det werden.

Ein Containerabbild wird in einer Datei-basierten Form spezi fiziert und auf ein schichtbasiertes Containerabbild- Dateisystem, beispielsweise entsprechend einem standardisier ten Open-Container-Intensiv (OCI)-Format, abgebildet. Eine Befehlszeile in einer solchen Datei entspricht einer Schicht in einem Containerabbild. Die einzelnen Schritte des Verfah rens gehen von einer solchen Struktur und Erzeugung des Con tainerabbilds aus und werden nun anhand von Fig. 1 näher er läutert.

In einem Ausgangszustand SO liegt ein in einem Erstellungs prozess erzeugtes Containerabbild vor, das mindestens zwei Schichten umfasst. Die erste, unterste Schicht bildet ein Ba sisabbild. Eine oder mehrere darüber liegende Schichten, so genannte Anwendungsschichten, weisen mindestens eine Ände rungsoperation auf, die auf dem Basisabbild ausgeführt wer den. Im ersten Verfahrensschritt wird bei einem Zusammenbauen des Containerabbildes zu mindestens einer Schicht eine für die Schicht spezifische Integritätsregel zugeordnet. Das Zusam menbauen des Containerabbildes wird häufig auch als „Build- Prozess" bezeichnet. Dabei wird aus mehreren Komponenten, die beispielsweise in einer Dockerdatei spezifiziert sind, das Containerabbild zusammengefügt und gekoppelt. Eine Befehls zeile in einer Dockerdatei entspricht dabei einer Schicht im Containerabbild. Ein Ersteller der Dockerdatei kann diese In tegritätsregeln beispielsweise als Kommentare in die Docker datei einpflegen und diese somit schichtbasiert konfigurie ren. Durch die Schicht-basierte Definition der Integritätsre geln ist es möglich die Integritätsüberprüfung und - Überwachung so zu definieren, dass diese für die gestarteten Schichter der jeweiligen Containerinstanz angepasst sind.

Eine erste Schicht des Containerabbilds, das Basisabbild, enthält wiederum eine oder mehrere Basisschichten. Einer, mehreren oder allen dieser Basisschichten kann wiederum je weils eine Basisschicht-spezifische Integritätsregel zugeord net werden. Da der Hersteller des Basisabbilds häufig nicht mit dem Ersteller des Containerabbilds übereinstimmt, werden die Basisschicht-spezifischen Integritätsregeln von diesem Hersteller erzeugt und vordefiniert dem Containerabbild- Hersteller bereitgestellt. Enthält das Basisabbild zwei oder mehrere Basisschichten und mindestens zwei zugeordnete Basis schicht-spezifische Integritätsregeln, so wird beim Zusammen bauen des Containerabbildes geprüft, ob die Abfolge der Ba sisschicht-spezifischen Integritätsregeln sich gegenseitig ausschließen.

Wenn dies der Fall ist, wird lediglich die erste oder die letzte Basisschicht-spezifische Integritätsregel der Abfolge gekennzeichnet und dem Basisbild als Ganzes zugeordnet. Dies ist notwendig, da die Basisschichten beim Zusammenbauen des Containerabbilds zu einer einzigen ersten Schicht, dem Basis abbild zusammengefasst werden. Somit müssen auch die Basis schicht-spezifischen Integritätsregeln beim Bauen des Contai- nerabbilds zusammengefasst werden. Das Zuordnen der ersten oder letzten Integritätsregel wird bevorzugt über eine Konfi gurationseinstellung beim Erstellen des Containerabbilds hin terlegt und beim Zusammenbauen entsprechend ausgeführt. Dem Basisabbild als Ganzes wird somit auch lediglich eine Integ ritätsregel zugeordnet. Somit ist es möglich Integritätsre geln zu definieren, die Integritätsverletzungen durch in nachfolgenden Schichten spezifizierte Operationen erzeugen.

Diese Konfigurationseinstellung ermöglicht es, ein Regelwerk an Integritätsregeln zu erzeugen, das ohne Widersprüche über prüft werden kann. So kann eine Integritätsverletzung auftre- ten und erkannt werden, wenn beispielsweise ein vorgegebenes Programm installiert wird oder ein nicht erlaubter Prozess gestartet wird oder ein nicht erlaubter vorbestimmter Netz werk-Port von der darauffolgenden Schicht des Containerabbil des geöffnet wird. Dadurch kann zum Beispiel ein Entwickler eines Containerabbildes prüfen, ob nachfolgende Schichten ge mäß der Hersteller-Richtlinie des Basisabbilds spezifiziert sind. Operationen, die unter einem bestimmten Nutzer durchge führt werden, beispielsweise einem privilegierten, mit weit reichenden Rechten, beispielsweise sogenannten Root-Rechten ausgestatteten Nutzer oder Operationen, die auf Bereiche im Dateisystem erfolgen, können somit zu einer Integritätsver letzung führen.

Gleiches gilt auch für das gesamte Containerabbild. Ein Bei spiel:

In der Integritätsrichtlinie für die unterste Schicht ist de finiert, dass in die Datei /tmp nicht geschrieben werden darf. In Schicht 4 wird dann definiert, dass man doch in /tmp schreiben darf. Hier muss dann geregelt werden, welche Regel in diesem Fall ziehen soll, also ob die Schreibberechtigung integritätskonform ist oder nicht.

Um Integritätsüberprüfungen durchführen zu können ist es nicht ausreichend, diese ausschließlich in der Konfigurati onsdatei, d. h. der Dockerdatei, zu hinterlegen. Die Schicht- spezifischen Integritätsregeln müssen beim Zusammenbauen des Containerabbilds aus der Konfigurationsdatei mit den Integri tätsregeln verknüpft werden. Die Schicht-spezifischen Integ ritätsregeln werden dazu beispielsweise in einer eigenständi gen Datei angeordnet.

In Figur 2 ist eine solche Integritätsregeldatei 110 darge stellt. Die Integritätsregeldatei 110 enthält die Schicht spezifischen Integritätsregeln RI, R2, R3, R4. Diese sind beispielsweise über jeweils eine Zuordnungskennung ZI, Z2,

Z3, Z4 mit der jeweils entsprechenden Schicht, d. h. der Ba sisschicht LI bzw. den Anwendungsschichten L2, L3, L4 zuge ordnet. Die Zuordnungskennung kann beispielsweise eine Schichtkennung sein, die beim Zusammenbauen der Schichten für jede Schicht ermittelt und jede der Schichten eindeutig kenn zeichnet.

Alternativ zur Integritätsregeldatei kann die für eine Schicht spezifische Integritätsregel direkt in eine Meta- Information, beispielsweise im OCI-Dateisystem oder in eine neue, dazu gebildete Erweiterung der vorhandenen Metainforma tion, eingefügt werden.

Für das Basisabbild LI des Containerabbilds 100 wird dabei lediglich eine einzige Zuordnungskennung ZI zur Zuordnung zur entsprechenden Integritätsregel RI für das Basisabbild ver wendet. Die einzelnen Basisschichten Ll.l, LI.2, LI.3 werden beim Zusammenbauen des Containerabbildes zu einer einzigen Schicht verbunden, aus der die einzelnen Basisschichten nicht mehr konkret ermittelt werden können.

Beim Zusammenbau des Containerabbildes wird geprüft, ob In tegritätsverletzungen aus der Integritätsregel, die der in der Abfolge der Schichten vorhergehenden Schichten herrühren, auftreten. Im Zusammenbauprozess ist dabei konfigurierbar wie, d. h. in welcher Art, der weitere Zusammenbau des Con tainerabbilds weitergeführt wird, wenn eine Unverträglichkeit festgestellt wird. Eine solche Konfiguration kann durch den Ersteller des Containerabbilds 100 während des konkreten Zu sammenbauprozesses konfiguriert werden oder aber durch eine feste Einstellung im Zusammenbauprozess fest vorgegeben wer den. Die Art des weiteren Zusammenbaus kann dabei sein, dass das Zusammenbauen mit einem Fehler abbricht oder beispiels weise ohne eine Auswertung der Integritätsregeln fertigge stellt wird.

Sofern das Containerabbild 100 innerhalb eines kontinuierli chen Implementierungs- und Integrationsablauf (CI/CD- Pipeline) erstellt wird, ist dort ebenfalls konfigurierbar, ob bei einer Integritätsverletzung der kontinuierliche Imple mentierungs- und Integrationsprozess mit einem Fehler ange halten wird oder das Containerabbild fertig erstellt wird. Dadurch kann beispielsweise in einer Testumgebung die Art des weiteren Zusammenbaus derartig konfiguriert werden, dass kei ne Integritätsverletzungen durchgesetzt werden, sondern nur eine Alarmierung stattfindet. Andererseits kann auf einer Produktionsumgebung die Art des weiteren Zusammenbaus des Containerabbilds so konfiguriert werden, dass bei einer In tegritätsverletzung der weitere Zusammenbau des Containerab bildes 100 abgebrochen wird.

Sind das Containerabbild 100 und die Schicht-spezifischen In tegritätsregeln zugeordnet, so werden im Verfahrensschritt S2 das Containerabbild 100 und die zugeordneten Integritätsre geln 110, beispielsweise die Integritätsregeldatei oder das Containerabbild 100 mit den um die Integritätsregeln 110 er weiterten Metainformation an einen Gastrechner bereitge stellt. Im Gastrechner wird, basierend auf dem Containerab bild 100, eine Containerinstanz durch eine Laufzeitumgebung erzeugt, siehe Verfahrensschritt S3. Auf der Laufzeitumgebung wird bei der Ausführung der Containerinstanz jede einzelne Schicht LI, L2, L3, L4 gegenüber der zugeordneten Integri tätsregel RI, R2, R3, R4 überprüft, siehe Verfahrensschritt S4. Abhängig von der zugeordneten Schicht-spezifischen Integ ritätsregel RI, R2, R3, R4 und den darin definierten Vorgaben bzw. Maßnahmen wird die jeweilige Schicht LI, L2, L3, L4 aus geführt, siehe Verfahrensschritt S5.

Optional kann bereits eine Integritätsprüfung beim Start der Containerinstanz auf der Laufzeitumgebung durchgeführt wer den. Nicht jeder Schicht des Containerabbilds ist notwendi gerweise eine Integritätsregel zugeordnet. Beispielsweise könnte für das Containerabbild 100 aus Figur 2 lediglich für die erste, zweite und vierte Schicht LI, L2, L4 eine Schicht spezifische Integritätsregel RI, R3, R4 vorliegen und zuge ordnet sein. Entsprechend wird die Schicht L3 ohne eine In tegritätsprüfung ausgeführt. Auch für das Basisabbild LI muss nicht notwendigerweise eine Integritätsregel RI zugeordnet sein.

Das Überprüfen jeder einzelnen Schicht gegenüber der zugeord neten Integritätsregel wird beispielsweise mittels einer Aus wertung von Ereignis-basierten Systemaufrufen, die durch die Containerinstanz während der Laufzeit erzeugt werden, gegen über den Integritätsregeln überprüft. Das Überprüfen kann mit Hilfe von speziellen Filterprogrammen durchgeführt werden. Werden auf der Laufzeitumgebung nur signierte Containerabbil der zugelassen, kann über das Auswerten von Systemaufrufen während der gesamten Laufzeit der Containerinstanz hinweg dessen Integrität sichergestellt werden. Durch die Überprü fung der Signatur von signierten Containerabbildern kann si chergestellt werden, dass das Containerabbild als solches nicht verändert wurde. Mit der Überprüfung von Systemaufrufen kann zur Laufzeit überprüft werden, welche Aktivität eine Containerinstanz ausführt und diese Aktivität mit den hinter legten Integritätsregeln abgleichen.

Bei schneller Abfolge von Systemaufrufen, die von der Contai nerinstanz erzeugt wurden, ist nicht immer sichergestellt, dass tatsächlich alle Systemaufrufe ausgewertet und die Aus wertung zeitnahe erfolgt. Daher kann alternativ dazu die In tegritätsüberprüfung zyklisch mit Hilfe von Hashwerten, die über die einzelnen Dateien und Verzeichnisse der Container- instanz gebildet werden, ausgeführt werden. Diese Hashwerte werden in eine Referenzdatenbank abgelegt und dort mit vorge gebenen Integritätswerten verglichen. Die Überprüfung findet somit in zeitlich wiederkehrenden und bevorzugt vordefinier ten regelmäßigen oder variablen Zeitintervallen statt. Die Überprüfung kann auch durch ein Ereignis ausgelöst werden oder in zeitlich variierenden Abständen ausgeführt werden.

Der ermittelte Hashwert wird mit mindestens einem vorgegebe nen Integritätswert in der Referenzdatenbank verglichen.

Vorzugsweise ist eine maximale Anzahl von Systemaufrufen festlegbar, ab der von einer Überprüfung mittels der Auswer tung von ereignisbasierten Systemaufrufen zur Überprüfung mittels Erstellens von Integritätswerten gewechselt wird. Ein Zeitintervall für die zyklische Überprüfung ist dabei konfi gurierbar. Beispielsweise kann ein zeitliches Intervall von 60 Sekunden eingestellt werden.

Die Verwendung der Referenzdatenbank hat des Weiteren den Vorteil, dass auf der Laufzeitumgebung nicht zwingend Contai nerinstanzen signierter Containerabbilder betrieben werden müssen. Dabei wird bereits beim Zusammenbauen des Contai nerabbilds ein erster vorgegebener Hashwert und somit Integ ritätswert erzeugt und in der Referenzdatenbank gespeichert. Für jede modifizierte oder hinzukommende Datei muss definiert werden, für welche Schicht der Integritätswert gilt.

Alternativ kann die Referenzdatenbank erst beim Start der Containerinstanz auf dem Gastrechner, auf dem die Laufzeitum gebung betrieben wird, erzeugt werden. Um die Integrität der Containerinstanz zu gewährleisten ist es erforderlich, auf der Laufzeitumgebung ausschließlich signierte Containerabbil der zu verwenden. Bei der beim Start der Containerinstanz er zeugten Referenzdatenbank können umgebungsspezifische Parame ter der Laufzeitumgebung, wie beispielsweise konfigurierbare Logdateien, mitberücksichtigt werden. Bei beiden Varianten ist es ebenfalls möglich, dass eine separate Integritätsda tenbank für das Basisabbild, beispielsweise vom Hersteller des Basisabbildes, zur Verfügung gestellt wird und für die weiteren hinzukommenden Schichten lediglich ein Referenzwert zwischen dem Integritätswert der hinzukommenden Schicht und dem Basisabbild berechnet und gespeichert werden.

In Figur 3 ist ein System zur erweiterten Integritätsüberwa chung von Containerabbildern bzw. der daraus erzeugten Con tainerinstanzen und die von den einzelnen Komponenten des Systems durchgeführten Verfahrensschritte dargestellt.

Das System umfasst eine Zusammenbauvorrichtung 10, beispiels weise einen Zusammenbauserver, eine Registervorrichtung 20 sowie einen Gastrechner 30. In der Zusammenbauvorrichtung 10 wird eine Konfigurationsdatei 90, beispielsweise eine Docker datei, die die einzelnen Komponenten für die Schichten des Containerabbilds 100 enthält, übersetzt und daraus ein Con tainerabbild 100 zusammengebaut, siehe S02. Beim Zusammenbau des Containerabbilds werden in der Zusammenbauvorrichtung 10 auch die Schicht-spezifischen Integritätsregeln den entspre chenden Schichten zugeordnet. Dies entspricht dem Verfahrens schritt Sl. Die Zusammenbauvorrichtung 10 führt auch den zweiten Verfahrensschritt S2 aus und stellt das Containerab bild 100 und die zugeordneten Integritätsregeln 110 an dem Gastrechner 30 bereit.

Die Zusammenbauvorrichtung 10 übermittelt das Containerabbild 100 mit den Integritätsregeln 110 als Metainformation oder des Containerabbild 100 und die Integritätsregeln 110 in zwei unterschiedlichen Dateien an die Registervorrichtung 20, sie he S21. Der Gastrechner 30 ruft von der Registervorrichtung 20 das Containerabbild 100 und die Integritätsregeln 110 ab, siehe S22. Der Gastrechner 30 startet das Containerabbild 100 und erzeugt daraus eine Containerinstanz. Während der an schließenden Laufzeit der Containerinstanz werden die einzel nen Schichten der Containerinstanz gegenüber den zugeordneten Integritätsregeln überprüft, siehe S3 und die Schichten ab hängig von der zugeordneten, Schicht-spezifischen Integri tätsregel ausgeführt, siehe S4, S5. Die verschiedenen Phasen von der Erstellung einer Konfigurationsdatei über das Zusam- menbauen des Containerabbilds und dem Zuordnen der Integri tätsregeln bis zum Übermitteln der Containerabbildung, kann über eine kontinuierliche Bereitstellungs- und kontinuierli che Integrationsplattform, auch CI/DI-Plattform, ausgeführt werden.

Figur 4 zeigt die einzelnen Komponenten des Systems im De tail. Die Zusammenbauvorrichtung 10 ist dabei über eine Da tenkommunikationsverbindung mit der Registervorrichtung 20, die Registervorrichtung 20 wiederum mit einer Datenkommunika tionsverbindung mit dem Gastrechner 30 verbunden. Die Zusam menbauvorrichtung 10 umfasst eine Übersetzungseinheit 11, ei ne Zuordnungseinheit 12, eine Baueinheit 13 sowie eine Be reitstellungseinheit 14. Die Übersetzungseinheit 11 empfängt und prozessiert die Konfigurationsdatei. Die Zuordnungsein heit 12 erstellt Integritätsregeln für jede Schicht und ord net die spezifisch für eine Schicht erstellte Integrationsre gel der entsprechenden Schicht zu. Alternativ kann die Integ ritätsregel auch außerhalb der Zusammenbauvorrichtung 10 er stellt und vorgegebene Integritätsregeln von der Zuordnungs einheit 12 empfangen und weiterverarbeitet werden. In der Zu ordnungseinheit 12 können beispielsweise auch Integritätswer te für die einzelnen Schichten generiert und an eine Refe renzdatenbank 40 über eine Bereitstellungseinheit 14 bereit gestellt werden.

Die Zusammenbauvorrichtung 10 umfasst des Weiteren eine Bau einheit 13, die das Containerabbild zusammenbaut sowie die Bereitstellungseinheit 14, beispielsweise eine Ein- und Aus gabeschnittstelle, die derart konfiguriert ist, dass Contai nerabbild und die Integritätsregeln beispielsweise über die Registervorrichtung 20 an den Gastrechner 30 bereitzustellen.

Der Gastrechner 30 umfasst eine Erzeugungseinheit 31, die aus dem empfangenen Containerabbild die Containerinstanz erzeugt. Der Gastrechner 30 umfasst des Weiteren eine Überprüfungsein heit 32, die derart ausgebildet ist, jede einzelne Schicht gegenüber der zugeordneten Integritätsregel bei der Ausfüh rung der Containerinstanz auf der Laufzeitumgebung zu über prüfen. Die Überprüfungseinheit 32 meldet das Überprüfungser gebnis bzw. die aus der Überprüfung resultierenden Maßnahmen an eine Ausführungseinheit 33, die die Maßnahmen abhängig von der zugeordneten Schicht-spezifischen Integritätsregel bzw. dem Prüfungsergebnis ausführt.

Die Erzeugungseinheit 31, die Überprüfungseinheit 32 sowie die Ausführungseinheit 33 können in einer Einheit integriert ausgebildet sein. Die Erzeugungs-, Überprüfungs- und Ausfüh rungseinheit 31, 32, 33 können aber auch als separate eigen ständige Komponenten vorliegen und einen oder mehrere Prozes soren enthalten, auf denen die Verfahrensschritte innerhalb eines Integritätsüberwachungsprogramms ausgeführt werden.

Zusammengefasst können mit dem beschriebenen Verfahren und dem Integritätsüberwachungssystem Integritätsregeln bereits beim Stellen des Containerabbilds innerhalb des Erzeugungs prozesses, insbesondere innerhalb eines kontinuierlichen Be- reitstellungs- und Integrationsprozesses, hinterlegt werden. Schicht-basierte Integritätsregeln ermöglichen es, Container instanzen flexibel zu schützen, die lediglich aus einem Teil der im Containerabbild enthaltenen Schichten gestartet wurden und ablaufen. Des Weiteren ist es möglich zu konfigurieren, ob Integritätsüberprüfungen zur Laufzeit über die Auswertung von Systemaufrufen oder zyklisch über die Referenzdatenbank durchgeführt werden. Durch das Bereitstellen einer Referenz datenbank für Basisabbilder, kann beim Starten der Container instanz oder beim Bauen des eigentlichen Containerabbilds, lediglich die Abweichungen der Schichten vom Basisabbild in der Datenbank erfasst werden. Aktionen, die eine Integritäts verletzung verursachen, können entweder nur gemeldet oder komplett blockiert werden. Es kann überprüft werden, ob hin zugefügte Schichten konform sind zu den Richtlinien in der davor konfigurierten Schicht. Alle beschriebenen und/oder gezeichneten Merkmale können im Rahmen der Erfindung vorteilhaft miteinander kombiniert wer den. Die Erfindung ist nicht auf beschriebene Ausführungsbei spiele beschränkt.