Beveilig uw Azure Files

Dit artikel biedt beveiligingsrichtlijnen voor Azure Files, inclusief klassieke bestandsshares die zijn gemaakt met Microsoft.Storage en bestandsshares die zijn gemaakt met Microsoft.FileShares. Het omvat de middelen waarin uw aandelen worden gehouden, klanttoegang, gegevensbescherming en operationele controles.

Beveiligingsmaatregelen hangen af van de resourceprovider en het protocol. Voor een vergelijking van de ondersteunde functies, zie Azure Files beheerconcepten.

Resource-isolatie

  • Behandel het opslagaccount als een vertrouwensgrens: Het aanmaken van aparte klassieke bestandsdelingen in hetzelfde opslagaccount isoleert niet hun netwerkregels, SMB-identiteitsbron of configuratie van encryptiesleutels. Wijzigingen in deze accountniveau-instellingen beïnvloeden alle gedeelde items in het account. Groepeer klassieke shares alleen als ze deze besturing kunnen delen. Microsoft.FileShares omzeilt deze gedeelde accountgrens door onafhankelijke netwerk- en beveiligingsconfiguraties voor elke share te bieden.

  • Bescherm clientsystemen: Een client met schrijfrechten kan bestandsgegevens wijzigen of verwijderen. Houd de besturingssystemen van de client up-to-date en beperk lokale administratieve toegang. Gebruik endpointbescherming die past bij de clientomgeving. Netwerkisolatie en encryptie voorkomen niet dat een geautoriseerde client destructieve wijzigingen aanbrengt.

Netwerkbeveiliging

Inkomende toegang en uitgaande filtering

  • Beperk inkomende toegang tot de clients die het nodig hebben: Beide resourceproviders ondersteunen private endpoints en service-endpoints met virtuele netwerkbeperkingen. Toegang tot NFS Azure-bestandsdelingen vereist een van deze paden. Klassieke SMB- en FileREST-clients kunnen ook publieke endpoints met IP-adresregels gebruiken. Voor klassieke bestandsdelingen kan met een standaard service-endpoint één IP-adresregel veel subnetten toestaan voor SMB, NFS en FileREST. Voor configuratiestappen, zie Netwerkeindpunten configureren voor Azure-bestandsshares.

  • Schakel publieke toegang uit wanneer deze niet nodig is: Publieke endpoints kunnen veilig worden gebruikt met netwerktoegangscontroles, authenticatie en encryptie die passend zijn bij het protocol. Houd publieke toegang ingeschakeld wanneer je workloads dat vereisen en je beveiligingsmodel het toestaat, ook voor verbindingen via service-endpoints. Het aanmaken van een privé-endpoint schakelt de publieke toegang niet automatisch uit. Voor klassieke shares kun je alle uitzonderingen voor vertrouwde diensten of resource-instanties controleren die effectief kunnen blijven nadat publieke toegang is uitgeschakeld. Voor meer informatie, zie Toegang tot publieke eindpunten beperken.

  • Schakel alleen toegang tot vertrouwde diensten in wanneer dat nodig is: Alleen beschikbaar voor klassieke bestandsdelingen, de instelling voor vertrouwde diensten laat ondersteunde Azure-diensten de netwerkregels van het opslagaccount omzeilen. Schakel het alleen in wanneer een integratie deze toegang nodig heeft. Deze diensten moeten nog steeds geautoriseerd zijn om toegang te krijgen tot uw bestandsgegevens.

  • Optionele filtering voor service endpoint verkeer: Wanneer clients service endpoints gebruiken om toegang te krijgen tot klassieke bestandsdelingen, kun je optioneel een service endpoint-beleid toepassen op hun subnet. Het beleid beperkt tot welke opslagaccounts die clients via service-endpoints toegang hebben, waarbij het verkeer via die service-endpoints Azure Firewall en netwerkvirtuele appliances omzeilt. Het geldt alleen voor service endpoint verkeer en filtert geen privé-endpointverkeer of andere uitgaande paden. De netwerkregels en autorisatievereisten van de bestemming blijven van toepassing. Microsoft. FileShares ondersteunt deze beleidsregels momenteel niet. Clients in een subnet met een beleidsregel moeten een privé-eindpunt gebruiken om toegang te krijgen tot Microsoft.FileShares-shares. Voor meer informatie, zie Service-endpointbeleidsregels.

  • Controleer protocolondersteuning voordat je een netwerkbeveiligingsperimeter gebruikt: Netwerkbeveiligingsperimeters zijn alleen beschikbaar voor klassieke bestandsshares. Voor klassieke shares verschilt de perimeterondersteuning per protocol en authenticatiemethode. In de Enforced mode moeten SMB- en NFS-clients in Azure virtuele netwerken verbinding maken via een privé-endpoint, of via een standaard service-endpoint met een inbound access-regel voor het IP-adres daarvan. De perimeter weigert SMB- en NFS-verkeer via service-endpoints die geen toegewezen IP-adres hebben. SMB en NFS ondersteunen geen resource-to-resource toegang tussen perimeterleden of abonnementsgebaseerde toegangsregels. Private endpoint-verkeer valt buiten perimeterhandhaving. Controleer de beperkingen voor Azure Backup en Azure File Sync voordat je een perimeter toepast. Voor meer informatie, zie Netwerkbeveiligingsperimeter.

Beveiligingsversterking van het SMB-protocol

Deze aanbevelingen gelden voor klassieke SMB-bestandsshares.

  • Vereis SMB-kanaalencryptie: Gebruik versleutelde SMB 3.x-verbindingen. SMB 2.1 ondersteunt geen kanaalencryptie. De HTTPS-eis voor FileREST vervangt de SMB-encryptieconfiguratie niet. Voor meer informatie, zie SMB-encryptie en beveiligingsinstellingen.

  • Beperk protocolversies en algoritmen tot wat je klanten nodig hebben: Gebruik het veiligste SMB-profiel dat compatibel is met je workloads. Controleer clientondersteuning voordat je SMB 3.1.1 of AES-256-GCM vereist, omdat incompatibele clients geen verbinding kunnen maken. SMB-kanaalencryptie en Kerberos-ticketversleuteling zijn aparte controles. Voor meer informatie, zie SMB-beveiligingsinstellingen.

  • Beperk SMB-authenticatiemethoden: Gebruik Kerberos voor identiteitsgebaseerde toegang. Als geen enkele client voor SMB opslagaccountsleutelauthenticatie nodig heeft, verwijder NTLMv2 na het testen uit de toegestane SMB-authenticatiemethoden. Deze controle geldt voor SMB; het schakelt sleutelgebaseerde FileREST-toegang niet uit.

  • Behoud AD DS-inloggegevens waar van toepassing: Voor AD DS-authenticatie beheer je het wachtwoord van de directoryprincipal die het opslagaccount vertegenwoordigt volgens je directorybeleid. Volg de gedocumenteerde rotatieprocedure om het directorywachtwoord en de opslagaccount Kerberos-sleutel gesynchroniseerd te houden. Voor meer informatie raadpleegt u Het wachtwoord van de identiteit van het opslagaccount bijwerken in AD DS.

NFS 4.1 bestandsdelingen

Deze aanbevelingen zijn van toepassing op NFS-bestandsdelingen met elk van beide resourceproviders. NFS gebruikt netwerkgebaseerde authenticatie en POSIX-rechten, niet SMB-identiteitsgebaseerde authenticatie.

  • Beperk de toegang tot vertrouwde netwerken: Sta alleen de subnetten en privéverbindingen toe die de werklast nodig heeft. NFS is afhankelijk van de identiteiten die door de client worden gepresenteerd, dus beheer welke systemen en beheerders die verbindingen kunnen gebruiken.

  • Beheer POSIX-rechten en clientidentiteiten: Gebruik consistente gebruikers-ID's en groeps-ID's tussen clients. Beperk bestands- en directoryrechten tot de gebruikers en groepen die toegang nodig hebben. Azure RBAC-rechten voor het beheren van de Azure-resource verlenen geen NFS-bestandstoegang. Voor meer informatie, zie NFS-authenticatie en netwerktoegang.

  • Configureer root squash waar compatibel met de werklast: Root squash wijst verzoeken van UID/GID 0 toe aan een anonieme identiteit. Het beperkt andere identiteiten niet en maakt een share niet alleen-lezen. Voor instellingen en configuratiestappen voor beide resource providers, zie Root squashing voor NFS Azure file shares.

  • Vereis encryptie tijdens transport: Beide resourceproviders ondersteunen TLS via de AZNFS-mounthulp. Microsoft.FileShares vereist standaard encryptie tijdens transport. Klassieke shares hebben NFS-encryptie-instellingen op opslagaccountniveau. Voor standaardinstellingen en configuratielinks, zie NFS-encryptie.

Identiteits- en toegangsbeheer

Azure-resourcebeheer

  • Gebruik minimale bevoegdheden voor beheertoegang: Verleen Azure RBAC-rechten op de kleinste schaal die nodig is om resources aan te maken, te configureren of te verwijderen. Voor klassieke shares kunnen accountniveau-rechten van invloed zijn op elke share in het account. Je kunt Microsoft.FileShares-resources onafhankelijk beheren. Managementrollen en toegangsrechten voor gegevens hebben verschillende doelen. Zie Azure-besturingsvlak en -gegevensvlakvoor meer informatie.

  • Beperk permanente administratieve toegang: Gebruik Microsoft Entra Privileged Identity Management waar passend voor bevoorrechte Azure rollen. Vereist goedkeuring en multifactorauthenticatie voor administratieve activatie volgens het beleid van uw organisatie. Zie Privileged Identity Management voor meer informatie.

Identiteitsgebaseerde authenticatie voor SMB-bestandsshares

SMB-identiteitsgebaseerde toegang is beschikbaar voor klassieke bestandsdelingen. Een opslagaccountsleutel geeft brede data-toegang over de shares in een account en identificeert geen individuele gebruiker.

  • Gebruik een identiteitsbron die door je clients wordt ondersteund: Azure Files ondersteunt AD DS, Microsoft Entra Domeinservices en Microsoft Entra Kerberos. Hun klant- en identiteitsvereisten verschillen. Voor ondersteunde scenario's en setup-gidsen, zie Identity-based authentication for Azure Files.

  • Gebruik beheerde identiteiten voor ondersteunde applicatieworkloads: Beheerde identiteiten kunnen SMB-toegang bieden zonder opslagrekeningsleutels te verspreiden. Controleer de reken-, client- en authenticatievereisten voor je uitrol. Zie SMB-shares openen met behulp van managed identities voor meer informatie.

  • Bescherm accountsleutels wanneer ze vereist zijn: Beperk de toestemming om sleutels op te halen of opnieuw te genereren. Sla de benodigde sleutels op in Azure Key Vault en roteer ze na de blootstelling of volgens je credentialbeleid. Plan de rotatie voor clients en integraties die nog steeds de keys gebruiken. Zie Toegangssleutels voor een opslagaccount beheren voor meer informatie.

Machtigingen op shareniveau en NTFS-machtigingen

Deze rechten zijn van toepassing op klassieke SMB-bestandsshares.

  • Wijs share-level rollen toe op de vereiste scope: Verleen lees-, schrijf- of administratieve toegang alleen aan de identiteiten die het nodig hebben. Roltoewijzingen op share-niveau voorkomen dat toegang wordt gegeven tot niet-gerelateerde shares in hetzelfde opslagaccount. Zie Machtigingen op shareniveau toewijzen voor meer informatie.

  • Pas map- en bestandsrechten toe: Gebruik Windows ACL's, ook op de rootmap van de share waar nodig, om de toegang binnen de share te controleren. Gebruik overerving om de rechten beheerbaar te houden. Zowel share-level machtigingen als Windows ACL's worden gehandhaafd. Zie Machtigingen op map- en bestandsniveau configureren voor meer informatie.

  • Beperk toestemmingsbeheer: Beperk verhoogde rollen en rechten om ACL's te wijzigen tot identiteiten die verantwoordelijk zijn voor het beheren van rechten. Bekijk zowel roltoewijzingen als geërfde ACL's wanneer de toegangsvereisten veranderen.

FileREST-toegang en SAS

FileREST-data-toegang is beschikbaar voor klassieke shares. Microsoft. FileShares ondersteunt momenteel geen FileREST-data-toegang.

  • Gebruik OAuth voor ondersteunde beheerstoegang tot gegevens: Microsoft Entra-identiteiten, inclusief beheerde identiteiten, kunnen klassieke shares via FileREST benaderen. De bevoorrechte rollen die door deze toegangsmethode worden gebruikt, kunnen bestands- en directoryrechten omzeilen, dus verleen deze alleen waar die toegang vereist is. Voor meer informatie, zie Azure Files OAuth over REST.

  • Beperk SAS-rechten en levensduur: Wanneer een ondersteund hulpmiddel een shared access signature (SAS) vereist, beperk dan de reikwijdte, de rechten en de geldigheidsperiode, en vereis HTTPS. Bescherm de SAS als referentie. SAS-tokens worden niet gebruikt om shares te mounten via SMB of NFS. Voor meer informatie, zie Gedeelde toegangshandtekeningen.

  • HTTPS vereisen voor FileREST: HTTPS beschermt REST-verzoeken tijdens het verzenden. SMB-kanaalencryptie en NFS TLS-tunneling zijn los van de HTTPS-vereiste. Voor configuratiestappen, zie FileREST-versleuteling tijdens overdracht.

Gegevensbeveiliging

  • Begrijp encryptie in rust: Beide resourceproviders versleutelen standaard bestandsgegevens in rust met door Microsoft beheerde sleutels. Versleuteling van data in rust beschermt opgeslagen gegevens; het voorkomt niet dat geautoriseerde clients bestanden lezen of wijzigen.

  • Gebruik klantbeheerde sleutels wanneer nodig: Klassieke shares ondersteunen klantbeheerde sleutels in Azure Key Vault of Managed HSM. Microsoft. FileShares ondersteunt momenteel geen door klanten beheerde sleutels. Bescherm de sleutelopslag, plan de sleutelrotatie en begrijp dat verlies van sleuteltoegang de data onbeschikbaar kan maken. Voor meer informatie, zie Customer-managed keys for Azure Files.

  • Evalueer infrastructuurencryptie voor toepasselijke klassieke implementaties: Klassieke opslagaccounts kunnen een extra encryptielaag hebben wanneer vereist door uw compliancebeleid. Deze optie wordt geselecteerd bij het aanmaken van het account en kan daarna niet worden gewijzigd. Voor ondersteunde accounttypes, zie Infrastructuurversleuteling.

  • Gebruik resource locks om beheeroperaties te beschermen: Een CanNotDelete-lock op de juiste Azure-resource of ouderscope kan verwijdering via Azure Resource Manager voorkomen. Sloten voorkomen niet dat clients bestandsgegevens wijzigen of verwijderen. Voor klassieke shares voorkomen ze ook niet dat deze via FileREST data-plane API's worden verwijderd. Voor het gedrag van de vergrendeling en operationele effecten, zie Azure-resources vergrendelen.

Back-up en herstel

  • Neem sharesnapshots op basis van herstelbehoeften: Beide resourceproviders ondersteunen share-snapshots voor het herstel van eerdere bestandsversies. Stel een schema en retentiebeleid op die aansluiten bij je hersteldoelstellingen. Share snapshots blijven gekoppeld aan de bronshare, dus ze bieden geen onafhankelijke back-up als die share permanent wordt verwijderd. Voor meer informatie, zie Momentopnamen delen voor Azure Files.

  • Schakel soft delete in voor klassieke shares: Soft delete behoudt verwijderde shares gedurende een geconfigureerde periode. Het herstelt geen individuele bestanden of afzonderlijk verwijderde snapshots. Microsoft. FileShares ondersteunt momenteel geen soft delete. Zie Onbedoeld verwijderen van Azure-bestandsshares voorkomen voor meer informatie.

  • Kies een back-upoplossing die door het protocol wordt ondersteund: Azure Backup ondersteunt klassieke SMB-shares, met opties voor snapshot en kluisback-up. Het ondersteunt momenteel geen NFS-shares met geen van beide resourceproviders. Voor NFS kies je een back-upoplossing die het protocol ondersteunt en voldoet aan je retentie- en isolatievereisten. Zie Ondersteuning voor back-ups van Azure-bestandsshares voor informatie over Azure Backup-dekking.

  • Gescheiden back-upbeheer en testherstel: Beperk wie herstelpunten kan verwijderen of retentie kan wijzigen. Test het herstellen van bestanden, machtigingen en volledige workloads. Controleer of herstel mogelijk blijft als inloggegevens voor productie of de bronshare worden gecompromitteerd.

  • Plan infrastructuurstoringen apart van dataherstel: redundantie verbetert de weerstand tegen infrastructuurstoringen, maar repliceert ook datawijzigingen. Het vervangt geen back-ups voor ongewenste wijzigingen of verwijderingen. Beschikbare redundantieopties verschillen per medialaag en resourceprovider. Zie Azure Files-redundantie voor meer informatie.

Logboekregistratie en bewaking

  • Beheerwijzigingen controleren voor beide resourceproviders: Gebruik het Azure Activity Log om het verwijderen van resources, configuratiewijzigingen en roltoewijzingen te monitoren. Bekijk wijzigingen in publieke toegang, netwerkregels, encryptievereisten en herstelcontroles. Zie Het Azure-activiteitenlogboek voor meer informatie.

  • Verzamel ondersteunde data-toegangslogboeken: Voor klassieke SMB- en FileREST-toegang gebruik je bestandsservice-resourcelogs om aanroepers, autorisatiemethoden, mislukte verzoeken en verwijderingsactiviteiten te bekijken. Verzamel de logs die vereist zijn door je retentiebeleid in Log Analytics of een andere ondersteunde bestemming. Ga er niet van uit dat je dezelfde dekking van verzoekregistratie hebt voor NFS of Microsoft.FileShares. Voor ondersteunde operaties en velden, zie Azure Files monitoring data reference.

  • Correleer waarschuwingen met client- en identiteitslogboeken: Onderzoek onverwacht sleutelgebruik, mislukte authenticatie, verwijdering van shares en wijzigingen in beveiligingsconfiguraties. Gebruik client- en directorylogs wanneer er een authenticatiefout optreedt voordat het verzoek Azure Files bereikt. Stuur meldingen door naar het team dat verantwoordelijk is voor de werklast.

  • Evalueer Defender for Storage voor klassieke implementaties: Defender for Storage biedt dreigingsdetectie voor ondersteunde opslagaccounts. Controleer de dekking van functies en protocollen voor je implementatie; accountbescherming betekent niet dat elke bestandsbewerking wordt gescand op malware. Voor meer informatie, zie Microsoft Defender for Storage.

Naleving en bestuur

  • Pas beleidsregels toe die overeenkomen met de resourceprovider: Gebruik Azure Policy om de eisen van je organisatie te controleren of af te dwingen voor ondersteunde resourcetypen en eigenschappen. Controleer de reikwijdte en effecten van elke definitie. Een beleid gericht op Microsoft.Storage-opslagaccounts evalueert Microsoft.FileShares-resources niet automatisch. Zie Azure Policy definities voor meer informatie.

  • Record-eigendom en gegevensvereisten: Gebruik resource-tags om het verantwoordelijke team, de omgeving en de dataclassificatie te identificeren. Voor klassieke shares geldt de controle op rekeningniveau voor alle shares in de rekening. Noteer uitzonderingen en bekijk deze wanneer het eigenaarschap van de werklast verandert.

  • Valideer de naleving voor de uitrol: Bevestig dat de geselecteerde dienst, regio, protocol en beschermingsfuncties aan uw eisen voldoen. Gebruik de Microsoft cloud security benchmark om controlebeoordelingen te organiseren. Voor certificeringsinformatie, zie Azure Storage compliance offerings.

Azure File Sync

Azure File Sync ondersteunt klassieke SMB-shares. Het ondersteunt geen NFS of Microsoft.FileShares. Beveilig zowel de cloudshare als de Windows Server-eindpunten.

  • Gebruik beheerde identiteiten voor ondersteunde File Sync-implementaties: Volg de beheerde identiteitsconfiguratie voor de Storage Sync Service en geregistreerde servers om de afhankelijkheid van gedeelde sleutels te verwijderen. Voor meer informatie, zie Use managed identities with Azure File Sync.

  • Beperk de beheerderstoegang tot synchronisatiebronnen en servers: Gebruik de vereiste Storage Sync-rollen op de juiste scope. Bescherm lokale bestandsrechten en serverbeheer omdat wijzigingen die via een server-endpoint worden aangebracht gesynchroniseerd kunnen worden met de cloudshare. Voor meer informatie, zie Plan een Azure File Sync-implementatie.

Volgende stappen