Bewährte Methoden für die Überwachung von Azure Blob Storage
Dieser Artikel enthält eine Sammlung allgemeiner Speicherüberwachungsszenarien sowie Richtlinien für bewährte Methoden zu deren Umsetzung.
Identifizieren von Speicherkonten mit keiner oder geringer Nutzung
Storage-Erkenntnisse ist ein Dashboard, das zusätzlich zu den Metriken und Protokollen von Azure Storage verwendet werden kann. Mit Storage-Erkenntnissen können Sie das Transaktionsvolumen und die verwendete Kapazität aller Ihrer Konten untersuchen. Anhand dieser Informationen können Sie entscheiden, welche Konten Sie eventuell einstellen. Informationen zur Konfiguration von Storage-Erkenntnissen finden Sie unter Überwachen Ihres Speicherdiensts mit Azure Monitor Storage-Erkenntnissen.
Analysieren des Transaktionsvolumens
Sortieren Sie Ihre Konten in der Ansicht „Storage-Erkenntnisse“ in Azure Monitor in der Spalte Transaktionen in aufsteigender Reihenfolge. In der folgenden Abbildung ist ein Konto mit geringem Transaktionsvolumen im angegebenen Zeitraum dargestellt.
Klicken Sie auf den Kontolink, um mehr über diese Transaktionen zu erfahren. In diesem Beispiel werden die meisten Anforderungen an den Blob Storage-Dienst gesendet.
Um festzustellen, welche Anforderungen ausgeführt werden, können Sie das Diagramm Transactions by API name (Transaktionen nach API-Name) genauer analysieren.
In diesem Beispiel sind alle Anforderungen Auflistungsvorgänge oder Anforderungen von Informationen zu Kontoeigenschaften. Lese- und Schreibvorgänge sind nicht enthalten. Dies kann Sie zu der Annahme verleiten, dass das Konto nicht in nennenswerter Weise verwendet wird.
Analysieren der verwendeten Kapazität
Sortieren Sie Ihre Konten auf der Registerkarte Kapazität der Ansicht „Storage-Erkenntnisse“ in Azure Monitor in der Spalte Verwendete Kontokapazität in aufsteigender Reihenfolge. In der folgenden Abbildung ist ein Konto mit einem geringeren Kapazitätsvolumen als bei anderen Konten dargestellt.
Die Blobs, die dieser verwendeten Kapazität zugeordnet sind, können Sie mit Storage-Explorer untersuchen. Bei einer großen Anzahl von Blobs können Sie mithilfe einer Blobbestandsrichtlinie einen Bericht generieren.
Überwachen der Verwendung eines Containers
Wenn Sie die Daten Ihrer Kunden nach Container partitionieren, können Sie überwachen, welche Kapazität die einzelnen Kunden verwenden. Mithilfe des Azure Storage-Blobbestands können Sie eine Inventur der Blobs mit Größeninformationen durchführen. Anschließend können Sie die Größe und Anzahl auf Containerebene aggregieren. Ein Beispiel finden Sie unter Berechnen der Anzahl und Gesamtgröße von Blobs pro Container mit dem Azure Storage-Bestand.
Außerdem können Sie den Datenverkehr auf Containerebene durch Abfragen von Protokollen auswerten. Informationen zum Erstellen von Log Analytics-Abfragen finden Sie unter Log Analytics. Informationen zum Storage-Protokollschema finden Sie unter Überwachen von Daten in Azure Blob Storage – Referenz.
Mit der folgenden Abfrage wird die Anzahl der Lesetransaktionen und die Anzahl der in jedem Container gelesenen Bytes abgerufen.
StorageBlobLogs
| where OperationName == "GetBlob"
| extend ContainerName = split(parse_url(Uri).Path, "/")[1]
| summarize ReadSize = sum(ResponseBodySize), ReadCount = count() by tostring(ContainerName)
Mit der folgenden ähnlichen Abfrage werden Informationen zu Schreibvorgängen abgerufen.
StorageBlobLogs
| where OperationName == "PutBlob" or
OperationName == "PutBlock" or
OperationName == "PutBlockList" or
OperationName == "AppendBlock" or
OperationName == "SnapshotBlob" or
OperationName == "CopyBlob" or
OperationName == "SetBlobTier"
| extend ContainerName = split(parse_url(Uri).Path, "/")[1]
| summarize WriteSize = sum(RequestBodySize), WriteCount = count() by tostring(ContainerName)
Diese Abfrage referenziert die Namen mehrerer Vorgänge, da mehrere Vorgangstypen als Schreibvorgänge zählen können. Weitere Informationen dazu, welche Vorgänge als Lese- und Schreibvorgänge gelten, finden Sie unter Azure Blob Storage – Preise oder Azure Data Lake Storage – Preise.
Überwachen der Kontoaktivität
In vielen Fällen müssen Sie die Aktivitäten in Ihren Speicherkonten auf Sicherheit und Konformität überwachen. Die Vorgänge in Speicherkonten lassen sich in zwei Kategorien unterteilen: Vorgänge auf Steuerungsebene und Vorgänge auf Datenebene.
Ein Vorgang auf Steuerungsebene ist jede Azure Resource Manager-Anforderung zum Erstellen eines Speicherkontos oder zum Aktualisieren einer Eigenschaft eines vorhandenen Speicherkontos. Weitere Informationen finden Sie unter Azure Resource Manager.
Bei einem Vorgang auf Datenebene handelt es sich um einen Vorgang für die Daten in einem Speicherkonto, der sich aus einer Anforderung an den Speicherdienstendpunkt ergibt. Beispielsweise wird ein Vorgang auf Datenebene durchgeführt, wenn Sie ein Blob in ein Speicherkonto hochladen oder aus einem Speicherkonto herunterladen. Weitere Informationen finden Sie unter Azure Storage-API.
In diesem Abschnitt erfahren Sie, wie Sie die Informationen zum „Wann“, „Wer“, „Was“ und „Wie“ für Vorgänge auf Steuerungs- und Datenebene ermitteln.
Überwachen von Vorgängen auf Steuerungsebene
Resource Manager-Vorgänge werden im Azure-Aktivitätsprotokoll erfasst. Öffnen Sie zum Anzeigen des Aktivitätsprotokolls Ihr Speicherkonto im Azure-Portal, und klicken Sie anschließend auf Aktivitätsprotokoll.
Öffnen Sie einen beliebigen Protokolleintrag, um den JSON-Code anzuzeigen, mit dem die Aktivität beschrieben wird. Mit dem folgenden JSON-Code werden die Informationen zum „Wann“, „Was“ und „Wie“ für einen Vorgang auf Steuerungsebene angegeben:
Die Verfügbarkeit der Informationen zum „Wer“ hängt von der Authentifizierungsmethode ab, die zum Ausführen des Vorgangs auf Steuerungsebene verwendet wurde. Wurde die Autorisierung von einem Microsoft Entra-Sicherheitsprinzipal durchgeführt, wird der Objektbezeichner des Sicherheitsprinzipals auch in dieser JSON-Ausgabe angezeigt (z. B. "http://schemas.microsoft.com/identity/claims/objectidentifier": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"). Da möglicherweise nicht immer weitere identitätsbezogene Informationen wie E-Mail-Adresse oder Name angezeigt werden, stellt der Objektbezeichner die beste Möglichkeit zur eindeutigen Identifizierung des Sicherheitsprinzipals dar.
Sie können den Anzeigenamen des Sicherheitsprinzipals ermitteln, indem Sie mithilfe des Werts des Objektbezeichners auf der Microsoft Entra ID-Seite im Azure-Portal nach dem Sicherheitsprinzipal suchen. Im folgenden Screenshot sehen Sie ein Suchergebnis in Microsoft Entra ID.
Überwachen von Vorgängen auf Datenebene
Vorgänge auf Datenebene werden in Azure-Ressourcenprotokollen für Queue Storage erfasst. Sie können die Diagnoseeinstellung so konfigurieren, dass die Protokolle in den Log Analytics-Arbeitsbereich exportiert werden und so eine native Abfrage ermöglicht wird.
Mit der folgenden Log Analytics-Abfrage werden die Informationen zum „Wann“, „Wer“, „Was“ und „Wie“ in einer Liste von Protokolleinträgen abgerufen.
StorageBlobLogs
| where TimeGenerated > ago(3d)
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Für das „Wann“ der Überwachung wird im Feld TimeGenerated der Zeitpunkt angezeigt, an dem der Protokolleintrag erfasst wurde.
Für das „Was“ der Überwachung wird im Feld Uri das Element angezeigt, das geändert oder gelesen wurde.
Für das „Wie“ der Überwachung wird im Feld OperationName der Vorgang angezeigt, der ausgeführt wurde.
Tipp
Wenn Sie beispielsweise vermuten, dass ein Blob oder Container versehentlich gelöscht wurde, fügen Sie eine where-Klausel hinzu, die nur Protokolleinträge zurückgibt, bei denen OperationName auf Delete blob oder Delete Container festgelegt ist.
Für das „Wer“ der Überwachung wird in AuthenticationType der Authentifizierungstyp angezeigt, der für eine Anforderung verwendet wurde. In diesem Feld können alle von Azure Storage unterstützten Authentifizierungstypen angezeigt werden, z. B. die Verwendung eines Kontoschlüssels oder eines SAS-Tokens sowie die Microsoft Entra-Authentifizierung.
Wenn die Anforderung mithilfe von Microsoft Entra ID autorisiert wird, können Sie das Feld RequestObjectId verwenden, um Informationen darüber zu erhalten, „wer“ es war. Die Authentifizierung über gemeinsam verwendete Schlüssel und die SAS-Authentifizierung ermöglichen keine Überwachung einzelner Identitäten. In diesen Fällen können die Felder callerIPAddress und userAgentHeader Ihnen helfen, die Quelle des Vorgangs zu identifizieren. Wenn ein SAS-Token zum Autorisieren eines Vorgangs verwendet wurde, können Sie dieses Token identifizieren. Wenn Sie Token auf Ihrer Seite Tokenempfängern zugeordnet haben, können Sie ermitteln, welche*r Benutzer*in, Organisation oder Anwendung den Vorgang ausgeführt hat. Weitere Informationen finden Sie unter Identifizierung des SAS-Tokens, das zur Autorisierung einer Anforderung verwendet wird.
Identifizierung des Sicherheitsprinzipals, der zur Autorisierung einer Anforderung verwendet wird
Wurde eine Anforderung über Microsoft Entra ID authentifiziert, stellt das Feld RequesterObjectId die zuverlässigste Methode zur Identifizierung des Sicherheitsprinzipals dar. Sie können den Anzeigenamen des Sicherheitsprinzipals ermitteln, indem Sie mithilfe des Werts in Feld RequesterObjectId auf der Microsoft Entra ID-Seite im Azure-Portal nach dem Sicherheitsprinzipal suchen. Im folgenden Screenshot sehen Sie ein Suchergebnis in Microsoft Entra ID.
In einigen Fällen wird in den Protokollen möglicherweise ein Benutzerprinzipalname (UPN, User Principal Name) angezeigt. Ist der Sicherheitsprinzipal beispielsweise ein Microsoft Entra-Benutzer, wird wahrscheinlich der UPN angezeigt. Bei anderen Typen von Sicherheitsprinzipalen, wie etwa benutzerseitig zugewiesenen verwalteten Identitäten, oder in bestimmten Szenarios, wie etwa bei der mandantenübergreifenden Microsoft Entra-Authentifizierung, wird der UPN nicht in den Protokollen angezeigt.
Mit dieser Abfrage werden alle von OAuth-Sicherheitsprinzipalen ausgeführten Schreibvorgänge angezeigt.
StorageBlobLogs
| where TimeGenerated > ago(3d)
and OperationName == "GetBlob"
and AuthenticationType == "OAuth"
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Die Authentifizierung über gemeinsam verwendete Schlüssel und die SAS-Authentifizierung ermöglichen keine Überwachung einzelner Identitäten. Wenn Sie also die Möglichkeit der identitätsbasierten Überwachung verbessern möchten, sollten Sie auf Microsoft Entra ID umsteigen und die Authentifizierung über gemeinsam verwendete Schlüssel sowie die SAS-Authentifizierung verhindern. Informationen zum Verhindern dieser beiden Authentifizierungstypen finden Sie unter Verhindern der Autorisierung mit gemeinsam verwendeten Schlüsseln für ein Azure Storage-Konto. Informationen zu den ersten Schritten mit Microsoft Entra ID finden Sie unter Autorisieren des Zugriffs auf Blobs mit Microsoft Entra ID.
Identifizierung des SAS-Tokens, das zur Autorisierung einer Anforderung verwendet wird
Sie können nach Vorgängen suchen, die mit einem SAS-Token autorisiert wurden. Diese Abfrage gibt zum Beispiel alle Schreibvorgänge zurück, die mit einem SAS-Token autorisiert wurden.
StorageBlobLogs
| where TimeGenerated > ago(3d)
and OperationName == "PutBlob"
and AuthenticationType == "SAS"
| project TimeGenerated, AuthenticationType, AuthenticationHash, OperationName, Uri
Aus Sicherheitsgründen erscheinen SAS-Tokens nicht in den Protokollen. Der SHA-256-Hash der SAS-Tokensignatur wird jedoch im Feld AuthenticationHash angezeigt, das von dieser Abfrage zurückgegeben wird.
Wenn Sie mehrere SAS-Token verteilt haben und wissen möchten, welche SAS-Token verwendet werden, müssen Sie den Signaturteil jedes SAS-Tokens in einen SHA-256-Hash konvertieren und diesen dann mit dem Hashwert vergleichen, der in den Protokollen aufgeführt ist.
Dekodieren Sie zunächst jede SAS-Token-Zeichenkette. Das folgende Beispiel dekodiert den Signaturteil der SAS-Tokenzeichenfolge mithilfe von PowerShell.
[uri]::UnescapeDataString("<SAS signature here>")
Sie können ein beliebiges Tool oder SDK verwenden, um die decodierte Signatur in den SHA-256-Hash dieser Signatur zu konvertieren. Beispielsweise können Sie auf einem Linux-System den folgenden Befehl verwenden:
echo -n "<Decoded SAS signature>" | python3 -c "import sys; from urllib.parse import unquote; print(unquote(sys.stdin.read()), end='');" | sha256sum
Eine andere Methode zum Konvertieren der decodierten Signatur ist, die entschlüsselte Zeichenfolge an die hash_sha256()-Funktion als Teil einer Abfrage zu übergeben, wenn Sie Azure Data Explorer verwenden.
SAS-Tokens enthalten keine Identitätsinformationen. Eine Möglichkeit, die Aktivitäten von Benutzern oder Organisationen zu verfolgen, besteht darin, eine Zuordnung von Benutzern oder Organisationen zu verschiedenen SAS-Token-Hashes zu erstellen.
Optimieren der Kosten bei seltenem Durchführen von Abfragen
Sie können Protokolle in Log Analytics exportieren, um dort die umfassenden nativen Abfragefunktionen zu nutzen. Bei umfangreichen Transaktionen in Ihrem Speicherkonto können die Kosten für die Verwendung von Protokollen in Log Analytics beträchtlich sein. Weitere Informationen finden Sie unter Azure Log Analytics – Preise. Wenn Sie Protokolle nur gelegentlich abfragen möchten (z. B. zur Konformitätsüberwachung), können Sie die Gesamtkosten reduzieren, indem Sie die Protokolle in ein Speicherkonto exportieren und dann zusätzlich zu den Protokolldaten eine serverlose Abfragelösung verwenden, wie etwa Azure Synapse.
Mit Azure Synapse können Sie einen serverlosen SQL-Pool erstellen, um Protokolldaten bei Bedarf abzufragen. Dadurch lassen sich die Kosten erheblich senken.
Exportieren Sie die Protokolle in ein Speicherkonto. Weitere Informationen finden Sie unter Erstellen von Diagnoseeinstellungen.
Erstellen und konfigurieren Sie einen Synapse-Arbeitsbereich. Weitere Informationen finden Sie unter Schnellstart: Erstellen eines Synapse-Arbeitsbereichs.
Fragen Sie die Protokolle ab. Weitere Informationen finden Sie unter Abfragen von JSON-Dateien mit einem serverlosen SQL-Pool in Azure Synapse Analytics.
Hier sehen Sie ein Beispiel:
select JSON_VALUE(doc, '$.time') AS time, JSON_VALUE(doc, '$.properties.accountName') AS accountName, JSON_VALUE(doc, '$.identity.type') AS identityType, JSON_VALUE(doc, '$.identity.requester.objectId') AS requesterObjectId, JSON_VALUE(doc, '$.operationName') AS operationName, JSON_VALUE(doc, '$.callerIpAddress') AS callerIpAddress, JSON_VALUE(doc, '$.uri') AS uri doc from openrowset( bulk 'https://demo2uswest4log.blob.core.windows.net/insights-logs-storageread/resourceId=/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/mytestrp/providers/Microsoft.Storage/storageAccounts/demo2uswest/blobServices/default/y=2021/m=03/d=19/h=*/m=*/PT1H.json', format = 'csv', fieldterminator ='0x0b', fieldquote = '0x0b' ) with (doc nvarchar(max)) as rows order by JSON_VALUE(doc, '$.time') desc