Компрометация приложений и интерфейсов программирования остается одной из главных причин инцидентов, связанных с утечками данных [1]. Современные приложения часто изначально разрабатываются с помощью методов DevOps для выполнения в облаке поверх микросервисных архитектур [2]. Такие приложения подвергаются растущему количеству сложных атак, в том числе автоматизированных и DDoS-атак, использующих уязвимости архитектуры, кода и конкретной конфигурации [3]. Дефекты архитектуры и кода необходимо устранять с помощью методов безопасного программирования и конфигурирования, которые должны быть интегрированы в цикл разработки.

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

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

Угрозы безопасности облачных приложений

За последнее десятилетие широкое распространение в программной и облачной индустрии получил термин «приложение, изначально разработанное для облака» (Cloud-Native Application, CNA) [2]. Такие приложения проектируют и реализуют в соответствии с набором принципов, направленных на применение изолированных распределенных архитектур на основе микросервисов с контролем версий, обеспечивающих эластичность и горизонтальную масштабируемость приложения. Еще один важный принцип — приоритет именно программной инфраструктуры для выполнения таких приложений, что способствует освоению практик инженерии на основе DevOps и достижению необходимого уровня автоматизации развертываний приложений и инфраструктуры.

Рис. 1. Типичная архитектура облачного приложения

На рис. 1 изображены типичная архитектура облачного приложения и конвейер проектирования, программирования, сборки и развертывания:

  • проектирование архитектуры и программирование — стадии цикла, в ходе которых приложение проектируется с учетом требований бизнеса и затем программно реализуется;
  • сборка, тестирование, развертывание — конвейер непрерывной интеграции и доставки (continuous integration/continuous delivery, CI/CD), который обеспечивает автоматическую сборку и развертывание артефактов приложения на одной или нескольких облачных платформах;
  • облачная платформа;
  • шлюз API — главный механизм взаимодействия и обмена данными между компонентами внутренней части приложения и клиентами (мобильными, традиционными и веб-приложениями и т. д.), а также сторонними API и клиентами в средах периферийных вычислений. Все эти взаимодействия происходят через сервис шлюза API. Контейнеры — самодостаточные модули, развертываемые и управляемые с помощью слоя оркестровки, содержащего необходимые компоненты реестра и среды выполнения. Каждый модуль инкапсулирует самостоятельный изолированный сервис приложения, в том числе его код, данные, зависимости и локальное хранилище данных. Среда выполнения и оркестровки бессерверных функций похожа на контейнеры, представляющие собой изолированные сервисы приложения, инкапсулированные в виде индивидуальных функций, реализованных согласно соответствующей парадигме. Уровень шины событий и брокера сообщений обеспечивает взаимодействие различных сервисов и обмен сообщениями между ними в условиях отсутствия единого центрального хранилища данных;
  • клиентские приложения — всевозможные клиенты, использующие сервисы приложения и с их помощью выполняющие задачи пользователя.

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

Угрозы

Рис. 2а. Число общеизвестных уязвимостей с высокой и критической опасностью в базе данных CVE, обусловленных дефектами разработки ПО

В 2019 году во многих отраслях атаки на веб-приложения вошли в тройку наиболее распространенных [1] — прогнозируется, что к 2025 году 70% атак на контейнеры и выполняемые в них рабочие нагрузки будут осуществляться с использованием известных уязвимостей и ошибок настройки. На рис. 2а можно видеть, что в 2019 году в различных приложениях было обнаружено несколько тысяч критических и опасных брешей безопасности, причем большинство из них связаны с неверной обработкой буферов памяти и представлением данных. Приложения, написанные на интерпретируемых языках, реже подвержены проблемам с буферами памяти, но в таких приложениях часто встречаются ошибки представления данных, открывающие поле для опасных атак межсайтового скриптинга, инъекций и выполнения постороннего кода.

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

Рис. 2б. Контейнерная модель поставки облачного приложения и связанные риски безопасности Рис. 2в. Бессерверная модель поставки облачного приложения и связанные риски безопасности

Модули, распространяемые в форматах популярных систем управления пакетами программ, таких как npm, Composer, Maven, pip, тоже не безупречны и могут содержать специально подготовленный вредоносный код. Десять образов контейнеров Docker, которые чаще остальных скачивали в 2019 году, содержат от двух до 15 уязвимостей на уровне ОС. При этом разработчики облачных приложений нередко пользуются популярными общедоступными образами в качестве базового слоя для реализуемых контейнерных нагрузок. Соответственно, эти нагрузки наследуют все подобные уязвимости. На рис. 2б и 2в представлены самые распространенные риски безопасности для контейнерных и бессерверных рабочих нагрузок, затрагивающие специально разработанные слои, причем к этим рискам добавляются еще и уязвимости облачной инфраструктуры.

Угрозы безопасности конвейера. Компрометация конвейеров CI/CD может влиять на целостность обрабатываемых программных артефактов и приводить к компрометации конфиденциальной информации, например, ключей и учетных данных приложения. Конвейеры выполняют роль центральной воронки создания и запуска рабочей нагрузки — их ненадежные конфигурации создают угрозу конфиденциальности, целостности и доступности рабочих нагрузок. Кроме того, конвейеры — один из первых и важнейших элементов в цепочке поставок облачного приложения, а защита цепочки поставок — обязательное условие создания надежных рабочих нагрузок.

Угрозы безопасности веб-приложений. Типичные угрозы безопасности веб-приложений хорошо исследованы и известны — организация Open Web Application Security Project Foundation с 2003 года регулярно публикует перечень топ-10 рисков безопасности веб-приложений [3]. Несмотря на все усилия по укреплению защищенности веб-приложений, бреши, приводящие к атакам инъекции, остаются наиболее опасными. Подобные дефекты могут возникать при использовании SQL, технологий NoSQL и популярных брокеров сообщений. Любой компонент, работающий с внешними входными данными, может быть уязвим для атак инъекции.

Угрозы безопасности контейнеров. Средства контейнеризации позволяют выполнять изолированные компоненты приложения поверх виртуализованной ОС. Помимо переносимости контейнеры обеспечивают и другие преимущества, в том числе с точки зрения эффективного использования низкоуровневой инфраструктуры и удобства освоения практики реализации инфраструктуры в виде кода (infrastructure as code), облегчающей развертывание и настройку за счет автоматизации. Но внедрение контейнеров приводит к резкому увеличению поверхности атаки приложения — уязвимым может быть весь стек инструментов, применяемых для контейнеризации. В числе рисков: уязвимость образа и механизма дистрибуции, слабые средства управления доступом на уровне оркестровки, бреши в среде выполнения.

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

Методы и проблемы обеспечения безопасности

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

Моделирование угроз

Моделирование или анализ угроз — система мер по идентификации, оценке и приоритизации угроз в контексте конкретного приложения или программной системы. Моделирование обычно выполняют на этапе проектирования и повторяют по мере внесения масштабных архитектурных изменений с точки зрения технологий и обрабатываемых источников данных. Методик моделирования угроз немало (не меньше 25), и обычно они основаны на сочетании ручных, автоматизированных, формальных процессов и визуализации. Однако, несмотря на изобилие, мало исследований, посвященных практическому применению моделирования угроз в контексте проектов DevOps- и agile-разработки. Существует ряд нерешенных проблем, касающихся прослеживаемости на уровне кода, статистической обработки результатов анализа угроз различных компонентов и автоматизации анализа, необходимой в условиях быстрых изменений технологий DevOps.

Инспекция кода вручную

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

Статический анализ

Статический анализ — один из самых распространенных методов оценки безопасности приложения, в основе которого лежит обнаружение уязвимостей в исходном коде без необходимости доступа к работающей программе или сервису. С помощью алгоритмов формирования умозаключений обнаруживаются уязвимые участки кода, сведения о которых передаются разработчикам для исправления. При статическом анализе используются аннотации, поиск по подстроке, специально подготовленные потоки данных. Такой анализ может выполняться на уровне отдельных операторов либо процедур и их групп. Основные недостатки методики касаются точности, скорости и масштабируемости. Кроме того, традиционные инструменты статического анализа, рассчитанные на монолитные приложения, не всегда подходят для многокомпонентных облачных.

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

Динамический анализ

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

Интерактивное тестирование

Интерактивное тестирование (Interactive Application Security Testing, IAST) — еще одна ключевая, но пока еще молодая, по сравнению с динамическим и статическим анализом, методика, дополняющая последние за счет интерактивных средств, помогающих увеличить точность распознавания уязвимостей. Системы IAST одновременно имеют и компонент для статического анализа кода, и механизм анализа в период выполнения, обеспечивающий измерение рабочих характеристик приложения. IAST позволяет выяснить, можно ли использовать обнаруженные уязвимости в атаках, что повышает точность распознавания и облегчает назначение приоритетов исправлениям.

Еще одно преимущество — возможность полной замены динамического анализа при условии наличия в конвейере CI/CD этапа функционального тестирования: агент IAST может работать на том же этапе, пользуясь соответствующими данными. Однако процесс измерения характеристик может вызывать деградацию производительности в период тестирования. Кроме того, из-за новизны технологии в решениях IAST может не быть поддержки некоторых языков программирования.

Самозащита в период выполнения

Механизмы самозащиты приложения при выполнении (runtime application self-protection, RASP) — еще одна относительно новая технология, предполагающая интеграцию в среду выполнения движка защиты, который следит за потоком выполнения, обнаруживая аномальные вызовы и подозрительное поведение, указывающее на идущую атаку. Механизмы RASP непрерывно анализируют безопасность и принимают восстановительные меры изнутри самого приложения.

Такие системы, используя средства измерения характеристик и виртуализации среды, следят за поведением приложения в режиме реального времени. Им присущ гораздо меньший уровень ложноположительных срабатываний по сравнению с решениями для статического анализа и более точный и полный охват потоков выполнения приложения. RASP можно комбинировать со статическим анализом для устранения критических уязвимостей определенного рода. Однако внедрение средств RASP чревато непроизводительными затратами в связи с необходимостью интеграции в каждое отдельно взятое приложение. Кроме того, они не устраняют уже существующие уязвимости, а лишь предотвращают их эксплуатацию в период выполнения.

Анализ состава ПО

Методика анализа состава ПО была предложена в ответ на рост количества общедоступных библиотек и опасность появления в облачных приложениях уязвимых зависимостей из открытого кода. В контексте DevOps методика реализуется путем интеграции средств проверки зависимостей в конвейер CI/CD, но ее надежность определяется доступностью обширной базы уязвимостей и качеством самого инструментария — если в базе есть пробелы, то опасные зависимости могут быть упущены. Кроме того, такие системы не всегда обеспечивают возможность проверки зависимостей второго порядка, создавая ложное чувство защищенности.

Тестирование на проникновение

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

В таблице приведены краткий обзор перечисленных методик и дополнительные требования к специалистам, которые ими пользуются. Часть методов, например, моделирование угроз и инспекции кода, требует ручных процессов, тогда как в наибольшей степени для DevOps подходят методики на базе автоматизированных средств, которые можно включать в конвейеры CI/CD.

Безопасность облачных приложений

Направления исследований

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

Специализированные шаблоны безопасности

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

Автоматизация моделирования угроз

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

Соответственно — требуется автоматизация. Во многих облачных приложениях используются типовые модули и архитектурные шаблоны, например, Open Application Model. С такими приложениями можно было бы применять системы автоматизированной идентификации и приоритизации угроз. Но в этой области нужны дополнительные исследования, чтобы обеспечить более полный охват разных архитектур и компонентов, в том числе конвейера выпуска приложения, а также чтобы наладить систематическую валидацию автоматически сформированных моделей и рекомендуемых ими мер по устранению уязвимостей.

Более удобные и эффективные средства обеспечения безопасности

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

Методы обнаружения и анализа уязвимостей на основе машинного обучения и добычи данных находятся еще на ранней стадии развития — не исследованы возможности, касающиеся конструирования признаков, проектирования и разработки алгоритмов. Некоторые средства с элементами искусственного интеллекта уже достигли высокой точности, но для определения принципов и областей применения таких технологий нужны дополнительные исследования. Требуется также определить конкретные характеристики подобных инструментариев, чтобы ускорить их внедрение. Кроме того, нужны доступные и высокоточные инструменты для сообщества открытого кода, которые позволят устранять уязвимости в проектах Open Source.

Развитие DevSecOps

Концепция DevSecOps появилась в связи с потребностью интегрировать современные методы обеспечения безопасности приложений в процессы DevOps и обещает реализацию принципа изначально предусмотренной безопасности (security by design), но пока не лишена существенных недостатков, в том числе связанных с трудностями выбора методов и подходов, позволяющих обеспечить баланс между безопасностью и производительностью без использования неудобных традиционных инструментов. На организационном уровне также есть потребность определить необходимый набор навыков, требования к изменениям в культуре, а также к соответствующим процессам, стандартам и практикам. Доступность необходимых компетенций, инструментов и сред эксплуатации, позволяющих обеспечивать безопасность приложений в условиях стремительных изменений, станет ключом к повышению качества соответствующих процессов.

***

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

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

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

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

Литература

1. 2019 data breach investigations report. Verizon, 2020. https://enterprise.verizon.com/resources/reports/dbir/2020/introduction (дата обращения 21.05.2020).

2. Kratzke N., Quint P.-C. Understanding cloud-native applications after 10 years of cloud computing: A systematic mapping study // J. Syst. Softw. 2017; 126: 1–16. DOI: 10.1016/j.jss.2017.01.001.

3. OWASP Top 10–2017: The ten most critical web application security risks. OWASP. https://www.owasp.org/index.php/Top_10-2017_Top_10 (дата обращения 18.08.2019).

Максим Чернышев (mchernyshev@deakin.edu.au) –  аспирант;  Зубэр Бейг (zubair.baig@deakin.edu.au) – профессор, Университет Дикина (Австралия); Шерали Зидэлли (szeadally@uky.edu) – профессор, Университет Кентукки.

Maxim Chernyshev, Zubair Baig, Deakin University, Sherali Zeadally, Cloud-Native Application Security: Risks, Opportunities, and Challenges in Securing the Evolving Attack Surface. IEEE Computer, November 2021, IEEE Computer Society. All rights reserved. Reprinted with permission.