Как защитить сайт? Обеспечение информационной безопасности сайта

Обеспечение информационной безопасности - это комплекс мер для обеспечения бесперебойной работы сайта, секретности, целостости и доступности пользователям хранящейся информации.

В статье рассмотрим:

Также коснемся нашей веб-платформы Falcon Space в контексте вопросов информационной безопасности.

Если в вашем доме массивная стальная дверь, но окна при этом всегда открыты, общее состояние защищенности будет невысоким. Вы можете ставить различные антивирусы, закрыть все порты на сервере, но если при этом ваши пользовали ставят пароли 123456 и пишут их на бумажке на рабочем столе на ПК, то риски быть взломанным очень высоки.

Поэтому фокус внимания всегда должен быть на наиболее слабом на данный момент звене.

Зачем взламывают какую-либо систему? Для получения некой выгоды. Если взлом стоит дешевле этой выгоды, то игра стоит свеч. Задача защиты сделать взлом невыгодным.

Необходимо максимально повысить стоимость взлома. Это в первую очередь время на взлом и аппаратные/программные ресурсы взломщика.

Что может плохого случиться с информацией на сайте?

Все меры по безопасности так или иначе направлены на обеспечение конфиденциальности, целостности или доступности информации.

Человек слаб. У него есть множество соблазнов и уязвимых мест. Кого-то можно подкупить, кого-то запугать, а кто-то может по простоте дать доступ злоумышленнику по телефону.

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

Не нужно стрелять из пушки по воробьям. Ваша защита должна соответствовать уровню угроз и модели злоумышленника. Если против вас работает АНБ, то ресурсов на защиту, вероятно, потребуется много (но, наверняка, в этом случае вам есть, что защищать).

Это позволит вам понять, что может сделать злоумышленник, какие цели преследует (что он сможет с вас получить в случае успешного взлома) и какие варианты атаки он может реализовать.

Система безопасности должна работать непрерывно во времени. Странно будет выглядеть инкассаторы, которые при перевозке денег в 13:00 все разом поехали в кафе обедать, оставив деньги в машине.

Необходимо предусмотреть факторы, которые могут "оборвать" эту непрерывность состояния защищенности: выключили свет, уволился системный администратор, необходимо обновить какой-то ПО или ключ шифрования.

Информационная безопасность - это та же работа с рисками.

Риск - это вероятность и критичность для бизнеса.

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

Первый вопрос - откуда ноги растут? Кто злоумышленник, и зачем ему нужно взламывать наш сайт?

Что он получит? Какие возможности для взлома у него есть? Какой бюджет на взлом он может выделить?

Понимая эти вопросы, вы сможете более адекватно выработать ряд мер для защиты своего сайта.

Разберем основные меры защиты сайта по угрозам для конфиденциальности, целостности и доступности информации на сайте. Некоторые из мер относятся сразу к нескольким типам.

HTTPS соединение шифрует трафик между браузером и сервером. Это усложняет для злоумышленника получение данных в промежуточных узлах (например, извлечение пароля пользователя при входе).

Также SSL дает некую гарантию пользователю, что он взаимодействует именно с нужным сайтом (в браузере видна информация чей это сертификат).

Пользователь может ввести некий код через поля форм и этот код может негативно сказаться на работе системе.

Например, XSS атака подразумевает ввод JS кода, который сохранится в базе сайта (например, в виде тикета в службу поддержки), затем другой пользователь запросит эти данные из базы и этот вредоносный код JS выполнится от имени этого пользователя.

В Falcon Space мы производим защиту от XSS на уровне ролей. Только некоторые определенные в настройках роли могут сохранять HTML разметку в системе. Для всех других разметка сохраняется в кодированном виде (что не позволяет внедрить JS код).

Атака SQL Injection - вводится код SQL, который видоизменяет SQL выполняемый на сервере. Это очень опасная штука, т.к. позволяет вводить прямые команды в БД (например, удалять данные или считывать данные из таблиц). Защита от SQL инъекций - весь код sql выполнять в хранимых процедурах с параметрами без использования динамически генерируемых процедур.

В Falcon Space вся обработка построена на хранимых процедурах с параметрами.

Периодически разработчики находят уязвимости в ПО и выпускают обновления. Если не делать обновления, то есть риск, что этой уязвимостью воспользуются злоумышленники. Необходимо проводить профилактику сервера и ПО на нем.

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

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

Если ряд операций должны быть выполнены как единое целое, то они должны быть заключены в единую транзакцию, которая либо полностью выполнится, либо откатится.

Это имеет важное значение для таких случаев как пополнение баланса. В рамках одной транзакции происходит изменение статусов платежей, изменение баланса пользователя и логирование этой операции. В случае возникновения проблем система будет всегда оставаться в целостном состоянии, т.к. не будет такой ситуации, что статус мы изменили, а пополнение баланса и логирования не произошло.

Платформа Falcon Space позволяет менять SQL скрипты, т.к. вы можете самостоятельно задать транзакции в системе под свои нужды.

Данные в системе нужно периодически проверять. Код сайта может содержать ошибки, которые будут приводить к нарушению целостности. В этом случае необходимо создать ряд скриптов, которые будут проверять по бизнес-логике целостность данных в таблицах. Можно запускать подобные скрипты ежедневно для нахождения коллизий в данных, после чего выдавать отчет на почту.

В платформе Falcon Space есть подобный отчет для поиска медленных запросов. Ежедневно выполняется скрипт поиска проблемных запросов и отправляется краткий отчет на почту.

Если структура базы данных имеет проблемы, то при частичном обновлении данных может нарушиться целостность данных. Необходимо использовать нормализацию базы данных достаточного уровня, вводить ограничения, устанавливать внешние ключи и т.д.

Если сайт разрабатывался, а не просто был сделан на из готовых блоков, то в нем могут быть ошибки. И вылезти они могут не сразу, а в ходе эксплуатации.

Необходимо проводить профилактику приложения - смотреть логи, анализировать быстродействие, искать проблемные точки.

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

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

Защита от DOS атаки лежит в первую очередь на хостере. Задайте вопросы по поводу защиты от DOS атак своему хостеру.

Также вы можете блокировать подозрительные IP адреса, т.к. ваш сервер просто не будет обрабатывать некоторые запросы. Тут главное не перестараться, т.к. таким образом, можно отсеять реальных пользователей вместе с ботами (программы, заходящие на сайт).

Проводите нагрузочные тесты, находите проблемные места в своем сайте про производительности. То, что хорошо работает на малом объеме, может очень тормозить на больших оборотах.

Пример подобного теста можно найти здесь - нагрузочное тестирование каталога Falcon Space через Loader.io.

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

Если возникла остановка работы сайта, то необходимо узнать об этом как можно раньше, чтобы сразу принять все меры по восстановлению сайта. Для этого используются средства мониторинга, которые опрашивают сайт. В случае падения они сообщают через email или sms о проблеме. Пример бесплатного сервиса по мониторингу доступности сайта - https://uptimerobot.com/

Используйте сложные пароли, но которые реально запомнить. В этом случае пользователь не будет записывать их на бумажку. Пример: Kata007pulta* Пароль содержит спецсимволы, цифры, верхний регистр, более 8 символов. Такой пароль сложно подобрать, но легко запомнить пользователю.

Периодически меняйте важные пароли. Если храните пароли, то сделайте архив с паролем, и храните в нем Excel с паролями локально на своем ПК.

У каждого пользователя должен быть минимальный уровень доступа, достаточный для его работы. Не нужно давать больше, чем ему нужно для выполнения служебных обязанностей. Атаке извне может быть подвергнут любой элемент вашей системы, и чем меньше возможностей у этого элемента, тем лучше.

Закрывайте доступ через неиспользуемые порты на сервере. Каждый порт - потенциальная точка входа для злоумышленника.

Ставьте обновления своевременно. Заведите регламент работ по обновлению основного ПО - ПО сервера, CMS сайта, антивирус и т.д.

Инсайдер гораздо опаснее внешнего злоумышленника. У него уже есть доступ в системе. К нему есть некоторое доверие со стороны других людей в системе. Он может долгое время незаметно пакостить в системе. Создайте условия для максимальной удовлетворенности людей в системе, со всеми расставайтесь полюбовно, не оставляя долгов перед другими (особенно перед программистами и системными администраторами).

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

Проводите пересмотр рисков и мер по уменьшению критичности и вероятности возникновения риска.

Риски - это не что-то, что высечено на камне. Вы провели некие работы по снижению рисков, и необходимо пересмотреть их, сделать акцент на другие риски.

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

Не публикуйте в общий доступ информацию, чувствительную ко взлому. Тем самым вы уменьшите вероятность взлома внешним злоумышленником.

На рабочих станциях (и тем более на серверах) не должно быть ненужного ПО. Любое дополнительное - потенциальный риск получить вирус или другое вредоносное ПО.

Уязвимости в ПО также могут быть точкой входа в систему.

Поэтому ставьте приложения только из проверенных источников и давайте этим приложениям минимум необходимых прав.

Когда сайт обрабатывает запрос от браузера, нельзя доверять введенным данным от пользователя.

В платформе Falcon Space практически любая процедура принимает параметр @username, который находится внутри системы, а не получен от браузера. Именно на него мы ориентируемся при авторизации доступа к определенным ресурсам.

К примеру, пришел запрос GetOrder и передан параметр orderID - можем ли бы просто выдать заказ по orderID. Нет, т.к. юзер мог указать чужой orderID. Мы должны проверить сначала (по @username) имеет ли текущий пользователь доступ к этому объекту.

Делайте бекапы базы данных и файлов сайта. Ежедневно должны создаваться бекапы. Их нужно копировать на удаленное хранилище (яндекс диск или dropbox). В случае, если сгорит сервер, ваши бекапы будут в сохранности.

Периодически проверяйте, что ваши бекапы делаются и они пригодны для использования (может случиться так, что бекапы делаются, но они повреждены и не могут быть использованы; либо делаются сильно усеченные и не позволяют полностью восстановить информацию).

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

Регламенты могут разниться и будут зависеть от специфики, масштаба вашего проекта, модели угроз и ваших возможностей/приоритетов.

Выполняет системный администратор, проверяет критичные параметры сервера (память, место на диске, процессор), изучает системные логи, проводит обновление ПО, смотрит за бекапами сайта и базы данных.

Выполнять данную процедуру может разработчик на поддержке. Необходимо изучать лог ошибок приложения, делать диагностику ошибок и заносить в баг трекер, что необходимо поправить.

Также имеет смысл проводить диагностику быстродействия, искать слабые запросы и оптимизировать их.

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

Хотя бы раз полгода имеет смысл возвращаться к рискам информационной безопасности и обновлять меры, регламенты для более адекватной защиты от вновь выявленных угроз.

Информационная безопасность веб-сайтов требует времени и средств. А видимой отдачи от нее нет. Что-то сделали, внедрили, а прямой выгоды от этого нет.

Но есть риски, которые могут в итоге принести колоссальный ущерб. Сделав небольшие усилия (20% по Парето), вы можете обеспечить значительную степень защищенности сайта и усложнить взлом для злоумышленника (т.е. защититься от 80% атак).

Начните с минимальных базовых моментов по обеспечению безопасности, итеративно добавляя новые элементы по мере необходимости.

Есть прекрасный закон Мерфи: "Если что-то может пойти не так, оно пойдёт не так".

Смысл его не в том, что вас обязательно взломают, но смысл в том, что кого-то когда-то непременно взломают. Будет ли это ваш сайт или чужой, завтра или через год, но это точно произойдет.

Источник: