Что нужно поменять, добавить, удалить после того, как разработчик передал вам доступы на ваш новый сайт. Зачем всё это делать и что будет, если пренебречь такими рекомендациями. Делюсь своим чек-листом, что я передаю заказчику после работы над сайтом. Дополняйте, если считаете нужным.
Все пункты идут просто по очереди, а не по важности. Здесь всё важно. Рассказываю на примере WordPress. Хотя в общих чертах, без разницы, на чём работает ваш сайт.
Меняем пароли
Какие? А все, какими вы делились с разработчиком. Доступ к домену, хостингу – на первом месте. В личном кабинете вашего хостинга также зайдите в раздел FTP и удалите там все доступы. Либо поменяйте к ним пароли.
Заодно убеждаемся, что домен и хостинг зарегистрированы на ваше имя. Или на имя вашей организации.
Обязательно помним, что крепкие пароли – это ключевой элемент. Пароли должны быть достаточно длинными (не менее 12 символов) и содержать комбинацию строчных и заглавных букв, цифр и специальных символов. Используйте уникальные пароли для каждой учетной записи и избегайте очевидных сочетаний, таких как «123456» или «password». Менеджером паролей пользуетесь?
Удаляем лишних пользователей сайта
В консоли WordPress заходим в раздел “Пользователи” и удаляем там профиль разработчика (если таковой создавали). Если там одна учётная запись, то меняем у неё пароль. Заодно проверяем, что к этой учётке привязан ваш email адрес.
После этого идём в раздел “Настройки — Общие” и в строке “административный email” заново проверяем, что там тоже ваш email.
Есть вообще такой вариант — можно придумать механизм автоматического удаления неактивных аккаунтов, например, после определенного периода бездействия. Это поможет поддерживать базу данных пользователей в актуальном состоянии и предотвращать ненужные риски.
Удаляем лишние плагины
Бывает, что во время разработки на сайт добавляются разные плагины. После того, как сайт готов, часть плагинов уже не нужна и от них можно избавиться. Поэтому зайдите в раздел “Плагины” и посмотрите, что там делается.
Как минимум, оцените их количество. Если там больше 20 плагинов, попросите разработчика рассказать, что делает каждый. Хотя, можно даже не смотреть на количество, а и так попросить сделать небольшой экскурс по каждому плагину. Всё лишнее и ненужное – удаляем.
При анализе плагинов стоит применить подход критической оценки. Оцените каждый плагин по следующим критериям:
- Необходимость: Плагин должен решать конкретную задачу или предоставлять важную функциональность. Если плагин не является неотъемлемой частью функционирования сайта, его стоит рассмотреть на удаление.
- Обновления: Учтите, насколько активно разрабатывается плагин и как часто он обновляется. Плагины, которые не получают регулярных обновлений, могут стать уязвимой точкой в безопасности вашего сайта.
- Совместимость: Проверьте, совместимы ли плагины между собой и с текущей версией платформы, на которой работает ваш сайт. Несовместимость может привести к ошибкам и уязвимостям.
- Отзывы и рейтинги: Исследуйте отзывы пользователей и рейтинги плагина. Это может дать представление о качестве и надежности плагина.
После проведения анализа, удаляйте те плагины, которые больше не нужны или не соответствуют вашим требованиям. Важно также следить за новыми обновлениями плагинов и регулярно обновлять активные плагины, чтобы устранять возможные уязвимости.
Проверяем, что есть плагин безопасности
Также убеждаемся, что на сайте есть плагин безопасности. И не просто есть, а ещё и настроен. Что изменён адрес страницы авторизации (стандартный — /wp-admin), что настроена блокировка по неверному вводу логина/пароля и тому подобные шутки.
Включаем резервное копирование на хостинге
Возвращаемся на хостинг и ищем в панели управления раздел про резервные копии/бэкапы и как там его ещё могут назвать.
Убеждаемся, что эта функция активна и работает. Если можно регулировать частоту создания резервных копий, то ориентируйтесь на себя. Если каждый день вносите на сайт изменения, то можно и “ежедневно” включить. Вносите реже – поставьте на “раз в 3 дня”. Но не раз в месяц точно.
Про этот пункт ещё добавлю вот что – надеяться на хостинг можно и нужно, но дополнительно я (настоятельно) рекомендую ещё и вручную создавать архив сайта и хранить у себя на компьютере. Плагин Duplicator в этом смысле хорош.
Проверяем контактные email на самом сайте
Теперь смотрим, что написано на самом сайте. На странице контактов, в футере или где там у вас места для адресов почты. Там вполне может оказаться либо адрес разработчика (для тестирования во время работы), либо просто какой то выдуманный адрес. Типа test@test.ru. Меняем на актуальные, если нашли такое.
Настроена аналитика? Тоже проверяем
Если сайт подключен к Яндекс.Вебмастеру, Яндекс.Метрике и аналогичным сервисам от Google, то проверяем, что делается там. Пароли туда также меняем и убеждаемся, что счётчик Метрики работает, посетители считаются.
Также заходим в настройки счётчика и на вкладке “Доступ” проверяем, что он там никому дополнительно не выдан. Чтобы только вы могли смотреть всю статистику.
И в итоге
Каждый непроверенный (или не до конца настроенный) пункт из этого списка – потенциальная дыра в безопасности. Выделите время, чтобы пройтись по этому перечню. Право, это важные пункты, которыми не стоит пренебрегать.
Гораздо печальнее будет в один (не прекрасный) день увидеть неработающий сайт. А потом ещё и понять, что создание резервных копий на хостинге было выключено. И вручную созданного архива сайта у вас тоже нет.
Так что просто пройдитесь по всем пунктам этого чек-листа и наверняка заметите бреши в безопасности своего сайта.
