CMS: проблемы c безопасностью

Всякий web-сайт, выставленный в публичное пространство Интернета, рано или поздно наверняка атакуют хакеры. Сайт не обязательно взломают или испортят, но атака, может быть и самая простая, последует практически неизбежно. И не потому, что хакеров много, а потому, что совершенствуется инструментарий, используемый ими. Большинство атак на web-сайты сейчас проводится в автоматическом режиме, с помощью автоматических "сканеров" и прочего специального программного обеспечения, позволяющего обнаруживать уязвимости. ("Уязвимостями", применительно к информационной безопасности в Интернете, называют дефекты и ошибки в программном и аппаратном обеспечении, позволяющие злоумышленнику перехватить управление сайтом/сервером/программой или непредусмотренным образом вмешаться в работу последних.)

К сожалению, появление в составе программного обеспечения сайта любой CMS обязательно делает этот сайт менее безопасным. Дело в том, что сделанный из статических HTML-страниц сайт обслуживается исключительно HTTP-сервером (например, известнейшим сервером Apache). Распространённые HTTP-серверы весьма тщательно проверены на наличие уязвимостей, но даже в них продолжают находить новые "дыры". Любая же CMS устанавливается в дополнение к HTTP-серверу, и, конечно, уязвимости CMS прибавляются к уже имеющимся.

При этом, к сожалению, вклад CMS в количество уязвимостей, по отношению к статическому сайту, весьма велик. Это обусловлено двумя причинами: во-первых, за безопасностью основ серверного хозяйства -  в частности, за надёжностью HTTP-сервера - тщательно следят специалисты хостинг-провайдера (а следить за безопасностью "личной" CMS придётся владельцу сайта); во-вторых, вряд ли какая-то из существующих CMS прошла столь же серьёзные испытания на устойчивость, как серверные приложения  более низкого уровня.

Впрочем, то, что CMS неизбежно приводит к снижению безопасности сайта, не должно становится препятствием на пути внедрения CMS. Достаточно верно оценивать возможные угрозы, возможный ущерб от них и учитывать угрозы и риски в планировании. Вряд ли стоит отказываться от дополнительных возможностей по эффективному управлению сайтом и, в конечном итоге, от существенной части аудитории, по причине того, что риск "взлома сайта" возрастает на один или два процента, добравшись до отметки в пять процентов (это, конечно, условные значения).

На практике куда более важным оказывается правильное управление рисками. Ведь и суперзащищённый web-сайт без уязвимостей может быть элементарно захвачен злоумышленником, если владелец установил для этого сайта легко угадываемый пароль вида "qwerty123" или пароль, совпадающий с телефонным номером компании-владельца сайта (при том, что этот номер указан на самом сайте). Удивительно, но два только что приведённых примера не выдуманы - они совершенно реальные. Так что угрозы, связанные с самой CMS, если это распространённая система, оказываются пренебрежимо малы на фоне ошибок в "организации эксплуатации" CMS.

Подробный экскурс в информационную безопасность - за рамками нашей небольшой статьи. Мы лишь отметим наиболее важные, необходимые начинающему пользователю азы, которые, тем не менее, неплохо помогают на практике. И хотя замечания сосредоточены на CMS, они без изменений относятся ко всем составляющим web-сайт системам, будь то скрипт, реализующий голосование, или пакет программ для интернет-форума.

Во-первых, желательно использовать распространённые CMS, так как в этом случае несколько выше вероятность того, что основные "дыры" в них уже обнаружены и закрыты. Правда, никто не гарантирует, что завтра или послезавтра в системе не обнаружат новых "дыр". Поэтому следует "во-вторых".

Во-вторых, лучшим выбором является та CMS, развитие которой не прекращается. Если разработчики бросили систему ещё три года назад, то велика вероятность, что на вновь обнаруженную уязвимость просто некому будет реагировать.

В-третьих, необходимо тщательно отслеживать все выпускаемые разработчиками обновления CMS, касающиеся её безопасности и своевременно устанавливать эти обновления. Важно заметить, что некоторые современные CMS, например Joomla или "Битрикс", позволяют автоматизировать процесс отслеживания обновлений и их установки.

В-четвертых, нужно тщательно следить за расширениями CMS, выпущенными сторонними разработчиками. Главная хитрость в том, что при обновлении "ядра" CMS, уязвимости в расширениях обычно остаются без изменений. Обновлять расширения нужно отдельно, отслеживая новости на сайтах разработчиков расширений. (Отсюда следует другое важное наблюдение: расширения следует также выбирать среди живых, а не среди брошенных проектов.)

В-пятых, пароли для управления сайтом должны задаваться неугадываемые и хранить эти пароли следует в тайне, а не раздавать всем подряд. Даже если пароль передаётся человеку, которому можно доверять безгранично, возникает дополнительный риск: пароль у этого человека могут увести против его воли. Если позволяет хостинг-площадка и CMS, то доступ к администраторскому интерфейсу сайта лучше наладить с использованием защищённого протокола SSL. В противном случае, не так уж мала вероятность получения злоумышленником паролей через "прослушивание" сетевого трафика.

Кроме того, следует тщательно изучить рекомендации хостинг-провайдера по безопасности и им следовать. А если возможная уязвимость сайта для хакерских атак может угрожать убытками и даже подрывать само существование бизнеса (как, например, это происходит с интернет-магазинами), то нужно обязательно обратиться к специалистам по безопасности, чтобы они провели аудит программного обеспечения сайта.

Итак, основа практической безопасности - не "непробиваемая" CMS, а верная оценка рисков и угроз, подкрепляемая правильным управлением этими рисками. Лучше всего на вопросы безопасности ответит специалист, но такие специалисты недешевы. Поэтому, если бюджет не позволяет нанять эксперта, то необходимо хотя бы следовать самым простым, только что перечисленным, правилам безопасности.