DE102022109195A1

DE102022109195A1 - Konfiguration von instanzen mit instanz-metadaten in virtuellen sicherheitsprozessoren gespeichert

Info

Publication number: DE102022109195A1
Application number: DE102022109195.3A
Authority: DE
Inventors: Toshimitsu Kani; Benjamin D. Lytle; Clark T. Laughlin; Robert C. Elliot
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2022-01-31
Filing date: 2022-04-14
Publication date: 2023-08-03
Also published as: CN116560787A; US20230247023A1

Abstract

Als Reaktion auf den Start einer Instanz einer Cloud-basierten Computerumgebung wird auf Metadaten zugegriffen, die in einem virtuellen vertrauenswürdigen Plattformmodul (vTPM) gespeichert sind. Die Metadaten stellen Konfigurationsparameter für die Instanz dar, und die Konfigurationsparameter umfassen einen Sicherheitsnachweis. Die Instanz wird auf der Grundlage der Metadaten konfiguriert. Die Konfiguration umfasst die Konfiguration einer Zugriffskontrolle für die Instanz mit dem Sicherheitsnachweis.

Description

HINTERGRUND
Ein Computersystem kann einem Sicherheitsangriff ausgesetzt sein, bei dem eine böswillige Organisation versucht, auf Informationen zuzugreifen, die auf dem Computersystem gespeichert sind, oder Komponenten des Computersystems zu beschädigen. Um Sicherheitsangriffe zu verhindern oder zumindest das Ausmaß des potenziellen Schadens durch Sicherheitsangriffe zu begrenzen, kann das Computersystem verschiedene Schutzniveaus aufweisen. So kann das Computersystem beispielsweise über verschiedene Mechanismen zur Zugangsbeschränkung verfügen, wie Firewalls, Passwörter, Schlüssel usw. Als weiteres Beispiel kann ein Computersystem über einen sicheren kryptografischen Prozessor (oder „Sicherheitsprozessor“) verfügen, z. B. ein vertrauenswürdiges Plattformmodul (Trusted Platform Module, TPM), das eine Reihe von sicherheitsrelevanten Funktionen für das Computersystem bereitstellen kann. Die sicherheitsrelevanten Merkmale können beispielsweise zum Speichern von Geheimnissen (z. B. Schlüssel, Passwörter, Zertifikate usw.) verwendet werden, um sicherzustellen, dass sich das Computersystem stets in der erwarteten Weise verhält, und um zu beweisen, dass das Computersystem vertrauenswürdig ist.
Figurenliste

1 ist eine schematische Darstellung eines Cloud-Computing-Systems mit einer Computerplattform, die ein virtuelles vertrauenswürdiges Plattformmodul (vTPM) enthält, das Instanz-Metadaten speichert, die zur Konfiguration einer Maschineninstanz gemäß einer Beispielimplementierung verwendet werden.
2A ist ein Flussdiagramm, das einen Prozess darstellt, der von einem Controller der Computerplattform von 1 ausgeführt wird, um ein vTPM zu erstellen, das vTPM mit Instanzmetadaten zu versehen und das vTPM an eine Maschineninstanz gemäß einer Beispielimplementierung anzuhängen.
2B ist ein Flussdiagramm, das einen Prozess darstellt, der von der Steuerung der Computerplattform von 1 durchgeführt wird, um ein vTPM von einer Maschineninstanz gemäß einer Beispielimplementierung zu trennen.
2C ist ein Flussdiagramm, das einen Prozess darstellt, der von der Steuerung der Computerplattform von 1 durchgeführt wird, um ein vTPM von einer Maschineninstanz zu einer anderen Maschineninstanz zu bewegen und das vTPM an die andere Maschineninstanz gemäß einer Beispielimplementierung anzuschließen.
3 ist ein schematisches Diagramm einer Computerplattform mit einem Plattform-Controller, der vTPMs bereitstellt, die vTPMs mit virtuellen Maschineninstanzen verbindet und die Lebenszyklen der vTPMs gemäß einer Beispielimplementierung verwaltet.
4 ist ein Flussdiagramm, das einen Prozess zur Konfiguration eines Betriebssystems einer Maschineninstanz unter Verwendung von Instanzmetadaten, die in einem vTPM gespeichert sind, gemäß einer Beispielimplementierung zeigt.
5 ist ein schematisches Diagramm einer Computerplattform mit einem Controller, der einen virtuellen Sicherheitsprozessor instanziiert, den virtuellen Sicherheitsprozessor mit einer Maschineninstanz verbindet und den virtuellen Sicherheitsprozessor mit Instanzmetadaten gemäß einer Beispielimplementierung versorgt.
6 ist eine Illustration eines nicht-transitorischen maschinenlesbaren Speichermediums, das maschinenausführbare Befehle speichert, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, eine Instanz einer Cloud-basierten Rechenumgebung zu konfigurieren, indem sie auf Metadaten zugreifen, die in einem vTPM gemäß einer Beispielimplementierung gespeichert sind.

AUSFÜHRLICHE BESCHREIBUNG
Ein Cloud-Computing-System kann mehrere physische Serverknoten (z. B. Blade-Server oder Rack-Server) oder „Computerplattformen“ umfassen, die von einem zentralen Management-Subsystem des Cloud-Computing-Systems verwaltet werden. Im Allgemeinen verwaltet das zentrale Management-Subsystem eine softwaredefinierte logische Infrastruktur und Dienste (z. B. softwaredefinierte Rechendienste (SDC), softwaredefinierte Speicherdienste (SDS) und softwaredefinierte Netzwerkdienste (SDN)), die auf den Computerplattformen gehostet werden. Im Rahmen der Bereitstellung der logischen Infrastruktur und der Dienste können die Computerplattformen Maschineninstanzen bereitstellen.
Eine „Maschineninstanz“, wie sie hier verwendet wird, bezieht sich auf einen Fall oder ein Vorkommnis in einer Computerumgebung. Die „Datenverarbeitungsumgebung“ kann sich auf eine Abstraktion oder Virtualisierung tatsächlicher Hardware- und Softwareressourcen beziehen, d. h. die Datenverarbeitungsumgebung kann eine virtuelle Datenverarbeitungsumgebung sein. Die „Computerumgebung“ kann sich auf einen Satz tatsächlicher Hardware- und Softwareressourcen beziehen, d. h. die Computerumgebung kann eine Bare-Metal-Computerumgebung sein. Die Hardware- und Softwareressourcen für eine bestimmte Computerumgebung können beispielsweise eine Betriebssysteminstanz, eine oder mehrere Anwendungsinstanzen, eine oder mehrere Zentraleinheiten (CPUs), eine oder mehrere Grafikverarbeitungseinheiten (GPUs), Speicher, Netzwerkschnittstellen-Controller, dauerhaften Speicher usw. umfassen.
Eine virtuelle Maschineninstanz ist ein Beispiel für eine Maschineninstanz, die als Fall oder Vorkommnis einer virtuellen Datenverarbeitungsumgebung betrachtet werden kann. Eine virtuelle Maschineninstanz (hier auch als „virtuelle Gastmaschine“, „virtuelle Maschine“, „VM-Instanz“, „Gast-VM“ oder „VM“ bezeichnet) bezieht sich auf eine Abstraktion der Hardware- und Softwareressourcen auf Maschinenebene. Ein Virtual Machine Monitor (VMM) oder Hypervisor einer Computerplattform stellt die Abstraktion von Hardware- und Plattformressourcen für die virtuelle Maschineninstanz bereit, und der Hypervisor sorgt für die Isolierung zwischen mehreren virtuellen Maschineninstanzen der Rechenplattform. Darüber hinaus kann der Hypervisor die Lebenszyklen (z. B. das Starten und Beenden) der jeweiligen virtuellen Maschineninstanzen verwalten. Eine Instanz einer virtuellen Maschine enthält ein Gastbetriebssystem, das eine Abstraktion des eigentlichen Host-Betriebssystems ist, das auf der Computerplattform installiert ist. Als solches hat das Gastbetriebssystem keinen direkten Zugriff auf die zugrunde liegende Hardware der Host-Computerplattform. Die für eine bestimmte virtuelle Maschineninstanz verfügbaren Hardware- und Softwareressourcen hängen von den Besonderheiten des Abonnements des zugehörigen Cloud-Mieters ab.
Eine Bare-Metal-Instanz ist ein Beispiel für eine Maschineninstanz, die als Fall oder Vorkommnis einer Bare-Metal-Computerumgebung betrachtet werden kann, d. h. eine Umgebung, die einem dedizierten Satz tatsächlicher Hardware- und Softwarekomponenten der Host-Computerplattform entspricht. Das Betriebssystem einer Bare-Metal-Instanz hat Zugriff auf die zugrunde liegende Hardware der Host-Computerplattform. Es wird darauf hingewiesen, dass eine Bare-Metal-Instanz möglicherweise nicht auf alle Hardware- und/oder Softwareressourcen der Host-Computerplattform zugreifen kann, sondern dass der Umfang der Bare-Metal-Instanz auf bestimmte Hardware- und/oder Softwareressourcen beschränkt sein kann, je nach den Besonderheiten des Abonnements des entsprechenden Cloud-Mieters.
Die Bereitstellung einer Maschineninstanz auf einer bestimmten Computerplattform (d. h. einem Cloud-Domänenknoten) kann die Bereitstellung eines generischen Betriebssystemabbilds auf der Plattform und die anschließende Ausführung eines Startprogramms (z. B. eines Cloud-Init-Skripts) beim ersten Hochfahren der Maschineninstanz umfassen, um das Betriebssystemabbild speziell zu konfigurieren. Das Startprogramm konfiguriert das Betriebssystem-Image mit instanzspezifischen Informationen und benutzerspezifischen Informationen. Die instanzspezifischen Informationen können beispielsweise Attribute wie die Identifizierung eines Typs oder einer Kategorie der Maschineninstanz, die Identität eines virtuellen Geräts, das das Root-Dateisystem enthält, eine Verfügbarkeitszone der Maschineninstanz, eine Internetprotokolladresse (IP) der Maschineninstanz usw. umfassen. Die benutzerspezifischen Informationen enthalten neben anderen möglichen Informationen einen vom Benutzer gewählten Berechtigungsnachweis (z. B. einen Secure Shell SSH-Schlüssel), der dem Benutzer eine sichere Kommunikation (z. B. über einen SSH-Tunnel) mit der Maschineninstanz ermöglicht.
Das Startprogramm kann Metadaten (hier als „Instanz-Metadaten“ bezeichnet) abrufen, die instanzspezifische Informationen und benutzerspezifische Informationen darstellen, die das Startprogramm zur Konfiguration des Betriebssystemabbilds verwendet. Ein Ansatz zum Abrufen der Instanz-Metadaten besteht darin, dass das Startprogramm das Hypertext Transfer Protocol (HTTP) verwendet, um die Instanz-Metadaten von einer bestimmten IP-Adresse abzurufen. Als Sicherheitsmaßnahme kann der Server, der der angegebenen IP-Adresse entspricht, den Zugriff auf die Instanz-Metadaten auf die Maschineninstanz beschränken. Da das Start-up-Programm über seine Maschineninstanz agiert, erlaubt der Server dem Start-up-Programm, die Instanz-Metadaten abzurufen.
Selbst wenn der Zugriff auf die Instanz-Metadaten auf die Maschineninstanz beschränkt ist, kann eine bösartige Entität diese Sicherheitsmaßnahme umgehen, indem sie über die Maschineninstanz agiert, um Zugriff auf die Instanz-Metadaten (und damit auf sensible Benutzerinformationen) zu erhalten. Beispielsweise kann die Instanz des Rechners eine grafische Benutzeroberfläche (GUI) bereitstellen, die ein URL-Adressfeld (Uniform Resource Locator) enthält, das zur Angabe von URLs für Uploads auf die GUI verwendet werden soll. Eine betrügerische Entität kann in ein URL-Feld der grafischen Benutzeroberfläche eingegeben werden, um die grafische Benutzeroberfläche zum Hochladen und zur Offenlegung der Instanz-Metadaten zu veranlassen (einschließlich der Offenlegung sensibler Benutzeranmeldedaten). Die Sicherheitsmaßnahmen für den Zugriff auf die Instanz-Metadaten können weiter verstärkt werden, indem der Zugriff auf ein Token (z. B. ein Token, das durch einen Client-URL (cURL) PUT-Befehl erzeugt wird) beschränkt wird, das für eine bestimmte Sitzung generiert wird. Daher ist der Abruf der Instanz-Metadaten auf eine Anfrage (z. B. eine Anfrage mit dem Befehl cURL GET) beschränkt, die das generierte Token enthält. Dieser Ansatz zur Sicherung der Instanz-Metadaten kann jedoch immer noch anfällig sein, da die Kommunikation der Instanz-Metadaten über eine unsichere HTTP-Verbindung erfolgt.
Ein anderer Ansatz zum Schutz von Instanz-Metadaten besteht darin, dass eine Maschineninstanz zunächst von einem Betriebssystem-Installationsprogramm gebootet wird, das auf einem RAM-basierten Dateisystem läuft. Das Betriebssystem-Installationsprogramm installiert ein ausgewähltes Betriebssystem-Image auf dem Root-Gerät, und das Betriebssystem-Installationsprogramm erhält die Instanz-Metadaten und verwendet sie zur Konfiguration des Betriebssystem-Images. Bei diesem Ansatz kann es jedoch sehr lange dauern, eine neue Maschineninstanz einzurichten. Darüber hinaus kann das Root-Gerät nicht erneut an andere Instanzen angeschlossen werden, ohne dass zusätzliche Betriebssystem-Images eingerichtet werden müssen.
Gemäß Beispielimplementierungen wird das Startprogramm beim ersten Booten einer Maschineninstanz ausgeführt, um ein generisches Betriebssystemabbild der Maschineninstanz mit instanzspezifischen Informationen und benutzerspezifischen Informationen zu konfigurieren. Das Startprogramm ruft gemäß Beispielimplementierungen Instanz-Metadaten (die die instanzspezifischen Informationen und benutzerspezifischen Informationen enthalten) von einem virtuellen Sicherheitsprozessor ab, z. B. von einem virtuellen Trusted Platform Module (vTPM).
Insbesondere erstellt ein Controller einer Computerplattform (die die Maschineninstanz bereitstellt) gemäß Beispielimplementierungen ein vTPM, versorgt das vTPM mit den Instanzmetadaten und fügt das vTPM an die Maschineninstanz an. Der Controller kann die Erstellung, die Bereitstellung und das Anhängen des vTPM in Übereinstimmung mit Anforderungen durchführen, die von einem Cloud-Orchestrator bereitgestellt werden. Wenn die Maschineninstanz startet, greift ein Startprogramm (z. B. ein Skript) der Maschineninstanz auf das angeschlossene vTPM zu, um die Instanz-Metadaten abzurufen, und das Startprogramm verwendet die abgerufenen Instanz-Metadaten, um das Betriebssystem-Image einzurichten oder zu konfigurieren, das mit der Maschineninstanz verbunden ist.
In Übereinstimmung mit Beispielimplementierungen kann der Controller ein Abbild des persistenten Speichers (z. B. ein NVRAM-Abbild, wie ein TPM-NVRAM-Abbild) für das vTPM erstellen. Das Abbild des persistenten Speichers enthält neben anderen möglichen Daten auch die Metadaten der Instanz. Der Controller kann das erstellte Abbild des persistenten Speichers an den Cloud-Orchestrator übermitteln, so dass der Cloud-Orchestrator das Abbild des persistenten Speichers als Vertrauensquelle beibehalten kann. Der Controller kann auch eine lokale Cache-Kopie des Abbilds des persistenten Speichers pflegen.
Da der Cloud-Orchestrator das Abbild des persistenten Speichers als Vertrauensquelle verwaltet, kann die auf der Computerplattform gespeicherte lokale Cache-Kopie gelöscht werden, wenn die Maschineninstanz angehalten und das vTPM von der Maschineninstanz getrennt wird. Darüber hinaus kann der Controller die lokale Cache-Kopie aus der Vertrauensquelle ohne weiteres wiederherstellen, wenn die Maschineninstanz neu startet und wieder mit dem vTPM verbunden wird. Da das Abbild des persistenten Speichers als Vertrauensquelle außerhalb der Computerplattform aufrechterhalten wird, können auch Benutzeraktualisierungen (z. B. zusätzliche, vom Benutzer installierte Schlüssel) für das vTPM über den gesamten Lebenszyklus des vTPM aufrechterhalten werden (d. h. von der Erstellung des vTPM bis zum Löschen des vTPM, unabhängig davon, wie oft das vTPM von einer Maschineninstanz getrennt wird). Da das Abbild des persistenten Speichers von der Vertrauensquelle zur Verfügung steht, kann die Steuereinheit das Abbild des persistenten Speichers leicht aktualisieren (z. B. das Abbild des persistenten Speichers mit neuen Instanz-Metadaten aktualisieren), wenn das vTPM von einer Maschineninstanz zu einer anderen Maschineninstanz migriert wird, wie hier weiter beschrieben.
Wie in 1 als spezifischeres Beispiel dargestellt, umfasst ein Cloud-Computing-System 99 in Übereinstimmung mit einigen Implementierungen eine oder mehrere Computerplattformen 100, die entsprechende Domänenknoten eines Cloud-Computing-Systems 99 bilden. In diesem Zusammenhang bezieht sich eine „Computerplattform“ auf eine modulare Einheit, die einen Rahmen oder ein Chassis umfasst. Darüber hinaus kann diese modulare Einheit Hardware enthalten, die an dem Rahmen befestigt ist und maschinenausführbare Befehle ausführen kann. Ein Blade-Server ist ein Beispiel für eine Computerplattform 100 gemäß einer Beispielimplementierung. Bei der Computerplattform 100 kann es sich jedoch gemäß weiteren Implementierungen auch um eine beliebige Anzahl anderer Plattformen als einen Blade-Server handeln, z. B. um einen Server im Rack, einen Client, einen Desktop, ein Smartphone, einen Laptop, einen Tablet-Computer, einen modularen Switch, ein Speicherarray, einen Clusterknoten usw.
Die Computerplattform 100 hat eine Cloud-Mieter-Domäne 101 und eine Cloud-Betreiber-Domäne 103, die durch die dargestellte Grenze 120 getrennt sind. Die Cloud-Tenant-Software wird innerhalb der Cloud-Tenant-Domäne 101 ausgeführt. Bei der in 1 dargestellten Beispielimplementierung umfasst die Cloud-Mieterdomäne 101 eine oder mehrere Maschineninstanzen 104 (z. B. virtuelle Maschineninstanzen und/oder Bare-Metal-Instanzen). Gemäß Beispielimplementierungen kann eine Maschineninstanz 104 mit einem bestimmten Cloud-Tenant verbunden sein und mit Software verknüpft sein, die ausgeführt wird, um einen oder mehrere Cloud-Dienste für den Cloud-Tenant bereitzustellen. Bei der in 1 dargestellten Beispielimplementierung umfasst die Maschineninstanz 104 ein Betriebssystem 116 und Anwendungen 114. Die Software kann auch eine oder mehrere virtuelle vertrauenswürdige Plattformmodule (virtual trusted platform module, vTPM), Anwendungsprogrammierschnittstellen (APIs) 118 und eine Start-up-Engine 112 umfassen, die hier weiter beschrieben werden.
Die Cloud-Betreiberdomäne 103 der Computerplattform 100 umfasst einen Cloud-Orchestrator 170, der Hardware- und Softwarekomponenten der Cloud-Betreiberdomäne 103 verwaltet. Der Cloud-Orchestrator 170 kann in Übereinstimmung mit einigen Implementierungen einen oder mehrere Server umfassen, und der Cloud-Orchestrator 170 kann durch eine Netzwerkstrukturverbindung 160 verbunden sein (d. h. eine Verbindung 160 mit einer Netzwerkstruktur, die eine oder mehrere Netzwerkkomponenten, ein oder mehrere Netzwerkprotokolle usw. umfassen kann).
Der Cloud-Orchestrator 170 umfasst gemäß Beispielimplementierungen eine Lebenszyklus-Management-Engine 172, die die Lebenszyklen von Maschineninstanzen 104 verwaltet, die auf Domänenknoten des Cloud-Computing-Systems 99, wie der Computerplattform 100, bereitgestellt werden können. In diesem Zusammenhang umfasst die Verwaltung des Lebenszyklus einer Maschineninstanz 104 die Verwaltung oder Steuerung der Lebensphasen der Maschineninstanz 104. Beispielsweise kann eine bestimmte Maschineninstanz 104 unter der Verwaltung der Lebenszyklus-Verwaltungs-Engine 172 mehrere Lebenszyklusphasen durchlaufen, beispielsweise eine Bereitstellungsphase (d. h. eine Phase der Ressourcenzuweisung für die Maschineninstanz 104) und eine Bereitstellungsphase (d. h. eine Phase, in der sich die Maschineninstanz 104 auf ihr erstes Hochfahren oder ihren ersten Start vorbereitet). Die Lebenszyklusphasen der Maschineninstanz können auch eine Betriebsphase, eine Anhaltephase, in der die Maschineninstanz 104 gerade angehalten wird, eine Beendigungsphase usw. umfassen. Gemäß Beispielimplementierungen besteht die Lebenszyklusmanagement-Engine 172 aus einem oder mehreren Rechenkernen (z. B. CPU-Kernen oder GPU-Kernen) auf einem oder mehreren Servern, die maschinenlesbare Anweisungen (oder „Software“) ausführen.
Gemäß Beispielimplementierungen kann die Lebenszyklusmanagement-Engine 172 die Lebenszyklen von vTPMs, wie z. B. vTPM 122, die auf Computerplattformen erstellt werden, verwalten. Das vTPM 122 befindet sich in der Cloud-Betreiberdomäne 103. Wie hier weiter beschrieben, kann der Lebenszyklus der vTPM eine Bereitstellungsphase umfassen, um eine vTPM, wie die vTPM 122, zu erstellen, einschließlich der Zuweisung von Ressourcen des Cloud-Orchestrators 170 und der Computerplattform 100. Der Lebenszyklus des vTPM kann eine Anbindungsphase umfassen, in der ein vTPM an eine Maschineninstanz, wie die Maschineninstanz 104, angebunden wird. Darüber hinaus kann der Lebenszyklus des vTPM eine Abtrennungsphase umfassen, in der das vTPM von einer Maschineninstanz abgetrennt wird und die Ressourcen auf der Computerplattform 100 für das vTPM freigegeben (z. B. gelöscht oder gelöscht) werden. Der Lebenszyklus des vTPM kann ferner eine Löschphase umfassen, in der alle Ressourcen für das vTPM freigegeben werden, um das vTPM zu löschen (z. B. werden Ressourcen auf dem Cloud-Orchestrator 170 gelöscht oder gelöscht). Der Lebenszyklus des vTPM kann ferner eine Migrationsphase umfassen, in der ein vTPM von einer Maschineninstanz (z. B. einer virtuellen Maschineninstanz, die ausgefallen ist oder sich auf einer ersten Computerplattform befindet) zu einer anderen Maschineninstanz (z. B. einer virtuellen Maschineninstanz auf derselben ersten Computerplattform oder einer anderen Computerplattform) verschoben oder migriert wird.
Gemäß Beispielimplementierungen kommuniziert die Lifecycle-Management-Engine 172 mit einem Controller 150 der Computerplattform 100, um Maschineninstanzen (wie die Beispiel-Maschineninstanz 104) auf der Computerplattform 100 zu erstellen und die Lebenszyklen der Maschineninstanzen zu verwalten. Darüber hinaus kann die Lifecycle-Management-Engine 172 in Übereinstimmung mit Beispielimplementierungen mit dem Controller 150 kommunizieren, um vTPMs (wie z. B. vTPM 122) zu erstellen und die vTPMs mit den Maschineninstanzen zu verbinden oder zu verknüpfen. Bei der in 1 dargestellten Beispielimplementierung wird das vTPM 122 an die Maschineninstanz 104 angehängt (wie mit der Referenznummer 119 dargestellt). Das „Anhängen“ eines vTPM an eine bestimmte Maschineninstanz bezieht sich in diesem Zusammenhang darauf, dass das vTPM für Entitäten der Maschineninstanz zugänglich ist (wie durch Zugriffsrichtlinien gesteuert, wie hier weiter beschrieben).
Die folgende Erörterung bezieht sich speziell auf das vTPM 122 und die Maschineninstanz 104, die in 1 dargestellt sind, obwohl es sich versteht, dass die Computerplattform 100 gemäß den Beispielimplementierungen mehrere Maschineninstanzen und mehrere vTPMs haben kann. Darüber hinaus umfasst der Begriff „Cloud-Orchestrator 170“, der eine Aktion durchführt, in der folgenden Diskussion im Allgemeinen die Aktion, die von einer Komponente des Cloud-Orchestrators 170 (z. B. der Lifecycle Management Engine 172) durchgeführt wird.
Im Folgenden wird davon ausgegangen, dass der Controller 150 die Lebenszyklen des vTPM 122 als Reaktion auf Anforderungen des Cloud-Orchestrators 170 verwaltet. Darüber hinaus verwaltet die Steuereinheit 150 in Übereinstimmung mit Beispielimplementierungen den Lebenszyklus der Maschineninstanz 104 als Reaktion auf Anforderungen des Cloud-Orchestrators 170. In Übereinstimmung mit einigen Implementierungen, wie hierin weiter beschrieben, kann der Controller 150 mehr als eine Komponente umfassen, wie z. B. einen Hypervisor zur Verwaltung der Lebenszyklen von Maschineninstanzen und einen Plattform-Controller zur Verwaltung der Lebenszyklen von vTPMs. In Übereinstimmung mit weiteren Beispielimplementierungen kann die Steuereinheit 150 eine einzige Einheit sein, z. B. ein Hypervisor, der die Lebenszyklen von Maschineninstanzen und die Lebenszyklen von vTPMs verwaltet.
Wie unter der Referenznummer 153 angegeben, führt die Steuereinheit 150 gemäß Beispielimplementierungen die plattforminterne Verwaltung des Lebenszyklus der Maschineninstanz 104 durch (wie vom Cloud-Orchestrator 170 angewiesen). Darüber hinaus führt der Controller 150, wie mit der Referenznummer 151 angegeben, in Übereinstimmung mit Beispielimplementierungen die plattforminterne Verwaltung des Lebenszyklus des vTPM 122 durch, wie vom Cloud-Orchestrator 170 angewiesen.) Der Cloud-Orchestrator 170 kommuniziert gemäß Beispielimplementierungen als Teil eines Prozesses zum Einrichten der Konfiguration der Maschineninstanz 104 mit dem Controller 150, um das vTPM 122 zu erstellen. Als Teil der Erstellung des vTPM 122 versorgt der Controller 150 das vTPM 122 mit Instanzmetadaten 140. Wie hierin weiter beschrieben, kann der Cloud-Orchestrator 170 zum Zweck der Erstellung des vTPM 122 benutzerdefinierte Daten 180 von einem Cloud-Mieter empfangen (z. B. die Daten 180 über eine mit dem Cloud-Orchestrator 170 verbundene grafische Benutzeroberfläche empfangen oder die Daten 180 über eine Datei empfangen, die dem Cloud-Orchestrator 170 vom Mieter mitgeteilt wurde), und die benutzerdefinierten Daten 180 können Daten enthalten, die Parameter oder Attribute der Instanzmetadaten 140 darstellen.
In Übereinstimmung mit Beispielimplementierungen enthalten die Instanz-Metadaten 140 benutzerspezifische Metadaten 142 und instanzspezifische Metadaten 144. Wenn die Maschineninstanz 104 zum ersten Mal startet, greift die Start-up-Engine 112 (z. B. ein Skript, wie ein Cloud-Init-Skript, das von einem Verarbeitungskern der Computerplattform 100 ausgeführt wird) auf die vTPM 122 zu, um die Instanz-Metadaten 140 abzurufen. Die Start-up-Engine 112 konfiguriert dann auf der Grundlage der Instanz-Metadaten 140 ein Image eines Betriebssystems 116 der Maschineninstanz 104. Beispielsweise kann die Start-up-Engine 112 auf der Grundlage der Instanz-Metadaten 140 das Betriebssystem-Image mit instanzspezifischen Informationen konfigurieren, wie z. B. einer Kennung der Maschineninstanz 104, einer Identität eines virtuellen Geräts, das das Root-Dateisystem enthält, einem Host-Namen der Maschineninstanz 104, einer IP-Adresse der Maschineninstanz 104, der Verfügbarkeitszone der Maschineninstanz 104 und so weiter. Die Start-up-Engine 112 kann auf der Grundlage der Instanz-Metadaten 140 das Betriebssystem-Image mit benutzerspezifischen Informationen konfigurieren, z. B. einem SSH-Schlüssel oder einer anderen Benutzerberechtigung, die es einem Benutzer ermöglicht, sicher mit der Maschineninstanz 104 zu kommunizieren.
Der vTPM 122 ist ein Beispiel für einen virtuellen sicheren kryptografischen Prozessor oder einen „virtuellen Sicherheitsprozessor“. Im Allgemeinen kann ein Sicherheitsprozessor (unabhängig davon, ob es sich um einen tatsächlichen physischen Sicherheitsprozessor oder einen virtuellen Sicherheitsprozessor handelt) vertrauenswürdige Datenverarbeitungsvorgänge für eine Computerplattform bereitstellen, um sicherzustellen, dass sich die Computerplattform konsistent in der erwarteten Weise verhält. Als Beispiele für vertrauenswürdige Rechenoperationen kann der Sicherheitsprozessor kryptografische Schlüssel erzeugen; Sicherheitsartefakte speichern (z. B. kryptografische Schlüssel und Zertifikate); auf Sicherheitsartefakte zugreifen; Sicherheitsartefakte löschen; Integritätsmessungsauszüge speichern; signierte Integritätsmessungsauszüge für die Fernbescheinigung bereitstellen; Daten verschlüsseln; Daten entschlüsseln; kryptografische Schlüssel an bestimmte Integritätsmessungsauszugszustände binden (z. B., Binden eines Verschlüsselungsschlüssels (KEK) eines Speichergeräts an einen Satz von Integritätsmessungen); Entsiegeln von kryptografischen Schlüsseln; Bereitstellen von Nonces für kryptografische Kommunikationen; Signieren von Zertifikaten; Bereitstellen von Zufalls- oder Pseudozufallszahlen; und so weiter. Die vertrauenswürdigen Rechenoperationen können auch Operationen zur Konfiguration des Sicherheitsprozessors und Operationen zum Besitz des Sicherheitsprozessors umfassen. Ein vertrauenswürdiges Plattformmodul (Trusted Platform Module, TPM) ist ein Beispiel für einen Sicherheitsprozessor.
Der Sicherheitsprozessor kann gemäß Beispielimplementierungen über einen nichtflüchtigen oder dauerhaften Speicher verfügen, wie z. B. einen nichtflüchtigen Speicher mit wahlfreiem Zugriff (NVRAM), in dem zwei Arten von Daten gespeichert werden: vordefinierte Datenstrukturen (z. B. Strukturen, die einem Bestätigungsschlüssel (EK), einem Bescheinigungsschlüssel (AIK), Seeds, Autorisierungswerten usw. entsprechen) und unstrukturierte Daten. Die im NVRAM gespeicherten Daten können als „NVRAM-Image“ (oder „Persistent Memory Image“) bezeichnet werden. Die strukturierten Daten können durch einen architektonischen Standard für den Sicherheitsprozessor definiert werden, und die unstrukturierten Daten entsprechen Benutzerobjekten (z. B. kryptografischen Schlüsseln, Passwörtern, Seeds, sensiblen Daten usw.), auf die ein Mandant zugreifen (lesen oder speichern) kann, wenn er die entsprechenden Zugriffskontrollrichtlinien für die Benutzerobjekte einhält.
Ein bestimmtes Benutzerobjekt kann beispielsweise ein Festplattenverschlüsselungsschlüssel sein, für den die folgende Zugriffskontrollpolitik gilt. Der Zugriff auf den Festplattenverschlüsselungsschlüssel kann auf Mandanten mit der entsprechenden Berechtigungsstufe beschränkt werden. Darüber hinaus kann der Zugriff auf Tenant(s) mit Kenntnis des zugehörigen Handles oder „NV-Index“ des Benutzerobjekts beschränkt werden. Zusätzlich zu der Voraussetzung, dass der Mandant über die entsprechende Berechtigungsstufe und den NV-Index verfügt, kann die Zugriffskontrollpolitik weitere Kriterien festlegen. Beispielsweise kann der Festplattenverschlüsselungsschlüssel gemäß der zugehörigen Zugriffskontrollpolitik mit einem Messwert-Digest versiegelt werden, wie z. B. einem Messwert-Digest, der durch Plattformkonfigurationsregister (PCRs) der Computerplattform dargestellt wird. Hier bezieht sich der Begriff „versiegelter“ Festplattenverschlüsselungsschlüssel auf den zu verschlüsselnden Schlüssel. Der Festplattenverschlüsselungsschlüssel kann mit einem bestimmten Zustand der Computerplattform (oder einem anderen Zustand) versiegelt werden, so dass der Sicherheitsprozessor den Festplattenverschlüsselungsschlüssel nicht entsiegelt oder entschlüsselt und den Festplattenverschlüsselungsschlüssel dem anfragenden Mieter zur Verfügung stellt, wenn die aktuelle Messauswertung (z. B. die durch die aktuellen PCR-Werte dargestellte Auswertung) nicht mit der Messauswertung übereinstimmt, mit der der Festplattenverschlüsselungsschlüssel versiegelt ist.
In Übereinstimmung mit einigen Implementierungen bezieht sich ein Sicherheitsprozessor im Allgemeinen auf jede Komponente, die bestimmte Sicherheitsoperationen durchführt. Gemäß Beispielimplementierungen kann der Sicherheitsprozessor ein TPM sein, das gemäß einer von der Trusted Computing Group (TCG) definierten Sicherheitsspezifikation arbeitet, wie der Trusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.59 (November 2019), die von der Trusted Computing Group veröffentlicht wurde (im Folgenden als „TPM 2.0 Specification“ bezeichnet). Gemäß einigen Implementierungen kann ein Sicherheitsprozessor ein TPM sein, das gemäß einer anderen Sicherheitsspezifikation als der TPM 2.0-Spezifikation arbeitet. Gemäß weiteren Beispielen kann der Sicherheitsprozessor nicht gemäß einer TCG-Spezifikation arbeiten.
Ein physischer oder tatsächlicher Sicherheitsprozessor kann als physisches Gerät mit Hardware implementiert werden, z. B. mit einem integrierten Schaltkreis (IC) oder einem „Chip“. Ein „virtueller Sicherheitsprozessor“ (z. B. ein vTPM in Übereinstimmung mit Beispielimplementierungen) bezieht sich auf die Emulation eines physischen Sicherheitsprozessors durch die Ausführung maschinenlesbarer Anweisungen durch einen Hardwareprozessor (z. B. einen Hardwareprozessor, der aus einem oder mehreren Rechenkernen wie CPU- oder GPU-Kernen besteht). Je nach Implementierung können die maschinenlesbaren Befehle Firmware-Befehle oder Nicht-Firmware-Befehle sein. Unabhängig von seiner besonderen Form verfügt ein virtueller Sicherheitsprozessor gemäß den Beispielimplementierungen über einen zugehörigen sicheren Speicher, der mit geheimen oder sensiblen Informationen, einschließlich Instanz-Metadaten, ausgestattet werden kann.
Zu den Merkmalen des vTPM 122 gehören gemäß Beispielimplementierungen maschinenlesbare Anweisungen 128, die von einem Hardwareprozessor (z. B. einem Hardwareprozessor, der aus einem oder mehreren Prozessorkernen, wie CPU- oder GPU-Kernen der Computerplattform 100, gebildet wird) ausgeführt werden können, um ein physisches TPM zu emulieren. Im Rahmen dieser Emulation verfügt das vTPM 122 über eine emulierte TPM-Schnittstelle 124, und das vTPM 122 verfügt über einen NVRAM. In Übereinstimmung mit Beispielimplementierungen entspricht der NVRAM einem persistenten lokalen Cache 132 der Computerplattform 100 und einer persistenten Vertrauensquelle 174 des Cloud-Orchestrators 170. Der lokale Cache 132 speichert ein NVRAM-Abbild 136 für das vTPM 122, und das NVRAM-Abbild 136 enthält die Instanz-Metadaten 140, strukturierte Daten 147 (z. B. Daten, die strukturierte Daten darstellen, die durch die TPM 2.0-Spezifikation definiert sind) und unstrukturierte Daten, die ein oder mehrere andere Benutzerobjekte 145 darstellen (z. B. Objekte, die von der Maschineninstanz 104 gespeichert werden, wie Seeds, Schlüssel, Passwörter, Zertifikate). In Übereinstimmung mit einigen Implementierungen können die Instanz-Metadaten 140 als unstrukturierte Daten betrachtet werden.
In Übereinstimmung mit einigen Implementierungen kann der Zugriff auf die Instanz-Metadaten 140 durch eine Zugriffskontrollpolitik geschützt werden. Beispielsweise kann die Zugriffskontrollpolitik für die Instanz-Metadaten 140 bei einigen Implementierungen verhindern, dass eine andere Einheit als die angeschlossene Maschineninstanz 104 auf die Instanz-Metadaten 140 zugreift. Darüber hinaus können die Instanz-Metadaten 140 gemäß einigen Implementierungen für einen bestimmten PCR-Zustand versiegelt sein, und der Zugriff auf die Instanz-Metadaten 140 kann die Verwendung (und Kenntnis) eines den Instanz-Metadaten 140 entsprechenden NV-Index erfordern.
In Übereinstimmung mit weiteren Implementierungen kann ein Teil der Instanz-Metadaten 140 eine andere Zugriffskontrollpolitik haben als ein anderer Teil der Instanz-Metadaten. Beispielsweise können in einigen Implementierungen die benutzerspezifischen Metadaten 142 in einem bestimmten PCR-Zustand versiegelt sein, aber die instanzspezifischen Metadaten 144 können eine weniger restriktive Zugriffskontrollpolitik haben, die keine Versiegelung der Metadaten 144 beinhaltet. In weiteren Implementierungen können alle Instanz-Metadaten 140 dieselbe Zugriffskontrollpolitik haben.
Wie der Name schon andeutet, ist der lokale Cache 132 in Übereinstimmung mit den Beispielimplementierungen ein temporärer Speicher für das NVRAM-Abbild 136. Da sich der lokale Cache 132 lokal auf der Computerplattform 100 befindet, beschleunigt er den Zugriff auf die NVRAM-Daten. Der lokale Cache 132 kann gelöscht werden, wenn das vTPM 122 von der Maschineninstanz 104 abgetrennt wird. Das Löschen kann für Sicherheitszwecke vorteilhaft sein, da sensible Daten, die sich auf eine Maschineninstanz 104 beziehen, von der Computerplattform 100 entfernt werden können, wenn die Maschineninstanz 104 gestoppt wird. Es wird darauf hingewiesen, dass ein bestimmter Cloud-Mieter eine Maschineninstanz wiederholt anhalten und starten kann, um die Cloud-Kosten zu senken. Da das entsprechende NVRAM-Abbild 178 vom Cloud-Orchestrator 170 als Vertrauensquelle 174 verwaltet wird, kann beim Neustart einer gestoppten Maschineninstanz 104 die lokale Kopie des NVRAM-Abbilds der Plattform aus dem NVRAM-Abbild 178 wiederhergestellt werden. Darüber hinaus kann das NVRAM-Abbild 178, wie hier weiter beschrieben, mit neuen Instanz-Metadaten 140 aktualisiert werden, um ein vTPM zu einer anderen Maschineninstanz 104 zu verschieben oder zu migrieren.
Für den Zugriff auf das vTPM 122 kann das Betriebssystem 116 einen TPM-Treiber enthalten (in 1 nicht dargestellt). Die vTPM-APIs 118 können von Komponenten der Maschineninstanz 104, z. B. den Anwendungen 114 und der Start-up-Engine 112, verwendet werden, um Anfragen an das vTPM 122 zu richten und Antworten vom vTPM 122 zu erhalten.
2A zeigt einen Prozess 200, der von der Steuereinheit 150 durchgeführt wird, um ein vTPM 122 zu erstellen, das vTPM 122 mit Instanzmetadaten 140 zu versehen und das vTPM 122 an eine Maschineninstanz 104 gemäß einer Beispielimplementierung anzuhängen. Unter Bezugnahme auf 2A in Verbindung mit 1 empfängt der Controller 150 eine „Create vTPM Request“ (Block 204) vom Cloud Orchestrator 170, um ein vTPM 122 zu erstellen. Die „Create vTPM Request“ enthält die Instanzmetadaten 140 oder Daten, aus denen die Instanzmetadaten 140 abgeleitet werden können. Gemäß Block 204 erstellt der Controller 150 als Reaktion auf die „Create vTPM Request“ ein NVRAM-Image und übermittelt das NVRAM-Image an den Cloud-Orchestrator 170, damit der Cloud-Orchestrator 170 das NVRAM-Image als Vertrauensquelle 174 verwaltet.
Wie in Block 210 dargestellt, erhält der Controller 150 als Teil des Prozesses 200 eine „Attach vTPM Request“ vom Cloud-Orchestrator, um eine Maschineninstanz 104 zu starten. Die „Attach vTPM Request“ enthält einen Verweis auf das NVRAM-Image 178. Als Reaktion auf die Attach vTPM-Anforderung instanziiert der Controller 150 das vTPM 122 aus dem NVRAM-Image 178 und fügt das vTPM 122 an die Maschineninstanz 104 an. Mit dem bereitgestellten vTPM 122 an Ort und Stelle kann die Start-up-Engine 112 der Maschineninstanz 104 dann auf das vTPM 122 zugreifen, um die Instanz-Metadaten 140 abzurufen und das Bild für das Betriebssystem 116 auf der Grundlage der Instanz-Metadaten 140 zu konfigurieren, wie in Block 216 abgebildet.
2B zeigt einen Prozess 240, der von der Steuereinheit 150 durchgeführt wird, um ein vTPM 122 von einer Maschineninstanz 104 gemäß einer Beispielimplementierung zu trennen. Unter Bezugnahme auf 2B in Verbindung mit 1 empfängt der Controller 150 gemäß Block 244 eine „Detach vTPM Request“ vom Cloud Orchestrator 170. Die Detach vTPM-Anforderung kann einen Verweis auf die bestimmte Maschineninstanz 104 und einen Verweis auf das vTPM 122 enthalten. Als Reaktion auf die „Detach vTPM Request“ hält der Controller 150 die Maschineninstanz 104 an (Block 248) und löscht das NVRAM-Abbild 136 aus dem lokalen Cache 132.
2C zeigt einen Prozess 260, der von der Steuereinheit 150 durchgeführt wird, um ein vTPM 122 von einer Maschineninstanz 104 zu einer anderen Maschineninstanz 104 zu migrieren, gemäß einer Beispielimplementierung. Unter Bezugnahme auf 2C in Verbindung mit 1 empfängt die Steuerung 150 gemäß dem Prozess 260 eine „Move vTPM Request“ vom Cloud-Orchestrator 170, um ein vTPM zu einer Maschineninstanz 104 zu verschieben (Block 264). Die „Move vTPM Request“ enthält Instanz-Metadaten 140 (oder Daten, aus denen die Instanz-Metadaten 140 abgeleitet werden können) und einen Verweis auf ein NVRAM-Image 178. Gemäß Block 268 erstellt der Controller 150 als Reaktion auf die Move vTPM-Anforderung ein neues NVRAM-Abbild. Das neue NVRAM-Image enthält die Instanz-Metadaten 140, die mit der Move vTPM-Anforderung verbunden sind, d.h. diese neuen Instanz-Metadaten 140 ersetzen die Instanz-Metadaten 140 des alten NVRAM-Images 178. Das neue NVRAM-Abbild enthält die Benutzerdaten aus dem alten NVRAM-Abbild 178. Der Controller 150 übermittelt dann gemäß Block 272 das neue NVRAM-Image an den Cloud-Orchestrator 170, damit der Cloud-Orchestrator 170 es als NVRAM-Image 178 in einer Vertrauensquelle 174 verwaltet.
In 3 ist eine Computerplattform 302 gemäß einem Ausführungsbeispiel dargestellt. In 3 werden ähnliche Referenznummern verwendet, um auf ähnliche Komponenten zu verweisen, die oben beschrieben sind. Wie in 3 dargestellt, kann die Computerplattform 302 über eine Netzwerkstruktur 384 mit dem Cloud-Orchestrator 170 und mit einem oder mehreren Clients 380 (z. B. Client-Computerplattformen, die mit einem oder mehreren Cloud-Mietern verbunden sind) verbunden sein. Im Allgemeinen kann die Netzwerkstruktur 384 mit einem oder mehreren Typen von Kommunikationsnetzwerken verbunden sein, wie (als Beispiele) Fibre-Channel-Netzwerke, Gen-Z-Fabrics, dedizierte Managementnetzwerke, lokale Netzwerke (LANs), Weitverkehrsnetzwerke (WANs), globale Netzwerke (z. B. das Internet), drahtlose Netzwerke oder eine beliebige Kombination davon.
Bei der in 3 dargestellten Beispielimplementierung umfasst die Steuerung 150 eine Plattformsteuerung 350, und die Maschineninstanz ist eine virtuelle Maschineninstanz 104. Ein „Plattform-Controller“ kann sich auf einen Controller beziehen, der bestimmte Aufgaben in einem Computersystem ausführt. In einigen Beispielen kann der Plattform-Controller 350 ein Peripherie-Bus-Gerät sein, z. B. ein Bus-Gerät, das mit einem Peripheral Component Interconnect Express (PCIe)-Bus verbunden ist. In anderen Beispielen kann der Plattformcontroller ein Busgerät sein, das mit einem anderen Bustyp in einem System verbunden ist. Ein „Bus“ bezieht sich auf eine Kommunikationsverbindung, über die mehrere Geräte miteinander kommunizieren können. Wie in 3 dargestellt, kann der Plattform-Controller 350 mit einer Bus/Brücken-Architektur 330 verbunden sein. In diesem Fall steht die „Bus/Brücken-Architektur“ für einen oder mehrere Busse und möglicherweise eine oder mehrere Brücken, die die Kommunikation zwischen den Bussen herstellen.
Der Plattformcontroller 350 führt gemäß Beispielimplementierungen eine TPM-Emulation durch, um ein oder mehrere vTPMs 368 bereitzustellen. In diesem Zusammenhang bezieht sich die Bereitstellung von vTPMs auf die Verwaltung der Lebenszyklen der vTPMs. In Übereinstimmung mit Beispielimplementierungen kann der Plattformcontroller 350 die Lebenszyklen der vTPMs verwalten. Als Beispiele kann die Verwaltung des Lebenszyklus des vTPM die Verwaltung jedes Aspekts des Lebenszyklus umfassen, wie z. B. das Erstellen eines vTPM 368, das Bereitstellen eines vTPM 368 mit Instanzmetadaten, das Anhängen eines vTPM 368 an eine Maschineninstanz, wie z. B. eine virtuelle Maschineninstanz 104, das Trennen eines vTPM 368 von einer Maschineninstanz, das Löschen eines vTPM 368, das Migrieren eines vTPM 368 zu einer anderen Maschineninstanz usw.
Bei der in 3 dargestellten Beispielimplementierung enthält die Computerplattform 302 einen Hypervisor 326 zur Verwaltung der Lebenszyklen der virtuellen Maschineninstanzen 104. Auf diese Weise kann der Hypervisor 326 beispielsweise virtuelle Maschineninstanzen 104 erstellen, die Ausführungen der virtuellen Maschineninstanzen 104 verwalten, physische Ressourcen der Computerplattform 302 emulieren, auf die die virtuellen Maschineninstanzen 104 zugreifen können, eine Isolierung zwischen den virtuellen Maschineninstanzen 104 bereitstellen und andere Virtualisierungsaufgaben durchführen.
Gemäß Beispielimplementierungen kann der Plattformcontroller 350 Teil des Hypervisors 326 sein und vTPMs als Emulationsgerät bereitstellen. Gemäß weiteren Beispielimplementierungen kann der Plattformcontroller 350 nicht Teil des Hypervisors 326 sein, und der Plattformcontroller 350 kann von einem Hardwareprozessor 304 der Computerplattform 302 getrennt und verschieden sein. In diesem Zusammenhang steht ein „Hardware-Prozessor“ für einen von mehreren Prozessorkernen, die maschinenlesbare Anweisungen ausführen. Der Hardware-Prozessor kann einen oder mehrere Mikroprozessoren, einen oder mehrere Rechenkerne eines Multi-Core-Mikroprozessors, einen Mikrocontroller, einen digitalen Signalprozessor usw. umfassen.
Der Hardware-Prozessor 304 ist mit der Brücken-/Busarchitektur 330 verbunden. Der Hardware-Prozessor 304 führt maschinenlesbare Anweisungen 342 aus, die im Systemspeicher 340 der Computerplattform 302 gespeichert sein können, der mit dem Hardware-Prozessor 304 verbunden ist. Die Ausführung der maschinenlesbaren Anweisungen 342 kann Softwarekomponenten der Computerplattform 302 bilden, wie den Hypervisor 326, die virtuellen Maschineninstanzen 104, ein Host-Betriebssystem (falls vorhanden) sowie andere Programme (einschließlich Softwareprogramme und/oder Firmwareprogramme). Der Systemspeicher 340 kann ein Speichergerät oder mehrere Speichergeräte umfassen, um Daten und maschinenlesbare Anweisungen zu speichern. Eine Speichervorrichtung kann eine flüchtige Speichervorrichtung wie einen dynamischen Direktzugriffsspeicher (DRAM), einen statischen Direktzugriffsspeicher (SRAM) usw. umfassen. Alternativ kann eine Speichervorrichtung auch eine nichtflüchtige Speichervorrichtung sein. Obwohl nicht dargestellt, kann der Systemspeicher 340 einen Speichercontroller enthalten, oder alternativ kann ein Speichercontroller mit der/den Speichervorrichtung(en) verbunden sein, um den Zugriff auf die Daten in der/den Speichervorrichtung(en) zu steuern.
An die Busarchitektur 330 können auch andere Geräte angeschlossen werden, darunter ein Netzwerkschnittstellen-Controller (NIC) 334 und ein persistenter Speicher 378. Der NIC 334 ist in der Lage, über ein Netzwerk zu kommunizieren, so dass die Komponenten der Computerplattform 302, einschließlich der virtuellen Maschineninstanzen 104, mit anderen Einheiten über das Netzwerk durch den NIC 334 kommunizieren können. In weiteren Beispielen kann ein physisches TPM auch mit der Busarchitektur 330 verbunden sein. Gemäß Beispielimplementierungen kann die NIC 334 ein „intelligentes E/A-Peripheriegerät“ (z. B. ein intelligenter Netzwerkschnittstellen-Controller oder „intelligentes NIC“) sein, das sich auf ein Peripheriegerät bezieht, das Verarbeitungsvorgänge auslagert, die traditionell von den Hauptverarbeitungskernen älterer Computersysteme durchgeführt wurden. Ein bestimmtes intelligentes E/A-Peripheriegerät kann zum Beispiel Backend-E/A-Dienste für die Computerplattform 302 bereitstellen. Zu den E/A-Diensten können beispielsweise Netzwerkvirtualisierungsdienste (z. B. Overlay-Netzwerkdienste, virtuelle Vermittlungsdienste, virtuelle Routingdienste und Netzwerkfunktionsvirtualisierungsdienste), Netzwerkspeicherdienste, Netzwerküberwachungsdienste, Speicherbeschleunigungsdienste (z. B. NVMe-basierte Dienste), Sicherheitsdienste (z. B. Kryptographiedienste und Netzwerk-Firewalldienste) usw. gehören. In Übereinstimmung mit Beispielimplementierungen kann der Plattformcontroller 350 eine intelligente Netzwerkkarte sein (z. B. eine PCle-basierte intelligente Netzwerkkarte).
Der persistente Speicher 378 kann Daten speichern, die auch dann erhalten bleiben, wenn die Computerplattform 100 oder der persistente Speicher 378 von der Stromversorgung getrennt wird. Der dauerhafte Speicher 378 kann mit einem nichtflüchtigen Speichergerät (oder mehreren nichtflüchtigen Speichergeräten) implementiert werden. Eine nichtflüchtige Speichervorrichtung kann eine Flash-Speichervorrichtung, eine plattenbasierte Speichervorrichtung usw. umfassen. In Übereinstimmung mit Beispielimplementierungen speichert der dauerhafte Speicher 378 eine vTPM-Zustandsdatei 370, die dem NVRAM-Abbild 136 (siehe 1) für ein bestimmtes vTPM entspricht.
In Übereinstimmung mit Beispielimplementierungen kann der Plattformcontroller 350 ein vTPM 368 unter Verwendung einer PCI-Funktion 360 emulieren, die vom Plattformcontroller 350 bereitgestellt wird. Es sei darauf hingewiesen, dass ein Hardware-TPM ein Nicht-PCI-Gerät ist. Wenn ein Hypervisor ein emuliertes virtuelles TPM-Gerät erstellt, emuliert der Hypervisor ein Hardware-TPM-Gerät als ein Nicht-PCI-Gerät. Wie hierin beschrieben, kann der Plattform-Controller 350 in Übereinstimmung mit Beispielimplementierungen mehrere emulierte Hardware-TPM-Geräte erstellen, um entsprechende vTPMs 368 (oder „vTPM-Geräte“) unter Verwendung von PCI Single Root I/O Virtualization (SR-IOV), wie von der PCI Special Interest Group (PCI-SIG) definiert, bereitzustellen. Gemäß Implementierungsbeispielen kann der Hypervisor 326 einer bestimmten virtuellen Maschineninstanz 104 eine PCI-Funktion 360 (oder mehrere PCI-Funktionen 360) zuweisen, um das vTPM 368 mit der virtuellen Maschineninstanz 104 zu verbinden.
In Übereinstimmung mit Beispielimplementierungen kann die PCI-Funktion 360 eine virtuelle Funktion (VF) sein, die der PCI SR-IOV entspricht. Die SR-IOV ermöglicht es einem PCIe-Gerät (z. B. einem vom Plattform-Controller 350 bereitgestellten vTPM 368), sich einem Host (z. B. der Computerplattform 100) als mehrere unterschiedliche virtuelle Geräte zu präsentieren. In Übereinstimmung mit Beispielimplementierungen implementiert der Plattform-Controller 350 eine PCIe Physical Function (PF), die in mehrere VFs unterteilt ist, wobei jede VF einem anderen vTPM 368 entsprechen kann. Die PF bietet Kontrolle über die Erstellung und Zuweisung von VFs. Die PF enthält eine SR-IOV-Fähigkeitsstruktur und verwaltet die SR-IOV-Funktionalität. Die PF kann wie jedes andere PCIe-Gerät in der Computerplattform 100 erkannt, verwaltet und manipuliert werden.
In Übereinstimmung mit weiteren Implementierungen kann die Funktion 360 eine andere Funktion als eine VF sein. In einigen Implementierungen enthält jede VF eine entsprechende vTPM 368.
Neben anderen Merkmalen kann der Plattform-Controller 350 einen Hardware-Prozessor und einen Speicher umfassen. Auf diese Weise kann der Prozessor des Plattformsteuergeräts 350 maschinenlesbare Anweisungen ausführen, die im Speicher gespeichert sind, um die hier beschriebenen Aufgaben des Plattformsteuergeräts 350 auszuführen.
In Übereinstimmung mit einigen Implementierungen kann der Hypervisor 326 mehrere vTPMs 368 erstellen, die in entsprechenden VFs enthalten sind, die von dem durch den Plattform-Controller 350 implementierten PF partitioniert sind.
In einigen Beispielen erstellt der Hypervisor 326 eine vTPM 368 auf Anforderung für eine entsprechende Instanz einer virtuellen Maschine 104 (d. h., die vTPM 368 wird erst dann für die Instanz einer virtuellen Maschine 104 erstellt, wenn eine Instanz einer virtuellen Maschine 104 oder eine andere Einheit, wie der Cloud-Orchestrator 170, die Erstellung der vTPM 368 anfordert). In anderen Beispielen erstellt der Hypervisor 326 die entsprechenden vTPMs, wenn die Instanzen der virtuellen Maschine 104 erstellt werden.
In Übereinstimmung mit Beispielimplementierungen kann jedes vTPM 368 einen eigenen und separaten Datenpfad für I/O-bezogene Funktionen (z. B. TPM-Lese- und Schreibvorgänge) innerhalb der PCIe-Hierarchie unterstützen. Außerdem teilen sich die vTPMs 368 die zugrunde liegende Hardware des Plattform-Controllers und die PCle-Schnittstelle zum PCI-Bus.
Gemäß den Beispielimplementierungen ermöglicht SR-IOV den TPM-Zugriff durch Instanzen virtueller Maschinen 104 unter Umgehung einer Emulationsschicht im Hypervisor 326. VFs gemäß SR-IOV sind leichtgewichtig, so dass eine große Anzahl von VFs in der Plattformsteuerung 350 implementiert werden kann. Wenn die Computerplattform 100 beispielsweise eine große Anzahl von Instanzen virtueller Maschinen 104 umfasst, kann eine entsprechend große Anzahl von VFs auf dem Plattform-Controller 350 implementiert werden, um die TPM-Emulation für die jeweiligen Instanzen virtueller Maschinen 104 durchzuführen.
Der Plattform-Controller 350 stellt in Übereinstimmung mit Beispielimplementierungen einen Steuerbereich 348 für jedes vTPM 368 bereit, der im Adressraum des Systemspeichers 340 abgebildet ist. Der Steuerbereich 348 entspricht den Steuer- und Statusregistern, die für die Interaktion zwischen einer virtuellen Maschineninstanz 104 und dem vTPM 368 verwendet werden. Gemäß der TPM 2.0-Spezifikation kann der Zugriff auf ein TPM durch Lese- und Schreibvorgänge an beliebig festgelegten Adressen erfolgen. Zu diesen Lese- und Schreibvorgängen gehören auch Lese- und Schreibvorgänge in den Registern und Speicherpuffern, die mit dem Steuerbereich 348 des vTPM 368 verbunden sind.
Die Instanz der virtuellen Maschine 104 kann mit einem Satz von ACPI-Tabellen (Advanced Configuration and Power Interface) sowie mit einer oder mehreren ACPI-Methoden 322 verbunden sein, die vom Hypervisor 326 bereitgestellt werden können. ACPI-Tabellen werden verwendet, um Informationen zu ACPI-Operationen zu speichern, einschließlich einer oder mehrerer Kombinationen von Erkennung und Konfiguration von Hardwarekomponenten, Energieverwaltung, Statusüberwachung von Komponenten und anderen Operationen. Eine ACPI-Methode bezieht sich auf eine Routine mit maschinenlesbaren Anweisungen, die zur Durchführung von ACPI-Vorgängen aufgerufen werden kann.
Eine der ACPI-Tabellen, die einer virtuellen Maschineninstanz 104 zugeordnet werden können, ist eine TPM2-Tabelle 344. 3 zeigt die TPM2-Tabellen 344 für die jeweiligen vTPMs 368 gemäß den Beispielimplementierungen. Wie in 3 dargestellt, können die TPM2-Tabellen 344 im Systemspeicher 340 gespeichert sein. Außerdem können die TPM2-Tabellen 344 in den Speicheradressraum der jeweiligen Steuerbereiche 348 eingeblendet werden. Die in den TPM2-Tabellen 344 gespeicherten Adressen können durch den Hypervisor 326 programmiert werden.
Beachten Sie, dass die in den jeweiligen TPM2-Tabellen 344 enthaltenen Adressen logische Adressen (anstelle von physischen Adressen) der jeweiligen Steuerbereiche 348 sein können. Der Hypervisor 326 kann Abbildungsinformationen (nicht dargestellt) bereitstellen, um die logischen Adressen in den TPM2-Tabellen 348 auf entsprechende physische Adressen abzubilden, die die Standorte der jeweiligen Steuerbereiche 348 identifizieren. Die Zuordnungsinformationen zur Zuordnung der logischen Adressen zu den physischen Adressen können beispielsweise in Form einer Tabelle der Speicherverwaltungseinheit (MMU) vorliegen, die dem Prozessor 304 zugeordnet ist. In anderen Beispielen können die Abbildungsinformationen andere Formen annehmen.
Es ist zu beachten, dass die logischen Adressen dieselbe logische Adresse sein können, nur dass sie durch die Zuordnungsinformationen auf unterschiedliche physikalische Adressen abgebildet werden. Alternativ können die logischen Adressen auch unterschiedliche logische Adressen sein.
In Übereinstimmung mit Beispielimplementierungen kann der Plattformcontroller 350 vTPMs emulieren, wie in der US-Patentanmeldung Nr. 2021/0271502 mit dem Titel „VIRTUAL TRUSTED PLATFORM MODULES“ beschrieben.
Der Plattform-Controller 350 kann gemäß weiteren Implementierungen aus anderer Hardware als der Hardware eines PCIe-Peripheriegeräts gebildet werden. Beispielsweise kann der Plattform-Controller 350 gemäß einigen Implementierungen ein Chassis-Management-Controller sein.
Als weiteres Beispiel kann der Plattform-Controller 350 in Übereinstimmung mit weiteren Implementierungen ein Baseboard-Management-Controller oder „BMC“ sein. Ein Baseboard-Management-Controller ist ein spezialisierter Dienstprozessor, der den physischen Zustand eines Servers oder anderer Hardware mithilfe von Sensoren überwacht und über ein Verwaltungsnetzwerk mit einem Verwaltungssystem kommuniziert. Der Baseboard-Management-Controller kann auch mit Anwendungen kommunizieren, die auf der Betriebssystemebene ausgeführt werden, und zwar über einen IOCTL-Schnittstellentreiber (Input/Output Controller), eine REST-API (Representational State Transfer) oder einen anderen Systemsoftware-Proxy, der die Kommunikation zwischen dem Baseboard-Management-Controller und den Anwendungen erleichtert. Der Baseboard-Management-Controller kann auf Hardware-Ebene auf Hardware-Geräte zugreifen, die sich in einem Servergehäuse befinden, einschließlich des Systemspeichers. Der Baseboard-Management-Controller kann in der Lage sein, die Hardware-Geräte direkt zu verändern. Der Baseboard-Management-Controller kann unabhängig vom Betriebssystem des Systems arbeiten, in dem der Baseboard-Management-Controller angeordnet ist. Der Baseboard-Management-Controller kann sich auf der Hauptplatine oder der Hauptplatine des Servers oder eines anderen zu überwachenden Geräts befinden. Die Tatsache, dass ein Baseboard-Management-Controller auf der Hauptplatine des zu überwachenden Servers/der zu überwachenden Hardware montiert oder anderweitig mit dem zu überwachenden Server/der zu überwachenden Hardware verbunden oder daran angebracht ist, verhindert nicht, dass der Baseboard-Management-Controller als vom Server/der zu überwachenden Hardware „getrennt“ betrachtet wird. Wie hierin verwendet, hat ein Baseboard-Management-Controller Verwaltungsfunktionen für Teilsysteme eines Computergeräts und ist von einer Verarbeitungsressource getrennt, die ein Betriebssystem eines Computergeräts ausführt. Der Baseboard-Management-Controller ist getrennt von einem Prozessor, z. B. einer Zentraleinheit, die ein High-Level-Betriebssystem oder einen Hypervisor auf einem System ausführt.
Gemäß weiteren Beispielimplementierungen kann der Controller 150 eine Softwarekomponente sein, die aus allgemeinen Hauptverarbeitungskernen der Computerplattform gebildet wird, die maschinenlesbare Anweisungen ausführen. Wie oben erwähnt, kann der Controller 150 in einigen Implementierungen beispielsweise ein Hypervisor sein, wie der Hypervisor 360, der in 3 dargestellt ist.
Bezug nehmend auf 4 beinhaltet ein Prozess 400 in Übereinstimmung mit Beispielimplementierungen die Bereitstellung (Block 404) eines virtuellen vertrauenswürdigen Plattformmoduls (vTPM) auf der Computerplattform durch einen Controller einer Computerplattform. Das Bereitstellen umfasst das Versorgen des vTPM mit Instanzdaten, die von einem Cloud-Orchestrator bereitgestellt werden. Der Prozess 400 umfasst das Zuordnen (Block 408) des vTPM zu einer Maschineninstanz durch den Controller. Der Prozess 400 umfasst das Starten (Block 412) der Maschineninstanz. Gemäß Block 416 umfasst der Prozess 400 als Reaktion auf den Start der Maschineninstanz den Zugriff auf die Instanz-Metadaten von der vTPM und die Konfiguration eines Betriebssystemabbilds der Maschineninstanz auf der Grundlage der I nstanz-Metadaten.
Wie in 5 gezeigt, umfasst eine Computerplattform 500 gemäß Beispielimplementierungen einen Controller 504, einen Prozessor 512 und einen Speicher 540. Der Controller 504 empfängt eine Anforderung 506 von einem Cloud-Orchestrator, einen virtuellen Sicherheitsprozessor 520 an eine Maschineninstanz 522 anzuschließen. Die Anforderung 506 enthält einen Verweis 508 auf ein persistentes Bild, das von einer Vertrauensquelle verwaltet wird, und das persistente Bild enthält Instanzmetadaten 510. Der Controller 504 instanziiert als Reaktion auf die Anforderung 506 den virtuellen Sicherheitsprozessor 520 auf der Grundlage des Verweises 508 und fügt den virtuellen Sicherheitsprozessor 520 an die Maschineninstanz 522 an. Die Instanziierung des virtuellen Sicherheitsprozessors 520 umfasst die Bereitstellung des virtuellen Sicherheitsprozessors 520 mit den Instanzmetadaten 510. Der Speicher 540 speichert Anweisungen 544, die, wenn sie vom Prozessor 512 ausgeführt werden, den Prozessor 512 veranlassen, auf die Instanzmetadaten 510 des virtuellen Sicherheitsprozessors 520 zuzugreifen und die Maschineninstanz 522 auf der Grundlage der Instanzmetadaten 510 zu konfigurieren.
Bezug nehmend auf 6 speichert ein nicht transitorisches, maschinenlesbares Speichermedium 600 gemäß Beispielimplementierungen maschinenausführbare Anweisungen 604, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, als Reaktion auf den Start einer Instanz einer Cloud-basierten Rechenumgebung auf Metadaten zuzugreifen, die in einem virtuellen vertrauenswürdigen Plattformmodul (vTPM) gespeichert sind. Die Metadaten stellen Konfigurationsparameter für die Instanz dar, und die Konfigurationsparameter umfassen einen Sicherheitsnachweis. Die Anweisungen 604 veranlassen, wenn sie von der Maschine ausgeführt werden, die Maschine außerdem, die Instanz auf der Grundlage der Metadaten zu konfigurieren. Diese Konfiguration umfasst das Konfigurieren einer Zugriffskontrolle der Instanz mit dem Sicherheitsnachweis.
Gemäß Beispielimplementierungen umfasst das Konfigurieren des Betriebssystemabbilds das Konfigurieren des Betriebssystemabbilds mit einer Benutzerberechtigung, die durch die Metadaten dargestellt wird, und das Konfigurieren des Betriebssystemabbilds mit Informationen, die für die Maschineninstanz spezifisch sind. Ein besonderer Vorteil ist, dass die sensiblen Informationen in den Instanz-Metadaten sehr widerstandsfähig gegen Sicherheitsangriffe sind.
Gemäß Beispielimplementierungen umfasst die Bereitstellung des vTPM das Erzeugen des vTPM durch den Controller als Reaktion darauf, dass der Controller eine Anforderung vom Cloud-Orchestrator zur Erzeugung des vTPM erhält. Die Anforderung enthält Daten, die die Instanz-Metadaten darstellen. Das Bereitstellen der vTPM umfasst ferner das Erzeugen eines Abbilds des persistenten Speichers auf der Grundlage der Instanz-Metadaten. Das Abbild des persistenten Speichers entspricht der vTPM. Die Bereitstellung des vTPM umfasst ferner die Übermittlung des Abbilds des persistenten Speichers an den Cloud-Orchestrator, damit der Cloud-Orchestrator es als Vertrauensquelle beibehalten kann, und die Erstellung eines Cache auf der Computerplattform, um eine Kopie des Abbilds des persistenten Speichers zu speichern. Ein besonderer Vorteil besteht darin, dass die sensiblen Informationen in den Metadaten der Instanz sehr widerstandsfähig gegen Sicherheitsangriffe sind.
Gemäß Beispielimplementierungen hält der Controller als Reaktion auf eine Anforderung des Cloud-Orchestrators, die Maschineninstanz anzuhalten, die Maschineninstanz an und löscht den Cache. Ein besonderer Vorteil ist, dass sensible Informationen in den Instanz-Metadaten sehr widerstandsfähig gegen Sicherheitsangriffe sind.
In Übereinstimmung mit Beispielimplementierungen beinhaltet die Bereitstellung des vTPM, dass der Controller das vTPM von einer anderen Maschineninstanz verschiebt, und die Bereitstellung beinhaltet, dass der Controller ein dem vTPM zugeordnetes Abbild des persistenten Speichers aktualisiert. Ein besonderer Vorteil ist, dass die sensiblen Informationen in den Instanz-Metadaten sehr widerstandsfähig gegen Sicherheitsangriffe sind.
In Übereinstimmung mit Beispielimplementierungen umfasst die Bereitstellung des vTPM mit den Instanz-Metadaten ferner die Einrichtung mindestens einer Zugriffskontrolle oder einer Zugriffsrichtlinie für den Zugriff auf die Instanz-Metadaten. Ein besonderer Vorteil ist, dass die sensiblen Informationen in den Instanz-Metadaten sehr widerstandsfähig gegen Sicherheitsangriffe sind.
In Übereinstimmung mit Beispielimplementierungen umfasst die Festlegung der Zugriffskontrolle und/oder der Zugriffsrichtlinie die Zuordnung der Instanz-Metadaten zu einem Indexwert und die Versiegelung der Instanz-Metadaten mit einem Plattformkonfigurationsregisterzustand. Ein besonderer Vorteil ist, dass die sensiblen Informationen in den Instanz-Metadaten sehr widerstandsfähig gegen Sicherheitsangriffe sind.
In Übereinstimmung mit Beispielimplementierungen kann der Controller ein Plattform-Controller, ein Hypervisor oder ein Baseboard-Management-Controller sein. Ein besonderer Vorteil ist, dass die sensiblen Informationen in den Instanz-Metadaten sehr widerstandsfähig gegen Sicherheitsangriffe sind.
In Übereinstimmung mit Beispielimplementierungen kann die Maschineninstanz eine virtuelle Maschineninstanz oder eine Bare-Metal-Instanz sein. Ein besonderer Vorteil ist, dass die sensiblen Informationen in den Metadaten der Instanz sehr widerstandsfähig gegen Sicherheitsangriffe sind.
In Übereinstimmung mit Beispielimplementierungen wird als Reaktion auf das Starten der Maschineninstanz ein Startskript ausgeführt, um auf die Instanz-Metadaten vom vTPM zuzugreifen und ein Betriebssystem-Image der Maschineninstanz basierend auf den Instanz-Metadaten zu konfigurieren. Ein besonderer Vorteil ist, dass die sensiblen Informationen in den Instanz-Metadaten sehr widerstandsfähig gegen Sicherheitsangriffe sind.
In Übereinstimmung mit Beispielimplementierungen empfängt der Controller eine Anforderung vom Cloud-Orchestrator, die Maschineninstanz zu starten. Die Anforderung enthält einen Verweis auf eine Vertrauensquelle, und die Vertrauensquelle enthält ein persistentes Bild, das die Instanzmetadaten enthält. Als Reaktion auf die Anforderung instanziiert der Controller das vTPM, stattet das vTPM mit dem persistenten Image aus und fügt das vTPM an die Maschineninstanz an. Ein besonderer Vorteil ist, dass die sensiblen Informationen in den Instanz-Metadaten sehr widerstandsfähig gegen Sicherheitsangriffe sind.
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 schätzen. Es ist beabsichtigt, dass die beigefügten Ansprüche alle derartigen Modifikationen und Variationen abdecken.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2021/0271502 [0059]

Claims

Ein nicht-transitorisches, maschinenlesbares Speichermedium, das maschinenausführbare Befehle speichert, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen,: als Reaktion auf einen Start einer Instanz einer Cloud-basierten Rechenumgebung auf Metadaten zugreifen, die in einem virtuellen vertrauenswürdigen Plattformmodul (vTPM) gespeichert sind, wobei die Metadaten Konfigurationsparameter für die Instanz darstellen und die Konfigurationsparameter einen Sicherheitsnachweis enthalten; und Konfigurieren der Instanz auf der Grundlage der Metadaten, einschließlich des Konfigurierens einer Zugriffskontrolle der Instanz mit dem Sicherheitsnachweis.
Das Speichermedium nach Anspruch 1, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, ferner die Maschine veranlassen, ein Betriebssystem der Maschineninstanz auf der Grundlage der Metadaten zu konfigurieren.
Das Speichermedium nach Anspruch 1, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine außerdem veranlassen, mit einem Cloud-Orchestrator zu kommunizieren, um das vTPM zu verwalten.
Das Speichermedium nach Anspruch 3, wobei die Verwaltung des vTPM mindestens eines der folgenden Elemente umfasst: Erzeugen des vTPM, Anfügen des vTPM an die Instanz, Lösen des vTPM von der Instanz, Löschen des vTPM oder Verschieben des vTPM in eine andere Instanz.
Ein Verfahren, das Folgendes umfasst: Bereitstellen eines virtuellen vertrauenswürdigen Plattformmoduls (vTPM) auf der Computerplattform durch einen Controller einer Computerplattform, wobei das Bereitstellen das Versehen des vTPM mit Instanzmetadaten umfasst, die von einem Cloud-Orchestrator bereitgestellt werden; Zuordnen des vTPM zu einer Maschineninstanz durch den Controller; Starten der Maschineninstanz durch den Controller; und als Reaktion auf das Starten der Maschineninstanz, Zugreifen auf die Instanz-Metadaten von der vTPM und Konfigurieren eines Betriebssystem-Images der Maschineninstanz basierend auf den Instanz-Metadaten.
Das Verfahren nach Anspruch 5, wobei das Konfigurieren des Betriebssystemabbilds das Konfigurieren des Betriebssystemabbilds mit einer durch die Metadaten dargestellten Benutzerberechtigung und das Konfigurieren des Betriebssystemabbilds mit für die Maschineninstanz spezifischen Informationen umfasst.
Das Verfahren nach Anspruch 5, wobei die Bereitstellung des vTPM umfasst: Erzeugen des vTPM durch den Controller in Reaktion darauf, dass der Controller eine Anforderung vom Cloud-Orchestrator zum Erzeugen des vTPM empfängt, wobei die Anforderung die Instanz-Metadaten umfasst; Erzeugen eines persistenten Speicherabbilds auf der Grundlage der Instanz-Metadaten, wobei das persistente Speicherabbild dem vTPM entspricht; Übermittlung des Bildes des persistenten Speichers an den Cloud-Orchestrator, damit der Cloud-Orchestrator es als Vertrauensquelle beibehält; und Erstellung eines Caches auf der Computerplattform, um eine Kopie des Abbilds des persistenten Speichers zu speichern.
Das Verfahren nach Anspruch 7 umfasst ferner: als Reaktion auf eine Aufforderung des Cloud-Orchestrators, die Maschineninstanz zu stoppen, die Steuerung die Maschineninstanz stoppt und die Steuerung den Cache löscht.
Das Verfahren nach Anspruch 5, wobei das Bereitstellen des vTPM darin besteht, dass der Controller das vTPM von einer anderen Maschineninstanz verschiebt, und das Bereitstellen darin besteht, dass der Controller ein dem vTPM zugeordnetes Bild des persistenten Speichers aktualisiert.
Das Verfahren nach Anspruch 5, wobei das Bereitstellen des vTPM mit den Instanz-Metadaten ferner das Einrichten mindestens einer Zugriffskontrolle oder einer Zugriffsrichtlinie für den Zugriff auf die Instanz-Metadaten umfasst.
Das Verfahren nach Anspruch 10, wobei das Einrichten mindestens eines der folgenden Schritte umfasst: Zuordnen der Instanz-Metadaten zu einem Indexwert und Versiegeln der Instanz-Metadaten mit einem Plattformkonfigurations-Registerzustand.
Das Verfahren nach Anspruch 5, wobei der Controller einen Plattform-Controller, einen Hypervisor oder einen Baseboard-Management-Controller umfasst.
Das Verfahren nach Anspruch 5, wobei die Maschineninstanz eine virtuelle Maschineninstanz oder eine Bare-Metal-Instanz umfasst.
Das Verfahren nach Anspruch 5, das ferner umfasst, dass als Reaktion auf das Starten der Maschineninstanz ein Startskript der Computerplattform ausgeführt wird, um auf die Instanz-Metadaten vom vTPM zuzugreifen und ein Betriebssystem-Image der Maschineninstanz auf der Grundlage der Instanz-Metadaten zu konfigurieren.
Das Verfahren nach Anspruch 5 umfasst ferner: Empfangen einer Anforderung vom Cloud-Orchestrator zum Starten der Maschineninstanz durch den Controller, wobei die Anforderung einen Verweis auf eine Vertrauensquelle enthält und die Vertrauensquelle ein dauerhaftes Bild umfasst, das die Instanz-Metadaten enthält; und Als Reaktion auf die Anforderung instanziiert der Controller das vTPM, stellt das vTPM mit dem persistenten Image bereit und fügt das vTPM an die Maschineninstanz an.
Eine Computerplattform, bestehend aus: einen Controller an: eine Anforderung von einem Cloud-Orchestrator empfangen, um einen virtuellen Sicherheitsprozessor an eine Maschineninstanz anzuschließen, wobei die Anforderung einen Verweis auf ein dauerhaftes Bild umfasst, das von einer Vertrauensquelle gepflegt wird, und das dauerhafte Bild Instanz-Metadaten enthält; und als Reaktion auf die Anforderung den virtuellen Sicherheitsprozessor auf der Grundlage der Referenz instanziieren und den virtuellen Sicherheitsprozessor mit der Maschineninstanz verbinden, wobei die Instanziierung des virtuellen Sicherheitsprozessors die Bereitstellung des virtuellen Sicherheitsprozessors mit den Instanzmetadaten umfasst; einen Prozessor; und einen Speicher zum Speichern von Befehlen, die, wenn sie von dem Prozessor ausgeführt werden, den Prozessor veranlassen,: Zugriff auf die Instanz-Metadaten von dem virtuellen Sicherheitsprozessor; und die Maschineninstanz auf der Grundlage der Instanz-Metadaten konfigurieren.
Die Computerplattform nach Anspruch 16, wobei der Controller mindestens einen Hypervisor, einen Plattform-Controller oder einen Baseboard-Management-Controller umfasst.
Die Computerplattform nach Anspruch 16, wobei der Controller zu: Empfangen einer Anforderung vom Cloud-Orchestrator zum Erstellen des virtuellen Sicherheitsprozessors, wobei die Anforderung die Instanz-Metadaten umfasst; und Als Reaktion auf die Anforderung, den virtuellen Sicherheitsprozessor zu erstellen, erstellt der Controller das dauerhafte Bild auf der Grundlage der Instanz-Metadaten und übermittelt die Referenz an den Cloud-Orchestrator.
Die Computerplattform nach Anspruch 16, wobei die Maschineninstanz eine zweite Maschineninstanz umfasst, und die Steuerung zu: Empfangen einer Anforderung von dem Cloud-Orchestrator, den virtuellen Sicherheitsprozessor von einer ersten Maschineninstanz zu der zweiten Maschineninstanz zu verschieben, wobei die Anforderung die Referenz- und Instanzmetadaten umfasst, die der zweiten Maschineninstanz entsprechen; und als Reaktion auf die Anforderung erzeugt der Controller ein zweites beständiges Bild, das der zweiten Maschineninstanz entspricht, und übermittelt das zweite beständige Bild an den Cloud-Orchestrator, um es in der Vertrauensquelle aufrechtzuerhalten, wobei das zweite beständige Bild die Instanz-Metadaten enthält, die der zweiten Maschineninstanz entsprechen.
Die Computerplattform nach Anspruch 19, wobei das zweite dauerhafte Bild Benutzerdaten umfasst, die von der ersten Maschineninstanz im virtuellen Sicherheitsprozessor gespeichert wurden.