Оптимізація продуктивності спрямована на “швидше”, але реальний результат для веб-сайтів полягає у двох речах:

  • поручительствоНамагайтеся не потрапляти в неприємності (не бути зламаними, не зависати, не розбиватися, не стирати інтерфейси, не втручатися в роботу)
  • створюю резервну копіюшвидке відновлення, навіть якщо щось піде не так (випадкове видалення, відкат оновлення, збій сервера, відкат після викупу/вторгнення)

Наступні дві речі доповнюють одна одну:

  • Якщо ви займаєтеся лише безпекою, але не резервним копіюванням, ви все одно можете вийти на нуль за одну ніч, якщо зіткнетеся з неконтрольованими проблемами.“
  • Якщо ви робите тільки резервні копії, але не забезпечуєте безпеку, ви потрапите в цикл “щодня отримуєте удари і щодня відновлюєтесь”, а час і витрати будуть неконтрольованими!

Ви зможете це зробити після прочитання:

  • Знати, що саме покривається “резервним копіюванням та безпекою” (щоб не купити не те, що потрібно, не встановити не те і не думати, що воно надійне).
  • Можливість вибору правильного рішення за типом сайту (контент-сайт/бізнес-сайт/сайт електронної комерції/сайт членства)
  • Здатність поступово переходити до життя за дорожньою картою (стійкість, потім контрольованість, потім систематичність)
  • Можна перевірити за допомогою контрольного списку для самоперевірки: резервна копіяЦе дійсно можна відновити.БезпекаЗахист дійсно є.
  • Знати, де шукати в першу чергу, коли виникають проблеми (збій резервного копіювання, збій відновлення, підозра на злом тощо)

1. мета: Вам потрібна “відновлювана система”, а не “плагін”.”

Резервне копіювання - це не просто “наявність файлу резервної копії”.”

Натомість:Чи можете ви повернути сайт до бажаного вигляду, коли вам це потрібно。

Отже, ключовим показником резервного копіювання є не “встановлений плагін для резервного копіювання”, а ці дві речі:

  • Вікно допустимої втрати даних (RPO)Як довго ви можете миритися з втратою даних у найгіршому випадку?
    Приклад: втрата статей протягом 24 годин на контент-сайті може бути прийнятною; втрата замовлень протягом 30 хвилин на сайті електронної комерції - це серйозно.
  • Прийнятний час відновлення (RTO)Як швидко ви плануєте повернутися до роботи після аварії?
    Приклад: корпоративний сайт може потребувати відновлення протягом 1 години; сайт електронної комерції може потребувати відновлення протягом 10-30 хвилин.

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

2. швидка розробка стратегії за типом сайту (орієнтація, потім вибір інструментів)

Стратегічні поради:

A. Інформаційні сайти / блоги

  • Частота змін: зазвичай “щодня/щотижня”
  • Рекомендована частота резервного копіювання:повсякденнийРезервна копія бази даних + wp-контент (завантаження/теми/плагіни)
  • Мета відновлення: Достатньо вчорашньої/сьогоднішньої версії (з акцентом на те, щоб не втратити статті та медіатеку).

B. Бізнес-сайт / маркетинговий сайт (важливими є анкетні дані)

  • Частота змін: не обов'язково висока, але форми/посилання є критично важливими
  • Рекомендована частота резервного копіювання: база даних щонайменшеповсякденнийДані форми та електронної пошти/CRM не будуть знаходитися “в одному місці”.”
  • Мета відновлення: швидкий відкат у разі виникнення проблем зі скриптами відстеження оновлення/виправлення/додавання

C. Сайт електронної комерції (WooCommerce)

  • Частота змін: замовлення/інвентаризація/поведінка користувачів постійно
  • Рекомендована частота резервного копіювання: бажанавища частота(погодинно, або навіть в режимі реального часу/ближче до реального часу), принаймні, зробіть захист бази даних сильним
  • Мета відновлення: Мінімальна втрата даних про замовлення; можливість швидко відновити посилання на оплату/замовлення

D. Членський сайт / сайт курсів / спільнота

  • Частота змін: прогрес користувача, дозволи, розблокування контенту, дані про взаємодію
  • Рекомендована частота резервного копіювання: вища частота для баз даних; з точками відновлення “у часі”
  • Мета відновлення: користувацькі дані не зіпсовані, дозволи не втрачені, а вміст не підроблений

3. резервна дорожня карта (рекомендується рухатися вперед у цих 3 фазах)

Основні моменти:Давайте спочатку зробимо “спроможне відновлення”, а потім поговоримо про “автоматизацію та систематизацію”.

Етап 1: Почніть з “Автоматичне резервне копіювання + віддалене зберігання”

Ось у чому суть. Яким би інструментом ви не користувалися, знайомтеся з ним:

  • автоматичний:: Не покладайтеся на “я не забуду натиснути його вручну”.”
  • зберігання за межами майданчика: Не зберігайте резервні копії на одному сервері
    Причина дуже проста: сервер зависає/диск зламався/обліковий запис було зламано, щоб видалити бібліотеку, ваша “локальна резервна копія” може зникнути разом з ним.

Типові реалізації інструменту включають в себе наступні:

  • Плагін резервного копіювання виштовхує резервні копії на хмарний диск/об'єктне сховище/FTP (UpdraftPlus (Наприклад, явно підтримуються Dropbox, Google Drive, Amazon S3 та багато інших цілей).
  • Хмарний сервіс резервного копіювання зберігає резервні копії у своїй хмарі та пропонує відновлення в один клік (Резервне копіювання Jetpack VaultPress (Переважно хмарне резервне копіювання та відновлення в один клік, але необхідно включити платний план для резервного копіювання)

Етап 2: Оновлення резервних копій до “відновлюваних систем”

Багато сайтів дійсно падають, але не через відсутність резервних копій, а через:

  • Неповне резервне копіювання (тільки бази даних, але не завантажень/тем/плагінів)
  • Пошкоджений файл резервної копії/неправильні дозволи
  • Коли вам потрібно відновитися, ви розумієте, що “процес відновлення просто не працює”.”

Отже, завданням фази 2 є наступне:Регулярно виконуйте відновлювальні вправи(навіть у тестовому середовищі/відновлення тимчасового каталогу), перевірте наступні пункти:

  • База даних може бути відновлена.
  • Медіатеку можна відновити (wp-content/uploads/）
  • Теми/плагіни можна відновити (wp-content/themes/、wp-content/plugins/）
  • Після відновлення до сайту можна отримати нормальний доступ, увійти в бекенд і запустити ключові функції (електронну комерцію для тестування процесу замовлення/оплати, а також сайт для членів для тестування входу/дозволів).

Ось чому багато комерційних рішень для резервного копіювання наголошують на “відновленні в один клік”, “похвилинному відновленні” та “інкрементному резервному копіюванні для зменшення навантаження”. Наприклад BlogVault В описі плагіна підкреслюється, що передбачено **автоматичне, інкрементне резервне копіювання (включаючи бази даних, теми, плагіни, медіа)** та функції стадіювання/міграції.ManageWP Акцент також робиться на зменшенні навантаження за допомогою методів інкрементного резервного копіювання та можливості відновлення в один клік.

Етап 3: Прив'яжіть резервні копії до процесу оновлення/випуску (точка відкату)

На цьому етапі ваша мета:Точка відкату перед кожною великою зміною。

Типові сценарії включають

  • Оновлення основної версії ядра WordPress
  • Зміна теми/реконструкція шаблону
  • Встановлення або заміна ключових плагінів (платежі електронної комерції, системи членства, системи форм)
  • Пакетна заміна зображень / масова міграція контенту

Суть 3-го етапу полягає в тому, що вам не потрібно “молитися, щоб зміни пройшли добре”, а скоріше в тому, що ви можете швидко відкотитися до “моменту до змін”, якщо зміни підуть не так, як треба.

4. що саме створювати резервну копію (багато людей, які створюють резервні копії, пропустили ці ключові моменти)

Суть 1: База даних (куди потрапляють замовлення/користувачі/контент/налаштування)

  • Статті, сторінки, коментарі
  • Користувачі, дозволи
  • WooCommerce Замовлення, інвентаризація, купони
  • Плагіни конфігурацій (велика кількість конфігурацій, що зберігаються в базі даних)

Важливо 2: wp-контент (це основна частина “видимих активів” сайту на WordPress)

  • uploadsзображення, вкладення, медіатека (найпростіше місце, де можна “забути зробити резервну копію”)
  • themes: Файли тем (кастомний код/шаблони)
  • plugins: файли плагінів (деякі плагіни також пишуть власні файли)

За необхідності: інформація про конфігурацію та операційне середовище

Не ігноруйте відмінності в навколишньому середовищі:

  • Відмінності у версіях PHP можуть спричинити помилки після відновлення
  • Певні відмінності між компонентами розширення/кешу можуть призвести до різної поведінки
  • Правила безпеки зворотного проксі/CDN/security можуть впливати на вхід та інтерфейс бекенда

Відновлення - це не просто повернення файлу, а й забезпечення підтримки операційного середовища та конфігурації для його запуску.

5. вибір програми резервного копіювання

Тип A: Плагін для резервного копіювання за розкладом (підходяще початкове рішення для більшості сайтів)

Характеристики: низька вартість, контрольованість, швидке розгортання; але вам доведеться добре підготуватися до “зберігання за межами майданчика + тренування з відновлення”.

Інструменти репрезентації:

  • UpdraftPlusОсновна увага приділяється резервному копіюванню та відновленню за розкладом, з явною підтримкою декількох цілей резервного копіювання (Dropbox, Google Drive, Amazon S3, FTP, електронна пошта і т.д.) на сторінці плагіна.
    Ідеально підходить для: контент-сайтів/бізнес-сайтів, які тільки починають свою діяльність; і сайтів, яким потрібні “резервні копії у власному контрольованому сховищі”.
  • Резервне копіювання та міграція WPvivid: На сторінці плагіна показано резервні копії, міграції та стадії (стадії можна створити у підкаталозі для тестування змін).
    Ідеально підходить для: людей, які часто мігрують сайти і часто потребують тестування змін на спеціальній основі.
  • Дублікатор: Сторінка плагіна присвячена резервному копіюванню/пакуванню/міграції/клонуванню сайтів на нові хости або нові домени.
    Ідеально підходить для: міграції, реплікації сайтів, створення тестових майданчиків, створення “переміщуваних пакетів”.

UpdraftPlus - це скоріше “стартер системи резервного копіювання”.”

WPvivid/ Duplicator краще справляється з “міграцією/пакуванням/копіюванням”, але також може робити резервні копії.

Тип B: Хмарне резервне копіювання / резервне копіювання в режимі реального часу (більше підходить для сайтів, які є більш чутливими до даних і часу відновлення)

Особливості: Акцент на “захист від кожної зміни/високочастотних змін” та “відновлення в один клік”, більше схоже на набір послуг.

Інструменти репрезентації:

  • Резервне копіювання Jetpack VaultPress (Jetpack Backup): Сторінка плагіна наголошує на хмарному резервному копіюванні та відновленні в один клік, і явно вимагає платний план Jetpack, який включає резервне копіювання, чийНа офіційній сторінці підписки також висвітлено“Зберігайте кожну зміну, швидко повертайтеся до придатного для використання стану за допомогою відновлення в один клік”.
    Ідеально підходить для: електронної комерції / членства / сайтів, які чутливі до “швидкості відновлення”, або для тих, хто хоче передати операції резервного копіювання на аутсорсинг зрілому сервісу.
  • BlogVault: В описі плагіна чітко вказано, що він передбачає “автоматичне, безпечне, інкрементне резервне копіювання (баз даних, тем, плагінів, мультимедіа)” з вбудованими можливостями створення та міграції.
    Ідеально підходить для: Сайтів, де “Резервне копіювання + тестування + міграція” є повним робочим процесом.
  • ManageWP: Акцент на інкрементних методах резервного копіювання, щоб зменшити навантаження на сервер і забезпечити відновлення в один клік.
    Ідеально підходить для: людей (студій/команд), які керують кількома сайтами і хочуть робити резервні копії/оновлення/моніторинг в одній панелі в уніфікований спосіб.

Тип C: Знімок на стороні хоста/автоматичне резервне копіювання (настійно рекомендується як “друга лінія страхування”)

Цінність резервної копії хоста: це, як правило, “знімок на рівні системи” з більш широким охопленням (включаючи стан баз даних і файлів, і навіть оточення на певному рівні).

Поширені помилки:

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

Тому, як правило, це найбільш стабільна комбінація:

Резервне копіювання на хостингу (під капотом) + плагін/хмарне резервне копіювання (прикладний рівень мігрує + гранульовані точки відновлення)

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

Безпека - це не про “встановлення десяти плагінів”, це про побудову захисту на пошаровій основі:

Етап 1: Облікові записи та привілеї (найбільші та безпосередні переваги)

На цьому етапі вам потрібно “ускладнити найпоширеніші точки входу”:

  • Мінімізація облікового запису адміністратора: тільки для тих, кому це потрібно
  • Надійна політика паролів: не використовуйте повторно, не використовуйте слабкі паролі
  • 2FA (двоетапна перевірка)Це одне з найефективніших удосконалень в епоху “зломів/витоків паролів”.
    наприклад Надійна безпека Сторінка плагіна явно підтримує декілька методів 2FA (автентифікація, Google Authenticator, електронна пошта, альтернативні коди тощо).
  • Захист логінів: обмежте спроби грубого підбору, уникайте підроблених логінів
  • Облікові записи, які не використовуються, вимкнено/видалено; теми/плагіни, які більше не використовуються, видалено (не тільки деактивовано)

Етап 2: Оновлення та управління ризиками (не залишайте ризики в старих версіях)

Велика кількість вторгнень в WordPress відбувається через “старі плагіни/теми/ядро з загальнодоступними вразливостями”.

Тому “оновлення” є одним з ключових аспектів стратегії безпеки.
У документації WordPress згадується впровадження автоматичних фонових оновлень з WordPress 3.7 для покращення безпеки, а також зазначається, що автоматичні оновлення ввімкнені за замовчуванням на більшості сайтів, а з 5.6 Запуск нового сайту автоматично ввімкненоСтратегії, такі як великі та малі оновлення версій.

Принципи:

  • Ядро/теми/плагіни повинні мати чітку стратегію оновлення (автоматичний/напівавтоматичний/ручний перегляд)
  • Точки відкату перед основними оновленнями (поверніться до Розділу 3, “Етап резервного копіювання 3”)
  • Плагіни, які більше не підтримуються, слід замінити якомога швидше (це найпряміший спосіб “зменшити ризик”).

Етап 3: Захист і виявлення (ускладнити успіх атак і виявити аномалії на ранній стадії)

Те, що ви хочете зробити на цьому етапі, - це бути “більш схожим на систематичний захист”:

  • Firewall/WAF (блокування частини небажаного трафіку до того, як запит потрапить до WordPress)
  • Сканування шкідливого коду, моніторинг цілісності файлів
  • Журнали безпеки та сповіщення: аномальні входи, зміни привілеїв, змінені файли
  • Моніторинг: моніторинг простоїв, закінчення терміну дії сертифікатів, аномальні 5xx, аномальні сплески трафіку

Інструменти репрезентації:

  • Wordfence: На сторінці плагіна чітко вказано, що він включає брандмауер, сканування на шкідливе програмне забезпечення та безпеку входу в систему, а також зазначено, що Premium отримує оновлення правил брандмауера та сигнатур шкідливого програмного забезпечення в режимі реального часу, тоді як безкоштовна версія має 30-денну затримку.
    Рекомендація: безкоштовна версія значно покращує базовий рівень безпеки, але якщо ваш сайт є більш ризикованим або більше покладається на “актуальні дані про загрози”, зрозумійте різницю в “затримках оновлення”.
  • Patchstack(ідеї щодо віртуального виправлення/захисту від експлойтів): На його офіційному сайті наголошується на захисті сайтів від вразливих плагінів/тем за допомогою віртуальних патчівPatchstackа також є інструкції для безкоштовної версії щодо надання сповіщень про вразливості, для платної версії - щодо автоматизованого захисту від вразливостей та інші ідеї.
  • Сукурі.(Прибирання та обслуговування безпеки)На сторінці сервісу наголошується на очищенні від шкідливого програмного забезпечення з можливістю безперервного сканування/блокування майбутніх вторгнень Sucuri.

7. попередження про ризики

Високочастотні пастки, пов'язані з резервним копіюванням

  1. Резервні копії зберігаються лише на сервері
    Коли сервери виходять з ладу, локальні резервні копії часто зникають разом з ними.
  2. Тільки база даних, а не wp-вміст
    Після відновлення ви побачите, що допис є, а зображення зникло; або тема не налаштована; або файли плагінів не узгоджуються, що призводить до помилки.
  3. Ніколи не проводьте тренування з відновлення.
    Лише в критичний момент ви усвідомлюєте, що відновлення не вдалося, резервна копія пошкоджена або важливі файли відсутні.
  4. Частота резервного копіювання не відповідає потребам бізнесу
    На сайтах електронної комерції/сайтах для членів, які виконують резервне копіювання один раз на день, в гіршому випадку ви можете втратити дані про замовлення/поведінку користувачів за один день, а це може значно перевищити вартість резервного копіювання.

Високочастотні ями, пов'язані з безпекою

  1. Плагін безпеки встановлено, але він давно не оновлювався
    Плагіни безпеки не замінюють оновлення. Старі вразливості все ще існують, і ризик нікуди не зникне.
  2. Забагато облікових записів адміністратора/спільних облікових записів
    Дозволи вийшли з-під контролю, логи важко відстежити, а передача даних при виході з системи є ризикованою.
  3. Думка “WAF/CDN безпечний”.”
    Брандмауери можуть зупинити багато типових атак, але вони не можуть виправити слабкі паролі, старі вразливості, плагіни бекдорів і т.д. Найбезпечнішим підходом є “багаторівневий захист”. Найбезпечніше - це мати "багаторівневий захист".
  4. Використання декількох плагінів безпеки, які конфліктують між собою, також уповільнює роботу сайту
    Політики безпеки повинні мати пріоритет “менше - це більше”: 2FA + оновлені політики + брандмауер/сканування + сповіщення; а не “чим більше ви встановлюєте, тим більше ви захищені”.

8. контрольний список перевірки

Перевірка резервної копії (не кажіть “у мене є резервна копія”, якщо не пройдете ці 8 пунктів)

  • Чи ввімкнено автоматичне резервне копіювання (не вручну)
  • Чи містить резервна копія базу даних + wp-вміст (завантаження/теми/плагіни)
  • Чи зберігаються резервні копії за межами сайту (хмарний диск/об'єктне сховище/автономний сервер)
  • Чи існує чітка стратегія утримання (наприклад, утримання протягом 7/30/90 днів)?
  • Чи було останнє резервне копіювання успішним (не “розклад існує”)
  • Коли були останні відновлювальні вправи? Чи було воно успішним?
  • Чи створюється додаткова точка відкату перед великим оновленням?
  • Доступність критичного шляху після відновлення (логін, форми, електронні замовлення/доступ до членства тощо)

Перевірка безпеки (спочатку вивчіть основи)

  • Чи мінімізовано обліковий запис адміністратора? Чи існує механізм очищення вихідних рахунків?
  • Увімкнути або вимкнути 2FA(принаймні адміністратор/редактор/менеджер магазину з високими повноваженнями)
  • Чи існує чіткийОновлення стратегії(Ядро/теми/плагіни)
  • Чи потрібно видаляти невикористовувані плагіни/теми (а не просто деактивувати їх)
  • Наявність брандмауера/захисту входу/зловмисного сканування (Wordfence (і т.д. може охоплювати частину)
  • Наявність сповіщень про вразливості/ідей віртуальних патчів (Patchstack тощо).
  • Наявність сповіщень (аномальні входи, зміни файлів, простої, закінчення терміну дії сертифікату)
  • Наявність “планів на випадок непередбачуваних ситуацій”: що робити в першу чергу у випадку злому/втручання

загальні проблеми

1. чи достатньо використовувати лише власну резервну копію хоста?

Зазвичай не рекомендується покладатися лише на одне джерело.
Резервне копіювання на хостингу - це чудово, але воно не обов'язково полегшить вам процес “вилучення, міграції та відкату”. Це більш стабільно:Резервне копіювання на хостингу для підтримки + резервне копіювання через плагін/хмару для міграції та контрольованих точок відновлення。

2. як часто я повинен створювати резервні копії?

За “швидкістю зміни даних”:

  • Контент сайтів: зазвичай достатньо на день
  • Корпоративний сайт: щодня (особливо якщо є контактні дані) і підтверджувати, що ліди знаходяться не тільки на сайті
  • Електронна комерція / членство: рекомендується більш високочастотний (погодинний або навіть близький до реального часу), оскільки дані про замовлення/користувачів є більш цінними

3. як довго потрібно зберігати резервні копії?

Залежно від контенту та потреб у дотриманні вимог, ви можете використовувати цю ідею:

  • Зберігайте принаймні 7-30 днів для регулярного відкату
  • Якщо ви стурбовані “прихованими бекдорами/хронічним втручанням”, краще продовжити цикл (наприклад, до 90 днів), щоб ви могли повернутися до більш ранньої, чистої версії.

4. чи є UpdraftPlus / WPvivid / Duplicator “тим самим”?

Вони обидва підтримують, але з різними акцентами:

  • UpdraftPlus Більш типовим є “Заплановане резервне копіювання + багатоцільове зберігання + відновлення”.”
  • WPvivid Акцент на резервне копіювання + міграція + стадіювання Можливості тестування
  • Дублікатор Дуже сильний у “пакуванні/міграції/клонуванні сайту”

Якщо ви використовуєте “тип” для вибору, вас не заплутає назва.

5. чому я повинен платити за резервне копіювання Jetpack Backup? Для чого він потрібен?

Оскільки це, по суті, більше “хмарний сервіс резервного копіювання” - з акцентом на збереження в хмарі і відновлення в один клік - на сторінці плагіна явно має бути вказано Плани оплати за резервне копіюванняНа офіційній сторінці підписки наголошується на збереженні кожної зміни та швидкому відновленні в один клік.
Ідеально підходить для: людей, які більш чутливі до швидкості відновлення і хочуть залишити резервне копіювання та обслуговування зрілому сервісу.

6. у чому сенс “інкрементних резервних копій”, таких як BlogVault / ManageWP?

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

  • Плагін BlogVaultІнструкції наголошують на автоматичному, інкрементному резервному копіюванні та перезапису баз даних/тем/плагінів/медіа, з вбудованими функціями стадійності та міграції;
  • ManageWP Інкрементні методи резервного копіювання також використовуються для зменшення навантаження та забезпечення відновлення в один клік.

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

7. чи достатньо одного плагіна безпеки?

Для більшості сайтів “один основний плагін безпеки + правильна базова політика” зазвичай ефективніше, ніж “кілька плагінів”.
наприклад Wordfence Може охоплювати базові можливості, такі як брандмауер, сканування та безпека входу в систему; в поєднанні з 2FA(Solid Security пропонує безліч способів зробити це), вже може значно підвищити вартість атаки.

8. чи працює безкоштовна версія Wordfence? Чому деякі люди говорять про перехід на Premium?

Сторінка плагіна WordfenceЗрозумілість: Преміум надає оновлення правил брандмауера та сигнатур шкідливих програм у режимі реального часу, тоді як безкоштовна версія затримує їх на 30 днів.
Чи потрібен вам Преміум, залежить від вашого рівня ризику та толерантності:

  • Сайти з низьким рівнем ризику: безкоштовна версія + своєчасні оновлення + 2FA, зазвичай вже корисні!
  • Вищий ризик або більша залежність від “актуальних даних про загрози”: необхідність розуміти вікно можливостей, яке можуть створити “запізнілі оновлення”

9. що саме вирішує “віртуальний патч” на кшталт Patchstack?

Ідея полягає в тому, що правила використовуються для блокування поверхні атаки відомих вразливостей на рівні додатків до того, як вразливості плагіна/теми будуть використані (або до того, як патчі будуть повністю поширені).Офіційний сайт PatchstackАкцент на віртуальному захисті вразливих плагінів/тем з поясненням різниці між безкоштовними/платними оповіщеннями та автоматизованим захистом.
Це не заміна оновленню, а спосіб мінімізувати ризик появи “вікна виправлень”.

10. чи заблокуюся я, якщо активую 2FA?

Рекомендується підготуватися заздалегідь:

  • Альтернативний код/метод відновлення (Надійна безпека (також були згадані такі програми, як коди backup)
  • Підтримуйте щонайменше одного “аварійного менеджера” та захистіть інформацію про відновлення
  • Ключовий момент: не зберігайте інформацію для відновлення в тому ж місці, де до неї може дістатися зловмисник

11. чи потрібно вмикати автоматичне оновлення WordPress чи ні?

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

  • Безпека та незначні оновлення версій: як правило, автоматизовані (зменшують час на виявлення відомих вразливостей)
  • Основні релізи/критичні оновлення плагінів: об'єднайте точки відкату резервної копії з тестовим процесом перед тим, як рухатися далі (принаймні, щоб мати можливість відкоту)

12. що робити, якщо я підозрюю, що веб-сайт був зламаний?

Правильний порядок (щоб уникнути більшого безладу):

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

13. я займаюся безпекою та резервним копіюванням, навіщо мені моніторинг?

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