Callback
  • Від місця на ринку до магазину

  • -

  • Від магазину до торговельної мережі

  • -

  • Від торгівлі до виробництва

Захист сервера магазину: 20 рекомендацій

Що перевірити насамперед

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

Сервер часто забезпечує роботу облікової програми, бази товарів, кас, складу та віддалених користувачів. Несанкціонований доступ до нього може зупинити продажі, змінити або знищити облікові дані, відкрити доступ до персональних даних і дати змогу атакувати інші комп’ютери мережі.

СтрокЩо зробитиВідповідальний
Сьогодні Перевірити, чи немає RDP, панелі маршрутизатора, засобу резервування або іншого інтерфейсу керування у відкритому інтернеті. Переглянути активні облікові записи та адміністраторів. Системний адміністратор
Протягом 24 годин Встановити критичні оновлення, перевірити стан антивірусного захисту, брандмауера, журналів входу та останніх резервних копій. Системний адміністратор
Протягом 72 годин Налаштувати VPN або RD Gateway з MFA, створити окремі облікові записи, ізолювати одну резервну копію та виконати тестове відновлення в окремому середовищі. Адміністратор і власник
Щомісяця Переглядати оновлення, права доступу, події безпеки, результати резервування та зміни конфігурації. Призначена відповідальна особа

Чому сервери малого бізнесу залишаються ціллю

За даними Verizon Data Breach Investigations Report 2026, 31% підтверджених витоків у вибірці починалися з експлуатації програмних уразливостей, а програми-вимагачі були присутні у 48% витоків. Звіт охоплює інциденти з 1 листопада 2024 року до 31 жовтня 2025 року. Ці показники не описують окремо український ритейл, проте підтверджують пріоритет оновлень, контролю віддаленого доступу та відновлення.

Для України додатковим ризиком є цілеспрямована активність проти організацій і використання звичних каналів підтримки. CERT-UA фіксувала спроби переконати користувачів запустити AnyDesk нібито для перевірки захищеності. У повідомленні про спроби атак із використанням AnyDesk CERT-UA радить перевіряти особу та повноваження того, хто просить надати віддалений доступ.

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

20 рекомендацій для захисту сервера

1. Призначте власника сервера і ведіть паспорт системи

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

Інвентаризація потрібна для оновлень і реагування. Неможливо своєчасно закрити уразливість у компоненті, про наявність якого ніхто не знає.

2. Використовуйте підтримувану версію Windows Server

Windows Server 2008 і 2012 не слід використовувати для нового розгортання: їх звичайна підтримка завершилася. Станом на липень 2026 року підтримуються Windows Server 2016, 2019, 2022 і 2025, але розширена підтримка Windows Server 2016 завершується 12 січня 2027 року. Актуальні дати наведені на сторінці Windows Server release information.

Якщо сервер працює на Windows Server 2016, уже потрібен план переходу. Оновлення операційної системи, SQL Server, драйверів, засобів віддаленого доступу, браузера, архіватора та маршрутизатора слід включити до одного графіка. Перед установленням оновлень адміністратор створює придатну копію, перевіряє вільне місце та погоджує технологічне вікно.

3. Застосуйте базову конфігурацію безпеки

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

Спочатку тестуванняБазову конфігурацію не варто застосовувати до робочого сервера без перевірки. Вона може змінити мережеві протоколи, правила доступу, друк і взаємодію зі старим обладнанням. Адміністратор має протестувати зміни, зафіксувати необхідні винятки та підготувати порядок повернення попередньої конфігурації.

4. Не відкривайте RDP безпосередньо в інтернет

Порт віддаленого робочого столу не повинен бути доступним з будь-якої адреси інтернету. Для віддаленої роботи використовуйте VPN із MFA або Remote Desktop Gateway. Microsoft зазначає, що RD Gateway передає RDP через захищене HTTPS-з’єднання без відкриття внутрішнього RDP-порту та підтримує багатофакторну автентифікацію і політики доступу.

Якщо прямий доступ тимчасово неможливо прибрати, обмежте його брандмауером до конкретних довірених IP-адрес, увімкніть Network Level Authentication, поставте короткий строк усунення тимчасової схеми та контролюйте кожну спробу входу.

Зміна порту не захищає RDPПеренесення RDP з порту 3389 може зменшити кількість автоматичних спроб у журналі, але сканування виявляє службу на іншому порту. Це допоміжна зміна, яка не замінює VPN або RD Gateway, MFA, обмеження адрес і журналювання.

5. Увімкніть захищену автентифікацію для віддаленого доступу

Для RDP має бути ввімкнена Network Level Authentication: користувач проходить перевірку до створення повної віддаленої сесії. Microsoft рекомендує NLA для більшості середовищ.

MFA слід увімкнути на VPN, RD Gateway, хмарному обліковому записі, панелі хостингу, засобі резервного копіювання та системі дистанційної підтримки. Для адміністраторів бажані стійкі до фішингу засоби: ключі FIDO2, сертифікати або ключі доступу, якщо сервіс їх підтримує. Одноразовий код у застосунку кращий за один пароль, але він не є стійким до фішингу; це прямо розмежовано у NIST SP 800-63B-4.

6. Створіть окремий обліковий запис для кожної людини

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

Обліковий запис має містити мінімальний набір прав і строк дії, якщо доступ тимчасовий. CERT-UA у правилах кібергігієни рекомендує відокремлювати адміністративні записи від звичайних і блокувати записи, які більше не використовуються.

7. Відокремте повсякденну роботу від адміністрування

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

Для мережі з кількома Windows-комп’ютерами варто використовувати Windows LAPS. Він автоматично створює і змінює унікальний пароль локального адміністратора для кожного пристрою. Налаштування описані в документації Windows LAPS.

8. Замініть стару політику паролів

Для облікового запису, який захищений лише паролем, встановіть унікальну парольну фразу щонайменше з 15 символів. Якщо пароль використовується разом із MFA, мінімум NIST становить 8 символів, проте довша унікальна фраза залишається доцільною. Зберігайте паролі у корпоративному менеджері паролів і забороніть повторне використання.

NIST SP 800-63B-4 не рекомендує вимагати довільну суміш великих літер, цифр і символів та періодично змінювати пароль без ознак компрометації. Сервіс має блокувати поширені й відомі зі зламів паролі. Для Windows можна взяти за початковий орієнтир 10 невдалих спроб і 15 хвилин блокування, але адміністратор повинен оцінити ризик навмисного блокування облікових записів.

9. Залиште відкритими тільки необхідні порти

Брандмауер Windows і мережевий брандмауер мають працювати за правилом: вхідні з’єднання заборонені, крім явно дозволених. За замовчуванням Windows Firewall блокує небажаний вхідний трафік, якщо він не відповідає дозволеному правилу; це описано в документації Windows Firewall.

Не відкривайте діапазони портів «про всяк випадок». Для кожного правила зафіксуйте програму, протокол, порт, дозволені джерела й відповідального. Доступ до SQL Server, спільних папок, консолі резервування та панелі керування повинен бути обмежений локальною службовою мережею або VPN.

10. Розділіть сервер, каси, офісні пристрої та гостьовий Wi-Fi

Одна мережа для сервера, кас, особистих телефонів, камер, телевізорів і відвідувачів спрощує поширення атаки. Створіть окремі сегменти або VLAN: серверний, касовий, офісний, обладнання та гостьовий. Між ними дозвольте тільки потрібні з’єднання.

Для Wi-Fi використовуйте WPA3 або WPA2-AES, якщо старе обладнання не підтримує WPA3. Вимкніть WPS, змініть стандартний пароль адміністратора маршрутизатора, оновлюйте його прошивку та вимкніть керування з інтернету. Приховування назви Wi-Fi не є засобом захисту: назву мережі можна виявити за службовим трафіком. Основні параметри шифрування наведені в рекомендаціях CISA щодо Wi-Fi.

11. Не вимикайте антивірус, брандмауер і UAC

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

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

12. Використовуйте сервер тільки за призначенням

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

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

13. Контролюйте запуск програм і використання USB

Для стабільної конфігурації адміністратор може дозволити запуск тільки затверджених програм за допомогою App Control for Business або AppLocker. Спочатку політику запускають у режимі аудиту, аналізують журнали й лише потім переходять до блокування. Microsoft рекомендує починати впровадження App Control у режимі аудиту.

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

14. Шифруйте диски та захищайте ключі відновлення

BitLocker зменшує ризик читання даних після крадіжки диска або сервера. Перед увімкненням перевірте сумісність обладнання, наявність TPM і вплив на процедуру відновлення. Ключ BitLocker слід зберігати окремо від сервера, у місці з контрольованим доступом. Без ключа відновлення збій TPM або зміна завантаження може заблокувати доступ до диска. Microsoft описує ці сценарії в BitLocker recovery overview.

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

15. Побудуйте резервування за правилом 3–2–1

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

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

16. Перевіряйте не файл копії, а повне відновлення

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

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

17. Увімкніть журнали та сповіщення

Зберігайте події успішних і невдалих входів, блокування облікових записів, створення нових адміністраторів, зміни служб, параметрів брандмауера, антивірусу, резервування і RDP. Для невдалого входу Windows створює подію 4625. Серія таких подій, вхід у нетиповий час або з нової адреси потребують перевірки.

Журнали мають зберігатися достатньо довго для розслідування і, за можливості, копіюватися на окрему систему, де адміністратор атакованого сервера не може їх видалити. CISA пояснює роль журналів у рекомендаціях для малого та середнього бізнесу.

18. Захистіть сервер фізично та забезпечте коректне вимкнення

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

Джерело безперебійного живлення має бути розраховане на сервер, сховище і мережеве обладнання. Налаштуйте автоматичне коректне завершення роботи при тривалому відключенні електроенергії та перевіряйте батарею під навантаженням. UPS знижує ризик пошкодження бази через раптове вимкнення, але не замінює резервну копію.

19. Керуйте доступом техпідтримки й підрядників

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

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

20. Підготуйте план реагування і проведіть навчальну перевірку

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

Раз на рік проведіть навчальний сценарій: сервер недоступний, пароль адміністратора скомпрометований, остання копія пошкоджена. Перевірка має завершитися переліком недоліків, відповідальних і строків виправлення.

Особливості сервера з Торгсофт

У Термінальній версії Торгсофт користувачі працюють з єдиною базою через віддалений робочий стіл. Це не означає, що RDP потрібно відкривати для всього інтернету. Доступ до термінального сервера налаштовують через VPN або RD Gateway з MFA, окремими обліковими записами й обмеженими правами.

Сервер або основний комп’ютер із Торгсофт варто використовувати для роботи облікової системи. Пошта, месенджери, випадкові сайти та сторонні програми збільшують кількість способів проникнення. Перед зміною політик Windows, брандмауера, антивірусу, SQL Server або мережевих портів потрібно перевірити сумісність із робочою конфігурацією Торгсофт, касами, принтерами, ПРРО та інтеграціями.

У Торгсофт можна налаштувати автоматичне створення архіву бази. Опція Хмарний архів даних створює резервні копії за розкладом і зберігає їх у Google Drive. Такий архів може бути одним із рівнів резервування. Для стійкості до шифрувальника все одно потрібні окремі права доступу, MFA, кілька версій, ізольована або незмінна копія та тестове відновлення.

Межі допомоги Торгсофт

Технічна підтримка Торгсофт може допомогти встановити програму та розгорнути придатний архів бази. Захист Windows Server, VPN, RD Gateway, маршрутизатора, облікових записів, антивірусу й резервної інфраструктури належить до завдань системного адміністратора. Техпідтримка програми не є службою розшифрування заражених файлів.

Що робити при підозрі на злам

  1. Ізолюйте сервер від мережі. Від’єднайте мережевий кабель або заблокуйте з’єднання на комутаторі чи брандмауері. Якщо швидко ізолювати сервер неможливо, вимкніть його, щоб обмежити поширення атаки. Не підключайте резервні диски. Такий пріоритет дій містить чекліст реагування CISA.
  2. Не видаляйте файли й не перевстановлюйте Windows одразу. Збережіть журнали, повідомлення, час виявлення, список підключених систем і фотографії екрана. Ці дані потрібні для встановлення способу проникнення.
  3. Залучіть фахівця з реагування. Звичайне сканування антивірусом не підтверджує, що сторонній доступ усунуто.
  4. Змініть скомпрометовані паролі з чистого пристрою. Спочатку захистіть адміністративні, поштові, хмарні, VPN і резервні облікові записи. Завершіть активні сесії та відкличте ключі доступу.
  5. Перевірте інші пристрої. З’ясуйте, чи використовувався той самий пароль, чи є нові адміністратори, служби, завдання за розкладом або засоби віддаленого доступу.
  6. Відновлюйте тільки в очищене середовище. Перевстановіть або гарантовано очистьте систему, закрийте спосіб проникнення, перевірте копію на шкідливе програмне забезпечення і лише потім відновлюйте дані. Такий порядок рекомендує NCSC у настанові з протидії шкідливому програмному забезпеченню.
  7. Повідомте про інцидент. За наявності ознак кібератаки зверніться до CERT-UA через офіційні контакти на cert.gov.ua. Якщо є вимагання, шахрайство або викрадення коштів, також подайте звернення до Кіберполіції та повідомте банк.

Не відновлюйте поверх зараженої системиКопія може бути придатною, але скомпрометований сервер здатен повторно зашифрувати її або передати зловмиснику нові паролі. Спочатку потрібно усунути спосіб проникнення і підготувати чисте середовище.

Чекліст власника

  • Є призначений відповідальний за сервер і актуальний паспорт системи.
  • Операційна система та всі доступні з інтернету компоненти підтримуються й оновлюються.
  • RDP не відкритий безпосередньо для всього інтернету.
  • VPN, RD Gateway, хмарне сховище й панелі керування захищені MFA.
  • Кожна людина має власний обліковий запис; звільнені працівники доступу не мають.
  • Працівники працюють без адміністративних прав.
  • Брандмауер увімкнений, а кожен відкритий порт має обґрунтування.
  • Сервер, каси, офісна техніка та гостьовий Wi-Fi розділені.
  • Антивірус працює в реальному часі; широких постійних виключень немає.
  • На сервері не читають пошту, не користуються месенджерами й не встановлюють сторонні програми.
  • Є щонайменше одна офлайн- або незмінна резервна копія.
  • Повне відновлення перевірене на окремій системі й задокументоване.
  • Події входу, зміни прав і стан резервування контролюються.
  • Доступ підрядників є персональним, обмеженим у часі та зафіксованим у журналі.
  • План реагування доступний поза сервером і перевірений навчальним сценарієм.