Beveilig uw Azure Blob Storage

Azure Blob Storage slaat enorme hoeveelheden ongestructureerde objectgegevens op in containers. Het is vaak het doelwit van exfiltratie, ransomware en incidenten met publieke blootstelling. Dit artikel geeft beveiligingsaanbevelingen specifiek voor blobcontainers, blobs en hiërarchische naamruimtes van Azure Data Lake Storage.

Note

Dit artikel behandelt beveiligingspraktijken specifiek voor Azure Blob Storage. Voor beveiligingsrichtlijnen op accountniveau, zie Secure your Azure Storage account.

Netwerkbeveiliging

  • Gebruik Azure Front Door voor aangepaste domeinen, statische websites en alle openbaar aangeboden blob-inhoud: Laat TLS bij Azure Front Door beëindigen met een beheerd certificaat, schakel WAF in en beperk de openbare netwerktoegang van het opslagaccount zodat alleen Front Door de bron kan bereiken. De eigen custom-domeinfunctie van Azure Storage ondersteunt geen beheerde TLS-certificaten, en Front Door voegt WAF-bescherming, rate-limiting en logging toe die anonieme containertoegang niet heeft. Voor meer informatie, zie Use Azure Front Door with Azure Storage blobs.

  • Schakel het statische website-eindpunt uit wanneer het niet in gebruik is: De $web container blijft publiek leesbaar zolang de statische websitefunctie is ingeschakeld, zelfs als allowBlobPublicAccess het is false. Schakel de statische website-functie uit op accounts die het niet nodig hebben. Zie Statische websitehosting in Azure Storage voor meer informatie.

Identiteits- en toegangsbeheer

Anonieme publieke toegang

  • Schakel anonieme publieke leestoegang uit bij het opslagaccount: Stel de allowBlobPublicAccess eigenschap zo false in dat geen enkele container in het account openbaar kan zijn, ongeacht de configuratie op containerniveau. Raadpleeg Overzicht: Herstellen van anonieme leestoegang voor blobgegevens voor meer informatie.

  • Controleer en herstel bestaande anonieme toegang: Gebruik de richtlijnen in Remediate anonymous read access to blob data om containers te vinden die publieke toegang toestaan en deze om te zetten naar privétoegang of expliciet SAS-gebaseerde deling.

SAS en ABAC op blobniveau

  • Geef de voorkeur aan gebruikersdelegatie-SAS boven service-SAS voor blob-toegang: Een gebruikersdelegatie gedeelde toegangshandtekening (SAS) wordt ondertekend met een Microsoft Entra-credential. Het intrekken van de gebruikersdelegatiesleutel maakt onmiddellijk elke SAS die ermee is uitgegeven ongeldig en biedt daarmee een intrekkingsmogelijkheid die service- en account-SAS'en niet bieden. Zie Een SAS voor gebruikersdelegatie maken voor meer informatie.

  • Beperk een service-SAS met opgeslagen toegangsbeleid voor herroepbaarheid: Als je een service-SAS moet gebruiken, koppel deze dan aan een opgeslagen toegangsbeleid op de container. Je kunt het beleid dan aanpassen of verwijderen om elke SAS die ernaar verwijst in te trekken. Zonder beleid kan een service-SAS alleen worden ingetrokken door de accountsleutels te roteren, wat van invloed is op alle andere SAS in het account. Zie Een opgeslagen toegangsbeleid definiëren voor meer informatie.

  • Gebruik blob-indextags om toegang via ABAC te conditionen: Combineer blob-indextags met attribute-based access control (ABAC) voorwaarden om alleen leestoegang te verlenen aan blobs met specifieke tagwaarden - bijvoorbeeld, Classification=Public. Deze aanpak maakt het mogelijk dat één roltoewijzing veel bellers bedient zonder toegang te verlenen tot gevoelige getagde gegevens. Raadpleeg voor meer informatie Toegang tot blobs autoriseren met ABAC-voorwaarden.

Gegevensbeveiliging

  • Gebruik blob-encryptiescopes om encryptie te isoleren voor specifieke containers of blobs: Met encryptiescopes kun je verschillende sleutels of sleutelrotatiebeleid op container- of blob-niveau granulariteit binnen één account toepassen. 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.

  • Gebruik client-side encryptie voor blobdata die nooit in platte tekst op de server mogen verschijnen: Versleutel blob-inhoud in de client vóór upload. De SDK integreert met Azure Key Vault of Managed HSM voor sleutelbeheer. Combineer dit met CMK aan de servicezijde voor gelaagde bescherming. Voor meer informatie, zie Client-side encryptie voor blobs.

Onveranderlijkheid en WORM

  • Configureer tijdsgebaseerde retentiebeleid voor gereguleerde data: Pas container- of versieniveau tijdgebaseerde retentie toe om wijziging of verwijdering van blobs voor een vaste periode te voorkomen. Versie-niveau onveranderlijkheid biedt fijnere controle en je kunt deze inschakelen of uitbreiden op individuele versies. Zie Bedrijfskritieke blobgegevens opslaan met onveranderbare opslag voor meer informatie.

  • Gebruik juridische bewaring voor onbepaalde bewaring op basis van juridische of onderzoeksbehoeften: Juridische bewaring voorkomt dat gegevens worden verwijderd totdat een bevoegde gebruiker de bewaring expliciet opheft, zonder vaste duur. Zie Bedrijfskritieke blobgegevens opslaan met onveranderbare opslag voor meer informatie.

  • Vergrendel retentiebeleid om ze niet te wijzigen: Gebruikers met de juiste rechten kunnen een ontgrendeld retentiebeleid inkorten of verwijderen. Het vergrendelen van de polis maakt de retentieperiode een eenrichtingsverbintenis. Sluit alleen nadat je de duur van de polis hebt gevalideerd. Voor meer informatie, zie Onveranderlijkheidsbeleid configureren voor containers.

Replicatie van objecten en kopieerbewerkingen

  • Beperk objectreplicatie tot bronaccounts die je beheert: Configureer de toegestane bronrekeninglijst van het bestemmingsaccount zodat alleen bekende, vertrouwde bronaccounts data kunnen pushen. Zie Objectreplicatie configureren voor meer informatie.

  • Voorkom objectreplicatie tussen tenants: Replicatiebeleid verbieden waarbij de bron- en doelaccounts zich in verschillende Microsoft Entra-tenants bevinden. Deze beperking voorkomt dat een geautoriseerde gebruiker replicatie configureert naar een externe tenant. Zie Objectreplicatie voorkomen in Microsoft Entra-tenants voor meer informatie.

  • Beperk de toegestane scope voor kopieeroperaties: Configureer het account zodat kopieeroperaties alleen vanaf bronaccounts in dezelfde tenant of hetzelfde abonnement worden toegestaan. Deze configuratie blokkeert een gemeenschappelijk exfiltratiepad - kopiëren van een privéaccount naar een door aanvallers gecontroleerd account. Voor meer informatie, zie Toegestane scope voor kopieeroperaties.

Back-up en herstel

  • Schakel blobversiebeheer in om eerdere versies te behouden bij schrijven en verwijderen: Wanneer je versiebeheer inschakelt, maakt elke schrijf- of verwijderingsoperatie een nieuwe versie aan en behoudt de vorige toestand. Je kunt versies opgeven en herstellen. Zie Blob-versiebeheer voor meer informatie.

  • Schakel soft delete in voor blobs en containers: Soft delete bewaart verwijderde blobs en containers voor een bepaalde retentieperiode, zodat je ze in die tijd kunt herstellen. Configureer soft delete op containerniveau en op blobniveau afzonderlijk en schakel beide in. Voor meer informatie, zie Soft delete voor blobs en Soft delete voor containers.

  • Schakel point-in-time herstel in voor block blob-accounts: Point-in-time restore werkt met versiebeheer en soft delete om een bereik van block blobs terug te brengen naar een specifieke vorige tijdstempel. Deze functie is handig voor het herstel van ransomware. Herstel naar een bepaald tijdstip vereist dat u versiebeheer, voorlopig verwijderen van blobs en de wijzigingsfeed inschakelt. Zie Herstel naar een bepaald tijdstip voor blok-blobs voor meer informatie.

  • Schakel de wijzigingsfeed in voor audit en forensisch onderzoek: De wijzigingsfeed is een geordende, onveranderlijke logboek van elke wijziging aan blobs in het account. Naast het mogelijk maken van herstel op een bepaald moment, biedt het een duurzaam auditverslag voor onderzoeken. Zie Ondersteuning voor wijzigingsfeeds in Azure Blob Storage voor meer informatie.

Azure Data Lake Storage

Data Lake Storage voegt een hiërarchische naamruimte en POSIX-achtige toegangscontrolelijsten (ACL's) toe aan Blob Storage. ACL's en RBAC werken samen - geven grofweg toegang via RBAC en verfijnen binnen het bestandssysteem met ACL's.

  • Gebruik RBAC voor grofkorrelige toegang en ACL's voor fijnmazige toegang: Wijs ingebouwde blob-RBAC-rollen toe op container- of accountniveau om brede toegang te verlenen. Gebruik vervolgens ACL's op mappen en bestanden om de toegang binnen de container te beperken. Gebruik ACL's niet alleen voor permissies die een gebruiker nodig heeft voor een hele container. RBAC is efficiënter om te evalueren en te auditen. Zie het Access Control-model in Azure Data Lake Storage voor meer informatie.

  • Pas standaard ACL's toe op mappen om rechten te erven op nieuwe kinditems: Standaard ACL's zijn van toepassing op bestanden en mappen die zijn aangemaakt nadat je de ACL hebt ingesteld. Stel ze in op directoryniveau om het beheren van ACL's op individuele bestanden te vermijden. Voor meer informatie, zie Access control lists in Azure Data Lake Storage.

  • Schakel de hiërarchische naamruimte in bij het aanmaken van het account: Je kunt de hiërarchische naamruimte niet inschakelen op een bestaand account zonder migratie. Als je weet dat een workload Data Lake Storage-semantiek gebruikt, schakel deze dan meteen in in plaats van later te migreren. Voor meer informatie, zie Azure Data Lake Storage hiërarchische naamruimte.

Logboekregistratie en bewaking

  • Waarschuwing bij treffers voor anonieme toegang nadat je anonieme toegang hebt uitgeschakeld: Wanneer je allowBlobPublicAccess instelt op false, filter je de opslaglogboeken op AuthenticationType == "Anonymous" en genereer je een waarschuwing voor eventuele treffers. Deze hits wijzen op een onjuist geconfigureerde client of een verkenningspoging. Zie Azure Storage bewaken voor meer informatie.

  • Schakel Defender for Storage-malwarescanresultaten in en reageer erop: Wanneer je malwarescanning inschakelt, configureer dan een geautomatiseerde reactie (blobverwijdering, quarantaine-tag of onderdrukking van een downstream-workflow) op MalwareScanningResult scanresultaten, zodat geïdentificeerde schadelijke blobs niet aan gebruikers kunnen worden aangeboden. Raadpleeg voor meer informatie Reageren op resultaten van malwarescans in Defender for Storage.

  • Volg mutaties van blob-indextags voor classificatiedrift: Als je blob-indextags gebruikt om ABAC-toegangsvoorwaarden aan te sturen, bepalen wijzigingen aan die tags direct wie de blob kan lezen. Registreer en waarschuw bij SetBlobTags bewerkingen op gevoelige containers. Voor meer informatie, zie Beheren en gegevens vinden op Azure Blob Storage met blob index-tags.

Volgende stappen 

  • Laatst bijgewerkt om