О том как ИБ влияет на архитектуру.
Идеальная архитектура часто умирает в тот момент, когда сталкивается с первым серьезным требованием информационной безопасности. В этот же момент умирает и сама безопасность, превращаясь в "бумажную" надстройку, которую проектная команда будет саботировать при любой возможности. Итогом этого столкновения становится "безопасный труп" — система, которая теоретически защищена от всего на свете, но практически не способна эволюционировать, масштабироваться и приносить деньги бизнесу.
Проблема не в жесткости регуляторов, а в системном сбое: мы привыкли воспринимать информационную безопасность как внешний фильтр, а не как фундаментальное свойство дизайна. В результате архитектор проектирует "воздушные замки", а ИБ-специалист строит вокруг них бетонные стены. Мы заигрались и забыли, что мы — это лишь сервис для обеспечения работы продукта.
Введение
Парадокс современной разработки в том, что с одной стороны бизнес требует скорости вывода новой функциональности на рынок, в то время как с другой стороны классический подход к обеспечению информационной безопасности, все еще широко применяемый, превращается в непреодолимый барьер, борьба с которым может привести к непредсказуемым последствиям.
Традиционная модель, в которой ИБ выступает в роли «министерства запретов», куда архитектор или команда проекта приносит решение для согласования, кажется, что окончательно изжила себя. При таком подходе безопасность часто становится либо формальным статусом о соответствии требованиям ИБ, либо тяжелым якорем, который тянет проект на дно, а результат часто зависит не от выполнения конкретных требований ИБ, а от того кто кого уговорит, переспорит, утопит в эскалациях или выстоит перед давлением сверху.
Сегодня безопасность - это не внешний забор вокруг системы, а её ДНК. Безопасность это фундаментальное свойство архитектуры, которое зачастую определяет жизнеспособность и успешность проекта или его конец.
Мы находимся в ситуации, когда требования защиты либо ломают логику системы на корню, либо выводят архитектуру проекта на качественно новый уровень.
Очевидно, что в такой ситуации архитектор, не понимающий основ ИБ, проектирует «карточный домик», который рассыплется при первой серьезной нагрузке или атаке. В то же время ИБ-специалист, далекий от архитектурного контекста, от бизнес задачи, строит «бетонный саркофаг» - систему настолько защищенную, что ею невозможно пользоваться, и она, с не нулевой вероятностью, умрёт, так и не принеся пользы бизнесу.
Информационная безопасность оказывает влияние на архитектуру на столько высокое, что современные подходы к организации процесса разработки информационных систем зачастую перестают справляться со своей задачей и скатываются либо в безопасные и неповоротливые решения либо в гибкие, быстро реализуемые и не безопасные.
Безопасность - это свойство архитектуры
Обратимся к литературе.
В книге «Фундаментальный подход к программной архитектуре» Марк Ричардс и Нил Форд выделяют “Безопасность” как одну из ключевых характеристик архитектуры.
Авторы подчеркивают, что безопасность не существует в вакууме: она является неотъемлемым атрибутом качества, который должен учитываться наравне с остальными архитектурными свойствами.
Специфика безопасности как архитектурного свойства заключается в её колоссальном влиянии на все остальные характеристики системы, она может войти в прямой конфликт с другими целями проектирования.
Важность этого свойства, по мнению авторов, состоит в том, что его практически невозможно эффективно внедрить «поверх» уже готовой структуры. Если безопасность не была заложена в фундамент архитектуры как осознанный выбор, любая попытка добавить её позже приведет к деградации системы. Авторы подводят к мысли, что современный архитектор обязан владеть навыками проектирования безопасности, так как она определяет границы допустимого для всех остальных архитектурных решений.
Когда мы рассматриваем безопасность как внутреннее свойство, она перестает быть набором внешних «заплат», становится ее частью и начинает удовлетворять следующим критериям:
Неотделимость: В отличие от старых систем, где безопасность жила «снаружи» вы не можете «выключить» шифрование трафика или проверку прав, не нарушив работоспособность бизнес-логики.
Влияние на дизайн: Все свойства системы, включая “безопасность” - это равноправные нефункциональные требования они должны учитываться еще на этапе проектирования системы.
Проектируемость: Безопасность из контрольной точки в конце процесса разработки превращается в инженерную задачу. Архитектор не «ждет одобрения» от ИБ-специалиста, а изначально выбирает такие паттерны, которые реализуют нужный уровень защиты по умолчанию.
Если безопасность заложена как свойство, система остается устойчивой сама по себе, а не потому, что её окружили «забором» из сторонних инструментов мониторинга.
Рассмотрим пример ограничений:
Нельзя передавать незашифрованные данные между компонентами системы.
В системе должен быть реализован механизм отзыва прав пользователей.
В системе должен быть реализован механизм отзыва токенов аутентификации.
В контексте развертывания: изменения должны распространяться строго из более доверенных сегментов сети в менее доверенные.
Все запросы из менее доверенного сегмента в более доверенный должны проходить строгий форматно-логический контроль (ФЛК).
И так далее…
Как можно заметить, подобные ограничения напрямую диктуют архитектурные решения и неизбежно влияют на другие характеристики системы. Например, внедрение глубокого ФЛК на границах сегментов гарантировано снизит отзывчивость системы, а обязательное шифрование всех внутренних коммуникаций увеличит нагрузку на ресурсы и усложнит диагностику. Игнорирование этого влияния на этапе проектирования приводит к тому, что безопасность начинает восприниматься не как преимущество, а как препятствие, которое нужно преодолеть на поздних этапах реализации проекта.
Еще одним примером подобных ограничений может стать требование использовать mTLS. Зачастую команды внедряют его формально, совершая критическую ошибку — используют один и тот же сертификат для всего кластера или пары систем. Такая реализация фактически эквивалентна отсутствию аутентификации: она не позволяет идентифицировать конкретный сервис и превращает защиту в фикцию. В итоге это лишь усложняет инфраструктуру, не добавляя реальной безопасности. Чтобы mTLS приносил пользу, он должен обеспечивать уникальность каждой сущности, что требует внедрения полноценной PKI-инфраструктуры для управления жизненным циклом ключей. Зачастую на практике это заставляет архитектуру переходить к использованию Service Mesh решений, которые автоматизируют выпуск и ротацию сертификатов. Без таких дополнительных инструментов и жесткого контроля со стороны ИБ внедрение требований безопасности превращается в «карго-культ», который только мешает разработке.
Важно понимать, что информационная безопасность не сводится исключительно к архитектурным свойствам. Это комплексная дисциплина, где операционный контроль, расследование инцидентов и выработка регламентов играют не меньшую роль. Однако, с позиции архитектуры, требования ИБ к системе остаются критически важной частью. Они могут оказывать радикальное влияние на архитектуру: если не учесть их на старте, цена ошибки может привести к полной переработке логики приложения.
Налог на безопасность и трудности налогообложения
Избыточное давление ИБ-требований и отсутствие механизмов для поиска архитектурного компромисса становятся серьезным барьером для развития системы.
Необходимо признать: информационная безопасность неизбежно делает систему сложнее, дороже и медленнее. Это никогда не бывает "бесплатным”. ИБ всегда потребляет реальные ресурсы: шифрование нагружает CPU, mTLS увеличивает сетевые задержки, а аудит-логи перегружают дисковое пространство.
Величина этого "налога на безопасность" должна быть осознанно принята всеми участниками процесса. Однако самый дорогой ресурс, который мы теряем, - это не такты процессора, а время и эффективность команды, сгорающие в конфликте интересов между безопасностью и архитектурой при отсутствии компромиссов.
Основной вызов заключается в конфликте целеполагания: архитекторы сфокусированы на создании ценности, часто игнорируя векторы атак, а специалисты по безопасности — на минимизации рисков, не учитывая бизнес-контекст. Без общего контекста ИБ превращается в «министерство запретов», которое диктует жесткие условия, но не разделяет ответственность за сроки и успех бизнеса. Архитектор же в этой ситуации становится «адвокатом бизнеса», который воспринимает безопасность как досадную помеху и стремится обойти требования, лишь бы выкатить фичу в срок.
В результате возникают две крайности: либо «карточный домик» — уязвимая архитектура, созданная без понимания угроз, либо «бетонный саркофаг» — избыточно защищенная система, которой невозможно пользоваться. В обоих случаях страдает бизнес: система либо рассыпается при первой атаке, либо умирает, так и не принеся пользы из-за своей сложности.
Кейс: Реализация Logical Air Gap при проектировании интеграций
Рассмотрим задачу: вывести данные профиля в UI. Кажется, делов на пару часов: пробросил эндпоинт и готово. Но что, если ИБ запрещает входящий трафик в защищенный сегмент сети?
Первый вариант, без учета требования ИБ, мог бы выглядеть так:
Справедливо заметить, что "в базе" архитектуру могут дополнять WAF, API Gateway или реверс-прокси для контроля трафика. Но если эти средства решают задачи прикладного уровня, то требование, которое мы рассмотрим далее, меняет саму топологию сети и фундаментальный паттерн обмена данными.
У данной схемы есть вполне понятные архитектурные свойства:
Теперь добавим вводную от ИБ: "Никаких входящих соединений во внутреннюю сеть". Обычно о таких правилах известно на старте и это то к чему мы стремимся, но для нашего примера представим, что требование прилетело внезапно.
Переместить сервис профиля наружу нельзя — там чувствительные данные. В итоге простая связка превращается в архитектурный лабиринт: чтобы достать данные, не открывая порты на вход, приходится внедрять посредников и менять само направление запроса. Вот как может выглядет этот «монстр» на схеме:
Архитектурный подход Logical Air Gap (логический «воздушный зазор») — изолирует данные или системы на программном уровне. Физически кабель на месте, но логически мы строим «стену», через которую нельзя просто так пройти запросом.
Как изменились свойства архитектуры при радикальном увеличении безопасности ?
Мы рассмотрели хороший пример, иллюстрирующий как атрибут Безопасность вступает в прямой конфликт с остальными свойствами архитектуры, заставляя архитектора искать сложный компромисс. Жизнеспособным выходом в такой ситуации может стать полный переход к событийной модели, исключающий необходимость в синхронных вызовах между изолированными сегментами.
ИБ как катализатор деградации и паралича
В реальности влияние безопасности на архитектуру часто выглядит куда менее стройно чем в описанном выше примере с Logical Air Gap. Здесь мы входим в зону парадоксов, где требования защиты начинают напрямую конфликтовать с понятием «хорошей архитектуры».
Парадокс «неприступной свалки»
Существует опасное заблуждение, что система, построенная из “нестандартных решений и хаотичных нагромождений”, безопаснее просто потому, что её внутреннее устройство — это хаос, который невозможно просканировать стандартными методами. С одной стороны, это кажется «неберущимся укреплением»: атакующий не понимает, как это работает, потому что это работает вопреки логике.
С другой стороны, такая архитектура — это антипаттерн по определению. Если система не взломана только потому, что она слишком кривая, чтобы в ней разобрался чужой — это не безопасность, это временное везение. Нарушение чистоты кода и стандартов ради «запутывания» следов делает архитектуру хрупкой, а стоимость её поддержки — заоблачной.
Причина архитектурного паралича
В индустриях с жестким регулированием (финтех, госсектор) мы часто наблюдаем «архитектурный паралич». Требования ИБ могут в корне противоречить современным паттернам:
Cloud Native? - Нельзя, данные должны быть в закрытом контуре.
Serverless? - Недопустимо, мы не контролируем среду исполнения.
Быстрые релизы? - Забудьте, каждый коммит должен пройти недельный круг согласований.
Это состояние архитектурного паралича: новые технологии блокируются на входе, а существующая система обрастает слоями защитных механизмов, которые делают её неповоротливой. В таких условиях безопасность фактически становится «смертью инноваций», а архитектору приходится проектировать не оптимальное решение, а максимально «согласуемое».
Имеется и альтернативное мнение и оно не лишено смысла. Оно о том, что внедрение небезопасных технологий — это не инновационный прорыв, а вывод недотестированного MVP на живую архитектуру.
Требования ИБ лишь очерчивают границы зрелости продукта, превращая опасный эксперимент в устойчивое бизнес-решение.
Безусловно, когда избыточные требования ИБ блокируют внедрение уже проверенных рынком и индустрией продуктов, это тормозит бизнес. Однако здесь важно разделять: одно дело — адаптировать готовую мировую практику под внутренние комплаенс-рамки, и совсем другое — выдавать небезопасны, недотестированный продукт за полноценную инновацию.
Трагедия HSM: Кто виноват, когда всё упало?
Классический пример столкновения теории и практики — внедрение аппаратных модулей безопасности (HSM). Требование ИБ хранить ключи неизвлекаемо — абсолютно верное с точки зрения теории. Но когда система падает под нагрузкой, потому что HSM стал «бутылочным горлышком», возникает извечный вопрос: кто виноват?
ИБ-специалисты, которые требовали внедрения, не глядя на профиль нагрузки?
Архитектор, который не предусмотрел RPS и не «отбил» решение на этапе проектирования?
Бизнес, который выкатил акцию, не спросив про пропускную способность крипто-ядра?
В этой точке влияние ИБ на архитектуру достигает пика: ответственность распределяется между всеми участниками процесса, что на практике означает её полное отсутствие. Архитектура превращается в заложника, где ИБ ждет аргументов от проектировщиков, а те, в свою очередь, проектируют «от противного», пытаясь втиснуть требования безопасности в реальные возможности железа и софта.
Путь к синергии
Как мы видим, попытка строить архитектуру исключительно «от безопасности» приводит к созданию неприступной крепости, которая не способна сдвинуться с места и адаптироваться под запросы бизнеса. С другой стороны, игнорирование ИБ превращает систему в карточный домик. Решение кроется не в поиске компромисса между безопасностью и гибкостью, а в глубоком переосмыслении самих архитектурных паттернов.
От права «вето» к Shift Left
Традиционно ИБ воспринимается как контролирующая инстанция с правом вето, которую проектные команды пытаются «проскочить» на финальных этапах. Чтобы архитектура не превращалась в «костыльный монолит» перед самым релизом, необходимо внедрять подход Shift Left.
Смысл прост: требования безопасности должны «впекаться» в систему на этапе дизайна, а не прилетать на этапе приемки, когда переделывать что-то уже слишком поздно и дорого.
Для этого критически важны:
Постоянный обмен знаниями: Архитектор должен понимать логику угроз, а специалист ИБ — ограничения используемых технологий (например, почему HSM может стать бутылочным горлышком).
Общий KPI — «Time to Compliance»: Вместо противостояния - общая метрика: как быстро архитектурное решение проходит аудит ИБ. Это заставляет обе стороны работать над упрощением и автоматизацией проверок.
DevSecOps: Интеграция проверок безопасности непосредственно в CI/CD конвейер. Безопасность должна стать такой же естественной частью процесса, как Unit-тестирование.
Архитектура и ИБ как сервис для продукта
В бесконечных спорах о паттернах и угрозах архитекторы и ИБ специалисты часто забывают о существовании «третьей стороны» - продуктовой команды. Важно честно признать: ни архитектура сама по себе, ни ИБ не приносят компании денег. Деньги приносит фича, которую использует клиент. Мы — обслуживающий персонал и сервисные функции, задача которых — обеспечить выживаемость этой фичи.
Если архитектура и ИБ увлекаются своими играми, проектированием идеальных Air Gap или микросервисного ада, забывая о тех, кому с этим жить, они превращаются в обузу.
Каждое «безопасное» решение архитектора — это потенциальные гири на ногах разработки. Как только правила становятся слишком сложными, разработчик начинает искать способы обхода системы. Так рождается «теневое ИТ», которое в конечном итоге гораздо опаснее любого отсутствия HSM.
Чтобы не стать тормозом инноваций ИБ-специалист и архитектур должны объединиться и создать для команды проекта набор готовых, уже одобренных и протестированных инструментов, где вся техническая и регуляторная сложность скрыта «под капотом» (Golden Path).
Как это работает: Разработчику нужна база данных? Ему не нужно разрабатывать схемы сегментации или согласовывать порты. Он нажимает кнопку и получает ресурс, который уже находится в нужном контуре, с настроенными бэкапами и шифрованием.
Критерий успеха: Команда проекта должна писать бизнес-логику, а не разбираться в хитросплетениях требований к инфраструктуре. Если разработчику нужно пройти 10 кругов ада согласований и настроить 5 прокси-шлюзов, чтобы просто выкатить кнопку — вы как сервис провалились.
Заключение
От контроля к совместному проектированию
Чтобы выйти из клинча «архитектор против ИБ», необходимо изменить саму модель взаимодействия:
Риск-ориентированный подход: Защищать то, что реально важно, считая стоимость защиты vs стоимость риска. Это избавляет от избыточных «костылей» там, где они не нужны.
ИБ как сервис: ИБ-специалист должен перестать быть «инспектором с правом вето» и начать давать архитектору готовые «безопасные кубики» (типовые паттерны, проверенные библиотеки, настроенные инфраструктурные модули).
Автоматизация через DevSecOps: Это хороший способ убрать субъективность «ручных» согласований. Когда правила проверки прозрачны и вшиты в конвейер, вопрос «пропустит или не пропустит ИБ» исчезает сам собой.
Четкие ограничения на старте: Архитектору нужны не абстрактные запреты, а понятные технические рамки еще до начала работы над решением.
Роль архитектора и общая ответственность
Проблема не в отсутствии KPI, а в конфликте векторов: архитектор стремится к скорости (Time-to-Market), а ИБ-специалист — к защищенности (Compliance). Выход здесь один — общая ответственность перед бизнесом.
Архитектор становится медиатором. Он должен уметь «продавать» решения ИБ-специалистам через расчеты нагрузки и предлагать бизнесу безопасные альтернативы.
ИБ-специалист садится в одну лодку с инженерами, отвечая не только за отсутствие взломов, но и за то, чтобы система работала быстро и стабильно, была запущена в конечном счёте.
Интересное по Air-Gaps
Mind The Gap: Can Air-Gaps Keep Your Private Data Secure? https://arxiv.org/abs/2409.04190
«Шаблоны интеграции корпоративных приложений» (Enterprise Integration Patterns) — Грегор Хопп, Бобби Вулф. Разрыв синхронной связи между системами (как по времени, так и по сетевому пространству).
«Designing Data-Intensive Applications» (Проектирование высоконагруженных приложений) — Мартин Клеппман. Описывается изоляция состояний систем. Клеппман объясняет, почему системы, читающие из очередей (Pull-модель), принципиально более защищены от каскадных сбоев и внешних атак.
«Cybersecurity Blue Team Toolkit» — Nadean H. Tanner. Типы технологического разделения сетей (Logical vs. Physical Air Gap).
IBM DataPower Gateway
NIST SP 800-209: Security Guidelines for Storage Infrastructure https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf
"Cybersecurity: The Beginner's Guide" (Dr. Erdal Ozkaya) https://www.jre-training.com/WebSecurity/Cybersecurity.pdf
"Zero Trust Networks" (Evan Gilman, Doug Barth) https://soclibrary.futa.edu.ng/books/Zero trust networks building secure systems in untrusted networks by Barth, Doug Gilman, Evan (z-lib.org).pdf
