2020/04/22 12:39:13

Как защитить большой веб

Виктор Рыжков, менеджер по продуктовому маркетингу направления Application Security компании Positive Technologies, в материале, подготовленном для TAdviser, рассказал об угрозах т.н. большому вебу — высоконагруженным проектам федерального масштаба, о том, как эволюционируют эти угрозы и методы защиты от них.

Содержание

По данным Positive Technologies за 2019 год, эксплуатация веб-уязвимостей входит в топ-3 популярных методов атак, направленных на юридические лица. Главными мотивами киберпреступников остаются получение данных и финансовая выгода, потому особый интерес для них представляет большой веб — высоконагруженные проекты федерального масштаба, которые содержат персональные и платежные данные миллионов граждан. К таким веб-ресурсам относятся порталы государственных услуг, банковские и финансовые сервисы, социальные сети, онлайн-магазины, крупные агрегаторы, онлайн-кинотеатры и многое другое. Как обеспечить защиту таких масштабных проектов и какие требования необходимо предъявлять к основным средствам защиты веб-приложений?

Как защитить большой веб

Ландшафт угроз

Для защиты веб-ресурсов используются решения класса web application firewall (WAF) — межсетевые экраны уровня приложений. WAF позволяет защититься от современных атак на веб — угроз из списка OWASP Top 10, DDoS-атак уровня приложений и других.

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

Доступность. Веб-приложение должно быть доступно 99—99,999% времени. Это означает, что время простоя в течение года не может быть более четырех дней (99%) или 5,5 минут (99,999%). Очевидно, WAF должен также соблюдать эти требования, чтобы сохранить показатели доступности приложения.TAdviser выпустил Гид по российским операционным системам 10.4 т

Время отклика. Обработка запросов пользователя и выдача результата должны занимать от нескольких секунд до миллисекунд — в зависимости от бизнес-логики. И WAF не должен вносить существенную задержку в этот параметр.

Защищенность. Методы атак меняются в зависимости от трендов, существующих в разработке приложений, например Web 2.0, SPA, REST API. Вместе с новыми технологиями меняется и ландшафт угроз. Следовательно, WAF должен постоянно пополняться новыми методами их обнаружения.

Давайте проследим, как развивался большой веб в России и как, в зависимости от этих изменений, менялись и продолжают меняться требования к WAF — основному средству защиты веб. Для иллюстрации этих изменений рассмотрим PT Application Firewall — решение компании Positive Technologies.

Как защищали большой веб пять лет назад

Вспомним 2015 год. На первый взгляд, этот год не многим отличался от 2020-го: компании предоставляли цифровые сервисы своим клиентам, внедряли Agile, CI/CD и другие подходы, ускоряющие процессы разработки и обновления приложений.

Но характерной особенностью того периода был способ размещения веб-приложений. Большие компании размещали подавляющее большинство приложений в «домашних» ЦОД — на своих вычислительных мощностях. Плюс такого подхода в том, что компания получает полный контроль над веб-приложениями (как аппаратной, так и программной частями). Однако при таком подходе есть ряд ограничений и сложностей:

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

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

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

С точки зрения защиты тогда также требовалось выявление атак из списка OWASP Top 10, но список этот несколько отличался от актуального: в топе находились угрозы, которые стали менее распространены. Например, межсайтовое выполнение сценариев (XSS, Cross-Site Scripting) было угрозой № 2 (сегодня — угроза № 7), а межсайтовая подделка запроса (CSRF, Cross-Site Request Forgery) — угрозой № 5 (сегодня — отсутствует в списке).

Исходя из условий того времени, закономерно формировались и требования к web application firewall. С одной стороны, нужны были быстрая адаптация к изменениям в приложениях, производительность и отказоустойчивость. С другой стороны, для выявления атак в большинстве случаев WAF было достаточно сигнатурного анализа, механизмы машинного обучения для обнаружения неизвестных угроз применялись не так часто.

Так, в свое время PT Application Firewall получил возможность установки в двухсерверный кластер (в режиме active — passive) и механизмы адаптации под каждое веб-приложение на уровне политик. Обнаружение известных и неизвестных угроз стало доступно благодаря возможности сигнатурного анализа трафика и комбинации дополнительных модулей машинного обучения: в частности, самообучающегося модуля HMM.

Как защищать сейчас

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

Второй важный тренд — это разнородность инфраструктур веб-приложений. Помимо домашнего ЦОД большой веб все чаще использует ресурсы хостинг-провайдеров, публичного или частного облака (private сloud). Такой комбинированный подход снимает ограничения домашнего ЦОД: ответственность за соблюдение доступности ресурсов компания делегирует сервис-провайдеру. Теперь эти показатели могут быть выше — вплоть до 99,999% времени. Также упрощается и масштабирование: при необходимости достаточно запросить дополнительные ресурсы. Третий тренд — это увеличение трафика ботов в Сети.

Уже сейчас этот показатель составляет почти 40%, однако далеко не все из них относятся к безвредным — ботам поисковых систем, чат-ботам.

Исходя из перечисленного, к современному web application firewall также предъявляются повышенные требования доступности: до 99,999% времени (или 5,5 минут простоя в год), а также требования по горизонтальному масштабированию под любую нагрузку. Если говорить о выявлении атак, то теперь WAF должен защищать не только само приложение, но и его публичный API, а также обнаруживать и классифицировать ботов. Для всего этого уже недостаточно сигнатурного анализа, необходимы алгоритмы глубокого машинного обучения (deep machine learning).

К сожалению, не все WAF отвечают новым требованиям — чаще всего в силу архитектурных особенностей, заложенных в далеком прошлом. Также негативным фактором, влияющим на развитие WAF, является сложившаяся за долгие годы тенденция их установки не в активном (inline), а в пассивном (out-of-band, sniffer) режиме. В этом режиме WAF не становится возможной точкой отказа приложений, но в таком случае решения лишены возможности блокирования атак — это не мотивирует некоторых производителей WAF делать продукт стабильнее и надежнее.

В новом PT Application Firewall встроены алгоритмы глубокого машинного обучения, позволяющие выявлять новейшие и неизвестные угрозы на приложения и API, а также выявлять и классифицировать ботов. Благодаря новой, микросервисной архитектуре[1] компоненты PT Application Firewall становятся слабосвязанными и масштабируемыми независимо друг от друга — это дает продукту возможность обеспечивать высокие показатели доступности веб-приложений (до 99,999% времени в активном режиме). Упрощен процесс встраивания PT Application Firewall в инфраструктуру заказчика: новые публикуемые приложения теперь добавляются в два клика, предусмотрены дополнительные, упрощенные варианты интеграции (например, специальный легковесный агент, устанавливаемый на веб-сервер Nginx и обеспечивающий блокирование угроз и пересылку информации в ядро PT Application Firewall).

Какие вызовы ждут большой веб завтра

Интерес компаний к облачным технологиям продолжается. Согласно отчету аналитического агентства IDC, в 2018 году рынок облаков в России вырос на 24,8% и в 2019-м продолжил расти.

Закономерно растет интерес и к облачным WAF. По прогнозам аналитического агентства Gartner, доля «железных» WAF (работающих в домашних ЦОД) к 2022 году снизится с сегодняшних 30% до 10%. Также прогнозируется и рост потребности в защите API, выявлении и классификации ботов, широком использовании машинного обучения.

Каким должен быть WAF будущего? Прежде всего гибким и готовым к размещению в распределенных инфраструктурах — как в условиях домашнего ЦОД, так и на облачных ресурсах. При этом для WAF становится критически важным соблюдение высоких показателей доступности, предъявляемых для защищаемых приложений (до 99,999 % времени). С точки зрения безопасности WAF будущего должен обеспечивать равную степень защиты как для самого приложения, так и для его API, предотвращать известные и неизвестные ранее атаки с применением сигнатурного анализа и алгоритмов глубокого машинного обучения.

Смотрите также

Контроль и блокировки сайтов

Анонимность

Критическая инфраструктура

Импортозамещение


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

* Регулирование интернета в Казахстане, KZ-CERT




Примечания

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