Freigeben über

Azure SQL Transparent Data Encryption mithilfe eines kundenseitig verwalteten Schlüssels

Gilt für:Azure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse Analytics (nur dedizierte SQL-Pools)

Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) in Azure SQL mit kundenseitig verwalteten Schlüsseln (CMK) ermöglicht BYOK-Szenarien (Bring Your Own Key) für den Schutz von Daten im Ruhezustand und gibt Organisationen die Möglichkeit, Verwaltungsaufgaben von den Schlüsseln und Daten zu trennen. Bei vom Kunden verwalteter TDE ist der Kunde vollständig für die Kontrolle und Verwaltung des Lebenszyklus von Schlüsseln (Erstellung, Hochladen, Rotation, Löschung), der Berechtigungen zur Schlüsselnutzung sowie das Audit von Vorgängen an Schlüsseln verantwortlich.

In diesem Szenario wird der Schutz für transparente Datenverschlüsselung (Transparent Data Encryption, TDE) – ein vom Kunden verwalteter asymmetrischer Schlüssel, der zum Sichern des Datenbankverschlüsselungsschlüssels (DEK) verwendet wird, entweder in Azure Key Vault oder azure Key Vault Managed HSM gespeichert. Dies sind sichere, cloudbasierte Schlüsselverwaltungsdienste, die für hohe Verfügbarkeit und Skalierbarkeit konzipiert sind. Azure Key Vault unterstützt RSA-Schlüssel und kann von FIPS 140-2 Level 2 validierten HSMs gesichert werden. Für Kunden, die eine höhere Sicherheit erfordern, bietet Azure Key Vault Managed HSM FIPS 140-2 Level 3 validierte Hardware. Der Schlüssel kann im Dienst generiert, importiert oder sicher von lokalen HSMs übertragen werden. Der direkte Zugriff auf Schlüssel ist eingeschränkt – autorisierte Dienste führen kryptografische Vorgänge aus, ohne das Schlüsselmaterial verfügbar zu machen.

Bei Azure SQL-Datenbank und Azure Synapse Analytics wird der TDE-Schutz auf der Serverebene festgelegt und von allen verschlüsselten Datenbanken geerbt, die diesem Server zugeordnet sind. Bei der verwalteten Azure SQL-Instanz wird der TDE-Verschlüsselungsschutz auf der Instanzebene festgelegt und von allen verschlüsselten Datenbanken auf dieser Instanz geerbt. Der Begriff "Server" bezieht sich sowohl auf einen Server in der SQL-Datenbank und Azure Synapse als auch auf eine verwaltete Instanz in SQL Managed Instance in diesem Artikel, es sei denn, es wird anders angegeben.

Die Verwaltung der TDE-Schutzvorrichtung auf Datenbankebene in Azure SQL-Datenbank ist verfügbar. Weitere Informationen finden Sie unter Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) mit kundenseitig verwalteten Schlüsseln auf Datenbankebene.

Hinweis

Dieser Artikel gilt für Azure SQL-Datenbank, Azure SQL Managed Instance und Azure Synapse Analytics (dedizierte SQL-Pools (vormals SQL DW)). Weitere Informationen zur transparenten Datenverschlüsselung für dedizierte SQL-Pools in Synapse-Arbeitsbereichen finden Sie unter Azure Synapse Analytics-Verschlüsselung.

Hinweis

Microsoft Entra ID war zuvor als Azure Active Directory (Azure AD) bekannt.

Vom Kunden verwalteter Schlüssel (CMK) und Bring Your Own Key (BYOK)

In diesem Artikel werden die Begriffe Customer Managed Key (CMK) und Bring Your Own Key (BYOK) austauschbar verwendet, stellen jedoch einige Unterschiede dar.

  • vom Kunden verwalteter Schlüssel (Customer Managed Key, CMK) – Der Kunde verwaltet den Schlüssellebenszyklus, einschließlich Schlüsselerstellung, Drehung und Löschung. Der Schlüssel wird in Azure Key Vault oder azure Managed HSM gespeichert und für die Verschlüsselung des Datenbankverschlüsselungsschlüssels (DEK) in Azure SQL, SQL Server auf Azure VM und sql Server lokal verwendet.

  • Bring Your Own Key (BYOK) – Der Kunde bringt oder importiert sicher seinen eigenen Schlüssel aus einem lokalen Hardwaresicherheitsmodul (HSM) in Azure Key Vault oder azure Managed HSM. Solche importierten Schlüssel können als anderer Schlüssel im Azure Key Vault verwendet werden, einschließlich als vom Kunden verwalteter Schlüssel für die Verschlüsselung der DEK. Weitere Informationen finden Sie unter Import von durch HSM geschützte Schlüssel in ein Managed HSM (BYOK).

Vorteile der kundenseitig verwalteten TDE

Eine kundenseitig verwaltete TDE bietet Kunden die folgenden Vorteile:

  • Vollständige und präzise Kontrolle über die Verwendung und Verwaltung der TDE-Schutzkomponente.

  • Transparenz der TDE-Schutzverwendung.

  • Möglichkeit, die Trennung von Aufgaben in der Verwaltung von Schlüsseln und Daten innerhalb der Organisation zu implementieren.

  • Der Azure Key Vault-Administrator kann Schlüsselzugriffsberechtigungen widerrufen, um auf verschlüsselte Datenbanken nicht zugreifen zu können.

  • Zentrale Verwaltung von Schlüsseln in Azure Key Vault.

  • Größeres Vertrauen ihrer Endbenutzer, da Azure Key Vault so konzipiert ist, dass Microsoft keine Verschlüsselungsschlüssel sehen oder extrahieren kann.

Wichtig

Für Diejenigen, die dienstverwaltete TDE verwenden möchten, die mit der Verwendung von vom Kunden verwalteten TDE beginnen möchten, bleiben Die Daten während des Wechsels verschlüsselt, und es gibt keine Ausfallzeiten oder eine erneute Verschlüsselung der Datenbankdateien. Der Wechsel von einem dienstseitig verwalteten Schlüssel zu einem kundenseitig verwalteten Schlüssel erfordert lediglich eine erneute Verschlüsselung des Datenbankverschlüsselungsschlüssels (DEK), die schnell und online durchzuführen ist.

Berechtigungen zum Konfigurieren von kundengesteuerten TDE

Diagramm, dass die Einrichtung und Funktionsweise der kundenseitig verwalteten TDE zeigt.

Wählen Sie den Typ von Azure Key Vault aus, den Sie verwenden möchten.

Damit der logische Server in Azure die TDE-Schutzkomponente verwenden kann, die in Azure Key Vault für die Verschlüsselung des DEK gespeichert ist, muss der Key Vault-Administrator den Zugriff auf den Server mithilfe seiner eindeutigen Microsoft Entra-Identität gewähren. Die Serveridentität kann eine systemseitig zugewiesene verwaltete Identität oder eine benutzerseitig zugewiesene verwaltete Identität sein, die dem Server zugewiesen ist. Es gibt zwei Zugriffsmodelle, um dem Server Zugriff auf den Schlüsseltresor zu gewähren:

  • Rollenbasierte Zugriffssteuerung von Azure (RBAC) – Verwenden Sie Azure RBAC, um einem Benutzer, einer Gruppe oder einer Anwendung Zugriff auf den Schlüsseltresor zu gewähren. Diese Methode wird wegen ihrer Flexibilität und Granularität empfohlen. Die Serveridentität benötigt die Rolle Key Vault Crypto Service Encryption-Benutzer*in, damit sie den Schlüssel für Verschlüsselungs- und Entschlüsselungsvorgänge verwenden kann.

  • Tresorzugriffsrichtlinie – Verwenden Sie die Zugriffsrichtlinie für den Schlüsseltresor, um dem Server Zugriff auf den Schlüsseltresor zu gewähren. Diese Methode ist einfacher und unkomplizierter, aber weniger flexibel. Die Serveridentität muss über die folgenden Berechtigungen für das Key Vault verfügen:

    • abrufen – zum Abrufen des öffentlichen Teils und der Eigenschaften des Schlüssels im Azure Key Vault
    • wrapKey – um den DEK schützen (verschlüsseln) zu können
    • unwrapKey: zum Aufheben des Schutzes (der Verschlüsselung) des DEK

Im Zugriffskonfiguration Azure-Portal Menü des Schlüsseltresors haben Sie die Möglichkeit, die Azure-rollenbasierte Zugriffssteuerung oder Tresor-Zugriffsrichtlinie auszuwählen. Schrittweise Anleitungen zum Einrichten einer Azure Key Vault-Zugriffskonfiguration für TDE finden Sie unter Einrichten von SQL Server TDE Extensible Key Management mithilfe von Azure Key Vault. Weitere Informationen zu den Zugriffsmodellen finden Sie unter Azure Key Vault – Sicherheit.

Ein Key Vault-Administrator kann auch die Protokollierung von Key Vault-Überwachungsereignissen aktivieren, damit sie später überprüft werden können.

Wenn ein Server für die Verwendung einer TDE-Schutzkomponente aus Azure Key Vault konfiguriert ist, sendet der Server die DEK jeder TDE-fähigen Datenbank an den Schlüsseltresor für die Verschlüsselung. Key Vault gibt den verschlüsselten DEK zurück, der in der Benutzerdatenbank gespeichert wird.

Falls erforderlich, sendet der Server den geschützten DEK zur Entschlüsselung an die Schlüsselverwaltung.

Prüfer können Azure Monitor verwenden, um die AuditEvent-Protokolle von Key Vault zu überprüfen, sofern die Protokollierung aktiviert wurde.

Hinweis

Es kann ca. 10 Minuten dauern, bis alle Berechtigungsänderungen für den Key Vault wirksam werden. Dies umfasst das Aufheben der Zugriffsberechtigungen für die TDE-Schutzvorrichtung in AKV, und innerhalb dieses Zeitraums können Benutzer weiterhin über Zugriffsberechtigungen verfügen.

Anforderungen zum Konfigurieren von vom Kunden verwalteten TDE

  • Soft-Delete und Löschschutz müssen im Azure Key Vault aktiviert sein. Dadurch kann verhindert werden, dass ein Schlüsseltresor oder ein Schlüssel versehentlich oder böswillig gelöscht wird, was zum Wechsel der Datenbank in den Zustand Kein Zugriff führen kann. Beim Konfigurieren der TDE-Schutzvorrichtung auf einem vorhandenen Server oder während der Servererstellung überprüft Azure SQL, ob das vorläufige Löschen und der Löschschutz für den verwendeten Schlüsseltresor aktiviert sind. Wenn das vorläufige Löschen und der Löschschutz für den Schlüsseltresor nicht aktiviert sind, tritt beim Setup der TDE-Schutzvorrichtung ein Fehler auf. In diesem Fall müssen zuerst das vorläufige Löschen und der Löschschutz für den Schlüsseltresor aktiviert werden, und anschließend sollte das Setup der TDE-Schutzvorrichtung ausgeführt werden.

  • Wenn Sie eine Firewall mit Azure Key Vault verwenden, müssen Sie die Option Aktivieren, dass vertrauenswürdige Microsoft-Dienste die Firewall umgehen können, es sei denn, Sie verwenden private Endpunkte für den Azure Key Vault. Weitere Informationen finden Sie unter Konfigurieren von Azure Key Vault-Firewalls und virtuellen Netzwerken.

Anforderungen an die Konfiguration der TDE-Schutzvorrichtung

  • Die TDE-Schutzvorrichtung darf nur ein asymmetrischer RSA- oder RSA HSM-Schlüssel sein. Die unterstützten Schlüssellängen sind 2.048 Bit und 3.072 Bit.

  • Das Schlüsselaktivierungsdatum (sofern festgelegt) muss ein Datum und eine Uhrzeit in der Vergangenheit sein. Das Ablaufdatum (sofern festgelegt) muss ein Datum und eine Uhrzeit in der Zukunft sein.

  • Der Schlüssel muss sich im Zustand Aktiviert befinden.

  • Wenn Sie einen vorhandenen Schlüssel in den Schlüsseltresor importieren, stellen Sie sicher, dass er in einem der unterstützten Dateiformate bereitgestellt wird: .pfx, , .byokoder .backup. Informationen zum Importieren von HSM-geschützten Schlüsseln in Azure Managed HSM finden Sie unter Importieren von HSM-geschützten Schlüsseln in Verwaltetes HSM (BYOK).To import HSM-protected keys into Azure Managed HSM, see Import HSM-protected keys to Managed HSM (BYOK).

Hinweis

Ein Problem mit Thales CipherTrust Manager-Versionen vor v2.8.0 verhindert, dass neu importierte Schlüssel in Azure Key Vault mit Azure SQL-Datenbank oder azure SQL Managed Instance für kundenverwaltete TDE-Szenarien verwendet werden. Weitere Informationen zu diesem Problem finden Sie hier. Warten Sie für solche Fälle 24 Stunden nach dem Importieren des Schlüssels in Azure Key Vault, um sie als TDE-Schutzkomponente für den Server oder die verwaltete Instanz zu verwenden. Dieses Problem wurde in Thales CipherTrust Manager v2.8.0 behoben.

Empfehlungen für die Konfiguration einer kundenseitig verwalteten TDE

  • Um eine optimale Leistung und Zuverlässigkeit sicherzustellen, wird dringend empfohlen, einen dedizierten Azure Key Vault für Azure SQL zu verwenden. Dieser Schlüsseltresor sollte nicht für andere Dienste freigegeben werden. Wenn der Schlüsseltresor durch gemeinsame Nutzung oder übermäßige Schlüsselvorgänge hoher Belastung ausgesetzt ist, kann dies die Datenbankperformance negativ beeinflussen, insbesondere bei Zugriff auf den Verschlüsselungsschlüssel. Azure Key Vault erzwingt Drosselungsgrenzen. Wenn diese Grenzwerte überschritten werden, können Vorgänge verzögert oder fehlschlagen. Dies ist bei Serverfailovern wichtig, wodurch Schlüsselvorgänge für jede Datenbank auf dem Server ausgelöst werden.

    Weitere Informationen zum Drosselungsverhalten finden Sie im Azure Key Vault Drosselungsleitfaden.

    Um hohe Verfügbarkeit aufrechtzuerhalten und Drosselungen zu vermeiden, befolgen Sie die nachfolgenden Richtlinien pro Abonnement:

    • Verwenden Sie einen dedizierten Azure Key Vault für Azure SQL-Ressourcen.

    • Ordnen Sie nicht mehr als 500 Allgemeine Datenbanken einem einzelnen Azure Key Vault zu.

    • Ordnen Sie nicht mehr als 200 Business Critical-Datenbanken einem einzigen Azure Key Vault zu.

    • Die Anzahl der Hyperscale-Datenbanken, die einem einzelnen Azure Key Vault zugeordnet werden können, wird durch die Anzahl der Seitenserver bestimmt. Jeder Seitenserver ist mit einer logischen Datendatei verknüpft. Führen Sie die folgende Abfrage aus, um die Anzahl der Seitenserver zu finden.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Ordnen Sie nicht mehr als 500 Seitenserver einem einzelnen Azure Key Vault zu. Wenn die Datenbank wächst, nimmt die Anzahl der Seitenserver automatisch zu, daher ist es wichtig, die Datenbankgröße regelmäßig zu überwachen. Wenn die Anzahl der Seitenserver 500 überschreitet, verwenden Sie einen dedizierten Azure Key Vault für jede Hyperscale-Datenbank, die nicht für andere Azure SQL-Ressourcen freigegeben ist.

    • Überwachen und Konfigurieren von Azure Key Vault-Warnungen. Weitere Informationen zur Überwachung und Warnung finden Sie unter Überwachen von Azure Key Vault und Konfigurieren von Azure Key Vault-Warnungen.

  • Legen Sie eine Ressourcensperre für den Schlüsseltresor fest, um zu steuern, wer diese wichtige Ressource löschen kann, und um ein versehentliches oder nicht autorisiertes Löschen zu verhindern. Erfahren Sie mehr über Ressourcensperren.

  • Aktivieren Sie die Überwachung und Berichterstellung für alle Verschlüsselungsschlüssel: Azure Key Vault stellt Protokolle bereit, die einfach in andere Sicherheitsinformationen und Ereignisverwaltungstools eingefügt werden können. Log Analytics in Operations Management Suite ist ein Beispiel für einen Dienst, der bereits integriert ist.

  • Verwenden Sie einen Key Vault aus einer Azure-Region, die ihre Inhalte in eine gekoppelte Region replizieren kann, um maximale Verfügbarkeit zu gewährleisten. Weitere Informationen finden Sie unter Bewährte Methoden für die Verwendung von Azure Key Vault und Verfügbarkeit und Redundanz von Azure Key Vault.

Hinweis

Um eine größere Flexibilität beim Konfigurieren von vom Kunden verwalteten TDE zu ermöglichen, können Azure SQL-Datenbank und azure SQL Managed Instance in einer Region jetzt mit Azure Key Vault in jeder anderen Region verknüpft werden. Der Server und der Schlüsseltresor müssen sich nicht in derselben Region befinden.

Empfehlungen für die Konfiguration der TDE-Schutzvorrichtung

  • Bewahren Sie eine Kopie der TDE-Schutzvorrichtung an einem sicheren Ort auf oder hinterlegen Sie sie bei einem Treuhanddienst.

  • Wenn der Schlüssel im Schlüsseltresor generiert wird, erstellen Sie eine Schlüsselsicherung, bevor Sie den Schlüssel zum ersten Mal in Azure Key Vault verwenden. Die Sicherung kann nur in einer Azure Key Vault-Instanz wiederhergestellt werden. Unter Backup-AzKeyVaultKey erfahren Sie mehr zu diesem Befehl. Azure Managed HSM unterstützt das Erstellen einer vollständigen Sicherung des gesamten Inhalts des HSM, einschließlich aller Schlüssel, Versionen, Attribute, Tags und Rollenzuweisungen. Weitere Informationen finden Sie unter Vollständige Sicherung und Wiederherstellung und Selektive Schlüsselwiederherstellung.

  • Erstellen Sie immer dann eine neue Sicherung, wenn Änderungen am Schlüssel (z. B. Schlüsselattribute, Tags, ACLs) vorgenommen werden.

  • Behalten Sie vorherige Versionen des Schlüssels im Schlüsseltresor oder im verwalteten HSM beim Rotieren von Schlüsseln, sodass ältere Datenbanksicherungen wiederhergestellt werden können. Wenn die TDE-Schutzvorrichtung für eine Datenbank geändert wird, werden alte Sicherungen der Datenbank nicht aktualisiert, um die aktuelle TDE-Schutzvorrichtung zu verwenden. Bei der Wiederherstellung ist für jede Sicherung die TDE-Schutzvorrichtung erforderlich, mit der sie zum Erstellungszeitpunkt verschlüsselt wurde. Schlüsselrotationen können gemäß den Anweisungen im Artikel Rotation des TDE-Schlüssels für die transparente Datenverschlüsselung ausgeführt werden.

  • Behalten Sie alle zuvor verwendeten Schlüssel in Azure Key Vault oder azure Managed HSM bei, auch nachdem Sie zu dienstverwalteten Schlüsseln gewechselt haben. Es stellt sicher, dass Datenbanksicherungen mit den TDE-Schutzkomponenten wiederhergestellt werden können, die in Azure Key Vault oder azure Managed HSM gespeichert sind. TDE-Schutzkomponenten, die mit Azure Key Vault oder azure Managed HSM erstellt wurden, müssen verwaltet werden, bis alle verbleibenden gespeicherten Sicherungen mit dienstverwalteten Schlüsseln erstellt wurden. Erstellen Sie mithilfe von Backup-AzKeyVaultKey wiederherstellbare Sicherungskopien dieser Schlüssel.

  • Wenn Sie einen potenziell kompromittierten Schlüssel während eines Sicherheitsvorfalls ohne Datenverlust entfernen möchten, führen Sie die Schritte im Artikel Entfernen einer transparenten Datenverschlüsselungskomponente (Transparent Data Encryption, TDE) mithilfe von PowerShell aus.

Rotation der TDE-Schutzvorrichtung

Die Rotation der TDE-Schutzvorrichtung für einen Server bewirkt einen Wechsel zu einem neuen asymmetrischen Schlüssel, der die Datenbanken auf dem Server schützt. Die Schlüsselrotation ist ein Onlinevorgang und sollte nur wenige Sekunden in Anspruch nehmen. Bei diesem Vorgang wird nur der Verschlüsselungsschlüssel der Datenbank entschlüsselt und wieder verschlüsselt, nicht die gesamte Datenbank.

Die Rotation der TDE-Schutzvorrichtung kann entweder manuell oder unter Verwendung des Features zur automatisierten Rotation erfolgen.

Die automatische Rotation der TDE-Schutzvorrichtung kann beim Konfigurieren der TDE-Schutzvorrichtung für den Server aktiviert werden. Die automatisierte Rotation ist standardmäßig deaktiviert. Wenn diese Option aktiviert ist, überprüft der Server kontinuierlich den Schlüsseltresor oder das verwaltete Hardware-Sicherheitsmodul (HSM) auf neue Versionen des Schlüssels, der als TDE-Schutz verwendet wird. Wenn eine neue Version des Schlüssels erkannt wird, wird die TDE-Schutzkomponente auf dem Server oder der Datenbank innerhalb von 24 Stunden automatisch in die neueste Schlüsselversion gedreht.

Bei Verwendung mit automatisierter Schlüsselrotation in Azure Key Vault oder Autorotation in Azure Managed HSM ermöglicht dieses Feature die End-to-End-Zero-Touch-Drehung für die TDE-Schutzkomponente in Azure SQL-Datenbank und azure SQL Managed Instance.

Hinweis

Das Festlegen von TDE mit CMK mit manueller oder automatisierter Drehung von Schlüsseln verwendet immer die neueste Version des unterstützten Schlüssels. Das Setup lässt die Verwendung einer vorherigen oder niedrigeren Version von Schlüsseln nicht zu. Die Verwendung der neuesten Schlüsselversion entspricht der Azure SQL-Sicherheitsrichtlinie, die frühere Schlüsselversionen, die kompromittiert sein könnten, nicht zulässt. Die früheren Versionen des Schlüssels werden möglicherweise für Datenbanksicherungen oder -wiederherstellungen benötigt, insbesondere für Langzeitsicherungen, bei denen die älteren Schlüsselversionen erhalten bleiben müssen. Für Georeplikationssetups müssen alle vom Quellserver benötigten Schlüssel auf dem Zielserver vorhanden sein.

Überlegungen zur Georeplikation beim Konfigurieren der automatisierten Rotation der TDE-Schutzvorrichtung

Wenn die automatische Rotation der TDE-Schutzvorrichtung auf dem primären oder sekundären Server aktiviert ist, sollten Sie unbedingt die folgenden Regeln beim Konfigurieren der Georeplikation befolgen, um Probleme beim Einrichten oder während der Verwendung der Georeplikation zu vermeiden:

  • Sowohl der primäre als auch der sekundäre Server müssen über die Berechtigungen Get, wrapKey und unwrapKey für den Schlüsseltresor des primären Servers (des Schlüsseltresors, der den Schlüssel der TDE-Schutzvorrichtung für den primären Servers enthält) verfügen.

  • Bei einem Server mit aktivierter automatischer Schlüsselrotation fügen Sie vor dem Start der Georeplikation den auf dem primären Server als TDE-Schutzvorrichtung verwendeten Verschlüsselungsschlüssel zum sekundären Server hinzu. Der sekundäre Server benötigt Zugriff auf den Schlüssel im selben Schlüsseltresor oder in einem verwalteten HSM, das mit dem primären Server verwendet wird (und nicht auf einen anderen Schlüssel mit demselben Schlüsselmaterial). Stellen Sie alternativ vor dem Initiieren der Georeplikation sicher, dass die verwaltete Identität des sekundären Servers (vom Benutzer zugewiesen oder vom System zugewiesen) über erforderliche Berechtigungen für den Schlüsseltresor oder das verwaltete HSM des primären Servers verfügt, und das System versucht, den Schlüssel zum sekundären Server hinzuzufügen.

  • Fügen Sie für eine vorhandene Georeplikationseinrichtung vor dem Aktivieren der automatischen Schlüsselrotation auf dem primären Server den Verschlüsselungsschlüssel hinzu, der als TDE-Schutz auf dem primären Server verwendet wird. Der sekundäre Server benötigt Zugriff auf den Schlüssel im selben Schlüsseltresor oder in einem verwalteten HSM, das mit dem primären Server verwendet wird (und nicht auf einen anderen Schlüssel mit demselben Schlüsselmaterial). Stellen Sie alternativ vor dem Aktivieren des automatisierten Schlüssels sicher, dass die verwaltete Identität des sekundären Servers (vom Benutzer zugewiesen oder vom System zugewiesen) über erforderliche Berechtigungen für den Schlüsseltresor des primären Servers verfügt, und das System versucht, den Schlüssel zum sekundären Server hinzuzufügen.

  • Georeplikationsszenarios mit kundenseitig verwalteten Schlüsseln (Customer-Managed Keys, CMK) für TDE werden unterstützt. TDE mit automatischer Schlüsselrotation muss auf allen Servern konfiguriert werden, wenn Sie TDE im Azure-Portal konfigurieren. Weitere Informationen zum Einrichten der automatischen Schlüsselrotation für Georeplikationskonfigurationen mit TDE finden Sie unter Automatische Schlüsselrotation für Georeplikationskonfigurationen.

Nicht zugängliche TDE-Schutzvorrichtungen

Wenn TDE für die Verwendung eines kundenseitig verwalteten Schlüssels konfiguriert ist, ist dauerhafter Zugriff auf die TDE-Schutzvorrichtung erforderlich, damit die Datenbank online bleiben kann. Wenn der Server den Zugriff auf die vom Kunden verwaltete TDE-Schutzkomponente in Azure Key Vault oder azure Managed HSM verliert, beginnt eine Datenbank in bis zu 10 Minuten, alle Verbindungen mit der entsprechenden Fehlermeldung zu verweigern und den Status in "Nicht zugänglich" zu ändern. Die einzige zulässige Aktion für eine Datenbank im Zustand „Kein Zugriff“ ist das Löschen der Datenbank.

Nicht zugänglicher Zustand

Wenn auf die Datenbank aufgrund eines zeitweiligen Netzwerkausfalls (z. B. eines 5XX-Fehlers) nicht zugegriffen werden kann, ist keine Aktion erforderlich, da die Datenbanken automatisch wieder online sind. Um die Auswirkungen von Netzwerkfehlern oder Ausfällen beim Zugriff auf die TDE-Schutzkomponente in Azure Key Vault oder azure Managed HSM zu verringern, wird ein 24-Stunden-Puffer eingeführt, bevor der Dienst versucht, die Datenbank in einen nicht zugänglichen Zustand zu verschieben. Wenn ein Failover auftritt, bevor der nicht zugängliche Zustand erreicht wird, wird die Datenbank aufgrund des Verlusts des Verschlüsselungscaches nicht verfügbar.

Wenn der Server den Zugriff auf die vom Kunden verwaltete TDE-Schutzkomponente in Azure Key Vault oder azure Managed HSM aufgrund eines Azure Key Vault-Fehlers (z. B. einen 4XX-Fehler) verliert, wird die Datenbank nach 30 Minuten in einen nicht zugänglichen Zustand verschoben.

Wiederherstellen des Datenbankzugriffs nach einem Azure Key Vault- oder Azure Managed HSM-Fehler

Nachdem der Zugriff auf den Schlüssel wiederhergestellt wurde, erfordert das Wiedereinstellen der Datenbank zusätzliche Zeit und Schritte, die je nach Dauer der Nichtverfügbarkeit von Schlüsseln und der Größe der Daten in der Datenbank variieren können.

Wenn der Schlüsselzugriff innerhalb von 30 Minuten wiederhergestellt wird, wird die Datenbank im Laufe der nächsten Stunde automatisch repariert. Wenn der Schlüsselzugriff jedoch nach mehr als 30 Minuten wiederhergestellt wird, ist die automatische Wiederherstellung der Datenbank nicht möglich. In solchen Fällen umfasst das Wiederherstellen der Datenbank zusätzliche Verfahren über das Azure-Portal und kann je nach Größe der Datenbank zeitaufwändig sein.

Sobald die Datenbank wieder online ist, sind zuvor konfigurierte Einstellungen auf Serverebene, einschließlich Failovergruppenkonfigurationen, Tags und Einstellungen auf Datenbankebene, wie elastische Poolkonfigurationen, Lesemaßstab, automatische Pause, Point-in-Time-Wiederherstellungsverlauf, langfristige Aufbewahrungsrichtlinie und andere verloren gegangen. Daher wird empfohlen, dass Kunden ein Benachrichtigungssystem implementieren, um den Verlust des Zugriffs auf Verschlüsselungsschlüssel innerhalb von 30 Minuten zu erkennen. Nachdem das 30-Minütige Fenster abgelaufen ist, empfehlen wir, alle Einstellungen auf Server- und Datenbankebene für die wiederhergestellte Datenbank zu überprüfen.

Im Folgenden sehen Sie sich die zusätzlichen Schritte an, die im Portal erforderlich sind, um eine nicht zugängliche Datenbank wieder online zu schalten.

Screenshot einer nicht zugänglichen TDE BYOK-Datenbank.

Versehentliches Sperren des Zugriffs auf die TDE-Schutzvorrichtung

Es kann vorkommen, dass ein Benutzer mit ausreichenden Zugriffsrechten für den Schlüsseltresor oder verwaltetes HSM den Serverzugriff auf den Schlüssel versehentlich durch eine der folgende Aktionen deaktiviert:

  • Widerrufen der Berechtigungen get, wrapKey, unwrapKey des Schlüsseltresors oder des verwalteten HSM vom Server

  • Löschen des Schlüssels

  • Löschen des Schlüsseltresors oder des verwalteten HSM

  • Ändern der Firewallregeln des Schlüsseltresors oder des verwalteten HSM

  • Löschen der verwalteten Identität des Servers in Microsoft Entra ID

Erfahren Sie mehr über häufige Ursachen für Zugriffsprobleme bei Datenbanken.

Blockierte Konnektivität zwischen SQL Managed Instance und Azure Key Vault oder azure Managed HSM

Die Netzwerkverbindungsunterbrechung zwischen einer SQL Managed Instance und einem Schlüsseltresor oder verwalteten HSM tritt hauptsächlich auf, wenn die Schlüsseltresor- oder verwaltete HSM-Ressource zwar vorhanden ist, der Endpunkt jedoch von der verwalteten Instanz nicht erreicht werden kann. Alle Szenarien, in denen der Schlüsseltresor oder der verwaltete HSM-Endpunkt erreicht werden kann, aber die Verbindung verweigert wird, fehlende Berechtigungen usw. führen dazu, dass die Datenbanken ihren Status in "Nicht zugänglich" ändern.

Die häufigsten Ursachen für mangelnde Netzwerkkonnektivität mit Azure Key Vault oder azure Managed HSM sind:

  • Azure Key Vault oder Azure Managed HSM wird über einen privaten Endpunkt verfügbar gemacht, und die private IP-Adresse des Azure Key Vault- oder azure Managed HSM-Diensts ist in den ausgehenden Regeln der Netzwerksicherheitsgruppe (Network Security Group, NSG), die dem verwalteten Instanzsubnetz zugeordnet ist, nicht zulässig.

  • Schlechte DNS-Auflösung, z. B. wenn der FQDN des Schlüsseltresors oder des verwalteten HSM nicht aufgelöst oder in eine ungültige IP-Adresse aufgelöst wird.

Testen Sie die Konnektivität von SQL Managed Instance mit dem Azure Key Vault oder azure Managed HSM, das die TDE-Schutzkomponente hosten.

  • Der Endpunkt ist Ihr Tresor-FQDN, z. B. <vault_name>.vault.azure.net (ohne https://).
  • Der zu testende Port ist 443.
  • Das Ergebnis für RemoteAddress sollte existieren und die richtige IP-Adresse sein
  • Das Ergebnis für TCP-Test sollte tcpTestSucceededed: True sein.

Wenn der Test TcpTestSucceededed: False zurückgibt, überprüfen Sie die Netzwerkkonfiguration:

  • Überprüfen Sie die aufgelöste IP-Adresse, und bestätigen Sie, dass sie gültig ist. Ein fehlender Wert bedeutet, dass Probleme mit der DNS-Auflösung auftreten.

    • Vergewissern Sie sich, dass die Netzwerksicherheitsgruppe in der verwalteten Instanz über eine Ausgangsregel verfügt, die die aufgelöste IP-Adresse auf Port 443 abdeckt, insbesondere, wenn die aufgelöste Adresse zum privaten Endpunkt des Schlüsseltresors oder des verwalteten HSM gehört.

    • Überprüfen Sie andere Netzwerkkonfigurationen wie Routingtabelle, Vorhandensein des virtuellen Geräts und dessen Konfiguration usw.

"Überwachung der vom Kunden verwalteten TDE"

Konfigurieren Sie die folgenden Azure-Features, um den Datenbankzustand zu überwachen und Warnungen bei Verlust des Zugriffs auf die TDE-Schutzvorrichtung zu aktivieren:

  • Azure Resource Health: Eine nicht zugängliche Datenbank, die den Zugriff auf die TDE-Schutzkomponente verloren hat, wird als "Nicht verfügbar" angezeigt, nachdem die erste Verbindung mit der Datenbank verweigert wurde.

  • Aktivitätsprotokoll: Ist der Zugriff auf die TDE-Schutzvorrichtung im vom Kunden verwalteten Schlüsseltresor nicht möglich, werden dem Aktivitätsprotokoll entsprechende Einträge hinzugefügt. Durch die Erstellung von Warnungen für diese Ereignisse können Sie den Zugriff schnellstmöglich wiederherstellen.

  • Aktionsgruppen können definiert werden, um Ihnen Benachrichtigungen und Warnungen aufgrund Ihrer Präferenzen zu senden – beispielsweise per E-Mail/SMS/Pushbenachrichtigung/Sprachnachricht, per Logik-App, Webhook, ITSM oder Automation-Runbook.

Datenbank backup und restore mit kundenseitig verwalteter TDE

Sobald eine Datenbank mit TDE mit einem Schlüssel aus Azure Key Vault oder azure Managed HSM verschlüsselt wurde, werden alle neu generierten Sicherungen auch mit derselben TDE-Schutzkomponente verschlüsselt. Wenn die TDE-Schutzvorrichtung geändert wird, werden alte Sicherungen der Datenbank nicht aktualisiert, um die aktuelle TDE-Schutzvorrichtung zu verwenden.

Um eine mit einer TDE-Schutzkomponente verschlüsselte Sicherung aus Azure Key Vault oder azure Managed HSM wiederherzustellen, stellen Sie sicher, dass das Schlüsselmaterial auf dem Zielserver verfügbar ist. Daher wird empfohlen, alle älteren Versionen des TDE-Schutzes im Key Vault oder verwalteten HSM zu behalten, damit Datenbanksicherungen wiederhergestellt werden können.

Wichtig

Es kann zu jedem Zeitpunkt nicht mehr als eine TDE-Schutzkomponente für einen Server festgelegt werden. Der mit Legen Sie den ausgewählten Schlüssel als TDE-Standardschutzvorrichtung fest gekennzeichnete Schlüssel ist die TDE-Standardschutzkomponente im Azure-Portalbereich. Mehrere Schlüssel können jedoch mit einem Server verknüpft werden, ohne sie als TDE-Schutz zu kennzeichnen. Diese Schlüssel werden nicht zum Schutz der DEK verwendet, können aber während der Wiederherstellung aus einer Sicherung verwendet werden, wenn die Sicherungsdatei mit dem Schlüssel mit dem entsprechenden Fingerabdruck verschlüsselt ist.

Wenn der Schlüssel, der für die Wiederherstellung einer Sicherung benötigt wird, nicht mehr für den Zielserver verfügbar ist, wird beim Wiederherstellungsversuch die folgende Fehlermeldung zurückgegeben: „Target server <Servername> does not have access to all AKV URIs created between <Timestamp #1> and <Timestamp #2>. Wiederholen Sie den Vorgang, nachdem alle AKV-URIs wiederhergestellt wurden.“

Gehen Sie bei der Problembehandlung wie folgt vor: Führen Sie das Cmdlet Get-AzSqlServerKeyVaultKey für den Zielserver oder das Cmdlet Get-AzSqlInstanceKeyVaultKey für die verwaltete Zielinstanz aus, um die Liste der verfügbaren Schlüssel zurückzugeben und die fehlenden Schlüssel zu ermitteln. Um sicherzustellen, dass alle Sicherungen wiederhergestellt werden können, vergewissern Sie sich, dass der Zielserver für die Wiederherstellung auf alle erforderlichen Schlüssel zugreifen kann. Diese Schlüssel müssen nicht als TDE-Schutzvorrichtung gekennzeichnet sein.

Weitere Informationen zur Wiederherstellung der Sicherung für SQL-Datenbank finden Sie unter Wiederherstellen einer Datenbank aus einer Sicherung in der Azure SQL-Datenbank. Weitere Informationen zur Wiederherstellung für dedizierte SQL-Pools in Azure Synapse Analytics finden Sie unter Wiederherstellung eines dedizierten SQL-Pools. Informationen zur nativen Sicherung/Wiederherstellung von SQL Server mit SQL Managed Instance finden Sie in der Schnellstartanleitung: Wiederherstellen einer Datenbank in azure SQL Managed Instance with SSMS.

Weitere Hinweise zu Protokolldateien: Gesicherte Protokolldateien bleiben mit der ursprünglichen TDE-Schutzvorrichtung verschlüsselt, selbst wenn diese rotiert wurde und die Datenbank jetzt eine neue TDE-Schutzvorrichtung verwendet. Zur Wiederherstellungszeit werden beide Schlüssel benötigt, um die Datenbank wiederherzustellen. Wenn die Protokolldatei eine TDE-Schutzkomponente verwendet, die in Azure Key Vault oder azure Managed HSM gespeichert ist, wird dieser Schlüssel zur Wiederherstellungszeit benötigt, auch wenn die Datenbank in der Zwischenzeit geändert wurde, um dienstverwaltete TDE zu verwenden.

Hochverfügbarkeit bei der kundenseitig verwalteten TDE

Mit dem Azure Key Vault oder azure Managed HSM, das mehrere Redundanzebenen bereitstellt, können TDEs mit einem vom Kunden verwalteten Schlüssel die Verfügbarkeit und Ausfallsicherheit von Azure Key Vault oder azure Managed HSM nutzen und sich vollständig auf die Azure Key Vault- oder Azure Managed HSM-Redundanzlösung verlassen.

Azure Key Vault mehrere Redundanzebenen sorgen für den Schlüsselzugriff, auch wenn einzelne Dienstkomponenten fehlschlagen oder Azure-Regionen oder Verfügbarkeitszonen ausfallen. Weitere Informationen finden Sie unter Azure Key Vault: Verfügbarkeit und Redundanz.

Azure Key Vault bietet die folgenden Komponenten der Verfügbarkeit und Resilienz, die automatisch ohne Benutzereingriff bereitgestellt werden:

Hinweis

Für alle Paarregionen werden Azure Key Vault-Schlüssel in beide Regionen repliziert, und es gibt Hardwaresicherheitsmodule (HSM) in beiden Regionen, die mit diesen Schlüsseln arbeiten können. Weitere Informationen finden Sie unter Datenreplikation. Dies gilt für die Azure Key Vault-Dienstebenen „Standard“ und „Premium“ sowie für Software- oder Hardwareschlüssel.

Mit azure Managed HSM Multi-Region-Replikation können Sie einen Azure Managed HSM-Pool von einer Azure-Region (als primäre Region bezeichnet) auf eine andere Azure-Region (als erweiterte Region bezeichnet) erweitern. Nach der Konfiguration sind beide Regionen aktiv, können Anforderungen verarbeiten und bei automatisierter Replikation dasselbe Schlüsselmaterial, dieselben Rollen und Berechtigungen gemeinsam nutzen. Weitere Informationen finden Sie unter Aktivieren der Multi-Region-Replikation auf azure Managed HSM.

Georedundante Notfallwiederherstellung und kundenseitig verwaltete TDE

Sowohl in aktiven Szenarien für die Georeplikation als auch bei Failovergruppen können die beteiligten primären und sekundären Server mit dem Azure Key Vault oder azure Managed HSM in einer beliebigen Region verknüpft werden. Der Server und der Schlüsselbund oder das verwaltete HSM müssen nicht in derselben Region platziert werden. Aus Gründen der Einfachheit können die primären und sekundären Server mit demselben Schlüsseltresor oder verwaltetem HSM (in jeder Region) verbunden werden. Dadurch können Szenarien vermieden werden, in denen das Schlüsselmaterial möglicherweise nicht mehr synchronisiert ist, wenn separate Schlüsseltresore oder verwaltete HSMs für beide Server verwendet werden.

Azure Key Vault und Azure Managed HSM verfügen über mehrere Redundanzebenen, um sicherzustellen, dass die Schlüssel und Schlüsseltresor bei Dienst- oder Regionsfehlern verfügbar bleiben. Die Redundanz wird von den ungepaarten und gepaarten Regionen unterstützt. Weitere Informationen finden Sie unter Azure Key Vault: Verfügbarkeit und Redundanz.

Es gibt mehrere Optionen zum Speichern des TDE-Schutzschlüssels, basierend auf den Anforderungen der Kunden:

  • Verwenden Sie Azure Key Vault sowie die Resilienz der systemeigenen gekoppelten Region oder der nicht gekoppelten Region.

  • Verwenden Sie Kunden-HSMs und laden Sie Schlüssel in separaten Azure Key Vaults in mehreren Azure-Regionen.

  • Verwenden Sie Azure Managed HSM und die regionsübergreifende Replikationsoption.

    • Mit dieser Option kann der Kunde die gewünschte Region auswählen, in der die Schlüssel repliziert werden.

Das folgende Diagramm stellt eine Konfiguration für eine gekoppelte Region (primär und sekundär) für ein Azure Key Vault-Cross-Failover mit Azure SQL-Setup für die Georeplikation mithilfe einer Failovergruppe dar:

Diagramm, das die regionsübergreifende Failoverunterstützung von Azure Key Vault für eine gekoppelte Region zeigt.

Hinweise zu Azure Key Vault für Geo-DR

  • Sowohl primäre als auch sekundäre Server in Azure SQL greifen auf den Azure Key Vault in der primären Region zu.

  • Das Azure Key Vault-Failover wird vom Azure Key Vault-Dienst und nicht vom Kunden initiiert.

  • Wenn Azure Key Vault in der sekundären Region fehlschlägt, kann der Server in Azure SQL weiterhin auf denselben Azure Key Vault zugreifen. Intern wird die Azure Key Vault-Verbindung jedoch zur Azure Key Vault-Instanz in der sekundären Region umgeleitet.

  • Neue Schlüsselerstellungen, Importe und Schlüsselrotationen sind nur möglich, während der Azure Key Vault im primären Bereich verfügbar ist.

  • Nach dem Failover ist eine Schlüsselrotation erst wieder möglich, wenn die Azure Key Vault-Instanz in der primären Region der gekoppelten Region wieder verfügbar ist.

  • Der Kunde kann keine manuelle Verbindung mit der sekundären Region herstellen.

  • Azure Key Vault befindet sich im schreibgeschützten Modus, solange die Azure Key Vault-Instanz in der primären Region nicht verfügbar ist.

  • Der Kunde kann nicht auswählen oder überprüfen, in welcher Region sich der Azure Key Vault derzeit befindet.

  • Bei nicht gekoppelten Regionen greifen beide Azure SQL-Server auf die Azure Key Vault-Instanz in der ersten Region zu (wie im Diagramm dargestellt), und Azure Key Vault verwendet zonenredundanten Speicher, um die Daten innerhalb der Region über unabhängige Verfügbarkeitszonen derselben Region hinweg zu replizieren.

Weitere Informationen finden Sie unter Verfügbarkeit und Redundanz von Azure Key Vault, Azure-Regionspaare und nicht verairete Regionenund Vereinbarungen auf Serviceebene für Azure Key Vault.

Azure SQL-Hinweise für Geo-DR

  • Verwenden Sie die zonenredundante Option von Azure SQL Managed Instance und Azure SQL Database, um die Resilienz zu erhöhen. Weitere Informationen finden Sie unter Was sind Azure-Verfügbarkeitszonen?.

  • Verwenden Sie Failovergruppen für azure SQL Managed Instance und Azure SQL Database für die Notfallwiederherstellung in einer sekundären Region. Weitere Informationen finden Sie unter Übersicht über Failovergruppen & bewährte Methoden.

  • Wenn eine Datenbank Teil der aktiven Georeplikation oder Failovergruppen ist und nicht mehr zugegriffen werden kann, bricht die SQL-Kontrollebene die Verknüpfung auf und konvertiert die Datenbank in eine eigenständige Datenbank. Nach dem Beheben der Schlüsselberechtigungen kann die primäre Datenbank in der Regel wieder online gestellt werden. Die sekundäre Datenbank kann nicht online zurückgeführt werden, da Azure SQL keine vollständigen Sicherungen für sekundäre Datenbanken nach Dem Entwurf übernimmt. Die Empfehlung besteht darin, die sekundären Datenbanken abzulegen und den Link erneut einzurichten.

  • Die Konfiguration erfordert möglicherweise eine komplexere DNS-Zone, wenn private Endpunkte in Azure SQL verwendet werden (z. B. können nicht zwei private Endpunkte für dieselbe Ressource in derselben DNS-Zone erstellt werden).

  • Stellen Sie sicher, dass Anwendungen Wiederholungslogik verwenden.

Es gibt mehrere Szenarien, in denen Kunden die Azure Managed HSM-Lösung über Azure Key Vault auswählen möchten:

  • Es ist eine manuelle Verbindung zum sekundären Tresor erforderlich.

  • Auch bei einem Ausfall ist ein Lesezugriff auf den Tresor erforderlich.

  • Flexibilität beim Auswählen der Region, in der ihr Schlüsselmaterial repliziert wird

    • Erfordert die Aktivierung der regionsübergreifenden Replikation, wodurch der zweite azure Managed HSM-Pool in der zweiten Region erstellt wird.

  • Mithilfe von Azure Managed HSM können Kunden ein genaues Replikat für HSM erstellen, wenn das Original verloren geht oder nicht verfügbar ist.

  • Verwendung von Azure Managed HSM für Sicherheits- oder behördliche Anforderungen.

  • Die Möglichkeit, den gesamten Tresor zu sichern, anstatt nur einzelne Schlüssel zu sichern.

Weitere Informationen finden Sie unter Aktivieren der Multiregion-Replikation auf Azure Managed HSM und Managed HSM Notfallwiederherstellung.

Azure Policy für kundenseitig verwaltete TDEs

Azure Policy kann zum Erzwingen kundenseitig verwalteter TDEs während der Erstellung oder Aktualisierung eines Azure SQL-Datenbank-Servers oder von Azure SQL Managed Instance verwendet werden. Bei dieser Richtlinie schlagen alle Versuche zum Erstellen oder Aktualisieren eines logischen Servers in Azure oder verwalteter Instanz fehl, wenn sie nicht mit einem vom Kunden verwalteten Schlüssel konfiguriert ist. Azure Policy kann auf das gesamte Azure-Abonnement oder nur innerhalb einer Ressourcengruppe angewendet werden.

Weitere Informationen zur Azure-Richtlinie finden Sie unter Was ist Azure Policy und Azure-Richtliniendefinitionsstruktur.

Die folgenden zwei integrierten Richtlinien werden für kundenseitig verwaltete TDEs in Azure Policy unterstützt:

  • SQL Server-Instanzen müssen kundenseitig verwaltete Schlüssel zur Verschlüsselung ruhender Daten verwenden
  • Für SQL Managed Instance sollten kundenseitig verwaltete Schlüssel zur Verschlüsselung ruhender Daten verwendet werden.

Die kundenseitig verwaltete TDE-Richtlinie können Sie verwalten, indem Sie zum Azure-Portal wechseln und nach dem Dienst "Richtlinie" (Policy) suchen. Suchen Sie im Bereich Definitions (Definitionen) nach dem kundenseitig verwalteten Schlüssel.

Für diese Richtlinien gibt es drei Auswirkungen:

  • Überwachung – Die Standardeinstellung und erfasst nur einen Überwachungsbericht in den Azure-Richtlinienaktivitätsprotokollen.

  • Verweigern: Verhindert die Erstellung oder Aktualisierung eines logischen Servers oder einer verwalteten Instanz, wenn kein kundenseitig verwalteter Schlüssel konfiguriert ist

  • Deaktiviert – Deaktiviert die Richtlinie und schränkt Benutzer nicht daran ein, einen logischen Server oder eine verwaltete Instanz zu erstellen oder zu aktualisieren, ohne dass vom Kunden verwaltete TDE aktiviert ist.

Wenn die Azure-Richtlinie für vom Kunden verwaltete TDE auf "Verweigern" festgelegt ist, schlägt die Erstellung von logischen Azure SQL-Servern oder verwalteten Instanzen fehl. Die Details dieses Fehlers werden im Aktivitätsprotokoll der Ressourcengruppe aufgezeichnet.

Wichtig

Frühere Versionen integrierter Richtlinien für vom Kunden verwaltete TDE, die den AuditIfNotExists Effekt enthalten, sind veraltet. Vorhandene Richtlinienzuweisungen, die die veralteten Richtlinien verwenden, sind nicht betroffen und funktionieren weiterhin wie zuvor.

Zugehöriger Inhalt

  • Last updated on