Uw Azure Storage-account beveiligen

Azure Storage biedt schaalbare, duurzame cloudopslag voor blobs, bestanden, wachtrijen en tabellen in één opslagaccount. Omdat een opslagaccount gegevens van zeer verschillende gevoeligheidsniveaus kan bevatten en vaak het doelwit is van exfiltratie- en ransomware-aanvallen, neem dan bewuste stappen om het account, de gegevens die het bevat en de identiteiten die erop toegang hebben te beschermen.

Dit artikel geeft beveiligingsaanbevelingen om je Azure Storage-account te beschermen. Deze aanbevelingen gelden voor alle dataservices in het account (Blobs, Files, Queues en Tables). Voor richtlijnen specifiek voor elke datadienst, zie de artikelen over Gerelateerde beveiliging aan het einde van dit artikel.

In de aanbevelingen voor beveiliging in dit artikel worden zero Trust-principes geïmplementeerd: 'Expliciet verifiëren', 'Minimale toegang tot bevoegdheden gebruiken' en 'Inbreuk aannemen'. Zie het Zero Trust Guidance Center voor uitgebreide richtlijnen voor Zero Trust.

Servicespecifieke beveiliging

Azure Storage heeft architecturale kenmerken die bepalen hoe je het veilig uitrolt. De keuzes die je maakt bij het aanmaken van een account – deploymentmodel, type, redundantie en endpointconfiguratie – zijn later moeilijk te wijzigen en beïnvloeden de beveiligingspositie van elke workload die het account gebruikt.

Opslagaccountarchitectuur

  • Gebruik het Azure Resource Manager implementatiemodel: Maak nieuwe opslagaccounts aan door het Azure Resource Manager implementatiemodel te gebruiken. Resource Manager-accounts ondersteunen Azure role-based access control (RBAC), beheerde identiteiten, Microsoft Entra ID-autorisatie voor data, resource locks, tags en beleid – geen van deze is beschikbaar met het klassieke implementatiemodel. Migreer alle resterende klassieke accounts. Voor meer informatie, zie Migrate a classic storage account naar Azure Resource Manager.

  • Gescheiden opslagaccounts per werklast, omgeving en gevoeligheid: Maak aparte accounts aan voor ontwikkeling, preproductie en productie, en aparte accounts voor gegevens met verschillende gevoeligheidsclassificaties. Een opslagaccount vormt een vertrouwensgrens op basis van gedeelde sleutels en een beleidsgrens; het combineren van werklasten in één account vergroot de impact van een compromittering en maakt het moeilijker om toegang met minimale bevoegdheden te definiëren.

  • Gebruik één account per regio voor regionale isolatie: Het plaatsen van accounts in de regio waar hun verbruikende workloads draaien, vermindert de gegevensverwisseling tussen regio's en vereenvoudigt compliancegrenzen. Voor multiregion-ontwerpen koppel regionale accounts aan geo-redundante opslag of objectreplicatie in plaats van alle regio's vanuit één account te bedienen. Zie Redundantie in Azure Storage voor meer informatie.

Geschikt gebruik van Azure Storage

  • Gebruik geen Azure Storage-accountsleutels als langlopende applicatiecredentials: Storage-accountsleutels geven volledige controle over het account en kunnen niet worden gescoped. Applicaties moeten Microsoft Entra ID gebruiken met beheerde identiteiten of, als Entra ID geen optie is, kortdurende gebruikersdelegatie-shared access signature (SAS)-tokens. Zie Toegang tot gegevens in Azure Storage autoriseren voor meer informatie.

  • Gebruik Azure Storage niet als algemene geheimenopslag: Geheimen, verbindingsstrings en certificaten horen thuis in Azure Key Vault, dat rotatie, toegangsbeleid, bescherming van hardware security module (HSM) en auditsporen biedt. Zie het overzicht van Azure Key Vault voor meer informatie.

Netwerkbeveiliging

Opslagaccounts zijn standaard via internet bereikbaar. Het verkleinen van het aanvalsoppervlak van het netwerk is de meest effectieve verandering die je kunt doorvoeren om een account te beschermen tegen ongeautoriseerde toegang, data-exfiltratie en verkenning.

  • Schakel de toegang tot het openbare netwerk tot het opslagaccount uit: Wanneer je clients volledig in Azure zitten of bereikbaar zijn via Private Link, stel dan de publieke netwerktoegang van het account in op Uitgeschakeld zodat alleen verzoeken via private endpoints worden geaccepteerd. Zie Azure Storage-firewalls en virtuele netwerken configureren voor meer informatie.

  • Gebruik privé-endpoints voor toegang vanuit virtuele netwerken: Een privé-endpoint wijst een privé-IP-adres van je virtuele netwerk toe aan het opslagaccount en leidt verkeer via de Microsoft-backbone. In combinatie met uitgeschakelde toegang tot het openbare netwerk elimineren private endpoints de internetblootstelling. Zie Privé-eindpunten gebruiken voor Azure Storage voor meer informatie.

  • Beperk publieke toegang met de opslagfirewall wanneer private endpoints niet praktisch zijn: Als clients het account via publiek netwerk moeten bereiken, stel dan de standaardactie van de firewall in op Weigeren en sta alleen toe op specifieke IP-bereiken, virtuele netwerksubnetten (via service-endpoints) of resource-instanties die toegang nodig hebben. Zie Azure Storage-firewalls en virtuele netwerken configureren voor meer informatie.

    • Sta vertrouwde Microsoft-services toe wanneer ze toegang tot het account nodig hebben: Deny-by-default firewallregels blokkeren verzoeken van andere Azure-diensten (bijvoorbeeld Azure Backup, Log Analytics en Microsoft Defender for Storage) evenals van Azure portaal en diagnostische pijplijnen. Voeg de Allow Azure services toe aan de lijst met trusted services om toegang te krijgen tot deze opslagaccount-uitzondering, zodat first-party services waarop je vertrouwt het account kunnen bereiken zonder het open te stellen voor het publieke internet. Zie Grant-toegang tot vertrouwde Azure-services voor meer informatie.

    • Verleen toegang tot specifieke resource-instanties in plaats van vertrouwde services in het algemeen: geef de voorkeur aan resource-instantieregels, die een benoemde Azure-resource en diens beheerde identiteit autoriseren, boven de algemene uitzondering "Allow trusted Microsoft-services". Resource instance regels zorgen voor een kleiner vertrouwensoppervlak. Voor meer informatie, zie Toegang verlenen vanuit Azure-resource-exemplaren.

  • Koppel opslagaccounts aan een netwerkbeveiligingsperimeter: Een netwerkbeveiligingsperimeter definieert logische grenzen tussen platforms en serviceresources en blokkeert standaard verkeer buiten de perimeter, wat diepgaande verdediging biedt buiten de firewallregels per account. Voor meer informatie, zie Netwerkbeveiligingsperimeter voor Azure Storage.

  • Handhaaf een minimale TLS-versie van 1.2 of later: Configureer de minimale TLS-versie van het opslagaccount om klanten te weigeren die onderhandelen over oudere, verouderde versies. Voor meer informatie, zie De minimaal vereiste versie van Transport Layer Security (TLS) voor een opslagaccount configureren.

  • Vereiste veilige overdracht (HTTPS): Schakel de Secure transfer required-eigenschap in om elk verzoek via HTTP te weigeren. Deze eis geldt zowel voor REST-endpoints als voor SMB-toegang tot Azure Files. Voor meer informatie, zie Vereiste veilige overdracht voor een opslagaccount.

    • Sommige scenario's, zoals oudere SMB-clients of legacy-tools, vereisen HTTP. In zulke gevallen isoleer je die clients in een gecontroleerd netwerksegment en migreer je ze zo snel mogelijk van HTTP.

  • Beperk cross-tenant objectreplicatie en kopieeroperaties: Configureer het opslagaccount zodat kopieer- en objectreplicatiebewerkingen alleen vanaf bronaccounts binnen dezelfde tenant worden toegestaan, of alleen vanaf toegestane bronaccounts. Deze configuratie voorkomt gegevensoverdracht over tenantgrenzen door gebruikers die data-plane-rechten hebben. Voor meer informatie, zie Toegestane scope voor kopieeroperaties en Voorkom objectreplicatie over Microsoft Entra-tenants.

  • Gebruik VNet-servicetags voor uitgaande regels naar Azure Storage: Wanneer je uitgaand verkeer van een virtueel netwerk beperkt naar Azure Storage, gebruik dan de Storage servicetag (of regio-specifieke variant) in plaats van hardgecodeerde IP-bereiken. Microsoft onderhoudt de servicetag naarmate de IP-sector zich ontwikkelt. Zie het overzicht van Azure-servicetags voor meer informatie.

  • Geef de voorkeur aan het globale netwerk van Microsoft voor inbound routing: Stel de netwerkrouteringsvoorkeur van het opslagaccount in naar Microsoft netwerkroutering zodat inkomend verkeer de Microsoft-backbone binnenkomt op het moment van aanwezigheid het dichtst bij de client en end-to-end op het Microsoft-netwerk blijft. Internetroutering verlaat het Microsoft-netwerk eerder en vergroot de blootstelling aan het publieke internetpad. Zie Netwerkrouteringsvoorkeur configureren voor Azure Storage voor meer informatie.

Identiteits- en toegangsbeheer

Opslagaccounts ondersteunen twee autorisatiemodellen: Microsoft Entra ID (identiteitsgebaseerd, controleerbaar, herroepbaar) en Shared Key (een symmetrisch geheim met volledige accounttoegang). Verplaats workloads waar mogelijk naar Microsoft Entra ID en behandel Shared Key als een legacy fallback.

  • Gebruik Microsoft Entra ID om toegang tot data te autoriseren: Microsoft Entra ID-autorisatie gebruikt OAuth 2.0-tokens en integreert met Conditional Access, beheerde identiteiten en RBAC-auditsporen. Het is voor toegang tot het datavlak in elk opzicht superieur aan Shared Key. Zie Toegang tot gegevens in Azure Storage autoriseren voor meer informatie.

  • Shared Key authorization niet toestaan: Stel de allowSharedKeyAccess eigenschap zo in false dat het account elk verzoek dat met de accountsleutels is ondertekend weigert. Alleen Microsoft Entra ID en, waar van toepassing, gebruikersdelegatieverzoeken voor SAS worden geaccepteerd. Voor meer informatie, zie Preventie van autorisatie met gedeelde sleutel voor een Azure-opslagaccount.

  • Wijs RBAC-rollen toe op de kleinst redelijke schaal: Wijs de ingebouwde Storage data-plane-rollen toe (bijvoorbeeld Storage Blob Data Reader, Storage Queue Data Contributor) op container-, share-, queue- of tabelniveau waar mogelijk, in plaats van op account- of abonnementsniveau. Voor meer informatie, zie Toegang autoriseren tot blobs met Azure rolgebaseerde toegangscontrole.

    • Voeg ABAC-voorwaarden toe om de toegang tot data-plane verder te beperken: Azure attribute-based access control (ABAC) laat je voorwaarden koppelen aan roltoewijzingen – bijvoorbeeld door toegang te beperken tot blobs met een specifieke indextag of onder een specifiek padprefix. Zie Toegang tot blobs autoriseren met Azure-roltoewijzingen en ABAC-voorwaarden voor meer informatie.

  • Gebruik gebruikersdelegatie-SAS in plaats van service- of account-SAS wanneer SAS vereist is: een gebruikersdelegatie-SAS wordt ondertekend met een Microsoft Entra-credential in plaats van de accountsleutel, waardoor het intrekken van de gebruikersdelegatiesleutel onmiddellijk elke SAS die ervan wordt uitgegeven, ongeldig maakt. Service- en account SAS-tokens die met accountsleutels zijn ondertekend, kunnen niet individueel worden ingetrokken. Zie Beperkte toegang verlenen tot Azure Storage-resources met sas (Shared Access Signatures) voor meer informatie.

    • Beperk elke SAS tot de minimale rechten en kortste vereiste levensduur: Verleen alleen de specifieke bewerkingen (bijvoorbeeld, read maar niet write) en stel de vervaldatum in op één uur of minder voor service-SAS die niet worden ondersteund door een opgeslagen toegangsbeleid. Voor meer informatie, zie Best practices bij het gebruik van SAS.

    • Configureer een SAS-vervalbeleid op het account: Stel een bovengrens in voor de geldigheidsduur van SAS-tokens die vanaf het account worden uitgegeven. Overtredingen worden geregistreerd zodat je langlopende SAS in je codebase kunt vinden en repareren. Zie Een verloopbeleid maken voor handtekeningen voor gedeelde toegang voor meer informatie.

    • Beperk SAS-tokens tot alleen HTTPS: Wanneer je een SAS moet uitgeven, sta dan alleen HTTPS toe in de SAS-handtekening om tokenblootstelling in de clear te voorkomen. Zie Beperkte toegang verlenen tot Azure Storage-resources met sas (Shared Access Signatures) voor meer informatie.

  • Als je accountsleutels moet gebruiken, bescherm en roteer ze: Sla accountsleutels op in Azure Key Vault, haal ze tijdens runtime op in plaats van ze in de configuratie in te sluiten, en roteer ze op een bepaald tempo. Zorg voor een gedocumenteerde rotatieprocedure die downtime voorkomt door beide toetsen tijdens het overrollen te gebruiken. Zie Toegangssleutels voor een opslagaccount beheren voor meer informatie.

  • Wijs bevoorrechte opslagrollen just-in-time toe met Microsoft Entra Privileged Identity Management (PIM): Voor rollen die managementplane-wijzigingen aan opslag toestaan (zoals Storage Account Contributor of Owner), is PIM-activatie met goedkeuring en multi-factor authenticatie vereist in plaats van vaste toewijzingen. Zie Wat is Microsoft Entra Privileged Identity Management? voor meer informatie.

Gegevensbeveiliging

Azure Storage versleutelt standaard alle data in rust met door Microsoft beheerde sleutels. De aanbevelingen in deze sectie voegen klantcontrole toe, beschermen tegen onbedoelde of kwaadaardige wijzigingen, en verminderen de blootstelling van gegevens tijdens transport en in rust.

  • Configureer klantbeheerde sleutels (CMK) voor versleuteling in rust: Gebruik een sleutel die je beheert in Azure Key Vault of Managed HSM als de accountversleutelsleutel. CMK stelt je in staat om de encryptiesleutel onafhankelijk van door Microsoft beheerde sleutels te roteren, auditen en intrekken. Het ondersteunt compliance-eisen die klantsleutelcontrole verplicht stellen. Zie Door de klant beheerde sleutels voor Azure Storage-versleuteling voor meer informatie.

  • Schakel infrastructuurencryptie in voor defense-in-depth dubbele versleuteling: Infrastructuurencryptie voegt een tweede, servicebeheerde encryptielaag toe bovenop de primaire encryptielaag. Je moet het inschakelen bij het aanmaken van het account. Voor meer informatie, zie Infrastructuurencryptie inschakelen voor dubbele versleuteling van data.

  • Gebruik encryptiescopes om encryptie te isoleren voor specifieke containers of blobs: Met encryptiescopes kun je verschillende sleutels of sleutelrotatiebeleid toepassen op container- of blob-niveau granulariteit binnen één account. Deze functie is handig voor multitenant-workloads die een account delen maar per tenant sleutelbeheer nodig hebben. Voor meer informatie, zie Encryption scopes for Blob Storage.

  • Schakel Azure Storage-encryptie in voor alle data tijdens transport: Combineer Secure transfer required = enabled (zie Netwerkbeveiliging) met een minimale TLS-versie van 1.2 of later. Samen zorgen ze ervoor dat het account zowel onversleutelde als zwak versleutelde verbindingen afwijst.

  • Gebruik client-side encryptie voor de meest gevoelige data: Voor gegevens waarvan platte tekst nooit op de server mag verschijnen, versleutel je in de client vóór upload. Client-side encryptie is complementair aan service-side encryptie en kan samen met CMK worden gebruikt voor gelaagde bescherming. Voor per-service SDK-ondersteuning en patronen, zie Gerelateerde beveiligingsartikelen.

  • Bescherm het opslagaccount met een resource lock: Pas een CanNotDelete of ReadOnly lock toe om per ongeluk of kwaadaardige verwijdering of herconfiguratie van het account zelf te voorkomen. Vergrendelingen zijn van toepassing op de accountresource, niet op de gegevens daarin, en vormen dus een aanvulling op voorlopig verwijderen en onveranderlijkheid; ze vervangen deze niet. Zie Een Azure Resource Manager-vergrendeling toepassen op een opslagaccount voor meer informatie.

Voor dataservice-specifieke gegevensbeschermingsfuncties (blob-immutabiliteit en WORM-beleid, blob-encryptiescopes), zie het bijbehorende subartikel in Gerelateerde beveiligingsartikelen.

Logboekregistratie en bewaking

Opslagaccounts zijn vaak het doelwit van inlogijstal, exfiltratiepogingen en verkeerde configuratie. Je hebt continue logging en dreigingsdetectie nodig om aanvallen snel te detecteren en erop te reageren.

  • Schakel Microsoft Defender for Storage in: Defender for Storage biedt dreigingsdetectie, malware-scanning bij upload op blobs en ontdekking van gevoelige gegevens. Het markeert anomalistische toegangspatronen, bekende kwaadaardige IP's en Tor-exits, en ongebruikelijke authenticatieactiviteiten. Schakel het in op abonnements- of opslagaccountniveau. Voor meer informatie, zie Overzicht van Microsoft Defender voor opslag.

    • Schakel malware-scannen in op blob-uploads op accounts die niet-vertrouwde content accepteren: Malware-scanning inspecteert geüploade blobs en markeert of verwijdert kwaadaardige inhoud voordat deze aan downstream-gebruikers kan worden geleverd. Voor meer informatie, zie Malware Scanning in Defender for Storage.

    • Activeer detectie van gevoelige databedreigingen: Ontdekking van gevoelige gegevens classificeert gegevens in het account en geeft prioriteit aan meldingen op containers die gevoelige informatie bevatten. Voor meer informatie, zie Gevoelige gegevensontdekking in Defender for Storage.

  • Stuur diagnostische instellingen naar een Log Analytics-werkruimte: Configureer diagnostische instellingen op het account en elke datadienst (Blobs, Files, Queues, Tables) om , StorageWrite, en StorageDelete logs plus alle metrics naar Log Analytics te sturenStorageRead. Bewaar logs gedurende de periode die vereist is door uw compliance-verplichtingen. Zie Azure Storage bewaken voor meer informatie.

  • Controleer hoe elk verzoek is geautoriseerd: Opslaglogs registreren of elk verzoek is geautoriseerd met Microsoft Entra ID, Shared Key, SAS of anoniem. Raadpleeg regelmatig de logs om onverwachte autorisatiemethoden te detecteren, vooral het gebruik van Shared Key nadat je deze hebt uitgeschakeld of anonieme toegang nadat je hem hebt uitgeschakeld. Voor meer informatie, zie Monitorverzoeken tegen Azure Storage.

  • Waarschuwing bij hoog-signaal beveiligingsgebeurtenissen: Configureer Azure Monitor-waarschuwingen voor gebeurtenissen zoals sleutelregeneratie, wijzigingen in firewallregels, wijzigingen in openbare netwerktoegang, gebruik van gedeelde sleutels op accounts waar deze uitgeschakeld zou moeten zijn, en Defender for Storage waarschuwingen. Zie Logboekwaarschuwingen in Azure Monitor voor meer informatie.

  • Log doorsturen naar een centrale SIEM: Voor enterprise-schaal respons stuur opslaglogs van Log Analytics naar Microsoft Sentinel of een andere SIEM zodat opslaggebeurtenissen correlleren met identiteit, netwerk en endpointsignalen. Voor meer informatie, zie Connect Azure Storage to Microsoft Sentinel.

Naleving en bestuur

Governance-controles maken veilige configuraties standaard en detecteren drift automatisch. Voor elke opslaglocatie groter dan een handvol accounts is beleidsgebaseerde handhaving de enige duurzame manier om de basislijn consistent te houden.

  • Pas Azure Policy toe om basisbeveiligingsbeveiliging van opslag af te dwingen: Wijs ingebouwde beleidsregels toe die onveilige configuraties blokkeren bij implementatie en audit bestaande accounts. Waardevolle ingebouwde functies zijn onder andere: vereist veilige overdracht, vereist minimaal TLS 1.2, weigert publieke netwerktoegang, weigert publieke blob-toegang, vereist infrastructuurencryptie en vereist CMK. Voor een volledige lijst, zie Azure Policy ingebouwde definities voor Azure Storage en Azure Policy Regulatory Compliance controls voor Azure Storage.

  • Gebruik de Microsoft cloud security benchmark (MCSB) als basis: Lijn opslagcontroles af met MCSB v2-domeinen voor een consistente beveiligingspositie over services heen. Voor meer informatie, zie Overzicht van de Microsoft cloud security benchmark.

  • Tagopslagaccounts met eigenaar, gegevensclassificatie en omgeving: Governance-beleid, kostenbeheer en incidentrespons zijn allemaal afhankelijk van consistente tagging. Pas tags toe via Azure Policy zodat ze niet bij het maken kunnen worden weggelaten.

  • Bekijk compliance-aanbiedingen voordat je gereguleerde data opslaat: Azure Storage beschikt over certificeringen voor gangbare regelgevingskaders (HIPAA, PCI DSS, FedRAMP, ISO 27001 en anderen). Bevestig de dekking van je werklast vóór de uitzending. Voor meer informatie, zie Azure Storage compliance-aanbiedingen.

Back-up en herstel

Cross-region redundantie plus gevalideerde failoverprocedures zorgen voor regionale veerkracht voor het opslagaccount zelf. Voor gegevensservicespecifieke verwijderingsbeveiliging (blob soft delete, blobversiebeheer, wijzigingsfeed, herstel naar een bepaald tijdstip, soft delete voor bestandsshares en momentopnamen), zie het overeenkomstige subartikel in Gerelateerde beveiligingsartikelen.

  • Kies een geschikte redundantieoptie voor uw herstelbehoeften: Geo-redundante opslag (GRS/RA-GRS/GZRS/RA-GZRS) repliceert data naar een gekoppeld gebied en ondersteunt door de klant geïnitieerde failover voor regionale veerkracht. Zone-redundante opslag (ZRS/GZRS) beschermt tegen zone-niveau storingen binnen een regio. Zie Redundantie in Azure Storage voor meer informatie.

  • Vertrouw niet op geo-redundantie voor ransomware-bescherming: Geo-redundante replicatie weerspiegelt data - en eventuele corruptie of kwaadaardige verwijdering - naar het gekoppelde gebied. Combineer GRS met onveranderlijkheidsbeleid, soft delete en versiebeheer voor ransomware en manipulatiebestendigheid. Voor meer informatie, zie Gegevensbeschermingsfuncties in Azure Storage.

  • Oefen door de klant geïnitieerde failover en failback: Voor accounts met RA-GRS of RA-GZRS voer je een geplande failover-oefening uit om je herstelprocedure te valideren voordat je die nodig hebt. Zie Herstel na noodgevallen en failover van opslagaccounts voor meer informatie.

Voor beveiligingsrichtlijnen specifiek voor elke Azure Storage dataservice, zie:

Volgende stappen 

  • Laatst bijgewerkt om