La synchronizace souborů přes SMB Stala se klíčovou součástí pro každou organizaci, která sdílí data mezi servery Windows, Linux, NAS, Azure, AWS nebo hybridními servery. Když začnete spravovat několik terabajtů, desítky souběžných uživatelů a splňujete požadavky na dodržování předpisů, pouhé „sdílení složky“ už nestačí: do hry vstupuje výkon, oprávnění NTFS a sdílení, zabezpečení protokolu a dokonce i způsob migrace těchto dat, aniž byste zastavili polovinu podnikání.
V tomto článku najdete a kompletní průvodce o tom, jak funguje SMB, jakou roli hraje Samba ve smíšených prostředích, jak posílit zabezpečení (šifrování, podpisy, verze protokolů), jaké osvědčené postupy dodržovat s oprávněními a ACL ve Windows, Azure Files, Azure NetApp Files nebo FSLogix a jak udržovat slušný výkon i když přesouváte nebo synchronizujete obrovské objemy mezi servery nebo do cloudu.
Co je SMB a proč je stále klíčový pro sdílení souborů?
Protokol Serverový blok zpráv (SMB) Je to „jazyk“ pro sdílení souborů, tiskáren a určitých síťových služeb, který systémy Windows používají nativně. Prostřednictvím protokolu SMB může klient přistupovat ke sdíleným složkám, otevírat a upravovat soubory, zobrazovat tiskárny nebo dotazovat určité zdroje, jako by byly na jeho vlastním počítači, i když se ve skutečnosti nacházejí na vzdáleném serveru.
SMB se v průběhu let vyvíjel. Každý krok přinesl vylepšení výkonu, vylepšené zabezpečení (integrované šifrování, moderní podpisy, integritu předběžného ověřování) a další funkce určené pro vysoce dostupná nebo virtualizovaná prostředí, jako je Hyper-V nebo SQL Server na souborových serverech.
Krása používání SMB spočívá v tom, že umožňuje integrovat smíšené sítě (Windows, macOS, Linux, úložná zařízení, veřejné cloudy), aniž by uživatelé museli měnit způsob své práce: nadále používají Průzkumník souborů, mapují síťové disky a Dokumenty si uchovávají jako vždy..
Bezpečnostní vrstva SMB: šifrování, podpisy a verze protokolů
Zabezpečení SMB již není volitelným doplňkem. Pokud sdílíte soubory s citlivými daty a síť není zcela důvěryhodná, potřebujete ho. šifrování a ochrana proti útokům z odposlechu (man-in-the-middle). Systémy Windows Server a Windows 10/11 obsahují v nejnovějších verzích protokolu SMB významná vylepšení zabezpečení.
El Šifrování SMB Poskytuje komplexní ochranu dat přenášených mezi klientem a serverem. Na rozdíl od řešení, jako je IPsec nebo dedikovaný hardware WAN, je šifrování SMB konfigurováno přímo nad protokolem. Lze jej použít na:
- Na úrovni sdílených zdrojů (pouze některé složky).
- Na úrovni serveru (celý souborový server).
- V samotném mapování jednotka od zákazníka.
Mezi typické scénáře, kdy má smysl jej aktivovat, patří kritická uživatelská nebo aplikační data které procházejí nekontrolovanými sítěmi (sítě WAN dodavatelů, sítě třetích stran, hybridní prostředí) nebo když používáte SMB k poskytování vysoce dostupného úložiště službám, jako je SQL Server nebo Hyper-V.
Počínaje systémy Windows Server 2022 a Windows 11 protokol SMB 3.1.1 automaticky vyjednává moderní kryptografické sady, jako například AES-256-GCM a AES-256-CCMPřestože kompatibilita s AES-128-GCM a AES-128-CCM zůstává zachována, AES-128-GCM se obvykle používá jako výchozí, protože nabízí velmi dobrou rovnováhu mezi výkonem a zabezpečením.
Navíc nyní může SMB Direct (SMB over RDMA), který je k dispozici ve vysoce výkonných prostředích, Šifrování provozu bez obětování přímého přístupu k pamětiTo snižuje dopad na výkon ve srovnání s klasickým TCP, pokud je povoleno šifrování.
Požadavky a metody pro povolení šifrování SMB
Než se vrhnete na aktivaci šifrování u všech sdílených zdrojů, je dobré si ověřit několik věcí. základní předpoklady. Abyste se vyhnuli překvapením se starými klienty nebo neobvyklými aplikacemi, zde jsou:
Zaprvé: Mějte kompatibilní verze systému Windows nebo Windows Server s SMB 3.0 nebo vyšším. A že tento protokol je povolen na straně klienta i serveru. Pro úpravu konfigurace budete navíc potřebovat administrátorská oprávnění (nebo ekvivalent) na obou koncích.
Šifrování lze povolit přes grafické rozhraní s centrem pro správu systému Windows, prostřednictvím PowerShell nebo vynucením požadavků na klienta prostřednictvím tzv. „UNC ochrany“, která umožňuje vyžadovat šifrování, i když jej server nemá ve výchozím nastavení nakonfigurováno.
Když povolíte šifrování na serveru nebo sdíleném prostředku, ve výchozím nastavení se aktivuje pouze Klienti SMB 3.0, 3.02 a 3.1.1 Mohou se připojit. Toto je záměrné opatření, které zajišťuje, že všichni klienti přistupující k tomuto zdroji tak činí šifrovaně. Starší klienti nebo klienti bez podpory SMB 3.x budou odmítnuti, pokud neuvolníte konfiguraci.
Pokud vaše prostředí zahrnuje starší systémy, které nepodporují SMB 3.x, můžete odmítnutí nešifrovaného přístupu zakázat pomocí PowerShellu s vlastností Odmítnout nešifrovaný přístup ze serveru SMB. Tím se snižuje bezpečnostní limit, proto je vhodné jej omezit.
Jak povolit šifrování SMB: Centrum pro správu, PowerShell a ochrana UNC
V mnoha případech je nejpohodlnějším způsobem správy moderního souborového serveru Centrum pro správu systému WindowsZ webového rozhraní můžete aktivovat šifrování jak na úrovni serveru, tak pro konkrétní sdílené zdroje, aniž byste to komplikovali příkazy.
Pro konkrétní sdílený zdroj jednoduše vyberte název sdílené položky Na kartě sdílení souborů vyberte možnost povolit šifrování SMB. Pokud chcete vynutit používání šifrování na celém serveru, můžete přejít do nastavení souborového serveru a nastavit šifrování SMB 3 jako povinné pro všechny klienty, čímž se odmítnou všechna připojení, která jej nepodporují.
Pokud dáváte přednost příkazovému řádku, PowerShell nabízí přehledné cmdlety, jako například Set-SmbShare, Set-SmbServerConfiguration o New-SmbShare pro vytváření a konfiguraci zdrojů se šifrováním povoleným od začátku, a také příkazy pro mapování disků vyžadujících ochranu soukromí (-RequirePrivacy) jak z PowerShellu, tak z CMD s NET USE ... /REQUIREPRIVACY.
La Ochrana UNC Přidává další vrstvu. Umožňuje nakonfigurovat klienta tak, aby přijímal pouze šifrovaná připojení ke konkrétním UNC cestám, a to i v případě, že server šifrování ve výchozím nastavení nevyžaduje. To je obzvláště užitečné pro ochranu před útoky typu zachycení v nedůvěryhodných sítích a pro zajištění soukromí firemních klientů.
Při implementaci šifrování je nutné zvážit přítomnost Akcelerátory WAN nebo zprostředkující zařízení v síti, která se spoléhají na zobrazení obsahu v prostém textu. Šifrování SMB může narušit jejich provoz a způsobit problémy s přístupem nebo výkonem.
Integrita předběžného ověřování a moderní podpis v SMB 3.x
Pro další posílení zabezpečení proti útokům na degradaci protokolu nebo manipulaci s vyjednáváním obsahuje SMB 3.1.1 tzv. integrita předchozího ověřováníTato funkce vypočítává kryptografické hashe zpráv o vyjednávání a konfiguraci relace. Z tohoto výsledku pak odvodí klíče relace a podpisu.
Díky tomuto mechanismu mohou klient a server zjistit, zda někdo manipuluje Připojení se používá například k vynucení přechodu na nešifrovaný protokol SMB 2.x. Pokud je v těchto haších zjištěna nekonzistence, relace je okamžitě ukončena.
Spolu se šifrováním se SMB vyvíjí také v oblasti podpis zprávySMB 2.0 používal HMAC-SHA256, zatímco SMB 3.0/3.02 zavedl AES-CMAC, který je lépe optimalizován pro moderní procesory podporující instrukce AES. V systémech Windows Server 2022 a Windows 11 přidal SMB 3.1.1 jako podpisový algoritmus AES-128-GMAC, což nabízí vylepšený výkon v mnoha scénářích.
Praktickou výhodou je, že nyní můžete samostatný podpis a šifrování. Pokud někdy potřebujete pouze podpis (integritu) bez šifrování, SMB to umožňuje pomocí moderních algoritmů. To vám dává flexibilitu splnit požadavky na audit i výkon.
Abyste z těchto funkcí vytěžili maximum a zabránili útočníkovi v vynucení použití SMB 1.0, je vhodné zakázat SMBv1 kompletně na moderních serverech a klientech, což je něco, co Microsoft již ve výchozím nastavení dělá v novějších verzích Windows a Windows Serveru.
Proč byste měli co nejdříve zakázat SMB 1.0
SMB 1.0 je protokol zastaralé, neefektivní a s vážnými zranitelnostmi Jedná se o známé zranitelnosti, které v posledních letech zneužívá ransomware a další typy malwaru. Proto se od některých verzí Windows 10 a Windows Serveru již standardně neinstaluje.
Pokud ve svém prostředí stále máte servery nebo počítače s povoleným protokolem SMB 1.0, prvním rozumným krokem je naplánovat jeho likvidaci. Aktuální doporučení je zakázat jej na serverech i klientech. Doporučuje se ponechávat pouze SMB 2.x a 3.x. To drasticky snižuje... útočná plocha a zabraňuje tomu, aby legitimní připojení bylo převedeno na nešifrovanou nebo špatně zabezpečenou verzi.
V prostředí Windows můžete spravovat SMB 1.0 pomocí volitelných systémových funkcí, PowerShellu nebo nástrojů pro vzdálenou správu. Je vhodné důkladně zdokumentovat, které služby na něm mohou být závislé, abyste se vyhnuli případným překvapením později.
V některých velmi specifických scénářích (například starší aktivační centra) nemusíte mít jinou možnost než udržovat SMB 1.0 v izolovaném a vysoce kontrolovaném segmentu sítě. Jedná se o velmi specifické výjimky s významnými bezpečnostními kompromisy.
Synchronizace a migrace velkých objemů SMB bez přerušení služby
Jednou z nejotravnějších výzev v reálném životě je migrace nebo synchronizovat velké adresáře SMB (mluvíme o 10 TB nebo více) z jednoho serveru na druhý nebo na jinou platformu, aniž by společnost musela několik dní nechat zapisovat do sdílených prostředků.
Klasický přístup je obvykle tento:
- Zakázat zápis do staré sdílené složky.
- Použijte nástroj jako robocopy zkopírovat veškerý obsah při zachování oprávnění NTFS.
- Nakonfigurujte nové sdílené složky na cílovém serveru.
- Aktualizovat přiřazení jednotek.
- Požádejte uživatele o restartování počítačů.
To funguje, ale má to problém, že během dlouhé kopie nikdo nemůže uložit změny do zdroje.
Na velmi velkých svazcích a pomalých discích může počáteční kopie trvat více než jeden víkendTo má přímý dopad na podnikání. Pokud necháte sdílenou složku během kopírování používat, riskujete ztrátu změn, odstranění nebo přesunů souborů provedených během migračního okna.
V těchto případech strategie zahrnuje kombinaci vícenásobné průchody s Robocopy (Nejprve hromadná kopie, poté pouze změny) a naplánovat velmi krátké finální okno, během kterého je zápis zakázán. Poté se provede inkrementální synchronizace pomocí /MIR nebo podobného parametru a přístup se přesměruje na nový server. Pro VHDX a další velmi velké soubory může být nutné naplánovat specifická okna. Nebo dokonce replikaci na úrovni úložiště, pokud to úložné pole umožňuje.
Další alternativou je migrovat po částechTo zahrnuje přesun velkých složek po fázích a jasné sdělování změn cest uživatelům. Nevýhodou je, že to často komplikuje uživatelský zážitek.
Oprávnění a seznamy ACL v SMB pro FSLogix, Azure Files a Azure NetApp Files
V moderních prostředích virtualizace desktopů nebo aplikací, jako jsou ta používaná FSLogixUživatelské profily jsou uloženy v kontejnerech VHD(X) na prostředcích SMB. Tyto prostředky mohou být umístěny na tradičních souborových serverech, v Soubory Azure, v Azure NetApp Files nebo dokonce přes brány, jako je AWS Storage Gateway.
FSLogix používá cesty UNC (VHDLocations nebo CCDLocations) k vyhledání profilu a kontejnerů Office. Zabezpečení těchto dat závisí na dvou vrstvách:
- L Oprávnění NTFS (Windows ACL) ve sdíleném zdroji.
- L oprávnění na úrovni sdílení přiřazeno identitám Entra ID v Azure Files.
V Azure Files se důrazně doporučuje nakonfigurovat výchozí oprávnění ke sdílenému zdroji typu „Spolupracovník sdílení SMB dat úložiště“ aplikovaný na všechny ověřené identity. To je nezbytné pro to, aby mohly číst a zapisovat. Pro správu podrobných seznamů ACL je určitým uživatelům nebo skupinám udělena role spolupracovníka se zvýšenými oprávněními ke sdílené složce.
Doporučeným postupem pro tyto scénáře je použití tzv. přístup založený na uživateliKaždý uživatel musí vlastnit vlastní složku profilu nebo soubor VHD(X). Správci domény a skupiny podpory mají naopak plnou kontrolu nad úlohami údržby.
Pro konfiguraci se vytvoří typické ACL, kde skupina správců domény TVŮRCE/VLASTNÍK má plnou kontrolu nad celou strukturou, má oprávnění k úpravám podsložek a souborů a skupina uživatelů domény má oprávnění k úpravám pouze kořenové složky, aby bylo možné vytvářet její adresáře.
Použití ACL systému Windows: icacls, Explorer a SIDDirSDDL ve FSLogixu
Ve Windows můžete použít nástroj příkazového řádku icacls Hromadné použití doporučených oprávnění NTFS pro sdílený prostředek, včetně kořenové složky a všech jejích podadresářů a souborů, což je velmi užitečné při přípravě sdílených složek pro FSLogix, cestovní profily nebo úložiště s více uživateli.
S icacls můžete například Zakázat dědičnost V kořenovém adresáři sdíleného prostředku udělte zvláštní oprávnění TVŮRCI/VLASTNÍKOVI, správcům domény a uživatelům domény a zajistěte, aby každá nově vytvořená složka správně zdědila tuto strukturu oprávnění.
Pokud dáváte přednost grafickému prostředí, samotnému Průzkumník Windows Umožňuje upravovat pokročilá oprávnění: zakázat dědičnost, přidat bezpečnostní principy (například TVŮRCE/VLASTNÍK, skupiny domén atd.), definovat, na co se vztahují (pouze na tuto složku, podsložky a soubory atd.) a označit úrovně oprávnění, jako například Upravit nebo Úplný přístup.
FSLogix také nabízí zajímavou možnost s názvem SIDDirSDDLTato konfigurace přijímá řetězec SDDL, který definuje ACL, jež budou automaticky použity na adresář uživatele při jeho vytvoření. Pro vygenerování tohoto řetězce se obvykle vytvoří testovací složka. V této složce se upraví oprávnění na požadovanou strukturu, soubor SDDL se extrahuje pomocí PowerShellu (Get-Acl | Select SDDL) a poté se sekce owner a creator-owner upraví tak, aby dynamicky používaly SID uživatele.
Jakmile je SIDDirSDDL nakonfigurován v zásadách FSLogix, pokaždé, když se uživatel poprvé přihlásí, bude jeho adresář vytvořen s přesná oprávnění definované v daném SDDL. Díky tomu nemusíme později opravovat ACL nebo spouštět další skripty.
Cloudové malé a střední podniky a souborové brány: Azure, AWS a hybridní úložiště
Kromě klasického on-premise souborového serveru dnes mnoho organizací používá cloudové úložné služby pro malé a střední podniky například Azure Files, Azure NetApp Files nebo hybridní řešení, která zpřístupňují SMB na okraji sítě a ukládají data v S3 nebo jiných backendech, jako je AWS Storage Gateway v režimu souborové brány.
V Azure Files je typický pracovní postup následující:
- Vytvořit Zdroj pro sdílení souborů SMB.
- Propojte jej se zdrojem identity (tradiční služba Active Directory, Azure AD Domain Services atd.).
- Přiřaďte oprávnění ke sdílení uživatelům nebo skupinám Entra ID.
- Nakonfigurujte seznamy ACL NTFS z počítače připojeného k doméně.
V Azure NetApp Files jsou kroky následující:
- Vytvořte si účet NetApp.
- Definování webů a návrh pro službu AD DS.
- Vytvořte specifické skupiny kapacity a svazků pro SMB.
- Pracuje výhradně s Oprávnění systému Windows jako by se jednalo o klasický souborový server, ale s vysoce výkonným cloudovým úložištěm.
S AWS, konzolí Úložná brána Umožňuje vytvářet sdílené složky SMB podporované na úložištích S3, definovat bránu, úložiště nebo přístupový bod, třídu úložiště, roli IAM a možnosti, jako je použití či nepoužití PrivateLink, typy šifrování nebo detekce typu MIME.
V těchto hybridních prostředích, Seznamy ACL pro SMB a NTFS SMB zůstávají základním mechanismem pro kontrolu toho, kdo vidí které soubory a s jakou úrovní oprávnění, a to i v případě, že se pod nimi používají kontejnery objektů nebo cloudové svazky. Je obzvláště důležité koordinovat zabezpečení SMB s rolemi IAM nebo jejich ekvivalenty, aby se předešlo nekonzistencím.
Kombinací všech těchto částí je možné vybudovat infrastrukturu pro synchronizaci souborů robustaBezpečné a s rozumným výkonem. I při práci s obrovskými objemy dat a komplexními hybridními prostředími.
