La filsynkronisering via SMB Det er blevet en kritisk komponent for enhver organisation, der deler data på tværs af Windows, Linux, NAS, Azure, AWS eller hybridservere. Når du begynder at administrere adskillige terabyte, snesevis af samtidige brugere og compliance-krav, er det ikke længere nok blot at "dele en mappe": ydeevne, NTFS- og delingstilladelser, protokolsikkerhed og endda hvordan du migrerer disse data uden at sætte halvdelen af virksomheden i stå, kommer alle i spil.
I denne artikel finder du en komplet guide om hvordan SMB fungerer, hvilken rolle Samba spiller i blandede miljøer, hvordan man styrker sikkerheden (kryptering, signaturer, protokolversioner), hvilke bedste fremgangsmåder man skal følge med tilladelser og ACL'er i Windows, Azure Files, Azure NetApp Files eller FSLogix, og hvordan opretholde en ordentlig præstation selv når du flytter eller synkroniserer store mængder mellem servere eller til skyen.
Hvad er SMB, og hvorfor er det stadig vigtigt for fildeling?
protokollen Server Message Block (SMB) Det er "sproget" til deling af filer, printere og visse netværkstjenester, som Windows-systemer bruger indbygget. Gennem SMB kan en klient få adgang til delte mapper, åbne og redigere filer, se printere eller forespørge på bestemte ressourcer, som om de var på deres egen computer, selvom de faktisk er placeret på en fjernserver.
SMB har udviklet sig gennem årene. Hvert spring har medført forbedringer af ydeevne, forbedret sikkerhed (integreret kryptering, moderne signaturer, integritet før godkendelse) og flere funktioner designet til miljøer med høj tilgængelighed eller virtualiserede miljøer såsom Hyper-V eller SQL Server på filservere.
Det smukke ved at bruge SMB er, at det giver mulighed for integrere blandede netværk (Windows, macOS, Linux, lagerenheder, offentlige clouds) uden at tvinge brugerne til at ændre den måde, de arbejder på: de fortsætter med at bruge Stifinder, tilknytte netværksdrev og De beholder deres dokumenter som altid..
SMB-sikkerhedslag: kryptering, signaturer og protokolversioner
SMB-sikkerhed er ikke længere et valgfrit ekstraudstyr. Hvis du deler filer med følsomme data, og netværket ikke er fuldstændig troværdigt, har du brug for det. kryptering og beskyttelse mod aflytningsangreb (mand-i-middle-funktionen). Windows Server og Windows 10/11 har indarbejdet betydelige sikkerhedsforbedringer i de seneste versioner af SMB-protokollen.
El SMB-kryptering Det giver end-to-end-beskyttelse af data, der bevæger sig mellem klient og server. I modsætning til løsninger som IPsec eller dedikeret WAN-hardware konfigureres SMB-kryptering direkte oven på protokollen. Det kan anvendes til:
- På niveauet for delte ressourcer (kun nogle mapper).
- På serverniveau (hele filserveren).
- I selve kortlægningen enhed fra kunden.
Typiske scenarier, hvor det giver mening at aktivere det, inkluderer kritiske bruger- eller applikationsdata der krydser ukontrollerede netværk (leverandør-WAN'er, tredjepartsnetværk, hybridmiljøer), eller når du bruger SMB til at levere meget tilgængelig lagerplads til tjenester som SQL Server eller Hyper-V.
Fra og med Windows Server 2022 og Windows 11 forhandler SMB 3.1.1 automatisk moderne kryptografiske sæt som f.eks. AES-256-GCM og AES-256-CCMSelvom kompatibilitet med AES-128-GCM og AES-128-CCM fortsat er mulig, bruges AES-128-GCM typisk som standard, fordi det tilbyder en meget god balance mellem ydeevne og sikkerhed.
Derudover kan SMB Direct (SMB over RDMA), som findes i højtydende miljøer, nu Krypter trafik uden at ofre direkte hukommelsesadgangDette reducerer påvirkningen af ydeevnen sammenlignet med klassisk TCP, når kryptering er aktiveret.
Krav og metoder til aktivering af SMB-kryptering
Før du skynder dig at aktivere kryptering på alle delte ressourcer, er det en god idé at tjekke et par ting. grundlæggende forudsætninger. For at undgå overraskelser med gamle klienter eller usædvanlige applikationer, er de her:
Først: Hav en kompatibel version af Windows eller Windows Server med SMB 3.0 eller højere. Og at denne protokol er aktiveret på både klient- og serversiden. Derudover skal du have administratorrettigheder (eller tilsvarende) i begge ender for at ændre konfigurationen.
Kryptering kan aktiveres via grafisk brugerflade med Windows Administration, via PowerShell eller ved at påtvinge klienten krav gennem såkaldt "UNC-beskyttelse", som tillader, at kryptering kræves, selvom serveren ikke har det konfigureret som standard.
Når du aktiverer kryptering på en server eller delt ressource, er det som standard kun SMB-klienter 3.0, 3.02 og 3.1.1 De kan oprette forbindelse. Dette er en bevidst foranstaltning for at sikre, at alle klienter, der tilgår denne ressource, gør det med kryptering. Ældre klienter eller dem uden SMB 3.x-understøttelse vil blive afvist, medmindre du lemper konfigurationen.
Hvis dit miljø inkluderer ældre systemer, der ikke understøtter SMB 3.x, kan du deaktivere afvisning af ukrypteret adgang ved hjælp af PowerShell med egenskaben AfvisUkrypteret Adgang fra SMB-serveren. Dette sænker sikkerhedsbarrelen, så det er tilrådeligt at begrænse den.
Sådan aktiverer du SMB-kryptering: Administrationscenter, PowerShell og UNC-beskyttelse
I mange tilfælde er den mest bekvemme måde at administrere en moderne filserver på Windows Admin CenterFra dens webgrænseflade kan du aktivere kryptering både på serverniveau og for specifikke delte ressourcer uden at komplicere tingene med kommandoer.
For en specifik delt ressource skal du blot vælge del navn I fanen Fildeling skal du vælge muligheden for at aktivere SMB-kryptering. Hvis du vil tvinge hele serveren til at bruge kryptering, kan du gå til filserverindstillingerne og indstille SMB 3-kryptering til at være obligatorisk for alle klienter og afvise alle forbindelser, der ikke understøtter det.
Hvis du foretrækker kommandolinjen, tilbyder PowerShell klare cmdlets som f.eks. Set-SmbShare, Set-SmbServerConfiguration o Ny-SmbShare at oprette og konfigurere ressourcer med kryptering aktiveret fra starten, samt kommandoer til at tilknytte drev, der kræver privatliv (-RequirePrivacy) både fra PowerShell og fra CMD med NET USE ... /REQUIREPRIVACY.
La UNC-beskyttelse Det tilføjer endnu et lag. Det giver klienten mulighed for at blive konfigureret til kun at acceptere krypterede forbindelser til specifikke UNC-stier, selvom serveren ikke kræver kryptering som standard. Dette er især nyttigt til at beskytte mod aflytningsangreb på upålidelige netværk og håndhæve privatlivets fred for virksomhedskunder.
Når du implementerer kryptering, skal du overveje tilstedeværelsen af WAN-acceleratorer eller mellemliggende enheder på netværket, der er afhængige af at se indholdet i almindelig tekst. SMB-kryptering kan forstyrre deres drift og forårsage problemer med adgang eller ydeevne.
Integritet før godkendelse og moderne signatur i SMB 3.x
For yderligere at styrke sikkerheden mod protokolforringelsesangreb eller forhandlingsmanipulation inkorporerer SMB 3.1.1 den såkaldte integriteten af forudgående autentificeringDenne funktion beregner kryptografiske hashes af sessionsforhandlings- og konfigurationsmeddelelserne. Den bruger derefter dette resultat til at udlede sessions- og signaturnøgler.
Takket være denne mekanisme kan klient og server opdage, om nogen manipulerer Forbindelsen bruges til at fremtvinge f.eks. en nedgradering til ukrypteret SMB 2.x. Hvis der registreres en uoverensstemmelse i disse hashes, lukkes sessionen øjeblikkeligt.
Udover kryptering udvikler SMB sig også inden for beskedsignaturSMB 2.0 brugte HMAC-SHA256, mens SMB 3.0/3.02 introducerede AES-CMAC, som er bedre optimeret til moderne CPU'er, der understøtter AES-instruktioner. Med Windows Server 2022 og Windows 11 tilføjede SMB 3.1.1 AES-128-GMAC som en signaturalgoritme, hvilket giver forbedret ydeevne i mange scenarier.
Den praktiske fordel er, at du nu kan separat signatur og kryptering. Hvis du nogensinde kun har brug for en signatur (integritet) uden kryptering, tillader SMB dette med moderne algoritmer. Dette giver dig fleksibiliteten til at opfylde både revisions- og ydeevnekrav.
For at få mest muligt ud af disse funktioner og forhindre en angriber i at gennemtvinge brugen af SMB 1.0, er det en god idé deaktiver SMBv1 udelukkende på moderne servere og klienter, noget som Microsoft allerede gør som standard i nyere versioner af Windows og Windows Server.
Hvorfor du bør deaktivere SMB 1.0 så hurtigt som muligt
SMB 1.0 er en protokol forældet, ineffektiv og med alvorlige sårbarheder Dette er kendte sårbarheder, der er blevet udnyttet af ransomware og andre typer malware i de senere år. Derfor er det ikke længere installeret som standard fra og med visse versioner af Windows 10 og Windows Server.
Hvis du stadig har servere eller computere med SMB 1.0 aktiveret i dit miljø, er det første fornuftige skridt at planlægge dens bortskaffelse. Den nuværende anbefaling er at deaktivere det på både servere og klienter. Det anbefales kun at vedligeholde SMB 2.x og 3.x. Dette reducerer drastisk angrebsoverflade og forhindrer, at en legitim forbindelse nedgraderes til en ukrypteret eller dårligt sikker version.
I Windows-miljøer kan du administrere SMB 1.0 ved hjælp af valgfrie systemfunktioner, PowerShell eller fjernadministrationsværktøjer. Det er tilrådeligt at dokumentere grundigt, hvilke tjenester der kan være afhængige af det, for at undgå overraskelser senere.
I nogle meget specifikke scenarier (f.eks. ældre aktiveringscentre) har du muligvis intet andet valg end at opretholde SMB 1.0 i et isoleret og stærkt kontrolleret netværkssegment. Disse er meget specifikke undtagelser med betydelige sikkerhedsmæssige kompromiser.
Synkronisering og migrering af store mængder SMB uden afbrydelse af tjenesten
En af de mest irriterende udfordringer i det virkelige liv er at migrere eller synkroniser store SMB-mapper (vi taler om 10 TB eller mere) fra én server til en anden eller til en anden platform, uden at virksomheden kan skrive til delte ressourcer i flere dage.
Den klassiske fremgangsmåde er normalt denne:
- Deaktiver skrivning til den gamle deling.
- Brug et værktøj som f.eks robocopy at kopiere alt indhold, samtidig med at NTFS-tilladelser bevares.
- Konfigurer de nye delinger på destinationsserveren.
- Opdater enhedstildelinger.
- Bed brugerne om at genstarte deres computere.
Det virker, men det har det problem, at ingen kan gemme ændringer i kildekoden under den lange kopiering.
På meget store mængder og langsomme diske kan den oprindelige kopi tage mere end én weekendDette påvirker direkte virksomheden. Hvis du lader delingen være i brug under kopiering, risikerer du at miste ændringer, sletninger eller filflytninger foretaget under migreringsvinduet.
I disse tilfælde involverer strategien en kombination af flere gennemløb med robocopy (Først en massekopiering, derefter kun ændringer) og planlæg et meget kort vindue til endelig kopiering, hvor skrivning er deaktiveret. Derefter udføres en trinvis synkronisering ved hjælp af /MIR eller lignende, og adgangen omdirigeres til den nye server. For VHDX og andre meget store filer kan det være nødvendigt at planlægge specifikke vinduer. Eller endda replikering på lagerniveau, hvis lagerarrayet tillader det.
Et andet alternativ er migrere i stykkerDette involverer flytning af store mapper i faser og tydelig kommunikation af ændringer i stier til brugerne. Ulempen er, at dette ofte komplicerer brugeroplevelsen.
Tilladelser og ACL'er i SMB til FSLogix, Azure Files og Azure NetApp Files
I moderne desktop- eller applikationsvirtualiseringsmiljøer, såsom dem der bruges FSLogixBrugerprofiler gemmes i VHD(X)-containere på SMB-ressourcer. Disse ressourcer kan findes på traditionelle filservere, i Azure Files, i Azure NetApp Files eller endda via gateways som AWS Storage Gateway.
FSLogix bruger UNC-stier (VHDLocations eller CCDLocations) til at finde profilen og Office-containerne. Sikkerheden af disse data afhænger af to lag:
- masse NTFS-tilladelser (Windows ACL) i den delte ressource.
- masse Tilladelser på delingsniveau tildelt Entra ID-identiteter i Azure Files.
I Azure Files anbefales det kraftigt at konfigurere en standardtilladelse til delte ressourcer af typen "SMB-delingssamarbejdspartner til lagringsfildata" anvendes på alle godkendte identiteter. Dette er afgørende for, at de kan læse og skrive. For at administrere detaljerede ACL'er tildeles bestemte brugere eller grupper en samarbejdspartnerrolle med forhøjede rettigheder på delingen.
Den anbefalede praksis for disse scenarier er at bruge det, der kaldes brugerbaseret adgangHver bruger skal eje sin egen profilmappe eller VHD(X)-fil. Domæneadministratorer og supportgrupper har derimod fuld kontrol over vedligeholdelsesopgaver.
For at konfigurere dette etableres typiske ACL'er, hvor domæneadministratorgruppe OPSKABEREN/EJEREN har fuld kontrol over hele strukturen, har ændringstilladelser til undermapper og filer, og domænebrugergruppen har kun ændringstilladelser til rodmappen, så dens mapper kan oprettes.
Anvend Windows ACL'er: icacls, Explorer og SIDDirSDDL i FSLogix
I Windows kan du bruge kommandolinjeværktøjet icacls At anvende anbefalede NTFS-tilladelser samlet på en delt ressource, inklusive rodmappen og alle dens undermapper og filer, hvilket er meget nyttigt, når man forbereder delinger til FSLogix, roamingprofiler eller flerbrugerlagre.
Med icacls kan du f.eks. Deaktiver nedarvning I roden af den delte ressource skal du give særlige tilladelser til OPRETTER/EJER, domæneadministratorer og domænebrugere, og sørge for, at hver ny oprettet mappe arver denne tilladelsesstruktur korrekt.
Hvis du foretrækker et grafisk miljø, så er det selve miljøet Windows File Explorer Det giver dig mulighed for at redigere avancerede tilladelser: deaktivere nedarvning, tilføje sikkerhedsprincipper (f.eks. OPSKABER/EJER, domænegrupper osv.), definere, hvad de gælder for (kun denne mappe, undermapper og filer osv.) og markere tilladelsesniveauer som f.eks. Rediger eller Fuld kontrol.
FSLogix tilbyder også en interessant mulighed kaldet SIDDirSDDLDenne konfiguration accepterer en SDDL-streng, der definerer de ACL'er, der automatisk vil blive anvendt på brugerens mappe ved oprettelse. For at generere denne streng oprettes der typisk en testmappe. I denne mappe justeres tilladelser til den ønskede struktur, SDDL'en udtrækkes ved hjælp af PowerShell (Get-Acl | Select SDDL), og derefter tilpasses ejer- og skaber-ejer-sektionerne til dynamisk at bruge brugerens SID.
Når SIDDirSDDL er konfigureret i FSLogix-politikkerne, vil en brugers mappe blive oprettet med [navn på mappe], hver gang de logger ind for første gang. de nøjagtige tilladelser defineret i den SDDL. Dette sparer os for at skulle rette ACL'er bagefter eller køre yderligere scripts.
Cloud-SMV'er og filgateways: Azure, AWS og hybridlagring
Ud over den klassiske lokale filserver bruger mange organisationer i dag Cloud-lagringstjenester for SMB'er såsom Azure Files, Azure NetApp Files eller hybridløsninger, der eksponerer SMB i kanten og gemmer data i S3 eller andre backends, såsom AWS Storage Gateway i filgateway-tilstand.
I Azure Files er den typiske arbejdsgang som følger:
- Opret en SMB-fildelingsressource.
- Link den til en identitetskilde (traditionel Active Directory, Azure AD Domain Services osv.).
- Tildel delingstilladelser til brugere eller grupper af Entra ID.
- Konfigurer NTFS ACL'er fra en domæneforbundet computer.
I Azure NetApp Files er trinnene som følger:
- Opret en NetApp-konto.
- Definition af websteder og AD DS-design.
- Opret specifikke SMB-kapacitets- og volumengrupper.
- Arbejder udelukkende med Windows-tilladelser som om det var en klassisk filserver, men bakket op af højtydende cloud-lagring.
Med AWS, konsollen for Lagringsgateway Det giver dig mulighed for at oprette SMB-fildelinger, der understøttes af S3-buckets, definere gatewayen, bucketen eller adgangspunktet, lagringsklassen, IAM-rollen og muligheder såsom brugen af PrivateLink, krypteringstyper eller MIME-typedetektion.
I disse hybride miljøer, SMB- og NTFS-ACL'er SMB'er er fortsat den grundlæggende mekanisme til at kontrollere, hvem der ser hvilke filer og med hvilket niveau af tilladelser, selv når objektbuckets eller cloud-volumener bruges nedenunder. Det er især vigtigt at koordinere SMB-sikkerhed med IAM-roller eller tilsvarende for at undgå uoverensstemmelser.
Ved at kombinere alle disse dele er det muligt at opbygge en infrastruktur til filsynkronisering robustaSikker og med rimelig ydeevne. Selv når man arbejder med store mængder og komplekse hybridmiljøer.
