Мы выстраиваем кибербезопасность как оборону от собственных сотрудников, но при этом с распростёртыми объятиями впускаем в самое сердце инфраструктуры код и устройства, чью внутреннюю кухню мы не знаем. Это парадокс, который делает всю концепцию Zero Trust уязвимой в самой своей основе. https://seberd.ru/5697
Двойной стандарт: пользователь vs. вендор
Zero Trust, это не просто модный термин, а архитектурный принцип, который декларирует: «Никому не доверяй, проверяй всё». В российской регуляторике этот подход находит отражение в требованиях к разграничению доступа, многофакторной аутентификации, сегментации сетей и постоянному мониторингу действий пользователей. Каждое действие сотрудника — вход в систему, запрос к базе данных, попытка скачать файл — рассматривается как потенциальная угроза и требует верификации.
При этом цепочка поставок программного и аппаратного обеспечения часто остаётся слепым пятном. Организация может тратить значительные ресурсы на анализ поведения своего системного администратора, но при этом безоговорочно доверять обновлению операционной системы, прошивке межсетевого экрана или библиотеке, поставляемой внешним разработчиком. Вендор воспринимается не как потенциальный источник риска, а как гарант безопасности, что является фундаментальной ошибкой.
Этот дисбаланс возникает из-за нескольких причин. Во-первых, проверить пользователя технически проще — для этого есть готовые инструменты контроля доступа и SIEM-системы. Во-вторых, существует психологический барьер: сложно представить, что крупный, известный поставщик может стать каналом для атаки, преднамеренно или нет. И в-третьих, регуляторные требования 152-ФЗ и документы ФСТЭК традиционно больше сфокусированы на внутренних процессах и защите от инсайдеров, чем на глубоком аудите стороннего кода.
Уязвимости цепочки поставок: не гипотетическая угроза
Атаки через цепочку поставок (Supply Chain Attacks) перестали быть теорией. Их суть в компрометации легитимного процесса обновления или поставки компонентов. Злоумышленник внедряет вредоносный код не напрямую в целевую организацию, а в продукт её доверенного поставщика. Таким образом, атака получает «законный» пропуск в защищённый периметр.
Классические примеры, это инциденты с компрометацией средств обновления. Представьте, что механизм автоматического обновления вашего средства защиты или служебной утилиты был скомпрометирован. Вместо патча безопасности он доставляет на все компьютеры в сети троян или бэкдор. Поскольку процесс подписан цифровой подписью вендора и инициирован из доверенного источника, традиционные системы защиты могут его пропустить.
В российском контексте риски усугубляются необходимостью адаптации и доработки импортных решений, использованием open-source библиотек с неизвестной историей сборки и зависимостью от ограниченного круга отечественных вендоров, чьи процессы разработки также могут быть не идеальны.
Что скрывается за доверием к вендору?
Доверие к вендору обычно основывается на трёх столпах: репутация, наличие сертификатов соответствия (ФСТЭК, ФСБ) и цифровые подписи обновлений. Однако каждый из этих столпов может оказаться полым.
- Репутация — ненадёжный индикатор. Крупные компании также становятся жертвами взломов, а их сотрудники могут совершать ошибки или действовать злонамеренно.
- Сертификаты — важны, но они подтверждают соответствие продукта определённым требованиям на момент испытаний. Они не гарантируют отсутствие уязвимостей нулевого дня (0-day) или что процесс сборки следующего патча не будет скомпрометирован.
- Цифровые подписи — доказывают лишь то, что файл действительно выпущен вендором. Они не содержат информации о том, что находится внутри этого файла. Если приватный ключ подписи украден или сам вендор выпускает вредоносное обновление, подпись только придаст ему легитимности.
слепое доверие, это делегирование ответственности за безопасность без реальных механизмов контроля.
Как применить принципы Zero Trust к вендорам?
Чтобы устранить этот перекос, логику Zero Trust необходимо распространить и на взаимодействие с поставщиками. Это не означает отказа от их продуктов, а требует внедрения дополнительных контрольных точек.
1. Верификация и контроль обновлений
Нельзя допускать автоматическую установку критических обновлений без предварительного анализа. Необходимо создать внутренний репозиторий обновлений (как это часто делается с патчами для ОС). Перед развёртыванием обновление должно:
- Попасть в «карантинную» зону.
- Быть проверено с помощью средств анализа файлов и сигнатур вирусов, возможно, с привлечением песочниц (sandbox) для запуска и наблюдения за поведением.
- Проходить выборочное тестирование на изолированном стенде, имитирующем рабочую среду.
2. Сегментация и минимальные привилегии для систем вендоров
Серверы обновления, системы удалённого управления или мониторинга от вендоров не должны иметь неограниченный доступ ко всей сети. Их необходимо размещать в выделенном сегменте с жёстко контролируемыми правилами межсетевого экрана, разрешающими только необходимые для работы соединения. Принцип наименьших привилегий должен применяться и к служебным учётным записям, используемым вендорным ПО.
3. Аудит исходного кода и процессов сборки
Для критически важных компонентов, особенно отечественной разработки, где это возможно по договору, стоит рассматривать возможность аудита исходного кода или, как минимум, получения гарантий о применении безопасных практик разработки (SDL). Важно понимать, откуда берутся библиотеки, как организована сборка и кто имеет доступ к финальным бинарным файлам.
4. Мониторинг аномальной активности, исходящей от вендорных систем
Действия, совершаемые служебным ПО вендоров, также должны попадать под подозрение. Неожиданные исходящие соединения с серверов обновления, попытки доступа к нехарактерным ресурсам или выполнение подозрительных процессов должны генерировать оповещения в SIEM-системе.
Практические шаги для интеграции в существующие процессы
Внедрение такого подхода требует интеграции с существующими процессами обеспечения безопасности информации (ПОИБ).
- Анализ рисков при закупке. Включите в техническое задание требования к безопасности цепочки поставок: наличие у вендора политики безопасной разработки, процедур защиты репозиториев кода и ключей подписи, возможности аудита.
- Обновление регламентов. Дополните внутренние регламенты по управлению обновлениями и конфигурациями этапами верификации ПО от вендоров.
- Техническая реализация. Разверните инфраструктуру для карантинного анализа обновлений (песочницы, статические анализаторы) и ужесточите сетевые политики для сегментов, где работают системы вендоров.
- Обучение и осведомлённость. Донесите до сотрудников службы информационной безопасности и администраторов, что вендорное ПО — не «белый шум», а такой же объект для контроля, как и действия пользователей.
От слепого доверия к управляемому риску
Требовать Zero Trust только от пользователей — всё равно что установить бронированную дверь в дом, но оставить открытым окно в котельной, потому что туда заходит только проверенный сантехник. Безопасность сильна настолько, насколько сильно её самое слабое звено.
Расширение принципа «не доверяй, проверяй» на вендоров и цепочки поставок, это следующий логичный этап эволюции защиты. Он превращает безопасность из оборонительного периметра вокруг своих активов в сквозную систему управления рисками, где под подозрением находится не человек, а любое действие или артефакт, независимо от его источника. Только так можно построить устойчивую к современным угрозам инфраструктуру, соответствующую не только букве, но и духу требований регуляторов.