Plan voor het implementeren van Azure Files

U kunt Azure Files op twee belangrijke manieren implementeren: door de serverloze Azure-bestandsshares rechtstreeks te koppelen of door on-premises bestandsshares in de cache op te slaan met behulp van Azure File Sync. Overwegingen voor de implementatie verschillen op basis van welke optie u kiest.

• Directe koppeling van een Azure-bestandsshare: Omdat Azure Files server message block (SMB) of NFS-toegang (Network File System) biedt, kunt u Azure-bestandsshares on-premises of in de cloud koppelen met behulp van de standaard-SMB- of NFS-clients die beschikbaar zijn in uw besturingssysteem. Omdat Azure-bestandsshares serverloos zijn, hoeft u geen bestandsserver of NAS-apparaat te beheren voor implementatie in productiescenario's. Dit betekent dat u geen softwarepatches hoeft toe te passen of fysieke schijven te wisselen. U kunt ervoor kiezen om klassieke Azure-bestandsshares of Microsoft.FileShares (preview) te gebruiken als uw beheermodel.

• On-premises Azure-bestandsshares in cache opslaan met Azure File Sync (alleen SMB): Met Azure File Sync kunt u de bestandsshares van uw organisatie centraliseren in Azure Files, terwijl u de flexibiliteit, prestaties en compatibiliteit van een on-premises bestandsserver kunt behouden. Azure File Sync transformeert een on-premises (of cloud) Windows Server in een snelle cache van uw SMB Azure-bestandsshare.

In dit artikel worden de overwegingen voor implementatie besproken van een Azure-bestandsdeling die direct kan worden gekoppeld bij een lokale of cloudclient. Raadpleeg planning voor een Azure File Sync-implementatie om een Azure File Sync-implementatie te plannen.

Beheerconcepten

In Azure is een resource een beheerbaar item dat u maakt en configureert binnen uw Azure-abonnementen en -resourcegroepen. Resources worden aangeboden door resourceproviders, die beheerservices zijn die specifieke typen resources leveren. Hoewel u met veel resources kunt werken om een workload in Azure te implementeren, is Azure Files gebaseerd op twee belangrijke resources:

• Opslagaccounts, aangeboden door de Microsoft.Storage resourceprovider. Opslagaccounts zijn resources op het hoogste niveau die een gedeelde opslaggroep, IOPS en doorvoer vertegenwoordigen waarin u klassieke bestandsshares of andere opslagbronnen kunt implementeren, afhankelijk van het type opslagaccount. Alle opslagresources die in een opslagaccount worden geïmplementeerd, delen de limieten die van toepassing zijn op dat opslagaccount. Klassieke bestandsshares ondersteunen zowel de protocollen voor het delen van SMB- als NFS-bestanden.

• Bestandsshares (preview), aangeboden door de Microsoft.FileShares resourceprovider. Bestandsshares zijn een nieuwe resource op het hoogste niveau die de implementatie van Azure Files vereenvoudigt door de noodzaak van een opslagaccount te elimineren. In tegenstelling tot klassieke bestandsshares, die moeten worden geïmplementeerd in een opslagaccount, worden bestandsshares rechtstreeks geïmplementeerd in de resourcegroep, zoals opslagaccounts zelf of andere Azure-resources, zoals virtuele machines, schijven of virtuele netwerken. Microsoft.FileShares Momenteel ondersteunt alleen het NFS-protocol voor het delen van bestanden. Als u SMB nodig hebt, kiest u klassieke bestandsshares.

Deze video biedt een uitgebreid overzicht van de verschillen tussen het opslagaccount en beheermodellen voor bestandsshares:

Klassieke bestandsshares (Microsoft.Storage)

Klassieke bestandsshares of bestandsshares die zijn geïmplementeerd in opslagaccounts, zijn de traditionele manier om bestandsshares voor Azure Files te implementeren. Ze ondersteunen alle belangrijke functies die Azure Files ondersteunt, waaronder SMB- en NFS-, SSD- en HDD-medialagen, elk redundantietype en in elke regio. Hoewel klassieke bestandsshares de volledige breedte van Azure Files-functies ondersteunen, hebben ze belangrijke beperkingen:

• Capaciteitsplanning: klassieke bestandsshares, evenals de onderliggende objecten, zoals blobcontainers die zich in hetzelfde opslagaccount bevinden, delen een gemeenschappelijke opslaggroep, IOPS en doorvoer. Dit betekent dat het plaatsen van meerdere klassieke bestandsshares in een opslagaccount planning vereist om capaciteitsknelpunten te voorkomen. Bij het plannen van klassieke bestandsshares moet u rekening houden met de huidige en toekomstige behoeften van elke klassieke bestandsshare die in een opslagaccount is geplaatst, omdat de groei van één klassieke bestandsshare andere bestandsshares kan verdringen.

• Gedeelde instellingen: veel belangrijke instellingen, zoals netwerk- en beveiligingsregels, worden toegepast op het niveau van het opslagaccount. Als gevolg hiervan vereist het zorgvuldige overweging om klassieke bestandsshares in hetzelfde opslagaccount te plaatsen. Houd er rekening mee dat het opslagaccount een vertrouwensgrens is en alleen klassieke bestandsshares in hetzelfde opslagaccount plaatst als u hiermee dezelfde beveiligingsinstellingen hebt.

• Complexiteit schalen: grootschalige Azure Files-implementaties kunnen vereisen dat veel Azure-abonnementen worden beheerd vanwege de beperkingen voor opslagaccounts van de Microsoft.Storage resourceprovider. Zie limieten voor opslagaccounts voor meer informatie.

Er zijn twee soorten opslagaccounts die worden gebruikt voor klassieke bestandsshare-implementaties:

• Ingerichte opslagaccounts: Ingerichte opslagaccounts worden onderscheiden met behulp van het FileStorage type opslagaccount. Met ingerichte opslagaccounts kunt u ingerichte klassieke bestandsshares implementeren op SSD- of HDD-hardware. Ingerichte opslagaccounts kunnen alleen worden gebruikt voor het opslaan van klassieke bestandsshares en kunnen geen andere opslagbronnen gebruiken, zoals blobcontainers, wachtrijen en tabellen. Het is raadzaam om ingerichte opslagaccounts te gebruiken voor alle nieuwe klassieke bestandsshareimplementaties.
• Opslagaccounts voor betalen per gebruik: Opslagaccounts voor betalen per gebruik worden onderscheiden met behulp van het StorageV2 opslagaccounttype. Met opslagaccounts voor betalen per gebruik kunt u betalen per gebruik bestandsshares implementeren op HDD-gebaseerde hardware. Opslagaccounts voor betalen per gebruik kunnen worden gebruikt voor het opslaan van klassieke bestandsshares en andere opslagbronnen, zoals blobcontainers, wachtrijen of tabellen.

Zie Een klassieke bestandsshare maken voor meer informatie.

Bestandsshares (Microsoft.FileShares)

Bestandsshares (preview) zijn een nieuwe Azure-resource op het hoogste niveau die wordt geleverd door de Microsoft.FileShares resourceprovider. Deze bestandsshares bieden de volgende voordelen ten opzichte van klassieke bestandsshares:

• Vereenvoudigd beheer: bestandsshares worden rechtstreeks gemaakt als resources op het hoogste niveau in Azure Portal of via beheer-API's. Hierdoor wordt de vereiste voor het beheren van een opslagaccount verwijderd en wordt de implementatie-ervaring gestroomlijnd.

• Onafhankelijke capaciteit en prestaties: elke bestandsshare heeft een eigen toegewezen opslag, IOPS en doorvoer. Hierdoor hoeft u geen capaciteitsplanning uit te voeren voor de beperkte resources van uw opslagaccount en kunt u bestandsshares vrij laten groeien naarmate de werkbelasting toeneemt.

• Gedetailleerde configuratie: Netwerk- en beveiligingsinstellingen worden toegepast op bestandsshareniveau, zodat u nauwkeurig de toegangsgrenzen en isolatie kunt beheren. Hierdoor kunt u eenvoudiger beveiligingsbeleid afdwingen voor specifieke apps, teams of omgevingen.

• Voorspelbare, flexibele facturering: bestandsshares maken gebruik van het ingerichte v2-factureringsmodel, waarmee u onafhankelijk opslag, IOPS en doorvoer per share kunt inrichten. Omdat facturering in Azure wordt uitgevoerd per Azure-resource op het hoogste niveau, kunt u hiermee eenvoudig de kosten van elke afzonderlijke share bijhouden voor kostentoewijzing aan het project, team of de klant die de bestandsshare gebruikt.

• Verbeterde schaal en prestaties: bestandsshares ondersteunen hogere limieten en lagere implementatietijden dan klassieke bestandsshares. Zie Azure Files-schaalbaarheids- en prestatiedoelen voor meer informatie.

Regionale beschikbaarheid

Momenteel is het maken van een bestandsshare met Microsoft.FileShares (preview) beschikbaar in de volgende regio's. Ondersteuning voor privé-eindpunten voor bestandsshares met Microsoft.FileShares (preview) is beschikbaar in alle openbare Azure-cloudregio's.

• Australia East
• Centraal Australië
• Australia Southeast
• Oost-Azië
• East US
• Duitsland - noord
• Zuid-Korea
• Zuidoost-Azië
• Europa - noord
• Zuid-Afrika West
• South India
• UAE Central

Resourceproviders vergelijken: Microsoft.Storage versus Microsoft.FileShares

Functie	Klassieke	Bestandsshares (Microsoft.FileShares)
Ondersteuningsgarantie	Algemeen beschikbaar	Openbare preview
Resource op het hoogste niveau voor de service	van opslagaccount
SMB-protocol
NFS-protocol
Ondersteuning voor File Sync
Opslagaccount vereisen
Factureringsmodel betalen per gebruik
Ingericht v1-factureringsmodel
Ingericht v2-factureringsmodel
HDD-ondersteuning
Ondersteuning voor SSD
LRS
ZRS
GRS
GZRS
Facturerings-, netwerk- en beveiligingsconfiguraties per shareniveau
Configuraties van één vnet voor een bestandsshare
Configuratie van één vnet voor meerdere bestandsshares
AKS CSI-stuurprogramma
REST API's voor gegevensvlak

Beschikbare protocollen

Azure Files biedt twee industriestandaard bestandssysteemprotocollen voor het koppelen van Azure-bestandsshares: het SMB-protocol (Server Message Block) en het NFS-protocol (Network File System), zodat u het protocol kunt kiezen dat het meest geschikt is voor uw workload. Azure-bestandsshares bieden geen ondersteuning voor zowel de SMB- als NFS-protocollen op dezelfde bestandsshare, hoewel u SMB- en NFS Azure-bestandsshares binnen hetzelfde opslagaccount kunt maken.

Met zowel SMB- als NFS-bestandsshares biedt Azure Files hoogwaardige bestandsshares die omhoog kunnen worden geschaald om te voldoen aan uw opslagbehoeften en gelijktijdig toegankelijk zijn voor duizenden clients.

Identiteit

Voor toegang tot een Azure-bestandsshare moet de gebruiker worden geverifieerd en gemachtigd om toegang te krijgen tot de share. In bijna alle gevallen raden we u aan om verificatie op basis van identiteit te gebruiken in plaats van de sleutel van het opslagaccount voor toegang tot SMB Azure-bestandsshares.

Azure Files ondersteunt de volgende verificatiemethoden voor SMB-shares:

• On-premises Active Directory-domeindiensten (AD DS of on-premises AD DS): Azure-opslagaccounts kunnen worden gekoppeld aan een door de klant beheerde Active Directory-domeindiensten, net als een Windows Server-bestandsserver of NAS-apparaat. U kunt een domeincontroller on-premises, in een Azure-VM of zelfs als een VM in een andere cloudprovider implementeren; Azure Files is agnostisch voor de locatie waar uw domeincontroller wordt gehost. Zodra een opslagaccount lid is van een domein, kan de eindgebruiker een bestandsshare koppelen aan het gebruikersaccount waarmee hij of zij zich heeft aangemeld bij zijn pc. Verificatie op basis van AD maakt gebruik van het Kerberos-verificatieprotocol.
• Microsoft Entra Domain Services: Microsoft Entra Domain Services biedt een door Microsoft beheerde domeincontroller die kan worden gebruikt voor Azure-resources. Domein dat uw opslagaccount aan Microsoft Entra Domain Services voegt, biedt vergelijkbare voordelen als het domein dat deelneemt aan een AD DS die eigendom is van de klant. Deze implementatieoptie is het handigst voor lift-and-shift-scenario's van toepassingen waarvoor ad-machtigingen zijn vereist. Omdat Microsoft Entra Domain Services ad-gebaseerde verificatie biedt, maakt deze optie ook gebruik van het Kerberos-verificatieprotocol.
• Microsoft Entra Kerberos: Met Microsoft Entra Kerberos kunt u Microsoft Entra ID gebruiken om hybride of cloudidentiteiten te verifiëren (preview). Deze configuratie gebruikt Microsoft Entra ID om Kerberos-tickets uit te geven voor toegang tot de bestandsshare met het SMB-protocol. Dit betekent dat uw eindgebruikers via internet toegang hebben tot Azure-bestandsshares via Microsoft Entra hybrid en aan Microsoft Entra gekoppelde VM's.
• Active Directory-verificatie via SMB voor Linux-clients: Azure Files ondersteunt verificatie op basis van identiteiten via SMB voor Linux-clients met behulp van het Kerberos-verificatieprotocol via AD DS of Microsoft Entra Domain Services.
• Azure Storage-accountsleutel: Hoewel het om veiligheidsredenen niet wordt aanbevolen, kunt u ook Azure-bestandsshares koppelen met behulp van een Azure-opslagaccountsleutel in plaats van een identiteit te gebruiken. Als u een bestandsshare wilt koppelen met behulp van de sleutel van het opslagaccount, wordt de naam van het opslagaccount gebruikt als gebruikersnaam en wordt de sleutel van het opslagaccount gebruikt als wachtwoord. Het gebruik van de sleutel van het opslagaccount om de Azure-bestandsshare te koppelen, is effectief een beheerdersbewerking, omdat de gekoppelde bestandsshare volledige machtigingen heeft voor alle bestanden en mappen op de share, zelfs als ze ACL's hebben. Wanneer u de sleutel van het opslagaccount gebruikt om te koppelen via SMB, wordt het NTLMv2-verificatieprotocol gebruikt. Als u de sleutel van het opslagaccount moet gebruiken, raden we u aan privé-eindpunten of service-eindpunten te gebruiken, zoals beschreven in de sectie Netwerken .

Voor klanten die migreren van on-premises bestandsservers of het maken van nieuwe bestandsshares in Azure Files die bedoeld zijn om zich te gedragen als Windows-bestandsservers of NAS-apparaten, raden we u aan uw opslagaccount toe te voegen aan de AD DS van de klant. Zie Overzicht : on-premises AD DS-verificatie via SMB voor Azure-bestandsshares voor meer informatie.

Netwerken

Voor het rechtstreeks koppelen van uw Azure-bestandsshare moet u vaak nadenken over de netwerkconfiguratie, omdat:

• De poort die SMB-bestandsshares gebruiken voor communicatie, poort 445, wordt vaak geblokkeerd door veel organisaties en internetproviders (ISP's) voor uitgaand (internet) verkeer.
• NFS-bestandsshares zijn afhankelijk van verificatie op netwerkniveau en zijn daarom alleen toegankelijk via beperkte netwerken. Voor het gebruik van een NFS-bestandsshare is altijd een netwerkconfiguratie vereist.

Voor het configureren van netwerken biedt Azure Files een openbaar interneteindpunt en integratie met Azure-netwerkfuncties zoals service-eindpunten, waarmee het openbare eindpunt wordt beperkt tot opgegeven virtuele netwerken en privé-eindpunten, waardoor uw opslagaccount een privé-IP-adres krijgt vanuit een IP-adresruimte van een virtueel netwerk. Hoewel er geen extra kosten in rekening worden gebracht voor het gebruik van openbare eindpunten of service-eindpunten, gelden standaardgegevensverwerkingstarieven voor privé-eindpunten.

Dit betekent dat u rekening moet houden met de volgende netwerkconfiguraties:

• Als het vereiste protocol SMB is en alle toegang via SMB afkomstig is van clients in Azure, is er geen speciale netwerkconfiguratie vereist.
• Als het vereiste protocol SMB is en de toegang afkomstig is van clients on-premises, is een VPN- of ExpressRoute-verbinding van on-premises naar uw Azure-netwerk vereist, waarbij Azure Files beschikbaar is in uw interne netwerk met behulp van privé-eindpunten.
• Als het vereiste protocol NFS is, kunt u service-eindpunten of privé-eindpunten gebruiken om het netwerk te beperken tot opgegeven virtuele netwerken. Als u een statisch IP-adres nodig hebt en/of uw workload hoge beschikbaarheid vereist, gebruikt u een privé-eindpunt. Bij service-eindpunten kan een zeldzame gebeurtenis, zoals een zonegebonden storing, ertoe leiden dat het onderliggende IP-adres van het opslagaccount wordt gewijzigd. Hoewel de gegevens nog steeds beschikbaar zijn op de bestandsshare, moet de client de share opnieuw koppelen.

Zie Aandachtspunten voor Azure Files-netwerken voor meer informatie over het configureren van netwerken voor Azure Files.

Naast rechtstreeks verbinding maken met de bestandsshare via het openbare eindpunt of via een VPN/ExpressRoute-verbinding met een privé-eindpunt, biedt SMB een extra clienttoegangsstrategie: SMB via QUIC. SMB via QUIC biedt zero-config 'SMB VPN' voor SMB-toegang via het QUIC-transportprotocol. Hoewel Azure Files SMB niet rechtstreeks ondersteunt via QUIC, kunt u een lichtgewicht cache van uw Azure-bestandsshares maken op een Virtuele Machine met Windows Server 2022 Azure Edition met behulp van Azure File Sync. Zie SMB via QUIC met Azure File Sync voor meer informatie over deze optie.

Versleuteling

Azure Files ondersteunt twee verschillende typen versleuteling:

• Versleuteling tijdens overdracht, die betrekking heeft op de versleuteling die wordt gebruikt bij het koppelen/openen van de Azure-bestandsshare
• Versleuteling in rust, die betrekking heeft op de wijze waarop de gegevens worden versleuteld wanneer ze op schijf worden opgeslagen

Versleuteling tijdens transport

Standaard is versleuteling in-transit ingeschakeld voor alle Azure-opslagaccounts. Dit betekent dat wanneer u een bestandsshare koppelt via SMB of deze opent via het FileREST-protocol (zoals via Azure Portal, PowerShell/CLI of Azure SDK's), Azure Files alleen de verbinding toestaat als deze is gemaakt met SMB 3.x met versleuteling of HTTPS. Clients die geen ondersteuning bieden voor SMB 3.x of clients die SMB 3.x ondersteunen, maar geen SMB-versleuteling, kunnen de Azure-bestandsshare niet koppelen als versleuteling tijdens overdracht is ingeschakeld. Zie onze documentatie voor Windows, macOS en Linux voor meer informatie over welke besturingssystemen SMB 3.x ondersteunen met versleuteling. Alle huidige versies van PowerShell, CLI en SDK's ondersteunen HTTPS.

U kunt versleuteling in transit uitschakelen voor een Azure-opslagaccount. Wanneer versleuteling is uitgeschakeld, staat Azure Files SMB 2.1 en SMB 3.x zonder versleuteling en niet-versleutelde FileREST API-aanroepen via HTTP toe. De primaire reden voor het uitschakelen van versleuteling tijdens overdracht is het ondersteunen van een verouderde toepassing die moet worden uitgevoerd op een ouder besturingssysteem, zoals Windows Server 2008 R2 of een oudere Linux-distributie. Azure Files staat alleen SMB 2.1-verbindingen toe binnen dezelfde Azure-regio als de Azure-bestandsshare; een SMB 2.1-client buiten de Azure-regio van de Azure-bestandsshare, zoals on-premises of in een andere Azure-regio, heeft geen toegang tot de bestandsshare.

We raden u ten zeerste aan ervoor te zorgen dat versleuteling van gegevens in transit is ingeschakeld.

Zie voor meer informatie over versleuteling tijdens overdracht vereisten voor veilige overdracht in Azure Storage en Versleuteling tijdens overdracht voor NFS Azure-bestandsshares.

Versleuteling in rusttoestand

Alle gegevens die zijn opgeslagen in Azure Files, worden in rust versleuteld via SSE (Azure Storage Service-Side Encryption). SSE werkt op dezelfde manier als BitLocker in Windows: gegevens worden versleuteld onder het bestandssysteemniveau.

Omdat gegevens worden versleuteld onder het bestandssysteem van de Azure-bestandsshare, omdat deze zijn gecodeerd op schijf, hebt u geen toegang nodig tot de onderliggende sleutel op de client om naar de Azure-bestandsshare te lezen of schrijven. Inactieve versleuteling geldt voor zowel SMB- als NFS-protocollen.

Standaard worden gegevens die zijn opgeslagen in Azure Files versleuteld met door Microsoft beheerde sleutels. Met door Microsoft beheerde sleutels bevat Microsoft de sleutels voor het versleutelen en ontsleutelen van de gegevens. Microsoft is verantwoordelijk voor het regelmatig roteren van deze sleutels.

U kunt er ook voor kiezen om uw eigen sleutels te beheren. Dit geeft u controle over het roulatieproces. Als u ervoor kiest om uw bestandsshares te versleutelen met door de klant beheerde sleutels, is Azure Files gemachtigd om toegang te krijgen tot uw sleutels om te voldoen aan lees- en schrijfaanvragen van uw klanten. Met door de klant beheerde sleutels kunt u deze autorisatie op elk gewenst moment intrekken. Maar zonder deze autorisatie is uw Azure-bestandsshare niet meer toegankelijk via SMB of de FileREST-API.

Azure Files maakt gebruik van hetzelfde versleutelingsschema als de andere Azure Storage-services, zoals Azure Blob Storage. Zie Azure Storage-versleuteling voor data-at-rest voor meer informatie over Azure Storage SSE.

Gegevensbescherming

Azure Files heeft een benadering met meerdere lagen om ervoor te zorgen dat er een back-up van uw gegevens wordt gemaakt, kan worden hersteld en beveiligd tegen beveiligingsrisico's. Zie het overzicht van Azure Files-gegevensbeveiliging.

Zacht verwijderen

Voorlopig verwijderen is een instelling op opslagaccountniveau waarmee u uw bestandsshare kunt herstellen wanneer deze per ongeluk wordt verwijderd. Wanneer een bestandsshare wordt verwijderd, wordt deze overgezet naar een voorlopig verwijderde status in plaats van permanent te worden gewist. U kunt configureren hoe lang voorlopig verwijderde shares kunnen worden hersteld voordat ze permanent worden verwijderd en de share op elk gewenst moment tijdens deze bewaarperiode ongedaan maken.

Voorlopig verwijderen is standaard ingeschakeld voor nieuwe opslagaccounts. Als u een werkstroom hebt waarin het verwijderen van delen gebruikelijk is en verwacht, kunt u besluiten om een korte bewaarperiode te hebben of voorlopig verwijderen helemaal niet ingeschakeld te hebben.

Voor meer informatie over voorlopig verwijderen, zie Onopzettelijke gegevensverwijdering voorkomen.

Back-up

U kunt een back-up maken van uw Azure-bestandsshare via share snapshots, die read-only point-in-time kopieën van uw share zijn. Momentopnamen zijn incrementeel, wat betekent dat ze alleen zoveel gegevens bevatten als sinds de vorige momentopname is gewijzigd. U kunt maximaal 200 momentopnamen per bestandsshare hebben en ze maximaal 10 jaar bewaren. U kunt handmatig momentopnamen maken in Azure Portal, via PowerShell of opdrachtregelinterface (CLI), of u kunt Azure Backup gebruiken.

Azure Backup voor Azure-bestandsshares verwerkt de planning en retentie van momentopnamen. De mogelijkheden van grootvader-vader-zoon (GFS) betekenen dat u dagelijkse, wekelijkse, maandelijkse en jaarlijkse momentopnamen kunt maken, elk met een eigen afzonderlijke bewaarperiode. Azure Backup coördineert ook het inschakelen van soft delete en neemt een verwijdervergrendeling op een opslagaccount zodra een bestandsdeling binnen dit account is geconfigureerd voor back-up. Ten slotte biedt Azure Backup bepaalde belangrijke bewakings- en waarschuwingsmogelijkheden waarmee klanten een geconsolideerde weergave van hun back-upomgeving kunnen hebben.

U kunt herstelbewerkingen op item- en shareniveau uitvoeren in Azure Portal met behulp van Azure Backup. U hoeft alleen het herstelpunt (een bepaalde momentopname) te kiezen, het specifieke bestand of de map, indien relevant, en vervolgens de locatie (oorspronkelijk of alternatief) waarnaar u wilt herstellen. De back-upservice verwerkt het kopiëren van de momentopnamegegevens en toont uw herstelvoortgang in de portal.

Azure Files beveiligen met Microsoft Defender for Storage

Microsoft Defender for Storage is een systeemeigen beveiligingslaag van Azure waarmee potentiële bedreigingen voor uw opslagaccounts worden gedetecteerd. Het biedt uitgebreide beveiliging door de telemetrie van het gegevensvlak en het besturingsvlak te analyseren die worden gegenereerd door Azure Files. Het maakt gebruik van geavanceerde mogelijkheden voor detectie van bedreigingen die worden mogelijk gemaakt door Microsoft Threat Intelligence om contextuele beveiligingswaarschuwingen te bieden, inclusief stappen om de gedetecteerde bedreigingen te beperken en toekomstige aanvallen te voorkomen.

Defender for Storage analyseert continu de telemetriestroom die door Azure Files wordt gegenereerd. Wanneer mogelijk schadelijke activiteiten worden gedetecteerd, worden beveiligingswaarschuwingen gegenereerd. Deze waarschuwingen worden weergegeven in Microsoft Defender voor Cloud, samen met de details van de verdachte activiteit, onderzoeksstappen, herstelacties en beveiligingsaanbeveling.

Defender for Storage detecteert bekende malware, zoals ransomware, virussen, spyware en andere malware die is geüpload naar een opslagaccount op basis van volledige bestands-hash (alleen ondersteund voor REST API). Dit helpt voorkomen dat malware de organisatie binnenkomt en zich verspreidt naar meer gebruikers en resources. Zie Inzicht in de verschillen tussen malwarescans en hashreputatieanalyse.

Defender for Storage heeft geen toegang tot de gegevens van het opslagaccount en heeft geen invloed op de prestaties. U kunt Microsoft Defender for Storage inschakelen op abonnementsniveau (aanbevolen) of op resourceniveau.

Opslagniveaus

Azure Files biedt twee medialagen van opslag: SSD (solid-state disk) en harde schijf (HDD). Met deze lagen kunt u uw shares aanpassen aan de prestatie- en prijsvereisten van uw scenario:

• SSD (premium): SSD-bestandsshares bieden consistente hoge prestaties en lage latentie, binnen milliseconden met één cijfer voor de meeste I/O-bewerkingen, voor I/O-intensieve workloads. SSD-bestandsshares zijn geschikt voor een groot aantal workloads, zoals databases, websitehosting en ontwikkelomgevingen.

  U kunt SSD-bestandsshares gebruiken met zowel de SMB- als NFS-protocollen. SSD-bestandsshares zijn beschikbaar in de ingerichte v2 - en ingerichte v1-factureringsmodellen . SSD-bestandsshares bieden een SLA met een hogere beschikbaarheid dan HDD-bestandsshares.

• HDD (standaard): HDD-bestandsshares bieden een rendabele opslagoptie voor bestandsshares voor algemeen gebruik. HDD-bestandsshares zijn beschikbaar met de ingerichte v2 - en betalen per gebruik-factureringsmodellen , hoewel we het ingerichte v2-model aanbevelen voor nieuwe implementaties van bestandsshares. Zie de Azure SLA-pagina voor onlineservices voor informatie over de SLA.

Wanneer u een medialaag voor uw workload selecteert, moet u rekening houden met uw prestatie- en gebruiksvereisten. Als voor uw workload latentie van één cijfer is vereist of als u on-premises SSD-opslagmedia gebruikt, zijn SSD-bestandsshares waarschijnlijk het meest geschikt. Als lage latentie niet zo belangrijk is, zijn HDD-bestandsshares mogelijk beter geschikt vanuit kostenperspectief. Lage latentie kan bijvoorbeeld minder zorgen hebben over teamshares die on-premises zijn gekoppeld vanuit Azure of on-premises in de cache zijn opgeslagen via Azure File Sync.

Nadat u een bestandsshare in een opslagaccount hebt gemaakt, kunt u deze niet rechtstreeks verplaatsen naar een andere medialaag. Als u bijvoorbeeld een HDD-bestandsshare naar de SSD-medialaag wilt verplaatsen, moet u een nieuwe SSD-bestandsshare maken en de gegevens van de oorspronkelijke share naar de nieuwe bestandsshare kopiëren.

Meer informatie over de SSD- en HDD-medialagen vindt u in De factureringsmodellen van Azure Files en inzicht in en optimalisatie van de prestaties van Azure-bestandsshares.

Redundantie

Om gegevens in uw Azure-bestandsshares te beschermen tegen gegevensverlies of beschadiging, worden in Azure Files meerdere kopieën van elk bestand opgeslagen terwijl ze worden geschreven. Afhankelijk van uw vereisten kunt u de mate van redundantie selecteren. Azure Files ondersteunt momenteel de volgende opties voor gegevensredundantie:

• Lokaal redundante opslag (LRS): met lokale redundantie wordt elk bestand drie keer opgeslagen in een Azure-opslagcluster. Deze aanpak helpt u te beschermen tegen gegevensverlies als gevolg van hardwarefouten, zoals een ongeldig schijfstation. Als er echter een noodgeval optreedt, zoals brand of overstromingen in het datacenter, kunnen alle replica's van een opslagaccount dat gebruikmaakt van LRS verloren gaan of onherstelbaar zijn.

• Zone-redundante opslag (ZRS): Met zoneredundantie worden drie kopieën van elk bestand opgeslagen. Deze kopieën worden echter fysiek geïsoleerd in drie afzonderlijke opslagclusters in Azure-beschikbaarheidszones. Beschikbaarheidszones zijn unieke fysieke locaties in een Azure-regio. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke stroomvoorziening, koeling en netwerken. Een schrijfbewerking naar de opslag wordt pas geaccepteerd wanneer deze is uitgevoerd naar opslagclusters in alle drie de beschikbaarheidszones.

• Geografisch redundante opslag (GRS): Met georedundantie hebt u een primaire regio en een secundaire regio. Bestanden worden drie keer opgeslagen in een Azure-opslagcluster in de primaire regio. Schrijfbewerkingen worden asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio.

  Georedundantie biedt zes kopieën van uw gegevens verspreid over de twee Azure-regio's. Als er een grote ramp optreedt, zoals het permanente verlies van een Azure-regio vanwege een natuurramp of een andere soortgelijke gebeurtenis, voert Microsoft een failover uit. In dit geval wordt de secundaire de primaire en dient alle bewerkingen.

  Omdat de replicatie tussen de primaire en secundaire regio's asynchroon is, gaan gegevens die nog niet zijn gerepliceerd naar de secundaire regio verloren als er een grote noodgeval optreedt. U kunt ook een handmatige failover uitvoeren van een geografisch redundante opslagaccount.

• Geografisch zone-redundante opslag (GZRS):met redundantie op geo-zone worden bestanden drie keer opgeslagen in drie afzonderlijke opslagclusters in de primaire regio. Alle schrijfbewerkingen worden vervolgens asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio. Het failoverproces voor geozoneredundantie werkt hetzelfde als voor geo-redundantie.

HDD-bestandsshares ondersteunen alle vier de redundantietypen. SSD-bestandsshares ondersteunen alleen LRS en ZRS.

Opslagaccounts voor betalen per gebruik bieden twee andere redundantieopties die azure Files niet ondersteunt: geografisch redundante opslag met leestoegang (RA-GRS) en geografisch zone-redundante opslag met leestoegang (RA-GZRS). U kunt Azure-bestandsshares inrichten in opslagaccounts met deze optieset, maar Azure Files biedt geen ondersteuning voor lezen vanuit de secundaire regio. Azure-bestandsshares die zijn geïmplementeerd in RA-GRS of RA-GZRS opslagaccounts, worden respectievelijk gefactureerd als geografisch redundant of geografisch zone-redundant.

Zie Azure Files-gegevensredundantie voor meer informatie over redundantie.

Beschikbaarheid van zoneredundante SSD-bestandsshares

Zoneredundante SSD-bestandsshares zijn beschikbaar voor een subset van Azure-regio's.

Herstel na noodgevallen en overgangsfalen

In het geval van een niet-geplande regionale servicestoring moet u een noodherstelplan (DR) hebben voor uw Azure-bestandsshares. Zie Herstel na noodgevallen en failover voor Azure Files voor meer informatie over de concepten en processen die betrokken zijn bij noodgevallen en failover van opslagaccounts.

Migratie

In veel gevallen maakt u geen nieuwe net-bestandsshare voor uw organisatie, maar migreert u in plaats daarvan een bestaande bestandsshare vanaf een on-premises bestandsserver of NAS-apparaat naar Azure Files. Het kiezen van de juiste migratiestrategie en het juiste hulpprogramma is belangrijk voor het succes van uw migratie.

Zie voor SMB-migraties een overzicht van SMB-migraties met een tabel die u naar migratiehandleidingen leidt die waarschijnlijk betrekking hebben op uw scenario.

Zie Migreren naar NFS Azure-bestandsshares voor NFS-migraties.

Volgende stappen

• Een Azure File Sync-implementatie plannen
• Azure Files implementeren
• Azure File Sync implementeren