Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln ger säkerhetsvägledning för Azure Files, inklusive klassiska fildelningar skapade med Microsoft.Storage och fildelningar skapade med Microsoft.FileShares. Den täcker resurserna där dina aktier förvaras, kundåtkomst, dataskydd och operativa kontroller.
Säkerhetskontroller beror på resursleverantören och protokollet. För en jämförelse av stödda funktioner, se Azure Files management concepts.
Resursisolering
Behandla lagringskontot som en förtroendegräns: Att skapa separata klassiska fildelningar i samma lagringskonto isolerar inte deras nätverksregler, SMB-identitetskälla eller krypteringsnyckelkonfiguration. Ändringar i dessa kontonivåinställningar påverkar alla delningar på kontot. Gruppera klassiska resurser endast när de kan dela dessa kontroller. Microsoft.FileShares undviker denna gemensamma gräns på kontonivå genom att erbjuda oberoende nätverks- och säkerhetskonfiguration för varje resurs.
Skydda klientsystem: En klient med skrivbehörighet kan ändra eller ta bort fildata. Håll klientoperativsystemen uppdaterade och begränsa lokal administrativ åtkomst. Använd endpoint-skydd som är lämpligt för klientmiljön. Nätverksisolering och kryptering hindrar inte en auktoriserad klient från att göra destruktiva ändringar.
Nätverkssäkerhet
Inkommande åtkomst och utgående filtrering
Begränsa inkommande åtkomst till de klienter som behöver det: Båda resursleverantörerna stödjer privata slutpunkter och tjänstslutpunkter med virtuella nätverksbegränsningar. Tillgång till NFS Azure-fildelningar kräver en av dessa sökvägar. Klassiska SMB- och FileREST-klienter kan också använda publika endpoints med IP-adressregler. För klassiska fildelningar gör en standardslutpunkt för tjänst att en IP-adressregel kan omfatta många subnät för SMB, NFS och FileREST. För konfigurationssteg, se Konfigurera nätverksändpunkter för Azure-fildelningar.
Inaktivera offentlig åtkomst när den inte behövs: Publika endpoints kan användas säkert med nätverksåtkomstkontroller, autentisering och kryptering som är anpassad till protokollet. Ha offentlig åtkomst aktiverad när dina arbetsbelastningar kräver det och din säkerhetsmodell tillåter det, inklusive för anslutningar via service-endpoints. Att skapa en privat endpoint inaktiverar inte automatiskt offentlig åtkomst. För klassiska resursdelningar, granska eventuella undantag från betrodda tjänster eller resursinstanser som kan förbli effektiva efter att offentlig tillgång har inaktiverats. För mer information, se Begränsa offentlig endpoint-åtkomst.
Aktivera åtkomst till betrodda tjänster endast vid behov: Tillgänglig endast för klassiska fildelningar, gör inställningen för betrodda tjänster att Azure-tjänster som stöds kan kringgå lagringskontots nätverksregler. Aktivera det endast när en integration behöver denna åtkomst. Dessa tjänster måste fortfarande vara auktoriserade för att få tillgång till dina fildata.
Valfri filtrering för trafik till service-endpoints: När klienter använder service-endpoints för att komma åt klassiska fildelningar kan du valfritt tillämpa en service endpoint-policy på deras subnät. Policyn begränsar vilka lagringskonton dessa klienter kan nå via service-endpoints, där trafiken kringgår Azure Firewall och nätverksvirtuala enheter. Den gäller endast för trafik till tjänstslutpunkter och filtrerar inte privat slutpunktstrafik eller andra utgående vägar. Destinationens nätverksregler och auktorisationskrav gäller fortfarande. Microsoft. FileShares stöder för närvarande inte dessa policyer. Klienter i ett subnät med en policy måste använda en privat endpoint för att få tillgång till Microsoft.FileShares-delningar. För mer information, se Principer för tjänstslutpunkter.
Kontrollera protokollstöd innan du använder en nätverkssäkerhetsperimeter: Nätverkssäkerhetsperimeter finns endast för klassiska fildelningar. För klassiska resurser skiljer sig stödet för perimeter beroende på protokoll och autentiseringsmetod. I Enforced-läge måste SMB- och NFS-klienter i Azure-virtuella nätverk ansluta via en privat endpoint, eller via en standardservice-endpoint med en inkommande åtkomstregel för sin IP-adress. Perimetern nekar SMB- och NFS-trafik via tjänsteslutpunkter som inte har en tilldelad IP-adress. SMB och NFS stöder inte resurs-till-resurs-åtkomst mellan perimetermedlemmar eller prenumerationsbaserade åtkomstregler. Trafik för privat slutpunkt sker utanför perimetertillämpning. Kontrollera begränsningarna för Azure Backup och Azure File Sync innan du applicerar en perimeter. För mer information, se Nätverkssäkerhetsperimeter.
SMB-protokollhärdning
Dessa rekommendationer gäller för klassiska SMB-fildelningar.
Kräv SMB-kanalkryptering: Använd krypterade SMB 3.x-anslutningar. SMB 2.1 stöder inte kanalkryptering. HTTPS-kravet för FileREST ersätter inte SMB-krypteringskonfigurationen. För mer information, se SMB-kryptering och säkerhetsinställningar.
Begränsa protokollversioner och algoritmer till de som dina klienter behöver: Använd den mest säkra SMB-profilen som är kompatibel med dina arbetsbelastningar. Verifiera klientstöd innan du kräver SMB 3.1.1 eller AES-256-GCM, eftersom inkompatibla klienter inte kan ansluta. SMB-kanalkryptering och kryptering av Kerberos-biljetter är separata kontroller. För mer information, se SMB:s säkerhetsinställningar.
Begränsa autentiseringsmetoder för SMB: Använd Kerberos för identitetsbaserad åtkomst. Om inga klienter behöver autentisering av lagringskontonyckeln över SMB, ta bort NTLMv2 från de tillåtna SMB-autentiseringsmetoderna efter testning. Denna kontroll gäller SMB; den inaktiverar inte nyckelbaserad FileREST-åtkomst.
Behåll AD DS-inloggningsuppgifter där det är tillämpligt: För AD DS-autentisering hanterar du lösenordet för katalogobjektet som representerar lagringskontot enligt din katalogpolicy. Följ den dokumenterade rotationsproceduren för att hålla kataloglösenordet och lagringskontots Kerberos-nyckel synkroniserade. För mer information, se Uppdatera lösenordet för lagringskontots identitet i AD DS.
NFS 4.1-fildelningar
Dessa rekommendationer gäller för NFS-fildelningar med någon av de två resursleverantörerna. NFS använder nätverksbaserad autentisering och POSIX-behörigheter, inte SMB-identitetsbaserad autentisering.
Begränsa åtkomsten till betrodda nätverk: Tillåt endast de subnät och privata anslutningar som arbetsbelastningen behöver. NFS förlitar sig på de identiteter som klienten presenterar, så kontrollera vilka system och administratörer som kan använda dessa anslutningar.
Hantera POSIX-behörigheter och klientidentiteter: Använd konsekventa användar-ID:n och grupp-ID:n över klienter. Begränsa fil- och katalogbehörigheter till de användare och grupper som behöver åtkomst. Azure RBAC-behörigheter för att hantera Azure-resursen ger inte NFS-filåtkomst. För mer information, se NFS-autentisering och nätverksåtkomst.
Konfigurera root squash där den är kompatibel med arbetsbelastningen: Root squash mappar förfrågningar från UID/GID 0 till en anonym identitet. Den begränsar inte andra identiteter eller gör en delad resurs skrivskyddad. För inställningar och konfigurationssteg för båda resursleverantörerna, se Root squashing för NFS Azure-fildelningar.
Kräv kryptering under överföring: Båda resursleverantörerna stödjer TLS via AZNFS-monteringshjälparen. Microsoft.FileShares kräver kryptering under överföring som standard. Klassiska shares har NFS-krypteringsinställningar på lagringskontonivå. För standardinställningar och konfigurationslänkar, se NFS-kryptering.
Identitets- och åtkomsthantering
resurshantering i Azure
Använd minsta privilegium för hanteringsåtkomst: Ge Azure RBAC-behörigheter i minsta möjliga omfattning som behövs för att skapa, konfigurera eller ta bort resurser. För klassiska delningar kan behörigheter på kontonivå påverka varje delning i kontot. Du kan hantera Microsoft.FileShares-resurser självständigt. Hanteringsroller och behörigheter för dataåtkomst har olika syften. Mer information finns i Azure-kontrollplan och dataplan.
Begränsa ständig administrativ åtkomst: Använd Microsoft Entra Privileged Identity Management där det är lämpligt för privilegierade Azure-roller. Kräv godkännande och multifaktorautentisering för administrativ aktivering enligt din organisations policy. För mer information, se Privileged Identity Management.
Identitetsbaserad autentisering för SMB-fildelningar
SMB-identitetsbaserad åtkomst finns tillgänglig för klassiska fildelningar. En lagringskontonyckel ger bred dataåtkomst över fildelningarna i ett konto och identifierar inte en enskild användare.
Använd en identitetskälla som stöds av dina klienter: Azure Files stöder AD DS, Microsoft Entra Domain Services och Microsoft Entra Kerberos. Deras krav på kund och identitet skiljer sig åt. För stödda scenarier och installationsguider, se Identitetsbaserad autentisering för Azure Files.
Använd hanterade identiteter för stödda applikationsarbetsbelastningar: Hanterade identiteter kan ge SMB-åtkomst utan att distribuera lagringskontonycklar. Verifiera compute-, klient- och autentiseringskraven för din distribution/driftsättning. För mer information, se Access SMB shares genom att använda managed identities.
Skydda kontonycklar när de behövs: Begränsa behörighet att hämta eller generera om nycklar. Lagra nödvändiga nycklar i Azure Key Vault och rotera dem efter exponering eller enligt din autentiseringsuppgiftspolicy. Plan för rotation kring klienter och integrationer som fortfarande använder nycklarna. Mer information finns i Hantera åtkomstnycklar för lagringskonto.
Delningsnivå- och NTFS-behörigheter
Dessa behörigheter gäller för klassiska SMB-fildelningar.
Tilldela roller på resursnivå i det nödvändiga omfånget: Ge läs-, skriv- eller administrativ åtkomst endast till de identiteter som behöver det. Rolltilldelningar på delningsnivå undviker att ge tillgång till orelaterade delningar i samma lagringskonto. Mer information finns i Tilldela behörigheter på resursnivå.
Tillämpa katalog- och filbehörigheter: Använd Windows ACL:er, inklusive på delningens rotkatalog där det behövs, för att kontrollera åtkomst inom delningen. Använd arv för att hålla behörigheterna hanterbara. Både delningsnivåbehörigheter och Windows ACL tillämpas. Mer information finns i Konfigurera behörigheter på katalognivå och filnivå.
Begränsa behörighetsadministration: Begränsa roller med utökade behörigheter och rättigheter till ACL-ändringar till identiteter som ansvarar för att hantera behörigheter. Gå igenom både rolltilldelningar och ärvda ACL:er när åtkomstkraven ändras.
FileREST-åtkomst och SAS
FileREST-dataåtkomst är tillgänglig för klassiska delningar. Microsoft.FileShares stöder för närvarande inte åtkomst till FileREST-data.
Använd OAuth för stödd administrativ dataåtkomst: Microsoft Entra-identiteter, inklusive hanterade identiteter, kan komma åt klassiska delningar via FileREST. De privilegierade roller som används av denna åtkomstmetod kan kringgå fil- och katalogbehörigheter, så ge dem endast där sådan åtkomst krävs. För mer information, se Azure Files OAuth över REST.
Begränsa SAS-behörigheter och livslängd: När ett stödd verktyg kräver en shared access-signatur (SAS), begränsa dess omfattning, behörigheter och giltighetsperiod, och kräv HTTPS. Skydda SAS som en inloggningsuppgift. SAS-tokens används inte för att montera fildelningar över SMB eller NFS. För mer information, se Delade åtkomstsignaturer.
Kräv HTTPS för FileREST: HTTPS skyddar REST-förfrågningar under överföring. SMB-kanalkryptering och NFS TLS-tunnling är separata från HTTPS-kravet. För konfigurationssteg, se FileREST-kryptering vid överföring.
Dataskydd
Förstå kryptering i vila: Båda resursleverantörerna krypterar fildata i vila med Microsoft-hanterade nycklar som standard. Kryptering av data i vila skyddar lagrad data; den hindrar inte auktoriserade klienter från att läsa eller ändra filer.
Använd kundhanterade nycklar vid behov: Klassiska filresurser har stöd för kundhanterade nycklar i Azure Key Vault eller Managed HSM. Microsoft.FileShares stöder för närvarande inte kundhanterade nycklar. Skydda nyckellagringen, planera nyckelrotation och förstå att förlust av nyckelåtkomst kan göra datan otillgänglig. För mer information, se Kundhanterade nycklar för Azure Files.
Utvärdera infrastrukturkryptering för tillämpliga klassiska distributioner: Klassiska lagringskonton kan ha ett extra krypteringslager när din efterlevnadspolicy kräver det. Detta alternativ väljs vid kontoskapandet och kan inte ändras efteråt. För mer information, se Infrastrukturkryptering.
Använd resurslås för att skydda hanteringsoperationer: Ett CanNotDelete-lås på lämplig Azure-resurs eller föräldrascope kan förhindra radering via Azure Resource Manager. Lås hindrar inte klienter från att ändra eller radera fildata. För klassiska filresurser förhindrar de inte heller radering via FileREST-dataplan-API:er. För låsbeteende och operativa effekter, se Lås Azure-resurser.
Säkerhetskopiering och återställning
Ta ögonblicksbilder av fildelningar efter återställningsbehov: Båda resursleverantörerna stödjer ögonblicksbilder av fildelningar för återställning av tidigare filversioner. Sätt upp ett schema och en bevarandeprincip som uppfyller dina återhämtningsmål. Delningssnapshots förblir kopplade till källsharen, så de ger ingen oberoende backup om den sharen tas bort permanent. För mer information, se Share snapshots for Azure Files.
Aktivera mjuk borttagning för klassiska filresurser: Mjuk borttagning behåller raderade filresurser under en konfigurerad period. Den återställer inte enskilda filer eller individuellt raderade snapshots. Microsoft.FileShares stöder för närvarande inte soft delete. Mer information finns i Förhindra oavsiktlig borttagning av Azure-fildelningar.
Välj en backuplösning som stöds av protokollet: Azure Backup stöder klassiska SMB-delningar, med snapshot- och vaulted-backup-alternativ. Den stöder för närvarande inte NFS-delningar med någon av resursleverantörerna. För NFS, välj en backuplösning som stödjer protokollet och uppfyller dina krav på retention och isolering. För Azure Backup-täckning, se Stöd för säkerhetskopiering av Azure-filresurser.
Separat säkerhetskopieringsadministration och teståterställning: Begränsa vem som kan ta bort återställningspunkter eller ändra lagringstid. Testa återställningar av filer, behörigheter och kompletta arbetslaster. Verifiera att återställning är möjlig om produktionsautentiseringsuppgifter eller källutdelningen komprometteras.
Planera för infrastrukturfel separat från dataåterställning: Redundans förbättrar motståndskraften mot infrastrukturfel men replikerar också dataförändringar. Den ersätter inte säkerhetskopior vid oönskade ändringar eller borttagning. Tillgängliga redundansalternativ skiljer sig mellan medienivå och resursleverantör. För mer information, se Azure Files redundancy.
Loggning och övervakning
Granska hanteringsändringar för båda resursleverantörerna: Använd Azure Activity Log för att övervaka resursradering, konfigurationsändringar och rolltilldelningar. Granska ändringar i allmän åtkomst, nätverksregler, krypteringskrav och återställningskontroller. Mer information finns i Azure-aktivitetsloggen.
Samla in stödda dataåtkomstloggar: För klassisk SMB- och FileREST-åtkomst, använd filtjänstresursloggar för att granska anropare, auktoriseringsmetoder, misslyckade förfrågningar och raderingsaktivitet. Samla in loggarna som krävs enligt din lagringspolicy i Log Analytics eller någon annan stödd destination. Anta inte samma täckning för begäransloggning för NFS eller Microsoft.FileShares. För stödda operationer och fält, se Azure Files övervakningsdatareferens.
Korrelera varningar med klient- och identitetsloggar: Undersök oväntad nyckelanvändning, misslyckad autentisering, delningsradering och ändringar i säkerhetskonfigurationer. Använd klient- och katalogloggar när ett autentiseringsfel inträffar innan begäran når Azure Files. Skicka varningar till det team som ansvarar för arbetsbelastningen.
Utvärdera Defender for Storage för klassiska distributioner: Defender for Storage tillhandahåller hotdetektering för stödda lagringskonton. Verifiera funktions- och protokolltäckning för din driftsättning; kontoskydd innebär inte att varje filoperation skannas efter skadlig kod. För mer information, se Microsoft Defender for Storage.
Efterlevnad och styrning
Tillämpa policyer som matchar resursleverantören: Använd Azure Policy för att granska eller framtvinga organisationens krav där resurstyp och egenskaper stöds. Kontrollera omfattningen och effekterna för varje definition. En policy som riktar sig mot Microsoft.Storage-lagringskonton utvärderar inte automatiskt Microsoft.FileShares-resurser. Mer information finns i Azure Policy definitioner.
Postägarskap och datakrav: Använd resurstaggar för att identifiera ansvarigt team, miljö och dataklassificering. För klassiska delningar påverkar kontokontrollerna alla delningar i kontot. Registrera undantag och granska dem när ägarskapet för arbetsbelastningen förändras.
Validera efterlevnad för driftsättningen: Bekräfta att den valda tjänsten, regionen, protokollet och skyddsfunktionerna uppfyller dina krav. Använd Microsoft molnsäkerhetsbenchmark för att organisera kontrollgranskningar. För certifieringsinformation, se Azure Storage-erbjudanden för regelefterlevnad.
Azure File Sync
Azure File Sync stöder klassiska SMB-delningar. Den stöder inte NFS eller Microsoft.FileShares. Säkra både molndelningen och Windows Server-endpoints.
Använd hanterade identiteter för File Sync-distributioner som stöds: Följ konfigurationen för den hanterade identiteten för Storage Sync Service och registrerade servrar för att ta bort beroendet av delade nycklar. För mer information, se Använd hanterade identiteter med Azure File Sync.
Begränsa administrativ åtkomst till synkroniseringsresurser och servrar: Använd de nödvändiga Storage Sync-rollerna i rätt omfattning. Skydda lokala filbehörigheter och serveradministration eftersom ändringar som görs via en server-endpoint kan synkroniseras med molndelningen. För mer information, se Planera en Azure File Sync-distribution.