Налаштування файлового сервера

Файловий сервер централізує робочі документи, спрощує керування доступом і дає адміністраторам контрольовану точку для резервного копіювання. Але встановити роль File Server недостатньо: без продуманої структури каталогів, коректних NTFS-дозволів і журналювання доступу спільне сховище швидко перетворюється на набір папок із незрозумілими власниками.

У цій інструкції налаштуємо файловий сервер на Windows Server 2022, створимо SMB-ресурси через PowerShell, розмежуємо доступ за групами Active Directory, увімкнемо квоти та розглянемо базові заходи захисту. Перед початком сервер бажано приєднати до домену, призначити йому статичну IP-адресу та встановити актуальні оновлення. Якщо доменна інфраструктура ще не розгорнута, спочатку варто виконати встановлення Active Directory на Windows Server 2022.

Планування структури файлового сервера

До створення першої спільної папки потрібно визначити, які дані зберігатимуться на сервері та хто відповідатиме за доступ до них. Не варто створювати єдиний ресурс Share і дозволяти користувачам самостійно формувати всередині довільну структуру. Такий підхід ускладнює аудит, резервне копіювання та подальшу міграцію.

Практична структура може виглядати так:

D:\Shares
├── Departments
│   ├── Accounting
│   ├── Engineering
│   └── HR
├── Projects
├── Exchange
└── Users

Системний диск C: не слід використовувати для робочих файлів. Дані краще розміщувати на окремому томі D: або на виділеному дисковому масиві. Це розділяє операційну систему й користувацькі файли, спрощує відновлення та зменшує ризик зупинки Windows через заповнення системного розділу.

Під час планування потрібно врахувати:

- прогнозований обсяг даних і темпи його збільшення; - максимальний розмір окремих файлів; - вимоги до швидкості читання та запису; - період зберігання видалених або змінених документів; - перелік груп із правами читання та редагування; - розклад резервного копіювання; - потребу в шифруванні SMB-трафіку; - правила зберігання тимчасових і мультимедійних файлів.

Для робочого сховища доцільно використовувати NTFS або ReFS залежно від сценарію. NTFS залишається універсальним варіантом із повною підтримкою дозволів, квот і сумісних засобів резервного копіювання. ReFS може бути корисною для великих масивів даних, але перед його вибором потрібно перевірити сумісність усіх програм і backup-агентів.

Якщо сервер обслуговує критичні робочі процеси, проєктування дисків, моніторингу й резервного копіювання краще включати в загальний контур системного адміністрування, а не розглядати файлове сховище як ізольований вузол.

Встановлення ролей і підготовка каталогів

Базова роль файлового сервера зазвичай уже присутня у Windows Server, але її стан потрібно перевірити. Для квот, файлових фільтрів і звітів додатково встановимо File Server Resource Manager.

Запустіть PowerShell від імені адміністратора та виконайте:

Install-WindowsFeature FS-FileServer, FS-Resource-Manager -IncludeManagementTools
Get-WindowsFeature FS-FileServer, FS-Resource-Manager

У результаті обидва компоненти повинні мати стан Installed. Перезавантаження зазвичай не потрібне, але його варто виконати, якщо Windows повідомляє про незавершені операції обслуговування.

Далі створіть кореневий каталог і папки підрозділів:

New-Item -Path "D:\Shares" -ItemType Directory -Force
New-Item -Path "D:\Shares\Departments" -ItemType Directory -Force
New-Item -Path "D:\Shares\Departments\Accounting" -ItemType Directory -Force
New-Item -Path "D:\Shares\Departments\Engineering" -ItemType Directory -Force
New-Item -Path "D:\Shares\Departments\HR" -ItemType Directory -Force
New-Item -Path "D:\Shares\Projects" -ItemType Directory -Force
New-Item -Path "D:\Shares\Exchange" -ItemType Directory -Force

Не публікуйте кожен каталог одразу. Спочатку створіть доменні групи, налаштуйте NTFS-дозволи й тільки після перевірки відкривайте SMB-доступ.

Для керування правами зручно застосовувати модель AGDLP: облікові записи користувачів додаються до глобальних груп за роллю, глобальні групи — до локальних доменних груп ресурсу, а дозволи призначаються саме локальним групам. Наприклад:

- GG_Accounting_Users — працівники підрозділу; - DL_FS_Accounting_RW — право зміни файлів; - DL_FS_Accounting_RO — право лише читання.

Створити групи можна через Active Directory Users and Computers або PowerShell на сервері з модулем Active Directory:

New-ADGroup -Name "GG_Accounting_Users" -GroupScope Global -GroupCategory Security
New-ADGroup -Name "DL_FS_Accounting_RW" -GroupScope DomainLocal -GroupCategory Security
New-ADGroup -Name "DL_FS_Accounting_RO" -GroupScope DomainLocal -GroupCategory Security
Add-ADGroupMember -Identity "DL_FS_Accounting_RW" -Members "GG_Accounting_Users"

Такий підхід дає змогу змінювати склад працівників без ручного редагування ACL на файловому сервері.

Налаштування NTFS-дозволів і SMB-ресурсів

Доступ до спільної папки визначається двома рівнями: дозволами SMB і NTFS. Під час мережевого підключення застосовується найсуворіша комбінація цих правил. Якщо на рівні SMB дозволено зміну, але NTFS надає тільки читання, користувач матиме лише читання.

Практичний варіант — зробити SMB-дозволи відносно широкими для визначених груп, а детальне розмежування виконувати через NTFS. Не залишайте Everyone: Full Control, якщо ресурс не є спеціальною відкритою зоною обміну.

Спочатку вимкніть успадкування на папці бухгалтерії, видаліть зайві записи та призначте права адміністраторам і доменним групам:

icacls "D:\Shares\Departments\Accounting" /inheritance:r
icacls "D:\Shares\Departments\Accounting" /grant "SYSTEM:(OI)(CI)F"
icacls "D:\Shares\Departments\Accounting" /grant "BUILTIN\Administrators:(OI)(CI)F"
icacls "D:\Shares\Departments\Accounting" /grant "CONTOSO\DL_FS_Accounting_RW:(OI)(CI)M"
icacls "D:\Shares\Departments\Accounting" /grant "CONTOSO\DL_FS_Accounting_RO:(OI)(CI)RX"

Замініть CONTOSO на NetBIOS-ім’я свого домену. Позначення (OI)(CI) поширюють дозволи на файли та вкладені каталоги. Право M означає Modify: користувач може читати, створювати, змінювати й видаляти файли, але не може довільно змінювати власника або ACL.

Створіть SMB-ресурс:

New-SmbShare `
  -Name "Accounting$" `
  -Path "D:\Shares\Departments\Accounting" `
  -FullAccess "CONTOSO\Domain Admins" `
  -ChangeAccess "CONTOSO\DL_FS_Accounting_RW" `
  -ReadAccess "CONTOSO\DL_FS_Accounting_RO" `
  -FolderEnumerationMode AccessBased `
  -CachingMode None

Символ $ наприкінці імені робить ресурс прихованим під час звичайного перегляду мережі, але не є механізмом захисту. Реальний контроль забезпечують ACL. Параметр AccessBased приховує каталоги, на які користувач не має дозволів. CachingMode None вимикає автономне кешування, що доречно для документів, які часто змінюються кількома працівниками.

Перевірте конфігурацію:

Get-SmbShare -Name "Accounting$"
Get-SmbShareAccess -Name "Accounting$"
Get-Acl "D:\Shares\Departments\Accounting" | Format-List

З клієнтського комп’ютера ресурс буде доступний за UNC-шляхом:

\\FS01\Accounting$

Перевіряти потрібно щонайменше під трьома обліковими записами: користувачем із правом зміни, користувачем із правом читання та користувачем без доступу. Тест лише під Domain Admin не показує реальну поведінку дозволів.

Квоти, захист SMB та аудит доступу

Квоти допомагають не допустити неконтрольованого заповнення диска. File Server Resource Manager підтримує жорсткі квоти, які блокують запис після досягнення межі, та м’які квоти, що лише реєструють перевищення.

Створимо жорстку квоту 100 ГБ для каталогу обміну:

New-FsrmQuota `
  -Path "D:\Shares\Exchange" `
  -Size 100GB `
  -Description "Ліміт для тимчасового обміну файлами"

Get-FsrmQuota -Path "D:\Shares\Exchange"

Перед застосуванням блокування до робочих каталогів краще кілька тижнів використовувати м’яку квоту та зібрати статистику. Занадто малий ліміт може зупинити роботу програм, які створюють великі тимчасові файли.

На рівні SMB слід вимкнути застарілий протокол SMB 1.0 та перевірити підписування трафіку:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
Set-SmbServerConfiguration -EnableSecuritySignature $true -Force
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, EnableSecuritySignature

Примусове підписування або шифрування потрібно впроваджувати після перевірки клієнтів і мережевих пристроїв. Для окремого ресурсу з конфіденційними документами можна ввімкнути шифрування:

Set-SmbShare -Name "Accounting$" -EncryptData $true -Force
Get-SmbShare -Name "Accounting$" | Select-Object Name, EncryptData

Шифрування SMB захищає дані під час передавання мережею, але не замінює шифрування диска, резервне копіювання та контроль фізичного доступу до сервера.

Для журналювання операцій увімкніть політику аудиту файлової системи:

auditpol /set /subcategory:"File System" /success:enable /failure:enable
auditpol /get /subcategory:"File System"

Після цього в розширених параметрах безпеки потрібного каталогу додайте auditing entry для визначеної групи. Не варто реєструвати всі успішні операції для всіх користувачів на великому сховищі: журнал Security швидко заповниться. Зазвичай достатньо фіксувати видалення, зміну дозволів, невдалі спроби доступу та операції з критичними папками.

Файловий сервер також потрібно включити в централізований моніторинг. Контролюйте вільне місце, стан дисків, помилки NTFS, події SMB, завантаження мережі, тривалість резервного копіювання та появу незвично великої кількості змінених файлів. Регулярне адміністрування серверів Windows і Linux допомагає виявляти деградацію сховища до того, як користувачі втратять доступ до документів.

Типові помилки

Призначення дозволів безпосередньо користувачам. Через кілька місяців ACL містять десятки персональних записів, а причину доступу неможливо швидко встановити. Дозволи потрібно надавати групам, а користувачів включати до цих груп.

Використання Deny без нагальної потреби. Явна заборона має пріоритет над дозволами та часто створює неочікуваний результат через вкладене членство у групах. Краще не додавати групу до ACL, ніж масово застосовувати Deny.

Зберігання даних на системному диску. Заповнення C: може порушити роботу оновлень, журналів і самої операційної системи. Робочі файли мають розміщуватися на окремому томі.

Надання Full Control звичайним користувачам. Для повсякденної роботи достатньо Modify. Full Control дозволяє змінювати ACL і власника, через що користувач може випадково заблокувати доступ адміністраторам або колегам.

Перевірка тільки під адміністративним обліковим записом. Членство в привілейованих групах спотворює результат тесту. Потрібні окремі тестові облікові записи для кожного рівня доступу.

Відсутність резервного копіювання та тестового відновлення. RAID захищає від відмови окремого диска, але не від видалення, шифрувальника, пошкодження файлової системи чи помилки адміністратора. Резервні копії мають зберігатися окремо, а процедура відновлення — регулярно перевірятися.

Увімкнення аудиту всіх операцій. Надмірний аудит створює великий потік подій і ускладнює пошук справді важливих дій. Політику потрібно налаштовувати вибірково для критичних каталогів та операцій.

Використання прихованого ресурсу як єдиного захисту. Суфікс $ лише прибирає ресурс зі звичайного списку. Користувач, який знає UNC-шлях, усе одно може спробувати підключитися, тому NTFS- і SMB-дозволи залишаються обов’язковими.

Висновок

Надійний файловий сервер — це не просто роль Windows і кілька опублікованих папок. Його стабільність залежить від окремого тому для даних, зрозумілої структури каталогів, групової моделі доступу, узгоджених NTFS- та SMB-дозволів, квот, аудиту й перевіреного резервного копіювання.

Після впровадження зафіксуйте призначення кожного ресурсу, відповідальних осіб, групи доступу, квоти та політику зберігання. Періодично переглядайте членство у групах і видаляйте застарілі права. Так файловий сервер залишатиметься керованим навіть після розширення команди, появи нових підрозділів або перенесення даних на іншу платформу.