Wie können Sie mit Microsoft Azure die Produktivität Ihrer Organisationen steigern?

Organisationen, die Microsoft Azure nutzen, erreichen Compliance (HIPAA, DSGVO, PCI DSS, CCPA, NYDFS und ähnliche Standards) durch eine Kombination aus Azure Policy, Microsoft Defender for Cloud, Microsoft Purview Compliance Manager und den Schlüsselverwaltungsoptionen von Azure Key Vault. Dies ist wichtig, da Azure Blueprints, eines der seit Jahren bewährten Tools, bis zum 31. Januar 2027 schrittweise eingestellt wird. Empfohlene Vorgehensweise: Stellen Sie Ihre gesamte Blueprints-basierte Governance jetzt auf Azure Deployment Stacks und Template Specs um, bevor das Migrationsfenster abläuft.

Veröffentlicht: Februar 2022. Aktualisiert: August 2026. Geprüft vom Compliance Advisory Team von Encryption Consulting.

Grundlagen zu Azure Key Vault finden Sie unter Microsoft Azure-Dienste – Azure Key Vault . Einen Vergleich der Schlüsselverwaltung von Azure mit AWS und GCP finden Sie unter AWS KMS vs. Azure Key Vault vs. GCP KMS . Informationen zur zertifikatsbasierten Identitätsverwaltung in verschiedenen Clouds finden Sie unter Cloudbasierte PKI – GCP, AWS und Azure.

Was bedeutet Compliance für Organisationen, die Azure nutzen?

Compliance bedeutet, die spezifischen Sicherheits- und Datenschutzstandards zu erfüllen, die für die Branche und den Kundenstamm eines Unternehmens gelten. Beispiele hierfür sind HIPAA und HITECH für Gesundheitsdaten, die DSGVO für personenbezogene Daten in Europa, PCI DSS für Zahlungskartendaten sowie landesspezifische Regelungen wie CCPA und NYDFS. Jeder Standard definiert seine eigenen Mindestkontrollen. Daher muss ein Unternehmen seine tatsächlichen Azure-Workloads den jeweils geltenden Standards zuordnen, anstatt von einer allgemeinen Sicherheitsarchitektur auszugehen, die alle abdeckt. Azure allein gewährleistet keine Compliance; es stellt die zugrunde liegenden Kontrollmechanismen (Verschlüsselung, Zugriffsverwaltung, Überwachung und Audit-Tools) bereit, die ein Unternehmen konfiguriert und betreibt, um diese Standards zu erfüllen.

Ist Azure Blueprints immer noch ein Compliance-Tool, auf das man sich verlassen sollte?

Nein. Azure Blueprints, bisher eine gängige Methode, Governance-Artefakte (Richtlinien, Rollenzuweisungen und Ressourcenvorlagen) in einem wiederverwendbaren, organisationsweit genehmigten Framework zu bündeln, wird schrittweise eingestellt. Jede Compliance-Architektur, die noch auf Blueprints basiert, benötigt jetzt einen Migrationsplan und nicht erst später.

Datum	Was ändert sich
Juli 31, 2026	Es können keine neuen Blaupausendefinitionen und keine neuen Versionen bestehender Definitionen mehr erstellt werden.
31. Oktober 2026	Bestehende Definitionen können nicht mehr geändert werden; neue Zuordnungen können nicht mehr erstellt werden.
December 31, 2026	Bestehende Zuweisungen können nicht mehr geändert werden.
31. Januar 2027	Vollständige Außerbetriebnahme: Die Blueprints-API reagiert nicht mehr, der Portalzugriff wird entfernt und alle Blueprint-Artefakte, die nicht zuvor exportiert wurden, werden gelöscht.

Microsofts empfohlene Alternative kombiniert zwei Dienste: Azure Deployment Stacks übernimmt Zuweisung, Bereitstellung und Lebenszyklusverwaltung (einschließlich der Durchsetzung von Zuweisungssperren und dem Ersetzen von Blueprint-Sperren), während Template Specs oder ein Git-Repository die Speicherung und Versionierung der Definitionen übernimmt. Exportieren Sie alle vorhandenen Blueprint-Definitionen, Versionen und Zuweisungen rechtzeitig vor dem 31. Januar 2027, da nicht exportierte Daten bis zu diesem Datum nicht wiederhergestellt werden können.

Azure Policy ist von dieser Einstellung nicht betroffen und bleibt das aktuelle Werkzeug zum Definieren und Durchsetzen von Geschäftsregeln für Azure-Ressourcen; es war immer die Governance-Engine unter Blueprints und wird auch nach dem Wegfall von Blueprints eigenständig weitergeführt.

Wie funktioniert die native im Vergleich zur externen Schlüsselverwaltung in Azure Key Vault?

Azure Key Vault und die zugehörigen Dienste bieten mehrere Stufen der Schlüsselverwahrung, die jeweils einen Kompromiss zwischen Kosten, Isolation und der letztendlichen Kontrolle über das Schlüsselmaterial darstellen:

Schlüsselkontrollebene	So funktioniert’s	Optimale Bildschirmwahl
Key Vault Standard (nativ, Software)	In einer Multi-Tenant-Umgebung sind die Schlüssel softwaregeschützt.	Standardeinstellung für die meisten Arbeitslasten; niedrigste Kosten.
Key Vault Premium (nativ, HSM-gestützt)	Die Schlüssel werden in einem gemeinsam genutzten, mandantenfähigen Pool von Hardware-Sicherheitsmodulen geschützt.	Workloads, die hardwaregestützte Schlüssel benötigen, ohne dass dafür ein dediziertes HSM anfällt.
Azure Key Vault Managed HSM (nativ, dediziert)	Die Schlüssel befinden sich in einem dedizierten, mandantenfähigen, FIPS 140-3 Level 3 validierten HSM-Pool, der von Microsoft im Auftrag des Kunden betrieben wird.	Regulierte Arbeitslasten, die die Verwahrung dedizierter Hardware und die vollständige administrative Kontrolle über das HSM erfordern.
Azure Dedicated HSM (kundenseitig kontrollierte Hardware)	Eine physische HSM-Appliance für einen einzelnen Mandanten in Azure, die direkt vom Kunden und nicht von Microsoft verwaltet wird.	Organisationen, die aufgrund der Compliance-Vorgabe verpflichtet sind, dass der Cloud-Anbieter das HSM niemals selbst verwaltet.
BYOK (importiertes Schlüsselmaterial)	Schlüsselmaterial, das außerhalb von Azure (oft in einem lokalen HSM) generiert wird, wird in Key Vault oder Managed HSM importiert, welches dann seinen Lebenszyklus verwaltet.	Organisationen, die die Herkunft von Schlüsseln nachweisen müssen oder bereits Schlüssel über ein bestehendes lokales HSM generieren.

Standardmäßig wird Key Vault Standard oder Premium verwendet, es sei denn, eine bestimmte Anforderung verlangt den dedizierten Pool von Managed HSM oder die vom Kunden verwaltete Hardware von Dedicated HSM. Beide Varianten verursachen deutlich höhere Kosten und einen größeren Betriebsaufwand und lohnen sich nur, wenn eine spezifische Compliance-Vorgabe dieses Isolationsniveau erfordert.

Wie sollte IAM für Azure Key Vault und Compliance-Tools strukturiert sein?

Die rollenbasierte Zugriffssteuerung (RBAC) von Azure ist das von Microsoft empfohlene Berechtigungsmodell für Key Vault und ersetzt das ältere Zugriffsrichtliniensystem auf Vault-Ebene durch die gleichen detaillierten, überprüfbaren Rollenzuweisungen, die im übrigen Azure verwendet werden.

1. Migrieren Sie Tresore, die noch das veraltete Zugriffsrichtlinien-Berechtigungsmodell verwenden, zu Azure RBAC, da RBAC mit Azure AD Conditional Access integriert ist und einen konsistenten Prüfpfad über alle Dienste hinweg erzeugt.
2. Trennen Sie die Schlüsseltresor-Kryptobeauftragter Rolle (Schlüssellebenszyklusverwaltung: Erstellen, Rotieren, Löschen) von Key Vault Krypto-Benutzer (nur Verschlüsselungs-/Entschlüsselungs-/Signaturvorgänge), wobei jeder Vorgang einer anderen Identität zugeordnet wird.
3. Die Rollenzuweisung sollte auf Ebene des Tresors oder einzelner Schlüssel und nicht auf Abonnementebene erfolgen, damit eine einzige zu weit gefasste Berechtigung nicht jeden Schlüssel im Abonnement offenlegt.
4. Die Rollenzuweisungen für Tresore sollten im gleichen Rhythmus wie andere Zugriffsüberprüfungen für die Produktion überprüft werden, da eine veraltete Krypto-Benutzerberechtigung einer permanenten Entschlüsselungsberechtigung gleichkommt.

Wie sollte die Schlüsselrotation in Azure gehandhabt werden?

Azure Key Vault unterstützt integrierte automatische Rotationsrichtlinien. Organisationen können so einen Rotationszeitraum und optional ein Benachrichtigungsfenster vor Ablauf der Schlüssel festlegen. Wie bei allen gängigen Cloud-Schlüsselverwaltungsdiensten wird durch die Rotation lediglich eine neue Schlüsselversion für zukünftige Vorgänge erstellt. Bereits durch eine vorherige Version geschützte Daten werden nicht erneut verschlüsselt, und die vorherige Version wird nicht automatisch gelöscht. Ein vollständiger Rotationsplan erfordert einen separaten Schritt zur erneuten Verschlüsselung sowie einen expliziten Zeitplan für die Löschung alter Schlüsselversionen, sobald diese nicht mehr benötigt werden.

Was sollten Sie für Azure Compliance und Schlüsselverwaltung protokollieren?

• Key Vault-Diagnoseprotokolle, Die Daten werden an Azure Monitor oder Log Analytics gesendet und umfassen alle wichtigen Operationen, die Identität des Aufrufers und die verwendete Schlüsselversion.
• Microsoft Defender for Cloud-Warnungen bei auffälligen Zugriffsmustern auf Key Vault und andere überwachte Ressourcen.
• Änderungen des Azure Policy-Konformitätsstatus Nachverfolgung, wann eine Ressource die zugewiesene Richtlinie einhält oder nicht mehr einhält.
• Bewertungshistorie von Microsoft Purview Compliance Manager das den Status von Verbesserungsmaßnahmen im Zeitverlauf für Standards wie HIPAA und DSGVO erfasst.

Was kosten die Compliance- und Schlüsselverwaltungstools von Azure?

Key Vault Standard und Premium werden pro Schlüsseloperation und pro HSM-geschützter Schlüsselversion abgerechnet. Managed HSM und Dedicated HSM haben eine deutlich höhere Pauschalgebühr, um die dedizierte Hardwarekapazität abzudecken. Microsoft Defender for Cloud wird pro geschützter Ressource abgerechnet, sobald die erweiterten Pläne aktiviert sind. Die Kernfunktionen von Microsoft Purview Compliance Manager sind in bestimmten Microsoft 365- und Compliance-Abonnements enthalten und werden nicht separat abgerechnet. Azure Deployment Stacks und Template Specs sind native Azure Resource Manager-Funktionen und verursachen keine zusätzlichen Servicegebühren über die bereitgestellten Ressourcen hinaus. Prüfen Sie die aktuellen Preise pro Einheit auf den Preisseiten von Microsoft, bevor Sie eine Migration von Blueprints planen, da diese Tools nach völlig anderen Modellen abgerechnet und lizenziert werden.

Wie sieht eine Multi-Cloud-Compliance-Architektur für Azure, AWS und GCP aus?

Jede der großen Cloud-Plattformen implementiert dieselben konzeptionellen Schichten – eine Governance-Engine für Richtlinien als Code, einen Dienst zur kontinuierlichen Überwachung des Sicherheitsstatus und einen mehrstufigen Schlüsselverwaltungsdienst – unter verschiedenen Namen: Azure Policy und Defender for Cloud auf Azure, AWS Config und Security Hub auf AWS sowie Organization Policy und Security Command Center auf GCP. Eine konsistente Multi-Cloud-Compliance-Architektur bildet dieselben Kontrollziele (Verschlüsselung ruhender Daten, Zugriff auf Schlüssel nach dem Prinzip der minimalen Berechtigungen, kontinuierliche Überwachung) auf die jeweiligen nativen Tools der einzelnen Clouds ab, anstatt zu versuchen, eine einzige Governance-Engine für alle drei Plattformen zu betreiben, da keine von ihnen die Ressourcen einer anderen nativ verwaltet.

In unserem Vergleich von AWS KMS, Azure Key Vault und GCP KMS finden Sie eine detaillierte Aufschlüsselung der Unterschiede im Schlüsselmanagement der drei Systeme. Einen Vergleich der zertifikatsbasierten Identitätssysteme finden Sie unter Cloud-basierte PKI – GCP, AWS und Azure .

Welche Einschränkungen gibt es bei den Compliance-Tools von Azure?

• Die schrittweise Abschaffung von Azure Blueprints zwingt jede Organisation, die ihre Governance darauf aufgebaut hat, zu einem echten Migrationsprojekt; Deployment Stacks und Template Specs sind kein direkter Ersatz, sondern erfordern eine Neufassung der Governance-Artefakte.
• Sowohl Managed HSM als auch Dedicated HSM sind deutlich teurer als Standard oder Premium Key Vault, was sich durch eine tatsächliche Compliance-Anforderung rechtfertigen lässt und nicht einfach standardmäßig übernommen werden sollte.
• Die Migration von Tresoren vom alten Zugriffsrichtlinienmodell auf RBAC erfordert eine sorgfältige Planung, da die beiden Modelle nicht immer eins zu eins übereinstimmen und eine überstürzte Migration entweder zu viele Zugriffsrechte gewähren oder legitime Zugriffe aussperren kann.
• Sowohl Microsoft Defender for Cloud als auch Purview Compliance Manager erfordern eine anfängliche Anpassung; die standardmäßigen Alarm- und Bewertungsschwellenwerte erzeugen Rauschen, das auf das tatsächliche Risikoprofil der Organisation abgestimmt werden muss.

Entscheidungscheckliste: Modernisierung der Compliance auf Azure

1. Erstellen Sie ein Inventar aller aktuell verwendeten Azure Blueprints-Definitionen und -Zuweisungen und planen Sie deren Migration vor dem Stichtag 31. Juli 2026 für neue Definitionen.
2. Governance-Artefakte werden mithilfe von Azure Deployment Stacks für die Zuweisung und den Lebenszyklus sowie Template Specs oder Git für die Definitionsspeicherung neu erstellt.
3. Wählen Sie die Key Vault-Stufe (Standard, Premium, Managed HSM oder Dedicated HSM) anhand einer tatsächlich dokumentierten Anforderung und nicht standardmäßig.
4. Migrieren Sie alle Tresore, die noch das veraltete Zugriffsrichtlinienmodell verwenden, zu Azure RBAC, um die Schlüsselverwaltung von der Schlüsselverwendung zu trennen.
5. Aktivieren Sie die automatische Rotation des Key Vaults und dokumentieren Sie den separaten Prozess der erneuten Verschlüsselung für bestehende Daten.

Was würde Encryption Consulting empfehlen?

Die meisten unserer Azure-Kunden nutzen noch immer Blueprints-basierte Governance ohne Migrationsplan, was eine geplante Abschaltung schnell zu einem unvorhergesehenen Chaos führen kann. Die Compliance-Beratungsdienste von Encryption Consulting ordnen Ihre tatsächlichen regulatorischen Verpflichtungen (HIPAA, DSGVO, PCI DSS usw.) den passenden Azure-Kontrollen zu, planen Ihre Migration von Blueprints zu Deployment-Stacks und bieten Ihnen mit unserem HSM-as-a-Service -Angebot hardwaregestützte Schlüsselverwaltung, ohne dass Sie die HSM-Infrastruktur direkt betreiben müssen.

Häufig gestellte Fragen

Wann wird Azure Blueprints tatsächlich eingestellt?

Die vollständige Außerdienststellung ist für den 31. Januar 2027 geplant, die schrittweise Abschaffung beginnt jedoch früher: Neue Entwurfsdefinitionen sind ab dem 31. Juli 2026 nicht mehr möglich, und weitere Einschränkungen gelten ab dem 31. Oktober und 31. Dezember 2026.

Was sollte Azure Blueprints ersetzen?

Microsoft empfiehlt Azure Deployment Stacks für die Zuweisung, Bereitstellung und das Lebenszyklusmanagement, kombiniert mit Template Specs oder einem Git-Repository zum Speichern und Versionieren der zugrunde liegenden Vorlagen.

Ist Azure Security Center noch das richtige Tool?

Das Azure Security Center wurde in Microsoft Defender for Cloud umbenannt; die zugrunde liegende Funktion zur kontinuierlichen Überwachung des Sicherheitsstatus ist unter diesem Namen weiterhin aktuell.

Worin besteht der Unterschied zwischen Azure Key Vault Premium und Managed HSM?

Premium schützt Schlüssel in einem gemeinsam genutzten, mandantenfähigen Hardware-Sicherheitsmodul-Pool; Managed HSM schützt Schlüssel in einem dedizierten, mandantenfähigen, FIPS 140-3 Level 3 validierten HSM-Pool mit voller administrativer Kontrolle, zu entsprechend höheren Kosten.

Führt die Rotation eines Key-Vault-Schlüssels automatisch zu einer erneuten Verschlüsselung der vorhandenen Daten?

Nein. Durch die Rotation wird lediglich eine neue aktive Schlüsselversion für zukünftige Operationen erstellt; Daten, die bereits mit der vorherigen Version verschlüsselt wurden, bleiben von dieser abhängig, bis ein expliziter Neuverschlüsselungsprozess ausgeführt wird.

Benötigen Sie Unterstützung bei der Planung Ihrer Azure Blueprints-Migration oder bei der Zuordnung Ihrer Compliance-Anforderungen zu den richtigen Azure-Steuerelementen? Sprechen Sie mit dem Compliance Advisory Team von Encryption Consulting.

Referenzen

Einstellung von Azure Blueprints – learn.microsoft.com

Wie Sie die richtige Azure-Schlüsselverwaltungslösung auswählen – learn.microsoft.com