«Нужно принять решение по ИБ-инфраструктуре, и классическая тройка «сделать-купить-аутсорсить» не работает. Оказывается, выбор зависит не от задачи, а от того, что именно мы оцениваем: риски, компетенции, расходы или скорость. Нужна не таблица, а 3D-матрица, где у каждой оси — свой критерий оценки.»
Почему классический подход не работает
Традиционная логика выбора сводится к табличке с тремя столбцами: «build» — делать самому, «buy» — купить готовое решение, и «partner» — отдать на аутсорс. Казалось бы, чего проще.
Но если вы пытаетесь оценить, допустим, внедрение системы управления событиями информационной безопасности (SIEM) по такому шаблону, вы сразу упрётесь в противоречия.
- Делать самим, это контроль, глубокое соответствие процессам и огромный порог входа в виде зарплат инженеров.
- Купить коробку, это скорость, вендорская поддержка, но закрытый код, обновления по расписанию вендора и потенциальные проблемы с интеграцией.
- Отдать на аутсорс, это снятие операционных задач с команды, но передача критически важных данных и отчётности третьей стороне.
Таблица окажется неполной и спорной. Один и тот же фактор — например, контроль над кодом — для одного проекта будет решающим, а для другого — второстепенным. Нужна не плоская таблица, а система координат для оценки.
Оси оценки: что на самом деле важно
Чтобы принимать взвешенные решения, нужно чётко определить, по каким осям мы будем оценивать каждый вариант. Эти оси — не про задачи, а про ваши внутренние приоритеты как организации.
Ось X: Уровень контроля и адаптации
На одном полюсе — полный контроль. Вы сами решаете, какой функционал реализовать, как должна работать система, как она интегрируется с вашим уникальным стеком. Это глубокая кастомизация.
На другом — стандартизация. Вы принимаете готовые решения, которые «как у всех». Гибкость ниже, но вы получаете проверенную, стабильную платформу.
- Сделать самому: Максимальный контроль. Система проектируется под ваши процессы с нуля.
- Купить: Умеренный контроль. Вы контролируете конфигурацию, но не ядро продукта. Адаптация ограничена настройками и API.
- Аутсорс: Минимальный контроль. Вы делегируете управление системой. Контроль смещается на уровень SLA и договорных отношений.
Ось Y: Объём требуемых внутренних компетенций
Эта ось измеряет, сколько именно экспертизы должно оставаться внутри организации для успешной реализации и поддержки решения.
Пример с виртуализацией: если вы выбираете популярную платформу, вам нужны администраторы, которые знают её консоль. Если вы строите собственную систему на базе OpenStack, вам потребуются инженеры по Linux, сетевики, специалисты по хранилищам и разработчики, понимающие архитектуру облаков.
Частая ошибка — недооценить эту ось. Решение «сделать самому» может потребовать не 1-2 специалистов, а целую команду с редкими компетенциями, которых на рынке почти нет.
Ось Z: Структура издержек и рисков
Здесь оцениваются не просто деньги, а их природа и связанные с ними риски.
- Капитальные расходы (CAPEX) vs операционные (OPEX): Покупка лицензий и оборудования, это CAPEX. Аутсорс и подписка на SaaS, это OPEX, что часто предпочтительнее с точки зрения финансового планирования.
- Предсказуемость расходов: Собственная разработка может уйти в «кроличью нору» с непредсказуемыми сроками и бюджетами. Подписка на облачный сервис имеет фиксированную ежемесячную стоимость.
- Риск устаревания и привязки: Самописное решение рискует устареть морально, если за ним не стоит команда на постоянной основе. Готовый продукт может привязать вас к вендору, отказ от которого в будущем будет стоить огромных денег (vendor lock-in).
Матрица в действии: SIEM и не только
Давайте применим эту трёхмерную модель к реальным сценариям.
Сценарий 1: Система управления событиями ИБ (SIEM)
Если вам нужен SIEM «как у всех» для базового мониторинга и отчётов для регулятора, ось контроля не критична. Готовое решение будет на оптимальной позиции по скорости и предсказуемости расходов.
Но если ваша инфраструктура, это уникальный набор legacy-систем и самописных приложений, стандартный SIEM не сможет их адекватно парсить. Контроль и адаптация становятся ключевой осью. Тогда либо глубоко кастомизируемое коммерческое решение с открытым SDK, либо собственная разработка на базе Elastic Stack становятся единственными вариантами.
Ось компетенций при этом резко меняется: для кастомизации готового SIEM нужны программисты, знающие конкретный вендорский фреймворк. Для собственного решения — инженеры по Big Data и ML.
Сценарий 2: Средство криптографической защиты информации (СКЗИ)
Здесь первичной становится ось контроля и доверия, но с оговорками. Сделать своё СКЗИ с нуля — путь, сопряжённый с колоссальными затратами на сертификацию по требованиям ФСТЭК и ФСБ России. Это многолетний проект.
Покупка сертифицированного аппаратного или программного СКЗИ у аккредитованного вендора — стандартный путь. Контроль над алгоритмами вы уступаете, но в обмен получаете легитимность и соответствие 152-ФЗ.
Аутсорсинг в чистом виде (например, использование облачного провайдера с ГОСТ-шифрованием) возможен, но требует жёсткого юридического оформления и глубокой проверки поставщика, так как вы передаёте ему критичные данные.
Сценарий 3: Платформа для DevSecOps
Цель — встроить проверки безопасности прямо в пайплайны разработки. Критична скорость и интеграция с существующими инструментами (GitLab CI, Jenkins).
Покупать монолитный «волшебный» продукт для всего — ошибка. Он не встроится в ваши процессы. Делать с нуля всё — слишком медленно.
Правильная стратегия здесь — комбинация. Ядро (система оркестрации проверок, единый интерфейс) можно сделать своим, чтобы сохранить полный контроль над процессом. Но сами «инструменты проверки» — статические и динамические анализаторы, сканеры зависимостей — брать в виде готовых решений (open source или коммерческих) и встраивать их через API. Это даёт баланс по всем осям.
Как проводить оценку: практические шаги
- Сформулируйте цель и ограничения. Не «внедрить DLP», а «контролировать утечки через корпоративную почту и мессенджеры в течение 6 месяцев с бюджетом N». Ограничения по времени и бюджету сразу отсекут заведомо нереалистичные варианты.
- Оцените по каждой оси для всех трёх моделей. Не «лучше-хуже», а по шкале. Например, для оси контроля: самописное решение — 9/10, коробочное — 5/10, аутсорс — 2/10.
- Определите вес каждой оси. Для критически важной системы вес контроля может быть 50%, а для вспомогательного инструмента — 10%. Само взвешивание заставляет команду договориться о приоритетах.
- Рассмотрите гибридные модели. Самый интересный результат даёт не выбор одного варианта, а их комбинация. Например, ядро системы — своё, а отдельные модули (отчётность, интеграция с внешними БД угроз) — аутсорс-сервисы.
Типичные ошибки при выборе
- Игнорирование долгосрочной стоимости владения. Лицензия стоит X рублей в год, а команда из трёх разработчиков для поддержки самописной системы, это не только их зарплаты, но и затраты на их обучение, замещение в случае увольнения и инфраструктуру для разработки.
- Продолжение «программистского» подхода. «Мы сами с PhD» — часто приводит к созданию недокументированного, ни на что не похожего решения, которое становится головной болью для всех, кроме его создателей. После их ухода систему не может поддерживать никто.
- Слепое доверие аутсорсеру. Передача функции без сохранения внутренней экспертизы для контроля результата. В итоге вы не можете оценить качество работы и полностью зависите от подрядчика.
- Ориентация только на первоначальные вложения. Дешёвое коробочное решение может оказаться дорогим из-за необходимости покупать дополнительные модули для базовой функциональности.
Матрица «сделать/купить/аутсорсить» перестаёт быть упрощённой схемой, когда вы начинаете мыслить в трёх измерениях: контроль, компетенции и структура затрат. Ценность такого подхода — не в волшебном ответе, а в том, что процесс оценки заставляет команду обсудить фундаментальные вопросы о том, что для организации действительно важно, до того, как будут потрачены деньги и время.