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

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

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

Глоссарий CSRC от NIST описывает ее как представления, показывающие, как система «разделена на сегменты безопасности», а NIST SP 800-160 рассматривает ее как инженерную деятельность.

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

Архитектура безопасности против средств безопасности

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

Инвентаризация говорит вам, что вы затаскиваете в работу. Архитектура говорит вам, почему это находится именно там, где находится. Вопросы ниже разделяют эти понятия:

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

CIS Controls v8.1 представляет собой приоритетный список мер защиты, поэтому он работает как контрольный список инвентаризации. NIST CSF 2.0 группирует результаты по категориям: Управление (Govern), Идентификация (Identify), Защита (Protect), Обнаружение (Detect), Реагирование (Respond) и Восстановление (Recover). Ни то, ни другое не говорит, где проходят ваши границы доверия. Это сопоставление — работа архитектора.

То, как архитектурные решения влияют на бюджет, управление и приоритеты программ, относится к стратегии кибербезопасности.

Каковы компоненты архитектуры безопасности?

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

В таблице ниже каждый компонент соотнесен с категорией STRIDE, которую он решает, способом его типичного сбоя и первыми признаками предупреждения:

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

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

Сбои на уровне приложений рассматриваются отдельно в нашем руководстве по безопасности API и руководстве по безопасности веб-приложений, а порядок прорисовки этих границ описан в разделах проектирования далее в этой статье.

Что такое сетевая архитектура безопасности?

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

Она применяет принцип эшелонированной защиты к сети: каждая граница доверия получает собственную точку принудительного применения, поэтому нарушение в одном сегменте не подвергает опасности следующий. NIST SP 800-207 zero trust architecture формализует это с помощью точки принятия решений о политиках и точек принудительного применения политик перед каждым ресурсом, охватывая как трафик «восток-запад», так и периметр.

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

Плюсы и минусы раннего проектирования сегментации по сравнению с ее последующей доработкой:

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

Какими принципами руководствуется архитектура безопасности?

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

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

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

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

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

Для распределенных сред сетка кибербезопасности (cybersecurity mesh) является одним из способов распределения точек принудительного применения по различным средам.

Сравнение фреймворков архитектуры безопасности: SABSA против TOGAF против NIST

Для продуктовой компании численностью 100 человек фреймворком для начала работы является каталог элементов управления, такой как CIS Controls v8.1 или NIST CSF 2.0. Метод проектирования можно добавить позже, если этого потребует сложность системы.

Руководства по архитектуре безопасности SABSA и TOGAF являются методами: они описывают, как создавать и документировать архитектуру. NIST CSF 2.0, CIS Controls v8.1 и ISO/IEC 27001:2022 Приложение A представляют собой каталоги результатов или средств защиты, которые необходимо охватить, и они мало что говорят о том, где должны проходить ваши границы доверия.

Фреймворки в сопоставлении:

Наш рекомендуемый порядок действий для компании такого размера:

Базовый уровень: примите группу внедрения 1 из в качестве бэклога, затем сопоставьте ее с функциями NIST CSF 2.0, чтобы вы могли сообщать о состоянии безопасности на едином языке.
Сертификация: добавьте Приложение А, когда закупки потребуют сертификата ISO 27001. Заложите в бюджет аудит и СУИБ (ISMS), поскольку стандарт сертифицирует систему менеджмента, а не ваше проектирование.
Прослеживаемость: заимствуйте идею SABSA, не принимая сам метод. Каждая запись об архитектурном решении называет риск и требование, лежащие в основе выбранного ею средства защиты.

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

Как спроектировать архитектуру безопасности по шагам

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

Инвентаризуйте активы. Перечислите хранилища данных, учетные записи и сервисы с указанием владельца и классификации данных. Артефакт: реестр активов, ранжированный по степени ущерба в случае нарушения конфиденциальности, целостности или доступности.
Смоделируйте угрозы. Нарисуйте диаграмму потоков данных и примените STRIDE к каждому элементу и потоку. Используйте деревья атак только для двух- или трех активов с несколькими путями для злоумышленника, например для захвата учетной записи администратора. Артефакт: реестр угроз со стабильными идентификаторами.
Расположите границы доверия. Отметьте на диаграмме потоков данных каждую точку изменения идентификационных данных, привилегий или сетевой зоны. Артефакт: аннотированная диаграмма.
Сопоставьте средства контроля с угрозами. Выберите средства контроля из каталога (CIS Controls v8.1, OWASP ASVS) и зафиксируйте остаточный риск. Артефакт: матрица прослеживаемости.
Зафиксируйте решения. Напишите запись об архитектурном решении для каждого выбора, который будущий инженер может отменить, включая отвергнутые варианты и принятый остаточный риск.
Проведите валидацию. Запустите проверки проекта, тесты на проникновение и проверки на расхождение, описанные ниже.

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

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

Диаграммы расходятся с реальностью в течение нескольких недель, поэтому мы рекомендуем автоматизировать сравнение диаграммы с развертыванием:

Храните модель угроз как код, например с помощью OWASP pytm, чтобы границы и потоки можно было сравнивать в пул-реквестах.
Помечайте каждый ресурс инфраструктуры идентификатором границы и запускайте политику как код (Open Policy Agent для плана Terraform или правила Azure Policy и AWS Config), которая блокирует сборку, если для помеченного ресурса отсутствует сопоставленное средство контроля.
Еженедельно запрашивайте актуальный инвентарь с помощью AWS Config или Azure Resource Graph на предмет публичных эндпоинтов, входящих правил групп безопасности и кросс-аккаунт ролей, отсутствующих на диаграмме. Каждое совпадение — это либо недокументированный поток, либо несанкционированное изменение.

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

Практический пример: от интернета до шлюза API и хранилища данных тенанта

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

Предположим, у нас есть шлюз, проверяющий OIDC-токены, бессерверные службы на Kubernetes, общий кластер PostgreSQL со столбцом tenant_id и отдельная административная плоскость. Шлюз является точкой принудительного применения политик. Службы и база данных выполняют повторную проверку, поэтому одна неудачная проверка не приведет к раскрытию данных другого тенанта.

Проход STRIDE для этой границы с указанием средства контроля и оставшейся части:

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

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

Что проверяет аудит архитектуры безопасности?

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

Границы доверия. Каждая граница на диаграмме потоков данных имеет названную точку принудительного применения и владельца. Каждый пересекающий ее поток аутентифицирован и авторизован.
Учетные данные. Перечислите служебные аккаунты, ключи API и долгоживущие токены, указав для каждого владельца, область действия и дату ротации. Сопоставьте политики ключей KMS с тем, кто их вызывает.
Записи об архитектурных решениях (ADR). Каждое средство контроля прослеживается до принятого ADR. Помечайте средства контроля без ADR, ADR, описывающие больше не существующие средства контроля, и исключения без даты окончания срока действия.
Расхождение между диаграммой и развернутым состоянием. Экспортируйте актуальное состояние (состояние Terraform, правила групп безопасности, сетевые политики Kubernetes, публичные эндпоинты) и сравните его с диаграммой. Любой поток, эндпоинт или административный путь, отсутствующий на диаграмме, является находкой.
Политика как код. Средства защиты, такие как SCP, Azure Policy или правила OPA, хранятся в системе контроля версий, имеют тесты и охватывают каждую границу. Проверяйте каждое исключение.
Обнаружение. Каждая точка принудительного применения отправляет логи в SIEM, и кто-то подтвердил срабатывание оповещения.

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

Что такое облачная архитектура безопасности?

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

Провайдер защищает инфраструктуру, аппаратное обеспечение, гипервизор и внутренности управляемых сервисов. Вы владеете управлением доступом и идентификацией (IAM), конфигурацией, данными и кодом рабочих нагрузок. AWS и Azure документируют это разделение, и доля ответственности клиента возрастает по мере перехода от SaaS к IaaS.

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

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

Работа на стороне клиента сопоставляется с конкретными механизмами:

Защитные барьеры (guardrails) должны находиться в системе контроля версий как «политика как код» (policy as code) с использованием модулей Terraform, проверяемых с помощью OPA или Checkov, чтобы изменение в SCP проходило такое же ревью, как и изменение в коде приложения. Конвейеры CI/CD для этой задачи — отдельная тема.

Контрольные списки Well-Architected Framework по направлению безопасности для AWS, Azure и Google Cloud — это чек-листы, по которым можно оценить результаты. Каждый из них охватывает управление доступом, обнаружение угроз, защиту инфраструктуры, защиту данных и реагирование на инциденты, и все три предполагают, что базовый уровень, описанный выше, уже существует.

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

Какой объем архитектуры безопасности необходим стартапу?

Стартапу требуются диаграмма потоков данных с границами доверия, краткая модель угроз и несколько отчетов о принятии архитектурных решений (ADR), и ничего более формального — по крайней мере, до появления регулируемых данных или корпоративных клиентов. Программы в стиле SABSA или TOGAF на посевной стадии чаще всего приводят лишь к созданию документов, которые никто не читает.

Наша рекомендация в зависимости от стадии развития (как экспертное мнение, а не стандарт):

Сопоставление с требованиями комплаенса превращается в бездумную работу по чек-листу, если команды начинают со списка мер контроля. Начните вместо этого с модели угроз. Каждая заявляемая вами ISO/IEC 27001:2022 Annex A мера контроля должна указывать на угрозу, которую она снижает, и на ADR, фиксирующий это решение, чтобы аудитор мог проследить единую цепочку от риска к подтверждению. Проводите повторное сопоставление при изменении диаграммы, а не по календарному годовому графику.

Платежи и медицинские данные повышают планку раньше, чем это делает численность персонала. Финтех- или хелстех-продукт на посевной стадии должен реализовать пункты колонки для раундов Series A-B еще до запуска.

Почему архитектура безопасности имеет значение?

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

Преимущества и сложности бок о бок:

Что касается времени реагирования, то среднее время выявления и сдерживания утечки выросло до 247 дней в исследовании IBM за 2026 год, что на шесть дней дольше, чем годом ранее (IBM Cost of a Data Breach Report 2026). Определение масштаба инцидента зависит от понимания того, какая граница доверия была нарушена, и только актуальная диаграмма потоков данных дает эту информацию.

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

Мы рекомендуем сосредоточить основные усилия по проектированию на регулируемых данных и идентификации — там, где концентрируются радиус поражения и область аудита. Детальная сегментация в остальных областях может подождать до тех пор, пока затраты на внедрение не будут оправданы конкретным риском.

Часто задаваемые вопросы по архитектуре безопасности

Чем занимается архитектор по безопасности?

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

Что такое архитектура корпоративной безопасности?

Архитектура корпоративной безопасности (enterprise security architecture) применяет тот же метод ко всей организации, а не к одной системе: единая служба идентификации, сетевые зоны, управление журналами и ключами, которые наследует каждый продукт, а также стандарты, которым должна соответствовать каждая команда. Именно здесь фреймворки вроде SABSA и TOGAF полностью оправдывают себя, поскольку нескольким продуктам и регуляторам требуется единая отслеживаемая модель.

Что такое фреймворк архитектуры безопасности?

Фреймворк архитектуры безопасности — это либо методология разработки архитектуры (SABSA, руководства по безопасности TOGAF), либо каталог мер контроля и целевых показателей (NIST CSF 2.0, CIS Controls v8.1, ISO/IEC 27001 Приложение A). Большинство продуктовых компаний начинают с каталога и переходят к полноценной методологии только тогда, когда задействовано несколько продуктов или регуляторов.

Что такое 5 C в безопасности?

Единого общепринятого определения нет. Один из распространенных вариантов — change (изменения), compliance (комплаенс), cost (стоимость), continuity (непрерывность) и coverage (охват), и он подходит максимум в качестве памятки для ревью. Для архитектурной работы и аудитов лучше сопоставлять меры контроля с NIST CSF 2.0 или ISO/IEC 27001 Приложение A.

Проведите аудит архитектуры безопасности вместе с Netguru

Аудит архитектуры безопасности позволяет сопоставить ваши границы доверия, модель угроз и отчеты о принятии архитектурных решений с тем, как система работает сегодня, и завершается списком пробелов с решениями, необходимыми для их устранения. Это подходит как для нового SaaS-продукта, так и для платформы, переросшей свою первоначальную архитектуру.

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