Aanbevolen procedures voor het bewaken van Azure Blob Storage
In dit artikel vindt u een verzameling algemene scenario's voor opslagbewaking en krijgt u richtlijnen voor aanbevolen procedures om ze uit te voeren.
Opslagaccounts zonder of weinig gebruik identificeren
Storage Insights is een dashboard boven op metrische gegevens en logboeken van Azure Storage. U kunt Storage Insights gebruiken om het transactievolume en de gebruikte capaciteit van al uw accounts te onderzoeken. Met deze informatie kunt u bepalen welke accounts u mogelijk buiten gebruik wilt stellen. Zie Uw opslagservice bewaken met Azure Monitor Storage-inzichten om Opslaginzichten te configureren.
Transactievolume analyseren
Sorteer in de weergave Storage Insights in Azure Monitor uw accounts in oplopende volgorde met behulp van de kolom Transacties . In de volgende afbeelding ziet u een account met een laag transactievolume gedurende de opgegeven periode.
Klik op de accountkoppeling voor meer informatie over deze transacties. In dit voorbeeld worden de meeste aanvragen verzonden naar de Blob Storage-service.
Als u wilt bepalen welke soorten aanvragen worden gedaan, zoomt u in op de grafiek transacties op API-naamdiagram .
In dit voorbeeld bevatten alle aanvragen bewerkingen of aanvragen voor accounteigenschapsgegevens. Er zijn geen lees- en schrijftransacties. Dit kan ertoe leiden dat u denkt dat het account niet op een aanzienlijke manier wordt gebruikt.
Gebruikte capaciteit analyseren
Sorteer uw accounts in oplopende volgorde op het tabblad Capaciteit van de weergave Storage Insights in Azure Monitor met behulp van de kolom Gebruikte capaciteit van account. In de volgende afbeelding ziet u een account met een lager capaciteitsvolume dan andere accounts.
Als u de blobs wilt onderzoeken die aan deze gebruikte capaciteit zijn gekoppeld, kunt u Storage Explorer gebruiken. Voor grote aantallen blobs kunt u overwegen om een rapport te genereren met behulp van een blobinventarisbeleid.
Het gebruik van een container bewaken
Als u de gegevens van uw klant per container partitioneert, kunt u controleren hoeveel capaciteit door elke klant wordt gebruikt. U kunt azure Storage-blob-inventaris gebruiken om een inventaris van blobs met groottegegevens te maken. Vervolgens kunt u de grootte en het aantal op containerniveau aggregeren. Zie Bijvoorbeeld Het aantal blobs en de totale grootte per container berekenen met behulp van Azure Storage-inventaris.
U kunt ook verkeer op containerniveau evalueren door query's uit te voeren op logboeken. Zie Log Analytics voor meer informatie over het schrijven van Log Analytics-query's. Zie de naslaginformatie over bewakingsgegevens van Azure Blob Storage voor meer informatie over het schema voor opslaglogboeken.
Hier volgt een query om het aantal leestransacties en het aantal bytes op te halen dat in elke container wordt gelezen.
StorageBlobLogs
| where OperationName == "GetBlob"
| extend ContainerName = split(parse_url(Uri).Path, "/")[1]
| summarize ReadSize = sum(ResponseBodySize), ReadCount = count() by tostring(ContainerName)
De volgende query maakt gebruik van een vergelijkbare query om informatie over schrijfbewerkingen te verkrijgen.
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)
De bovenstaande query verwijst naar de namen van meerdere bewerkingen, omdat meer dan één type bewerking kan tellen als een schrijfbewerking. Zie prijzen voor Azure Blob Storage of Prijzen voor Azure Data Lake Storage voor meer informatie over welke bewerkingen worden beschouwd als lees- en schrijfbewerkingen.
Accountactiviteit controleren
In veel gevallen moet u de activiteiten van uw opslagaccounts controleren op beveiliging en naleving. Bewerkingen voor opslagaccounts vallen in twee categorieën: Besturingsvlak en Gegevensvlak.
Een besturingsvlakbewerking is een Azure Resource Manager-aanvraag voor het maken van een opslagaccount of het bijwerken van een eigenschap van een bestaand opslagaccount. Zie Azure Resource Manager voor meer informatie.
Een gegevensvlakbewerking is een bewerking op de gegevens in een opslagaccount dat het resultaat is van een aanvraag naar het eindpunt van de opslagservice. Een gegevensvlakbewerking wordt bijvoorbeeld uitgevoerd wanneer u een blob uploadt naar een opslagaccount of een blob downloadt vanuit een opslagaccount. Zie Azure Storage-API voor meer informatie.
In de sectie wordt beschreven hoe u de informatie 'wanneer', 'wie', 'wat' en 'hoe' van besturings- en gegevensvlakbewerkingen identificeert.
Besturingsvlakbewerkingen controleren
Resource Manager-bewerkingen worden vastgelegd in het Azure-activiteitenlogboek. Als u het activiteitenlogboek wilt weergeven, opent u uw opslagaccount in Azure Portal en selecteert u vervolgens Activiteitenlogboek.
Open een logboekvermelding om JSON weer te geven waarin de activiteit wordt beschreven. In de volgende JSON ziet u de informatie 'when', 'what' en 'how' van een besturingsvlakbewerking:
De beschikbaarheid van de 'wie'-informatie is afhankelijk van de verificatiemethode die is gebruikt om de besturingsvlakbewerking uit te voeren. Als de autorisatie is uitgevoerd door een Microsoft Entra-beveiligingsprincipaal, wordt de object-id van die beveiligingsprincipaal ook weergegeven in deze JSON-uitvoer (bijvoorbeeld: "http://schemas.microsoft.com/identity/claims/objectidentifier": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"). Omdat u mogelijk niet altijd andere identiteitsgerelateerde informatie zoals een e-mailadres of naam ziet, is de object-id altijd de beste manier om de beveiligingsprincipaal uniek te identificeren.
U vindt de beschrijvende naam van die beveiligingsprincipaal door de waarde van de object-id te gebruiken en te zoeken naar de beveiligingsprincipaal op de pagina Microsoft Entra-id van Azure Portal. In de volgende schermopname ziet u een zoekresultaat in Microsoft Entra ID.
Bewerkingen van het gegevensvlak controleren
Gegevensvlakbewerkingen worden vastgelegd in Azure-resourcelogboeken voor Storage. U kunt de diagnostische instelling configureren voor het exporteren van logboeken naar de Log Analytics-werkruimte voor een systeemeigen query-ervaring.
Hier volgt een Log Analytics-query waarmee de gegevens 'when', 'who', 'what' en 'how' worden opgehaald in een lijst met logboekvermeldingen.
StorageBlobLogs
| where TimeGenerated > ago(3d)
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Voor het 'wanneer'-gedeelte van uw controle wordt het TimeGenerated veld weergegeven wanneer de logboekvermelding is vastgelegd.
Voor het 'wat'-gedeelte van uw controle toont het Uri veld dat het item is gewijzigd of gelezen.
Voor het gedeelte 'hoe' van uw controle wordt in het OperationName veld weergegeven welke bewerking is uitgevoerd.
Tip
Als u bijvoorbeeld vermoedt dat een blob of container per ongeluk is verwijderd, voegt u een where component toe die alleen logboekvermeldingen retourneert waarvoor de OperationName blob of De container verwijderen is ingesteld.
Voor het 'wie'-gedeelte van uw controle AuthenticationType geeft u aan welk type verificatie is gebruikt om een aanvraag te doen. In dit veld kunnen alle typen verificatie worden weergegeven die door Azure Storage worden ondersteund, waaronder het gebruik van een accountsleutel, een SAS-token of Microsoft Entra-verificatie.
Als de aanvraag is geautoriseerd met behulp van Microsoft Entra ID, kunt u het RequestObjectId veld gebruiken om de 'wie' te identificeren. Gedeelde sleutel- en SAS-verificatie bieden geen middelen om afzonderlijke identiteiten te controleren. In die gevallen kunnen de callerIPAddress en userAgentHeader velden u helpen om de bron van de bewerking te identificeren. Als een SAS-token is gebruikt om een bewerking te autoriseren, kunt u dat token identificeren en als u tokens hebt toegewezen aan tokenontvangers aan uw kant, kunt u bepalen welke gebruiker, organisatie of toepassing de bewerking heeft uitgevoerd. Zie Het identificeren van het SAS-token dat wordt gebruikt om een aanvraag te autoriseren.
De beveiligingsprincipaal identificeren die wordt gebruikt om een aanvraag te autoriseren
Als een aanvraag is geverifieerd met behulp van Microsoft Entra ID, biedt het RequesterObjectId veld de meest betrouwbare manier om de beveiligingsprincipaal te identificeren. U vindt de beschrijvende naam van die beveiligingsprincipaal door de waarde van het RequesterObjectId veld te gebruiken en te zoeken naar de beveiligingsprincipaal op de pagina Microsoft Entra-id van Azure Portal. In de volgende schermopname ziet u een zoekresultaat in Microsoft Entra ID.
In sommige gevallen kan een user principal name of UPN worden weergegeven in logboeken. Als de beveiligingsprincipaal bijvoorbeeld een Microsoft Entra-gebruiker is, wordt de UPN waarschijnlijk weergegeven. Voor andere typen beveiligings-principals, zoals door de gebruiker toegewezen beheerde identiteiten, of in bepaalde scenario's, zoals verificatie via meerdere Microsoft Entra-tenants, wordt de UPN niet weergegeven in logboeken.
Deze query toont alle leesbewerkingen die worden uitgevoerd door OAuth-beveiligingsprinciplen.
StorageBlobLogs
| where TimeGenerated > ago(3d)
and OperationName == "GetBlob"
and AuthenticationType == "OAuth"
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Gedeelde sleutel- en SAS-verificatie bieden geen middelen om afzonderlijke identiteiten te controleren. Als u daarom de mogelijkheid wilt verbeteren om te controleren op basis van identiteit, raden we u aan over te stappen op Microsoft Entra-id en gedeelde sleutel- en SAS-verificatie te voorkomen. Zie Autorisatie van gedeelde sleutels voorkomen voor een Azure Storage-account voor meer informatie over het voorkomen van gedeelde sleutel- en SAS-verificatie. Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra-id om aan de slag te gaan met Microsoft Entra-id.
Het SAS-token identificeren dat wordt gebruikt om een aanvraag te autoriseren
U kunt query's uitvoeren op bewerkingen die zijn geautoriseerd met behulp van een SAS-token. Deze query retourneert bijvoorbeeld alle schrijfbewerkingen die zijn geautoriseerd met behulp van een SAS-token.
StorageBlobLogs
| where TimeGenerated > ago(3d)
and OperationName == "PutBlob"
and AuthenticationType == "SAS"
| project TimeGenerated, AuthenticationType, AuthenticationHash, OperationName, Uri
Om veiligheidsredenen worden SAS-tokens niet weergegeven in logboeken. De SHA-256-hash van de SAS-tokenhandtekening wordt echter weergegeven in het AuthenticationHash veld dat door deze query wordt geretourneerd.
Als u verschillende SAS-tokens hebt gedistribueerd en u wilt weten welke SAS-tokens worden gebruikt, moet u het handtekeninggedeelte van elk van uw SAS-tokens converteren naar een SHA-256-hash en die hash vervolgens vergelijken met de hashwaarde die in logboeken wordt weergegeven.
Codeer eerst elke SAS-tokentekenreeks. In het volgende voorbeeld wordt het handtekeninggedeelte van de SAS-tokentekenreeks gedecodeerd met behulp van PowerShell.
[uri]::UnescapeDataString("<SAS signature here>")
U kunt elk hulpprogramma of elke SDK gebruiken om de gedecodeerde handtekening te converteren naar de SHA-256 van die handtekening. Op een Linux-systeem kunt u bijvoorbeeld de volgende opdracht gebruiken:
echo -n "<Decoded SAS signature>" | python3 -c "import sys; from urllib.parse import unquote; print(unquote(sys.stdin.read()), end='');" | sha256sum
Een andere manier om de gedecodeerde handtekening te converteren, is door de gedecodeerde tekenreeks door te geven aan de functie hash_sha256() als onderdeel van een query wanneer u Azure Data Explorer gebruikt.
SAS-tokens bevatten geen identiteitsgegevens. Een manier om de activiteiten van gebruikers of organisaties bij te houden, is door een toewijzing van gebruikers of organisaties aan verschillende SAS-token-hashes te houden.
Kosten optimaliseren voor onregelmatige query's
U kunt logboeken exporteren naar Log Analytics voor uitgebreide systeemeigen querymogelijkheden. Wanneer u enorme transacties voor uw opslagaccount hebt, zijn de kosten voor het gebruik van logboeken met Log Analytics mogelijk hoog. Zie prijzen voor Azure Log Analytics voor meer informatie. Als u alleen query's wilt uitvoeren op logboeken (bijvoorbeeld querylogboeken voor nalevingscontrole), kunt u overwegen de totale kosten te verlagen door logboeken naar het opslagaccount te exporteren en vervolgens een serverloze queryoplossing te gebruiken boven op logboekgegevens, bijvoorbeeld Azure Synapse.
Met Azure Synapse kunt u serverloze SQL-pool maken om logboekgegevens op te vragen wanneer u dat nodig hebt. Dit kan kosten aanzienlijk besparen.
Exporteer logboeken naar het opslagaccount. Zie Een diagnostische instelling maken voor meer informatie.
Een Synapse-werkruimte maken en configureren. Zie quickstart: Een Synapse-werkruimte maken voor meer informatie.
Querylogboeken. Zie JSON-bestanden opvragen met behulp van een serverloze SQL-pool in Azure Synapse Analytics voor meer informatie.
Hier volgt een voorbeeld:
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