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

Ситуация с безопасностью усугубляется распространением программного обеспечения с открытым исходным кодом, контейнеризацией и инфраструктурой как кодом (IaC). Теперь, когда адаптация или модификация микросервиса может занять 15 минут, у специалистов по безопасности может не быть своевременной возможности должным образом проанализировать безопасность микросервисов. Внедрение комплексной оценки безопасности в качестве контрольного этапа в конвейерах развертывания почти всегда вызывает неблагоприятную реакцию со стороны команды DevOps. Даже если кому-то удалось эффективно блокировать развертывание, многие проблемы безопасности, особенно атаки во время выполнения, не могут быть выявлены во время развертывания.

Безопасность уже не та

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

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

Учитывая все факторы, которые необходимо учитывать для надлежащей безопасности, необходимо собрать, сопоставить, обработать и изучить большой объем данных почти в режиме реального времени, чтобы принимать обоснованные и своевременные решения по обеспечению безопасности. Это требование делает традиционные решения и средства контроля неадекватными. К счастью, достижения в машинном обучении (ML) и зрелость моделей обучения за последнее десятилетие обеспечивают очень мощную платформу для решения этих новых проблем безопасности.

МЛ в помощь!

Мощь машинного обучения позволяет нам переосмыслить то, как мы определяем, совершенствуем и реализуем элементы управления безопасностью. Это позволяет нам справляться с динамическим характером взаимодействия API и при этом обеспечивать эффективную безопасность API. Теперь мы обсудим три основных шага в создании комплексного и эффективного решения на основе машинного обучения.

1. Позвольте машинному обучению открыть для себя возможности… Не подпитывайте его

Как обсуждалось ранее, динамический характер и огромный объем API-интерфейсов не позволяют разработчикам или группам безопасности осмысленно определять и передавать определения API в системы, обеспечивающие безопасность конечных точек API. С моделями на основе машинного обучения можно вводить некоторые данные обучения в автономном режиме и позволить системе автономно обнаруживать, идентифицировать, классифицировать, учитывать и разрешать/запрещать вызовы API на основе конечной точки API (скажем, путь URL в случае HTTP), вызывающая сторона, полезная нагрузка и т. д. Например, обнаружение API выполняется с использованием графа URL-адресов на основе машинного обучения и классификации компонентов, которые можно выполнить с помощью глубокого обучения. Это позволяет системе со временем строить, расширять и изучать объем и характер обмена данными через API.

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

2. Изучайте, настраивайте, повторяйте

Это основная часть любого решения безопасности на основе машинного обучения. Хорошие решения позволяют элементам управления безопасностью наблюдать за поведением системы, создавать профили поведения и корректировать текущую модель (построенную с использованием прошлых наблюдений). Это непрерывный процесс, и четко реализованное решение позволяет применять элементы управления осмысленно и своевременно. Например, если прошлые профили показали, что определенная последовательность вызовов API является обычным потоком, обновленная сборка приложения, которая реализует пару дополнительных вызовов в потоке, может быть изучена и добавлена ​​в профиль за считанные часы.

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

3. Обнаружить

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

На рис. 2 показана последовательность вызовов API, профилированная как нормальная и приемлемая для системы.

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

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

Как только эти решения будут реализованы и начнут приносить результаты, их можно использовать для улучшения существующих элементов управления, таких как брандмауэры веб-приложений (WAF) для трафика на основе HTTP.

Подведение итогов

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