Построение кибербезопасной архитектуры веб-приложений

Введение

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

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

Исходя из определения, перед нами стоят две основные задачи, которые необходимо решить:

правильно спроектировать веб-приложение;
определить требования кибербезопасности к разработке веб‑приложения.

Обзор архитектуры типового веб-приложения

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

Архитектура веб-приложения Рисунок 1. Архитектура веб-приложения

Рассмотрим компоненты веб-приложения.

Компоненты серверной части:

Веб-серверы. Веб-серверы обрабатывают первоначальный запрос от клиента и отвечают файлами в формате HTML, CSS, JavaScript или другими статическими файлами. Популярными веб‑серверами являются Apache HTTP Server и nginx.
Серверы приложений. Серверы приложений обрабатывают генерацию динамического контента и определяют логику работы с данными веб-приложений. Они выполняют код, написанный на таких языках, как Python, Ruby, Java или PHP. Примерами таких серверов являются Apache Tomcat, Gunicorn и Unicorn.
Балансировщики нагрузки. Балансировщики нагрузки распределяют входящий сетевой трафик между несколькими веб-серверами или серверами приложений для обеспечения эффективного использования ресурсов, повышения производительности и высокой доступности. Они могут быть программными (например, nginx) или аппаратными (например, F5 Big-IP).
Механизмы кэширования. Механизмы кэширования, такие как Redis, memcached или Varnish, помогают хранить часто используемые данные в памяти. Они сокращают время отклика, уменьшают нагрузку на базу данных и повышают общую производительность системы.
Базы данных. Базы данных хранят и извлекают структурированные данные. Распространенными типами являются реляционные базы данных, такие как MySQL, PostgreSQL или Oracle, и базы данных NoSQL, такие как MongoDB или Cassandra. Они обеспечивают постоянное хранилище данных веб-приложений.
API. Серверы API используются для предоставления данных другим информационным системам и мобильным приложениям.

Компоненты клиентской части:

Браузер. Современные браузеры представляют собой удобный инструмент для использования веб‑приложения. Браузеры имеют богатый набор функций, в том числе собственное хранилище. Функции современных браузеров могут быть расширены при установке плагинов.
Сети доставки контента (CDN от англ. content delivery network). CDN — это территориально распределенная сетевая инфраструктура, обеспечивающая быструю доставку контента пользователям веб-сервисов. CDN хранят кэшированные копии статического контента (изображения, CSS, JavaScript) в различных территориально распределенных центрах обработки данных. Они помогают сократить задержку и использование полосы пропускания, доставляя контент из места, расположенного ближе к пользователю. Примерами популярных CDN являются Cloudflare, Akamai, Amazon CloudFront и Yandex Cloud CDN.
Внешние информационные системы. Внешние информационные системы получают доступ к веб-приложению, используя встроенные функции API, либо, в случае его отсутствия, пытаются собрать информацию с веб-приложения напрямую, применяя различные технологии веб-скрапинга.
Мобильное приложение. Для пользователей может быть разработано мобильное приложение, которое будет получать данные через специальный API.

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

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

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

Основные угрозы и уязвимости компонентов веб‑приложения

В исследовании Positive Technologies «Уязвимости и угрозы веб-приложений в 2020–2021 гг.» было установлено, что в абсолютном большинстве веб-приложений (98%) злоумышленники имеют возможность проводить атаки на пользователей; утечки важных данных имели место в 91% веб-приложений; возможность несанкционированного доступа была отмечена в 84% веб-приложений, участвовавших в исследовании. Наиболее опасными уязвимостями стали недостатки механизмов авторизации и аутентификации пользователей.

В исследовании Kaspersky Security Services «Топ-10 уязвимостей в веб-приложениях в 2021–2023 годах» основными категориями уязвимостей стали недостатки контроля доступа (70% всех проанализированных приложений), раскрытие чувствительной информации (без указания процентов), подделка межсерверных запросов (SSRF) (57% содержали уязвимость, которая позволяла злоумышленнику взаимодействовать с внутренними сервисами в обход логики приложения).

Современной тенденцией также является увеличение числа атак со стороны ботов. По данным исследования «Imperva Bad Bot Report», почти половина интернет-трафика приходится на ботов, большинство из которых (30,2% против 17,3%) являются «плохими» (то есть цель данного ПО — запуск автоматических задач со злым умыслом).

OWASP Top 10 — общепризнанный источник информации об основных рисках (категориях уязвимостей) для веб-приложений. В табл. 1 показаны категории OWASP Top 10–2021 и их описание (перевод категорий и описание сделаны автором и не являются частью OWASP Top 10–2021).

Таблица 1. Категории OWASP Top 10

Категория OWASP	Краткое описание
А01:2021-Недостатки контроля доступа	Нарушение политики управления доступом приводит к несанкционированному разглашению, изменению или уничтожению данных, а также к возможному выполнению бизнес‑функции, выходящей за рамки прав доступа пользователя
A02:2021-Ошибки реализации криптографии	Ошибки в реализации криптографической защиты часто приводят к раскрытию конфиденциальных данных при их хранении или передаче по сети
A03:2021-Инъекции	Существуют различные виды инъекций (SQL, NoSQL, LDAP, ORM и другие), опасность которых возникает в случае некорректной проверки введенных данных. Это позволяет злоумышленнику передать в следующий компонент веб-приложения (например, СУБД) вредоносный код через формы ввода
A04:2021-Небезопасный дизайн	Широкая категория, представляющая различные недостатки архитектуры, выраженные в отсутствии или неэффективности используемых средств защиты
A05:2021-Неправильная настройка безопасности	Категория, включающая уязвимости, связанные с неправильной настройкой компонентов веб-приложения
A06:2021-Уязвимые и устаревшие компоненты	Использование уязвимых компонентов влечет за собой ряд потенциальных рисков и проблем. Уязвимости могут иметь разный потенциал, эксплуатация уязвимости имеет разную сложность (например, для некоторых уязвимостей эксплойт может находиться в открытом доступе), для уязвимостей может быть недоступно обновление (например, оно может быть не разработано или блокироваться вендором по причине наложенных ограничений). Разный потенциал уязвимостей, разная сложность эксплуатации, недоступность обновления и прочие могут стать причиной возникновения рисков
A07:2021-Ошибки идентификации и аутентификации	Категория включает ошибки, связанные со сбоями идентификации и аутентификации
A08:2021-Нарушения целостности программного обеспечения и данных	Категория, связанная с обновлением программного обеспечения критически важных данных и конвейеров CI/CD без проверки целостности
A09:2021-Недостатки журналирования и мониторинга безопасности	Категория, связанная с недостатками или отсутствием журналирования событий безопасности или мониторинга безопасности. Без регистрации и мониторинга работы веб‑приложения невозможно обнаружить события и инциденты информационной безопасности, а значит, предпринять ответные действия
A10:2021-Подделка запросов на стороне сервера	Ошибки Server-Side Request Forgery (SSRF) возникают всякий раз, когда веб-приложение извлекает удаленный ресурс без проверки URL-адреса, предоставленного пользователем. Это позволяет злоумышленнику отправлять запросы от имени скомпрометированного сервера, что, в свою очередь, может заставить приложение отправить созданный запрос, даже если оно защищено межсетевым экраном, VPN или списком управления доступом к сети

OWASP Top 10 является группировкой уязвимостей (CWE и CVE) по категориям. Категория «A04:2021-Небезопасный дизайн» впервые появилась в последней редакции, что говорит о важности принятия правильных архитектурных решений в части обеспечения кибербезопасности. Такие решения должны приниматься как можно раньше в цикле разработки веб-приложения.

Проактивные аспекты и требования кибербезопасной архитектуры при разработке веб-приложения

С точки зрения построения кибербезопасной архитектуры веб-приложения разберем два проекта OWASP — это OWASP Proactive Controls (OWASP PC) и OWASP Application Security Verification Standard (OWASP ASVS). Рекомендации «Проактивная защита: Топ‑10 требований OWASP» (из документа OWASP Proactive Controls), на которые разработчики должны обращать внимание при создании веб-приложения, приведены в таблице ниже.

Таблица 2. Краткое описание проактивных аспектов безопасности OWASP PC

Наименование аспекта	Краткое описание
С1: Определение требований безопасности	Требования безопасности описывают функции, которые необходимо реализовать для обеспечения определенных параметров безопасности ПО. Эти требования составляются на основе промышленных стандартов, действующих законов и данных об обнаруженных уязвимостях. Требования безопасности определяют функции, которые необходимо разработать или доработать для решения определенных проблем с безопасностью или устранения потенциальных угроз
С2: Использование безопасных фреймворков и библиотек	Безопасные библиотеки и фреймворки со встроенными функциями безопасности помогают разработчикам избежать появления уязвимостей на этапе разработки и реализации. Разработчики, создающие приложение с нуля, могут не иметь достаточных знаний, времени или средств для реализации или поддержания безопасности. Использование безопасных фреймворков позволяет добиваться безопасности приложений наиболее эффективно
С3: Обеспечение безопасного доступа к базе данных	Обеспечение безопасного доступа ко всем хранилищам данных, включая реляционные базы данных и базы данных NoSQL, является ключевым аспектом безопасности приложения. Для этого необходимо учитывать следующие аспекты: - безопасность запросов; - безопасность конфигурации; - безопасность аутентификации; - безопасность соединений
С4: Кодирование и экранирование данных	Кодирование и экранирование являются методами защиты от внедрения кода. Кодирование (обычно называемое кодированием выходных данных) представляет собой преобразование специальных символов в эквивалентные, неопасные для интерпретатора комбинации (например, преобразование символа < в сочетание < при его добавлении на HTML-страницу). Экранирование заключается в добавлении спецсимволов перед символами или строками для предотвращения их некорректной интерпретации (например, добавление символа \ перед " позволяет интерпретировать их в качестве части текста, а не в качестве обозначения окончания строки)
C5: Обязательная проверка всех входных данных	Проверка входных данных является частью методики программирования, обеспечивающей попадание в компоненты программы только правильно отформатированных данных
C6: Внедрение цифровой идентификации	Цифровая идентификация — это уникальное представление пользователя (или любого другого объекта) при онлайн‑транзакциях. Она также должна быть обеспечена аутентификацией и управлением сессиями. Аутентификация — процесс подтверждения того, что человек или сущность является тем, кем представляется. Управление сессиями — процесс, с помощью которого сервер контролирует состояние аутентификации пользователя, чтобы он мог продолжать пользоваться системой без повторной аутентификации
C7: Обязательный контроль доступа	Контроль доступа (или авторизация) заключается в разрешении или запрещении специфических запросов, поступающих от пользователей, программ или процессов, а также предполагает выдачу и отзыв подобных привилегий
C8: Повсеместная защита данных	Конфиденциальные данные, такие как пароли, номера кредитных карт, медицинские записи, персональные данные и коммерческие тайны требуют дополнительной защиты. Первое правило управления конфиденциальными данными — избегать хранения конфиденциальных данных, когда это возможно. Если сохранять конфиденциальные данные необходимо, то убедитесь в наличии у них криптографической защиты от несанкционированного доступа и изменений
C9: Внедрение журналирования и мониторинга событий безопасности	Большинство разработчиков уже используют журналирование при отладке и диагностике. Однако важно также регистрировать события безопасности и во время работы приложения. Мониторинг — это анализ приложения и журналов безопасности с помощью различных средств автоматизации. Такие же инструменты и шаблоны могут применяться к выполняемым операциям, отладке и обеспечению безопасности
C10: Обязательная обработка всех ошибок и исключений	Обработка исключений позволяет приложению реагировать на различные ошибки (например, сбой сети или подключения к базе данных) различными способами. Корректная обработка исключений и ошибок необходима для обеспечения надежности и безопасности вашего кода

В первом же аспекте «С1: Определение требований к безопасности» OWASP PC ссылается на OWASP ASVS, который представляет собой каталог доступных требований и параметров проверки. Требования безопасности объединены в категории на основе общих функций безопасности высшего порядка. Каждая категория содержит перечень требований, представляющих собой рекомендации для этой категории в виде списка проверяемых параметров.

OWASP ASVS регулярно обновляется (идет разработка 5-й версии). Текущая стабильная версия — 4.0.3, в дальнейшем анализе мы будем использовать ее. Стандарт верификации требований к безопасности приложений определяет три уровня соответствия, каждый из которых усиливает требования предыдущего:

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

Диаграмма Эйлера-Венна распределения требований между уровнями OWASP ASVS Рисунок 2. Диаграмма Эйлера-Венна распределения требований между уровнями OWASP ASVS

Для низкого (базового уровня) достаточно исполнения 128 требований, чтобы обеспечить второй уровень защиты необходимо дополнительно исполнить 130 требований (см. рис. 2). Переход на третий уровень добавляет 20 требований, а также ужесточает некоторые требования: добавление аппаратного модуля безопасности (Hardware Security Module (HSM)), меньшее время жизни сессий.

На рис. 3 показаны основные главы OWASP ASVS (всего их 14), внутри которых выделены разделы (секции), содержащие требования (размер зависит от количества требований в секции).

Главы ASVS Рисунок 3. Главы ASVS

Больше всего требований в главах «Аутентификация» и «Архитектура, проектирование и моделирование угроз» (см. рис. 3). Если к ним прибавить требования глав «ФЛК, нейтрализация и кодировка» (ФЛК — форматно‑логический контроль) и «Конфигурация», то можно охватить более 50% требований OWASP ASVS.

Факторы, влияющие на кибербезопасную архитектуру веб‑приложения

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

Моделирование угроз. Начните с выявления потенциальных угроз и уязвимостей, характерных для вашего веб-приложения. Проведите тщательную оценку архитектуры веб-приложения, чтобы понять потенциальное воздействие различных угроз.
Практика безопасного кодирования. Внедряйте методы безопасного кодирования на протяжении всего процесса разработки. Сюда входит проверка входных данных, кодирование выходных данных, контроль доступа и соблюдение правил безопасного кодирования.
Аутентификация и авторизация. Внедрите надежные методы аутентификации. Выбор метода аутентификации зависит от специфики работы и степени важности веб-приложения или отдельных его частей. Для привилегированных и административных учетных записей необходимо использовать многофакторную аутентификацию. Кроме того, внедрите механизмы авторизации для ограничения доступа к ресурсам веб-приложения на основе ролей или привилегий пользователей.
Шифрование. Используйте надежные протоколы шифрования, такие как HTTPS/TLS, для защиты данных при передаче. Зашифруйте хранящиеся конфиденциальные данные, используя соответствующие механизмы шифрования, основанные на лучших отраслевых практиках.
Межсетевой экран прикладного уровня (WAF). Разверните WAF для фильтрации и мониторинга входящего веб-трафика, предотвращения таких атак, как внедрение SQL-кода, межсайтовое выполнение сценариев (XSS) и других распространенных уязвимостей.
Управление сессиями. Обеспечьте безопасное управление сессиями, используя сессионные ключи или токены доступа. Устанавливайте тайм-ауты сессий и ограниченное время жизни токенов.
Проверка входных данных и кодирование выходных данных. Внедрите строгую проверку входных данных, чтобы предотвратить распространенные атаки, такие как SQL-инъекция, межсайтовый скриптинг и внедрение команд. Кроме того, примените кодирование вывода для защиты от атак с использованием межсайтовых сценариев.
Мониторинг безопасности и реагирование на инциденты. Внедрите надежные механизмы регистрации и мониторинга для оперативного обнаружения инцидентов безопасности и реагирования на них. Настройте оповещения о подозрительных действиях и разработайте план реагирования на инциденты.
Безопасное развертывание и управление исправлениями. Следуйте правилам безопасного развертывания, включая безопасную настройку веб‑серверов, инфраструктур приложений и компонентов инфраструктуры. Регулярно применяйте исправления и обновления безопасности, чтобы обеспечить безопасность приложения и базовых компонентов.
Регулярные проверки безопасности и тестирование на проникновение. Проводите регулярные проверки безопасности и тестирование на проникновение для выявления уязвимостей и слабых мест в вашем веб-приложении. Своевременно устраняйте выявленные проблемы. Помните, что безопасность — это непрерывный процесс, и крайне важно быть в курсе развивающихся угроз и новых технологий. Регулярно переоценивайте и совершенствуйте свою архитектуру информационной безопасности, чтобы решать новые проблемы и эффективно защищать свое веб‑приложение.

Харденинг компонентов веб-приложения

Веб-сервер, серверы приложений, сервер базы данных, сервер кэширования, серверы для хранения файлов статики (CDN), API, нуждаются в харденинге. Подробнее о процессе харденинга написано в статье

Построение кибербезопасной архитектуры

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

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

Пример кибербезопасной архитектуры веб-приложения Рисунок 4. Пример кибербезопасной архитектуры веб-приложения

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

Таблица 3. Основные компоненты защиты веб-приложения

Компонент защиты	Описание
DDoS-защита	Защита от распределенных атак типа «отказ в обслуживании» (Distributed Denial of Service (DDoS)) является мерой безопасности, предназначенной для защиты сетевых ресурсов от больших объемов трафика, создаваемого злоумышленниками с целью сделать систему недоступной для законных пользователей. Также следует рассмотреть возможность обеспечения работы антибот-решений, нацеленных на предотвращение атак со стороны ботов. Данный компонент защиты должен быть основан на поведенческом анализе и предотвращать атаки в том числе на уровне приложения
Межсетевой экран (NGFW)	Межсетевой экран (Next-Generation Firewall (NGFW)) обеспечивает: · проактивную защиту: NGFW способен определить и блокировать известные угрозы, а также анализировать неизвестные, чтобы предотвратить их проникновение в сеть; · интеллектуальный анализ трафика: NGFW анализирует каждый байт передаваемых данных, что позволяет обнаруживать даже замаскированные угрозы; · управление доступом к приложениям: NGFW позволяет контролировать доступ к конкретным приложениям и сервисам, что улучшает безопасность сети; · визуализацию и мониторинг: NGFW предоставляет интуитивно понятный интерфейс для наблюдения за состоянием сети и обнаружения потенциальных угроз; · расширенную поддержку протоколов: NGFW поддерживает множество сетевых протоколов, что позволяет обеспечить защиту всех видов сетевого трафика.
Web Application Firewall (WAF)	Web Application Firewall (WAF) — это специализированное программное обеспечение, предназначенное для защиты веб‑приложений от различных видов атак, включая SQL‑инъекции, XSS, атаки с использованием скриптов и других вредоносных действий. WAF анализирует входящий трафик, определяет, является ли он вредоносным, и, если да, блокирует или фильтрует этот трафик, предотвращая таким образом потенциальный вред для приложения. Данный компонент защиты также имеет возможность защищаться от DDoS-атак на прикладном уровне
Система защиты и мониторинга	Основным компонентом системы защиты и мониторинга веб‑приложения является SIEM-система, которая собирает и анализирует данные со всех компонентов защиты, перечисленных выше, а также следующих компонентов: · Endpoint Detection and Response (EDR) — это система обнаружения и реагирования на инциденты на конечных устройствах, таких как компьютеры и серверы. EDR использует агентские технологии для сбора данных о безопасности и их анализа в реальном времени, что позволяет быстро обнаруживать потенциальные угрозы и реагировать на них. · Host-based Detection and Response (HDR) — система обнаружения и реагирования на инциденты на уровне хоста, которая использует агентские технологии для мониторинга и анализа активности хостов в реальном времени. HDR может обнаруживать и реагировать на потенциальные угрозы, такие как вредоносные программы, несанкционированный доступ к данным и другие. · Honeypot — специальный прием, применяемый в компьютерной безопасности для обнаружения и предотвращения атак. Honeypot представляет собой виртуальный объект, который имитирует реальный объект или систему и используется для привлечения атак злоумышленников. Для понимания глубины проникновения злоумышленника в инфраструктуру рекомендуется иметь honeypot во всех элементах инфраструктуры (имитировать работу веб-сервера, серверов приложений, серверов БД). · Network detection and response (NDR) — решение для выявления и блокирования атак внутри сети, основанное на поведенческом анализе работы сети. Задача NDR — выявить и блокировать активные действия злоумышленников во время атаки, не давать злоумышленникам развивать атаку, даже если они получили доступ к одному из компонентов веб‑приложения.
Hardware security module (HSM)	Hardware security module (HSM) — это устройство, предназначенное для безопасного хранения и управления криптографическими ключами. HSM обеспечивает высокий уровень защиты ключей от нелегитимного доступа и использования злоумышленниками. Это важный аспект безопасности веб‑приложений, использующих шифрование для защиты данных

Среды разработки и тестирования веб-приложения

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

Среды разработки, тестирования, подготовки и продуктивная среда Рисунок 5. Среды разработки, тестирования, подготовки и продуктивная среда

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

Процесс перехода между средами обычно обеспечивается через использование Secure Software Development Life Cycle (SSDLC) и Continuous Integration and Continuous Deployment (CI/CD). Оба подхода направлены на автоматизацию разработки и развертывания программного обеспечения. Однако, они имеют разные акценты и принципы:

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

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

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

Статическое тестирование безопасности приложений (Static Application Security Testing (SAST)) — тестирование приложения на наличие ошибок и уязвимостей в исходном коде с применением статического анализа. Применяется к исходному коду веб-приложения для выявления уязвимостей.
Динамическое тестирование безопасности приложений (Dynamic Application Security Testing (DAST)) — тестирование, при котором приложение оценивается с использованием определенных методов. Конечный результат тестирования охватывает слабые места безопасности и уязвимости, присутствующие в приложении. Реализуется как программа, которая взаимодействует с веб-приложением через веб-интерфейс с целью выявления потенциальных уязвимостей безопасности и недостатков архитектуры.
Интерактивное тестирование безопасности приложений (Interactive Application Security Testing (IAST)) — тестирование приложений, которое направлено на обнаружение проблем безопасности в программном коде приложений путем взаимодействия с программой в сочетании с наблюдением. Применяется к исходному коду веб‑приложения для выявления уязвимостей.
Фаззинг (Fuzzing) — тестирование программного обеспечения, заключающееся в передаче приложению на вход неправильных, неожиданных или случайных данных.

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

Заключение

Современные веб-приложения являются сложными системами, состоящими из множества компонентов. Для обеспечения безопасности и надежности веб‑приложения необходимо учитывать актуальные угрозы и реализовывать соответствующие меры защиты на всех этапах жизненного цикла веб-приложения. В рамках построения архитектуры веб‑приложения нужно концентрировать свои усилия на защите критически значимых бизнес-процессов, выделяя для них отдельные компоненты веб-приложения и максимально усложняя доступ злоумышленников к данным компонентам. В целях создания требований кибербезопасности можно использовать стандарт OWASP ASVS, причем для разных компонентов, реализующих бизнес-процессы различной значимости, требования будут отличаться.