Schlüsselhoheit, Verfügbarkeit, Leistung und Skalierbarkeit in verwaltetem HSM
Kryptografische Schlüssel stellen die Vertrauensgrundlage für die Absicherung moderner Computersysteme – am lokalen Standort oder in der Cloud. Daher ist die Kontrolle darüber, wer die Autorität über diese Schlüssel besitzt, für die Entwicklung sicherer und konformer Anwendungen von entscheidender Bedeutung.
Bei Azure beruht unsere Vision, wie die Schlüsselverwaltung in der Cloud erfolgen soll, auf der Schlüsselhoheit. Schlüsselhoheit bedeutet, dass die Organisation eines Kunden die vollständige und exklusive Kontrolle darüber besitzt, wer auf Schlüssel zugreifen und Schlüsselverwaltungsrichtlinien ändern kann und welche Azure-Dienste diese Schlüssel nutzen. Nachdem diese Entscheidungen vom Kunden getroffen wurden, wird das Microsoft-Personal durch technische Mittel daran gehindert, diese Entscheidungen zu ändern. Die Entscheidungen des Kunden werden durch den Code des Schlüsselverwaltungsdiensts so lange ausgeführt, bis der Kunde seine Entscheidung ändert. Das Microsoft-Personal kann dabei nicht eingreifen.
Gleichzeitig vertreten wir die Ansicht, dass jeder Dienst in der Cloud vollständig verwaltet werden muss. Der Dienst muss die erforderlichen Grundversprechen im Hinblick auf Verfügbarkeit, Resilienz, Sicherheit und Cloud einlösen, die durch Vereinbarungen zum Servicelevel (SLAs) unterstützt werden. Um einen verwalteten Dienst bereitzustellen, muss Microsoft Schlüsselverwaltungsserver patchen, HSM-Firmware (Hardwaresicherheitsmodul) upgraden, fehlerhafte Hardware reparieren, Failover durchführen und weitere Vorgänge mit hohen Berechtigungen verarbeiten. Wie die meisten Sicherheitsexperten wissen, ist es ein schwieriges Problem, jemandem mit hohen Rechten oder physischem Zugriff auf ein System den Zugriff auf die Daten innerhalb dieses Systems zu verweigern.
In diesem Artikel wird erläutert, wie wir dieses Problem im verwalteten HSM-Dienst von Azure Key Vault gelöst haben (und dem Kunden sowohl volle Schlüsselhoheit als auch SLAs für vollständig verwaltete Dienste bieten), indem wir vertrauliche Computingtechnologie in Verbindung mit HSMs verwenden.
Hardwareumgebung mit verwaltetem HSM
Der Pool verwalteter HSMs eines Kunden in einer beliebigen Azure-Region befindet sich in einem sicheren Azure-Rechenzentrum. Drei Instanzen sind über mehrere Server verteilt. Jede Instanz wird in einem anderen Rack bereitgestellt, um Redundanz zu gewährleisten. Jeder Server verfügt über einen durch FIPS 140-2 Level 3 validierten Marvell LiquidSecurity-HSM-Adapter mit mehreren kryptografischen Kernen. Die Kerne werden verwendet, um vollständig isolierte HSM-Partitionen zu erstellen, einschließlich vollständig isolierter Anmeldeinformationen, Datenspeicherung und Zugriffssteuerung.
Die physische Trennung der Instanzen innerhalb des Rechenzentrums ist entscheidend, um sicherzustellen, dass der Verlust einer einzelnen Komponente (beispielsweise des Top-of-Rack-Switchs oder einer Energieverwaltungseinheit in einem Rack) sich nicht auf alle Instanzen eines Pools auswirken kann. Diese Server sind ausschließlich für das HSM-Team von Azure Security bestimmt. Sie werden nicht mit anderen Azure-Teams gemeinsam genutzt, und es werden keine Kundenworkloads darauf bereitgestellt. Physische Zugriffssteuerungen, einschließlich gesperrter Racks, werden verwendet, um unbefugten Zugriff auf die Server zu verhindern. Diese Kontrollen erfüllen FedRAMP-High, PCI, SOC 1/2/3, ISO 270x und andere Sicherheits- und Datenschutzstandards und werden im Rahmen des Azure-Complianceprogramms regelmäßig unabhängig überprüft. Die HSMs verfügen über eine verbesserte physische Sicherheit, die auf die Erfüllung von FIPS 140-2 Level 3-Anforderungen überprüft wurde. Der gesamte verwaltete HSM-Dienst basiert auf der standardmäßigen sicheren Azure-Plattform einschließlich vertrauenswürdigem Start, und bietet somit Schutz vor erweiterten persistenten Bedrohungen.
Die HSM-Adapter können Dutzende isolierte HSM-Partitionen unterstützen. Auf jedem Server wird ein Steuerungsprozess namens Node Service ausgeführt. Node Service nimmt jeden Adapter in Besitz und installiert die Anmeldeinformationen für den Adapterbesitzer, in diesem Fall Microsoft. Das HSM ist so konzipiert, dass Microsoft durch den Besitz des Adapters keinen Zugriff auf gespeicherte Daten in Kundenpartitionen erlangt. Es gibt Microsoft lediglich die Möglichkeit, Kundenpartitionen zu erstellen, deren Größe zu ändern und sie zu löschen. Es unterstützt die Erstellung blinder Sicherungen der Kundenpartitionen. Bei einer blinden Sicherung wird die Sicherung von einem kundenseitig bereitgestellten Schlüssel umschlossen, der vom Dienstcode nur innerhalb einer HSM-Instanz des Kunden wiederhergestellt werden kann und deren Inhalte von Microsoft nicht gelesen werden können.
Architektur eines verwalteten HSM-Pools
Abbildung 1 zeigt die Architektur eines HSM-Pools, der aus drei Linux-VMs besteht, die jeweils auf einem HSM-Server in einem eigenen Rack im Rechenzentrum ausgeführt werden, um Verfügbarkeit zu gewährleisten. Die wichtigsten Komponenten sind:
- Der HSM Fabric Controller (HFC) stellt die Steuerungsebene des Diensts dar. Der HFC steuert automatisierte Patches und Reparaturen für den Pool.
- Eine exklusive kryptografische Grenze für jeden Kunden bestehend aus drei vertraulichen Enclaves von Intel Secure Guard Extensions (Intel SGX), die mit drei mit FIPS 140-2 Level 3 kompatiblen HSM-Instanzen verbunden sind. Die Stammschlüssel für diese Grenze werden in den drei HSMs generiert und gespeichert. Wie weiter unten in diesem Artikel beschrieben, besitzt keine mit Microsoft in Verbindung stehende Person Zugriff auf die Daten, die sich innerhalb dieser Grenze befindet. Nur Dienstcode, der im Auftrag des Kunden in der Intel SGX-Enclave ausgeführt wird (einschließlich des Node Service-Agents), verfügt über Zugriff.
Trusted Execution Environment (TEE)
Ein Pool verwalteter HSMs besteht aus drei Dienstinstanzen. Jede Dienstinstanz wird als vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) implementiert, die Intel SGX-Funktionen und das Open Enclave SDK verwendet. Die Ausführung innerhalb einer TEE stellt sicher, dass keine Person auf der VM, die den Dienst hostet, oder dem Hostserver der VM Zugriff auf Kundengeheimnisse, Daten oder die HSM-Partition erlangt. Jede TEE ist für einen bestimmten Kunden dediziert und führt TLS-Verwaltung, Anforderungsverarbeitung und Zugriffssteuerung für die HSM-Partition aus. Außerhalb dieser TEE sind keine Anmeldeinformationen oder kundenspezifischen Datenverschlüsselungsschlüssel in Klartext vorhanden, außer als Teil des Sicherheitsdomänenpakets. Dieses Paket wird mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt und bei der ersten Erstellung des Pools heruntergeladen.
Die TEEs kommunizieren untereinander mithilfe von nachgewiesener TLS. Nachgewiesene TLS kombiniert die Remotenachweisfunktionen der Intel SGX-Plattform mit TLS 1.2. Dadurch kann verwalteter HSM-Code in der TEE seine Kommunikation auf anderen Code beschränken, der mit demselben Codesignaturschlüssel des verwalteten HSM-Diensts signiert ist, um Man-in-the-Middle-Angriffe zu verhindern. Der Codesignaturschlüssel des verwalteten HSM-Diensts wird im Produktrelease and Sicherheitsdienst von Microsoft gespeichert (der beispielsweise auch verwendet wird, um den Windows-Codesignaturschlüssel zu speichern). Der Schlüssel wird vom Team für verwaltete HSMs gesteuert. Gemäß unseren gesetzlichen und compliancebezogenen Verpflichtungen in Bezug auf das Change Management kann dieser Schlüssel von keinem anderen Microsoft-Team zum Signieren von Code verwendet werden.
Die für die Kommunikation zwischen TEEs verwendeten TLS-Zertifikate werden vom Dienstcode innerhalb des TEE selbst ausgestellt. Die Zertifikate enthalten einen Plattformbericht, der von der Intel SGX-Enclave auf dem Server generiert wird. Die zur Signierung des Plattformberichts verwendeten Schlüssel werden von Schlüsseln abgeleitet, die von Intel bei der Herstellung in die CPU eingeschmolzen wurden. Der Bericht identifiziert den Code, der in die Intel SGX-Enclave geladen wird, über seinen Codesignaturschlüssel und den binären Hash. Anhand dieses Plattformberichts können Dienstinstanzen feststellen, dass ein Peer auch vom Codesignaturschlüssel des verwalteten HSM-Diensts signiert wurde, und mit einer gewissen kryptografischen Verschränkung über den Plattformbericht zudem bestimmen, dass der selbst ausgestellte Zertifikatsignaturschlüssel auch innerhalb der TEE generiert worden sein muss, um einen externen Identitätswechsel zu verhindern.
Anbieten von Verfügbarkeits-SLAs mit vollständiger Steuerung über kundenseitig verwaltete Schlüssel
Um Hochverfügbarkeit sicherzustellen, erstellt der HFC-Dienst drei HSM-Instanzen in der kundenseitig ausgewählten Azure-Region.
Erstellung eines verwalteten HSM-Pools
Die Hochverfügbarkeitseigenschaften von Pools mit verwalteten HSMs beruhen auf den automatisch verwalteten dreifach redundanten HSM-Instanzen, die immer synchron gehalten werden (oder bei Verwendung der Replikation mit mehreren Regionen auf der Synchronisierung aller sechs Instanzen). Die Poolerstellung wird vom HFC-Dienst verwaltet, der Pools über die verfügbare Hardware in der vom Kunden ausgewählten Azure-Region zuteilt.
Wenn ein neuer Pool angefordert wird, wählt der HFC rackübergreifend drei Server aus, deren HSM-Adapter verfügbaren Speicherplatz aufweisen, und beginnt mit der Erstellung des Pools:
Der HFC weist die Node Service-Agents in jeder der drei TEEs an, anhand einer Reihe von Parametern eine neue Instanz des Dienstcodes zu starten. Die Parameter identifizieren den Microsoft Entra-Mandanten des Kunden, die IP-Adressen des internen virtuellen Netzwerks aller drei Instanzen und einige andere Dienstkonfigurationen. Eine Partition wird zufällig als primäre Partition zugewiesen.
Die drei Instanzen starten. Jede Instanz stellt eine Verbindung mit einer Partition auf dem lokalen HSM-Adapter her und nullifiziert und initialisiert dann die Partition mithilfe zufällig generierter Benutzernamen und Anmeldeinformationen (um sicherzustellen, dass keine Person oder eine andere TEE-Instanz auf die Partition zugreifen kann).
Die primäre Instanz erstellt mithilfe des privaten Schlüssels, der im HSM generiert wird, ein Stammzertifikat des Partitionsbesitzers. Sie richtet den Besitz des Pools ein, indem sie ein Zertifikat auf Partitionsebene für die HSM-Partition mit diesem Stammzertifikat signiert. Die primäre Instanz generiert außerdem einen Datenverschlüsselungsschlüssel, der zum Schützen aller ruhenden Kundendaten innerhalb des Diensts verwendet wird. Für Schlüsselmaterial wird eine doppelte Umschließung verwendet, da das HSM auch das Schlüsselmaterial selbst schützt.
Als Nächstes werden diese Eigentumsdaten mit den beiden sekundären Instanzen synchronisiert. Jede sekundäre Instanz kontaktiert die primäre über nachgewiesene TLS. Die primäre Instanz teilt das Stammzertifikat des Partitionsbesitzers mit dem privaten Schlüssel und dem Datenverschlüsselungsschlüssel. Die sekundären Instanzen verwenden nun das Partitionsstammzertifikat, um ein Partitionszertifikat für ihre eigenen HSM-Partitionen auszugeben. Sobald dieser Vorgang abgeschlossen sind, verfügen Sie über HSM-Partitionen auf drei separaten Servern, die sich im Besitz desselben Partitionsstammzertifikat befinden.
Über den Link mit nachgewiesener TLS teilt sich die HSM-Partition der primären Instanz ihren generierten Datenumschließungsschlüssel (der zum Verschlüsseln von Nachrichten zwischen den drei HSMs verwendet wird) mit den sekundären Instanzen. Zu diesem Zweck wird eine sichere API verwendet, die vom HSM-Anbieter bereitgestellt wird. Während dieses Austauschs bestätigen die HSMs, dass sie über dasselbe Partitionsbesitzerzertifikat verfügen, und verwenden dann ein Diffie-Hellman-Schema, um die Nachrichten so zu verschlüsseln, dass sie vom Microsoft-Dienstcode nicht gelesen werden können. Der Dienstcode kann lediglich undurchsichtige Blobs zwischen den HSMs transportieren.
An diesem Punkt können alle drei Instanzen als Pool im virtuellen Netzwerk des Kunden verfügbar gemacht werden. Sie teilen sich dasselbe Partitionsbesitzerzertifikat und denselben privaten Schlüssel, denselben Datenverschlüsselungsschlüssel und einen gemeinsamen Datenumschließungsschlüssel. Jede Instanz verfügt jedoch über eindeutige Anmeldeinformationen für ihre HSM-Partitionen. Nun sind die letzten Schritte abgeschlossen.
Jede Instanz generiert ein RSA-Schlüsselpaar und eine Zertifikatsignaturanforderung (Certificate Signing Request, CSR) für das öffentliche TLS-Zertifikat. Die CSR wird vom Microsoft-PKI-System (Public Key-Infrastruktur) über einen öffentlichen Microsoft-Stamm signiert, und das resultierende TLS-Zertifikat wird an die Instanz zurückgegeben.
Alle drei Instanzen erhalten ihren eigenen Intel SGX-Versiegelungsschlüssel von ihrer lokalen CPU. Der Schlüssel wird mithilfe des eigenen eindeutigen Schlüssels der CPU und des Codesignaturschlüssels der TEE generiert.
Der Pool leitet einen eindeutigen Poolschlüssel von den Intel SGX-Versiegelungsschlüsseln ab, verschlüsselt all seine Geheimnisse mit diesem Poolschlüssel und schreibt dann die verschlüsselten Blobs auf den Datenträger. Diese Blobs können nur entschlüsselt werden, wenn sie durch denselben Intel SGX-Versiegelungsschlüssel codesigniert sind, der auf derselben physischen CPU ausgeführt wird. Die Geheimnisse sind an diese spezifische Instanz gebunden.
Der sichere Bootstrap-Prozess ist jetzt abgeschlossen. Dieser Prozess hat sowohl die Erstellung eines dreifach redundanten HSM-Pools als auch die Erstellung einer kryptografischen Garantie der Hoheit von Kundendaten ermöglicht.
Verwalten von Verfügbarkeits-SLAs zur Laufzeit mithilfe der vertraulichen Dienstheilung
Anhand der in diesem Artikel beschriebenen Vorgänge zur Poolerstellung ist ersichtlich, wie der verwaltete HSM-Dienst seine Hochverfügbarkeits-SLAs erfüllen kann, indem er die dem Dienst zugrunde liegenden Server sicher verwaltet. Stellen Sie sich vor, dass ein Server, ein HSM-Adapter oder sogar die Stromversorgung des Racks ausfällt. Das Ziel des verwalteten HSM-Diensts besteht darin, den Pool ohne Kundeneingriffe und ohne die Möglichkeit, dass Geheimnisse außerhalb der TEE in Klartext offengelegt werden, als drei fehlerfreie Instanzen wiederherzustellen. Dies wird durch vertrauliche Dienstheilung erreicht.
Dazu muss der HFC zunächst ermitteln, welche Pools Instanzen auf dem ausgefallenen Server hatten. HFC findet neue, fehlerfreie Server in der Region des Pools, auf denen die Ersatzinstanzen bereitgestellt werden können. Er startet neue Instanzen, die dann während des ersten Bereitstellungsschritts genau wie eine sekundäre Instanz behandelt werden: Initialisierung des HSM, Auffinden seiner primären Instanz, sicherer Austausch von Geheimnissen über bescheinigtes TLS, Signieren des HSM in die Eigentümerhierarchie und anschließendes Versiegeln seiner Dienstdaten an seine neue CPU. Der Dienst ist jetzt geheilt, vollständig automatisch und vollständig vertraulich.
Wiederherstellen nach einem Notfall mithilfe der Sicherheitsdomäne
Die Sicherheitsdomäne ist ein gesichertes Blob, das alle Anmeldeinformationen enthält, die zum vollständigen Neuerstellen der HSM-Partition erforderlich sind: Partitionsbesitzerschlüssel, Partitionsanmeldeinformationen, Datenumschließungsschlüssel und eine erste Sicherung des HSM. Bevor der Dienst livegeschaltet wird, muss der Kunde die Sicherheitsdomäne herunterladen, indem er eine Reihe von RSA-Verschlüsselungsschlüsseln für deren Schutz bereitstellt. Die Sicherheitsdomänendaten stammen aus den TEEs und werden durch einen generierten symmetrischen Schlüssel und eine Implementierung des Secret Sharing-Algorithmus von Shamir geschützt, der die Schlüsselfreigaben gemäß den vom Kunden ausgewählten Quorumparametern auf die vom Kunden bereitgestellten öffentlichen RSA-Schlüssel aufteilt. Während dieses Vorgangs werden keinerlei Dienstschlüssel oder Anmeldeinformationen in Klartext außerhalb des in den TEEs ausgeführten Dienstcodes offengelegt. Nur der Kunde kann die Sicherheitsdomäne während eines Wiederherstellungsszenarios entschlüsseln, indem er der TEE ein Quorum seiner RSA-Schlüssel vorlegt.
Die Sicherheitsdomäne wird nur benötigt, wenn aufgrund einer Katastrophe die gesamte Azure-Region nicht verfügbar ist und Microsoft alle drei Instanzen des Pools gleichzeitig verliert. Wenn nur eine oder sogar zwei Instanzen verloren gehen, wird durch eine vertrauliche Dienstheilung im Hintergrund ohne Kundeneingriff eine Wiederherstellung in drei fehlerfreie Instanzen durchgeführt. Wenn die gesamte Region verloren geht, hat Microsoft keine Möglichkeit, die HSM-Anmeldeinformationen und Partitionsbesitzerschlüssel wiederherzustellen, da Intel SGX-Versiegelungsschlüssel für jede CPU eindeutig sind. Sie existieren nur im Kontext der Instanzen.
Im äußerst unwahrscheinlichen Fall, dass eine solche Katastrophe eintritt, kann der Kunde seinen vorherigen Poolzustand und die Daten wiederherstellen, indem er einen neuen leeren Pool erstellt, ihn in die Sicherheitsdomäne einschleust und dann sein RSA-Schlüsselquorum vorlegt, um den Besitz der Sicherheitsdomäne nachzuweisen. Falls ein Kunde die regionsübergreifende Replikation aktiviert hat, müsste die noch unwahrscheinlichere Katastrophe eines gleichzeitigen Komplettausfalls beider Regionen eintreten, bevor ein Kundeneingriff erforderlich wäre, um den Pool aus der Sicherheitsdomäne wiederherzustellen.
Kontrollieren des Zugriffs auf den Dienst
Wie oben beschrieben, ist unser Dienstcode in der TEE die einzige Entität mit Zugriff auf das HSM selbst, weil die erforderlichen Anmeldeinformationen weder dem Kunden noch anderen Personen zur Verfügung gestellt werden. Stattdessen ist der Pool des Kunden an die Microsoft Entra-Instanz gebunden, und dies wird für die Authentifizierung und Autorisierung verwendet. Bei der ersten Bereitstellung kann der Kunde eine anfängliche Gruppe von Mitarbeiter*innen auswählen, denen die Administratorrolle für den Pool zugewiesen werden soll. Diese Personen und die Mitarbeiter*innen mit der Rolle „Globaler Administrator“ für den Microsoft Entra-Mandanten des Kunden können Zugriffssteuerungsrichtlinien innerhalb des Pools festlegen. Alle Zugriffssteuerungsrichtlinien werden vom Dienst in derselben Datenbank wie die maskierten Schlüssel gespeichert, die ebenfalls verschlüsselt sind. Nur der Dienstcode in der TEE hat Zugriff auf diese Zugriffssteuerungsrichtlinien.
Zusammenfassung
Mit verwaltetem HSM müssen Kunden keine Kompromisse zwischen Verfügbarkeit und Kontrolle über kryptografische Schlüssel eingehen, indem sie die hochmoderne Technologie hardwarebasierter vertraulicher Enclaves einsetzen. Wie in diesem Artikel beschrieben, können Mitarbeiter*innen oder Vertreter*innen von Microsoft bei dieser Implementierung selbst dann nicht auf Material kundenseitig verwalteter Schlüssel oder auf entsprechende Geheimnisse zugreifen, wenn sie physischen Zugang zu den Hostcomputern verwalteter HSMs und zu HSMs besitzen. Diese Sicherheit hat das Vertrauen unserer Kunden aus den Bereichen Finanzdienstleistungen, Fertigung, öffentlicher Sektor, Verteidigung und anderen Branchen bestärkt, ihre Migrationen zur Cloud zu beschleunigen.