Безопасность сайтов и веб-приложений

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

Безопасность веб‑приложений зависит от качества их программного кода, от квалификации системного администратора и от компетенций всех пользователей, имеющих доступ к чувствительной информации.

То есть причинами угроз безопасности — взломов и утечек данных — могут быть:

• Уязвимости самого сайта / приложения перед кибератакой — например, отсутствие защиты от перебора паролей, возможность внедрения стороннего кода (XSS, SQL‑инъекции, отсутствие защиты от CSRF)
• Недостаточное быстродействие системы или повышенная ресурсоёмкость обработки запросов, что приводит к уязвимости к атакам типа «отказ в обслуживании» — (D)DoS
• Ошибки, допущенные администратором веб‑сервера — несвоевременное обновление ПО или небезопасное конфигурирование сервисов
• Незнание или несоблюдение сотрудниками банальных правил безопасности — простые пароли, ввод данных на фишинговых сайтах, заражение вирусами ПК.

Рекомендации

• Доверяйте разработку требовательных к уровню безопасности сервисов опытным специалистам. Новички, как правило, могут добиться работоспособности приложения, но не в состоянии учесть риски взлома и атак типа «отказ в обслуживании».
• Администрированием сервера должен на регулярной основе заниматься компетентный специалист, большинство заражений сайтов вирусами происходит из‑за того, что серверное ПО никто не обновляет, а очень много утечек данных связаны с неверным конфигурированием серверных служб (из банального — открытые «в мир» порты систем хранения).
• Обучайте пользователей основам информационной безопасности, урезайте права до необходимого для работы минимума и используйте мониторинг доступа к чувствительной информации. Огромное количество проблем связано именно с некомпетентностью нетехнического персонала, возникающих как из‑за банальной некомпетентности (попался на фишинг, «случайно» удалил данные), так и по злому умыслу (хищение клиентской базы, слив заказов конкурентам и т.д.)
• Если вас мучают сомнения о безопасности вашего сайта, то закажите аудит безопасности у независимой компании. Мы на своей практике были по обе стороны этого процесса — и мы проверяли сторонние разработки на уязвимости, и разработанные нами системы проверяли — особенно много и тщательно в банковской / финансовой сфере.

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

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

Информационная безопасность в разработке ПО

• Разработчики должны знать об угрозах ИБ — практически все типичные виды атак на приложения — SQL- и XSS‑инъекции, CSRF, SSRF, брутфорс, нарушение контроля доступа, DDoS — могут быть или исключены на уровне разработки, или их реализация будет сильно усложнена.
• Запрещено всё, что не разрешено — это ключевая мантра безопасности в ИТ: реально хорошо работают только политики, которые основаны на простой модели — запрещаем всё и разрешаем только то, что необходимо. В разработке этот метод применяется при проектировании авторизации и ролевой модели доступа к системе.
• Могут быть подделаны все входные данные, поступающие в приложение — это данные форм, параметры запроса, любые http‑заголовки, cookies. Подделанные данные используются для взлома, получения конфиденциальной информации или для нарушения нормальной работы приложения. Больше всего думать об этом стоит разработчикам публичных сервисов, доступных не только из внутрикорпоративной сети, но и из интернета. Тем не менее, даже если ваш сервис надёжно спрятан внутри компании, то это всё равно не гарантия 100% защиты от проникновения злоумышленников.
• Используйте анализаторы кодовой базы — очень много ошибок в ИБ может быть выявлено именно благодаря подобным инструментам.
• Используйте системы управления версиями, автоматизированного тестирования и разворачивания проекта — это сильно снижает риски попадания в кодовую базу как инородных фрагментов (типа вирусов), так и позволяет отлавливать возможные ошибки. Про тестирование более подробно написано ниже.
• Помните о вреде «велосипедостроения» — для того, чтобы правильно написать ту же самую систему аутентификации надо достаточно много знать и разбираться в криптографии, хэшировании, знать как работают cookies или как работать с токенами, разбираться в применяющихся методиках брутфорса и других возможных атаках на систему аутентификации. Если нужные знания отсутствуют, то более рациональным решением будет воспользоваться зарекомендовавшей себя библиотекой, а не разрабатывать решение самостоятельно.
• Код‑ревью — все люди ошибаются, причём собственные ошибки очень часто заметить бывает труднее, чем чьи‑то ещё. Поэтому код надо проверять не только самостоятельно, но и с помощью коллег.

Информационная безопасность и тестирование

• Автоматизация тестирования — регулярно и в полном объёме делается только то, что делается автоматически. Ручное тестирование — штука тоже полезная, но полагаться только на него достаточно рисковая стратегия.
• Нагрузочное тестирование — позволяет избежать как критичных проблем вроде перегрузки серверов от неэффективных алгоритмов, так и снижает возможные угрозы DDoS на уровень приложения.
• Проверка отказоустойчивости — если вы спроектировали отказоустойчивую систему, то обязательно проверяйте запланированные сценарии отказа. Очень часто бывает так, что в теории решение выглядит идеальным, но на практике не работает.
• Сканирование уязвимостей — наличие большинства типовых уязвимостей может быть проверены автоматически. Включите в сценарий автоматизированного тестирования те же проверки на XSS и инъекции исполняемого кода.
• Канареечные релизы — в нагруженных проектах сначала тестируйте новый функционал на небольшой доле пользователей. Это позволяет избежать возможных отказов системы, если в кодовую базу вдруг попал неэффективный алгоритм, который в тестовой среде мог адекватно отработать, но под реальной пользовательской нагрузкой вполне может перегрузить инфраструктуру и привести к общей неработоспособности системы.
• Учения — регулярно проверяйте всё, что можете проверить. Удостоверьтесь, что в случае вероятных форс‑мажоров у вас готов сценарий действий и сотрудники знают что в этом случае делать.

Информационная безопасность и системное администрирование

• Настройка серверного ПО в соответствии с задачами и ресурсами системы — звучит банально, но проблема очень распространена: если служба не используется извне, то закройте к ней внешний доступ; если на сервере всего 8Gb RAM, то сервер СУБД не может быть сконфигурирован в расчете на 32Gb RAM; если для ПО устанавливается конфигурация «по умолчанию» — обязательно ознакомьтесь с ней, часть софта бывает весьма жадными до ресурсов и вы можете столкнуться с тем, что под нагрузкой это ПО будет прибито по OOM, а бывает и обратная ситуация — «дефолтные» настройки прописаны для работы на очень слабом железе и тогда вы просто не получите хорошей производительности.
• Регулярное обновление ПО — уязвимости бывают в любом софте, чем быстрее вы их закроете — тем меньше риск того, что кто‑то их проэксплуатирует. Еще бывает так, что критическая уязвимость формируется как сумма мелких проблем различных используемых программ.
• Запрещено всё, что не разрешено — этот подход верен и в разработке, и в системном администрировании. Ограничивайте всё, что не нужно для нормально работы.
• Инфраструктура как код — очень хорошая практика, позволяющая ничего не забыть в настройке оборудования и ПО, а также позволяющая хранить знания о настройке оборудования в понятной форме, а не в виде сакральных знаний админов или в виде истории bash‑команд на production-сервере.
• Высокая доступность сервисов и системы оркестрации — если используете контейнеризованные приложения, то задумайтесь о внедрении системы оркестрации типа Kubernetes, если же нет, то всё равно автоматизируйте процессы отработки отказов и реакции на повышение нагрузки.
• Мониторинг — очень важный процесс. Построение системы мониторинга — это тема для отдельной стать, если тезисно, то отслеживать стоит нагрузку / другие метрики приложения и обязательно настраивать оповещения об отклонениях, необходим контроль целостности программного кода, бывает полузным использование HoneyPot, а также в действительно крупных проектах стоит использовать комплексные системы обнаружения и предотвращения вторжений.
• Резервное копирование — бэкапы также очень важны. Лучше использовать несколько различных и изолированных методов снятия резервных копий. Бэкапы должны отправляться на удаленное хранение — резервная копия на сервере с боевыми данными может быть потеряна вместе с оригиналами. Проверка целостности — бэкапы надо проверять, как автоматикой, так и периодически вручную: резервная копия из которой нельзя ничего восстановить — это фикция, а не бэкап. Автоматический мониторинг — задачи резервного копирования должны быть под системой мониторинга с оповещениями. Хранилище резервных копий должно быть защищено не хуже production-окружения — в бэкапах очень много чувствительной информации.
• Следите за всем периметром безопасности — это не только production, но и системы управления версиями, тестирования, развертывания, мониторинга, сервера для резервного копирования, корпоративные базы знаний, баг‑трекер, рабочие станции разработчиков и администраторов... и это далеко не полный список мест, где может быть ценная информация, а значит всё это может быть возможной целью атаки.