Оптимизацията на производителността е насочена към “по-бързото”, но истинската цел на уебсайтовете е свързана с две неща:

  • поръчителство: Опитайте се да не се забърквате в неприятности (не се хаквайте, не се закачайте, не се сривайте, не си сменяйте интерфейсите, не се подправяйте)
  • архивиране: бързо възстановяване, дори ако нещо се обърка (случайно изтриване, преобръщане на ъпгрейд, повреда на сървъра, връщане назад след откуп/взлом)

Следните две неща се допълват взаимно:

  • Ако се занимавате само със сигурност, но не и с резервни копия, все още можете да преминете към нулево ниво за една нощ, ако срещнете неконтролируеми проблеми.“
  • Ако правите само резервни копия, но не и сигурност, ще попаднете в цикъла “всеки ден се удря и всеки ден се възстановява”, а времето и разходите ще бъдат извън контрол!

Трябва да можете да го направите, след като го прочетете:

  • Да знаете какво точно да покриете с “архивиране и сигурност” (за да избегнете закупуването на грешна система, инсталирането на грешна система и приемането ѝ за безотказна)
  • Възможност за избор на подходящо решение според типа на сайта (сайт за съдържание/бизнес сайт/електронна търговия/сайт за членство)
  • Възможност за постепенна реализация на пътна карта (устойчива, след това контролируема, след това систематична)
  • Може да се провери с контролен списък за самотестване: резервно копиеНаистина може да се възстанови.ЗащитаНаистина има защита.
  • Знаете къде да търсите първо при възникване на проблеми (отказ на архивиране, отказ на възстановяване, съмнение за хакерска атака и др.)

1. Цел: Нуждаете се от “възстановима система”, а не от “приставка”.”

Резервните копия не са свързани с “наличието на файл за резервно копие”.”

Вместо това:Можете ли да върнете сайта в желаното състояние, когато имате нужда от него。

Така че ключовият индикатор за архивиране не е “инсталиран плъгин за архивиране”, а тези две неща:

  • Приемлив прозорец за загуба на данни (RPO): Колко време можете да приемете загубата на данни в най-лошия случай?
    Пример: сайт за съдържание, който губи статии за 24 часа, може да бъде приемлив; сайт за електронна търговия, който губи поръчки за 30 минути, е сериозен проблем.
  • Приемливо време за възстановяване (RTO): Колко бързо очаквате да бъдете отново онлайн след инцидента?
    Пример: корпоративен сайт може да иска да се възстанови в рамките на 1 час; сайт за електронна търговия може да иска да се възстанови в рамките на 10-30 минути.

Не е необходимо да записвате тези показатели във формула, но ги използвайте, за да вземете решение:Честота на архивиране, време на съхранение, необходимост от архивиране в реално време/инкрементално архивиране, необходимост от възстановяване с едно кликване/възстановяване извън сайта。

2. Разработване на бърза стратегия по видове обекти (ориентация, след това избор на инструменти)

Стратегически съвети:

А. Сайтове за съдържание / блогове

  • Честота на промените: обикновено “ежедневно/седмично”
  • Препоръчителна честота на архивиране:ежедневиеАрхивиране на базата данни + wp-съдържание (качване/теми/включватели)
  • Цел на възстановяването: Вчерашната/днешната версия е достатъчна (с акцент върху това да не се губят статии и медийна библиотека).

Б. Бизнес сайт / маркетингов сайт (формулярите са важни)

  • Честота на промените: не е задължително да е висока, но формулярите/насоките са от решаващо значение
  • Препоръчителна честота на архивиране: база данни понеежедневиеДанните от формуляра и имейлът/CRM няма да са “на едно място”.”
  • Цел за възстановяване: бързо връщане назад в случай на проблеми със скриптовете за проследяване на актуализации/ревизии/добавки

C. Сайт за електронна търговия (WooCommerce)

  • Честота на промените: поръчки/инвентар/поведение на потребителите постоянно
  • Препоръчителна честота на архивиране: предпочитанапо-висока честота(ежечасно или дори в реално време/близо до реално време), поне направете силна защита на базата данни
  • Цел на възстановяването: минимална загуба на данни за поръчките; възможност за бързо възстановяване на връзките между плащанията и поръчките

Г. Сайт за членство / сайт за курсове / общност

  • Честота на промените: напредък на потребителя, разрешения, отключване на съдържание, данни за взаимодействие
  • Препоръчителна честота на архивиране: по-висока честота за базите данни; с точки за възстановяване “точка-в-времето”
  • Цел на възстановяването: потребителските данни не са повредени, разрешенията не са загубени и съдържанието не е подправено.

3. Пътна карта за архивиране (препоръчва се да продължите напред в тези 3 фази)

Акценти:Нека първо направим “способно възстановяване”, а след това да говорим за “автоматизация и систематизация”.

Етап 1: Започнете с “Автоматично архивиране + съхранение извън сайта”

Това е основното. Без значение какъв инструмент използвате, той трябва да бъде изпълнен:

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

Типичните реализации на инструмента включват:

  • Плъгинът за архивиране избутва резервни копия в облачно устройство/съхранение на обекти/FTP (UpdraftPlus (Например, Dropbox, Google Drive, Amazon S3 и много други цели се поддържат изрично).
  • Услугата за архивиране в облак поставя резервни копия в своя облак и предлага възстановяване с едно кликване (Jetpack VaultPress Backup (Основно архивиране в облака и възстановяване с едно кликване, но трябва да включите платен план за архивиране)

Етап 2: Надграждане на резервните копия до “възстановими системи”

Много сайтове наистина се преобръщат не поради липса на резервни копия, а поради:

  • Непълно архивиране (само на базата данни, не и на качвания/теми/включватели)
  • Повреден файл за резервно копие/неправилни разрешения
  • Когато трябва да се възстановите, осъзнавате, че “процесът на възстановяване просто не работи”.”

Целите на фаза 2 са:Правете редовно упражнения за възстановяване(дори в тестова среда/възстановяване на временна директория), потвърдете следните точки:

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

Ето защо много търговски решения за архивиране наблягат на “възстановяване с едно кликване”, “възстановяване минута по минута” и “инкрементални архиви за намаляване на натоварването”. Например BlogVault В описанието на плъгина е подчертано, че са осигурени **автоматични, инкрементални резервни копия (включително бази данни, теми, плъгини, медии)** и функции за поетапно мигриране.ManageWP Набляга се и на намаляването на натоварването с техники за инкрементално архивиране и осигуряване на възстановяване с едно кликване.

Етап 3: Обвързване на резервните копия с процеса на актуализиране/изпускане (точка на връщане)

На този етап целта ви е:Точка на оттегляне преди всяка голяма промяна。

Типичните сценарии включват:

  • Надграждане на основната версия на WordPress
  • Промяна на темата/прекратяване на шаблона
  • Инсталиране или подмяна на ключови плъгини (плащания за електронна търговия, системи за членство, системи за формуляри)
  • Пакетна замяна на изображения / масова миграция на съдържание

Смисълът на Етап 3 е, че не е необходимо да се “молите промяната да е наред”, а по-скоро да можете бързо да се върнете към “момента преди промяната”, ако тя се обърка.

4. Архивиране на какво точно да се архивира (много хора, които архивират, пропускат тези ключови точки)

Основно 1: База данни (където се съхраняват поръчките/потребителите/съдържанието/настройките)

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

Същност 2: wp-content (това е основната част от “видимите активи” на сайта на WordPress)

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

По целесъобразност: информация за конфигурацията и работната среда

Не пренебрегвайте различията в околната среда:

  • Разликите във версиите на PHP могат да доведат до отчитане на грешки след възстановяване
  • Специфичните разлики между разширенията/компонентите на кеша могат да доведат до различно поведение
  • Правилата за обратен прокси сървър/CDN/сигурност могат да повлияят на влизането в системата и на интерфейса на бекенда

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

5. Избор на програма за архивиране

Тип А: Включени резервни копия по време (подходящо решение за стартиране за повечето сайтове)

Характеристики: ниски разходи, контролируемост, бързо внедряване; но трябва да се направи солидна тренировка за съхранение и възстановяване извън сайта.

Инструменти за представяне:

  • UpdraftPlus: Основният фокус е върху архивирането и възстановяването на планирани задачи с изрична поддръжка на множество цели за архивиране (Dropbox, Google Drive, Amazon S3, FTP, имейл и т.н.) на страницата на плъгина.
    Идеален за: стартиращи сайтове със съдържание/бизнес сайтове и сайтове, които искат да правят резервни копия в собственото си контролирано хранилище.
  • WPvivid архивиране и миграция: Страницата за плъгини показва резервни копия, миграция и етапна проверка (етапна проверка може да бъде създадена в поддиректория за тестване на промените).
    Идеален за: хора, които често мигрират сайтове и често се налага да тестват промени ad hoc.
  • Дубликатор: Страницата с плъгини набляга на архивирането/пакетирането/мигрирането/клонирането на сайтове към нови хостове или нови домейни.
    Идеален за: мигриране, репликиране на сайтове, изграждане на тестови сайтове, създаване на “преместваеми пакети”.

UpdraftPlus е по-скоро “стартова система за архивиране”.”

WPvivid/ Duplicator е по-добър в “миграцията/опаковането/копирането”, но може да прави и резервни копия.

Тип B: Архивиране в облак/близко до реално време (по-подходящо за сайтове, които са по-чувствителни към данните и времето за възстановяване)

Функции: Набляга се на “защита на всяка промяна/високочестотна промяна” и “възстановяване с едно кликване”, по-скоро като набор от услуги.

Инструменти за представяне:

  • Jetpack VaultPress Backup (Jetpack Backup): Страницата на плъгина набляга на архивирането в облака и възстановяването с едно кликване и изрично изисква платен план на Jetpack, който включва Backup, чийтоОфициалната страница за абонамент също така подчертава.“Запазвайте всяка промяна и бързо се връщайте към използваемо състояние с възстановяване с едно кликване”.
    Идеален за: сайтове за електронна търговия/членство/сайтове, които са чувствителни към “скоростта на възстановяване”, или за тези, които искат да възложат операциите по архивиране на зряла услуга.
  • BlogVault: Описанието на плъгина изрично включва “автоматични, сигурни, инкрементални резервни копия (бази данни, теми, плъгини, медии)” с вградени възможности за постановка и миграция.
    Идеален за: Сайтове, в които “Архивиране + Тест + Миграция” е пълен работен процес.
  • ManageWP: Акцентирайте върху техниките за инкрементално архивиране, за да намалите натоварването на сървъра и да осигурите възстановяване с едно кликване.
    Идеален за: хора (студия/екипи), които управляват няколко сайта и искат да правят резервни копия/актуализации/мониторинг в един панел по унифициран начин.

Тип C: моментна снимка/автоматично архивиране от страна на хоста (силно препоръчително като “втора линия на застраховка”)

Стойността на резервното копие на хоста: то обикновено е “моментна снимка на системно ниво” с по-широк обхват (включително състоянието на базите данни и файловете, и дори на средата на определено ниво).

Често срещани погрешни схващания:

  • Архивиране на хост ≠ Мигриращо архивиране: Резервните копия на хостинга може да не са удобни, когато сменяте хоста или се налага да изнесете резервните си копия.
  • Резервните копия на плъгини са по-мигриращиРезервните копия попадат в хранилище, което можете да контролирате, което прави възстановяването в различни среди по-гъвкаво.

Затова най-стабилната комбинация обикновено е:

Хоствано архивиране (под капака) + Plugin/Cloud Backup (мигриращ слой на приложението + гранулирани точки за възстановяване)

6. пътна карта на сигурността (започнете с най-ефективните основи, а не с множество приставки)

Сигурността не се изразява в “инсталиране на десет приставки”, а в изграждане на защити слой по слой:

Етап 1: Акаунти и привилегии (най-големи и непосредствени ползи)

Това, което искате да направите на този етап, е да “затрудните най-често срещаните точки за влизане”:

  • Минимизиране на администраторските акаунти: само за тези, които имат нужда от това
  • Политика за силна парола: не използвайте повторно, не използвайте слаби пароли
  • 2FA (проверка в две стъпки)Това е едно от най-ефективните подобрения в епохата на “паролите за срив/изтичане”.
    например Солидна сигурност Страницата на плъгина изрично поддържа множество методи за 2FA (Authy, Google Authenticator, имейл, алтернативни кодове и др.).
  • Защита при влизане: Ограничете опитите за груба сила, избягвайте влизане с подменени данни
  • Неизползваните акаунти са деактивирани/изтрити; изтрити са темите/приставките, които вече не се използват (а не само деактивирани)

Етап 2: Актуализации и управление на експозицията (не оставяйте рисковете в старите версии)

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

Ето защо “актуализирането” е един от основните аспекти на стратегията за сигурност.
В документацията на WordPress се споменава въвеждането на автоматични фонови актуализации от версия 3.7 на WordPress с цел подобряване на сигурността и се посочва, че автоматичните актуализации са активирани по подразбиране на повечето сайтове, а от 5.6 Стартирането на нов сайт се активира автоматичноСтратегии, като например актуализации на големи и малки версии.

Принцип:

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

Етап 3: Защита и откриване (да се затрудни успехът на атаките и аномалиите да се откриват по-рано)

Това, което искате да направите на този етап, е да бъдете “по-скоро систематична защита”:

  • Защитна стена/WAF (блокиране на част от нежелания трафик, преди да стигне до WordPress)
  • Сканиране на зловреден код, наблюдение на целостта на файловете
  • Дневници и сигнали за сигурността: необичайни влизания, промени в привилегиите, променени файлове
  • Мониторинг: мониторинг на престой, изтичане на валидността на сертификата, аномалии 5xx, аномалии в трафика

Инструменти за представяне:

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

7. Сигнали за риск

Високочестотни капани, свързани с архивирането

  1. Резервните копия са локални само за сървъра
    Когато сървърите се повредят, местните резервни копия често изчезват заедно с тях.
  2. База данни само не wp-съдържание
    При възстановяването ще откриете, че: публикацията е въведена, но изображението е изчезнало; или персонализирането на темата е изчезнало; или файловете на плъгина са непоследователни, което води до грешка.
  3. Никога не правете тренировка за възстановяване.
    Едва в критичния момент разбирате, че възстановяването е неуспешно, че резервното копие е повредено или че липсват важни файлове.
  4. Честотата на архивиране не съответства на бизнеса
    При сайтовете за електронна търговия и членство, които правят резервно копие веднъж дневно, в най-лошия случай може да загубите данни за поръчките/поведението на потребителите за един ден, като разходите за това могат да надхвърлят значително разходите за резервното копие.

Високочестотни ями, свързани с безопасността

  1. Инсталирана приставка за сигурност, която не е актуализирана от дълго време
    Плъгините за сигурност не са заместител на актуализациите. Старите уязвимости са налице и рискът няма да изчезне.
  2. Твърде много администраторски акаунти/споделени акаунти
    Разрешенията са извън контрол, логовете са трудни за проследяване, а предаването на изхода е рисковано.
  3. Мислене “WAF/CDN е безопасен”.”
    WAF могат да спрат много общи атаки, но не могат да поправят слаби пароли, стари уязвимости, плъгини със задна врата и т.н. Най-сигурният подход е “многопластова защита”. Най-безопасният подход е "многопластова защита".
  4. Натрупването на множество плъгини за сигурност, които са в конфликт помежду си, също забавя работата на сайта
    Политиките за сигурност трябва да дават приоритет на принципа “по-малко е повече”: 2FA + актуализирани политики + защитна стена/сканиране + предупреждения; а не “колкото повече инсталирате, толкова по-сигурни сте”.

8. Контролен списък за валидиране

Проверка на резервно копие (не казвайте “Имам резервно копие”, ако не преминете тези 8)

  • Дали са разрешени автоматични резервни копия (не ръчни)
  • Дали резервното копие съдържа база данни + wp-съдържание (качвания/теми/включватели)
  • Дали резервните копия се съхраняват извън сайта (устройство в облака/съхранение на обекти/самостоятелен сървър)
  • Има ли ясна стратегия за задържане (напр. 7/30/90 дни задържане)
  • Дали последното резервно копие е било успешно (а не “графикът съществува”)
  • Кога беше последното упражнение за възстановяване? Беше ли успешно?
  • Има ли допълнителна точка за връщане назад, генерирана преди голямата актуализация?
  • Наличност на критичния път след възстановяване (вход, формуляри, достъп до електронна търговия за поръчки/членство и др.)

Валидиране на сигурността (първо се запознайте с основите)

  • Минимизиран ли е акаунтът на администратора? Има ли механизъм за почистване на акаунта при излизане?
  • Включване или изключване 2FA(поне роли на администратор/редактор/ръководител на магазин с високи правомощия)
  • Има ли ясенСтратегия за актуализиране(Ядро/теми/включватели)
  • Дали да премахнете неизползваните плъгини/теми (а не само да ги деактивирате)
  • Наличие на защитна стена/защита от влизане/злонамерено сканиране (Wordfence (и т.н. могат да покриват част от тях)
  • Наличност на сигнали за уязвимости/виртуални идеи за кръпки (Пачстейк и т.н.)
  • Наличност на сигнали (необичайни влизания, промени във файлове, престой, изтичане на сертификат)
  • Наличие на “планове за действие при извънредни ситуации”: каква е първата стъпка, която трябва да се предприеме в случай на хакерска атака/подправяне

общи проблеми

1. Достатъчно ли е да се използва само собственото резервно копие на хоста?

Обикновено не е препоръчително да се разчита само на един източник.
Резервните копия на хостинга са чудесни, но не е задължително да ви улеснят в “отнемането, миграцията и финото връщане”. Това е по-стабилно:Хоствани резервни копия за поддръжка + Plugin/Cloud Backups за миграция и контролирани точки за възстановяване。

2. Колко често трябва да създавам резервни копия?

Според “скоростта на промяна на данните”:

  • Сайтове за съдържание: обикновено достатъчно на ден
  • Сайт на предприятието: ежедневно (особено ако има формуляри) и потвърдете, че потенциалните клиенти не са само на сайта
  • Електронна търговия/членство: препоръчва се по-висока честота (на всеки час или дори почти в реално време), тъй като данните за поръчките/потребителите са по-ценни.

3. Колко дълго трябва да се съхраняват резервните копия?

В зависимост от съдържанието и нуждите за съответствие можете да използвате тази идея:

  • Съхранявайте поне 7-30 дни за редовно връщане
  • Ако сте загрижени за “скрити задни вратички/хронична намеса”, по-ценно е да запазите цикъла по-дълъг (напр. 90 дни), за да можете да се върнете към по-ранна, по-чиста версия.

4. UpdraftPlus / WPvivid / Duplicator “едно и също нещо” ли е?

И двамата се подкрепят, но с различни акценти:

  • UpdraftPlus По-типично е “Планирано архивиране + многоцелево съхранение + възстановяване”.”
  • WPvivid Акцент върху възможностите за архивиране + миграция + стациониране
  • Дубликатор Много силен в “пакет/миграция/клониране на сайт”

Ако използвате “type”, за да изберете, няма да бъдете объркани от името.

5. Защо трябва да плащам за Jetpack Backup? За какво служи?

Тъй като по същество това е по-скоро “услуга за архивиране в облака” - с акцент върху запазването в облака и възстановяването с едно кликване - страницата на плъгина трябва изрично да включва Планове за плащане за резервно копиеНа официалната страница за абонамент се подчертава запазването на всяка промяна и бързото възстановяване с едно кликване.
Идеален за: хора, които са по-чувствителни към скоростта на възстановяване и искат да оставят управлението на резервни копия на зряла услуга.

6. Какъв е смисълът на “инкременталните резервни копия” като BlogVault / ManageWP?

Инкременталните резервни копия са в основата им:Създаване на резервно копие само на промените, което намалява натоварването на сървъра и същевременно позволява генерирането на точки за възстановяване с по-голяма честота.

  • BlogVault PluginВ инструкциите се набляга на автоматичното, поетапно архивиране и презаписване на бази данни/теми/приставки/медии с вградени възможности за преместване и миграция;
  • ManageWP Набляга се и на техниките за инкрементално архивиране, за да се намали натоварването и да се осигури възстановяване с едно кликване.

Идеален за: големи сайтове, много медии, чести актуализации или ако управлявате няколко сайта.

7. Достатъчна ли е една приставка за сигурност?

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

8. Работи ли безплатната версия на Wordfence? Защо някои хора говорят за преминаване към Premium?

Страница на плъгина WordfenceЯснота: Premium осигурява актуализации на правилата на защитната стена и на злонамерените сигнатури в реално време, докато безплатната версия се забавя с 30 дни.
Дали се нуждаете от Premium, зависи от нивото на риска и толерантността ви:

  • Сайтове с нисък риск: безплатна версия + навременни актуализации + 2FA, обикновено вече са полезни!
  • По-висок риск или по-голямо разчитане на “актуална информация за заплахите”: необходимостта да се разбере възможността, която “забавените актуализации” могат да създадат.

9. Какво точно решава “виртуална кръпка” като Patchstack?

Идеята е, че правилата се използват за блокиране на повърхността на атака на известни уязвимости на ниво приложение, преди да бъдат използвани уязвимостите на плъгините/темите (или преди пачовете да са напълно разпространени).Официален уебсайт на PatchstackАкцент върху уязвимите плъгини/теми за защита от виртуални кръпки с обяснения на разликите между безплатните и платените сигнали и автоматичната защита.
Това не е заместител на актуализирането, а начин да се сведе до минимум рискът от “прозорец на кръпките”.

10. Ще се блокирам ли, ако активирам 2FA?

Препоръчително е да се подготвите предварително:

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

11. Трябва ли да се включи или не автоматичното обновяване на WordPress?

Документация на WordPressОбяснете, че механизмът за автоматично фоново актуализиране е предназначен за подобряване на сигурността и е активиран по подразбиране за повечето сайтове, както и че могат да се конфигурират различни видове политики за актуализиране.
Препоръка:

  • Актуализации на сигурността и на второстепенни версии: обикновено са автоматизирани (намаляват времето за разкриване на известни уязвимости).
  • Големи версии/критични актуализации на плъгини: комбинирайте точките за връщане на резервни копия с процес на тестване, преди да продължите напред (поне за да можете да се върнете назад)

12. Каква е първата стъпка, ако подозирам, че даден уебсайт е бил хакнат?

Правилен ред (за да не се получи по-голяма бъркотия):

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

13. Осигурявам сигурност и архивиране, защо ми е необходимо да наблюдавам?

Защото “ранното откриване” намалява загубите.
Прекъсване на работата, изтекли сертификати, необичаен трафик, необичайни влизания, необичайни поръчки - това са все проблеми, за които колкото по-рано разберете, толкова по-добре.