DE112017004033T5

DE112017004033T5 - Verfahren zum Erhalten von geprüften Zertifikaten durch Mikrodienste in elastischen Cloud-Umgebungen

Info

Publication number: DE112017004033T5
Application number: DE112017004033.7T
Authority: DE
Inventors: Adam C. Lewis; Anthony R. Metke; Shanthi E. Thomas
Original assignee: Motorola Solutions Inc
Current assignee: Motorola Solutions Inc
Priority date: 2016-08-11
Filing date: 2017-07-27
Publication date: 2019-05-09
Also published as: GB201900651D0; GB2566874B; GB2566874A; US20180048638A1; US10404680B2; WO2018031242A1

Abstract

Es wird ein Verfahren und ein Mikrodienst zum Erhalten eines geprüften Zertifikats für einen Mikrodienst in einer elastischen Cloud-Umgebung angegeben. Der Mikrodienst empfängt einen Einmal-Authentifizierungsberechtigungsnachweis. Der Mikrodienst verwendet den Einmal-Authentifizierungsberechtigungsnachweis, um ein Client-Geheimnis zu erhalten 5. Der Mikrodienst erhält einen Zugriffs-Token und CSR-Attribute (CSR = Certificate Signing Request/Zertifikatsignieranforderung) unter Verwendung des Client-Geheimnisses, und er erstellt eine CSR unter Verwendung der CSR-Attribute. Der Mikrodienst fordert ein geprüftes Zertifikat von einer CA (CA = Certificate Authority/Zertifikatautorität) an, und fügt den Zugriffs-Token und die CSR in die Anforderung ein. Wenn der Zugriffs-Token und die CSR eine Prüfung bei der CA bestehen, sendet die CA ein geprüftes Zertifikat an den Mikrodienst 10.

Description

HINTERGRUND DER ERFINDUNG
Containerisierte, cloud-basierte, elastische Architekturen werden populärer. Jeder Container enthält typischerweise eine Anwendung oder einen Mikrodienst. Die Anwendung oder der Mikrodienst erfordert eine sichere Kommunikation mit anderen containerisierten Anwendungen oder Mikrodiensten.
Ein Problem mit Containern besteht in der Notwendigkeit im Transit befindliche Daten zu schützen. Die Anwendungen und Mikrodienste müssen auch dazu in der Lage sein, sich gegenseitig zu authentifizieren. Ein Verfahren hierzu ist die Verwendung von SSL (Secure Sockets Layer), wobei es sich um eine Sicherheitstechnologie zum Einrichten einer verschlüsselten Verbindung zwischen zwei Anwendungen handelt. SSL adressiert beide dieser Sicherheitsanforderungen; SSL hängt jedoch von X.509-Zertifikaten ab, wobei in diesem Fall jeder Container ein Öffentlich-Privat-Schlüsselpaar und ein entsprechendes Zertifikat benötigen wird.
Ein Problem bei der Verwendung von SSL in containerisierten Umgebungen besteht darin, dass Container in elastischen Umgebungen existieren, wo Container dynamisch erzeugt werden, um die Nachfrage zu befriedigen, zerstört werden, wenn sie nicht länger gebraucht werden, und wieder erzeugt werden, wenn die Nachfrage erneut ansteigt. Dies ist nicht die Umgebung, für die SSL ausgelegt wurde.
Ein weiteres Problem besteht darin, dass die Verwendung in Cloud-Umgebungen vollständig automatisiert ist. Weil kein Mensch präsent ist, können sich Cloud-Netzwerke nicht darauf verlassen, eine Berechtigung eines Menschen zu verwenden, um die Identität des Containers, der erzeugt wird, zu verifizieren und zu bestätigen. Weiterhin ist es aus einem Sicherheitsstandpunkt unakzeptabel, zu versuchen, die privaten Schlüssel in die Containerimages einzubacken, weil sie leicht herausleaken, was zu Sicherheitsverletzlichkeiten führt.
Es besteht daher ein Bedarf an einem verbesserten Verfahren zur Bereitstellung von sicherer Kommunikation zwischen Mikrodiensten in elastischen Cloud-Umgebungen.
Figurenliste
Die begleitenden Figuren, in denen sich gleiche Bezugszeichen auf identische oder funktionell ähnliche Elemente durch die getrennten Ansichten hindurch beziehen, werden zusammen mit der nachfolgenden detaillierten Beschreibung in die Spezifizierung aufgenommen, und sie bilden einen Teil davon, und sie dienen zur weiteren Veranschaulichung von Ausführungsformen von Konzepten, die die beanspruchte Erfindung enthalten, und sie erläutern verschiedene Prinzipien und Vorteile dieser Ausführungsformen.

1 ist ein Systemdiagramm, das ein Cloud-Netzwerk gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung veranschaulicht.
2 zeigt ein Flussdiagramm, das einen Prozess zum Registieren eines Mikrodienstes in einer elastischen Cloud-Umgebung veranschaulicht, gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung.
3 zeigt ein Flussdiagramm, das einen Prozess zum Erhalten eines geprüften Zertifikats durch einen Mikrodienst in einer elastischen Cloud-Umgebung veranschaulicht, gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung.

Fachleute werden erkennen, dass Elemente in den Figuren zum Zwecke der Einfachheit und Klarheit veranschaulicht sind und nicht notwendigerweise maßstabsgetreu gezeichnet sind. Zum Beispiel können die Abmessungen einiger der Elemente in den Figuren im Vergleich zu anderen Elementen übertrieben sein, um dabei zu helfen, das Verständnis von Ausführungsformen der vorliegenden Erfindung zu verbessern.
Die Vorrichtungs- und Verfahrenskomponenten wurden dort, wo es angemessen erscheint, durch konventionelle Symbole in den Zeichnungen dargestellt, wobei nur jene spezifischen Einzelheiten gezeigt werden, die für ein Verständnis der Ausführungsformen der vorliegenden Erfindung wesentlich sind, um so die Offenbarung nicht mit Einzelheiten zu verschleiern, die für jene Durchschnittsfachleute ohne weiteres erkennbar sind, die den Vorteil dieser Beschreibung genießen.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Offenbart wird ein verbessertes Verfahren und eine verbesserte Vorrichtung zum Erhalten eines geprüften Zertifikats für einen Mikrodienst in einer elastischen Cloud-Umgebung. Der Mikrodienst empfängt einen Einmal-Authentifizierungsberechtigungsnachweis und verwendet den Einmal-Authentifizierungsberechtigungsnachweis, um ein Client-Geheimnis zu erhalten. Der Mikrodienst erhält einen Zugriffs-Token, der CSR-Attribute (CSR = Certificate Signing Request/Zertifikatsignieranforderung) enthält, die das Client-Geheimnis verwenden. Der Mikrodienst erstellt eine CSR unter Verwendung der CSR-Attribute. Der Mikrodienst fordert ein geprüftes Zertifikat von einer CA (CA = Certificate Authority/Zertifikatautorität) an, indem er eine Anforderung, die den Zugriffs-Token und die CSR enthält, an die CA sendet. Die CA prüft die Anforderung, indem sie die in der CSR angeforderten Attribute mit Attributen abgleicht, die in dem Zugriffs-Token eingebettet sind. Wenn es eine Übereinstimmung gibt, betrachtet die CA die CSR als geprüft und die CA sendet ein geprüftes Zertifikat an den Mikrodienst.
1 ist ein Systemdiagramm, das ein Cloud-Netzwerk 100 gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung veranschaulicht. Das Cloud-Netzwerk 100 umfasst vorzugsweise einen Administrator 101, einen zweiten Mikrodienst 103, einen ersten Mikrodienst 105, einen Autorisierungsserver 107, eine Datenbank 109, einen Geheimnisserver 111 und eine Zertifikatautorität 113.
Der Administrator 101 ist an den zweiten Mikrodienst 103, den Autorisierungsserver 107 und den Geheimnisserver 111 gekoppelt. Der Administrator 101 kann eine Person, eine Computervorrichtung oder eine Kombination aus beidem sein. Der Administrator 101 ermöglicht eine Anmeldung und ein Management von Benutzern und ihrem Zugriff auf Server oder Dienste.
Der Administrator 101 erzeugt einen Geheimnismanagementbehälter in dem Geheimnisserver 111, auf den vorzugsweise über einen Token und andere Berechtigungsnachweise zugegriffen wird, wie beispielsweise eine APP_ID oder eine BENUTZER_ID, einen Benutzernamen oder ein Password oder Zertifikate. Der Administrator 101 leitet diese Informationen an den zweiten Mikrodienst 103 weiter. Der Administrator 101 erzeugt vorzugsweise auch einen Client bei dem Autorisierungsserver 107, unter Verwendung einer Client-ID und eines Client-Geheimnisses. Der Administrator 101 speichert vorzugsweise auch die Client-ID und das Client-Geheimnis in dem Geheimnisserver 111. Der Administrator 101 erzeugt weiterhin eine APP_ID und speichert sie in dem Geheimnisserver 111.
Der zweite Mikrodienst 103 ist ein Mikrodienst, der dabei hilft, sichere Container in einem cloud-basierten Netzwerk einzurichten. Der zweite Mikrodienst 103 ist an den Administrator 101 und den Geheimnisserver 111 gekoppelt. Wie hier verwendet, ist ein Mikrodienst ein Prozess, der mit einem anderen Mikrodienst kommuniziert, um ein Ziel innerhalb des Cloud-Netzwerks 100 zu erreichen. Mikrodienste sind typischerweise kleine Softwaremodule, die leichtgewichtige Protokolle verwenden. Der zweite Mikrodienst 103 erzeugt eine neue BENUTZER_ID und bildet die BENUTZER_ID auf der APP_ID in dem Geheimnismanagementbehälter ab. Der zweite Mikrodienst 103 erzeugt auch einen neuen Mikrodienst, den ersten Mikrodienst 105, und er leitet ihm die APP_ID/BENUTZER_ID weiter.
Der erste Mikrodienst 105 ist an den Autorisierungsserver 107, den Geheimnisserver 111 und die Zertifikatautorität 113 gekoppelt. Der erste Mikrodienst 105 umfasst vorzugsweise einen Transceiver und einen an den Transceiver gekoppelten Prozessor. Der erste Mikrodienst 105 loggt sich bei dem Geheimnisserver 111 unter Verwendung des APP_ID/BENUTZER_ID-Tupels ein und ruft die Client-ID und das Client-Geheimnis ab. Der erste Mikrodienst 105 verwendet die Client-ID und das Client-Geheimnis, um einen Zugriffs-Token abzurufen, der autorisierte CSR-Attribute von dem Autorisierungsserver 107 umfasst. Bei einer beispielhaften Ausführungsform erzeugt der erste Mikrodienst 105 ein Schlüsselpaar und eine CSR, zumindest teilweise auf den CSR-Attributen und dem Zugriffs-Token basierend. Der erste Mikrodienst 105 sendet den Zugriffs-Token und die CSR an die Zertifikatautorität 113, die die CSR prüft, indem sie die die in der CSR enthaltenen Attribute mit den Attributen abgleicht, die in dem Zugriffs-Token enthalten sind, und sie sendet ein Zertifikat an den ersten Mikrodienst 105 zurück, wenn die Werte zueinander passen und die Überprüfung erfolgreich ist.
Der Autorisierungsserver 107 ist eine Anwendung, die dazu verwendet wird, die Berechtigungsnachweise von einem Mikrodienst zu authentifizieren, um den Mikrodienst zu autorisieren, auf einen oder mehrere andere Mikrodienste zuzugreifen. Die Berechtigungsnachweise, können, beispielsweise, Client-Identifizierer und Passwörter sein. Der Autorisierungsserver 107 ist an den Administrator 101, den ersten Mikrodienst 105 und die Datenbank 109 gekoppelt. Der Autorisierungsserver 107 kann sich auf einem zugewiesenen Computer befinden, er kann jedoch alternativ auch in einem Ethernet-Switch, einem Zugriffspunkt oder einem Netzwerkzugriffsserver untergebracht sein. Der Autorisierungsserver 107 gibt beim Verifizieren von Berechtigungsnachweisen vorzugsweise einen Token aus, der dazu verwendet werden kann, auf verschiedene Dienste zuzugreifen.
Die Datenbank 109 ist an den Autorisierungsserver 107 gekoppelt, und sie ermöglicht eine Speicherung von Informationen für den Autorisierungsserver 107. Gemäß einer beispielhaften Ausführungsform speichert die Datenbank 109 eine Client-ID und CSR-Attribute.
Der Geheimnisserver 111 ist an den Administrator 101, den zweiten Mikrodienst 103 und den ersten Mikrodienst 105 gekoppelt. Der Geheimnisserver 111 ermöglicht ein sicheres Passwortmanagement in dem Netzwerk 100. Der Geheimnisserver 111 ermöglicht vorzugsweise die Fähigkeit, Geheimnisse zu managen und zu organisieren, Benutzerberechtigungen zuzuordnen und auf Steuerrichtlinien für die Geheimnisse zuzugreifen, eine Verschlüsselung und Authentifizierung zu ermöglichen, und er ermöglicht eine Notfallwiederherstellung.
Die Zertifikatautorität 113 ist an den ersten Mikrodienst 105 gekoppelt, und sie ist eine Einheit, die digitale Zertifikate ausgibt. Ein digitales Zertifikat zertifiziert den Besitz eines öffentlichen Schlüssels durch den benannten Gegenstand des Zertifikats, was es darauf vertrauenden Parteien ermöglicht, sich auf Signaturen zu verlassen, die über den privaten Schlüssel gemacht wurden, der dem zertifizierten öffentlichen Schlüssel entspricht.
2 zeigt ein Flussdiagramm, das einen Prozess zum Registrieren eines Mikrodienstes in einer elastischen Cloud-Umgebung veranschaulicht, gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Der Administrator 101 erzeugt 201 eine Anwendungs-ID, APP_ID. Die APP_ID repräsentiert eine Anwendung, bei einer beispielhaften Ausführungsform einen Mikrodienst, der in einer elastischen Cloud-Umgebung lebt.
Der Administrator 101 erzeugt 203 eine Client_ID und ein Client_Geheimnis. Die Client_ID und das Client_Geheimnis werden von dem ersten Mikrodienst 105 dazu verwendet werden, sich bei dem Autorisierungsserver 107 zu authentifizieren und einen Zugriffs-Token zu erhalten.
Der Administrator 101 sendet eine Speichere-APP_ID-Nachricht 205 an den Geheimnisserver 111. Die Speichere-APP_ID-Nachricht 205 umfasst die APP_ID, und sie wird an den Geheimnisserver 111 gesendet, so dass der Geheimnisserver 111 die APP_ID speichern wird.
Der Administrator 101 sendet eine Neue-OAuth-Client-Nachricht 207 an den Autorisierungsserver 107. Die Neue-OAuth-Client-Nachricht 207 umfasst die Client_ID und das Client_Geheimnis.
Der Administrator 101 sendet eine Speichere-Client_ID und Client-Geheimnis und Geheimnisnachricht 209 an den Geheimnisserver 111.
Der zweite Mikrodienst 103 sendet eine Fordere-Geheimnis_Server_Client_Token-An-Nachricht 211 an den Administrator 101.
Der Administrator 101 antwortet dem zweiten Mikrodienst 103 mit einer Geheimnisserver-Client-Token-Nachricht 213, die den Geheimnis_Server_Client_Token umfasst.
Der zweite Mikrodienst 103 sendet eine Login-Nachricht 215 an den Geheimnisserver 111. Die Login-Nachricht 215 umfasst den Geheimnis_Server_Client_Token.
Der zweite Mikrodienst 103 sendet eine Fordere-App-ID-An-Nachricht 217 an den Geheimnisserver 111. Die Fordere-App-ID-An-Nachricht 217 umfasst vorzugsweise den Geheimnis_Server_Client_Token.
Der Geheimnisserver 111 sendet eine Gib-App-ID-Zurück-Nachricht 219 an den zweiten Mikrodienst 103.
Der zweite Mikrodienst 103 erzeugt 221 eine Benutzer_ID.
Der zweite Mikrodienst 103 sendet eine Abbildungsnachricht 223 an den Geheimnisserver 111. Die Abbildungsnachricht 223 umfasst Sicherheitsmanagementauthentifizierungsberechtigungsnachweise, bei dieser beispielhaften Ausführungsform die APP_ID und die Benutzer_ID. Die Abbildungsnachricht 223 umfasst vorzugsweise einen Geheimnis_Server_Client_Token.
Der zweite Mikrodienst 103 leitet 225 die APP_ID und die BENUTZER_ID zu dem ersten Mikrodienst 105 weiter.
3 zeigt ein Flussdiagramm, das einen Prozess zum Erhalten eines geprüften Zertifikats durch einen Mikrodienst in einer elastischen Cloud-Umgebung veranschaulicht, gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Bei einer beispielhaften Ausführungsform loggt sich der erste Mikrodienst 105 in das Mikrodienstsystem ein, indem er eine Login-Nachricht 301 an den Geheimnisserver 111 sendet. Die Login-Nachricht 301 umfasst die APP_ID und die Benutzer_ID des angeforderten Mikrodienstes.
Der erste Mikrodienst 105 sendet eine Rufe-Geheimnis-Ab-Nachricht 303 an den Geheimnisserver 111. Die Rufe-Geheimnis-Ab-Nachricht 303 umfasst die Client_ID, das Client_Geheimnis und den Geheimnis_Server_Client_Token des gewünschten Mikrodienstes. Unter Verwendung von Nachrichten 303 und 305 verwendet der erste Mikrodienst 105 die Geheimnismanagement-Authentifizierungsberechtigungsnachweise, um ein Client-Geheimnis von einem Geheimnismanagementdienst zu erhalten.
Als Antwort auf die Rufe-Geheimnis-Ab-Nachricht 303 sendet der Geheimnisserver 111 eine Geheimnis-Zurückgegeben-Nachricht 305 an den ersten Mikrodienst 105. Die Geheimnis-Zurückgegeben-Nachricht 305 umfasst die Client-ID und das Client_Geheimnis, die zur Authentifizierung am Autorisierungsserver 107 erforderlich sind.
Der erste Mikrodienst 105 sendet eine Fordere-Token-An-Nachricht 307 an den Autorisierungsserver 107. Die Fordere-Token-An-Nachricht 307 umfasst die Client_ID und das Client_Geheimnis. Unter Verwendung von Nachrichten 307, 309, 311 und 313 verwendet der erste Mikrodienst 105 das Client-Geheimnis, um einen Zugriffs-Token zu erhalten, der zumindest ein Attribut enthalten wird, das der Mikrodienst in seiner CSR anfordern wird und das zur Prüfung der CSR-Anforderung verwendet werden wird.
Der Autorisierungsserver 107 sendet eine Erhalte-Attribute-Nachricht 309 an die Datenbank 109. Die Erhalte-Attribute-Nachricht 309 umfasst die Client_ID.
Die Datenbank 109 sendet eine Erhalte-Attribute-Antwort 311 an den Autorisierungsserver 107. Die Erhalte-Attribute-Antwort 311 umfasst CSR_Attribute.
Der Autorisierungsserver 107 sendet eine Erhalte-Token-Antwort-Nachricht 313 an den ersten Mikrodienst 105. Die Erhalte-Token-Antwort-Nachricht 313 umfasst einen OAuth_Zugriffs_Token, der die CSR_Attribute enthält.
Der erste Mikrodienst 105 erzeugt (315) ein Schlüssel_Paar und eine CSR. Das Schlüssel_Paar ist vorzugsweise ein Öffentlich-Privat-Schlüsselpaar.
Der erste Mikrodienst 105 sendet eine Erhalte-Zertifikat-Nachricht 317 an die CA 113. Die Erhalte-Zertifikat-Nachricht 317 enthält vorzugsweise die CSR und den OAuth_Client-Token.
Die CA 113 prüft (319) die CSR, vorzugsweise indem sie Attribute in der CSR mit den Attributen in dem Zugriffs-Token abgleicht.
Wenn die CA 113 die Attribute abgleicht, sendet die CA 113 eine Zertifikat-Antwort-Nachricht 321 an den ersten Mikrodienst 105. Die Zertifikat-Antwort-Nachricht 321 enthält ein Zertifikat, das die Anforderung und die geprüften Attribute enthält. Bei einer beispielhaften Ausführungsform ist das Zertifikat ein signiertes X.509-Zertifikat.
Aus dem vorstehenden ergibt sich ein verbessertes Verfahren und eine verbesserte Vorrichtung zum Bereitstellen einer Top-Level-Orchestrierungsfunktion zum Koordinieren von Client-Identitäten, Client-Berechtigungsnachweisen und Client-Attributen über eine Mehrzahl von Architekturkomponenten. Ein verbessertes Verfahren und eine verbesserte Vorrichtung werden auch zur Verwendung dieser koordinierten Identitäten, Berechtigungsnachweise und Attribute bereitgestellt, um einen Zugriffs-Token zu erhalten, der verwendet wird, um eine Zertifikat-Signierungs-Anforderung dynamisch zu registrieren und zu prüfen. Das Verfahren und die Vorrichtung ermöglichen es containerisierten Apps und Mikrodiensten geprüfte Zertifikate zu erhalten, wie beispielsweise X.509-Zertifikate, in einer elastischen Cloud-Umgebung, ohne dass private Schlüssel außerhalb des RAM des Containers aufgedeckt werden, so dass nichts auf Platte bestehen bleibt, was dieses Verfahren und diese Vorrichtung extrem sicher macht.
In der vorangehenden Spezifikation sind spezifische Ausführungsformen beschrieben worden. Dem Fachmann auf dem Gebiet ist jedoch klar, dass verschiedene Modifizierungen und Änderungen vorgenommen werden können, ohne von dem Geist der Erfindung abzuweichen, wie in den Ansprüchen unten dargelegt. Dementsprechend sind die Spezifikation und die Abbildungen in einem eher illustrativen als einem restriktiven Sinne zu verstehen und alle solche Modifikationen sollen in dem Geist der vorliegenden Lehren enthalten sein. Die Nutzen, Vorteile, Problemlösungen und jedes denkbare Element, das dazu führt, dass irgendein Nutzen, Vorteil oder irgendeine Lösung eintritt oder ausgeprägter wird, sollen nicht als kritische, erforderliche oder essentielle Merkmale oder Elemente eines beliebigen Anspruchs oder aller Ansprüche ausgelegt werden. Die Erfindung wird ausschließlich durch die angehängten Ansprüche definiert, einschließlich jeder beliebigen Änderung, die während der Rechtshängigkeit der vorliegenden Anmeldung vorgenommen wird, und aller Äquivalente solcher Ansprüche, wie veröffentlicht.
Darüber hinaus sollen in diesem Dokument relationale Ausdrücke, wie zum Beispiel, erste und zweite, oben und unten, und dergleichen ausschließlich verwendet werden, um eine Entität oder Aktion von einer anderen Entität oder Aktion zu unterscheiden, ohne notwendigerweise irgend eine tatsächliche solche Beziehung oder Reihenfolge zwischen solchen Entitäten oder Aktionen zu erfordern oder zu implizieren. Die Ausdrücke „umfasst“, „umfassend“, „hat“, „habend“, „beinhalten“, „beinhaltend“, „enthalten“, „enthaltend“ oder eine beliebige Variation davon sollen eine nicht-exklusive Einbeziehung abdecken, so dass ein Prozess, Verfahren, Artikel oder eine Vorrichtung, die eine Liste von Elementen umfassen, haben, beinhalten, enthalten, nicht nur solche Elemente beinhalten, sondern andere Elemente beinhalten können, die nicht ausdrücklich aufgeführt werden, oder solchen Prozessen, Verfahren, Artikeln oder Vorrichtungen inhärent sind. Ein Element, das fortfährt mit „umfasst... ein“, „hat... ein“, „beinhaltet... ein“, „enthält... ein“, schließt nicht, ohne weitere Auflagen, die Existenz zusätzlicher identischer Elemente in dem Prozess, Verfahren, Artikel oder der Vorrichtung aus, die das Element umfassen, haben, beinhalten, enthalten. Die Ausdrücke „eine“ und „ein“ werden als eins oder mehr definiert, sofern hierin nichts anderes explizit festgelegt ist. Die Ausdrücke „im Wesentlichen“, „essentiell“, „ungefähr“, „etwa“ oder eine beliebige andere Version davon wurden als „nahe bei sein“ definiert, wie dem Fachmann auf dem Gebiet klar ist, und in einer nicht begrenzenden Ausführungsform wird der Ausdruck definiert, innerhalb von 10 %, in einer anderen Ausführungsform innerhalb von 5 % in einer anderen Ausführungsform innerhalb von 1 % und in einer anderen Ausführungsform innerhalb von 0,5 % zu sein. Der Ausdruck „gekoppelt“, wie er hierin verwendet wird, wird als „verbunden“ definiert, obwohl nicht notwendigerweise direkt und nicht notwendigerweise mechanisch. Eine Vorrichtung oder Struktur, die in einer bestimmten Art und Weise „konfiguriert“ ist, ist mindestens auf diese Art und Weise konfiguriert, kann aber auch auf mindestens eine Art und Weise konfiguriert sein, die nicht aufgeführt ist.
Es ist gewünscht, dass einige Ausführungsformen einen oder mehrere generische oder spezialisierte Prozessoren (oder „Verarbeitungsvorrichtungen“) umfassen, wie zum Beispiel, Mikroprozessoren, digitale Signalprozessoren, kundenspezifische Prozessoren und freiprogrammierbare Feld-Gate-Arrays (FPGAs) und eindeutige gespeicherte Programmanweisungen (die sowohl Software als auch Firmware umfassen), die den einen oder mehrere Prozessoren steuern, um in Verbindung mit bestimmten Nicht-Prozessor-Schaltungen, einige, die meisten oder alle der Funktionen des Verfahrens und/oder der Vorrichtung, die hierin beschrieben werden, zu implementieren. Alternativ können einige oder alle Funktionen durch eine Zustandsmaschine implementiert werden, die über keine gespeicherten Programmanweisungen verfügt, oder in einer oder mehreren anwendungsspezifischen integrierten Schaltungen (ASICs), in denen jede Funktion oder einige Kombinationen von bestimmten der Funktionen, als kundenspezifische Logik implementiert sind. Selbstverständlich kann eine Kombination der zwei Ansätze verwendet werden.
Darüber hinaus kann eine Ausführungsform als ein computerlesbares Speichermedium implementiert sein, das über einen darauf gespeicherten computerlesbaren Code zum Programmieren eines Computers (der zum Beispiel einen Prozessor umfasst) verfügt, um ein hierin beschriebenes und beanspruchtes Verfahren durchzuführen. Beispiele solcher computerlesbaren Speichermedien umfassen, ohne darauf beschränkt zu sein: eine Festplatte, eine CD-ROM, eine optische Speichervorrichtung, eine magnetische Speichervorrichtung, einen ROM (Nur-Lese-Speicher), einen PROM (Programmierbarer Lesespeicher), einen EPROM (Löschbarer Programmierbarer Lesespeicher), einen EEPROM (Elektrisch Löschbarer Programmierbarer Lesespeicher) und einen Flash-Speicher. Weiterhin ist zu erwarten, dass ein Fachmann auf dem Gebiet, ungeachtet möglicher erheblicher Anstrengungen und einer großen Designauswahl, die zum Beispiel durch eine zur Verfügung stehende Zeit, der aktuellen Technologie und ökonomische Überlegungen begründet ist, geleitet durch die hierin offenbarten Konzepte und Prinzipien, ohne Weiteres in der Lage ist solche Softwareanweisungen und Programme und ICs mit minimalem Versuchsaufwand zu erzeugen.
Die Zusammenfassung der Offenbarung wird zur Verfügung gestellt, um dem Leser zu erlauben, die Natur der technischen Offenbarung schnell zu erkennen. Es wird mit dem Verständnis eingereicht, dass es nicht verwendet wird, um den Geist oder die Bedeutung der Ansprüche zu interpretieren oder zu begrenzen. Zusätzlich ist der vorangehenden ausführlichen Beschreibung zu entnehmen, dass verschiedene Merkmale in verschiedenen Ausführungsformen zusammengruppiert werden, um die Offenbarung zu straffen. Dieses Offenbarungsverfahren soll nicht als ein Reflektieren einer Intention interpretiert werden, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern, als ausdrücklich in jedem Anspruch vorgetragen werden. Vielmehr liegt, wie aus den folgenden Ansprüchen hervorgeht, ein erfinderischer Gegenstand in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform vor. Somit werden die folgenden Ansprüche hierdurch in die ausführliche Beschreibung integriert, wobei jeder Anspruch für sich alleine als ein getrennt beanspruchter Gegenstand steht.
Es wird beansprucht:

Claims

Verfahren zum Erhalten eines geprüften Zertifikats für einen Mikrodienst in einer elastischen Cloud-Umgebung, wobei das Verfahren umfasst: Empfangen eines Einmal-Authentifizierungsberechtigungsnachweises bei dem Mikrodienst; Verwenden des Einmal-Authentifizierungsberechtigungsnachweises, um ein Client-Geheimnis zu erhalten; Erhalten eines Zugriffs-Tokens und Erhalten von CSR-Attributen (CSR = Certificate Signing Request/Zertifikatsignieranforderung) bei dem Mikrodienst unter Verwendung des Client-Geheimnisses; Erstellen einer CSR bei dem Mikrodienst unter Verwendung der CSR-Attribute; Anfordern eines geprüften Zertifikats von einer CA (CA = Certificate Authority/Zertifikatautorität), wobei die Anforderung den Zugriffs-Token und die CSR umfasst; und wenn der Zugriffs-Token und die CSR die Prüfung bestehen, Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst.
Verfahren nach Anspruch 1, wobei der Einmal-Authentifizierungsberechtigungsnachweis einen Mikrodiensttyp umfasst.
Verfahren nach Anspruch 1, wobei der Einmal-Authentifizierungsberechtigungsnachweis ein erstes Datenstück und ein zweites Datenstück umfasst, wobei das erste Datenstück einen Diensttyp umfasst und das zweite Datenstück eine Dienstinstanz umfasst.
Verfahren nach Anspruch 1, wobei das Client-Geheimnis einen Diensttyp einem Geheimnismanagementdienst zuordnet.
Verfahren nach Anspruch 1, wobei der Schritt „wenn der Zugriffs-Token und die CSR die Prüfung bestehen, Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst“ ein Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst umfasst, wenn der Zugriffs-Token zu einem bei der CA gespeicherten Zugriffs-Token passt.
Verfahren nach Anspruch 1, wobei der Schritt „wenn der Zugriffs-Token und die CSR die Prüfung bestehen, Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst“ ein Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst umfasst, wenn der Zugriffs-Token einen bei der CA gespeicherten Zugriffs-Token abbildet.
Verfahren nach Anspruch 1, wobei der Schritt „wenn der Zugriffs-Token und die CSR die Prüfung bestehen, Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst“ ein Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst umfasst, wenn der Zugriffs-Token äquivalent zu einem bei der CA gespeicherten Zugriffs-Token ist.
Verfahren nach Anspruch 1, wobei der Schritt „wenn der Zugriffs-Token und die CSR die Prüfung bestehen, Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst“ ein Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst umfasst, wenn der Zugriffs-Token einem bei der CA gespeicherten Zugriffs-Token zugeordnet ist.
Verfahren nach Anspruch 1, wobei der Schritt „wenn der Zugriffs-Token und die CSR die Prüfung bestehen, Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst“ ein Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst umfasst, wenn die CSR zu einer bei der CA gespeicherten CSR passt.
Verfahren zum Erhalten eines geprüften Zertifikats für einen Mikrodienst in einer elastischen Cloud-Umgebung, wobei das Verfahren umfasst: Erhalten eines Zugriffs-Tokens bei dem Mikrodienst; Anfordern eines geprüften Zertifikats von einer CA (CA = Certificate Authority/Zertifikatautorität), wobei die Anforderung den Zugriffs-Token umfasst; und Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst, wenn der Zugriffs-Token zu einem bei der CA gespeicherten Zugriffs-Token passt.
Verfahren nach Anspruch 10, wobei der Schritt „Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst, wenn der Zugriffs-Token zu einem bei der CA gespeicherten Zugriffs-Token passt“ ein Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst umfasst, wenn der Zugriffs-Token einen bei der CA gespeicherten Zugriffs-Token abbildet.
Verfahren nach Anspruch 10, wobei der Schritt „Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst, wenn der Zugriffs-Token zu einem bei der CA gespeicherten Zugriffs-Token passt“ ein Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst umfasst, wenn der Zugriffs-Token äquivalent zu einem bei der CA gespeicherten Zugriffs-Token ist.
Verfahren nach Anspruch 10, wobei der Schritt „Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst, wenn der Zugriffs-Token zu einem bei der CA gespeicherten Zugriffs-Token passt“ ein Empfangen eines geprüften Zertifikats von der CA bei dem Mikrodienst umfasst, wenn der Zugriffs-Token einem bei der CA gespeicherten Zugriffs-Token zugeordnet ist.
Mikrodienst, der aufweist: einen Transceiver; und einen Prozessor, der zu folgendem konfiguriert ist: Empfange einen Einmal-Authentifizierungsberechtigungsnachweis über den Transceiver; Verwende den Einmal-Authentifizierungsberechtigungsnachweis, um ein Client-Geheimnis über den Transceiver zu erhalten; Erhalte einen Zugriffs-Token und CSR-Attribute (CSR = Certificate Signing Request/Zertifikatsignieranforderung) unter Verwendung des Client-Geheimnisses über den Transceiver; Erstelle eine CSR unter Verwendung der CSR-Attribute; Fordere ein geprüftes Zertifikat von einer CA an (CA = Certificate Authority/Zertifikatautorität), über den Transceiver, wobei die Anforderung den Zugriffs-Token und die CSR umfasst; und Empfange ein geprüftes Zertifikat von der CA über den Transceiver, wenn der Zugriffs-Token und der CSR eine Prüfung bestehen.
Mikrodienst nach Anspruch 14, wobei der Einmal-Authentifizierungsberechtigungsnachweis einen Mikrodiensttyp umfasst.
Mikrodienst nach Anspruch 14, wobei der Einmal-Authentifizierungsberechtigungsnachweis ein erstes Datenstück und ein zweites Datenstück aufweist, wobei das erste Datenstück einen Diensttyp umfasst und das zweite Datenstück eine Dienstinstanz umfasst.
Mikrodienst nach Anspruch 14, wobei das Client-Geheimnis einen Diensttyp einem Geheimnismanagementdienst zuordnet.
Mikrodienst nach Anspruch 14, wobei der Prozessor dazu konfiguriert ist, ein geprüftes Zertifikat von der CA über den Transceiver zu empfangen, wenn der Zugriffs-Token zu einem bei der CA gespeicherten Zugriffs-Token passt.
Mikrodienst nach Anspruch 14, wobei der Prozessor dazu konfiguriert ist, ein geprüftes Zertifikat von der CA über den Transceiver zu empfangen, wenn die CSR zu einer bei der CA gespeicherten CSR passt.