Как выбраться из ловушки «COTS»

За годы работы в корпоративных средах кибербезопасности накопилось ошеломляющее количество коммерческих инструментов. Отраслевые исследования сходятся в единой картине распространения инструментов, которое ведет к усложнению, росту затрат и рисков. Мировая индустрия кибербезопасности оценивается примерно в 243 миллиарда долларов в 2024 году, и прогнозируется, что к 2026 году этот показатель превысит 520 миллиардов долларов ежегодно. Коммерческое готовое программное обеспечение (COTS) обещает скорость и зрелость, позволяя избежать многолетней разработки на заказ. Поначалу все идет идеально, и решение кажется оправданным.

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

Стоимость зависимости от COTS становится наиболее очевидной, когда организации пытаются сменить платформы. Статистика неудач миграции подчеркивает глубину архитектурной запутанности, которую создают платформы COTS. Это происходит потому, что система вокруг них спроектирована таким образом, что программное обеспечение трудно бросить. Зависимость от COTS в сфере кибербезопасности носит структурный характер, является дорогостоящей и усиливается. Организации, которые не принимают архитектурных контрмер, сталкиваются с растущими расходами, снижением стратегической гибкости и повышением уязвимости как перед киберугрозами, так и перед сбоями со стороны поставщиков.

Что такое COTS и почему оно нравится людям?

COTS (сокращение от commercial off-the-shelf software — коммерческое готовое программное обеспечение) относится к готовым программам, которые обычно продаются онлайн или в розничных магазинах. Они поставляются с предварительно настроенными функциями прямо из коробки, поэтому требуют минимальных изменений или не требуют их вовсе.

Примеры включают:

• IAM
• GRC
• IGA
• Платформа обнаружения угроз

Большинству предприятий они нравятся, потому что:

• Они уже «работают».
• Они развертываются легко и быстро.
• Снижение долгосрочных расходов, как обещают поставщики.

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

Новая динамика: ИИ и следующая волна привязки

Искусственный интеллект представляет собой как следующий рубеж возможностей в области кибербезопасности, так и новый вектор зависимости от поставщиков. Исследование McKinsey за 2024/2025 годы определяет ИИ как фактор, расширяющий общий адресуемый рынок кибербезопасности до 2 триллионов долларов. Платформы безопасности на базе ИИ, от поведенческой аналитики до автоматизированного обнаружения угроз и SIEM на базе ИИ, создают новые формы зависимости от COTS. Модели ИИ обучаются на проприетарных наборах данных, используют специализированные каналы разведки угроз поставщиков (62% корпоративных развертываний интегрируют разведку угроз, потребляя 2,4 миллиарда индикаторов компрометации ежедневно) и требуют специализированной вычислительной инфраструктуры. Инвестиции в модели обнаружения на основе ИИ создают новую категорию затрат на переключение: переобучение моделей, восстановление поведенческих базовых линий и потерю институциональной информации об угрозах. Организации, использующие нативные для ИИ платформы безопасности, сталкиваются с риском того, что эффективность их обнаружения угроз будет привязана к данным обучения модели и алгоритмическому подходу одного поставщика.

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

Привязка к поставщику редко происходит в одночасье. Вместо этого она возникает постепенно по мере накопления технических и бизнес-решений. Как это происходит?

Встроенная бизнес-логика

После некоторого времени использования программного обеспечения предприятие привыкает к нему, и важные правила, такие как логика ценообразования и проверки, оказываются «закопанными» внутри этого ПО. Со временем предприятие постепенно теряет прямой контроль над собственной логикой.

Рабочие процессы, сформированные поставщиком

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

Нативная для платформы кастомизация

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

Запутанность данных

Проще говоря, ваши данные оказываются запертыми в форматах и структурах, которые понимает только поставщик. Чтение этих данных становится сложным, медленным и дорогостоящим. Это затрудняет переход, поскольку данные держат предприятие в заложниках.

Архитектурные паттерны, разрушающие ловушку COTS

Выход из ловушки COTS не означает отказ от коммерческого программного обеспечения. Это означает проектирование систем таким образом, чтобы программное обеспечение никогда не становилось точкой контроля.

Решение 1: Слой защиты от искажений (Anti-Corruption Layer)

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

Решение 2: Паттерн абстракции процессов

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

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

Решение 3: Интеграция на основе событий

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

Решение 4: Паттерн «Удушающая фига» (Strangler Fig Pattern)

Замену систем всегда следует проводить медленно, а не одномоментно.

• Заменяйте небольшие части шаг за шагом.
• Позвольте старой и новой системам работать параллельно.
• Постепенно перемещайте пользователей и данные.

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

Решение 5: Стратегия суверенитета данных

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

Проектирование с учетом заменяемости: Архитектурные принципы

Именно здесь большинство предприятий допускают ошибку. Они рассматривают программное обеспечение COTS как окончательное решение с самого начала. После выбора, покупки и установки все остальное должно подстраиваться под него. Большинство процессов искажаются, модели данных растягиваются, а архитектура переопределяется, чтобы соответствовать требованиям программного обеспечения. Результат? Его замена становится немыслимой.

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

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

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

Цель здесь не в том, чтобы постоянно менять платформы, а в том, чтобы обеспечить возможность сделать это, когда это необходимо. Вот что значит проектировать корпоративные системы, которые вы можете покинуть.

Заключение: Гибкость имеет значение в архитектурном проектировании

Зависимость индустрии кибербезопасности от COTS — это не провал закупок. Это структурная характеристика рынка, растущего на 10–15% ежегодно, где более 3000 поставщиков борются за корпоративные бюджеты. $212 миллиардов, потраченных на кибербезопасность в 2025 году, подавляющим большинством проходят через каналы COTS, создавая зависимости, которые дорого устанавливать, затратно поддерживать и чрезвычайно трудно разорвать.

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

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

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

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

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

Эта статья опубликована в рамках сети экспертных авторов Foundry.
Хотите присоединиться?