Freigeben über

Datensicherheit in Azure Monitor Logs

  • Artikel

In diesem Artikel wird erläutert, wie Azure Monitor Protokolldaten sammelt, verarbeitet und schützt und Sicherheitsfunktionen beschreibt, mit denen Sie Ihre Azure Monitor-Umgebung weiter sichern können. Die Informationen in diesem Artikel gelten besonders für Azure Monitor-Protokolle und ergänzen die Informationen im Azure Trust Center.

Azure Monitor Logs verwaltet Ihre cloudbasierten Daten sicher mithilfe der Verwendung von:

  • Trennung von Daten
  • Beibehaltung von Daten
  • Physische Sicherheit
  • Incident Management
  • Compliance
  • Sicherheitsstandard-Zertifizierungen

Sollten Sie Fragen, Vorschläge oder Probleme im Zusammenhang mit den folgenden Informationen (einschließlich unserer Sicherheitsrichtlinien) haben, können Sie sich über die Azure-Supportoptionen mit uns in Verbindung setzen.

Sicheres Senden von Daten mit TLS

Um die Sicherheit von Daten bei der Übertragung an Azure Monitor sicherzustellen, wird dringend empfohlen, den Agent so zu konfigurieren, dass er mindestens TLS 1.2 (Transport Layer Security) verwendet. Bei älteren Versionen von TLS/Secure Sockets Layer (SSL) wurde ein Sicherheitsrisiko festgestellt. Sie funktionieren aus Gründen der Abwärtskompatibilität zwar noch, werden jedoch nicht empfohlen, und die Industrie ist bestrebt, diese älteren Protokolle schnell auszumustern.

Das PCI Security Standards Council hat den 30. Juni 2018 als Termin für die Deaktivierung älterer Versionen von TLS/SSL und das Upgrade auf sicherere Protokolle festgelegt. Sobald Azure keine Legacy-Unterstützung mehr anbietet und wenn Ihre Agents nicht mindestens über TLS 1.3 kommunizieren können, ist das Senden von Daten an Azure Monitor-Protokolle nicht möglich.

Es wird empfohlen, den Agent NICHT explizit so zu konfigurieren, dass nur TLS 1.3 verwendet wird, es sei denn, dies ist erforderlich. Dem Agent sollte stattdessen besser das automatische Erkennen, Aushandeln und Nutzen zukünftiger Sicherheitsstandards ermöglicht werden. Andernfalls könnten Sie die zusätzliche Sicherheit neuerer Standards verpassen und möglicherweise Probleme bekommen, wenn TLS 1.3 zugunsten dieser neueren Standards veraltet werden sollte.

Plattformspezifische Anleitungen

Plattform/Sprache Support Weitere Informationen
Linux Linux-Distributionen greifen zur Unterstützung von TLS 1.2 tendenziell auf OpenSSL zurück. Überprüfen Sie anhand des OpenSSL-Änderungsprotokolls, ob Ihre Version von OpenSSL unterstützt wird.
Windows 8.0 bis 10 Wird unterstützt und ist standardmäßig aktiviert. Zur Bestätigung, dass Sie weiterhin die Standardeinstellungen verwenden.
Windows Server 2012 bis 2016 Wird unterstützt und ist standardmäßig aktiviert. Zur Bestätigung, dass Sie weiterhin die Standardeinstellungen verwenden
Windows 7 SP1 und Windows Server 2008 R2 SP1 Wird unterstützt, ist jedoch standardmäßig deaktiviert. Details zur Aktivierung finden Sie auf der Seite Transport Layer Security (TLS) registry settings (Registrierungseinstellungen für Transport Layer Security (TLS)).

Trennung von Daten

Nachdem Ihre Daten von Azure Monitor erfasst wurden, werden sie für jede Komponente des Diensts logisch getrennt verwaltet. Sämtliche Daten werden nach Arbeitsbereich gekennzeichnet. Dieser Kennzeichnung wird während des gesamten Datenlebenszyklus beibehalten und auf jeder Ebene des Diensts erzwungen. Die Daten werden in einer dedizierten Datenbank im Speichercluster in der ausgewählten Region gespeichert.

Beibehaltung von Daten

Die Daten der indizierten Protokollsuche werden gemäß des von Ihnen gewählten Tarifs gespeichert und aufbewahrt. Weitere Informationen finden Sie unter Log Analytics-Preise.

Im Rahmen Ihres Abonnementvertrags bewahrt Microsoft Ihre Daten gemäß den Vertragsbedingungen auf. Wenn Kundendaten entfernt werden, werden keine physischen Laufwerke zerstört.

Die folgende Tabelle enthält einige der verfügbaren Lösungen sowie Beispiele für die Typen der jeweils gesammelten Daten.

Lösung Datentypen
Kapazität und Leistung Leistungsdaten und Metadaten
Updateverwaltung Metadaten und Statusdaten
Log Management Benutzerdefinierte Ereignisprotokolle, Windows-Ereignisprotokolle und/oder IIS-Protokolle
Change Tracking Metadaten für Softwarebestand, Windows-Dienste und Linux-Daemons sowie Windows/Linux-Dateimetadaten
SQL und Active Directory Assessment WMI-Daten, Registrierungsdaten, Leistungsdaten und Ergebnisse der dynamischen SQL Server-Verwaltungssichten

Die folgende Tabelle zeigt Beispiele für Datentypen:

Datentyp Fields
Warnung AlertName, AlertDescription, BaseManagedEntityId, ProblemId, IsMonitorAlert, RuleId, ResolutionState, Priority, Severity, Category, Owner, ResolvedBy, TimeRaised, TimeAdded, LastModified, LastModifiedBy, LastModifiedExceptRepeatCount, TimeResolved, TimeResolutionStateLastModified, TimeResolutionStateLastModifiedInDB, RepeatCount
Konfiguration CustomerID, AgentID, EntityID, ManagedTypeID, ManagedTypePropertyID, CurrentValue, ChangeDate
Ereignis EventId, EventOriginalID, BaseManagedEntityInternalId, RuleId, PublisherId, PublisherName, FullNumber, Number, Category, ChannelLevel, LoggingComputer, EventData, EventParameters, TimeGenerated, TimeAdded
Hinweis: Wenn Sie Ereignisse mit benutzerdefinierten Feldern in das Windows-Ereignisprotokoll schreiben, werden diese per Log Analytics gesammelt.
Metadaten BaseManagedEntityId, ObjectStatus, OrganizationalUnit, ActiveDirectoryObjectSid, PhysicalProcessors, NetworkName, IPAddress, ForestDNSName, NetbiosComputerName, VirtualMachineName, LastInventoryDate, HostServerNameIsVirtualMachine, NetbiosDomainName, LogicalProcessors, DNSName, DisplayName, DomainDnsName, ActiveDirectorySite, PrincipalName, OffsetInMinuteFromGreenwichTime
Leistung ObjectName, CounterName, PerfmonInstanceName, PerformanceDataId, PerformanceSourceInternalID, SampleValue, TimeSampled, TimeAdded
State StateChangeEventId, StateId, NewHealthState, OldHealthState, Context, TimeGenerated, TimeAdded, StateId2, BaseManagedEntityId, MonitorId, HealthState, LastModified, LastGreenAlertGenerated, DatabaseTimeModified

Physische Sicherheit

Azure Monitor wird von Microsoft-Mitarbeitern verwaltet. Alle Aktivitäten werden protokolliert und können überwacht werden. Azure Monitor wird als Azure-Dienst betrieben und erfüllt sämtliche Compliance- und Sicherheitsanforderungen in Azure. Ausführliche Informationen über die physische Sicherheit der Azure-Ressourcen finden Sie auf Seite 18 des Dokuments Microsoft Azure Security Overview (Microsoft Azure-Sicherheitsübersicht). Physische Zugriffsrechte auf sichere Bereiche werden innerhalb eines Geschäftstags für jeden Benutzer geändert, der keine Verantwortung mehr für den Azure Monitor-Dienst trägt, einschließlich der Übertragung und Beendigung. Informieren Sie sich über die globale physische Infrastruktur, die wir in Microsoft-Rechenzentren verwenden.

Incident Management

Azure Monitor verfügt über einen Incident-Management-Prozess, dem alle Microsoft-Dienste entsprechen. Zusammenfassung:

  • Wir verwenden ein Modell für gemeinsame Verantwortung, bei dem Microsoft einen Teil der Verantwortung für die Sicherheit trägt und der Kunde für den anderen Teil zuständig ist.
  • Wir verwalten Azure-Sicherheitsincidents:
    • Wir leiten bei Erkennung eines Vorfalls eine Untersuchung ein.
    • Wir bewerten die Auswirkung und den Schweregrad eines Vorfalls durch ein Teammitglied für Sicherheitsvorfälle auf Abruf. Je nach Situation kann diese Bewertung zu einer weiteren Eskalation an das Security Response-Team führen.
    • Es wird ein Vorfall diagnostiziert, dann führen Sicherheitsfachleute die technische oder forensische Untersuchung durch und identifizieren Strategien zum Eindämmen, zur Risikominderung und zur Umgehung. Wenn das Sicherheitsteam davon ausgeht, dass Kundendaten möglicherweise einer rechtswidrigen oder nicht autorisierten Person ausgesetzt worden sind, beginnt die parallele Ausführung des Kundenvorfall-Benachrichtigungsvorgangs.
    • Stabilisieren und Wiederherstellen nach dem Vorfall. Das Sicherheitsteam erstellt einen Wiederherstellungsplan, um das Problem zu beheben. Schritte zur Schadensbegrenzung, z.B. Isolieren betroffener Systeme, können sofort und parallel zur Diagnose erfolgen. Längerfristige Maßnahmen können geplant werden, die ergriffen werden, nachdem die unmittelbare Gefahr vorüber ist.
    • Schließen des Vorfalls und Durchführen einer Nachbereitung. Das Sicherheitsteam erstellt eine Nachbereitung mit einer Beschreibung der Details des Vorfalls und der Absicht, Richtlinien, Verfahren und Prozesse zu überarbeiten, um eine Wiederholung des Ereignisses zu verhindern.
  • Wir benachrichtigen Kunden über Sicherheitsincidents:
    • Festlegen des Umfangs der betroffenen Kunden und möglichst detaillierte Benachrichtigung aller Betroffenen
    • Erstellen einer Benachrichtigung mit genügend Informationen für Kunden, damit sie ihrerseits eine genauere Untersuchung durchführen und Versprechen halten können, die sie gegenüber ihren Endbenutzern gegeben haben, ohne den Benachrichtigungsvorgang unangemessen zu verzögern.
    • Bestätigung und Meldung des Vorfalls nach Bedarf.
    • Benachrichtigung von Kunden mit einer Vorfallmeldung ohne unangemessene Verzögerung und in Übereinstimmung mit allen gesetzlichen oder vertraglichen Verpflichtungen. Benachrichtigung mindestens eines Administrators des Kunden über Sicherheitsvorfälle mittels von Microsoft ausgewählter Kommunikationsmittel (einschließlich E-Mail).
  • Wir führen Team-Bereitschaft und Schulungen durch:
    • Microsoft-Mitarbeiter müssen eine Sicherheits- und Sensibilisierungs-Schulung absolvieren, um verdächtige Sicherheitsprobleme identifizieren und melden zu können.
    • Operatoren, die mit dem Microsoft Azure-Dienst arbeiten, haben zusätzliche Schulungspflichten hinsichtlich ihres Zugriffs auf vertrauliche Systeme mit Kundendaten.
    • Microsoft Security Response-Mitarbeiter erhalten spezielle Schulungen für ihre Rollen

Erhebliche Verluste von Kundendaten treten zwar selten auf, aber in einem solchen Fall benachrichtigt Microsoft jeden Kunden innerhalb eines Tages.

Weitere Informationen über die Reaktion von Microsoft auf Sicherheitsvorfälle finden Sie unter Microsoft Azure Security Response in the Cloud (Microsoft Azure Security Response in der Cloud).

Compliance

Das Informationssicherheits- und Governance-Programm des Softwareentwicklungs- und Serviceteams für Azure Monitor unterstützt die geschäftlichen Anforderungen und entspricht Gesetzen und Vorschriften, wie unter Microsoft Azure Trust Center und Microsoft Trust Center Compliance beschrieben. Außerdem wird beschrieben, wie Azure Monitor Logs Sicherheitsanforderungen einrichtet, Sicherheitskontrollen identifiziert und Risiken verwaltet und überwacht. Richtlinien, Standards, Verfahren und Leitlinien werden jährlich überprüft.

Jedes Mitglied des Entwicklungsteams erhält eine formale Anwendungssicherheitsschulung. Intern verwenden wir ein Versionskontrollsystem für die Softwareentwicklung. Jedes Softwareprojekt wird durch das Versionskontrollsystem geschützt.

Microsoft hat ein Sicherheits- und Compliance-Team, das alle Microsoft-Dienste überwacht und bewertet. Dieses Team besteht aus Informationssicherheitsbeauftragten, die nicht mit den Entwicklungsteams, die Log Analytics entwickeln, in Verbindung stehen. Die Sicherheitsbeauftragten verfügen über eine eigene Managementkette und führen unabhängige Beurteilungen von Produkten und Dienstleistungen durch, um Sicherheit und Compliance zu gewährleisten.

Der Microsoft-Vorstand wird in einem Jahresbericht über alle IT-Sicherheitsprogramme bei Microsoft informiert.

Das Softwareentwicklungs- und Serviceteam für Log Analytics arbeitet aktiv mit den Legal- und Compliance-Teams von Microsoft sowie mit anderen Branchenpartnern zusammen, um verschiedenste Zertifizierungen zu erlangen.

Zertifizierungen und Nachweise

Azure Log Analytics erfüllt folgende Anforderungen:

Hinweis

In einigen Zertifizierungen/Nachweisen ist Azure Monitor Logs unter dem ehemaligen Namen Operational Insights angegeben.

Datenfluss beim sicheren Cloud Computing

Das folgende Diagramm zeigt eine Cloud-Sicherheitsarchitektur sowie den Fluss von Informationen von Ihrem Unternehmen und deren Schutz auf dem Weg zu Azure Monitor, wo Sie sie letztlich im Azure-Portal anzeigen können. Weitere Informationen zu den einzelnen Schritten finden Sie nach dem Diagramm.

Abbildung der Datensammlung und Sicherheit in Azure Monitor Logs

1. Registrieren für Azure Monitor und Erfassen von Daten

Damit Ihre Organisation Daten an Azure Monitor Logs senden kann, konfigurieren Sie einen Windows- oder Linux-Agent, der auf virtuellen Azure-Computern oder auf virtuellen oder physischen Computern in Ihrer Umgebung oder einem anderen Cloudanbieter ausgeführt wird. Bei Verwendung von Operations Manager konfigurieren Sie den Operations Manager-Agent über die Verwaltungsgruppe. Benutzer (Sie, andere Einzelbenutzer oder eine Gruppe von Personen) erstellen Log Analytics-Arbeitsbereiche und registrieren Agents mithilfe eines der folgenden Konten:

In einem Log Analytics-Arbeitsbereich werden Daten gesammelt, aggregiert, analysiert und präsentiert. Ein Arbeitsbereich wird hauptsächlich zum Partitionieren von Daten verwendet, wobei jeder Arbeitsbereich eindeutig ist. Beispielsweise empfiehlt es sich, Produktionsdaten mit einem Arbeitsbereich zu verwalten und Testdaten mit einem anderen Arbeitsbereich. Arbeitsbereiche helfen Administratoren außerdem dabei, den Benutzerzugriff auf Daten zu steuern. Jedem Arbeitsbereich können mehrere Benutzerkonten zugeordnet werden, und jedes Benutzerkonto kann auf mehrere Log Analytics-Arbeitsbereiche zugreifen. Sie erstellen Arbeitsbereiche auf Grundlage der Rechenzentrumsregion.

Für Operations Manager wird über die Operation Manager-Verwaltungsgruppe eine Verbindung mit dem Azure Monitor-Dienst hergestellt. Dann legen Sie fest, welche mit einem Agent verwalteten Systeme in der Verwaltungsgruppe Daten erfassen und an den Dienst senden können. Je nach aktivierter Lösung werden Daten aus diesen Lösungen entweder direkt von einem Operations Manager-Verwaltungsserver oder aufgrund des Umfangs der Daten, die im mit einem Agent verwalteten System gesammelt werden, direkt vom Agent an den Azure Monitor-Dienst gesendet. In Systemen, die nicht über Operations Manager überwacht werden, wird jeweils direkt eine sichere Verbindung mit dem Azure Monitor-Dienst hergestellt.

Die gesamte Kommunikation zwischen verbundenen Systemen und dem Azure Monitor-Dienst ist verschlüsselt. Das TLS (HTTPS)-Protokoll wird für die Verschlüsselung verwendet. Das Microsoft SDL-Verfahren stellt sicher, dass Log Analytics nach den neuesten Fortschritten bei kryptografischen Protokollen aktualisiert wird.

Jeder Agent-Typ sammelt Protokolldaten für Azure Monitor. Der Typ der gesammelten Daten hängt von der Konfiguration Ihres Arbeitsbereichs und anderen Azure Monitor-Funktionen ab.

2. Senden von Daten von Agents

Sie registrieren alle Agent-Typen mit einem Registrierungsschlüssel. Eine sichere Verbindung zwischen dem Agent und Azure Monitor-Dienst wird mithilfe der zertifikatbasierten Authentifizierung und TLS an Port 443 hergestellt. Azure Monitor verwendet einen geheimen Speicher zum Generieren und Verwalten von Schlüsseln. Private Schlüssel werden alle 90 Tage rotiert und in Azure gespeichert. Sie werden von Azure-Operatoren verwaltet, die Gesetze und Compliance-Vorschriften strikt einhalten.

In Operations Manager wird über die mit einem Log Analytics-Arbeitsbereich registrierte Verwaltungsgruppe eine sichere HTTPS-Verbindung mit einem Operations Manager-Verwaltungsserver hergestellt.

Für Windows- oder Linux-Agents, die auf virtuellen Computern in Azure ausgeführt werden, wird ein schreibgeschützter Speicherschlüssel verwendet, um Diagnoseereignisse in Azure-Tabellen zu lesen.

Wenn jeder Agent Daten an eine Operations Manager-Verwaltungsgruppe meldet, die in Azure Monitor integriert ist, und der Verwaltungsserver aus einem bestimmten Grund nicht mit dem Dienst kommunizieren kann, werden die gesammelten Daten lokal in einem temporären Cache auf dem Verwaltungsserver gespeichert. Es wird dann zwei Stunden lang alle acht Minuten versucht, die Daten erneut zu senden. Bei Daten, bei denen der Verwaltungsserver umgangen wird und die direkt an Azure Monitor gesendet werden, entspricht das Verhalten dem des Windows-Agents.

Zwischengespeicherte Daten des Windows-Agents oder des Agents des Verwaltungsservers sind durch den Anmeldeinformationsspeicher des Betriebssystems geschützt. Wenn der Dienst die Daten innerhalb von zwei Stunden nicht verarbeiten kann, platzieren die Agents die Daten in einer Warteschlange. Wenn die Warteschlange voll ist, beginnt der Agent, Datentypen zu löschen, beginnend mit Leistungsdaten. Die Begrenzung für die Agent-Warteschlange ist ein Registrierungsschlüssel, den Sie bei Bedarf ändern können. Die gesammelten Daten werden komprimiert und unter Umgehung der Datenbanken der Operations Manager-Verwaltungsgruppe an den Dienst gesendet, sodass keine weitere Last hinzugefügt wird. Nach dem Senden werden die gesammelten Daten aus dem Cache entfernt.

Wie oben beschrieben, werden die Daten von dem Verwaltungsserver oder den direkt verbundenen Agents über TLS an Microsoft Azure-Rechenzentren gesendet. Optional können Sie ExpressRoute verwenden, um zusätzliche Sicherheit für die Daten bereitzustellen. ExpressRoute ist eine Möglichkeit, direkt aus Ihrem vorhandenen WAN mit Azure zu verbinden, z.B. ein Multi-Protocol Label Switching-VPN (MPLS), das von einem Netzwerkdienstanbieter bereitgestellt wird. Weitere Informationen finden Sie unter ExpressRoute und Wird für meinen Agent-Datenverkehr meine Azure ExpressRoute-Verbindung verwendet?.

3. Empfangen und Verarbeiten von Daten durch den Azure Monitor-Dienst

Der Azure Monitor-Dienst stellt sicher, dass eingehende Daten aus einer vertrauenswürdigen Quelle stammen, indem Zertifikate und die Integrität der Daten mittels Azure-Authentifizierung überprüft werden. Die nicht verarbeiteten Rohdaten werden dann in einer Azure Event Hubs-Instanz in der Region gespeichert, in der die Daten schließlich im Ruhezustand gespeichert werden. Die Art der gespeicherten Daten ist abhängig von der Art der importierten und zum Sammeln von Daten verwendeten Lösungen. Der Azure Monitor-Dienst verarbeitet dann die Rohdaten und erfasst sie in der Datenbank.

Die Beibehaltungsdauer der gesammelten Daten, die in der Datenbank gespeichert sind, hängt von dem ausgewählten Tarif ab. Beim Free-Tarif sind die gesammelten Daten 7 Tage verfügbar. Beim kostenpflichtigen Tarif sind die gesammelten Daten standardmäßig 31 Tage verfügbar, aber dieser Zeitraum kann auf 730 Tage verlängert werden. Daten werden im Ruhezustand verschlüsselt in Azure Storage gespeichert, um die Vertraulichkeit der Daten sicherzustellen, und die Daten werden innerhalb der lokalen Region mithilfe von lokal redundantem Speicher (LRS) repliziert oder mithilfe von zonenredundantem Speicher (ZRS) in unterstützen Regionen. Die letzten zwei Wochen von Daten werden ebenfalls im SSD-basierten Cache gespeichert, und dieser Cache ist verschlüsselt.

Daten im Datenbankspeicher können nach der Erfassung nicht mehr geändert werden, aber mithilfe der Purge-API endgültig gelöscht werden. Obwohl Daten nicht verändert werden können, verlangen einige Zertifizierungen, dass Daten unveränderlich aufbewahrt werden und im Speicher nicht geändert oder gelöscht werden können. Die Unveränderlichkeit von Daten kann durch Datenexport in ein Speicherkonto erreicht werden, das als unveränderlicher Speicher konfiguriert ist.

4. Verwenden von Azure Monitor für den Datenzugriff

Für den Zugriff auf Ihren Log Analytics-Arbeitsbereich melden Sie sich mit dem zuvor eingerichteten Organisationskonto oder Microsoft-Konto beim Azure-Portal an. Der gesamte Datenverkehr zwischen dem Portal und dem Azure Monitor-Dienst erfolgt über einen sicheren HTTPS-Kanal. Bei Verwendung des Portals wird eine Sitzungs-ID auf dem Client des Benutzers (Webbrowser) generiert, und die Daten werden in einem lokalen Cache gespeichert, bis die Sitzung beendet wird. Wenn die Sitzung beendet ist, wird der Cache gelöscht. Clientseitige Cookies enthalten keine persönlich identifizierbaren Informationen und werden nicht automatisch entfernt. Sitzungscookies sind „HTTPOnly“ markiert und gesichert. Nach einer vorher festgelegten Zeit im Leerlauf wird die Sitzung im Azure-Portal beendet.

Kundenseitig verwaltete Schlüssel (Sicherheitsschlüssel)

Daten in Azure Monitor werden mit von Microsoft verwalteten Schlüsseln verschlüsselt. Sie können vom Kunden verwaltete 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 Ihre 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.

Privater Speicher

Azure Monitor-Protokolle verwenden Azure Storage für bestimmten Szenarien. Verwenden Sie privaten/vom Kunden verwalteten Speicher, um Ihr persönlich verschlüsseltes Speicherkonto zu verwalten.

Mit Azure Private Link-Netzwerk können Sie Azure-PaaS-Dienste (Platform-as-a-Service) einschließlich Azure Monitor über private Endpunkte sicher mit Ihrem virtuellen Netzwerk verknüpfen.

Kunden-Lockbox für Microsoft Azure

Kunden-Lockbox für Microsoft Azure bietet Ihnen eine Schnittstelle, über die Sie Anfragen zum Zugriff auf Kundendaten überprüfen und genehmigen oder ablehnen können. Das Feature wird verwendet, wenn eine Microsoft-Technikerin bzw. ein Techniker beispielsweise im Rahmen eines kundeninitiierten Supporttickets oder aufgrund eines von Microsoft identifizierten Problems auf Kundendaten zugreifen muss. Um Kunden-Lockbox zu aktivieren, benötigen Sie einen dedizierten Cluster.

Manipulationsprüfung und Unveränderlichkeit

Azure Monitor ist eine Append-only-Datenplattform (es kann nur angefügt werden), die allerdings Bestimmungen zum Löschen von Daten für Compliancezwecke enthält. Sie können eine Sperre für Ihren Log Analytics-Arbeitsbereich festlegen, um alle Aktivitäten zu blockieren, die Daten löschen könnten: Bereinigen, Löschen von Tabellen und Änderungen der Datenaufbewahrung auf Arbeitsbereichsebene. Diese Sperre kann allerdings dennoch entfernt werden.

Um Ihre Überwachungslösung vollständig manipulationssicher zu machen, empfehlen wir, Ihre Daten in eine unveränderliche Speicherlösung zu exportieren.

Häufig gestellte Fragen

Dieser Abschnitt enthält Antworten auf häufig gestellte Fragen.

Wird für meinen Agent-Datenverkehr meine Azure ExpressRoute-Verbindung verwendet?

Für den Datenverkehr an Azure Monitor wird die ExpressRoute-Verbindung für Microsoft-Peering verwendet. Eine Beschreibung der verschiedenen Typen von ExpressRoute-Datenverkehr finden Sie in der ExpressRoute-Dokumentation.