“Почти всегда говорят, что защитить можно всё. Но мало кто смотрит на сложность системы как на непреодолимое физическое ограничение, после которого защита превращается в обман — либо для себя, либо для регулятора. Этот предел есть, и мы можем его вычислить.”
Когда-то сложность системы была её главным защитником. Запутанный код, кастомные протоколы, нестандартная архитектура — всё это становилось барьером для атакующего. Сегодня эта же сложность превратилась в главную уязвимость. Она не скрывает дыры, а создаёт их в таких масштабах, что команда просто не успевает их отследить, а система — обработать.
Логично задаться вопросом: если сложность растёт, а ресурсы на защиту конечны, должен существовать некий порог. За ним обеспечить декларируемый уровень защищённости становится математически или физически невозможно. Мы говорим не о недостатке бюджетов или специалистов, а о фундаментальных ограничениях.
От сложности как защиты к сложности как угрозе
Исторически сложность и безопасность были синонимами. Если злоумышленник не мог разобраться в системе, он не мог её атаковать. Этот принцип, известный как «безопасность через неизвестность» (security through obscurity), работал в эпоху изолированных, уникальных систем. Сегодня он не просто устарел, а стал опасным.
Современные IT-системы, это не монолиты, а экосистемы. Они состоят из сотен контейнеров, десятков микросервисов, внешних API, облачных сервисов и цепочек поставок стороннего кода. Каждый новый элемент увеличивает общую сложность системы не линейно, а по экспоненте. Взаимодействия между компонентами создают лавинообразный рост состояний, которые необходимо учитывать при моделировании угроз.
В результате атакующая поверхность (attack surface) превращается из чётко очерченной линии в размытое облако возможных векторов. Традиционный подход «защити периметр» больше не работает, потому что периметра как такового нет. Сложность сама по себе становится источником угроз, создавая слепые зоны, которые невозможно полностью осветить имеющимися инструментами аудита.
Предел Коупленда: когда безопасность превращается в коллапс
Можно ли измерить эту точку перелома? Один из способов — применить концепцию предела Коупленда к безопасности. В оригинале он описывает сложность программного обеспечения: после определённого порога добавление новых разработчиков в проект не ускоряет, а замедляет его из-за накладных расходов на коммуникацию.
В контексте защищённости предел Коупленда выглядит так: после достижения определённого уровня сложности системы (C), добавление ресурсов на её защиту (R) — будь то новые инструменты, специалисты или регламенты — перестаёт повышать реальный уровень безопасности (S). График выходит на плато, а затем может начать снижаться из-за вносимой этими самыми «усилениями» новой сложности.
S = f(C, R), где после C > C_lim, dS/dR стремится к нулю или становится отрицательным.
Практически это означает, что в сверхсложной системе новый модуль SIEM или найм ещё одного пентестера не даёт прироста в обнаружении инцидентов. Сигнал тонет в шуме, ложные срабатывания парализуют SOC, а настройка правил становится самостоятельной непосильной задачей. Система защиты достигает состояния коллапса, когда она потребляет все ресурсы просто для поддержания собственной работы, не выполняя полезной функции.
Что насчитывает счётчик сложности: атрибуты и метрики
Чтобы говорить о пределе, нужно уметь измерять саму сложность. Это не одна метрика, а набор атрибутов:
- Количество компонентов и их версий. Каждая библиотека, микросервис, контейнерный образ.
- Количество уникальных интерфейсов взаимодействия (API, протоколы, очереди).
- Глубина цепочек зависимостей. Прямые и транзитивные зависимости от стороннего кода.
- Динамичность среды. Частота обновлений, деплоев, масштабирования.
- Сложность конфигурации. Количество настроек, политик, правил, их взаимозависимости.
Простого суммирования недостаточно. Два взаимодействующих компонента создают не два, а потенциально четыре состояния связи. Три компонента — уже девять. Это комбинаторный взрыв, который быстро уходит за горизонт возможностей анализа.
Для практической оценки вводят интегральные метрики, например, Cyclomatic Complexity для инфраструктуры — адаптацию известной метрики кода к топологии сети и правилам межсетевого экранирования. Или Attack Surface Score, который пытается количественно оценить доступные извне точки входа с учётом их критичности.
Регуляторика против реальности: когда 152-ФЗ встречает закон Мура для уязвимостей
Требования регуляторов, такие как приказы ФСТЭК, часто исходят из предпосылки контролируемости. Они предполагают, что можно составить полную модель угроз, проанализировать все риски и применить необходимые меры защиты. Для системы средней сложности это рабочая модель.
Проблема в том, что сложность современных сред растёт быстрее, чем способность регуляторики её осмыслить. Пока разрабатывается и утверждается новый приказ, технологии успевают смениться дважды. Требование «обеспечить контроль целостности» для статичного сервера выполнимо. Для динамического Kubernetes-кластера, где поды создаются и уничтожаются каждую минуту, это превращается в задачу с постоянно меняющимися условиями.
Возникает разрыв: формально организация выполняет все пункты — у неё есть политики, журналы событий, средства криптозащиты. Но реальная защищённость сложной, динамичной системы оказывается на порядок ниже, чем предполагает статичная модель регулятора. Это не значит, что требования бессмысленны. Это значит, что для сверхсложных систем необходим иной подход к оценке соответствия, основанный не на чек-листе, а на оценке процессов и resilience (устойчивости к сбоям и атакам).
Практический индикатор: пять признаков, что предел пройден
Как на практике понять, что система перешла порог защищаемой сложности? Есть несколько характерных признаков:
- Время на восстановление после инцидента превышает MTTR (Mean Time To Respond), заложенное в SLA. Команда просто не успевает разобраться во взаимосвязях, чтобы локализовать проблему.
- Результаты автоматизированного сканирования уязвимостей невозможно обработать физически. Каждый день приходит тысячи критических уязвимостей, а на устранение одной требуется от нескольких часов до дней.
- Изменение в одной части системы регулярно приводит к неожиданным отказам в другой, несвязанной. Это признак непредсказуемых каскадных зависимостей.
- Ни один специалист в компании не обладает полной ментальной моделью системы. Знания размыты между командами, документация устаревает быстрее, чем пишется.
- Затраты на эксплуатацию средств защиты (лицензии, обучение, анализ ложных срабатываний) начинают превышать стоимость защищаемых активов или потенциальный ущерб от реализации угроз. Безопасность экономически нецелесообразна.
Если наблюдается три и более признака, скорее всего, система уже находится за пределами разумно защищаемой сложности. Дальнейшие инвестиции в традиционные меры безопасности будут иметь крайне низкую отдачу.
Что делать? Стратегии работы на пределе
Осознание предела — не приговор, а отправная точка для смены стратегии. Вместо попыток «защитить всё любой ценой» нужно двигаться в одном из следующих направлений.
1. Радикальное упрощение архитектуры
Это самый эффективный, но и самый трудный путь. Он требует пересмотра бизнес-процессов и технологического стека. Речь идёт о консолидации, отказе от избыточных и малозначимых систем, стандартизации технологий и переходе к более примитивным, но управляемым решениям. Часто это противоречит трендам на цифровизацию, но с точки зрения безопасности иногда лучше иметь один хорошо защищённый монолит, чем десяток «умных» неуправляемых микросервисов.
2. Сдвиг фокуса с предотвращения на устойчивость (Resilience)
Если сложность нельзя победить, нужно научиться жить с последствиями её прорыва. Вместо того чтобы пытаться заблокировать все атаки, стратегия resilience делает ставку на быструю обнаружаемость (Detection), ограничение ущерба (Containment) и восстановление (Recovery). Ключевые инвестиции идут не в новые файерволы, а в системы оркестрации безопасности (SOAR), неизменяемую инфраструктуру, регулярное и проверенное восстановление из бэкапов. Это признание того, что инцидент неизбежен, но его последствия можно минимизировать.
3. Сегментация и принятие рисков
Нельзя одинаково хорошо защитить всё. Архитектурно система делится на сегменты по уровню критичности и приемлемости риска. Максимальные усилия концентрируются на ядре — нескольких самых важных компонентах с упрощённой архитектурой. Остальные сегменты окружаются базовыми мерами, и для них осознанно принимается более высокий риск. Это требует зрелого риск-менеджмента и честного диалога с бизнесом.
4. Автоматизация не как добавление, а как замена
Часто автоматизацию воспринимают как добавление нового слоя поверх существующих ручных процессов. В контексте сложности это только усугубляет проблему. Правильная автоматизация должна заменять человеческие решения там, где система уже не осознаваема. Например, не человек анализирует тысячи алёртов, а алгоритм, обученный на поведении системы, автономно принимает решение об изоляции скомпрометированного сегмента по жёстким, проверенным правилам. Человек переходит в роль архитектора и контролёра этих правил.
Предел защищаемой сложности — не теоретическая конструкция, а практическая реальность, с которой сталкиваются крупные технологические компании и государственные информационные системы. Его игнорирование ведёт к фиктивной безопасности, где всё есть на бумаге, но отсутствует в реальности. Признание этого предела позволяет перейти от бесконечной и проигрышной гонки вооружений к осмысленной стратегии, где защита, это не тотальный контроль, а управляемый баланс между возможностями, рисками и стоимостью.