DE102021127237A1

DE102021127237A1 - Messbehälter

Info

Publication number: DE102021127237A1
Application number: DE102021127237.8A
Authority: DE
Inventors: Francisco Plinio Oliveira Silveira; Nigel John Edwards; Ludovic Emmanuel Paul Noel JACQUIN; Guilherme De Campos Magalhaes; Leandro Augusto Penna Dos Santos; Rodrigo Jose Da Rosa Antunes
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-12-07
Filing date: 2021-10-20
Publication date: 2022-06-09
Also published as: US20240126883A1; CN114661540A; US11874926B2; US20220179959A1

Abstract

Ein Prozess beinhaltet in einem Computersystem das Erfassen einer ersten Messung, die einem Software-Container entspricht. Das Erfassen der Messung beinhaltet, dass ein Hardware-Prozessor des Computersystems eine gegebene Schicht einer Vielzahl von Schichten einer geschichteten Dateisystemstruktur misst, die dem Software-Container entspricht. Die gegebene Schicht umfasst eine Vielzahl von Dateien, und die erste Messung umfasst eine Messung der Vielzahl von Dateien. Der Prozess beinhaltet die Speicherung der ersten Messung in einem sicheren Speicher des Computersystems. Ein Inhalt des sicheren Speichers wird verwendet, um die Integrität des Software-Containers zu überprüfen.

Description

HINTERGRUND
Eine Computerplattform (z. B. ein Server) kann einem Sicherheitsangriff ausgesetzt sein, bei dem eine externe Einheit versucht, auf Informationen zuzugreifen, die auf der Computerplattform gespeichert sind, oder Komponenten der Computerplattform zu beschädigen. Um solche Sicherheitsangriffe zu verhindern oder zumindest einzudämmen, kann die Computerplattform über verschiedene Mechanismen zur Zugangsbeschränkung verfügen, wie Firewalls, Passwörter, Schlüssel usw. Darüber hinaus können die Messungen der Computerplattform analysiert werden, um Sicherheitsangriffe zu erkennen und zu entschärfen. Zu diesem Zweck kann die Computerplattform ihre Softwarekomponenten regelmäßig messen und die Messungen protokollieren. Die Messprotokolle können zusammen mit einem überprüfbaren Nachweis der Authentizität der Messprotokolle zur Analyse an einen entfernten Prüfer oder eine andere Stelle gesendet werden.
Figurenliste

1 ist ein schematisches Diagramm eines Computernetzwerks, das einen Agenten zur Messung von Container-Images und Container-Instanziierungen gemäß einer Beispielimplementierung enthält.
2 zeigt eine Illustration des Agenten, der eine oder mehrere Schichten eines Containerbildes gemäß einer Beispielimplementierung misst.
3 zeigt, wie der Agent Metadaten misst, die Informationen über das Containerbild darstellen, gemäß einer Beispielimplementierung.
4 zeigt, wie der Agent eine oder mehrere Schichten des Overlay-Dateisystems eines Containers gemäß einer Beispielimplementierung misst.
5 zeigt, wie der Agent Metadaten misst, die Informationen über einen instanziierten Container darstellen, gemäß einer Beispielimplementierung.
6 zeigt eine Zeitleiste von containerbezogenen Messungen und ihren entsprechenden Auslösern über einen beispielhaften Lebenszyklus eines Containers gemäß einer Beispielimplementierung.
7 ist ein Flussdiagramm, das einen Prozess zur Erfassung und Speicherung einer Messung, die einem Software-Container entspricht, gemäß einer Beispielimplementierung darstellt.
8 ist eine Illustration eines nicht-transitorischen maschinenlesbaren Speichermediums, das Anweisungen speichert, um eine Maschine zu veranlassen, Schichten eines Containerbildes zu messen, ein mit einem Container verbundenes Overlay-Dateisystem zu messen und die Messungen in einem sicheren Speicher gemäß einer Beispielimplementierung zu speichern.
9 ist ein schematisches Diagramm eines Systems, das einen Prozessor enthält, um Schichten eines oberen Verzeichnisses und eines unteren Verzeichnisses eines Overlay-Dateisystems zu messen, das einem Container entspricht, und die Messungen in einem sicheren Speicher gemäß einer Beispielimplementierung zu speichern.

AUSFÜHRLICHE BESCHREIBUNG
Eine Computerplattform kann von Zeit zu Zeit Integritätsmessungen (hier auch „Messungen“ genannt) ihrer Softwarekomponenten (z. B. Treiber, ein Betriebssystem, einen Bootloader, virtuelle Maschinen, Container usw.) durchführen. In diesem Zusammenhang bezieht sich eine „Integritätsmessung“ (oder „Messung“) einer Softwarekomponente auf Daten, die Beweise darstellen, die analysiert werden können, um die Integrität der Softwarekomponente zu bewerten, d. h. auf der Grundlage der Daten zu bestimmen, ob die Softwarekomponente kompromittiert wurde oder nicht. Im Allgemeinen können protokollierte Integritätsmessungen analysiert und mit Basisreferenzen (z. B. Signaturen, Hashes, Werten usw.) verglichen werden, um zu bewerten, ob die Computerplattform als vertrauenswürdig gilt, um festzustellen, ob die Computerplattform einem Sicherheitsangriff ausgesetzt war, um Sicherheitsschwachstellen zu ermitteln, um Softwarekomponenten zu identifizieren, die kompromittiert wurden, usw.
Eine Integritätsmessung einer Softwarekomponente kann viele verschiedene Formen annehmen. Eine Integritätsmessung kann beispielsweise ein Klartext-Metadatenwert sein, der ein Merkmal einer Softwarekomponente darstellt; ein Tupel von Metadatenwerten, die verschiedene Merkmale einer Softwarekomponente darstellen; ein Hash-Wert, der einen Fingerabdruck einer Datei darstellt, auf die die Softwarekomponente zugreift; ein Hash-Wert, der einen Fingerabdruck einer ausführbaren Datei der Softwarekomponente und der Eingaben in die ausführbare Datei darstellt; ein Hash-Wert, der einen Fingerabdruck einer bestimmten Abfolge von Dateien darstellt, auf die die Softwarekomponente zugreift, und so weiter.
Eine vertrauenswürdige Datenverarbeitungsbasis (TCB) der Computerplattform kann die Integritätsmessungen der Plattform vornehmen und protokollieren. Eine „vertrauenswürdige Datenverarbeitungsbasis“ bezieht sich hier auf eine Reihe von Hardware-, Firmware- und/oder Softwarekomponenten der Computerplattform, die den Kern der Sicherheit der Plattform bilden. Mit anderen Worten, die TCB kann inhärent vertrauenswürdige Software, Hardware oder eine Kombination davon sein.
Bei der Fernbescheinigung handelt es sich um einen Prozess, der es einer Computerplattform ermöglicht, einer entfernten Prüfstelle (z. B. einem Server) zu beweisen, dass die Computerplattform vertrauenswürdig ist. Genauer gesagt kann eine entfernte Prüfstelle die Computerplattform mit einer Bescheinigungsanforderung herausfordern, und als Antwort auf die Bescheinigungsanforderung kann die Computerplattform Integritätsmessungsprotokolle an die entfernte Prüfstelle senden, zusammen mit einem Nachweis (z. B. einer signierten Zusammenfassung von Mess-Hashes), dass die Integritätsmessungsprotokolle authentisch sind. Nachdem die Authentizität der Integritätsmessungsprotokolle überprüft wurde, kann die Fernüberprüfungsstelle oder eine andere Stelle die Integritätsmessungsprotokolle analysieren, um mögliche Sicherheitsbedenken für die Computerplattform zu bewerten, und, falls die Computerplattform betroffen ist, entsprechende Abhilfemaßnahmen für die Computerplattform empfehlen und/oder bereitstellen.
Die TCB der Computerplattform kann Integritätsmessungen der Computerplattform als Reaktion auf eine Reihe verschiedener Ereignisse vornehmen, wie z. B. das Hochfahren oder Booten der Computerplattform, eine Bescheinigungsanforderung oder -aufforderung, das Starten einer Softwarekomponente, den Zugriff auf eine Datei und so weiter. Gemäß Beispielimplementierungen kann die Computerplattform ein oder mehrere Protokolle von Integritätsmessungen in einem nichtflüchtigen Speicher der Computerplattform speichern; und zum Zweck des Nachweises der Authentizität der Protokolle kann die Computerplattform aus den Messprotokollen abgeleitete Hashes in einem sicheren, vertrauenswürdigen Speicher der Computerplattform speichern, z. B. im Speicher des Plattformkonfigurationsregisters (PCR) in einem vertrauenswürdigen Plattformmodul (TPM). Als Reaktion auf eine Bestätigungsanforderung von einer entfernten Prüfstelle kann die Computerplattform die Integritätsmessprotokolle bereitstellen und eine authentifizierte Zusammenfassung der im PCR-Speicher gespeicherten Hashes liefern, um zu beweisen, dass die Integritätsmessprotokolle authentisch sind.
Gemäß den hier beschriebenen Beispielimplementierungen kann die Computerplattform als Reaktion auf bestimmte auslösende Ereignisse Integritätsmessungen an einem Softwarecontainer der Computerplattform durchführen. In diesem Zusammenhang bezieht sich ein „Container“ (hier auch „instanziierter Container“, „Containerinstanz“ oder „Softwarecontainer“ genannt) im Allgemeinen auf eine virtuelle Laufzeitumgebung für eine oder mehrere Anwendungen und/oder Anwendungsmodule, und diese virtuelle Laufzeitumgebung ist so aufgebaut, dass sie eine Schnittstelle zu einem Betriebssystemkern bildet. Ein Container für eine bestimmte Anwendung kann beispielsweise den ausführbaren Code für die Anwendung und ihre Abhängigkeiten, wie Systemtools, Bibliotheken, Konfigurationsdateien, ausführbare Dateien und Binärdateien für die Anwendung, enthalten. In Übereinstimmung mit Beispielimplementierungen enthält der Container eine Schnittstelle zur Einbindung des Betriebssystemkerns, aber nicht den Betriebssystemkern. So kann eine bestimmte Computerplattform beispielsweise mehrere Container enthalten, die sich einen Betriebssystemkern über entsprechende Betriebssystem-Kernel-Mount-Schnittstellen teilen. Docker-Container und rkt-Container sind Beispiele für Software-Container.
Der Container ist eine Laufzeiteinheit, die über ein entsprechendes Overlay-Dateisystem verfügt. Wie weiter unten beschrieben, hat das Overlay-Dateisystem eine geschichtete Dateisystemstruktur, die untere Schichten, die einem Containerbild entsprechen, und eine obere Schicht, die als Arbeitsbereich für das Dateisystem dient, umfasst. Ein instanziierter Container wird zur Ladezeit aus dem Container-Image erstellt, und mehrere instanziierte Container können aus demselben Container-Image erstellt werden.
Das Container-Abbild bildet unveränderliche Schichten des Overlay-Dateisystems des Containers. Die „unveränderliche“ Natur des Container-Abbilds bedeutet hier, dass das Container-Abbild und die entsprechenden unteren Schichten des aus dem Container-Abbild gebildeten Overlay-Dateisystems schreibgeschützt sein sollen (d. h. nicht verändert werden sollen). Das Container-Abbild enthält Verzeichnisse, Dateien, ausführbare Dateien, Bibliotheken usw. Eine Basisschicht des Container-Abbilds enthält ein Root-Dateisystem (d. h. das Root-Dateiverzeichnis und Dateien) und eine Grundkonfiguration für das Root-Dateisystem (z. B. den Einstiegspunkt des Root-Dateisystems, Umgebungsvariablen usw.). Das Container-Image kann auch eine oder mehrere Schichten (so genannte „Zwischenschichten“) oberhalb der Basisschicht enthalten. Zusammen bilden die Schichten des Container-Abbilds ein mehrschichtiges Dateisystem (hier als „Container-Abbild-Dateisystem“ bezeichnet).
Gemäß Beispielimplementierungen ist das Overlay-Dateisystem des Containers ein Unions-Dateisystem, das die Überlagerung von Dateien und Verzeichnissen verschiedener Dateisysteme zu einem einzigen kohärenten Dateisystem ermöglicht. Genauer gesagt enthält das Overlay-Dateisystem des Containers ein unteres Verzeichnis, das aus dem Container-Image-Dateisystem gebildet wird. Das untere Verzeichnis ist schreibgeschützt, was mit der Unveränderbarkeit des Container-Images vereinbar ist. Das Overlay-Dateisystem des Containers umfasst auch ein oberes Verzeichnis, das eine Containerschicht enthält, in der Dateien gelesen und geschrieben werden können.
Aufgrund des Unions-Dateisystems werden in der Regel Dateien in den Ebenen, die dieselben Pfade haben, zusammengeführt, wobei die Dateiversionen der obersten Ebene die Ansichten der Dateien steuern. Bei einem Copy-on-Write-Vorgang kann beispielsweise eine Datei aus dem unteren Verzeichnis gelesen, geändert und dann in der geänderten Form in das obere Verzeichnis geschrieben werden; die geänderte Datei wird durch die Container-Einhängung angezeigt, obwohl die Datei im unteren Verzeichnis nicht geändert wurde. Als weiteres Beispiel kann eine Datei, die im unteren Verzeichnis nicht existiert, erstellt und im oberen Verzeichnis gespeichert werden; und als weiteres Beispiel kann eine Datei des oberen Verzeichnisses gelöscht werden, obwohl die Datei im unteren Verzeichnis vorhanden sein kann.
Instanziierte Container können sich Container-Image-Schichten teilen, was sowohl unter dem Gesichtspunkt der Wiederverwendung häufig verwendeter Image-Schichten als auch der Einsparung von Speicherressourcen vorteilhaft sein kann. Beispielsweise kann eine Container-Image-Basisschicht einer bestimmten Datenbankverwaltungsanwendung entsprechen, z. B. einer bestimmten Structured Query Language (SQL)-Datenbankverwaltungsanwendung. Ein Benutzer kann zum Beispiel einen Container erstellen, der die Grundfunktionen der SQL-Datenbankanwendung aufweist, aber mit bestimmten statistischen Werkzeugen weiter angepasst ist. Der Benutzer kann beispielsweise eine Container-Build-Engine oder eine Container-Engine verwenden, um eine Container-Build-Datei zu erstellen, in der die Basisebene der SQL-Datenbankverwaltungsanwendung als übergeordnete Basisebene des Container-Images angegeben ist und in der eine weitere Ebene für das Container-Image angegeben ist, die einem bestimmten Statistikpaket entspricht. Der Container, der die SQL-Datenbankanwendung mit dem Statistikpaket enthält, kann z. B. an einen anderen Container gebunden werden, der dieselbe Basisschicht für einen Nur-Lese-Zugriff enthält, so dass die Wiederverwendung der Basisschicht keine zusätzlichen Speicherressourcen verbraucht.
Containermessungen können sowohl zur Ladezeit als auch zur Laufzeit durchgeführt werden. Eine Möglichkeit, die Integrität eines Containers zu messen, ist die Messung des gesamten Containerabbilds zur Ladezeit durch Berechnung eines Hashwerts, der das gesamte Containerabbild repräsentiert. Aufgrund der unveränderlichen Natur des Containerabbilds sollte der berechnete Hashwert nicht von einem erwarteten Hashwert für das Containerabbild abweichen.
In diesem Zusammenhang wird ein „Hash“ (hier auch als „Hash-Wert“ bezeichnet) durch die Anwendung einer kryptografischen Hash-Funktion auf einen Wert (z. B. eine Eingabe, wie ein Bild) erzeugt. Eine „kryptografische Hash-Funktion“ kann eine Funktion sein, die durch die Ausführung von maschinenlesbaren Anweisungen durch einen Prozessor (z. B. eine oder mehrere Zentraleinheiten (CPUs), einen oder mehrere CPU-Verarbeitungskerne usw.) bereitgestellt wird. Die kryptografische Hash-Funktion kann eine Eingabe erhalten, und die kryptografische Hash-Funktion kann dann eine hexadezimale Zeichenfolge erzeugen, die der Eingabe entspricht. Die Eingabe kann z. B. eine Datenkette enthalten (z. B. die Datenstruktur im Speicher, die durch eine Anfangsspeicheradresse und eine Endspeicheradresse gekennzeichnet ist). In einem solchen Beispiel gibt die kryptografische Hash-Funktion auf der Grundlage der Datenkette eine hexadezimale Zeichenfolge aus. Außerdem kann jede winzige Änderung der Eingabe die ausgegebene hexadezimale Zeichenfolge verändern. In einem anderen Beispiel kann die kryptografische Hash-Funktion eine sichere Hash-Funktion (SHA), eine von den Federal Information Processing Standards (FIPS) genehmigte Hash-Funktion, eine vom National Institute of Standards and Technology (NIST) genehmigte Hash-Funktion oder eine andere kryptografische Hash-Funktion sein. In einigen Beispielen kann anstelle eines hexadezimalen Formats ein anderes Format für die Zeichenfolge verwendet werden.
Die Vermessung eines Containers durch Berechnung eines Hashes über das gesamte Container-Image kann sowohl vom Standpunkt der Verarbeitungsressourcen als auch der Speicherressourcen ineffizient sein. So können sich mehrere Container eine Basisschicht und möglicherweise Zwischenschichten teilen, so dass die Berechnung von Hashes über die Gesamtheit der Containerabbilder unnötige Hash-Verarbeitungen nach sich ziehen kann.
Gemäß den hier beschriebenen Beispielimplementierungen führt ein Agent einer Computerplattform schichtenorientierte Integritätsmessungen eines Containers durch. In diesem Zusammenhang bezieht sich der Agent, der eine oder mehrere „schichtenorientierte Container-Integritätsmessungen“ durchführt, darauf, dass er eine oder mehrere Integritätsmessungen für eine bestimmte Schicht eines Container-Images (zur Ladezeit) oder eine bestimmte Schicht des Overlay-Dateisystems eines Containers (zur Laufzeit) bestimmt.
Als spezifischeres Beispiel für die schichtenorientierten Container-Integritätsmessungen kann der Agent gemäß einigen Implementierungen einen Hash für jede einzelne Datei einer Schicht berechnen, und die resultierenden Hashes entsprechen einem Satz von Messungen für die Schicht. Als weiteres Beispiel kann der Agent in Übereinstimmung mit einigen Implementierungen Hashes für Gruppen von Dateien (z. B. Hashes für verschiedene Unterverzeichnisse) berechnen, und diese Hashes entsprechen einer Reihe von Messungen für die Gruppe von Dateien (z. B. bestimmte Verzeichnisse). Schichtenorientierte Container-Integritätsmessungen für einzelne Dateien oder Dateigruppen können besonders vorteilhaft sein, um Dateimanipulationen zu erkennen. Gemäß weiteren Implementierungen kann der Agent, wenn das Ziel nicht die Erkennung von Dateimanipulationen ist, einen einzelnen Hash-Wert berechnen, der als Messwert für die gesamte Schicht dient.
Gemäß den Beispielimplementierungen kann der Agent mehrere Schichten des Containerbildes messen. So kann der Agent beispielsweise einen oder mehrere Hashes (je nachdem, ob Dateimanipulationen erkannt werden sollen) für die Basisschicht und für jede Zwischenschicht des Containerbildes berechnen.
Da die Schichten des Container-Abbilds unveränderlich sind, sollten die Messungen den erwarteten Werten entsprechen. In ähnlicher Weise kann der Agent auch eine oder mehrere Schichten des Overlay-Dateisystems des instanziierten Containers messen. Die Zwischen- und Basisschichten des Dateisystems des instanziierten Containers sollten den erwarteten Werten entsprechen, da diese Schichten unveränderlich sind. Der Agent kann in Übereinstimmung mit Beispielimplementierungen die obere Containerschicht des Overlay-Dateisystems messen. Obwohl die Container-Schicht von Natur aus dynamisch ist, kann der Agent bei der Messung der Container-Schicht einzelne Datei- und/oder Gruppenmessungen für die Container-Schicht erzeugen, wodurch bestimmte Dateien und/oder Verzeichnisse bei der Analyse der Messungen der Container-Schicht analysiert oder ignoriert werden können.
Der Agent kann in Übereinstimmung mit Beispielimplementierungen andere Integritätsmessungen als schichtenorientierte Integritätsmessungen vornehmen. In einigen Implementierungen kann der Agent beispielsweise Metadaten von Containerabbildern lesen, um entsprechende Messungen vorzunehmen, Metadaten des instanziierten Container-Dateisystems lesen, um entsprechende Messungen vorzunehmen, Dateien messen, auf die während der Laufzeit des Containers zugegriffen wird, und so weiter.
Wie hierin weiter beschrieben, kann der Agent in Übereinstimmung mit Beispielimplementierungen die Integritätsmessungen als Reaktion auf bestimmte containerbezogene Ereignisse durchführen, wie z. B. Container-Startanfragen, Dateizugriffsanfragen, Container-Erfassungsanfragen, Bescheinigungsanfragen und so weiter. Wie ebenfalls hierin weiter beschrieben, protokolliert oder zeichnet der Agent in Übereinstimmung mit Beispielimplementierungen die Integritätsmessungen auf, um ein oder mehrere Worklog-Integritätsprotokolle zu erstellen; und der Agent speichert Hashes, die die protokollierten Integritätsmessungen in einem sicheren Speicher eines Sicherheitsmoduls der Computerplattform repräsentieren, so dass ein entfernter Überprüfer eine authentifizierte Zusammenfassung der Hashes (bereitgestellt durch das Sicherheitsmodul) verwenden kann, um zu überprüfen, dass das/die Workload-Integritätsprotokoll(e) vertrauenswürdig sind.
Bezug nehmend auf 1, als spezifischeres Beispiel, kann ein Computernetzwerk 100 in Übereinstimmung mit einigen Implementierungen eine oder mehrere Computerplattformen 110 umfassen; und, wie in 1 dargestellt, kann eine bestimmte Computerplattform 110 eine oder mehrere Container-Instanziierungen oder „Container 120“ ausführen. Gemäß Beispielimplementierungen kann die Computerplattform 110 ein beliebiges prozessorbasiertes Gerät sein, wie z. B. ein Server, ein Client, ein Thin Client, ein Desktop, ein tragbarer Computer, ein Laptop, ein Tablet-Computer, ein Notebook, ein Smartphone, ein tragbarer Computer und so weiter.
Der Container 120 kann mit einem „Knoten“ verbunden sein, der sich auf eine Einheit von Verarbeitungsressourcen bezieht, die zur Ausführung des Containers 120 ausreicht. Der Knoten kann ein tatsächlicher oder physischer Knoten sein, z. B. ein Knoten, der aus der Computerplattform 110 oder einer Partition davon gebildet wird; oder, gemäß anderen Beispielimplementierungen, kann ein bestimmter Knoten ein virtueller Knoten sein, z. B. eine virtuelle Maschine, die auf der physischen Computerplattform 1 10.
Die Computerplattform 110 kann eine beliebige Anzahl verschiedener Architekturen aufweisen. Bei der in 1 dargestellten Beispielarchitektur umfasst die Computerplattform 110 einen oder mehrere Prozessoren 124 (z. B. eine oder mehrere zentrale Verarbeitungseinheiten (CPUs), einen oder mehrere CPU-Verarbeitungskerne usw.). Darüber hinaus kann die Computerplattform 110 über andere zugehörige Hardware verfügen, wie z. B. einen Speicher 128, eine Netzwerkschnittstelle 146, ein Sicherheitsmodul, wie z. B. ein vertrauenswürdiges Plattformmodul (TPM) 150, Massenspeichergeräte 142, Eingabe-/Ausgabegeräte und so weiter.
Bei dem Speicher 128 handelt es sich im Allgemeinen um nicht transitorische Speichermedien der Computerplattform 110. Der Speicher 128 kann aus Halbleiter-Speichervorrichtungen, Memristor-basierten Speichervorrichtungen, magnetischen Speichervorrichtungen, Phasenwechsel-Speichervorrichtungen, einer Kombination von Vorrichtungen aus einer oder mehreren dieser Speichertechnologien usw. bestehen. Darüber hinaus kann der Speicher 128 eine Sammlung von Speichern aus flüchtigen und nichtflüchtigen Speichervorrichtungen darstellen.
In Übereinstimmung mit Beispielimplementierungen speichert der Speicher 128 Daten, die ein oder mehrere Workload-Integritätsprotokolle 137 darstellen. Gemäß einigen Implementierungen ist ein Workload-Integritätsprotokoll 137 einem bestimmten Container 120 zugeordnet und enthält Einträge; und jeder Eintrag des Workload-Integritätsprotokolls 137 entspricht einer anderen Integritätsmessung für den Container 120 und kann zusätzlich zur Speicherung von Daten, die die Integritätsmessung darstellen, Daten enthalten, die eines oder mehrere der folgenden Elemente darstellen: eine Kennung für ein Ereignis, das mit der Integritätsmessung verbunden ist; einen Zeitstempel; eine Kennung für einen Typ oder eine Kategorie der Integritätsmessung; und so weiter. In Übereinstimmung mit weiteren Beispielimplementierungen kann ein Workload-Integritätsprotokoll 137 Integritätsmessungen für mehrere Container 120 enthalten. Darüber hinaus kann ein bestimmter Eintrag des Workload-Integritätsprotokolls 137 in Übereinstimmung mit weiteren Beispielimplementierungen mehrere Messungen eines Containers 120 speichern. Unabhängig von der jeweiligen Organisation der protokollierten Integritätsmessungen können im Allgemeinen Integritätsmessungen zur Ladezeit und zur Laufzeit für die Container protokolliert und im Speicher 128 gespeichert werden.
Wie in 1 dargestellt, kann der Speicher 128 zusätzlich zu dem/den Arbeitslast-Integritätsprotokoll(en) 137 auch andere Daten 136 und maschinenausführbare Anweisungen 132 speichern. Ein oder mehrere Prozessoren 124 können die maschinenausführbaren Anweisungen 132 ausführen, um eine oder mehrere Softwarekomponenten zu bilden, die hier erörtert werden, wie z. B. eine Container-Engine 160, einen Container 120, ein Betriebssystem 125 und einen Container-Messagenten 164 (im Folgenden „der Agent 164“ genannt).
Bei der in 1 dargestellten Beispielimplementierung umfasst das Computernetzwerk 100 einen oder mehrere Fernüberprüfer 195, die mit den Computerplattformen 110 über die Netzwerkstruktur 180 kommunizieren können, um Bescheinigungsanforderungen an die Computerplattformen 110 zu stellen. Als Teil der Bescheinigung kann die Computerplattform 110, wenn sie von einer entfernten Prüfstelle 195 dazu aufgefordert wird, in Übereinstimmung mit Beispielimplementierungen das Workload-Integritätsprotokoll 137 zusammen mit einer authentifizierten Zusammenfassung von Hashes 153 als Beweis für die Authentizität der Integritätsmessungen im Workload-Integritätsprotokoll 137 vorlegen.
Im Allgemeinen kann die Netzwerkstruktur 180 Komponenten enthalten und Protokolle verwenden, die mit einem oder mehreren Typen von Kommunikationsnetzwerken verbunden sind, wie (als Beispiele) Fibre-Channel-Netzwerke, iSCSI-Netzwerke, ATA-over-Ethernet-Netzwerke (AoE), HyperSCSI-Netzwerke, Gen-Z-Fabrics, dedizierte Managementnetzwerke, lokale Netzwerke (LANs), Weitverkehrsnetzwerke (WANs), globale Netzwerke (z. B. das Internet), drahtlose Netzwerke oder eine beliebige Kombination davon.
In Übereinstimmung mit Beispielimplementierungen ist der Agent 164 so konstruiert, dass er Integritätsmessungen zur Ladezeit und zur Laufzeit des Containers vornimmt, die Integritätsmessungen in einem oder mehreren Workload-Integritätsprotokollen 137 protokolliert und Hashes 153 speichert, die die Integritätsmessungen in einem sicheren Speicher der Computerplattform 110 darstellen, z. B. in einem Plattformkonfigurationsregister (PCR)-Speicher 151. Wie oben erwähnt, kann eine signierte Zusammenfassung der Hashes 153 von einer entfernten Prüfstelle 195 verwendet werden, um zu beweisen, dass die protokollierten Integritätsmessungen authentisch sind (d. h., um zu beweisen, dass die protokollierten Integritätsmessungen nicht manipuliert oder anderweitig beeinträchtigt wurden).
In der Beispielimplementierung von 1 ist der PCR-Speicher 151 ein vertrauenswürdiger, sicherer Speicher, der Teil des TPM 150 ist. Es sei darauf hingewiesen, dass das TPM 150 ein Beispiel für ein vertrauenswürdiges Sicherheitsmodul ist. Die Computerplattform 110 kann gemäß den vielen möglichen Implementierungen eine beliebige Anzahl von verschiedenen vertrauenswürdigen Sicherheitsmodulen verwenden. Abhängig von der jeweiligen Implementierung kann das Sicherheitsmodul ein hardwarebasiertes Sicherheitsmodul sein, wie z. B. ein TPM; oder, in Übereinstimmung mit weiteren Implementierungen, kann das Sicherheitsmodul ein virtuelles Sicherheitsmodul sein, wie z. B. ein virtuelles TPM (vTPM), das über Software implementiert ist. Unabhängig davon, ob das Sicherheitsmodul in Hardware, Firmware oder Software implementiert ist, verfügt das Sicherheitsmodul über einen sicheren Speicher zur Speicherung von Hashes, die Messprotokolle darstellen.
In Übereinstimmung mit Beispielen, in denen das Sicherheitsmodul in Hardware implementiert ist, kann das Modul ein integrierter Schaltkreis (oder „Chip“) sein, der sich auf der Hauptplatine der Computerplattform 110 befindet und von den Prozessoren 124 der Computerplattform 110 getrennt sein kann. Das Sicherheitsmodul ist in der Regel fälschungssicher und wurde gemäß Industriestandards entwickelt, um Sicherheitsfunktionen bereitzustellen und gleichzeitig Manipulationen und bösartiger Software zu widerstehen. Darüber hinaus kann das Sicherheitsmodul gemäß Beispielimplementierungen einen kryptografischen Prozessor enthalten (z. B. einen speziellen Mikroprozessor oder Mikroprozessorkern zur Durchführung kryptografischer Operationen), der gemäß Industriestandards entwickelt wurde, um Sicherheitsfunktionen bereitzustellen und gleichzeitig Manipulationen und bösartiger Software zu widerstehen.
Wie in 1 dargestellt, kann das Sicherheitsmodul bei einigen Implementierungen ein TPM sein, das von Anbietern wie Infineon Technologies, Nuvoton und STMicroelectronics im Handel erhältlich ist. Bei anderen Beispielen kann ein Sicherheitsmodul ein Firmware-basierter Sicherheits-Coprozessor sein, wie z. B. ein TPM, das in ARM Trustzone implementiert ist, das von ARM Ltd. aus Cambridge, UK, erhältlich ist, oder Intel SGX, das von Intel aus Santa Clara, CA, erhältlich ist.
Der PCR-Speicher 151 stellt den Speicherbereich eines oder mehrerer Plattformkonfigurationsregister (PCRs) des TPM 150 dar. Ein bestimmtes PCR kann beispielsweise einem Workload-Integritätsprotokoll 137 entsprechen und einen Hash speichern, der einem aktuellen Zustand des Workload-Integritätsprotokolls 137 entsprechen 153sollte und auch der Reihenfolge entspricht, in der die protokollierten Integritätsmessungen dem Workload-Integritätsprotokoll 137 hinzugefügt wurden. In Übereinstimmung mit Beispielimplementierungen protokolliert der Agent 164 eine oder mehrere Integritätsmessungen im Workload-Integritätsprotokoll 137 und erweitert dann den PCR-Speicher 151. In diesem Zusammenhang bezieht sich der Begriff „Erweiterung des PCR-Speichers“ im Allgemeinen auf die Änderung des Inhalts des PCR-Speichers 151, so dass der geänderte Inhalt sowohl die letzte(n) Messung(en) als auch ein Hauptbuch der Messungen darstellt, die zu der/den letzten Messung(en) führen.
In Übereinstimmung mit Beispielimplementierungen kann der Agent 164 den PCR-Speicher 151 für eine neue Integritätsmessung durch die Verwendung eines „PCR-Erweiterungsbefehls“ erweitern. Die Ausführung des PCR-Erweiterungsbefehls bewirkt, dass ein Hash-Wert auf der Grundlage des aktuellen Inhalts des PCR und der neuen Integritätsmessung(en) berechnet wird, und dieser berechnete Hash-Wert wird dann im PCR-Speicher 151 anstelle des aktuellen Inhalts gespeichert. Als solcher kann der Hash-Wert von einer entfernten Prüfstelle 195 zur Authentifizierung des Workload-Integritätsprotokolls 137 verwendet werden, da der Hash-Wert für die aktuelle Version des Workload-Integritätsprotokolls 137 und die Reihenfolge, in der das Workload-Integritätsprotokoll 137 geändert wurde, um zur aktuellen Version zu gelangen, eindeutig ist. Gemäß Beispielimplementierungen kann das TPM 150 als Reaktion auf eine Bescheinigungsanforderung von einer entfernten Prüfstelle 195 den PCR-Speicherinhalt signieren, um einen authentifizierten Prüfwert zu bilden, der zusammen mit den Daten, die die aktuelle Version des Workload-Integritätsprotokolls 137 darstellen, an die Prüfstelle 195 gesendet wird.
Der Container 120 aus 1 stellt einen instanziierten Container dar, der einem Container-Image entspricht, das durch eine Build-Datei spezifiziert werden kann. Die Build-Datei kann eine oder mehrere Schichten des Bildes bezeichnen, die von anderen Containern gemeinsam genutzt werden. In Übereinstimmung mit einigen Implementierungen kann die Container-Engine 160 zur Ladezeit einen bestimmten Container 120 auf der Grundlage seiner entsprechenden Build-Datei in Reaktion auf eine Mitteilung von einem Container-Orchestrator 190 starten oder instanziieren. Auf diese Weise kann der Container-Orchestrator 190 einen oder mehrere Container 120 auf einem oder mehreren Knoten starten, um eine entsprechende Gruppe oder einen Cluster von Knoten zum Zweck der Durchführung einer Aktivität zu bilden, die vom Benutzer über den Container-Orchestrator 190 eingerichtet wurde.
Wie hierin beschrieben, nimmt der Agent 164 in Übereinstimmung mit Beispielimplementierungen Integritätsmessungen 174 zur Ladezeit und zur Laufzeit (hier auch „Messungen 174“ genannt) für einen gegebenen Container 120 vor; speichert die Integritätsmessungen 174 in einem Workload-Integritätsprotokoll 137; und in Übereinstimmung mit Beispielimplementierungen kommuniziert der Agent 164 für jede Integritätsmessung 174 mit dem TPM 150 (wie durch die Referenznummer 176 dargestellt), um den PCR-Speicher 151 entsprechend zu erweitern. Die Integritätsmessungen zur „Ladezeit“ beziehen sich auf Messungen des Container-Images, bevor der Container 120 instanziiert wird, und die Integritätsmessungen zur „Laufzeit“ beziehen sich auf Messungen des Overlay-Dateisystems des instanziierten Containers.
1 zeigt ein Beispiel für containerbezogene Daten oder Informationen, die vom Agenten 164 gemessen werden können, um entsprechende Integritätsmessungen 174 in Übereinstimmung mit Beispielimplementierungen bereitzustellen: Containerbildschichten 166; Containerschichten 168 des Overlay-Dateisystems des instanziierten Containers; Container-Metadaten 170 (d.h.
Metadaten, die Merkmale des instanziierten Containers 120 beschreiben); und Containerbild-Metadaten 172 (d.h. Metadaten, die Merkmale des Containerbildes beschreiben).
Der Agent 164 kann als Reaktion auf ein Ereignis, das dem Start oder der Instanziierung eines Containers 120 entspricht, eine Integritätsmessung der Ladezeit vornehmen. Beispielsweise kann sich der Agent 164 in Übereinstimmung mit Beispielimplementierungen in die Inbetriebnahme eines Containers 120 „einklinken“, um eine oder mehrere Lastzeit-Integritätsmessungen durchzuführen, bevor der Container 120 instanziiert wird, und um den PCR-Speicher 151 auf der Grundlage der Integritätsmessung(en) 174 zu erweitern. In diesem Zusammenhang bezieht sich das „Einklinken“ in die Inbetriebnahme auf den Agenten 164, der in die Inbetriebnahme des Containers 120 eingreift, um die Inbetriebnahme anzuhalten, was es dem Agenten 164 ermöglicht, eine Reihe von messungsbezogenen Aktionen durchzuführen, bevor der Agent 164 die Anhaltung aufhebt und die Inbetriebnahme des Containers 120 ermöglicht. Die Einbindung in die Inbetriebnahme des Behälters 120 kann auf verschiedene Weise erfolgen, entsprechend den vielen möglichen Implementierungen. Zum Beispiel kann der Agent 164 ein registriertes Plug-in der Container-Engine 160 oder des Container-Orchestrators 190 sein.
Im Allgemeinen wird jeder instanziierte Container 120 aus einem entsprechenden unveränderlichen Container-Image aufgebaut, das Container-Image-Schichten 166 enthält. Auf diese Weise enthält das Containerbild eine Basisbildschicht und möglicherweise eine oder mehrere obere Zwischenschichten. Darüber hinaus verfügt jeder instanziierte Container 120 über ein Overlay-Dateisystem, das mehrere Containerschichten 168 enthält: untere unveränderliche Schichten, die dem Containerbild entsprechen und ein unteres Verzeichnis des Overlay-Dateisystems bilden, und eine obere Containerschicht, die ein oberes Verzeichnis des Overlay-Dateisystems bildet und dem Lese-/Schreibarbeitsbereich für den Container 120 entspricht.
Um von der Effizienz der gemeinsamen Nutzung von Containerbildebenen zu profitieren, kann der Agent 164, in Übereinstimmung mit Beispielimplementierungen eine Containerbildebene 166 als Reaktion auf die Instanziierung eines bestimmten Containers 120 messen und dann die Messung für ein anderes Containerbild (entsprechend einer anderen Instanziierung des Containers 120) wiederverwenden, das die Ebene 166 gemeinsam nutzt. In Übereinstimmung mit Beispielimplementierungen kann der Agent 164 mehrere Messungen für eine bestimmte Containerbildschicht 166 bestimmen. Beispielsweise kann der Agent 164 Hashes für entsprechende einzelne Dateien oder entsprechende Gruppen von Dateien der Containerbildschicht 166 bestimmen.
In Übereinstimmung mit weiteren Beispielimplementierungen kann der Agent 164 eine einzelne Messung (z. B. einen einzelnen Hash) für die gesamte Container-Bildebene 166 bestimmen. Zum Beispiel kann der Agent 164 in Übereinstimmung mit einigen Implementierungen Hashes für die einzelnen Dateien bestimmen und dann einen einzelnen Hash (d. h. die Messung) für die Container-Bildebene 166 über die Verkettung der Datei-Hashes bestimmen. Ein Vorteil eines einzigen Hash-Werts für die Ebenenmessung ist, dass Speicherplatz im Workload-Integritätsprotokoll 137 gespart wird. Ein Vorteil mehrerer Hash-Werte als Messungen der Container-Image-Schicht 166 besteht darin, dass eine feinere Granularität bereitgestellt wird, die eine spätere Analyse der Messung ermöglicht, um eine bestimmte Datei oder Dateigruppe zu identifizieren, die kompromittiert wurde. Abhängig von der jeweiligen Implementierung kann der Agent 164 Messungen für eine einzelne Container-Bildebene 166 (z. B. die Basisebene) oder Messungen für jede von mehreren Bildebenen 166 (z. B. Messungen für jede der Basisebene und jede von bestimmten Zwischenebenen des Container-Bildes oder Messungen für jede einzelne Ebene 166 des Container-Bildes) ermitteln.
Der Agent 164 kann auch andere als schichtenorientierte Messungen der Ladezeit vornehmen. Zum Beispiel können die Ladezeitmessungen eine Messung der Containerbild-Metadaten 172 beinhalten. Im Allgemeinen stellen die Containerbild-Metadaten 172 Merkmale oder Attribute des Containerbildes dar. Der Agent 164 kann die Container-Image-Metadaten 172 von einer oder mehreren Quellen lesen, z. B. von der Container-Engine 160, dem Container-Orchestrator 190, dem Betriebssystem 125 oder einer anderen Einheit. In Übereinstimmung mit einigen Implementierungen kann eine Messung der Container-Image-Metadaten 172 darin bestehen, dass der Agent 164 die Metadaten 172 aus einer oder mehreren Quellen liest und dann ein Tupel von Einträgen (d. h. einen Eintrag pro Metadatenkategorie) erstellt, das die entsprechende Messung bildet. Eine entfernte Prüfstelle 195 kann zum Beispiel Metadatenwerte mit Referenzwerten abgleichen oder Richtlinien anwenden, um relativ komplexe Entscheidungen über die in der Messung enthaltenen Metadatenwerte zu treffen.
Die Laufzeitmessungen können die Messung einer oder mehrerer Schichten 168 des Overlay-Dateisystems des instanziierten Containers umfassen. Das obere Verzeichnis des Containers (d. h. die Containerschicht) ist dynamisch, da es das Arbeitsverzeichnis der Anwendung ist, das während des Lebenszyklus des Containers 120 vielen Lese- und Schreibvorgängen unterworfen sein kann. In Übereinstimmung mit einigen Implementierungen kann der Agent 164 aufgrund der dynamischen Natur der Containerschicht Hash-Werte für einzelne Dateien der Containerschicht bestimmen, und diese Hash-Werte können entsprechende Messungen für die Containerschicht bilden. Die Messung einzelner Dateien ermöglicht der Fernüberprüfungsstelle 195 die flexible Anwendung von Richtlinien, wie z. B. das Ignorieren von Dateien oder Verzeichnissen (z. B. Protokoll- oder Cache-Verzeichnisse), das Überprüfen bestimmter Dateien und/oder Verzeichnisse (z. B. bestimmter ausführbarer Dateien) usw.
In Übereinstimmung mit einigen Implementierungen können die Laufzeitmessungen Messungen einer oder mehrerer Schichten des unteren Verzeichnisses des Overlay-Dateisystems des instanziierten Containers umfassen (d. h. der unveränderlichen, von Container-Images abgeleiteten Schichten unterhalb der Container-Schicht). Abhängig von der jeweiligen Implementierung kann der Agent 164 für eine bestimmte Schicht des unteren Verzeichnisses Messungen für einzelne Dateien oder eine Messung für die gesamte Schicht ermitteln. Darüber hinaus kann der Agent 164 je nach Implementierung Messwerte für die Basisebene des unteren Verzeichnisses, Messwerte für ausgewählte Ebenen des unteren Verzeichnisses oder Messwerte für jede von mehreren Ebenen des unteren Verzeichnisses ermitteln.
Der Agent 164 kann auch andere als schichtenorientierte Messungen des instanziierten Containers 120 vornehmen. In Übereinstimmung mit Beispielimplementierungen können die Laufzeitintegritätsmessungen beispielsweise Integritätsmessungen von Metadaten umfassen, die Merkmale oder Attribute des instanziierten Containers 120 darstellen. Solche Metadatenmessungen können später von einer entfernten Prüfstelle 195 (durch Anwendung von Wertevergleichen und Richtlinien) untersucht werden, um beispielsweise festzustellen, ob der Container 120 die erwartete Anzahl und Reihenfolge von Schichten aufweist, ob sich der Container 120 wie erwartet verhält und so weiter.
2 ist eine Illustration 200, die zeigt, wie der Agent 164 eine oder mehrere Ladezeitmessungen 220 eines Containerbildes 202 in Übereinstimmung mit einigen Implementierungen vornimmt. In diesem Beispiel umfasst das Containerbild 202 eine Basisschicht 166 sowie eine oder mehrere obere Schichten 166. Die Schichten 166 sind unveränderlich und als solche sollten Hashes der Schichten 166 sowie Hashes, die durch Kombination von Hashes, die von einzelnen Schichten 166 abgeleitet wurden, erzeugt werden, Referenzhashes entsprechen. Wie oben erwähnt, kann die Messung 220 in Übereinstimmung mit einigen Implementierungen ein Hash-Wert für eine bestimmte Schicht 166, ein Hash-Wert für eine bestimmte Gruppe von Schichten 166, ein Hash-Wert für alle Schichten 166 usw. sein. Darüber hinaus kann ein Hash-Wert für eine bestimmte Ebene 166 auf der Grundlage des Binärwertes der gesamten Ebene 166, auf der Grundlage von Hash-Werten für einzelne Dateien der Ebene 166, auf der Grundlage von Hash-Werten für Gruppen von Dateien der Ebene usw. abgeleitet werden.
3 ist eine Illustration 300 des Agenten 164, der eine Messung 312 der Containerbild-Metadaten 172 vornimmt, gemäß einer Beispielimplementierung. Die Messung 312 kann ein Tupel von Einträgen sein, die einem oder mehreren Einträgen der Containerbild-Metadaten 172 entsprechen. 3 zeigt drei Beispiele für Containerbild-Metadaten 172: Bildmanifest-Metadaten 312, Vertrauens-Metadaten 308 und Eintrittspunkt-Metadaten 304. Die Messung 312 kann beispielsweise ein Tupel aus allen drei Einträgen 304, 308 und 312 sein; ein Tupel aus anderen oder zusätzlichen Einträgen der Containerbild-Metadaten 172 als den Einträgen 304, 308, 312; und so weiter. Bei den in 3 dargestellten Beispielen für Containerbild-Metadaten 172 können die Einstiegspunkt-Metadaten 304 beispielsweise einen Standardbefehl darstellen, der ausgeführt wird, wenn eine Container-Instanziierung 120 beginnt oder startet. Die Vertrauens-Metadaten 308 können zum Beispiel eine Signatur und/oder ein Zertifikat darstellen, die mit dem Container-Image verbunden sind, wobei ein bestimmter Mechanismus wie Docker Content Trust oder Docker Notary verwendet wird. Im Allgemeinen ermöglichen die Vertrauens-Metadaten 304 die Überprüfung sowohl der Integrität als auch des Herausgebers aller von einer Registrierung über einen beliebigen Kanal empfangenen Daten.
Die Bildmanifest-Metadaten 312 können zum Beispiel Informationen über das Container-Image selbst und die Registry, von der das Container-Image heruntergeladen wurde, enthalten. Im Allgemeinen kann ein Remote-Verifizierer 195 die Metadaten des Bildmanifests 312 untersuchen, um zu überprüfen, ob das Container-Bild von einer bestimmten Registry heruntergeladen wurde. Die Messung 312 kann in Übereinstimmung mit weiteren Implementierungen Metadaten aus anderen und/oder anderen Metadatenkategorien enthalten.
4 ist eine Illustration 400 des Agenten 164, der eine oder mehrere Laufzeitmessungen 428 des Overlay-Dateisystems 404 eines instanziierten Containers durchführt. Das Overlay-Dateisystem 404 umfasst in diesem Beispiel untere Schichten 168, die den Containerbildschichten 166 entsprechen und ein unteres Verzeichnis 470 bilden, und eine obere Schicht 168, die einer oberen Containerschicht entspricht412, die ein oberes Verzeichnis 480 bildet. Die Containerschicht 412 ist insofern dynamisch, als die Dateien der Schicht 412 geschrieben, gelöscht, erstellt usw. werden können. In der sind vier Dateien 430, 434, 436 und 438 aus einem zusammengefassten Verzeichnis 408 sichtbar, das einem Einhängepunkt des Betriebssystems entspricht. Obwohl die Dateien 430 und 436 nicht Teil der Containerschicht 412 sind, handelt es sich um schreibgeschützte Dateien aus dem unteren Verzeichnis 470. Obwohl die Datei 434 im unteren Verzeichnis 470 nicht geändert werden kann, ist die Datei 434 in diesem Beispiel Teil der Containerschicht 412, und als solche kann sich die Version der Datei 434 in der Containerschicht 412 von der Version im unteren Verzeichnis 470 unterscheiden. Wie ebenfalls in 4 dargestellt, existiert die Datei 438 im oberen Verzeichnis 480 und hat kein Gegenstück im unteren Verzeichnis 470.
In Übereinstimmung mit einigen Implementierungen kann der Agent 164 eine oder mehrere Laufzeitmessungen 428 des Overlay-Dateisystems 404 des Containers vornehmen. Zum Beispiel kann der Agent 164 einen Hash oder einen Satz von Hashes für eine bestimmte Schicht 168 des unteren Verzeichnisses 470 bestimmen; und der/die Hash(s) kann/können einer Messung/den Messungen der Schicht 166 entsprechen. Der Agent 164 kann ähnliche Messungen von mehreren oder allen Schichten 168 des unteren Verzeichnisses 470 gemäß Beispielimplementierungen vornehmen. Der Agent 164 kann auch, in Übereinstimmung mit Beispielimplementierungen, die Containerschicht 412 des oberen Verzeichnisses 480 messen. Zum Beispiel kann der Agent 164 Hashes für einzelne Dateien und/oder Verzeichnisse der Containerschicht 412 berechnen, und diese Hashes können den Messungen 428 entsprechen. Daher kann der Agent 164 (als Beispiele) eine oder mehrere der folgenden Messungen 428 des Overlay-Dateisystems 404 vornehmen: Messung(en) 428 einer bestimmten Schicht 168 des unteren Verzeichnisses 470; Messung(en) 428 mehrerer Schichten 168 des unteren Verzeichnisses 470; Messung(en) 428 aller Schichten 168 des unteren Verzeichnisses 470; Messung(en) 428 von Dateien der Containerschicht 412 des oberen Verzeichnisses 480; und/oder Messung(en) 428 von Verzeichnissen oder Gruppen von Dateien der Containerschicht 412 des oberen Verzeichnisses 480.
5 ist eine Illustration 500 des Agenten 164, der eine Messung 550 der Metadaten 170 des instanziierten Containers 120 gemäß einer Beispielimplementierung vornimmt. Bei der Messung 550 kann es sich beispielsweise um ein Tupel von Metadateneinträgen handeln, die Metadaten zur Bildidentifikation (ID) 504, Metadaten zur Ebenenliste 508, Metadaten zu offenen Ports 512, Metadaten zu zugeordneten Volumes 516, Metadaten zu Umgebungsvariablen 520, Metadaten zu Befehlen 524, Metadaten zu Argumenten 528, Metadaten zu Sicherheitsoptionen 532, Metadaten zu Netzwerkeinstellungen 536, Metadaten zum Namensraum 540 und Metadaten zu Privilegien 544 entsprechen.
Die Bild-ID-Metadaten 504 stellen eine Kennung für das Bild dar, das als Basis für den Container 120 verwendet wird. Der Identifikator kann verwendet werden, um das Bild mit einem bekannten gemessenen Bild zu verknüpfen. Die Metadaten der Ebenenliste 508 stellen eine Liste der Ebenen dar, die das untere Verzeichnis des Overlay-Dateisystems des Containers bilden. Die offenen Ports-Metadaten 512 stellen die Anzahl der offenen Ports für den Container 120 dar und können verwendet werden, um zu überprüfen, dass der Container 120 nicht mehr Ports öffnet, als für die spezifische Arbeitslast erwartet werden. Die Metadaten zu den zugeordneten Datenträgern 516 stellen die zugeordneten Datenträger für den Container 120 dar und können zur Überprüfung des Zugriffs des Containers auf das Host-Dateisystem verwendet werden.
Die Umgebungsvariablen-Metadaten 520 stellen die vom Container 120 verwendeten Umgebungsvariablen dar und können verwendet werden, um den Zugriff des Containers auf Host-Informationen zu überprüfen. Die Befehlsmetadaten 524 stellen die vom Container 120 verwendeten Befehle dar und können verwendet werden, um zu überprüfen, ob der Container 120 mit der erwarteten Anwendung ausgeführt wird.
Die Argumente-Metadaten 258 stellen Argumente dar, die vom Container 120 verwendet werden, und können verwendet werden, um zu überprüfen, ob der Container 120 mit den erwarteten Argumenten ausgeführt wird. Die Sicherheitsoptions-Metadaten 532 stellen Sicherheitsoptionen dar (z. B. Sicherheitsmoduleinstellungen wie ApparmorProfileinstellungen oder Sicherheitsmerkmal-Einstellungen eines Betriebssystemkerns wie SECComp-Einstellungen), die vom Container 120 verwendet werden, und können z. B. verwendet werden, um zu überprüfen, ob der Container 120 native Sicherheitsmechanismen umgeht oder nicht.
Die Netzwerkeinstellungs-Metadaten 536 stellen Netzwerkeinstellungen dar, wie z. B. einen dynamischen Namensserver (DNS), Netzwerktyp, Hosts usw., und können verwendet werden, um zu überprüfen, ob der Container 120 mit den erwarteten Einheiten kommuniziert oder nicht. Die Namensraum-Metadaten 540 können verwendet werden, um zu überprüfen, ob ein Container 120 in einem isolierten Namensraum läuft oder nicht. Anhand der Metadaten zu den Privilegien 544 kann überprüft werden, ob der Container 120 Privilegien ausweitet oder nicht.
In Übereinstimmung mit weiteren Beispielimplementierungen kann der Agent 164 metadatenbezogene Messungen des instanziierten Containers aus anderen und/oder anderen Metadatenkategorien vornehmen.
6 zeigt eine beispielhafte Zeitleiste 600 von Auslösern oder Ereignissen 602, die mit einem Container 120 über seinen Lebenszyklus verbunden sein können, und die entsprechenden Aktionen 603, die vom Agenten 164 als Reaktion auf die Ereignisse 602 durchgeführt werden können. Wie weiter unten beschrieben, umfassen die Aktionen 603 die Durchführung und Protokollierung von Messungen durch den Agenten 164 sowie die Erweiterung des PCR-Speichers 151 durch den Agenten 164.
Wie in 6 dargestellt, tritt das erste Ereignis zum Zeitpunkt 604 ein, zu dem die Container-Maschine 160 den Start des Containers 120 anfordert. Dieses Ereignis veranlasst den Agenten 164 gemäß Ausführungsbeispielen dazu, von der Zeit 606 bis zur Zeit 612 das Bild des Containers zu messen, wie mit der Bezugsziffer 608 dargestellt. Während dieser Zeitspanne hält der Agent 164 die Inbetriebnahme des Behälters 120 auf. Wie hierin beschrieben, kann der Agent 164 als Teil der Containerbildmessung eine oder mehrere Schichten des Containerbildes messen und Containerbild-Metadaten messen. Zum Zeitpunkt 612 ist die Messung des Containerbildes abgeschlossen, und der Agent 164 kann dann die Messung(en) des Start-up-Ereignisses protokollieren und den PCR-Speicher erweitern, wie in der Referenznummer 614 dargestellt. Nachdem der PCR-Speicher erweitert wurde, kann der Agent 164 die Sperrung aufheben, so dass der Container 120 in Betrieb gehen kann (siehe Zeitpunkt 620).
In Fortsetzung der Beispielzeitleiste 600 können weitere Ereignisse Messungen durch den Agenten 164 auslösen. Zum Beispiel tritt zum Zeitpunkt 624 ein Dateizugriffsereignis ein (z. B. wird eine Datei aus dem Container-Dateisystem gelesen oder in das Container-Dateisystem geschrieben), was den Agenten 164 veranlasst, von Zeit 626 zu Zeit 629 die Datei zu messen, wie bei 628 dargestellt; und dann protokolliert der Agent 164 die Messung des Dateizugriffsereignisses und erweitert den PCR-Speicher, wie bei der Referenznummer 630 dargestellt.
Als Nächstes tritt in der Beispielzeitleiste 600 zum Zeitpunkt 640 ein Ereignis zur Ausführung der Containererfassung ein. Es ist anzumerken, dass das Ausführungsereignis der Behältererfassung nach einem Zeitplan (z. B. einem periodischen Zeitplan) auftreten kann. Mit anderen Worten, in Übereinstimmung mit Beispielimplementierungen tritt zu bestimmten vorbestimmten Zeiten ein Behältererfassungsereignis ein, um den Agenten 164 zu veranlassen, den Behälter 120 zu messen, wie mit der Referenznummer 646 dargestellt, und daher eine oder mehrere Laufzeitbehältermessungen vorzunehmen. Das Ereignis der Behältererfassung kann in Übereinstimmung mit weiteren Implementierungen auf andere Ursachen zurückzuführen sein. Beispielsweise kann ein Capture-Container-Ereignis durch den Start einer anderen Instanz desselben Containers 120 entstehen. Die Messung 646 des Containers kann beinhalten, dass der Agent 164 Laufzeitmessungen des Container-Dateisystems erfasst, die Messungen von Dateien der Container-Schicht, eine oder mehrere Messungen einer Schicht des unteren Verzeichnisses, eine oder mehrere Messungen jeder Schicht des unteren Verzeichnisses und so weiter, wie hierin beschrieben, umfassen können. Der Agent 164 kann dann die Container-Erfassungsereignis-Messung(en) protokollieren und den PCR-Speicher erweitern, wie unter der Referenznummer 649 dargestellt.
6 zeigt außerdem ein Beispiel für eine Verifizierungsanfrage zum Zeitpunkt 660. Eine Verifizierungsanforderung kann zum Beispiel im Rahmen einer Fernbescheinigung erfolgen. Als Reaktion auf die Verifizierungsanforderung kann der Agent 164 gemäß Beispielimplementierungen das Containerbild (z. B. Messungen der Containerbildschicht und der Containerbild-Metadaten) und das Containerdateisystem (z. B. Messungen der Containerschichtdateien und der unteren Verzeichnisebene) vom Zeitpunkt 664 bis zum Zeitpunkt 668 messen (wie mit der Referenznummer 666 dargestellt). Der Agent 164 kann dann die Messungen der Verifizierungsanforderung protokollieren und den PCR-Speicher erweitern, wie unter der Referenznummer 669 dargestellt.
Zum Zeitpunkt 670 endet der Container 120 für die Beispielzeitleiste 600. Gemäß Beispielimplementierungen können als Reaktion auf das Container-Ende-Ereignis mehrere Aktionen vom Agenten 164 durchgeführt werden, wie z. B. die Aufzeichnung des Ereignisses (d. h. die Aufzeichnung der Beendigung des Containers) im Workload-Integritätsprotokoll 137 und/oder in einem Systemprotokoll; das Zurücksetzen des PCR-Speichers nach dem Signieren der endgültigen PCR-Werte; die Archivierung des Protokolls; usw. Es wird darauf hingewiesen, dass die Aktionen 603 des Agenten 164 und die auslösenden Ereignisse 602 von 6 lediglich Beispiele sind, da ein bestimmter Container 120 andere, weniger oder mehr auslösende Ereignisse haben kann. Im Allgemeinen kann der Agent 164 auf eine Reihe verschiedener Ereignisse reagieren, wie z. B. Betriebssystem- und Systemaufrufe, um die Laufzeitaktivitäten des Containers 120 zu messen, wie z. B. den Zugriff auf Dateien (wie oben beschrieben), das Mounten, den Zugriff auf Netzwerke und so weiter. Im Allgemeinen lösen diese Ereignisse Laufzeitmessungen des Containers durch den Agenten 164 auf der Grundlage von konfigurierten Richtlinien aus. Darüber hinaus können die Aktionen 603, wie ebenfalls oben beispielhaft beschrieben, durch explizite Anfragen zur Durchführung von Laufzeitmessungen ausgelöst werden, z. B. durch eine Anfrage eines entfernten Überprüfers, eines Benutzers, einer Anfrage zur Erfassung von Container-Ereignissen oder allgemein jeder autorisierten Einheit. Dies ermöglicht die flexible Durchführung periodischer und/oder bedarfsgesteuerter Messungen in einem relativ komplexen System, bei dem die Messung aller Aspekte eines Containers möglicherweise nicht praktikabel ist.
Bezug nehmend auf 7, in Übereinstimmung mit Beispielimplementierungen, beinhaltet ein Prozess 700 in einem Computersystem das Erfassen (Block 704) einer ersten Messung, die einem Software-Container entspricht. Das Erfassen der Messung beinhaltet, dass ein Hardware-Prozessor des Computersystems eine gegebene Schicht einer Vielzahl von Schichten einer geschichteten Dateisystemstruktur misst, die dem Software-Container entspricht. Die gegebene Schicht umfasst eine Vielzahl von Dateien, und die erste Messung umfasst eine Messung der Vielzahl von Dateien. Der Prozess 700 umfasst das Speichern (Block 708) der ersten Messung in einem sicheren Speicher des Computersystems. Ein Inhalt des sicheren Speichers wird verwendet, um die Integrität des Software-Containers zu überprüfen.
Bezug nehmend auf 8 speichert ein maschinenlesbares Speichermedium 800 in Übereinstimmung mit Ausführungsbeispielen Anweisungen 804. Die Anweisungen 804 veranlassen, wenn sie von einer Maschine ausgeführt werden, die Maschine dazu, in Verbindung mit einer Ladezeit eines Behälters jede Schicht einer Vielzahl von Schichten eines Behälterbildes zu messen, um eine Vielzahl von ersten Messungen bereitzustellen, und die Vielzahl von ersten Messungen in einem sicheren Speicher zu speichern. Der Inhalt des sicheren Speichers wird verwendet, um die Integrität des Behälters zu überprüfen. Die Anweisungen 804 veranlassen, wenn sie von der Maschine ausgeführt werden, ferner die Maschine, in Verbindung mit einer Laufzeit des Containers ein Overlay-Dateisystem zu messen, um eine zweite Messung bereitzustellen; und die zweite Messung in dem sicheren Speicher zu speichern, so dass der Inhalt die Mehrzahl der ersten Messungen und die zweite Messung enthält.
Wie in 9 gezeigt, umfasst ein System 900 gemäß Beispielimplementierungen ein Hardware-Sicherheitsmodul 904, einen Prozessor 912 und einen Speicher 916. Das Hardware-Sicherheitsmodul 904 umfasst einen sicheren Speicher 908 zum Speichern von Inhalten, die zur Überprüfung der Integrität eines Containers verwendet werden. Der Speicher 916 speichert Anweisungen 918, die, wenn sie von dem Prozessor 912 ausgeführt werden, den Prozessor 912 veranlassen, jede Schicht einer Vielzahl von Schichten eines unteren Verzeichnisses eines Overlay-Dateisystems, das dem Container entspricht, zu messen, um eine Vielzahl von ersten Messungen bereitzustellen; und eine Containerschicht eines oberen Verzeichnisses des Overlay-Dateisystems zu messen, um eine zweite Messung bereitzustellen. Die Anweisungen 918 veranlassen, wenn sie vom Prozessor 912 ausgeführt werden, den Prozessor 912 ferner, die ersten Messungen und die zweite Messung im sicheren Speicher 908 zu speichern.
Gemäß Ausführungsbeispielen entspricht die erste Messung einem Bild des Behälters, und die angegebene Schicht entspricht einer unteren Schicht der mehreren Schichten. Ein besonderer Vorteil besteht darin, dass die Messung einer Basisschicht, die für mehrere Behälterbilder verwendet wird, wiederverwendet werden kann.
Gemäß Beispielimplementierungen werden Metadaten, die mit einem Container verbunden sind, gemessen, um eine zweite Messung zu erhalten, und die zweite Messung wird im sicheren Speicher gespeichert, so dass der Inhalt die erste Messung und die zweite Messung enthält. Ein besonderer Vorteil ist, dass Metadaten verwendet werden können, um festzustellen, ob sich die Struktur des Containerbildes geändert hat oder ob sich der instanziierte Container wie erwartet verhält.
Gemäß Beispielimplementierungen können die Metadaten mit einem Bild eines Containers verbunden sein. Ein besonderer Vorteil besteht darin, dass die Metadaten verwendet werden können, um eine bestimmte Schichtstruktur des Containerbildes zu bestätigen, um zu überprüfen, ob eine Schicht weggelassen wurde, eine Schicht hinzugefügt wurde, eine Schichtanordnung geändert wurde usw.
Gemäß Beispielimplementierungen können die Metadaten Daten enthalten, die mindestens eines der folgenden Elemente repräsentieren: einen Einstiegspunktbefehl, der einer Anforderung zum Starten einer Instanziierung des Containers entspricht, eine dem Bild entsprechende Signatur, ein dem Bild entsprechendes Zertifikat oder ein Manifest des Bildes. Ein besonderer Vorteil besteht darin, dass zur Validierung des Containerabbilds neben einer Messung einer bestimmten Schicht des Containers auch andere Daten verwendet werden können.
Gemäß Beispielimplementierungen können die Metadaten mit einer Instanziierung des Containers verbunden sein. Ein besonderer Vorteil ist, dass die Metadaten verwendet werden können, um zu überprüfen, ob sich der Container wie erwartet verhält.
Gemäß Beispielimplementierungen kann die Messung der Metadaten als Reaktion auf eine Anforderung zum Starten einer weiteren Instanziierung des Containers durchgeführt werden. Ein besonderer Vorteil ist, dass sowohl dynamische als auch statische Aspekte des Containers zwischen Container-Instanziierungen überprüft werden können.
Obwohl die vorliegende Offenbarung in Bezug auf eine begrenzte Anzahl von Implementierungen beschrieben wurde, werden Fachleute, die über die Vorteile dieser Offenbarung verfügen, zahlreiche Modifikationen und Variationen davon erkennen. Es ist beabsichtigt, dass die beigefügten Ansprüche alle derartigen Modifikationen und Variationen abdecken.

Claims

Ein Verfahren, das Folgendes umfasst: in einem Computersystem, Erfassen einer ersten Messung, die einem Softwarecontainer entspricht, wobei das Erfassen der Messung einen Hardwareprozessor des Computersystems umfasst, der eine gegebene Schicht einer Vielzahl von Schichten einer geschichteten Dateisystemstruktur misst, die dem Softwarecontainer entspricht, wobei die gegebene Schicht eine Vielzahl von Dateien umfasst, und die erste Messung eine Messung der Vielzahl von Dateien umfasst; und Speichern der ersten Messung in einem sicheren Speicher des Computersystems, wobei ein Inhalt des sicheren Speichers verwendet wird, um eine Integrität des Software-Containers zu überprüfen.
Das Verfahren nach Anspruch 1, wobei: die erste Messung entspricht einem Bild des Behälters; und die gegebene Schicht entspricht einer Basisschicht aus der Vielzahl der Schichten.
Das Verfahren nach Anspruch 1, das ferner umfasst: Initiierung der Messung der gegebenen Schicht als Reaktion auf eine Aufforderung, eine Instanziierung des Software-Containers zu starten.
Das Verfahren nach Anspruch 1, das ferner umfasst: Messen von Metadaten, die mit dem Behälter verbunden sind, um eine zweite Messung durchzuführen; und Speichern der zweiten Messung in dem sicheren Speicher, so dass der Inhalt die erste Messung und die zweite Messung enthält.
Das Verfahren nach Anspruch 4, wobei: die Metadaten sind mit einem Bild des Containers verbunden.
Das Verfahren nach Anspruch 5, wobei die Metadaten Daten umfassen, die mindestens eines der folgenden Elemente darstellen: einen Einstiegspunkt-Befehl, der einer Anforderung zum Starten einer Instanziierung des Containers entspricht, eine dem Bild entsprechende Signatur, ein dem Bild entsprechendes Zertifikat oder ein Manifest des Bildes.
Das Verfahren nach Anspruch 4, das ferner umfasst: Durchführung der Messung der Metadaten und der Messung der gegebenen Schicht als Reaktion auf eine Überprüfungsanfrage.
Das Verfahren nach Anspruch 4, wobei: die Metadaten sind mit einer Instanziierung des Containers verbunden.
Das Verfahren nach Anspruch 8, wobei die Metadaten Daten umfassen, die mindestens eines der folgenden Elemente repräsentieren: eine Bildkennung für eine Basisschicht der mehreren Schichten, eine Liste der mehreren Schichten, eine Nummer eines offenen Ports, eine Kennung eines zugeordneten Volumes, eine Umgebungsvariable, einen Befehl, ein Argument, eine Sicherheitsoption, eine Netzwerkeinstellung, einen Namensraum oder ein Privileg.
Das Verfahren nach Anspruch 8, das ferner umfasst: Durchführen der Messung der Metadaten während einer Laufzeit des Containers, die der Instanziierung des Containers entspricht; und die Messung der gegebenen Schicht vor der Instanziierung des Containers.
Das Verfahren nach Anspruch 8, das ferner umfasst: Durchführung der Messung der Metadaten als Reaktion auf eine Anforderung, eine weitere Instanziierung des Containers zu starten.
Ein maschinenlesbares Speichermedium, das Befehle speichert, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen: in Verbindung mit einer Ladezeit eines Behälters jede Schicht einer Vielzahl von Schichten eines Behälterbildes messen, um eine Vielzahl von ersten Messungen zu erhalten; die Vielzahl der ersten Messungen in einem sicheren Speicher zu speichern, wobei ein Inhalt des sicheren Speichers verwendet wird, um eine Integrität des Behälters zu überprüfen; in Verbindung mit einer Laufzeit des Containers ein Overlay-Dateisystem messen, um eine zweite Messung zu liefern; und Speichern der zweiten Messung in dem sicheren Speicher, so dass der Inhalt die mehreren ersten Messungen und die zweite Messung enthält.
Speichermedium nach Anspruch 12, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, ferner die Maschine veranlassen, eine Vielzahl von Schichten des Überlagerungsdateisystems entsprechend dem Bild zu messen und eine Containerschicht des Überlagerungsdateisystems zu messen.
Speichermedium nach Anspruch 12, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine außerdem veranlassen, Metadaten zu messen, die das Overlay-Dateisystem darstellen.
Speichermedium nach Anspruch 14, wobei die Metadaten Daten umfassen, die mindestens eines der folgenden Elemente repräsentieren: eine Bildkennung für eine Basisschicht der mehreren Schichten, eine Liste der mehreren Schichten, eine Nummer eines offenen Ports, eine Kennung eines zugeordneten Volumes, eine Umgebungsvariable, einen Befehl, ein Argument, eine Sicherheitsoption, eine Netzwerkeinstellung, einen Namensraum oder ein Privileg.
Ein System, das Folgendes umfasst: ein Hardware-Sicherheitsmodul umfasst einen sicheren Speicher zum Speichern von Inhalten, die zur Überprüfung der Integrität eines Containers verwendet werden; einen Prozessor; und einen Speicher zum Speichern von Befehlen, die, wenn sie von dem Prozessor ausgeführt werden, den Prozessor veranlassen: jede Schicht einer Vielzahl von Schichten eines unteren Verzeichnisses eines dem Container entsprechenden Overlay-Dateisystems messen, um eine Vielzahl von ersten Messungen zu erhalten; eine Containerschicht eines oberen Verzeichnisses des Overlay-Dateisystems messen, um eine zweite Messung zu erhalten; und Speichern der mehreren ersten Messungen und der zweiten Messung in dem sicheren Speicher.
System nach Anspruch 16, wobei die Anweisungen, wenn sie von dem Prozessor ausgeführt werden, den Prozessor außerdem veranlassen: erste Metadaten zu messen, die Informationen über den Container darstellen, um eine dritte Messung vorzunehmen; zweite Metadaten messen, die Informationen über eine Instanziierung des Containers darstellen, um eine vierte Messung vorzunehmen; und den dritten Messwert und den zweiten Messwert im sicheren Speicher zu speichern.
System nach Anspruch 17, wobei die Befehle, wenn sie von dem Prozessor ausgeführt werden, den Prozessor außerdem veranlassen: Messen der ersten Metadaten als Reaktion auf einen Befehl zum Starten der Instanziierung des Containers; und Messung der zweiten Metadaten als Reaktion auf ein vorbestimmtes Ereignis.
System nach Anspruch 18, wobei das vorbestimmte Ereignis ein in periodischen Abständen ausgelöstes Ereignis oder ein Ereignis zum Starten einer weiteren Instanziierung des Behälters umfasst.
System nach Anspruch 16, wobei die Anweisungen, wenn sie von dem Prozessor ausgeführt werden, den Prozessor ferner veranlassen, eine Datei einer Instanziierung des Containers als Reaktion auf eine Dateizugriffsanforderung zu messen, um eine dritte Messung bereitzustellen, und die dritte Messung in dem sicheren Speicher zu speichern.