Як підтримувати стабільну роботу сервера магазину

Що найбільше впливає на стабільність сервера

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

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

Захист від кібератак також впливає на безперервність роботи. У звіті CERT-UA за друге півріччя 2025 року описані атаки програм-вимагачів на системи Windows, у яких початковий доступ отримували через відкриті в інтернет інтерфейси адміністрування, переважно RDP. Перед шифруванням зловмисники видаляли тіньові копії Windows, щоб ускладнити відновлення. Джерело: звіт «Кіберзагрози: Україна» за друге півріччя 2025 року.

Використовуйте сервер лише для робочих завдань

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

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

Оновлюйте систему у визначений час

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

Щотижневе перезавантаження саме по собі не є технічним обслуговуванням. Перезавантажуйте сервер після оновлень, які цього потребують, після зміни системних налаштувань або під час діагностики. Робіть це у погоджене вікно обслуговування, коли користувачі завершили роботу. Microsoft рекомендує для серверів керувати встановленням і перезавантаженням окремо; відповідні параметри описані в документації з керування перезавантаженнями Windows.

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

На сервері має постійно працювати сумісний засіб захисту від шкідливих програм. Для Windows це може бути вбудований Microsoft Defender або корпоративне рішення іншого виробника. Бази виявлення, сам захисний модуль і механізми хмарної перевірки потрібно регулярно оновлювати. Microsoft не рекомендує вимикати або видаляти Defender без іншого активного засобу захисту: огляд Microsoft Defender Antivirus.

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

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

Розділіть звичайні та адміністративні облікові записи

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

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

Чинна редакція NIST SP 800-63B рекомендує щонайменше 15 символів для пароля, який є єдиним фактором входу, дозволяє менеджери паролів і не вимагає періодичної заміни пароля без ознак компрометації. Отже, правило «змінювати всі паролі кожні два-три місяці» застаріло. Пароль потрібно негайно замінити після витоку, підозрілого входу, звільнення працівника з доступом або передачі пароля іншій особі. Джерело: NIST SP 800-63B.

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

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

Протокол віддаленого робочого столу Windows (RDP) не повинен бути доступним з будь-якої адреси в інтернеті. Для постійного віддаленого доступу використовуйте захищене приватне підключення (VPN) або шлюз віддаленого доступу з багатофакторною автентифікацією. Обмежте дозволені адреси, час підключення та перелік користувачів. Увімкніть журналювання успішних і невдалих входів.

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

Зберігайте кілька незалежних резервних копій

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

Як практичну основу використовуйте правило 3–2–1: щонайменше три копії даних, на двох різних носіях, одна з них — поза основним місцем роботи. Одну копію тримайте від’єднаною від робочої мережі або захищеною від зміни й видалення з облікового запису сервера. Таку схему та необхідність регулярного тестування описує Національний центр кібербезпеки Великої Британії.

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

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

Використовуйте UPS з автоматичним завершенням роботи

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

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

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

Використовуйте RAID за призначенням

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

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

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

Контролюйте температуру, диски та вільне місце

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

Адміністратор має контролювати температуру процесора й накопичувачів, стан вентиляторів, помилки дисків, стан RAID, навантаження на оперативну пам’ять і запас місця на системному диску. Різке зростання помилок введення-виведення, температури або часу відповіді потребує діагностики. Не чекайте повної відмови диска.

Очищення від пилу виконуйте після коректного вимкнення і від’єднання живлення. Не розбирайте сервер та UPS без потрібної кваліфікації. Якщо обладнання на гарантії, дотримуйтеся умов виробника або постачальника.

Ведіть журнал обслуговування й налаштуйте сповіщення

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

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

Практичний графік перевірок

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

Що робити при ознаках атаки або пошкодження даних

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

1. Від’єднайте підозрілий сервер від локальної мережі та інтернету: витягніть мережевий кабель або вимкніть мережевий інтерфейс.
2. Не підключайте резервні диски й не запускайте відновлення в ураженій системі.
3. Не видаляйте файли, журнали й облікові записи до огляду фахівцем. Зафіксуйте час, повідомлення на екрані та дії, що передували проблемі.
4. Зв’яжіться з адміністратором або фахівцем із реагування. Повідомте власника та визначте, які операції магазину потрібно перевести на резервний порядок.
5. Перевірте інші комп’ютери, облікові записи й засоби віддаленого доступу. Змінюйте скомпрометовані паролі з чистого пристрою.
6. Відновлюйте систему на чистому та оновленому середовищі з копії, створеної до проникнення і перевіреної на відсутність шкідливих файлів.

CISA радить насамперед визначити уражені системи й негайно ізолювати їх; вимикати живлення варто тоді, коли ізоляція від мережі неможлива. Повний порядок наведений у переліку дій при атаці програми-вимагача.

Хто за що відповідає

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