Страница-источник на сайте falconspace.ru
Представьте: вы вложили в свой сайт душу, деньги и время. Запустили. А однажды утром заходите — а его нет. Взломали. Данные утекли. Или всё зависло и не грузится. Знакомо? Если нет — вы в зоне риска. Я — веб-разработчик с многолетним стажем. И поверьте: защита сайта — это не роскошь, а базовая гигиена. Как чистить зубы. Только для вашего бизнеса.
Эта статья — не скучная теория. Это план действий. Вы узнаете:
Читайте до конца — я покажу, как не потерять сайт и деньги. Поехали.
Представьте: у вас стальная дверь, а окна открыты. Смысла в двери — ноль. Так и с сайтом: можно поставить супер-антивирус, но если сотрудник использует пароль 123456 — вы уязвимы. Всегда ищите самое слабое место и закрывайте его в первую очередь.
Злоумышленник тратит ресурсы на взлом. Ваша задача — сделать так, чтобы его затраты превысили возможную выгоду. Чем сложнее и дороже взлом, тем меньше шансов, что на вас нападут.
Всё, что может случиться с информацией на сайте, укладывается в три пункта:
Любая мера безопасности работает на один из этих пунктов.
Люди — самое слабое звено. Инсайдер (свой сотрудник) опаснее внешнего хакера. Его можно подкупить, запугать или просто обидеть. Он уже имеет доступ к системе. Поэтому стройте процессы так, чтобы минимизировать риски от своих же.
Не нужно тратить миллионы, если ваш сайт — небольшой интернет-магазин. Оцените угрозы: кто на вас нападет? Зачем? Какие у него ресурсы? Исходя из этого — выбирайте меры. Защита должна соответствовать угрозе, а не быть «на всякий случай».
Система безопасности не может «отдыхать». Если в 13:00 все инкассаторы ушли обедать, оставив деньги в машине — это катастрофа. Защита должна работать 24/7. Учитывайте: отключение света, увольнение админа, обновление софта — всё это может нарушить непрерывность.
Информационная безопасность — это работа с рисками. Оцените, насколько вероятно негативное событие и насколько оно критично для бизнеса. Затем продумайте, как снизить и вероятность, и критичность.
Подробнее о рисках — в статье «Ключевые риски на старте разработки продукта».
Шифрует трафик между браузером и сервером. Это мешает злоумышленнику перехватить данные (например, пароль при входе). Плюс — пользователь видит, что сайт настоящий (зеленый замочек).
Пользователь может ввести вредоносный код в поле формы. XSS — это когда JS-код сохраняется в базе и потом выполняется от имени другого пользователя. В Falcon Space мы защищаемся от XSS на уровне ролей: только некоторые роли могут сохранять HTML-разметку.
SQL-инъекция — ввод SQL-кода, который меняет запрос к базе. Опасная штука: можно удалить данные или считать их. Защита — использовать хранимые процедуры с параметрами, а не динамические запросы. В Falcon Space так и сделано.
Разработчики находят уязвимости и выпускают патчи. Если не обновляться — вы оставляете дверь открытой. Регулярно обновляйте CMS, плагины, серверное ПО.
Постройте бизнес-процессы так, чтобы снизить риск утечки. Пример: платежные документы подписывают два разных человека. Обучайте сотрудников: что можно, что нельзя, как реагировать на подозрительные ситуации.
Если операция состоит из нескольких шагов (например, пополнение баланса: изменить статус платежа + изменить баланс + записать в лог), все они должны быть в одной транзакции. Если что-то пошло не так — система откатится к исходному состоянию. В Falcon Space вы можете настраивать транзакции под свои задачи.
Периодически проверяйте данные на ошибки. Создайте скрипты, которые ищут коллизии по бизнес-логике. Запускайте их ежедневно и получайте отчет на почту. В Falcon Space есть такой отчет для медленных запросов.
Нормализация, ограничения, внешние ключи — это база. Если структура кривая, при частичном обновлении данные могут «разъехаться».
Сайт не работает сам по себе. Ошибки вылезают в процессе эксплуатации. Смотрите логи, анализируйте быстродействие, ищите проблемные точки. Это и качество, и безопасность.
DDoS — это когда на сайт идет шквал запросов, и сервер падает. Первая линия защиты — ваш хостинг-провайдер. Спросите у него, как он защищает от DDoS. Также можно блокировать подозрительные IP, но аккуратно, чтобы не отсечь реальных пользователей.
Проверьте, как сайт ведет себя под нагрузкой. То, что работает на 10 пользователях, может упасть на 1000. Пример теста — нагрузочное тестирование каталога Falcon Space через Loader.io.
Если основной сервер упал, хорошо иметь запасной. В идеале — несколько серверов в связке, чтобы при сбое одного запросы шли на другой.
Если сайт упал, вы должны узнать об этом мгновенно. Используйте сервисы мониторинга (например, UptimeRobot), которые пришлют уведомление на email или в SMS.
Используйте сложные, но запоминаемые пароли. Пример: Kata007pulta* — есть спецсимвол, цифры, верхний регистр, больше 8 символов. Такой пароль сложно подобрать, но легко запомнить. Меняйте важные пароли периодически. Храните пароли в зашифрованном архиве на локальном ПК.
Каждому пользователю — ровно столько прав, сколько нужно для работы. Не больше. Чем меньше возможностей у элемента системы, тем меньше точек входа для атаки. Закрывайте неиспользуемые порты на сервере.
Ставьте обновления вовремя. Заведите регламент: раз в месяц проверять и обновлять CMS, плагины, серверное ПО, антивирус.
Инсайдер опаснее внешнего хакера. У него уже есть доступ, ему доверяют. Он может вредить незаметно. Создайте комфортные условия для сотрудников, расставайтесь полюбовно, не оставляйте долгов. Особенно перед программистами и сисадминами.
Чем сложнее система, тем больше в ней багов. А баги — это риски. Не усложняйте сайт без необходимости. Он и так усложнится со временем — из-за данных, хотелок пользователей и т.д.
Пересматривайте риски и меры хотя бы раз в полгода. То, что было актуально вчера, может быть неактуально сегодня.
Злоумышленник собирает информацию из открытых источников. Не выкладывайте в открытый доступ то, что может помочь взломать сайт.
Любое дополнительное ПО — потенциальный риск. Ставьте только из проверенных источников и давайте минимум прав.
Никогда не доверяйте данным, которые пришли от браузера. В Falcon Space мы используем параметр @username, который берется из системы, а не от пользователя. Пример: пришел запрос GetOrder с orderID. Мы не отдаем заказ сразу — сначала проверяем, имеет ли пользователь (по @username) доступ к этому заказу.
Делайте ежедневные бекапы базы данных и файлов сайта. Копируйте их на удаленное хранилище (Яндекс.Диск, Dropbox). Периодически проверяйте, что бекапы создаются и их можно восстановить.
Без регулярных действий все описанные меры — просто теория. Внедрите регламенты:
Системный администратор проверяет: память, место на диске, процессор, системные логи, обновляет ПО, контролирует бекапы.
Разработчик на поддержке изучает лог ошибок, диагностирует проблемы, заносит в баг-трекер. Также анализирует быстродействие и оптимизирует слабые запросы.
Регулярно меняйте пароли для критичных точек: доступ к БД, хостинг-панелям, серверу, платежным аккаунтам.
Раз в полгода возвращайтесь к списку угроз и обновляйте меры защиты.
Информационная безопасность — это невидимые инвестиции. Вы не видите отдачу, пока всё работает. Но когда случается беда — ущерб может быть колоссальным.
Сделайте 20% усилий (по Парето) и защититесь от 80% атак. Начните с базовых вещей: сложные пароли, обновления, бекапы, минимальный доступ. Добавляйте новые элементы итеративно, по мере необходимости.
Помните закон Мерфи: «Если что-то может пойти не так, оно пойдёт не так». Кого-то когда-то взломают. Вопрос — будете ли это вы?
Читайте также: «Почему закрываются сайты» и «Ошибки владельцев сайтов».
Ключевая мысль: Безопасность сайта — это не разовое действие, а непрерывный процесс. Регулярно проверяйте слабые места, обновляйте ПО и обучайте сотрудников. Только так вы сможете минимизировать риски.
SSL (HTTPS) шифрует данные между браузером и сервером. Это защищает от перехвата паролей и другой конфиденциальной информации. Плюс — повышает доверие пользователей.
Основная защита — на стороне хостинг-провайдера. Также можно блокировать подозрительные IP и использовать CDN.
XSS — это внедрение вредоносного JS-кода через поля ввода. SQL-инъекция — внедрение SQL-кода для манипуляции базой данных. Защита — фильтрация ввода и использование параметризованных запросов.
Ежедневно. И обязательно проверяйте, что бекапы можно восстановить.
Немедленно отключите сайт, смените все пароли, восстановите данные из последнего бекапа, проанализируйте причину взлома и устраните уязвимость.
