Концентрация на одном ИТ-вендоре: скрытая единая точка отказа
Почему зависимость от одного поставщика инфраструктуры или ПО - это операционный риск, а не просто переговорная позиция.
После инцидента с CrowdStrike в июле 2024 года у многих директоров возник один и тот же вопрос: "А у нас нет таких же концентраций?" Ответ в большинстве случаев - есть. Просто они не так видны, потому что ни разу не проявлялись.
Концентрация вендора - это не только про кибербезопасность. Это структурный вопрос о том, где в вашей инфраструктуре находятся единые точки отказа, которые контролирует сторонняя организация.
Как выглядит вендорная концентрация
Самый очевидный вариант - когда один продукт установлен на всех серверах, всех рабочих местах, во всех регионах, и обновляется централизованно. Любая проблема с этим продуктом - это проблема везде одновременно.
Менее очевидный вариант - когда несколько разных продуктов принадлежат одному вендору или используют одну облачную платформу для доставки обновлений. Внешне кажется, что диверсификации достигнута, но единая точка входа осталась.
Ещё один вариант - функциональная зависимость: когда один поставщик обслуживает критически важный процесс без альтернативы. Не обязательно ПО - это может быть единственный интегратор, единственный провайдер подключения, единственный поставщик лицензий на ключевую систему.
Во всех этих случаях проблема не в самом вендоре. Проблема в том, что отсутствие его работоспособности останавливает вашу операционную деятельность.
Почему эта концентрация возникает
Консолидация у одного вендора часто выглядит разумно по отдельности: скидки за объём, единый контракт, упрощённая поддержка, интеграция продуктов между собой. Каждое из этих решений принималось на уровне департамента с локальной логикой.
Системная картина возникает только тогда, когда кто-то смотрит на всю карту зависимостей сразу. Обычно это происходит после инцидента - не до него.
Ещё одна причина: стоимость диверсификации видна сразу - лишняя лицензия, лишняя интеграция, лишнее обслуживание. Выгода от диверсификации - страховая. Она проявляется только когда что-то идёт не так, и вероятность этого кажется низкой.
На что смотреть при аудите зависимостей
Когда я помогаю компаниям разобраться с вендорными рисками, я смотрю на несколько вещей:
Охват: сколько машин, систем или пользователей зависит от продукта без альтернативы?
Глубина доступа: какой уровень привилегий имеет продукт или поставщик? Доступ к ядру - это другой класс риска по сравнению с SaaS-приложением.
Скорость распространения изменений: обновляется ли продукт автоматически и немедленно? Или есть буфер?
Скорость восстановления: если продукт перестанет работать, сколько времени займёт возврат к нормальному состоянию? Это тест не для одной машины, а для всего парка.
Альтернатива: есть ли временная замена на случай отказа - пусть неполноценная?
Что делать с обнаруженными концентрациями
Не всякая концентрация требует немедленного исправления. Некоторые риски принимаются осознанно, потому что альтернатива дороже или технически невозможна в обозримой перспективе.
Но принятие риска должно быть явным. Это означает: зафиксировать, что зависимость существует, оценить её вес, определить сценарий отказа, договориться кто принимает решение при развитии этого сценария.
Риск, который не зафиксирован, не управляется. Он просто ждёт своего часа.
Три вопроса для начала:
- Есть ли в вашей инфраструктуре компоненты, обновляющиеся автоматически на весь парк без тестового периода?
- Если завтра один из ключевых вендоров прекратит работу на сутки - какие ваши процессы остановятся?
- Кто в компании отвечает за карту вендорных зависимостей - или такой карты нет?