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 oder verschiedene Optionen zum genauen Verwalten der Verschlüsselung und Verschlüsselungsschlüssel nutzen.

Mit Azure Monitor wird sichergestellt, dass alle Daten und gespeicherten Abfragen im Ruhezustand mit von Microsoft verwalteten Schlüsseln (MMK) verschlüsselt werden. Die Verwendung der Verschlüsselung durch Azure Monitor entspricht der Funktionsweise der Azure Storage-Verschlüsselung.

Sie können Daten mit Ihrem eigenen Schlüssel mithilfe von Azure Key Vaultverschlüsseln, um den Schlüssellebenszyklus zu verwalten und den Zugriff auf Ihre Daten zu widerrufen.

Kundenseitig verwaltete Schlüssel sind in dedizierten Clustern verfügbar und bieten Ihnen ein höheres Maß an Schutz und Kontrolle. Daten werden zweimal im Speicher verschlüsselt: einmal auf der Dienstebene mit von Microsoft verwalteten Schlüsseln oder kundenseitig verwalteten Schlüsseln und einmal auf der Infrastrukturebene mit zwei verschiedenen Verschlüsselungsalgorithmen und zwei verschiedenen Schlüsseln. Mehrfachverschlüsselung schützt vor dem Szenario, dass einer der Verschlüsselungsalgorithmen oder Schlüssel kompromittiert wurde. Mit dedizierten Clustern können Sie auch Daten mit Lockbox schützen.

Daten, die in den letzten 14 Tagen erfasst oder 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.

Wichtig

Dedizierte Cluster verwenden ein Preismodell mit Mindestabnahme von mindestens 100 GB pro 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 fungiert eine Log Analytics-Clusterressource als temporäre Identitätsverbindung zwischen Key Vault und Log Analytics-Arbeitsbereichen. Der Clusterspeicher verwendet die dem Cluster 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 systemseitig zugewiesene verwaltete Identität ist einfacher und wird automatisch mit Cluster generiert, wenn identity type auf SystemAssigned festgelegt ist. Diese Identität wird später genutzt, um Zugriff auf Ihre Key Vault-Instanz für Datenverschlüsselung und -entschlüsselung zu gewähren.
  • Mit der benutzerseitig zugewiesenen verwalteten Identität können Sie kundenseitig verwaltete Schlüssel bei der Clustererstellung konfigurieren, wenn identity type auf UserAssigned festgelegt ist und Sie ihm vor der Clustererstellung Berechtigungen in Key Vault erteilen.

Sie können kundenseitig verwaltete Schlüssel für einen neuen Cluster oder vorhandenen Cluster konfigurieren, der mit Arbeitsbereichen verknüpft ist und bereits 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 Microsoft-Schlüsseln verschlüsselt. Die Konfiguration kundenseitig verwalteter Schlüssel hat keine Auswirkungen auf Ihre Abfragen. Diese werden weiterhin nahtlos für alte und neue Daten ausgeführt. Sie können die Verknüpfung mit Arbeitsbereichen eines Cluster jederzeit aufheben. Neue Daten, die Sie nach dem Aufheben der Verknüpfung erfassen, werden mit Microsoft-Schlüsseln verschlüsselt, und Abfragen werden nahtlos für alte und neue Daten 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 derselben Region befinden, können jedoch in unterschiedlichen Abonnements enthalten sein.

Screenshot der Übersicht über vom Kunden verwalteten Schlüssel.

  1. Schlüsseltresor
  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 die Key Vault-Instanz, und im Fall eines verwalteten „HSM“ verlässt er 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 der Einstellungen für vorläufiges Löschen und Löschen des Schutzes.

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 identity type auf SystemAssigned oder UserAssigned fest, um den Zugriff auf Ihre Key Vault-Instanz für Datenverschlüsselungs- und -entschlüsselungsvorgänge zuzulassen.

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

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

Hinweis

Der Identitätstyp kann geändert werden, nachdem der Cluster ohne Unterbrechung der Aufnahme oder Abfragen mit den folgenden Überlegungen erstellt wurde.

  • Aktualisieren von SystemAssigned auf UserAssigned: Gewähren Sie die „UserAssign”-Identität im Key Vault, und aktualisieren Sie dann identity type im Cluster.
  • Aktualisieren von UserAssigned auf SystemAssigned: Da die systemseitig zugewiesene verwaltete Identität nach dem Aktualisieren des Clusters identity type mit SystemAssigned erstellt wurde, müssen diese Schritte befolgt werden:
    1. Aktualisieren des Clusters und Entfernen des Schlüssels: Legen Sie keyVaultUri, keyName und keyVersion mit dem Wert "" fest.
    2. Aktualisieren Sie das Cluster identity type auf SystemAssigned.
    3. Aktualisieren Sie Key Vault und Erteilen Sie Berechtigungen für die Identität.
    4. Aktualisieren Sie den Schlüssel im Cluster.

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 benötigen Sie eine Rolle mit Berechtigungen vom Typ Microsoft.Authorization/roleAssignments/write und Microsoft.Authorization/roleAssignments/delete (beispielsweise als Benutzerzugriffsadministrator oder Besitzer).

    1. Öffnen Sie Ihre Key Vault-Instanz im Azure-Portal, und wählen Sie Einstellungen>Zugriffskonfiguration>Rollenbasierte Zugriffssteuerung in Azure und Anwenden aus.
    2. Klicken Sie auf die Schaltfläche Zur Zugriffssteuerung (IAM) wechseln, und fügen Sie die Rollenzuweisung Kryptografiedienstverschlüsselung für Schlüsseltresore hinzu.
    3. Wählen Sie Verwaltete Identität auf der Registerkarte „Mitglieder” aus, und wählen Sie das Abonnement für Identität und die Identität als Mitglied aus.

    Screenshot von RBAC-Berechtigungen für den Grant Key Vault erteilen.

  2. Zuweisen einer Vault-Zugriffsrichtlinie (Legacy)

    Öffnen Sie Ihre Key Vault-Instanz im Azure-Portal, und wählen Sie Zugriffsrichtlinien>Tresorzugriffsrichtlinie>+ Zugriffsrichtlinie hinzufügen aus, um eine Richtlinie mit diesen Einstellungen 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 der Berechtigungen für die Zugriffsrichtlinie Key Vault gewähren.

    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 oder nach einer expliziten Schlüsselversion erfolgen. 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 der Erteilung von Schlüsseltresorberechtigungen.

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 identity type 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 (oder früher) berücksichtigt, und der Speicher steht dann nicht mehr zur Verfügung. Neue Daten, die in verknüpften Arbeitsbereichen erfasst 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 die Eigenschaften "keyVaultProperties" im Cluster, und ü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 die "keyVaultProperties"-Eigenschaften und die Schlüsselversion in der Eigenschaft "keyVersion". Die Schlüsselrotation erfordert eine explizite Aktualisierung der Eigenschaft "keyVersion" im Cluster. Weitere Informationen finden Sie unter Aktualisieren des Clusters mit Schlüsselbezeichnerdetails. Wenn Sie in Key Vault eine neue Schlüsselversion generieren, den Schlüssel 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 während und 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 der Arbeitsmappe speichern.

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.
  • Gespeicherte 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.

  • Lockbox gilt nicht für Tabellen mit dem Hilfsplan.

  • 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.
    • Einstellungen für die Mehrfachverschlüsselung können 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 Microsoft-Schlüsseln 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 identity type 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.

  • Der Hilfstabellenplan unterstützt keine kundenseitig verwalteten Schlüssel. Daten in Tabellen mit dem Hilfsplan werden mit von Microsoft verwalteten Schlüsseln verschlüsselt, auch wenn Sie die Daten im restlichen Log Analytics-Arbeitsbereich mit Ihrem eigenen Verschlüsselungsschlüssel schützen.

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 Clusterspeicher 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.

  • Das Verknüpfen eines Arbeitsbereichs mit einem Cluster schlägt fehl, wenn der Arbeitsbereich mit einem anderen Cluster verknüpft ist.

  • Wenn Sie einen Cluster erstellen und „KeyVaultProperties“ sofort angeben, schlägt der Vorgang möglicherweise fehl, bis dem Cluster eine Identität zugewiesen und Zugriff auf 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