Кібербезпека для малих бізнесів: основні кроки щодо захисту сайту

Вступ: малий бізнес — ідеальна мішень для хакерів

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

Реальність протилежна. За даними Verizon Data Breach Investigations Report, 46% усіх кібератак спрямовані саме на малий і середній бізнес. Причина проста: великі компанії інвестують мільйони у кібербезпеку, мають цілі відділи безпеки і складну захисну інфраструктуру. Малий бізнес — ні. Для зловмисника це виглядає як відкрита двері поряд із замкненими воротами: навіщо витрачати час на важку мету, коли легка — поруч?

Наслідки злому для малого бізнесу катастрофічні. За даними National Cyber Security Alliance (США), 60% малих компаній, що зазнали серйозної кібератаки, закриваються протягом шести місяців. Не тому що технічно не можуть відновитись — а тому що втрачають репутацію, клієнтів і фінансові ресурси одночасно.

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

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

Частина 1: Розуміння загроз — знати ворога в обличчя

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

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

Застаріле програмне забезпечення — причина №1. WordPress, плагіни, теми, бібліотеки — все це потребує регулярного оновлення. Кожне оновлення закриває виявлені вразливості. Якщо ви не оновлюєте — ви залишаєте відомі "дірки" відкритими. Автоматизовані сканери зловмисників постійно шукають сайти зі застарілим ПЗ і атакують їх масово, без ручного вибору жертви.

Слабкі паролі — причина №2. "admin/admin", "password123", назва компанії як пароль — це все ще реальність для більшості малих бізнесів. Brute force атаки перебирають мільйони комбінацій за секунди. Слабкий пароль — це відкритий замок.

Фішинг — причина №3. Електронний лист, що виглядає як повідомлення від банку, хостингу або партнера, але містить шкідливе посилання або вкладення. Один клік співробітника — і зловмисник всередині вашої системи. За даними IBM, фішинг є вектором атаки у 41% випадків зламів.

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

Скомпрометовані плагіни і розширення. Особливо актуально для WordPress. Один шкідливий або скомпрометований плагін може надати зловмиснику повний доступ до сайту і сервера.

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

Що шукають зловмисники на сайті малого бізнесу

Розуміння мотивації допомагає правильно розставити пріоритети захисту.

Платіжні дані і особиста інформація клієнтів. Найцінніший трофей. Бази даних із іменами, email-адресами, номерами карток продаються на тіньових ринках. Для e-commerce-сайтів це основна загроза.

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

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

Перенаправлення трафіку. Відвідувачі вашого сайту перенаправляються на фішингові або шкідливі сайти. Ви втрачаєте клієнтів і репутацію.

Ransomware (здирництво). Шифрування файлів сайту або бази даних із вимогою викупу за розшифровку. Все частіше застосовується і до малого бізнесу.

Частина 2: Основи основ — те, що потрібно зробити негайно

Крок 1: HTTPS і SSL/TLS — нульовий рівень захисту

Якщо ваш сайт досі працює на HTTP — це перше, що потрібно виправити. Прямо сьогодні.

HTTPS шифрує весь трафік між браузером відвідувача і вашим сервером. Без нього будь-хто в тій самій мережі (публічний WiFi у кафе, корпоративна мережа) може перехопити і прочитати: паролі, дані форм, особисту інформацію.

Крім захисту, HTTPS впливає на довіру. Браузери Chrome і Firefox позначають HTTP-сайти як "Небезпечний" — і значна частина відвідувачів одразу закриває такі сайти. Google знижує позиції HTTP-сайтів у пошуковій видачі.

Let's Encrypt — безкоштовний SSL-сертифікат із автоматичним оновленням. Більшість сучасних хостингів підключають його в один клік або автоматично. Більше немає жодного виправдання для HTTP.

Після підключення HTTPS: налаштуйте автоматичний редирект усього HTTP-трафіку на HTTPS, увімкніть HSTS (Strict Transport Security) — заголовок, що змушує браузер завжди використовувати HTTPS для вашого домену.

Крок 2: Оновлення — найнудніший і найважливіший захист

Якщо у вас сайт на WordPress, Joomla, OpenCart або будь-якій іншій CMS — регулярне оновлення є критично важливим.

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

Практичний підхід до оновлень:

Увімкніть автоматичні оновлення для ядра CMS. Для WordPress: Settings → Updates → автоматичні оновлення для мінорних версій.

Регулярно (щотижня) перевіряйте і встановлюйте оновлення для плагінів і тем вручну. Перед кожним оновленням — переконайтесь, що є свіжий бекап.

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

Слідкуйте за оголошеннями про вразливості у плагінах, що ви використовуєте. WPScan Vulnerability Database і CVE Details — корисні ресурси.

Крок 3: Паролі і управління доступом

Слабкий пароль адміністратора — це як залишити ключ під килимком. Всі знають, що так роблять.

Правила надійних паролів для бізнесу:

Мінімум 16 символів. Комбінація великих і малих літер, цифр, спеціальних символів.

Унікальний пароль для кожного сервісу. Один і той самий пароль для адмін-панелі, хостингу, email і банківського рахунку — означає, що злам будь-якого одного сервісу компрометує всі.

Менеджер паролів — не опція, а необхідність. Bitwarden (безкоштовний і відкритий), 1Password, Dashlane дозволяють зберігати сотні унікальних складних паролів без необхідності їх пам'ятати.

Для WordPress і інших CMS: змініть стандартне ім'я користувача "admin" на унікальне. Стандартне "admin" — перше, що перевіряють автоматизовані brute force атаки.

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

Крок 4: Двофакторна автентифікація (2FA)

Двофакторна автентифікація — один з найефективніших заходів безпеки при мінімальних зусиллях. За даними Microsoft, 99,9% атак на акаунти провалюються, якщо увімкнена 2FA.

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

Де увімкнути 2FA:

Адмін-панель вашого сайту (WordPress: плагіни WP 2FA або Google Authenticator, інші CMS — аналогічні плагіни або вбудована функція).

Хостинг-акаунт — особливо критично, бо через хостинг є доступ до всіх файлів і баз даних.

Реєстратор домену — перехоплення домену може зробити сайт недоступним або перенаправити всіх відвідувачів.

Email-акаунти — особливо корпоративні, через які відбувається управління всіма сервісами.

Google Workspace, Microsoft 365 і будь-які хмарні сервіси, що містять бізнес-дані.

Застосунки-автентифікатори: Google Authenticator, Microsoft Authenticator, Authy (з хмарним бекапом кодів).

Частина 3: Захист сервера і хостингу

Вибір надійного хостингу — перша лінія оборони

Безпека вашого сайту значною мірою залежить від безпеки хостинг-провайдера. Дешевий shared-хостинг може бути ризикованим: якщо один із тисяч сайтів на тому ж сервері заражений — це може вплинути і на ваш сайт.

На що звертати увагу при виборі хостингу з точки зору безпеки:

Ізоляція акаунтів — ваш сайт ізольований від інших сайтів на тому самому сервері.

Вбудований WAF (Web Application Firewall) — фільтрує шкідливий трафік до того, як він досягне вашого сайту.

Автоматичне сканування на шкідливий код — хостинг регулярно перевіряє файли на наявність відомих шкідливих шаблонів.

Захист від DDoS — особливо важливо для e-commerce і медіа-сайтів.

Регулярні бекапи — хостинг автоматично робить резервні копії.

Підтримка SFTP замість FTP — передача файлів у зашифрованому вигляді.

Managed-хостинг для WordPress (Kinsta, WP Engine, Cloudways) — більш дорогий варіант, але хостинг сам піклується про значну частину безпекових налаштувань.

Налаштування серверних заголовків безпеки

HTTP Security Headers — заголовки відповіді сервера, що інструктують браузер, як безпечно обробляти контент. Вони захищають від цілого класу атак і налаштовуються один раз у конфігурації сервера або через .htaccess файл.

Ключові заголовки для малого бізнесу:

Content-Security-Policy — контролює, звідки браузер може завантажувати ресурси. Основний захист від XSS-атак.

X-Frame-Options — захищає від Clickjacking (вставка вашого сайту в невидимий iframe).

X-Content-Type-Options — запобігає MIME-sniffing атакам.

Referrer-Policy — контролює, яка інформація про URL передається при переходах.

Permissions-Policy — обмежує доступ до браузерних API (камера, мікрофон, геолокація).

Перевірити наявність і якість заголовків можна безкоштовно через securityheaders.com — введіть URL і отримаєте оцінку і список відсутніх заголовків.

Правильна конфігурація прав доступу до файлів

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

Рекомендовані права доступу для WordPress і більшості CMS:

Файли: 644 (власник може читати і писати, інші — тільки читати).

Директорії: 755 (власник має всі права, інші — читати і виконувати).

Файл конфігурації (wp-config.php для WordPress): 600 або 640 (тільки власник може читати і писати).

Файл .htaccess: 644.

Ніколи не встановлюйте 777 — це надає права запису всім, що є критичною вразливістю.

Частина 4: Захист від конкретних атак

Захист від брутфорс-атак на адмінку

Автоматизовані боти постійно перебирають паролі до адмін-панелей CMS. Без захисту ваша адмінка отримує тисячі спроб входу на день.

Зміна стандартного URL адмінки. Для WordPress за замовчуванням — wp-admin і wp-login.php. Всі боти знають ці адреси і атакують їх автоматично. Зміна на нестандартний URL (наприклад, через плагін WPS Hide Login) одразу усуває 99% автоматизованих атак.

Обмеження кількості спроб входу. Після N невдалих спроб — тимчасове блокування IP. Для WordPress: плагіни Limit Login Attempts Reloaded або Wordfence.

Captcha на формі входу. Cloudflare Turnstile або hCaptcha — сучасні, ненав'язливі альтернативи reCAPTCHA.

Обмеження доступу до адмінки за IP-адресою. Якщо ви завжди заходите в адмінку з одного або кількох фіксованих IP — можна закрити доступ для всіх інших на рівні сервера або .htaccess. Це радикальний, але дуже ефективний захист.

WAF: Web Application Firewall

WAF аналізує весь HTTP-трафік до вашого сайту і блокує запити, що відповідають відомим шаблонам атак: SQL-ін'єкції, XSS, path traversal, сканування вразливостей, DDoS.

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

Sucuri — спеціалізований сервіс безпеки для сайтів. Включає WAF, моніторинг, видалення шкідливого коду і відновлення після зламу. Популярний серед WordPress-сайтів.

Wordfence — плагін для WordPress із вбудованим firewall, сканером шкідливого коду і захистом від брутфорс. Безкоштовна версія покриває базові потреби.

Захист від SQL-ін'єкцій і XSS

SQL-ін'єкції і XSS (Cross-Site Scripting) — два найпоширеніші типи атак на веб-застосунки. Обидва використовують незахищені поля введення для впровадження шкідливого коду.

Для малого бізнесу без власної команди розробників:

Використовуйте актуальну версію CMS і плагінів — більшість відомих уразливостей закриваються оновленнями.

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

Увімкніть WAF (Cloudflare або Sucuri) — вони фільтрують більшість відомих шаблонів SQL-ін'єкцій і XSS на рівні трафіку.

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

Захист від DDoS-атак

DDoS (Distributed Denial of Service) — перевантаження сервера мільйонами запитів одночасно, що робить сайт недоступним. Раніше це була загроза переважно для великих ресурсів — але зростаючий ринок "DDoS-as-a-service" зробив такі атаки доступними для виконання навіть проти малого бізнесу.

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

Обмеження швидкості запитів (Rate Limiting) — на рівні сервера або WAF: якщо один IP робить більше N запитів за X секунд — він блокується.

Частина 5: Резервні копії — страховка, яка рятує бізнес

Правило 3-2-1: золотий стандарт резервного копіювання

Правило 3-2-1 — проста і надійна стратегія бекапів:

Три копії даних (оригінал плюс дві резервні).

Два різних носії або сервіси зберігання.

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

Чому це важливо: якщо ваш хостинг зламали і всі дані на сервері зашифровані — бекап на тому самому сервері теж зашифровано. Якщо хостинг-провайдер зазнав технічної аварії — бекапи на їхній же інфраструктурі теж недоступні.

Offsite-бекап на незалежному сервісі (Google Drive, Dropbox, Amazon S3, Backblaze) — єдина справжня страховка.

Що потрібно включати в бекап

Повний бекап сайту включає три компоненти: файли сайту (всі файли WordPress або іншої CMS, завантажені медіафайли, плагіни, теми), базу даних (вся динамічна інформація: пости, сторінки, коментарі, налаштування, замовлення) і конфігураційні файли (.htaccess, php.ini, налаштування сервера).

Бекап тільки бази даних без файлів — неповний. Бекап тільки файлів без бази — теж неповний. Потрібні обидва компоненти разом.

Автоматизація і перевірка бекапів

Бекап, що не робиться автоматично — не робиться взагалі. Ручне резервне копіювання завжди відкладається і врешті-решт забувається.

Для WordPress: UpdraftPlus (найпопулярніший плагін бекапів, є безкоштовна версія) або BackWPup. Налаштовуйте автоматичний бекап щодня або щотижня і відправку копій на Google Drive, Dropbox або Amazon S3.

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

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

Частина 6: Захист електронної пошти і фішинг

Email — найбільш вразливий вектор атаки

Більшість успішних кібератак на малий бізнес починаються не зі зламу сайту напряму — а з компрометації корпоративної пошти через фішинг.

Фішинговий лист виглядає як повідомлення від вашого банку, хостингу, Google, Microsoft або навіть від колеги — і просить перейти за посиланням, ввести пароль або відкрити вкладення. Після одного кліку зловмисник отримує доступ до акаунту — і через нього може отримати доступ до всіх пов'язаних сервісів.

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

SPF, DKIM і DMARC — захист вашого домену від підробки

Ці три технічні налаштування захищають ваш домен від підробки (email spoofing) — коли зловмисники надсилають листи від імені вашого домену.

SPF (Sender Policy Framework) — список IP-адрес і серверів, яким дозволено відправляти листи від вашого домену. Налаштовується через DNS-запис.

DKIM (DomainKeys Identified Mail) — цифровий підпис, що підтверджує автентичність листів від вашого домену. Налаштовується через DNS-запис.

DMARC (Domain-based Message Authentication, Reporting and Conformance) — визначає, що робити з листами, що не пройшли SPF або DKIM (відхилити, помістити в спам або дозволити). Також налаштовується через DNS.

Разом ці три налаштування запобігають тому, щоб хтось надсилав листи від імені вашого домену — і підвищують доставлюваність ваших власних листів.

Перевірити поточний стан: MXToolbox.com → SuperTool → введіть свій домен і перевірте SPF, DKIM, DMARC.

Навчання команди: людський фактор

Найдосконаліший технічний захист може бути зведений нанівець одним недбалим кліком співробітника. "Людський фактор" — найбільша вразливість будь-якої організації.

Базові правила, які має знати кожен співробітник:

Ніколи не відкривайте вкладення від невідомих відправників. Навіть від відомих — якщо не очікували файл і він виглядає підозріло.

Перевіряйте реальну адресу відправника, а не тільки ім'я. "Служба підтримки Google" може мати адресу [email protected].

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

Якщо лист від "колеги" містить незвичне прохання (переказати гроші, надати доступ, встановити файл) — перевірте через інший канал зв'язку.

При найменшому сумніві — не клікайте. Краще зайвий раз уточнити, ніж стати жертвою фішингу.

Регулярне навчання — раз на квартал нагадуйте команді про поточні схеми фішингу. Phishing-симуляції (тестові фішингові листи від вашої ж організації) — ефективний спосіб перевірити і підвищити обізнаність.

Частина 7: Моніторинг і реагування на інциденти

Як знати, що вас зламали

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

Ознаки можливого злому:

Незвичні зміни у файлах — нові файли або зміни у існуючих, яких ви не робили.

Незрозумілі редиректи — відвідувачі перенаправляються на інші сайти.

Попередження від браузерів або Google Search Console — "Цей сайт може бути зламано" або "Шкідливий вміст".

Різке падіння позицій у пошуку — сигнал про SEO-спам або санкції від Google.

Незнайомі адміністраторські акаунти — хтось створив новий акаунт із правами адміністратора.

Незрозуміле навантаження на сервер — CPU або пам'ять постійно на максимумі без видимої причини.

Скарги клієнтів — вони отримують фішингові листи нібито від вашої компанії.

Інструменти моніторингу

Google Search Console — безкоштовний і обов'язковий. Повідомляє про виявлений шкідливий код, проблеми безпеки і санкції. Перевіряйте вкладку "Безпека та ручні дії" регулярно.

Google Safe Browsing — перевіряє, чи занесений ваш сайт до списків шкідливих. Перевірка: transparencyreport.google.com/safe-browsing/search.

Sucuri SiteCheck — безкоштовний онлайн-сканер: sitecheck.sucuri.net. Сканує сайт на шкідливий код, чорні списки, застаріле ПЗ.

Uptime-моніторинг (UptimeRobot, Better Uptime) — сповіщення, якщо сайт стає недоступним.

Журнали доступу сервера (access logs) — детальний запис усіх запитів до сайту. Аналіз логів допомагає виявити атаки і аномальну активність.

План реагування на інцидент

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

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

Крок 2 — Оцінка. Що саме сталось? Який масштаб? Які дані потенційно скомпрометовані? Зверніться до хостинг-провайдера — вони часто можуть допомогти з аналізом.

Крок 3 — Відновлення. Відновіть сайт із чистого бекапу (зробленого до зламу). Змініть усі паролі, ключі та токени. Виявіть і усуньте вразливість, через яку стався злам.

Крок 4 — Повідомлення. Якщо були скомпрометовані персональні дані клієнтів — у більшості юрисдикцій (включно з GDPR для роботи з європейськими клієнтами) є обов'язок повідомити про це протягом 72 годин. Юридична консультація тут обов'язкова.

Крок 5 — Аналіз і покращення. Що дозволило зламу відбутись? Які заходи запобігли б йому? Впровадьте покращення, щоб не повторити ситуацію.

Частина 8: Юридичні вимоги і відповідальність

GDPR і захист персональних даних

Якщо ваш сайт збирає або обробляє будь-які персональні дані громадян ЄС (включно з українськими бізнесами, що мають клієнтів з ЄС) — GDPR поширюється на вас.

Основні вимоги, що стосуються безпеки:

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

Повідомлення про витік даних — регулятора протягом 72 годин, постраждалих осіб — без зайвих затримок.

Мінімізація даних — збирайте тільки ті дані, що справді потрібні.

Право на видалення ("право бути забутим") — можливість для клієнта вимагати видалення своїх даних.

Штрафи за порушення GDPR — до 4% річного глобального обороту компанії або 20 мільйонів євро (залежно від більшого). Для малого бізнесу це може бути екзистенційна загроза.

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

PCI DSS для інтернет-магазинів

Якщо ваш сайт приймає платіжні картки — PCI DSS (Payment Card Industry Data Security Standard) є обов'язковим стандартом безпеки.

Найпростіший спосіб дотриматись PCI DSS для малого e-commerce: використовувати сертифікованого платіжного провайдера (LiqPay, WayForPay, Stripe) і не зберігати дані карток у власній системі. Платіжна сторінка на стороні провайдера — вся відповідальність за безпеку картних даних лежить на ньому, а не на вас.

Частина 9: Практичний чеклист безпеки

Щоденні і щотижневі задачі

Безпека — це не одноразовий захід, а постійна дисципліна. Ось мінімальний набір регулярних дій:

Щодня: перевіряйте сповіщення від систем моніторингу, перевіряйте Google Search Console на попередження.

Щотижня: перевіряйте і встановлюйте оновлення плагінів і тем (після створення бекапу), переглядайте журнали помилок і підозрілу активність.

Щомісяця: перевіряйте список адміністраторів і користувачів — чи немає незнайомих акаунтів, запускайте сканування Sucuri SiteCheck, перевіряйте, що автоматичні бекапи справді виконуються.

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

Повний чеклист безпеки для малого бізнесу

Базовий захист: — HTTPS увімкнено, HTTP перенаправляється на HTTPS — SSL-сертифікат дійсний і автоматично оновлюється — CMS, плагіни і теми на актуальних версіях — Невикористовувані плагіни і теми видалено — Стандартне ім'я "admin" змінено на унікальне — Всі паролі унікальні і складні (16+ символів) — Менеджер паролів використовується всією командою — 2FA увімкнена на адмінці сайту, хостингу, домені, email

Захист сервера: — Хостинг з ізоляцією акаунтів і вбудованим захистом — WAF налаштований (Cloudflare або аналог) — HTTP Security Headers налаштовані — Права доступу до файлів правильно встановлені — SFTP замість FTP — URL адмін-панелі змінено на нестандартний

Резервні копії: — Автоматичні бекапи налаштовані (щодня або щотижня) — Бекапи зберігаються в незалежному сховищі (offsite) — Кілька версій бекапів (мінімум 30 днів) — Тест відновлення з бекапу проведено і успішний

Email і фішинг: — SPF запис налаштований — DKIM налаштований — DMARC налаштований — Команда навчена основам захисту від фішингу

Моніторинг: — Google Search Console підключена і перевіряється — Uptime-моніторинг налаштований — Сканування на шкідливий код проводиться регулярно

Висновок: безпека — це звичка, а не подія

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

Більшість кіберінцидентів з малим бізнесом — передбачувані і запобіжні. Свіжі оновлення, надійні паролі з 2FA, автоматичні бекапи і базовий WAF — це не складно і не дорого. Але відсутність цих речей перетворює ваш сайт у легку мішень для автоматизованих атак.

Почніть з чеклісту. Виправляйте найбільш критичні прогалини першими. Автоматизуйте, що можна автоматизувати. І пам'ятайте: вартість превентивних заходів завжди нижча за вартість відновлення після злому — і незрівнянно нижча за вартість втрати репутації і довіри клієнтів.

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