Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Das Zertifikatsmanagement im Azure Device Registry vereinfacht die Verwaltung von X.509-Zertifikaten für IoT-Geräte. Dieser Artikel führt die grundlegenden Konzepte des Zertifikatsmanagements und der zertifikatsbasierten Authentifizierung ein. Weitere Informationen finden Sie unter Was ist die Zertifikatverwaltung (Vorschau)?
Important
Azure IoT Hub mit Azure Geräteregistrierungsintegration und Microsoft gesicherten X.509-Zertifikatverwaltung befindet sich in public preview und wird für Produktionsworkloads nicht empfohlen. Weitere Informationen finden Sie unter FAQ: Neuerungen in IoT Hub?.
Cloud-Public-Key-Infrastruktur (PKI)
Die Public Key Infrastructure (PKI) ist das Rahmenwerk aus Zertifizierungsstellen, kryptografischen Schlüsseln, Richtlinien und Prozessen, die zur Ausgabe, Verwaltung, Verlängerung und Widerrufung digitaler Zertifikate verwendet werden. Zertifikate sind unerlässlich, um verschiedene Szenarien wie Web- und Geräteidentität abzusichern. Historisch gesehen bauen und betreiben Organisationen ihre eigene PKI-Umgebung, die oft Hardware-Sicherheitsmodule (HSMs), Zertifizierungsstellensoftware und betriebliche Verfahren umfasst, die für IoT-Flotten besonders komplex sein können.
Eine Cloud-PKI bietet die gleichen Zertifizierungsautoritätsfunktionen wie eine herkömmliche PKI, stellt sie jedoch als verwalteten Cloud-Dienst bereit. Anstatt die PKI-Infrastruktur selbst bereitzustellen und zu betreiben, nutzen Organisationen Zertifizierungsdienste über cloud-verwaltete APIs, Lebenszyklus-Workflows und automatisierte Operationen. Sie können das Zertifikatsmanagement im Azure Device Registry nutzen, um die Sicherheit Ihrer Geräte zu verbessern und Ihre digitale Transformation mithilfe eines vollständig verwalteten Cloud-PKI-Dienstes zu beschleunigen.
Microsoft Cloud-PKI vs. PKI von Drittanbietern
Während IoT Hub zwei Arten von PKI-Anbietern für die X.509-Zertifikatsauthentifizierung unterstützt, unterstützt die Zertifikatsverwaltung in Azure Device Registry derzeit nur Microsoft cloud PKI und die Verwendung einer eigenen Zertifizierungsstelle (CA). Informationen zur Verwendung von PKI-Drittanbietern finden Sie unter Authentifizieren von Geräten mit X.509-Zertifizierungsstellenzertifikaten.
| PKI-Anbieter | Integration erforderlich | Azure Geräteregistrierung erforderlich | Gerätebereitstellungsdienst erforderlich |
|---|---|---|---|
| Microsoft Cloud PKI | Konfigurieren Sie Zertifizierungsstellen direkt im Azure Device Registry oder bringen Sie Ihre eigene CA mit. | Ja | Ja |
| PKI von Drittanbietern (DigiCert, GlobalSign usw.) | Yes. Manuelle Integration erforderlich. | No | No |
Jeder Namensraum erhält seine eigene logisch isolierte Cloud-PKI-Umgebung, die sicherstellt, dass Zertifikatsoperationen auf Ressourcen innerhalb dieses Namensraums beschränkt sind. Kunden verwalten die Cloud-PKI nicht als separate Azure-Ressource. Stattdessen wird die Cloud-PKI automatisch bereitgestellt, abgegrenzt und als Teil eines Azure Device Registry-Namensraums verwaltet.
X.509-Zertifikate
Ein X.509-Zertifikat ist ein digitales Dokument, das einen öffentlichen Schlüssel an die Identität einer Entität bindet, z. B. ein Gerät, ein Benutzer oder einen Dienst. Zertifikatbasierte Authentifizierung bietet mehrere Vorteile gegenüber weniger sicheren Methoden:
- Zertifikate verwenden Kryptografie mit öffentlichem/privatem Schlüssel. Der öffentliche Schlüssel wird frei freigegeben, während der private Schlüssel auf dem Gerät verbleibt und sich innerhalb von Trusted Platform Modules (TPMs) oder sicheren Elementen befinden kann. Dadurch wird verhindert, dass Angreifer die Identität des Geräts imitieren.
- Zertifikate werden über eine Zertifizierungsstelle-Hierarchie ausgestellt und überprüft, sodass Organisationen Millionen von Geräten über eine einzelne Zertifizierungsstelle vertrauen können, ohne geheime Schlüssel für jedes Gerät zu verwalten.
- Geräte authentifizieren sich in der Cloud und die Cloud authentifiziert sich beim Gerät, wodurch die gegenseitige Transport Layer Security (mTLS)-Authentifizierung ermöglicht wird.
Zertifikattypen
Es gibt zwei allgemeine Kategorien von X.509-Zertifikaten:
Zertifizierungsstellenzertifikate: Diese Zertifikate werden von einer Zertifizierungsstelle ausgestellt, und Sie verwenden sie, um andere Zertifikate zu signieren. CA-Zertifikate umfassen Stamm- und Zwischenzertifikate.
Stammzertifizierungsstelle: Ein Stammzertifikat ist ein selbstsigniertes Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle, das zum Signieren von zwischengeschalteten Zertifizierungsstellen verwendet werden kann.
Zwischen- oder ausstellende ZS: Ein Zwischenzertifikat ist ein ZS-Zertifikat, das von einem vertrauenswürdigen Stammzertifikat signiert wird. Es kann hilfreich sein, unterschiedliche Zwischenzertifikate für verschiedene Gerätegruppen zu verwenden, z. B. Geräte von unterschiedlichen Herstellern oder unterschiedliche Gerätemodelle.
End-Entity-Zertifikate oder Gerätezertifikate: Diese Zertifikate werden von CA-Zertifikaten signiert und können individuelle oder Gerätezertifikate sein. Die CA gibt sie dann an Nutzer, Server oder Geräte aus.
Vorgänge im Zertifikatslebenszyklus
Zertifikatsverwaltung unterstützt den gesamten Lebenszyklus von Zertifizierungsstellen und Gerätezertifikaten. Das Verständnis der verschiedenen Lebenszyklusoperationen hilft sicherzustellen, dass Geräte während ihrer gesamten Betriebszeit eine sichere, unterbrechungsfreie Verbindung aufrechterhalten.
Ausstellung: Der Prozess der Erstellung und Unterzeichnung eines neuen Zertifikats für eine Zertifizierungsstelle oder ein Gerät. Dieser Prozess beginnt mit einer Zertifikatsignierungsanforderung (CSR).
Verlängerung: Der Prozess, die Gültigkeit eines Gerätezertifikats zu verlängern, indem ein Ersatzzertifikat vor Ablauf des aktuellen Zertifikats ausgestellt wird. Gerätezertifikate können erneuert werden, ohne dass das Gerät neu bereitgestellt werden muss.
Rotation: Der Prozess, eine Zertifizierungsstelle durch eine neue zu ersetzen, während die Vertrauensbeziehung erhalten bleibt. Rotation wird üblicherweise durchgeführt, wenn eine Zwischen-ZS bald abläuft oder wenn sich kryptografische Anforderungen ändern.
Widerruf: Der Prozess, ein Zertifikat vor seinem Ablaufdatum ungültig zu machen, wenn es nicht mehr vertrauenswürdig, kompromittiert oder nicht mehr für die Nutzung autorisiert ist.
Ablaufdatum: Das Ende der Gültigkeitsdauer eines Zertifikats. Abgelaufene Zertifikate können nicht mehr zur Authentifizierung verwendet werden und müssen erneuert oder ersetzt werden.
Zertifikatsignaturanforderung
Eine Zertifikatsignierungsanforderung (Certificate Signing Request, CSR) ist eine digital signierte Nachricht, die ein Client, z. B. ein IoT-Gerät, generiert, um ein signiertes Zertifikat von einer Zertifizierungsstelle anzufordern. Die CSR umfasst den öffentlichen Schlüssel des Geräts und die Identifizierung von Informationen, z. B. die Registrierungs-ID, und wird mit dem privaten Schlüssel des Geräts signiert, um den Besitz des Schlüssels zu bestätigen. Eine CSR muss den Richtlinienanforderungen der PKI entsprechen, einschließlich genehmigter Schlüsselalgorithmen, Schlüsselgrößen und Themenfeldformaten. Wenn ein Gerät einen neuen privaten Schlüssel generiert, generiert es auch eine neue CSR. Nachdem die Zertifizierungsstelle die CSR überprüft und genehmigt hat, gibt sie ein X.509-Zertifikat aus, das die Identität des Geräts an seinen öffentlichen Schlüssel bindet. Dieser Prozess stellt sicher, dass nur Geräte, die den Besitz ihres privaten Schlüssels nachweisen können, vertrauenswürdige Zertifikate erhalten.
Weitere Informationen zu den Anforderungen an Zertifikatsanfragen in der Azure Device Registry finden Sie unter Zertifikatsausgabe im Azure Device Registry.
Rotationen der Zertifizierungsstellen
Die Rotation der Zertifizierungsstelle ist der geplante oder Notfallprozess, bei dem ein bestehendes Root- oder Zwischenzertifikat der CA durch ein neues ersetzt wird, bevor das alte Zertifikat abläuft oder kompromittiert wird. Da die CA der Vertrauensanker ist und alle nachgelagerten Zertifikate signiert, aktualisiert ihr Ersatz die kryptografische Grundlage jedes Geräts.
In der Azure-Geräteregistrierung werden Zertifizierungsstellen vor dem Ablauf automatisch erneuert:
Neue CA-Generation: Bevor eine CA abläuft, stellt ADR automatisch eine Ersatz-CA bereit. Dieser Schritt leitet eine Übergangsphase ein, in der IoT-Dienste sowohl den alten als auch den neuen CAs vertrauen. Gerätezertifikate, die ADR ausgibt, dürfen kein Ablaufdatum haben, das später als das ihrer Zwischen-CA ist, sodass Sie sich nie Sorgen um Ghost-Zertifikate machen müssen.
Erneuerung des Gerätezertifikats: Während dieses Fensters sollte das Gerät auf seine Ersatz-CA umstellen. Geräte können einfach ein neues Zertifikat gemäß dem regelmäßig geplanten Zertifikatsverlängerungsprozess des Geräts anfordern. ADR leitet automatisch Anfragen zur Signierung von Gerätezertifikaten an die neue zwischenliegende CA weiter.
Einstellung der alten ZS: Sobald das Übergangsfenster geschlossen ist, nimmt ADR die alte ZS außer Betrieb. Jedes Gerät, das kein neues Zertifikat abruft, scheitert an der gegenseitigen TLS-Authentifizierung (mTLS) und verliert die Verbindung. Diese Geräte können ein neues Zertifikat anfordern, um sich mit dem IoT Hub zu verbinden.
Kryptographische Algorithmen und Schlüsseltypen
Zertifikate verwenden Public-Key-Kryptographie, um Vertrauen zwischen Geräten und Diensten herzustellen. Jedes Zertifikat enthält einen öffentlichen Schlüssel und wird von einer Zertifizierungsstelle (CA) mit einem kryptografischen Signierungsalgorithmus signiert. Die Stärke, Leistung und Kompatibilität eines Zertifikats hängen vom Schlüsselalgorithmus, der Schlüsselgröße und dem Hashing-Algorithmus ab, den Sie während der Zertifikatserstellung und -signierung verwenden.
Schlüsselalgorithmen
Das Zertifikatsmanagement nutzt asymmetrische Kryptographie, um vertrauenswürdige digitale Identitäten zu etablieren. In der asymmetrischen Kryptographie wird ein mathematisch verwandtes öffentliches und privates Schlüsselpaar für Authentifizierung, digitale Signaturen und Verschlüsselung verwendet. Die Wahl des kryptographischen Algorithmus beeinflusst Sicherheitsstärke, Leistungsmerkmale, Interoperabilität und Ressourcenanforderungen. Das Zertifikatsmanagement im Azure Device Registry verwendet Elliptic Curve Cryptography (ECC), um Zertifikate zu signieren.
Tastengröße und Tastenkurve
Die Schlüsselgröße oder Schlüsselkurve bestimmt die kryptografische Stärke des öffentlichen und privaten Schlüsselpaares eines Zertifikats. Größere Schlüsselgrößen oder stärkere Kurven bieten in der Regel eine größere kryptografische Stärke, können aber auch die Zertifikatsgröße, die Verarbeitungsanforderungen und die Leistung beeinflussen. Zum Beispiel stellt das Zertifikatsmanagement in Azure Device Registry ECC-Zertifikate mit der P-384-Kurve aus.
Hashing-Algorithmen
Zertifizierungsstellen verwenden kryptografische Hashfunktionen beim Signieren von Zertifikaten. Eine Hashfunktion erzeugt einen festen Digest der Zertifikatsinhalte, den die ausstellende CA dann digital signiert. Hashing-Algorithmen helfen dabei, die Zertifikatsintegrität, die Manipulationserkennung, die Validierung der Vertrauenskette und die Überprüfung digitaler Signaturen sicherzustellen. Das Zertifikatsmanagement im Azure Device Registry verwendet SHA-384.
Digitale Signaturen
Wenn eine Zertifizierungsstelle ein Zertifikat ausgibt, signiert sie das Zertifikat digital mit ihrem privaten Schlüssel und dem gewählten Signaturalgorithmus.
Während der Zertifikatsvalidierung:
Der Hash des Zertifikats wird neu berechnet.
Der öffentliche Schlüssel der CA überprüft die digitale Signatur.
Die Zertifikatskette wird bis zu einer vertrauenswürdigen Root-CA validiert.
Wenn du ein Zertifikat in der Kette modifizierst, scheitert die Signaturvalidierung, und dem Zertifikat kann nicht mehr vertraut werden.
Hardwaregeschützte und softwaregeschützte Schlüssel
Zertifizierungsstellen (CAs) verwenden private Schlüssel, um Zertifikate auszustellen und zu signieren. Die Sicherheit einer CA hängt stark davon ab, wie du diese privaten Schlüssel erstellst, speicherst und nutzt.
Softwaregeschützte Schlüssel werden in der Software gespeichert und sind auf Betriebssystemschutzmaßnahmen angewiesen, um unbefugten Zugriff zu verhindern. Die Bereitstellung von Softwareschlüsseln ist zwar einfacher, sie sind im Allgemeinen jedoch anfälliger für Kompromittierungen durch Malware, Diebstahl von Anmeldeinformationen, Fehlkonfigurationen oder unbefugten administrativen Zugriff.
Hardwaregeschützte Schlüssel werden in einem Hardware Security Module (HSM) generiert und gespeichert, einem dedizierten kryptografischen Gerät, das zum Schutz sensibler Schlüsselmaterialien entwickelt wurde. Private Schlüssel, die in einem HSM gespeichert sind, verlassen niemals die Hardwaregrenze, und alle kryptografischen Signierungsoperationen werden innerhalb des Geräts durchgeführt. Dies verringert das Risiko einer Schlüssel-Exposition erheblich und hilft Organisationen, strenge Sicherheits- und Compliance-Anforderungen zu erfüllen.
Das Azure Device Registry verwendet hardwaregeschützte Schlüssel für Zertifizierungsstellen. Private Schlüssel der Zertifizierungsstelle werden durch die Verwendung von Azure Key Vault Managed HSM geschützt, wodurch sichergestellt wird, dass Signing-Operationen innerhalb einer FIPS-validierten Hardware-Sicherheitsgrenze stattfinden und privates Schlüsselmaterial nicht exportiert werden kann.
Online-CAs vs. Offline-CAs
Sie können Zertifizierungsstellen auch nach ihrem Netzwerkzugang und ihrem Betriebsmodell klassifizieren.
Eine Offline-CA bleibt über die meiste Zeit ihrer Lebensdauer von Produktionsnetzwerken getrennt. Verwenden Sie Offline-CAs als hochsichere Root-CAs, da der private Schlüssel von netzwerkbasierten Bedrohungen isoliert ist. Administrative Maßnahmen erfordern typischerweise manuelle Prozesse, wodurch Offline-CAs sehr sicher, aber betriebsintensiv sind.
Eine Online-CA verbindet sich mit einem Netzwerk und kann automatisch Zertifikatsausgabe, Verlängerung und Lebenszyklusoperationen durchführen. Online-CAs ermöglichen skalierbares Zertifikatsmanagement und Automatisierung, benötigen jedoch starke Kontrollen, um Signingschlüssel und CA-Infrastruktur zu schützen.
Das Azure Device Registry verwendet Online-Zertifizierungsstellen, um automatisierte Zertifikatsausgabe, -verlängerung, -widerruf und -rotation im Cloud-Maßstab zu unterstützen. Azure Managed HSM schützt diese Online-CAs durch hardwaregestützte Schlüsselspeicherung und kombiniert die operativen Vorteile von Online-CAs mit starken Schlüsselschutzkontrollen. Kunden, die das Bring Your Own CA (BYOCA)-Vertrauensmodell verwenden, pflegen ihre Root-CA häufig offline und nutzen sie ausschließlich, um Vertrauen für Online-Zertifizierungsstellen herzustellen. Dieser Ansatz verbindet die Sicherheitsvorteile eines Offline-Vertrauensankers mit der Skalierbarkeit cloud-verwalteter Online-CAs.
Authentifizierung im Vergleich zu Autorisierung
Die Authentifizierung bedeutet, dass die Identität beim IoT Hub nachgewiesen wird. Es wird überprüft, ob ein Benutzer oder Gerät tatsächlich derjenige ist, als der er sich ausgibt. Dieser Prozess wird häufig als AuthN bezeichnet.
Autorisierung bedeutet, dass bestätigt wird, auf welche Elemente ein authentifizierter Benutzer oder Gerät im IoT Hub zugreifen kann. Sie definiert Berechtigungen für Ressourcen und Befehle. Die Autorisierung wird manchmal als AuthZ bezeichnet.
IoT Hub verwendet X.509-Zertifikate ausschließlich zur Authentifizierung, nicht zur Autorisierung. Im Gegensatz zu Microsoft Entra ID und Shared-Access-Signaturen unterstützen X.509-Zertifikate keine anpassbaren Berechtigungen.