La синхронизация на файлове чрез SMB Това се превърна в критичен компонент за всяка организация, която споделя данни между Windows, Linux, NAS, Azure, AWS или хибридни сървъри. Когато започнете да управлявате няколко терабайта, десетки едновременни потребители и изисквания за съответствие, просто „споделянето на папка“ вече не е достатъчно: производителността, NTFS и разрешенията за споделяне, сигурността на протокола и дори начинът, по който мигрирате тези данни, без да спирате половината бизнес, влизат в играта.
В тази статия ще намерите a пълно ръководство за това как работи SMB, каква роля играе Samba в смесени среди, как да се засили сигурността (криптиране, подписи, версии на протоколи), какви най-добри практики да се следват с разрешения и ACL в Windows, Azure Files, Azure NetApp Files или FSLogix и как поддържане на прилична производителност дори когато премествате или синхронизирате огромни обеми между сървъри или към облака.
Какво е SMB и защо все още е ключов за споделяне на файлове?
протокола Блокиране на сървърни съобщения (SMB) Това е „езикът“ за споделяне на файлове, принтери и определени мрежови услуги, който Windows системите използват оригинално. Чрез SMB клиентът може да осъществява достъп до споделени папки, да отваря и редактира файлове, да преглежда принтери или да прави заявки към определени ресурси, сякаш са на собствения му компютър, въпреки че всъщност се намират на отдалечен сървър.
SMB се е развивал през годините. Всеки скок е донесъл подобрения в производителността, подобрена сигурност (интегрирано криптиране, модерни подписи, целостност преди удостоверяване) и повече функции, предназначени за високодостъпни или виртуализирани среди, като Hyper-V или SQL Server на файлови сървъри.
Красотата на използването на SMB е, че позволява интегриране на смесени мрежи (Windows, macOS, Linux, устройства за съхранение, публични облаци), без да се принуждават потребителите да променят начина си на работа: те продължават да използват File Explorer, да свързват мрежови устройства и Те пазят документите си както винаги..
SMB защитен слой: криптиране, подписи и версии на протоколи
SMB сигурността вече не е допълнителна опция. Ако споделяте файлове с чувствителни данни и мрежата не е напълно надеждна, имате нужда от нея. криптиране и защита срещу атаки за прихващане (човек по средата). Windows Server и Windows 10/11 са включили значителни подобрения в сигурността в най-новите версии на SMB протокола.
El SMB криптиране Той осигурява цялостна защита за данните, пътуващи между клиент и сървър. За разлика от решения като IPsec или специализиран WAN хардуер, SMB криптирането се конфигурира директно върху протокола. Може да се прилага към:
- На ниво споделен ресурс (само някои папки).
- На ниво сървър (целият файлов сървър).
- В самото картографиране единица от клиента.
Типични сценарии, при които има смисъл да се активира, включват критични потребителски или приложни данни които преминават през неконтролирани мрежи (WAN мрежи на доставчици, мрежи на трети страни, хибридни среди) или когато използвате SMB, за да предоставите високодостъпно хранилище за услуги като SQL Server или Hyper-V.
Започвайки с Windows Server 2022 и Windows 11, SMB 3.1.1 автоматично договаря съвременни криптографски набори, като например AES-256-GCM и AES-256-CCMВъпреки че съвместимостта с AES-128-GCM и AES-128-CCM остава, AES-128-GCM обикновено се използва по подразбиране, защото предлага много добър баланс между производителност и сигурност.
Освен това, SMB Direct (SMB over RDMA), наличен във високопроизводителни среди, вече може Криптиране на трафика без компромис с директния достъп до паметтаТова намалява влиянието върху производителността в сравнение с класическия TCP, когато е активирано криптиране.
Изисквания и методи за активиране на SMB криптиране
Преди да се втурнете да активирате криптирането на всички споделени ресурси, е добре да проверите няколко неща. основни предпоставки. За да избегнете изненади със стари клиенти или необичайни приложения, ето ги:
Първо: Имайте съвместима версия на Windows или Windows Server с SMB 3.0 или по-нова версия. И че този протокол е активиран както от страна на клиента, така и на сървъра. Освен това ще ви трябват администраторски права (или еквивалентни) и от двете страни, за да промените конфигурацията.
Криптирането може да бъде активирано чрез графичен интерфейс с Центъра за администриране на Windows, чрез PowerShell или чрез налагане на изисквания към клиента чрез така наречената „UNC защита“, която позволява изискването за криптиране, дори ако сървърът не го е конфигурирал по подразбиране.
Когато активирате криптиране на сървър или споделен ресурс, по подразбиране само SMB клиенти 3.0, 3.02 и 3.1.1 Те могат да се свързват. Това е умишлена мярка, за да се гарантира, че всички клиенти, които имат достъп до този ресурс, го правят с криптиране. По-стари клиенти или такива без поддръжка на SMB 3.x ще бъдат отхвърлени, освен ако не разхлабите конфигурацията.
Ако вашата среда включва по-стари системи, които не поддържат SMB 3.x, можете да деактивирате отказването на некриптиран достъп, като използвате PowerShell със свойството Отхвърляне на некриптиран достъп от SMB сървъра. Това понижава нивото на сигурност, така че е препоръчително да го ограничите.
Как да активирате SMB криптиране: Административен център, PowerShell и UNC защита
В много случаи най-удобният начин за управление на съвременен файлов сървър е Център за администриране на WindowsОт уеб интерфейса му можете да активирате криптиране както на ниво сървър, така и за конкретни споделени ресурси, без да усложнявате нещата с команди.
За конкретен споделен ресурс просто изберете име на споделено В раздела за споделяне на файлове изберете опцията за активиране на SMB криптиране. Ако искате да принудите целия сървър да използва криптиране, можете да отидете в настройките на файловия сървър и да зададете SMB 3 криптирането да бъде задължително за всички клиенти, като отхвърлите всички връзки, които не го поддържат.
Ако предпочитате командния ред, PowerShell предлага ясни командлети, като например Set-SmbShare, Set-SmbServerConfiguration o New-SmbShare за създаване и конфигуриране на ресурси с активирано криптиране от самото начало, както и команди за картографиране на дискове, изискващи поверителност (-RequirePrivacy) както от PowerShell, така и от CMD с NET USE ... /REQUIREPRIVACY.
La UNC защита Това добавя още един слой. Позволява клиентът да бъде конфигуриран да приема само криптирани връзки към определени UNC пътища, дори ако сървърът не изисква криптиране по подразбиране. Това е особено полезно за защита от атаки за прихващане в ненадеждни мрежи, като по този начин се осигурява поверителност за корпоративни клиенти.
Когато прилагате криптиране, трябва да вземете предвид наличието на WAN ускорители или междинни устройства в мрежата, които разчитат на преглеждане на съдържанието в обикновен текст. SMB криптирането може да попречи на тяхната работа и да причини проблеми с достъпа или производителността.
Цялостност на предварителното удостоверяване и модерен подпис в SMB 3.x
За да се засили допълнително сигурността срещу атаки за деградация на протокола или манипулиране на договарянето, SMB 3.1.1 включва т.нар. целостта на предишното удостоверяванеТази функция изчислява криптографските хешове на съобщенията за договаряне и конфигурация на сесията. След това използва този резултат, за да извлече ключове за сесия и подпис.
Благодарение на този механизъм, клиентът и сървърът могат откриване дали някой се подправя Връзката се използва например за принудително преминаване към некриптиран SMB 2.x. Ако се открие несъответствие в тези хешове, сесията незабавно се затваря.
Наред с криптирането, SMB се развива и в областта на подпис на съобщениеSMB 2.0 използваше HMAC-SHA256, докато SMB 3.0/3.02 въведе AES-CMAC, който е по-добре оптимизиран за съвременни процесори, поддържащи AES инструкции. С Windows Server 2022 и Windows 11, SMB 3.1.1 добави AES-128-GMAC като алгоритъм за подпис, предлагайки подобрена производителност в много сценарии.
Практическото предимство е, че сега можете отделен подпис и криптиране. Ако някога ви е необходим само подпис (цялостност) без криптиране, SMB позволява това със съвременни алгоритми. Това ви дава гъвкавостта да отговаряте както на изискванията за одит, така и на изискванията за производителност.
За да извлечете максимума от тези функции и да предотвратите налагането на SMB 1.0 от страна на атакуващ, е добра идея деактивиране на SMBv1 изцяло на съвременни сървъри и клиенти, нещо, което Microsoft вече прави по подразбиране в последните версии на Windows и Windows Server.
Защо трябва да деактивирате SMB 1.0 възможно най-скоро
SMB 1.0 е протокол остарели, неефективни и със сериозни уязвимости Това са известни уязвимости, които са били използвани от ransomware и други видове зловреден софтуер през последните години. Следователно, започвайки с някои версии на Windows 10 и Windows Server, той вече не се инсталира по подразбиране.
Ако все още имате сървъри или компютри с активиран SMB 1.0 във вашата среда, първата разумна стъпка е планирайте неговото изхвърляне. Настоящата препоръка е да се деактивира както на сървърите, така и на клиентите. Препоръчително е да се поддържат само SMB 2.x и 3.x. Това драстично намалява атакуваща повърхност и предотвратява понижаването на нивото на легитимна връзка до некриптирана или слабо защитена версия.
В Windows среди можете да управлявате SMB 1.0, използвайки допълнителни системни функции, PowerShell или инструменти за отдалечено администриране. Препоръчително е да документирате подробно кои услуги могат да зависят от него, за да избегнете изненади по-късно.
В някои много специфични сценарии (например, стари центрове за активиране), може да нямате друг избор, освен да поддържате SMB 1.0 в изолиран и силно контролиран мрежов сегмент. Това са много специфични изключения със значителни компромиси по отношение на сигурността.
Синхронизация и миграция на големи обеми SMB без прекъсване на услугата
Едно от най-досадните предизвикателства в реалния живот е мигрирането или синхронизиране на големи SMB директории (говорим за 10 TB или повече) от един сървър към друг или към друга платформа, без да се налага компанията да не може да записва в споделени ресурси в продължение на няколко дни.
Класическият подход обикновено е следният:
- Деактивирайте записването в стария дял.
- Използвайте инструмент като Robocopy да копирате цялото съдържание, като същевременно запазите NTFS разрешенията.
- Конфигурирайте новите споделени ресурси на целевия сървър.
- Актуализирайте назначенията на единиците.
- Помолете потребителите да рестартират компютрите си.
Това работи, но има проблема, че по време на дългото копие никой не може да запази промените в източника.
При много големи обеми и бавни дискове първоначалното копие може да отнеме повече от един уикендТова пряко влияе върху бизнеса. Ако оставите споделения ресурс използван, докато копирате, рискувате да загубите промени, изтривания или премествания на файлове, направени по време на прозореца за миграция.
В тези случаи стратегията включва комбиниране множество проходи с robocopy (Първо групово копие, след това само промени) и планиране на много кратък прозорец за финално копиране, през който записът е деактивиран. След това се извършва инкрементална синхронизация с помощта на /MIR или подобен параметр и достъпът се пренасочва към новия сървър. За VHDX и други много големи файлове може да се наложи да се планират специфични прозорци. Или дори репликация на ниво съхранение, ако масивът за съхранение го позволява.
Друга алтернатива е мигрират на парчетаТова включва преместване на големи папки на етапи и ясно съобщаване на промените в пътя на потребителите. Недостатъкът е, че това често усложнява потребителското изживяване.
Разрешения и ACL в SMB за FSLogix, Azure Files и Azure NetApp Files
В съвременни среди за виртуализация на настолни компютри или приложения, като например тези, използвани FSLogixПотребителските профили се съхраняват във VHD(X) контейнери на SMB ресурси. Тези ресурси могат да се намират на традиционни файлови сървъри, в Azure файлове, в Azure NetApp Files или дори през шлюзове като AWS Storage Gateway.
FSLogix използва UNC пътища (VHDLocations или CCDLocations), за да локализира профила и контейнерите на Office. Сигурността на тези данни зависи от два слоя:
- Лос NTFS разрешения (Windows ACL) в споделения ресурс.
- Лос разрешения на ниво споделяне присвоени на самоличности на Entra ID в Azure Files.
В Azure Files е силно препоръчително да конфигурирате разрешение за споделен ресурс по подразбиране от типа „SMB сътрудник за споделяне на данни за файлове за съхранение“, приложен към всички удостоверени самоличности. Това е от съществено значение, за да могат те да четат и пишат. За да управляват подробни ACL, на определени потребители или групи се предоставя роля на сътрудник с повишени привилегии за споделянето.
Препоръчителната практика за тези сценарии е да се използва така нареченото достъп, базиран на потребителВсеки потребител трябва да притежава собствена папка с профил или VHD(X) файл. Администраторите на домейни и групите за поддръжка, от друга страна, имат пълен контрол върху задачите по поддръжка.
За да се конфигурира това, се установяват типични ACL, където група администратори на домейни СЪЗДАТЕЛЪТ (CREATOR OWNER) има пълен контрол над цялата структура, има разрешения за промяна на подпапки и файлове, а групата потребители на домейна (domain users) има разрешения за промяна само на главната папка, така че да могат да се създават нейните директории.
Прилагане на ACL на Windows: icacls, Explorer и SIDDirSDDL във FSLogix
В Windows можете да използвате инструмента за команден ред icacls За да приложите масово препоръчителните NTFS разрешения към споделен ресурс, включително главната папка и всички нейни поддиректории и файлове, което е много полезно при подготовка на споделени ресурси за FSLogix, роуминг профили или хранилища за много потребители.
С icacls можете например, Деактивиране на наследяването В основата на споделения ресурс, предоставете специални разрешения на СЪЗДАТЕЛ-СОБСТВЕНИК, администраторите на домейна и потребителите на домейна и се уверете, че всяка новосъздадена папка наследява правилно тази структура на разрешенията.
Ако предпочитате графична среда, самата такава Windows File Explorer Позволява ви да редактирате разширени разрешения: да деактивирате наследяването, да добавяте принципи за сигурност (като СЪЗДАТЕЛ-СОБСТВЕНИК, групи домейни и др.), да дефинирате за какво се отнасят (само за тази папка, подпапки и файлове и др.) и да маркирате нива на разрешения като „Промяна“ или „Пълен контрол“.
FSLogix предлага и интересна опция, наречена SIDDirSDDLТази конфигурация приема SDDL низ, който определя ACL, които ще бъдат автоматично приложени към директорията на потребителя при създаването. За генерирането на този низ обикновено се създава тестова папка. В тази папка разрешенията се настройват до желаната структура, SDDL се извлича с помощта на PowerShell (Get-Acl | Select SDDL) и след това секциите owner и creator-owner се адаптират, за да използват динамично SID на потребителя.
След като SIDDirSDDL е конфигуриран в правилата на FSLogix, всеки път, когато потребител влезе за първи път, неговата директория ще бъде създадена с точните разрешения дефинирани в този SDDL. Това ни спестява необходимостта от последващо коригиране на ACL или изпълнение на допълнителни скриптове.
Малки и средни предприятия в облака и файлови шлюзове: Azure, AWS и хибридно съхранение
В допълнение към класическия локален файлов сървър, много организации днес използват Услуги за съхранение в облак за малки и средни предприятия като например Azure Files, Azure NetApp Files или хибридни решения, които предоставят достъп на SMB на периферията и съхраняват данни в S3 или други бекендове, като например AWS Storage Gateway в режим на файлов шлюз.
В Azure Files типичният работен процес е следният:
- Създайте a Ресурс за споделяне на SMB файлове.
- Свържете го с източник на самоличност (традиционен Active Directory, Azure AD Domain Services и др.).
- Присвояване на разрешения за споделяне на потребители или групи от Entra ID.
- Конфигурирайте NTFS ACL от компютър, присъединен към домейн.
В Azure NetApp Files стъпките са следните:
- Създайте акаунт в NetApp.
- Дефиниране на сайтове и дизайн на AD DS.
- Създайте специфични групи капацитет и томове за малкия и среден бизнес.
- Работейки изключително с Разрешения за Windows сякаш е класически файлов сървър, но подкрепен от високопроизводително облачно съхранение.
С AWS, конзолата на Шлюз за съхранение Позволява ви да създавате SMB файлови споделени ресурси, поддържани от S3 контейнери, като дефинирате шлюза, контейнера или точката за достъп, класа на съхранение, IAM ролята и опции като използване или неизползване на PrivateLink, типове криптиране или откриване на MIME тип.
В тези хибридни среди, SMB и NTFS ACL Малките и средни бизнеси (SMB) остават основният механизъм за контролиране на това кой вижда кои файлове и с какво ниво на разрешения, дори когато отдолу се използват контейнери с обекти или облачни томове. Особено важно е да се координира SMB сигурността с IAM ролите или техни еквиваленти, за да се избегнат несъответствия.
Чрез комбиниране на всички тези части е възможно да се изгради инфраструктура за синхронизиране на файлове здравСигурен и с разумна производителност. Дори при работа с огромни обеми и сложни хибридни среди.
