Монолитные приложения частично утратили популярность в эпоху микросервисных архитектур, но, возможно, это скоро изменится. Организации начинают обращать внимание не только на преимущества, но и на недостатки использования микросервисов, в том числе в контексте безопасности.
Популярность микросервисов
Основная мотивация создания программного обеспечения из связанных модулей, а не одного куска кода для всего приложения, не изменилась. Модульное ПО легче разрабатывать, поддерживать, тестировать, расширять и повторно использовать, а сочетание облачных развертываний с гибкой разработкой быстро сделало эти преимущества еще более привлекательными. Особенно в случае стартапов, небольшие команды, у которых есть только ноутбуки, могут использовать микросервисы для быстрого создания инновационного программного обеспечения без первоначальных инвестиций. Для облачных приложений в контейнерах микросервис стал основной архитектурой, а поставщики облачных услуг быстро переходят к предоставлению готовых к использованию сред и функциональных возможностей для создания распределенного ПО.
Но, несмотря на все свои преимущества, микросервисная архитектура не универсальна. К примеру, в исследовании кейса Amazon, их использование оказалось совершенно неправильным решением. Из-за типа и самой интенсивности вызовов микросервисов, архитектура на основе бессерверных компонентов Amazon Web Services была медленной, дорогой и непригодной для масштабирования на необходимом уровне. Переход к монолитному приложению привел к снижению расходов на облако на 90% и улучшению работы в данном конкретном случае.
Этот кейс появился в то время, когда все больше организаций начали пересматривать свою облачную стратегию и серьезно взвешивают все за и против облачного развертывания по сравнению с локальным. Хотя преимущественно это обусловлено стоимостью облака, выбор архитектуры приложения также имеет серьезные последствия для безопасности.
Монолитная архитектура: сложнее обновить, но легче защитить
Наличие монолитного приложения, содержащего всю базу кода в одном месте, традиционно считалось плохой инженерной практикой. В частности, любое изменение обычно требует перестройки всей программы, даже если это только одна строка кода. В зависимости от внутренней структуры монолитная архитектура также может быть сложной в обслуживании, поскольку любые изменения могут нарушить функционирование. А также быть склонна к чрезмерному разрастанию, так как быстрее и безопаснее добавить новую функцию, чем адаптировать или удалить существующую.
Во-первых, поверхность атаки монолитного приложения обычно будет меньше по сравнению с архитектурами, где каждый микросервис является отдельной целью. Менее распределенные программы обычно имеют меньше внешних зависимостей, поэтому более понятно, что нужно тестировать. В монолите вся бизнес-логика и коммуникация между функциями обрабатываются внутренне, а не через потоки вызовов API, которыми обмениваются фронтенд и бэкенд. Для монолитного приложения также легче настроить меры защиты данных, безопасности сети и инструменты защиты во время выполнения, такие как брандмауэр веб-приложений (WAF).
Кроме того, в этом случае упрощается тестирование безопасности. Ведь тогда команде доступна большая часть или весь исходный код (часто с тем же стеком технологий и языком программирования). Можно применить не только динамическое тестирование безопасности программы (DAST), как решения Invicti и Acunetix, которое внедряют в различные этапы жизненного цикла разработки ПО (SDLC), от первых сборок до финального приложения в продакшне. А также доступно использование статического тестирования безопасности приложений (SAST) и анализа программных компонентов (SCA), как Mend.io.
Одним из недостатков монолитной архитектуры является то, что процесс налаживания и устранения недостатков безопасности может быть медленнее по сравнению с микросервисами. В микросервисах легче изолировать и исправить уязвимости в конкретной службе (если команда разработчиков имеет доступ к исходному коду).
Минусы и плюсы микросервисов в контексте безопасности
Преимущества микросервисов следует сравнивать со многими потенциальными проблемами безопасности. Вышеупомянутые проблемы связанными с тем, что поверхность атаки расширяется на десятки или сотни независимых сервисов. На уровне безопасности инфраструктуры каждая отдельная служба часто работает в облачном контейнере с конкретными служебными инстансами. Они организованны с помощью Kubernetes или подобного решения, что делает важной защиту облака. Поскольку все компоненты приложения коммуницируют через вызовы API, их безопасность также имеет первостепенное значение как для операций, так и для тестирования. При этом аутентификация часто является проблемой. Так как каждая служба выступает отдельной целью, мониторинг является еще одним слабым местом. Злоумышленники потенциально могут таргетировать отдельные службы, не вызывая уведомление о том, что приложение подвергается атаке.
С облачными приложениями легко полагаться на сторонние зависимости и службы, которые компания не контролирует и может проверять только извне, ограничивая методы до DAST и ручного тестирования на проникновение. В сочетании с тем фактом, что приложения могут использовать несколько языков программирования и технологий, это делает инструменты анализа кода, такие как SAST и SCA ограниченными. Даже если команда контролирует и способна проверять свою основную базу кода, этого недостаточно, чтобы охватить всю поверхность атаки.
Как уже упоминалось, преимущество микросервисов состоит в том, что изолировать недостаток безопасности для определенной службы легче, чем в монолитном приложении. Также проще применить брандмауэр или полностью заблокировать службу, если невозможно быстро устранить уязвимость. Кроме того, службы, как правило, автономны, что уменьшает риск полной компрометации системы, если один компонент программы взломан.
Надежное тестирование безопасности программ независимо от архитектуры
Относительная легкость и быстрота создания и модификации веб-приложений также распространяется на изменения в архитектуре и моделях развертывания. Но хотя аспекты разработки программного обеспечения и инфраструктуры таких проектов часто понятны и управляемы, безопасность не всегда за ними успевает. Например, если приложение переведено на другой стек технологий и язык программирования, существующие инструменты SAST и рабочие процессы могут ему больше не подходить. Или если компания-разработчик, ранее в значительной степени применявшая SAST для тестирования своих монолитных приложений, начинает создавать ПО с помощью микросервисов, обнаруживает, что у них нет DAST для проверки всей среды, которая значительно полагается на API.
Преимущество решений DAST в том, что они способны сканировать веб-приложения независимо от их технологий и архитектур. Но на практике они могут сильно отличаться точностью и практической пользой. К примеру, многие организации полагаются на облачные сканеры уязвимостей для защиты своих облачных приложений. Когда они решают перенести часть программного обеспечения в локальное развертывание, они часто понимают, что используемый ими продукт больше не покрывает их потребности. Подобные сюрпризы могут также относиться к движению в сторону микросервисов, поскольку компании иногда слишком поздно осознают, что теперь им нужно сканировать большое количество API, с которыми их инструменты не справляются.
Универсальным вариантом является выбор решения DAST, которое будет эффективно работать независимо от архитектуры или модели развертывания. Например, лидер среди динамических сканеров для веб-приложений Invicti позволяет организациям внедрять тестирование безопасности в конвейеры DevOps. Это позволяет автоматически запускать сканирование, подтверждать уязвимости и отправлять отчеты о них непосредственно в системы отслеживания ошибок. И все это как для облачных, так и для локальных приложений с поддержкой проверок разных типов API.
