Kundenseitig verwaltete Schlüssel in Azure Monitor

  • Artikel

Daten in Azure Monitor werden mit von Microsoft verwalteten Schlüsseln verschlüsselt. Sie können Ihren eigenen Verschlüsselungsschlüssel verwenden, um die Daten und gespeicherten Abfragen in Ihren Arbeitsbereichen zu schützen. Kundenseitig verwaltete Schlüssel in Azure Monitor bieten Ihnen mehr Flexibilität beim Verwalten von Zugriffssteuerungen für Protokolle. Nach der Konfiguration werden neue Daten für verknüpfte Arbeitsbereiche mit Ihrem Schlüssel verschlüsselt, der imAzure Key Vaultoder Azure Key Vault Managed „HSM“ gespeichert ist.

Überprüfen Sie Einschränkungen und Einschränkungen vor der Konfiguration.

Übersicht über kundenseitig verwaltete Schlüssel

Die Verschlüsselung ruhender Daten ist eine übliche Datenschutz- und Sicherheitsanforderung in Organisationen. Sie können die Verschlüsselung ruhender Daten vollständig von Azure verwalten lassen, wobei Ihnen verschiedene Optionen zum genauen Verwalten der Verschlüsselung und Verschlüsselungsschlüssel bereitstehen.

Mit Azure Monitor wird sichergestellt, dass alle Daten und gespeicherten Abfragen im Ruhezustand mit von Microsoft verwalteten Schlüsseln (MMK) verschlüsselt werden. Sie können Daten mithilfe Ihres eigenen Schlüssels im Azure Key Vaultverschlüsseln, um die Kontrolle über den Schlüssellebenszyklus zu erhalten und den Zugriff auf Ihre Daten zu widerrufen. Die Verwendung der Verschlüsselung durch Azure Monitor entspricht der Funktionsweise der Azure Storage-Verschlüsselung.

Kundenseitig verwaltete Schlüssel werden auf dedizierten Clustern bereitgestellt, die mehr Schutz und Kontrolle bieten. In dedizierten Clustern erfasste Daten werden zweimal im Speicher verschlüsselt: einmal auf der Dienstebene mit von Microsoft verwalteten Schlüsseln oder kundenseitig verwaltetem Schlüssel und einmal auf der Infrastrukturebene mit zwei verschiedenen Verschlüsselungsalgorithmen und zwei verschiedenen Schlüsseln. Doppelte Verschlüsselung: schützt vor dem Szenario, dass einer der Verschlüsselungsalgorithmen oder Schlüssel kompromittiert wurde. Mit dediziertem Cluster können Sie auch Daten mit Lockboxschützen.

Daten, die in den letzten 14 Tagen erfasst wurden, oder die kürzlich in Abfragen verwendet wurden, werden für effizientes Abfragen im Cache für heiße Daten (SSD-gestützt) aufbewahrt. Unabhängig von der Konfiguration kundenseitig verwalteter Schlüssel sind SSD-Daten mit Microsoft-Schlüsseln verschlüsselt, aber Ihre Kontrolle über SSD-Zugriff entspricht der Schlüsselsperrung.

Das Preismodell für dedizierte Log Analytics-Cluster erfordert eine Mindestabnahme beginnend bei 100 GB/Tag.

Funktionsweise von kundenseitig verwalteten Schlüsseln in Azure Monitor

Azure Monitor verwendet eine verwaltete Identität, um Zugriff auf Ihre Azure Key Vault-Instanz zu gewähren. Die Identität des Log Analytics-Clusters wird auf Clusterebene unterstützt. Zur Unterstützung von kundenseitig verwalteten Schlüsseln in mehreren Arbeitsbereichen wird eine Log Analytics-Clusterressource als temporäre Identitätsverbindung zwischen Key Vault und Log Analytics-Arbeitsbereichen eingesetzt. Der Clusterspeicher verwendet die der Clusterressource zugeordnete verwaltete Identität für die Authentifizierung bei Azure Key Vault über Microsoft Entra ID.

Cluster unterstützen zwei Typen verwalteter Identitäten: systemseitige Zuweisung und benutzerseitige Zuweisung. Hierbei kann je nach Szenario eine einzelne Identität in einem Cluster definiert werden.

  • Die Verwendung einer systemseitig zugewiesenen verwalteten Identität ist einfacher. Sie wird bei der Erstellung des Clusters automatisch generiert, wenn type für die Identität auf SystemAssigned festgelegt ist. Diese Identität kann später genutzt werden, um Zugriff auf Ihre Key Vault-Instanz zu gewähren, damit Vorgänge zum Umschließen bzw. Aufheben der Umschließung durchgeführt werden können.
  • Mit der benutzerseitig zugewiesenen verwalteten Identität können Sie den kundenseitig verwalteten Schlüssel bei der Clustererstellung konfigurieren, wenn Sie ihm vor der Clustererstellung Berechtigungen in Ihrem Key Vault erteilen.

Sie können die vom Kunden verwaltete Schlüsselkonfiguration auf einen neuen Cluster oder vorhandenen Cluster anwenden, der mit Arbeitsbereichen verknüpft ist und Daten erfasst. Neue Daten, die in verknüpften Arbeitsbereichen erfasst werden, werden mit Ihrem Schlüssel verschlüsselt, und ältere Daten, die vor der Konfiguration erfasst wurden, bleiben mit dem Microsoft-Schlüssel verschlüsselt. Ihre Abfragen werden nicht von der Konfiguration mit kundenseitig verwalteten Schlüsseln beeinflusst und die Abfrage wird nahtlos für alte und neue Daten ausgeführt. Sie können die Verknüpfung von Arbeitsbereichen mit dem Cluster jederzeit aufheben. Neue Daten, die aufgenommen wurden, nachdem die Verknüpfung mit Dem Microsoft-Schlüssel verschlüsselt wurde, und Abfragen werden über alte und neue Daten nahtlos ausgeführt.

Wichtig

Die Funktion für kundenseitig verwaltete Schlüssel ist regional. Azure Key Vault, Cluster und verknüpfte Arbeitsbereiche müssen sich in der gleichen Region befinden, können jedoch in unterschiedlichen Abonnements enthalten sein.

Screenshot of customer-managed key overview.

  1. Key Vault
  2. Log Analytics-Clusterressource mit verwalteter Identität und Berechtigungen für Key Vault. Die Identität wird an den zugrunde liegenden dedizierten Clusterspeicher weitergegeben.
  3. Dedizierter Cluster
  4. Arbeitsbereiche, die mit einem dedizierten Cluster verknüpft sind

Vorgang für Verschlüsselungsschlüssel

An der Speicherdatenverschlüsselung sind drei Arten von Schlüsseln beteiligt:

  • „KEK“ (Key Encryption Key): Schlüsselverschlüsselungsschlüssel (Ihr kundenseitig verwalteter Schlüssel)
  • „AEK“ (Account Encryption Key): Kontoverschlüsselungsschlüssel
  • „DEK“ (Data Encryption Key): Datenverschlüsselungsschlüssel

Es gelten die folgenden Regeln:

  • Der Cluster-Speicher hat einen eindeutigen Verschlüsselungsschlüssel für jedes Speicherkonto, der als AEK bezeichnet wird.
  • Der „AEK“ dient zum Ableiten von „DEKs“, bei denen es sich um die Schlüssel handelt, die zum Verschlüsseln der einzelnen, auf den Datenträger geschriebenen Datenblöcke verwendet werden.
  • Wenn Sie einen Schlüssel in Ihrem Key Vault konfigurieren und die Schlüsseldetails im Cluster aktualisiert haben, führt der Clusterspeicher Anforderungen an „wrap“ und „unwrap“ „AEK“ zur Verschlüsselung und Entschlüsselung aus.
  • Der „KEK“ verlässt niemals den Key Vault, und im Fall eines verwalteten „HSM“ verlässt dieser niemals die Hardware.
  • Azure Storage verwendet eine verwaltete Identität, die der Cluster Ressource für die Authentifizierung zugeordnet ist. Der Zugriff auf Azure Key Vault erfolgt über Microsoft Entra ID.

Bereitstellungsschritte für kundenseitig verwaltete Schlüssel

  1. Erstellen von Azure Key Vault und Speichern des Schlüssels
  2. Erstellen eines Clusters
  3. Gewähren von Berechtigungen für Key Vault
  4. Aktualisieren des Clusters mit Schlüsselbezeichnerdetails
  5. Verknüpfen von Arbeitsbereichen

Im Azure-Portal wird die Konfiguration kundenseitig verwalteter Schlüssel derzeit nicht unterstützt. Die Bereitstellung kann über PowerShell-, CLI- oder REST-Anforderungen vorgenommen werden.

Speichern des Verschlüsselungsschlüssels (KEK)

Ein Portfolio von Azure Key Management-Produkten listet die Tresore und verwalteten HSMs auf, die verwendet werden können.

Erstellen oder verwenden Sie einen vorhandenen Azure Key Vault in der Region, in der der Cluster geplant ist. Generieren oder importieren Sie in Ihrem Key Vault einen Schlüssel, der für die Protokollverschlüsselung verwendet werden soll. Azure Key Vault muss als wiederherstellbar konfiguriert werden, um Ihren Schlüssel und den Zugriff auf Ihre Daten in Azure Monitor zu schützen. Sie können diese Konfiguration unter den Eigenschaften in Ihrer Key Vault-Instanz überprüfen. Sowohl Vorläufiges Löschen als auch Bereinigungsschutz sollten aktiviert sein.

Screenshot of soft delete and purge protection settings.

Diese Einstellungen können in Key Vault über die CLI und PowerShell aktualisiert werden:

Cluster erstellen

Cluster verwenden verwaltete Identitäten für die Datenverschlüsselung mit Ihrer Key Vault-Instanz. Legen Sie beim Erstellen Ihres Clusters die Eigenschaft type der Identität auf SystemAssigned fest, um den Zugriff auf Ihre Key Vault-Instanz für Pack- und Entpackvorgänge zuzulassen.

Identitätseinstellungen im Cluster für systemseitig zugewiesene verwaltete Identität

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Folgen Sie dem im Artikel zu dedizierten Clustern beschriebenen Verfahren.

Erteilen von Key Vault-Berechtigungen

Es gibt zwei Berechtigungsmodelle in Key Vault, um den Zugriff auf Ihren Cluster und Underlay-Speicher zu gewähren: die rollenbasierte Azure-Zugriffskontrolle (Azure RBAC) und Vault-Zugriffsrichtlinien (Legacy).

  1. Zuweisen von Rollen mit Azure RBAC, die Sie steuern (empfohlen)

    Zum Hinzufügen von Rollenzuweisungen müssen Sie über die Berechtigungen „Microsoft.Authorization/roleAssignments/write“ und „Microsoft.Authorization/roleAssignments/delete“ wie Benutzerzugriffsadministrator oder Besitzer verfügen.

    Öffnen Sie Ihre Key Vault-Instanz im Azure-Portal, klicken Sie auf Zugriffskonfiguration in den Einstellungen, und wählen Sie die Option Rollenbasierte Zugriffssteuerung in Azure aus. Geben Sie dann Zugriffssteuerung (IAM) ein, und fügen Sie die Rollenzuweisung Kryptografiedienstverschlüsselung für Schlüsseltresore hinzu.

    Screenshot of Grant Key Vault RBAC permissions.

  2. Zuweisen einer Vault-Zugriffsrichtlinie (Legacy)

    Öffnen Sie Ihre Key Vault-Instanz im Azure-Portal, und klicken Sie auf Zugriffsrichtlinien. Wählen Sie dann Tresorzugriffsrichtlinie aus, und klicken Sie auf + Zugriffsrichtlinie hinzufügen, um mit diesen Einstellungen eine Richtlinie zu erstellen.

    • Key permissions (Schlüsselberechtigungen): Wählen Sie Abrufen, Wrap Key (Schlüssel packen) und Unwrap Key (Schlüssel entpacken) aus.
    • Auswählen des Prinzipals: abhängig vom im Cluster verwendeten Identitätstyp (vom System oder Benutzer zugewiesene verwaltete Identität)
      • Vom System zugewiesene verwaltete Identität: Geben Sie den Clusternamen oder die Clusterprinzipal-ID ein.
      • Vom Benutzer zugewiesene verwaltete Identität: Geben Sie den Identitätsnamen ein.

    Screenshot of Grant Key Vault access policy permissions.

    Die Berechtigung Abrufen ist erforderlich, damit sichergestellt werden kann, dass Key Vault als wiederherstellbar konfiguriert ist, um Ihren Schlüssel und den Zugriff auf Ihre Azure Monitor-Daten zu schützen.

Aktualisieren des Clusters mit Schlüsselbezeichnerdetails

Für alle Vorgänge im Cluster ist die Aktionsberechtigung Microsoft.OperationalInsights/clusters/write erforderlich. Diese Berechtigung kann über den Besitzer oder einen Mitwirkenden erteilt werden, der die Aktion */write enthält, oder über die Rolle „Analytics-Mitwirkender“, die die Aktion Microsoft.OperationalInsights/* enthält.

In diesem Schritt wird der dedizierte Clusterspeicher mit dem Schlüssel und der Version aktualisiert, die zum Packen und Entpacken von „AEK“ verwendet werden.

Wichtig

  • Die Schlüsselrotation kann automatisch erfolgen oder eine explizite Aktualisierung des Schlüssels erfordern. Unter Schlüsselrotation finden Sie Informationen zur Bestimmung des geeigneten Ansatzes, bevor Sie die Schlüsselbezeichnerdetails im Cluster aktualisieren.
  • Das Clusterupdate sollte nicht sowohl Identitäts- als auch Schlüsselbezeichnerdetails in demselben Vorgang enthalten. Wenn Sie beides aktualisieren müssen, sollte das Update in zwei aufeinanderfolgenden Vorgängen erfolgen.

Screenshot of Grant Key Vault permissions.

Aktualisieren Sie KeyVaultProperties im Cluster mit den Schlüsselbezeichnerdetails.

Der Vorgang ist asynchron und kann einige Zeit in Anspruch nehmen.

N/V

Wichtig

Dieser Schritt sollte nur nach Bereitstellung des Clusters ausgeführt werden. Wenn Sie vor der Bereitstellung Arbeitsbereiche verknüpfen und Daten erfassen, werden die erfassten Daten gelöscht und können nicht wiederhergestellt werden.

Sie brauchen Schreibberechtigungen für Ihren Arbeitsbereich und den Cluster, um diesen Vorgang auszuführen. Dazu gehören Microsoft.OperationalInsights/workspaces/write und Microsoft.OperationalInsights/clusters/write.

Folgen Sie dem im Artikel zu dedizierten Clustern beschriebenen Verfahren.

Schlüsselsperrung

Wichtig

  • Die empfohlene Vorgehensweise zum Widerrufen des Zugriffs auf Ihre Daten besteht darin, Ihren Schlüssel zu deaktivieren oder die Zugriffsrichtlinie auf Ihrer Key Vault-Instanz zu löschen.
  • Wenn Sie identitytype für den Cluster auf None festlegen, wird auch der Zugriff auf Ihre Daten widerrufen. Dieser Ansatz wird jedoch nicht empfohlen, da Sie ihn nicht ohne Kontaktaufnahme mit dem Support rückgängig machen können.

Im Clusterspeicher werden Änderungen der Schlüsselberechtigungen immer innerhalb einer Stunde berücksichtigt, und der Speicher steht dann nicht mehr zur Verfügung. Neue Daten, die in verknüpften Arbeitsbereichen aufgenommen werden, werden gelöscht und können nicht wiederhergestellt werden. In diesen Arbeitsbereichen kann nicht auf Daten zugegriffen werden und Abfragen können nicht verwendet werden. Zuvor erfasste Daten verbleiben im Speicher, solange der Cluster und Ihre Arbeitsbereiche nicht gelöscht werden. Daten, auf die nicht zugegriffen werden kann, unterliegen der Datenaufbewahrungsrichtlinie und werden bereinigt, sobald der Aufbewahrungszeitraum abgelaufen ist. Daten, die in den letzten 14 Tagen erfasst wurden, und Daten, die kürzlich in Abfragen verwendet wurden, werden für effizientes Abfragen auch im Cache für heiße Daten (SSD-gestützt) aufbewahrt. Die Daten auf SSD werden beim Schlüsselsperrungsvorgang gelöscht, und es kann dann nicht mehr darauf zugegriffen werden. Die Clusterspeicherversuche erreichen Ihre Key Vault, um die Verschlüsselung in regelmäßigen Abständen zu entpacken. Wenn der Schlüssel aktiviert ist, ist das Entpacken erfolgreich, SSD-Daten werden erneut aus dem Speicher geladen und die Datenerfassung und -abfrage werden innerhalb von 30 Minuten fortgesetzt.

Schlüsselrotation

Für die Schlüsselrotation stehen zwei Modi zur Verfügung:

  • Automatische Rotation: Aktualisieren Sie Ihren Cluster mit "keyVaultProperties", aber überspringen Sie die Eigenschaft "keyVersion", oder legen Sie sie auf "" fest. Der Speicher verwendet automatisch die neueste Schlüsselversion.
  • Explizites Update der Schlüsselversion: Aktualisieren Sie Ihren Cluster mit der Schlüsselversion in der Eigenschaft "keyVersion". Die Rotation von Schlüsseln erfordert eine explizite Aktualisierung von "keyVaultProperties" im Cluster. Weitere Informationen finden Sie unter Aktualisieren des Clusters mit Schlüsselbezeichnerdetails. Wenn Sie in Key Vault eine neue Schlüsselversion generieren, sie aber im Cluster nicht aktualisieren, wird vom Clusterspeicher weiterhin Ihr vorheriger Schlüssel verwendet. Wenn Sie den alten Schlüssel deaktivieren oder löschen, bevor Sie den neuen Schlüssel im Cluster aktualisieren, wird der Status der Schlüsselsperrung aktiv.

Auf alle Ihre Daten kann nach dem Schlüsselrotationsvorgang weiterhin zugegriffen werden. Daten werden immer mit dem Kontoverschlüsselungsschlüssel (Account Encryption Key, AEK) verschlüsselt, der mit Ihrer neuen Schlüsselverschlüsselungsschlüssel-Version (Key Encryption Key, KEK) in Key Vault verschlüsselt ist.

Kundenseitig verwalteter Schlüssel für gespeicherte Abfragen und Protokollsuchwarnungen

Die in Log Analytics verwendete Abfragesprache ist ausdrucksstark und kann vertrauliche Informationen in Kommentaren in der Abfragesyntax enthalten. Einige Organisationen verlangen, dass diese Informationen als Teil der Richtlinie für kundenseitig verwaltete Schlüssel geschützt werden, und Sie müssen Ihre Abfragen mit Ihrem Schlüssel verschlüsselt speichern. Azure Monitor ermöglicht Ihnen das mit Ihrem Schlüssel verschlüsselte Speichern von gespeicherten Abfragen und Protokollsuchwarnungen in Ihrem eigenen Speicherkonto, sofern Sie mit Ihrem Arbeitsbereich verbunden sind.

Kundenseitig verwalteter Schlüssel für Arbeitsmappen

Mit den Überlegungen zum kundenseitig verwalteten Schlüssel für gespeicherte Abfragen und Protokollsuchwarnungen können Sie mit Azure Monitor Arbeitsmappenabfragen, die mit Ihrem Schlüssel verschlüsselt sind, in Ihrem eigenen Speicherkonto speichern, wenn Sie im Vorgang „Speichern“ der Arbeitsmappe Inhalte in einem Azure Storage-Konto speichern auswählen.

Screenshot of Workbook save.

Hinweis

Abfragen bleiben in den folgenden Szenarios mit von Microsoft verwalteten Schlüsseln (Microsoft Managed Key, MMK) unabhängig von der Konfiguration kundenseitig verwalteter Schlüssel verschlüsselt: Azure-Dashboards, Azure-Logik-App, Azure Notebooks und Azure Automation-Runbooks.

Wenn Sie Ihr Speicherkonto für gespeicherte Abfragen verknüpfen, speichert der Dienst gespeicherte Abfragen und Abfragen zu Protokollsuchwarnungen in Ihrem Speicherkonto. Mit der Kontrolle über die Richtlinie zur Verschlüsselung ruhender Daten in Ihrem Speicherkonto können Sie gespeicherte Abfragen und Protokollsuchwarnungen mit einem kundenseitig verwalteten Schlüssel schützen. Sie sind jedoch auch für die mit diesem Speicherkonto verbundenen Kosten verantwortlich.

Überlegungen vor dem Festlegen des kundenseitig verwalteten Schlüssels für Abfragen

  • Sie müssen für Ihren Arbeitsbereich und das Speicherkonto über die Berechtigung „Schreiben“ verfügen.
  • Stellen Sie sicher, dass Sie Ihr Speicherkonto in derselben Region wie Ihren Log Analytics-Arbeitsbereich mit der vom Kunden verwalteten Schlüsselverschlüsselung erstellen. Dies ist wichtig, da gespeicherte Abfragen im Tabellenspeicher gespeichert werden und nur bei der Erstellung des Speicherkontos verschlüsselt werden können.
  • Im Abfragepaket gespeicherte Abfragen werden nicht mit dem vom Kunden verwalteten Schlüssel verschlüsselt. Wählen beim Speichern von Abfragen stattdessen Als Legacy speichern aus, um sie mit dem vom Kunden verwalteten Schlüssel zu schützen.
  • Die gespeicherten Abfragen im Speicher werden als Dienstartefakte angesehen und ihr Format kann sich ändern.
  • Beim Verknüpfen eines Speicherkontos für Abfragen wurden vorhandene gespeicherte Abfragen aus Ihrem Arbeitsbereich entfernt. Kopieren Sie vor diesem Konfigurationsschritt die gespeicherten Abfragen, die Sie benötigen. Sie können Ihre gespeicherten Abfragen mithilfe von PowerShell anzeigen.
  • Die Abfragen für den Verlauf und das Anheften an das Dashboard werden nicht unterstützt, wenn das Speicherkonto für Abfragen verknüpft wird.
  • Sie können ein einzelnes Speicherkonto mit einem Arbeitsbereich verknüpfen, der für gespeicherte Abfragen und Abfragen zu Protokollsuchwarnungen verwendet werden kann.
  • Protokollsuchwarnungen werden im Blob-Speicher gespeichert, und die Verschlüsselung des kundenseitig verwalteten Schlüssels kann bei der Erstellung des Speicherkontos oder später konfiguriert werden.
  • Ausgelöste Protokollsuchwarnungen enthalten keine Suchergebnisse oder Warnungsabfragen. Sie können Warnungsdimensionen verwenden, um Kontext in den ausgelösten Warnungen zu erhalten.

Konfigurieren von BYOS für gespeicherte Abfragen

Verknüpfen Sie ein Speicherkonto für Abfragen, um gespeicherte Abfragen in Ihrem Storage-Konto zu behalten.

–

Nach der Konfiguration werden alle neuen Abfragen gespeicherter Suchvorgänge in Ihrem Speicher gespeichert.

Konfigurieren von BYOS für Abfragen zu Protokollsuchwarnungen

Verknüpfen Sie ein Speicherkonto für Warnungen, um Abfragen zu Protokollsuchwarnungen in Ihrem Speicherkonto zu behalten.

–

Nach der Konfiguration werden alle neuen Warnungsabfragen in Ihrem Speicher gespeichert.

Kunden-Lockbox

Lockbox bietet Ihnen die Möglichkeit, die Anforderung eines Microsoft-Technikers für den Zugriff auf Ihre Daten während einer Supportanfrage zu genehmigen oder abzulehnen.

Lockbox wird im dedizierten Cluster in Azure Monitor bereitgestellt, wo Ihre Berechtigung für den Zugriff auf Daten auf Abonnementebene gewährt wird.

Weitere Informationen finden Sie unter Kunden-Lockbox für Microsoft Azure.

Vorgänge für kundenseitig verwaltete Schlüssel

Der kundenseitig verwaltete Schlüssel wird im dedizierten Cluster bereitgestellt. Die folgenden Vorgänge werden im Artikel über dedizierte Cluster behandelt:

  • Abrufen aller Cluster in einer Ressourcengruppe
  • Abrufen aller Cluster in einem Abonnement
  • Aktualisieren der Kapazitätsreservierung in einem Cluster
  • Aktualisieren von billingType im Cluster
  • Aufheben der Verknüpfung eines Arbeitsbereichs mit einem Cluster
  • Löschen von Clustern

Einschränkungen

  • In jeder Region und jedem Abonnement können maximal fünf aktive Cluster erstellt werden.

  • In jeder Region und jedem Abonnement können maximal sieben reservierte Cluster vorhanden sein (aktiv oder kürzlich gelöscht).

  • Maximal 1.000 Log Analytics-Arbeitsbereiche können mit einem Cluster verknüpft werden.

  • Maximal zwei Vorgänge zur Verknüpfung von Arbeitsbereichen sind innerhalb von 30 Tagen für einen bestimmten Arbeitsbereich zulässig.

  • Das Verschieben eines Clusters in eine andere Ressourcengruppe oder ein anderes Abonnement wird derzeit nicht unterstützt.

  • Das Clusterupdate sollte nicht sowohl Identitäts- als auch Schlüsselbezeichnerdetails in demselben Vorgang enthalten. Wenn Sie beides aktualisieren müssen, sollte das Update in zwei aufeinanderfolgenden Vorgängen erfolgen.

  • Lockbox ist in China derzeit nicht verfügbar.

  • Doppelte Verschlüsselung wird automatisch für Cluster konfiguriert, die ab Oktober 2020 in unterstützten Regionen erstellt werden. Sie können überprüfen, ob Ihr Cluster für doppelte Verschlüsselung konfiguriert ist. Dazu senden Sie eine GET-Anforderung für den Cluster und beobachten, ob der isDoubleEncryptionEnabled-Wert für Cluster mit aktivierter doppelter Verschlüsselung true ist.

    • Wenn Sie einen Cluster erstellen und die Fehlermeldung „Die doppelte Verschlüsselung für Cluster wird von Regionsname nicht unterstützt.“ erhalten, können Sie den Cluster trotzdem ohne doppelte Verschlüsselung erstellen, indem Sie "properties": {"isDoubleEncryptionEnabled": false} im REST-Anforderungstext hinzufügen.
    • Die Einstellung für die Mehrfachverschlüsselung kann nach dem Erstellen des Clusters nicht mehr geändert werden.

Das Löschen eines verknüpften Arbeitsbereichs ist zulässig, während er mit einem Cluster verknüpft ist. Wenn Sie sich entschließen, den Arbeitsbereich während des Zeitraums des vorläufigen Löschenswiederherzustellen, wird er in den vorherigen Zustand zurückversetzt und bleibt mit dem Cluster verknüpft.

  • Die Verschlüsselung mit kundenseitig verwaltetem Schlüssel gilt für Daten, die nach dem Konfigurationszeitpunkt neu erfasst werden. Daten, die vor der Konfiguration erfasst wurden, bleiben mit dem Microsoft-Schlüssel verschlüsselt. Sie können vor und nach der Konfiguration des kundenseitig verwalteten Schlüssels erfasste Daten nahtlos abfragen.

  • Azure Key Vault muss als wiederherstellbar konfiguriert werden. Die folgenden Eigenschaften sind standardmäßig nicht aktiviert und sollten mithilfe der CLI oder PowerShell konfiguriert werden:

    • Vorläufiges Löschen.
    • Der Bereinigungsschutz sollte aktiviert werden, wenn Sie sich auch nach dem vorläufigen Löschen vor dem erzwungenen Löschen des Geheimnis/Schlüsseltresors schützen möchten.

  • Ihre Azure Key Vault-Instanz, Cluster und Arbeitsbereiche müssen sich in derselben Region und im selben Microsoft Entra-Mandanten befinden. Sie können jedoch in unterschiedlichen Abonnements enthalten sein.

  • Wenn Sie identitytype für den Cluster auf None festlegen, wird auch der Zugriff auf Ihre Daten widerrufen. Dieser Ansatz wird jedoch nicht empfohlen, da Sie ihn nicht ohne Kontaktaufnahme mit dem Support rückgängig machen können. Die empfohlene Methode zum Widerrufen des Zugriffs auf Ihre Daten ist die Schlüsselsperrung.

  • Sie können einen kundenseitig verwalteten Schlüssel mit benutzerseitig zugewiesener verwalteter Identität nicht verwenden, wenn sich Ihre Key Vault-Instanz in einer Private Link-Instanz (VNet) befindet. Für dieses Szenario können Sie die systemseitig zugewiesene verwaltete Identität verwenden.

  • Suchaufträge asynchrone Abfragen werden derzeit nicht im Szenario „Kundenseitig verwalteter Schlüssel“ unterstützt.

Problembehandlung

  • Verhalten bei Key Vault-Verfügbarkeit:

    • Normalbetrieb: Der AEK wird für kurze Zeiträume von Storage zwischengespeichert und in regelmäßigen Abständen zum Entpacken in Key Vault zurückgeführt.

    • Key Vault-Verbindungsfehler: Speicher handhabt vorübergehende Fehler (Timeouts, Verbindungsfehler, DNS-Probleme), indem Schlüssel für die Dauer des Verfügbarkeitsproblems im Cache verbleiben können. Dadurch werden Probleme aufgrund von Ausfällen sowie Verfügbarkeitsprobleme behoben. Die Abfrage- und Erfassungsfunktionen werden ohne Unterbrechung fortgesetzt.

  • Key Vault-Zugriffsrate: Die Häufigkeit, mit der der Azure Cluster-Speicher für Pack- und Entpackvorgänge auf Key Vault zugreift, liegt zwischen 6 und 60 Sekunden.

  • Wenn Sie Ihren Cluster aktualisieren, während er bereitgestellt oder bereits aktualisiert wird, tritt bei der Aktualisierung ein Fehler auf.

  • Wenn ein Konflikt auftritt – Fehler beim Erstellen eines Clusters, wurde möglicherweise ein Cluster mit demselben Namen in den letzten 14 Tagen gelöscht und reserviert. Der gelöschte Clustername ist 14 Tage nach dem Löschen verfügbar.

  • Die Arbeitsbereichverknüpfung mit dem Cluster schlägt fehl, wenn er mit einem anderen Cluster verknüpft ist.

  • Wenn Sie einen Cluster erstellen und die KeyVaultProperties sofort angeben, schlägt der Vorgang möglicherweise fehl, bis die Identität im Cluster zugewiesen und im Key Vault gewährt wird.

  • Wenn Sie einen vorhandenen Cluster mit „KeyVaultProperties“ aktualisieren und die Zugriffsrichtlinie für den Schlüsselabruf in Key Vault nicht vorhanden ist, schlägt der Vorgang fehl.

  • Wenn Sie den Cluster nicht bereitstellen, vergewissern Sie sich, dass sich Azure Key Vault, Cluster und verknüpfte Arbeitsbereiche in der gleichen Region befinden. Sie können in unterschiedlichen Abonnements enthalten sein.

  • Wenn Sie die Schlüsselversion in Key Vault aktualisieren und die neuen Schlüsselbezeichnerdetails im Cluster nicht aktualisieren, verwendet der Cluster weiterhin den vorherigen Schlüssel, und auf die Daten kann nicht mehr zugegriffen werden. Aktualisieren Sie neue Schlüsselbezeichnerdetails im Cluster, um die Datenaufnahme und -abfrage fortzusetzen. Sie können die Schlüsselversion mit "'' aktualisieren, damit der Speicher immer automatisch die neueste Schlüsselversion verwendet.

  • Einige Vorgänge dauern lange und können einige Zeit in Anspruch nehmen. Dies sind Erstellen des Clusters, Aktualisieren des Clusterschlüssels und Löschen des Clusters. Sie können den Vorgangsstatus überprüfen, indem Sie eine GET-Anforderung an den Cluster oder Arbeitsbereich senden und die Antwort beobachten. Beispielsweise weist der nicht verknüpfte Arbeitsbereich unter features nicht die clusterResourceId auf.

  • Fehlermeldungen

    Clusterupdate

    • 400 – Der Cluster befindet sich im Zustand „wird gelöscht“. Asynchroner Vorgang wird ausgeführt. Der Cluster muss seinen Vorgang beenden, bevor ein Aktualisierungsvorgang ausgeführt wird.
    • 400 – „KeyVaultProperties“ ist nicht leer, hat aber ein ungültiges Format. Lesen Sie Key Identifier Update (Aktualisierung des Schlüsselbezeichners).
    • 400 – Fehler beim Überprüfen des Schlüssels in Key Vault. Mögliche Ursachen: Fehlende Berechtigungen, oder der Schlüssel ist nicht vorhanden. Vergewissern Sie sich, dass Sie die Schlüssel- und Zugriffsrichtlinie in Key Vault festgelegt haben.
    • 400 – Der Schlüssel kann nicht wiederhergestellt werden. Key Vault muss auf „Vorläufiges Löschen und Löschschutz“ festgelegt werden. Lesen Sie die Dokumentation zu Key Vault.
    • 400 – Der Vorgang kann jetzt nicht ausgeführt werden. Warten Sie, bis der asynchrone Vorgang beendet wurde, und versuchen Sie es erneut.
    • 400 – Der Cluster befindet sich im Zustand „wird gelöscht“. Warten Sie, bis der asynchrone Vorgang beendet wurde, und versuchen Sie es erneut.

    Clusterabruf

    • 404 – Der Cluster wurde nicht gefunden; möglicherweise wurde er gelöscht. Wenn Sie versuchen, einen Cluster mit diesem Namen zu erstellen, und es zu einem Konflikt kommt, befindet sich der Cluster im Löschprozess.

Nächste Schritte