Артемий ПономарёвПостроение кибербезопасной архитектуры веб-приложений
Артемий ПономарёвАртемий ПономарёвВ настоящей статье рассматривается подход к построению кибербезопасной архитектуры веб-приложения. Статья прежде всего будет полезна руководителям ИТ, внедряющих веб-приложения, а также широкому кругу читателей, интересующихся вопросами кибербезопасности веб-приложений. Вначале будут рассмотрены компоненты, необходимые для построения современного высоконагруженного веб-приложения, а затем основные угрозы. Также будут разобраны проактивные аспекты безопасности и требования кибербезопасности на основе проектов OWASP. За рамками статьи остаются организационные вопросы, связанные с защитой DNS-записей и защитой доступа к облачной инфраструктуре, на которой, возможно, будет разворачиваться веб‑приложение. Некоторые основные компоненты мы рассмотрим обзорно только для понимания архитектуры веб-приложения, рекомендации по их защите расположены в других разделах Резбеза.
Кибербезопасная архитектура — это подход к проектированию информационных систем, который обеспечивает их защиту от угроз кибербезопасности.
Исходя из определения, перед нами стоят две основные задачи, которые необходимо решить:
Типовая архитектура веб-приложения включает множество компонентов, таких как серверы приложений, веб-серверы, балансировщики нагрузки, сети доставки контента (CDN), механизмы кэширования и базы данных (см. рис. 1).
Рисунок 1. Архитектура веб-приложения
Рассмотрим компоненты веб-приложения.
Компоненты серверной части:
Компоненты клиентской части:
Приведенная архитектура обеспечивает масштабируемость, отказоустойчивость и эффективную обработку веб-трафика за счет балансировки нагрузки и возможности добавления различных компонентов инфраструктуры веб‑сервера (горизонтальное масштабирование).
Архитектура включает разделение серверов приложений на серверы бэкенда, отвечающие за обработку данных, и серверы фронтенда, отвечающие за отображение пользовательского интерфейса. Серверы приложения могут также быть разделены на множество микросервисов, взаимодействующих между собой (микросервисная архитектура).
Далее мы рассмотрим архитектурную безопасность для балансировщика нагрузки, веб‑сервера и сервера приложений (будем называть их основными компонентами веб‑приложения).
В исследовании 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 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: Определение требований к безопасности» OWASP PC ссылается на OWASP ASVS, который представляет собой каталог доступных требований и параметров проверки. Требования безопасности объединены в категории на основе общих функций безопасности высшего порядка. Каждая категория содержит перечень требований, представляющих собой рекомендации для этой категории в виде списка проверяемых параметров.
OWASP ASVS регулярно обновляется (идет разработка 5-й версии). Текущая стабильная версия — 4.0.3, в дальнейшем анализе мы будем использовать ее. Стандарт верификации требований к безопасности приложений определяет три уровня соответствия, каждый из которых усиливает требования предыдущего:
Рисунок 2. Диаграмма Эйлера-Венна распределения требований между уровнями OWASP ASVS
Для низкого (базового уровня) достаточно исполнения 128 требований, чтобы обеспечить второй уровень защиты необходимо дополнительно исполнить 130 требований (см. рис. 2). Переход на третий уровень добавляет 20 требований, а также ужесточает некоторые требования: добавление аппаратного модуля безопасности (Hardware Security Module (HSM)), меньшее время жизни сессий.
На рис. 3 показаны основные главы OWASP ASVS (всего их 14), внутри которых выделены разделы (секции), содержащие требования (размер зависит от количества требований в секции).
Рисунок 3. Главы ASVS
Больше всего требований в главах «Аутентификация» и «Архитектура, проектирование и моделирование угроз» (см. рис. 3). Если к ним прибавить требования глав «ФЛК, нейтрализация и кодировка» (ФЛК — форматно‑логический контроль) и «Конфигурация», то можно охватить более 50% требований OWASP ASVS.
Разработка кибербезопасной архитектуры веб-приложения включает в себя несколько ключевых факторов. Некоторые аспекты, которые следует учитывать:
Веб-сервер, серверы приложений, сервер базы данных, сервер кэширования, серверы для хранения файлов статики (CDN), API, нуждаются в харденинге. Подробнее о процессе харденинга написано в статье
Построение кибербезопасной архитектуры веб-приложения может быть выполнено с использованием подходов, изложенных ранее, для защиты инфраструктуры организации. Основной задачей является усложнение цепочки атаки злоумышленника таким образом, чтобы злоумышленник не смог реализовать недопустимые события при кибератаке. В рамках решения этой задачи должны быть выявлены , реализуемые веб-приложением. На них следует сосредоточить защиту.
На рис. 4 показан пример кибербезопасной архитектуры веб-приложения со средствами защиты. Основные средства защиты, которые должны быть развернуты в рамках обеспечения кибербезопасности, показаны в табл. 3.
Рисунок 4. Пример кибербезопасной архитектуры веб-приложения
Также следует уделить серьезное внимание сегментации сети и ограничению взаимодействия компонентов веб-приложения. Взаимодействие должно происходить только по разрешенным протоколам и портам. Так, на рис. 4 показаны группы безопасности сети, в которых должны находиться компоненты веб-приложения. На границах групп безопасности сети необходимо реализовать контроли безопасности, обеспечивающие защиту этих групп, на случай атаки злоумышленника, использующего скомпрометированные ресурсы из других групп безопасности. Следует отметить, что на рис. 4 показан только один балансировщик нагрузки, но на самом деле перед всеми компонентами (серверами) могут быть установлены балансировщики нагрузки для обеспечения высокой доступности веб-приложения. Для серверов системы управления базами данных и серверов кэширования могут применяться различные технологии повышения доступности, например кластеризация. На рис. 4 они не изображены, чтобы не нагружать схему.
Таблица 3. Основные компоненты защиты веб-приложения
В целях создания (разработки) и тестирования веб-приложения архитектура должна предусматривать среды разработки, тестирования, подготовки и продуктивную среду. Таким образом, продуктивная среда должна быть продублирована в меньшем масштабе (например, вместо ста серверов приложения для тестирования используются десять). В зрелых решениях выделяют следующие среды, показанные на рис. 5.
Рисунок 5. Среды разработки, тестирования, подготовки и продуктивная среда
Данные, обрабатываемые в веб-приложении (например, данные клиентов банка), должны содержаться только в продуктивной среде (см. рис. 5). Среды должны быть разделены между собой, чтобы исключить доступ разработчиков и тестировщиков в продуктивную среду и их влияние друг на друга.
Процесс перехода между средами обычно обеспечивается через использование Secure Software Development Life Cycle (SSDLC) и Continuous Integration and Continuous Deployment (CI/CD). Оба подхода направлены на автоматизацию разработки и развертывания программного обеспечения. Однако, они имеют разные акценты и принципы:
Оба подхода можно использовать совместно, чтобы обеспечить максимальную безопасность и эффективность разработки и развертывания программного обеспечения. Например, автоматизированные процессы CI/CD могут быть использованы для автоматического выполнения тестов безопасности на каждом этапе разработки, а SSDLC — для учета требований безопасности в процессе разработки программного обеспечения, а также для обеспечения необходимых проверок безопасности.
Объем тестирования приложений может существенно отличаться в зависимости от автоматизируемых бизнес-процессов. Если бизнес-процесс является критически значимым, то объем тестирования должен быть максимальным и может включать следующие методы тестирования:
Целевая архитектура приложения должна предусматривать использование инструментов для тестирования безопасности.
Современные веб-приложения являются сложными системами, состоящими из множества компонентов. Для обеспечения безопасности и надежности веб‑приложения необходимо учитывать актуальные угрозы и реализовывать соответствующие меры защиты на всех этапах жизненного цикла веб-приложения. В рамках построения архитектуры веб‑приложения нужно концентрировать свои усилия на защите критически значимых бизнес-процессов, выделяя для них отдельные компоненты веб-приложения и максимально усложняя доступ злоумышленников к данным компонентам. В целях создания требований кибербезопасности можно использовать стандарт OWASP ASVS, причем для разных компонентов, реализующих бизнес-процессы различной значимости, требования будут отличаться.
| A07:2021-Ошибки идентификации и аутентификации | Категория включает ошибки, связанные со сбоями идентификации и аутентификации |
| A08:2021-Нарушения целостности программного обеспечения и данных | Категория, связанная с обновлением программного обеспечения критически важных данных и конвейеров CI/CD без проверки целостности |
| A09:2021-Недостатки журналирования и мониторинга безопасности | Категория, связанная с недостатками или отсутствием журналирования событий безопасности или мониторинга безопасности. Без регистрации и мониторинга работы веб‑приложения невозможно обнаружить события и инциденты информационной безопасности, а значит, предпринять ответные действия |
| A10:2021-Подделка запросов на стороне сервера | Ошибки Server-Side Request Forgery (SSRF) возникают всякий раз, когда веб-приложение извлекает удаленный ресурс без проверки URL-адреса, предоставленного пользователем. Это позволяет злоумышленнику отправлять запросы от имени скомпрометированного сервера, что, в свою очередь, может заставить приложение отправить созданный запрос, даже если оно защищено межсетевым экраном, VPN или списком управления доступом к сети |
| C5: Обязательная проверка всех входных данных | Проверка входных данных является частью методики программирования, обеспечивающей попадание в компоненты программы только правильно отформатированных данных |
| C6: Внедрение цифровой идентификации | Цифровая идентификация — это уникальное представление пользователя (или любого другого объекта) при онлайн‑транзакциях. Она также должна быть обеспечена аутентификацией и управлением сессиями. Аутентификация — процесс подтверждения того, что человек или сущность является тем, кем представляется. Управление сессиями — процесс, с помощью которого сервер контролирует состояние аутентификации пользователя, чтобы он мог продолжать пользоваться системой без повторной аутентификации |
| C7: Обязательный контроль доступа | Контроль доступа (или авторизация) заключается в разрешении или запрещении специфических запросов, поступающих от пользователей, программ или процессов, а также предполагает выдачу и отзыв подобных привилегий |
| C8: Повсеместная защита данных | Конфиденциальные данные, такие как пароли, номера кредитных карт, медицинские записи, персональные данные и коммерческие тайны требуют дополнительной защиты. Первое правило управления конфиденциальными данными — избегать хранения конфиденциальных данных, когда это возможно. Если сохранять конфиденциальные данные необходимо, то убедитесь в наличии у них криптографической защиты от несанкционированного доступа и изменений |
| C9: Внедрение журналирования и мониторинга событий безопасности | Большинство разработчиков уже используют журналирование при отладке и диагностике. Однако важно также регистрировать события безопасности и во время работы приложения. Мониторинг — это анализ приложения и журналов безопасности с помощью различных средств автоматизации. Такие же инструменты и шаблоны могут применяться к выполняемым операциям, отладке и обеспечению безопасности |
| C10: Обязательная обработка всех ошибок и исключений | Обработка исключений позволяет приложению реагировать на различные ошибки (например, сбой сети или подключения к базе данных) различными способами. Корректная обработка исключений и ошибок необходима для обеспечения надежности и безопасности вашего кода |
| Система защиты и мониторинга | Основным компонентом системы защиты и мониторинга веб‑приложения является 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 обеспечивает высокий уровень защиты ключей от нелегитимного доступа и использования злоумышленниками. Это важный аспект безопасности веб‑приложений, использующих шифрование для защиты данных |