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

Безопасность начинается с понимания того, что защищаем

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

На первом этапе определяем:

• публичные домены и поддомены;
• административные интерфейсы;
• API и внешние endpoints;
• CMS и используемые зависимости;
• интеграции с внешними системами;
• серверы и сетевые точки входа;
• пользовательские и сервисные учетные записи;
• ключи, токены и другие секреты;
• данные, потеря или раскрытие которых критичны для проекта.

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

Поверхность атаки важнее количества защитных средств

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

Проверяем:

• ненужные административные интерфейсы;
• забытые поддомены и тестовые окружения;
• неиспользуемые сервисы;
• избыточные сетевые доступы;
• устаревшие компоненты;
• публичные endpoints, которые не должны быть доступны извне;
• функции CMS и приложения, которыми проект больше не пользуется.

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

Контроль доступов

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

В зависимости от проекта проверяем:

• административные роли;
• принцип минимально необходимых прав;
• MFA для критичных учетных записей;
• сервисные аккаунты;
• доступы бывших сотрудников и подрядчиков;
• ключи и токены;
• доступ к серверной инфраструктуре;
• хранение секретов;
• права на файлы и конфигурацию.

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

Приложение, CMS и зависимости

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

Поэтому учитываем:

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

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

Сервер и инфраструктура

Даже правильно написанное приложение может оказаться уязвимым из-за конфигурации окружения.

В защитный контур входят:

• web-сервер и reverse proxy;
• открытые сетевые сервисы;
• системные учетные записи;
• права процессов;
• сетевые ограничения;
• журналы событий;
• управление обновлениями;
• секреты и конфигурационные данные.

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

Защитный периметр

Перед приложением могут использоваться reverse proxy, CDN, WAF, средства фильтрации автоматизированного трафика и другие механизмы. Их задача - остановить часть нежелательного трафика до того, как он создаст нагрузку или достигнет чувствительной функции приложения.

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

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

Шифрование и защищенная передача данных

HTTPS является обязательной частью современного веб-проекта, но наличие значка замка не означает, что вся схема настроена корректно.

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

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

Мониторинг и наблюдаемость

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

Контролироваться могут:

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

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

Резервное копирование и восстановление

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

Резервная копия полезна только тогда, когда понятно:

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

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

Готовность к инциденту

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

Для критичных проектов полезно заранее определить:

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

Как проходит работа с безопасностью

1. Определяем архитектуру и активы. Понимаем, какие компоненты входят в проект и что является наиболее критичным.
2. Фиксируем поверхность атаки. Определяем доступные извне интерфейсы, сервисы, учетные записи и интеграции.
3. Формируем модель угроз. Рассматриваем реалистичные сценарии и возможные последствия.
4. Приоритизируем риски. Критичные проблемы исправляются раньше косметических улучшений защиты.
5. Внедряем изменения. Усиливаем необходимые компоненты без нарушения рабочих сценариев.
6. Проверяем результат. Повторно проверяем закрытые риски и работу системы после изменений.
7. Определяем контроль. Фиксируем, что необходимо отслеживать после завершения работ.

Безопасность не должна ломать продукт

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

Поэтому каждое изменение оцениваем одновременно по двум параметрам:

• насколько оно уменьшает риск;
• как оно влияет на нормальную работу системы.

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

Почему безопасность нельзя настроить один раз

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

Поэтому со временем необходимо повторно контролировать:

• актуальность компонентов;
• административные доступы;
• новые внешние точки входа;
• защитные правила;
• мониторинг;
• резервное копирование;
• изменения архитектуры.

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

Как оцениваем результат

Результатом работы не должно быть абстрактное утверждение "сайт защищен". Абсолютную защиту от любых атак технически гарантировать невозможно.

Вместо этого должны быть понятны:

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

Что мы не делаем

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

Нужно усилить безопасность веб-проекта?

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

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

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