Безопасности мало не бывает. Слабый пароль и логин admin на входе – это лишь пара пунктов. Представим, что еще можно сделать, чтобы свести к нулю условный индекс безопасности сайта. Все пункты, что я перечислю ниже, – исключительно сарказм. Грустный, печальный, но, увы, все основано на реальных примерах. Каждый пункт из списка – это живой сайт настоящего фонда, с кем мне довелось поработать. И что еще печальнее – многие пункты до сих пор не исправлены.
Номер 1. Хороший пароль – простой пароль
Реальность: Вокруг так много разных сайтов и сервисов, что заводить под каждый отдельный пароль – голову сломать можно. А все эти менеджеры паролей слишком сложны. Пусть лучше будет один пароль. Вот, например, qwerty. Или 123456. Или не, не, вот есть test1. Или все же password1? Ну, короче, что-нибудь из этого. Запомнить легко, пойдет. А, ну и, понятно, давайте один пароль и к сайту, и к хостингу. Это чтобы не запутаться совсем.
Ожидание: Пароли – это классика жанра. Из года в год публикуются топы самых популярных паролей, в которых многие находят и свои пароли (неожиданно). Разнообразием вариантов эти подборки тоже не блещут, что, впрочем, ситуацию особо не меняет. Добавляют пикантности регулярные сливы в Интернет различных баз с учетными записями, после чего нужно бежать и срочно менять пароль.
Идеальный вариант – это как раз использование менеджера паролей. В нем все будет по категориям и на своем месте. Каждый новый пароль можно задать через встроенный генератор, поэтому придумывать что-то свое и не нужно. В итоге нужно будет запомнить только один мастер-пароль на вход в само приложение. Плюс облачная синхронизация позволяет использовать одну базу сразу на нескольких устройствах. Как минимум – на компьютере и телефоне.
Номер 2. Постоянно менять пароли мне некогда
Реальность: qwerty – нормальный же пароль. Тем более он подходит и к сайту, и к хостингу. Постоянно его менять, это что, каждый раз новый придумывать? Авось пронесет, пусть пока так будет.
Ожидание: Да, создать сложный пароль – это лишь полдела. Нужно его регулярно менять. Иначе толку от него будет ровно половина. Конечно, чем длиннее и сложнее структура пароля, тем он надежнее, но в случае когда база данных пользователей утечет в свободное плавание, то вернее будет его поменять. А учитывая, что многие утечки стараются не афишировать, то лучше менять пароль по своей воле. Тем более во многих парольных менеджерах есть установка срока действия пароля – месяц, два, три и так далее. Срок действия истек – приложение выдаст напоминание.
Номер 3. Обновлять сайт – а вдруг что-то сломается?
Реальность: Во-первых, если все и так работает, зачем обновлять? Во-вторых, пусть лучше это сделает специалист, у нас его пока нет. Сделаем попозже, сейчас есть более важные дела, готовимся к мероприятию.
Ожидание: Сайт скорее всего сломается сам или будет взломан извне, если будет работать на устаревшей версии самой CMS (система управления контентом) или какого-либо плагина. Ведь любое обновление программы – это не только внешние изменения. Это исправление кода и латание найденных дыр в безопасности, обнаруженных за время работы прежней версии. Поэтому обновлять саму CMS и плагины сайта – дело первой необходимости.
К тому же каждое объявление о найденной уязвимости – это фактически открытое приглашение разного рода хакеров к тому, чтобы проверить, а действительно ли можно попасть на сайт через эту дырку в безопасности? А желающих такое проверить предостаточно. Поэтому поводов лучше не давать.
Номер 4. Стандартный адрес страницы авторизации – это удобно
Реальность: Ну, правда, это ведь удобно запомнить. Если сайт на WordPress, то вход в админку здесь: /wp-admin или /wp-config.php. Если на Joomla, то /administrator. Если MODX, то /manager. И все, не нужно придумывать что-то свое. Да кому вообще будет нужно залезать в нашу админку?
Ожидание: Это первый барьер безопасности на сайте, и если у вашего сайта эта страница открывается по стандартному адресу, то поздравляю – первый барьер успешно пройден. Хотя поздравлять здесь особо не с чем. Скорее наоборот, можно погрустить. А потом срочно менять адрес админки на свой собственный. Благо, сделать это можно в любом адекватном плагине безопасности. В сочетании с логином admin и стандартным адресом админки можно не спеша перебирать пароли – готовый список наиболее уязвимых можно взять в том же Топ-200. И это вполне себе рабочий сценарий.
Номер 5. Нашли в Интернете красивую тему? Качаем, не глядя
Реальность: Этих сайтов с каталогами тем и плагинов – полным-полно. Где же тут разобраться, какой из них официальный? Нашли красивую тему? Качаем! Установилось же, работает, а нам это и надо.
Ожидание: Устанавливать темы и плагины нужно только (и только) из официальных каталогов. Для WordPress это каталог тем и каталог плагинов. Все остальное – уже в зависимости от известности и репутации сайта. Есть довольно известные сайты с шаблонами тем и плагинами (TemplateMonster, например), а есть небольшие форумы, куда вы можете попасть по ссылке в поисковой выдаче. И скачивать оттуда тему или плагин – вот, право, лучше не надо. В том же каталоге тем для WordPress более 7 тысяч вариантов для загрузки. Есть и платные, и бесплатные варианты. Что-нибудь точно вам понравится. А плагинов для WordPress и того больше – 56 тысяч.
Внедрение стороннего кода в тему или плагин – тоже один из вариантов взлома сайта изнутри. Причем само проникновение вы можете и не заметить, а данные с вашего сайта (адреса email, имена, фамилии) будут улетать налево.
Номер 6. Семь админов на сайте? Ну да, а что такого?
Реальность: Один из них – это разработчик. Нет, после сдачи сайта он больше не заходил. Ну, а вдруг понадобится? Другая учетка – это наш контент-менеджер, новости добавляет. Говорит, ему так удобней. Третья учетка – это нам недавно волонтер помогал, может, еще будет помогать. А остальные – надо посмотреть, чьи.
Ожидание: Администратор на сайте должен быть один. Ну, ладно, два. Остальные пользователи должны быть вежливо, но настойчиво поделены на группы с другими (меньшими) правами доступа. Из своей практики – очень часто встречаются две ситуации. Первая: админ на сайте один (аккаунт разработчика), и все заходят на сайт под этой учеткой. При этом email адрес стоит тоже разработчика. Так себе безопасность, потому что в случае потери пароля его и восстановить будет непросто. Потому что почта указана не наша. Вторая ситуация: на сайте несколько учеток и все с правами полного доступа. А там и директор, и контент-менеджер, и волонтер, который недавно помогал по сайту. И у всех полный доступ к управлению.
В таких случаях после работы с сайтом я прошу удалить вновь созданную (для меня) учетку или поменять пароль, если я заходил под общим логином. И здесь уже безо всяких «доверяю/не доверяю». Просто поменяйте пароль, там работы меньше минуты.
Номер 7. Логин admin легко запомнить
Реальность: А так сразу было, мы только пароль поменяли после открытия сайта. У нас и на втором сайте логин admin, запоминать удобно.
Ожидание: Сразу после создания сайта лучше создать учетную запись с другим именем. Опять же потому что полдела уже сделано и останется только подобрать пароль. Дело исключительно в уровне безопасности.
Номер 8. Удалить ненужные плагины всегда успеем
Реальность: Все плагины, которые есть на сайте, – нужны. Там есть несколько, которыми пользовались год назад, но пусть они пока будут, потом удалим. Да, пусть пока будут активированы, вдруг срочно понадобятся.
Ожидание: В разделе плагинов держим только те, которые используются. Остальные или удаляем, или деактивируем. Если плагин давно-давно не обновлялся, то в нем наверняка накопилось достаточно дыр в безопасности, которые могут быть использованы против сайта. Так что если даже плагин и деактивирован, то его все равно лучше регулярно обновлять.
Номер 9. Резервные копии? Что-то настраивали, да
Реальность: Да, конечно, бекапы у нас настроены. Нужно только узнать у разработчика, он, вроде, это подключал.
Ожидание: На вашем хостинге наверняка есть услуга по автоматическому созданию резервных копий. Каждый день, раз в три дня или еще как то. Помимо этого, можно делать бекапы хоть каждый день, самостоятельно. Во многих плагинах безопасности тоже есть такая настройка. На хостинге создать архив сайта и базы данных можно в разделе резервного копирования. Есть либо функция ручного создания, либо можно заархивировать папку сайта и скачать себе на компьютер. Как часто создавать копии – зависит от вашего уровня маниакальности насчет безопасности сайта и степени важности информации на нем. Если в день у вас выходит с десяток новостей и добавляется другая важная информация, то понятно, что создание копий раз в неделю будет менее актуально, чем ежедневно. Случись что, вы сможете восстановить из архива версию сайта только по состоянию на день сохранения копии. А все остальное придется заводить вновь.
Кроме того, есть специальные плагины, заточенные именно под создание резервных копий. Это очень и очень успокаивающая функция, когда вы знаете, что на вашем компьютере есть полный бекап сайта. Но нужно знать, что оно настроено и работает.
Номер 10. Раз в год мы закидываем на карту разработчика деньги, и нам продлевают домен
Реальность: Домен на наше имя зарегистрирован. Вроде так. Раз в год мы закидываем деньги на карту, и нам продлевают домен. Ну, и хостинг, значит, тоже. Надо уточнить, в общем.
Ожидание: Еще один популярный случай. Здесь нюанс больше юридический, чем технический. В идеале все просто – домен и хостинг зарегистрированы на имя владельца сайта. Еще лучше, если на юридическое лицо, а не на имя директора. И вообще, для паролей нужно иметь красную папку (можно настоящую красную физическую папку), где будут собраны все-все логины/пароли. И папка должна быть у директора. Регистрация домена и хостинга на физические лица, не имеющие отношения к НКО, – весьма рискованная ситуация. Очень даже.
Номер 11. У нас не WordPress, нам сделали свою платформу
Реальность: Разработчик сказал, что под наши задачи лучше сделать свою систему, и написал специально для нас. А сейчас нам нужно подключить пожертвования, и он просит денег, чтобы дописать платформу.
Ожидание: Какая бы ни была CMS у вашего сайта, будет очень круто, если у сайта за спиной будет надежная поддержка. В том числе и техническая. Если сайт написан специально под вас, то хорошо. Но если специалистов, которые разбираются в этой системе, раз, два и обчелся, то нужно быть осторожнее. Монополия – это такое дело, неоднозначное. В какой то момент может случиться, что ваш разработчик уедет/будет недоступен, а на сайте будет ждать срочная работа. К тому же повышение цен на сопровождение сайта без возможности выбора – довольно частая ситуация.
В этом смысле системы открытого кода (WordPress, Joomla, Drupal, MODX) более предпочтительный вариант. Как минимум из-за гораздо большего сообщества разработчиков.
Номер 12. Какой-то дорогой плагин. Мне сказали, на торрентах есть взломанные версии
Реальность: У нас сейчас нет денег на покупку этого плагина. Поищите крякнутую версию, а потом мы ее обновим до официальной.
Ожидание: Никаких взломанных плагинов на сайте быть не должно. Ни плагинов, ни тем. Это огромная брешь в безопасности, которую вы сами себе и создаете. На моей практике это был буквально один случай, но запомнился он мне очень хорошо. Тогда просили найти взломанную русифицированную версию одной темы, на что я вежливо отказался. Покупка официальной версии темы стоимостью 30 долларов была куда более разумным вариантом.
Если не нашли бесплатный аналог нужного плагина, значит, плохо искали. Их там 56 тысяч на сегодня! К тому же если плагин нужен именно этот и только он, то лучше будет его купить.
Номер 13. Пароли лучше хранятся в разных местах
Реальность: Так, пароль от сайта у нашего контент-менеджера. От хостинга – сейчас запросим у админа. А от домена – мы поищем и напишем, когда найдем.
Ожидание: Снова вернемся к идее красной папки. Все пароли должны быть в одном месте, все они должны быть актуальными. Собирать пароли по всей команде не лучшая идея.
Про цифровую безопасность сайтов можно говорить постоянно, тема всегда актуальная и имеет своих читателей. Если вы увидели в этом списке хоть один пункт, который можно доработать у вашего сайта, сделайте. Вот прямо сейчас сделайте. Восстанавливать работу сайта и его данные будет куда как сложнее.
Если нужна помощь по настройке безопасности сайта, напишите или здесь в комментариях, или создайте задачу на it-волонтере. Вам обязательно помогут.