Почему инструменты безопасности становятся самыми опасными точками в инфраструктуре нулевого доверия?
Я всё чаще ловлю себя на мысли о системном противоречии. Инструменты, которые должны быть основой нулевого доверия, на деле становятся его самым слабым звеном потому что их архитектура требует именно там самых широких и вечных исключений, превращая эти продукты в приоритетные цели атак и главные уязвимости всей системы.
Архитектура нулевого доверия (Zero Trust) и принципа минимальных привелегий решает вполне реальную проблему. Когда угрозы внутри сети могут быть не менее опасными, чем внешние, идея не доверять никому по умолчанию выглядит не паранойей, а нормальной реакцией на реальность. Каждое соединение проверяется отдельно, доступ выдаётся ровно на то действие и на то время, которое нужно, и контекст учитывается каждый раз.
А вот большинство корпоративных продуктов делались для совсем другой картины мира. Агент однажды получает учётные данные и потом живёт с ними годами. Соединение с управляющим сервером держится постоянно. Права на уровне системы выдаются один раз и дальше почти не пересматриваются.
Из-за этого на практике всё часто ломается. Компания начинает внедрять ZT, ставит продукт от вендора, и он внезапно перестаёт работать как ожидалось. Вендор просит добавить исключения. Их добавляют, и именно в этих местах появляются дыры. Я всё чаще ловлю себя на мысли, что проблема здесь не в самой модели нулевого доверия, а в том, что многие решения до сих пор исходят из постоянного доверия, просто прикрываясь правильными словами.
Почему корпоративный софт несовместим с нулевым доверием
Средства защиты конечных точек (EDR), системы мониторинга, платформы управления конфигурациями разрабатывались когда базовой моделью была защита периметра. Внутри корпоративной сети считалось относительно безопасным.
При такой парадигме логично было дать агенту постоянный доступ после однократной авторизации. Незачем проверять каждое его действие если он в доверенной зоне. Логично было держать управляющее соединение постоянно открытым для быстрой реакции. Логично было дать широкие права для сбора данных со всех узлов.
Нулевое доверие отменяет понятие доверенной зоны. Каждое соединение потенциально враждебно. Каждый запрос проходит авторизацию с учётом текущего контекста. Права выдаются на минимально необходимый срок.
Переделать архитектуру продукта под эту модель означает фундаментальную перестройку. Как агент запрашивает доступ, как долго его сохраняет, как обосновывает каждое действие. Месяцы или годы разработки.
Вендоры не инвестируют в эту работу. Продукты продаются в текущем виде. Клиенты покупают, делают исключения, работают дальше.
Как инструменты безопасности становятся главной угрозой в архитектуре нулевого доверия
Продукты для защиты получают больше прав чем любой другой софт. Им нужна полная видимость для обнаружения угроз. Что вроде и логично.
Агент для защиты конечных точек работает с правами системы. Читает произвольные файлы, перехватывает системные вызовы, анализирует память процессов, контролирует сетевые соединения. Ограничь его права - потеряешь возможность обнаруживать целые классы атак. Формально это выглядит логично.
Платформа мониторинга опрашивает тысячи узлов каждые несколько секунд. Если для каждого запроса требовать новую авторизацию нагрузка на систему управления доступом вырастет на порядки.
Система сбора логов получает данные со всех критичных компонентов. Межсетевые экраны, серверы аутентификации, приложения. Скомпрометируй коллектор - получишь карту инфраструктуры и действий пользователей.
Все эти инструменты созданы для повышения безопасности. Именно поэтому они становятся приоритетными целями. Широкий доступ плюс исключения из общих политик контроля.
Компрометация платформы мониторинга или системы управления даёт легитимный канал для распространения вредоносного кода на все узлы. Обновление приходит с доверенного сервера, подписано правильным сертификатом, устанавливается автоматически.
Один скомпрометированный компонент с широкими правами открывает доступ ко всей инфраструктуре. Не теоретически, а практически именно так работают атаки через цепочку поставок последние несколько лет.
Почему компании не могут проверять действия вендорского софта
Компания хочет контролировать что агенты отправляют на сервера вендора. Включает инспекцию зашифрованного трафика. Прокси разворачивает TLS, проверяет содержимое, заворачивает обратно.
Агент использует привязку к сертификату. Он знает какой именно сертификат должен предъявить сервер вендора. Приходит сертификат от прокси - агент разрывает соединение, падает с ошибкой.
Когда включается инспекция трафика, на следующее утро начинают поступать сообщения, что агент защиты стал недоступен. В процессе анализа выясняется, что мониторинг не видит целую часть серверов. Вендор объясняет, что это защитная мера, направленная на предотвращение перехвата данных. Привязка агента к сертификату не позволяет сторонним организациям, в том числе прокси, расшифровывать трафик.
Для клиента "третья сторона" это его собственный прокси в его собственной инфраструктуре. Он хочет видеть какие данные покидают его сеть. Вендор говорит смотрите политику конфиденциальности, там описаны категории. Категории сформулированы общими фразами. Обход привязки технически возможен через модификацию агента. Нарушает лицензионное соглашение, переводит конфигурацию в статус неподдерживаемой. При инциденте вендор откажется помогать.
Крупные заказчики могут договориться о получении специальных сборок, где привязки к сертификатам нет. Средним и мелким компаниям такая возможность недоступна.
Модель нулевого доверия требует полной видимости трафика. Вендор блокирует эту видимость ссылаясь на защиту данных клиента. Клиент выбирает между контролем и использованием продукта.
Как автоматические обновления превращаются в канал для атак
Системы безопасности (задачи, политики обновления) обновляются автоматически без участия администраторов. Считается правильной практикой - задержка установки исправлений создаёт окно для эксплуатации уязвимостей.
Агент проверяет наличие новой версии, скачивает с серверов вендора, проверяет цифровую подпись, устанавливает. Подпись валидная - обновление легитимное.
Что если в обновлении вредоносный код? Проверка подписи пройдёт. Пакет собран и подписан инфраструктурой вендора. С точки зрения криптографии всё правильно.
Атака через компрометацию цепочки сборки или инфраструктуры обновлений распространяет вредоносный код на всех клиентов одновременно. Код приходит с доверенных серверов, подписан правильными сертификатами, устанавливается автоматически.
Задержка установки могла бы дать время на обнаружение. Тестирование в изолированной среде не покажет бэкдор который активируется через несколько дней или только при определённых условиях.
Задержка увеличивает риск эксплуатации публично известных уязвимостей. Вендор выпустил исправление, информация стала доступна, появились эксплойты. Каждый день задержки это день уязвимости.
Нулевое доверие не решает эту проблему. Не важно насколько хорошо сегментирована сеть если вредоносный код уже работает внутри с легитимными правами.
Почему сертификация вендора не гарантирует совместимость с нулевым доверием
Вендоры проходят аудиты, получают сертификаты соответствия, показывают их как подтверждение надёжности. Эти проверки оценивают процессы у вендора, не совместимость продукта с моделью безопасности клиента.
Аудитор проверяет есть ли процесс управления уязвимостями, документирован ли, выполняется ли. Процесс есть - требование выполнено. Аудитор не проверяет потребует ли продукт исключений в архитектуре нулевого доверия клиента.
Компании заполняют опросники безопасности при выборе вендора. Сотни вопросов про шифрование, резервное копирование, физическую безопасность. Вендор отвечает, прикладывает сертификаты, проходит проверку.
Сертификат говорит что у вендора настроен контроль доступа к собственной инфраструктуре, код проходит проверки, существует процесс реагирования на инциденты. Не отвечает на вопрос можно ли использовать продукт не разрушая архитектуру которую выстраивает клиент.
Смотришь такие опросники - триста вопросов про то как вендор хранит бэкапы и ни одного про то сможет ли его продукт работать когда авторизация обновляется каждые пятнадцать минут.
Нигде нет вопросов потребует ли продукт отключения инспекции трафика. Сможет ли работать с временными разрешениями доступа которые обновляются каждые несколько минут. Опросники оценивают безопасность вендора, не влияние продукта на модель клиента.
Что означает поддержка нулевого доверия в маркетинге вендоров
Вендоры добавляют в рекламу фразы про нулевое доверие. "Designed for zero trust", "zero trust ready", "compatible with zero trust architecture".
Смотришь документацию - поддержка означает что продукт может работать через специализированный прокси который добавляет уровень контроля. Сам продукт не изменился. Агент требует постоянных прав на уровне системы, держит открытое соединение, нуждается в доступе ко всем узлам.
Или совместимость означает интеграцию с корпоративной системой управления идентификацией. Агент авторизуется через неё вместо отдельных учётных данных. Не про ограничение прав, не про контроль действий.
Или поддержка принципа минимальных привилегий. В документации режим работы с ограниченными правами где часть функций отключена. Читаешь какие - те самые ради которых продукт покупался. В урезанном режиме бесполезен. Маркетинг научился использовать модные термины. Продукты остались архитектурно теми же.
Почему вендоры не адаптируют продукты под нулевое доверие
Вендоры не переделывают архитектуру потому что могут не делать этого. Продукты продаются, клиенты покупают, делают исключения, работают.
Адаптация под нулевое доверие это инвестиции которые не добавляют новых функций. Клиент не увидит новых возможностей обнаружения или улучшения производительности. Получит возможность использовать продукт без нарушения принципов своей архитектуры.
В презентациях показывают функции обнаружения атак, скорость реакции, удобство управления. Совместимость с нулевым доверием не впечатляет на слайдах.
Пока клиенты соглашаются на исключения и продлевают контракты у вендора нет стимула менять приоритеты. Отдельные клиенты требуют изменений, вендор вносит в план, работа откладывается годами.
Каждая компания считает что проблема только у неё. Сделали исключения, неудобно признавать, молчат. Другие видят то же, думают так же, тоже молчат.
Вендор не получает сигнала что архитектура устарела. Получает индивидуальные запросы которые можно обещать реализовать потом.
Как компаниям работать с несовместимостью вендорского софта и нулевого доверия
Ждать изменений можно долго. Работать нужно сейчас. Документировать каждое исключение из архитектуры. Что именно разрешено, для какого продукта, почему необходимо, какой риск создаёт, кто принял решение. Видимость реального состояния а не идеализированной схемы.
Пересматривать исключения регулярно. Нельзя ли сузить разрешения, не появились ли альтернативы, не изменились ли требования вендора в новых версиях.
Усилить мониторинг вендорского софта который работает с широкими правами. Раз дано больше доверия нужна повышенная видимость действий. Аномальное поведение должно вызывать проверку немедленно.
Фиксировать в контрактах требование планов по поддержке нулевого доверия. При продлении проверять выполнение обещаний. Обещали и не сделали - аргумент в переговорах о цене или причина для рассмотрения альтернатив.
Делать совместимость обязательным критерием при выборе новых продуктов. Два решения с похожими функциями, одно требует меньше исключений - выбирать его даже если дороже. Долгосрочная стоимость продукта который ломает архитектуру выше чем кажется при закупке.
Объединяться с другими клиентами того же вендора для совместного давления. Один клиент легко игнорировать. Десять крупных которые требуют одновременно - сложнее.
Публично обсуждать проблему. Писать обзоры где несовместимость указана как серьёзный недостаток. Делиться опытом отказа от продления из-за этого. Создавать рыночный сигнал который вендоры не смогут не заметить.
Рассматривать решения с открытым кодом там где могут заменить коммерческие. Требуют больше усилий на администрирование, нет готовой поддержки. Дают контроль над тем как софт работает и возможность адаптировать под свою модель.
Использовать изоляцию для вендорского софта который невозможно заменить. Контейнеризация, виртуальные машины с ограниченным доступом, прокси для перехвата трафика. Не полноценное решение но ограничивает последствия возможной компрометации.
Противоречие нельзя игнорировать дальше
Инструменты которые должны обеспечивать безопасность работают в режиме противоречащем базовым принципам современных моделей защиты. Постоянные права на уровне системы, открытые соединения без повторных проверок, доступ ко всей инфраструктуре.
Что делает их приоритетными целями. Один скомпрометированный компонент даёт доступ ко всему. Механизм автоматических обновлений превращается в канал массового распространения если инфраструктура вендора взломана.
Проблема не решится пока рынок не заставит вендоров меняться. Рынок не заставит пока компании молча делают исключения и платят. Круг замкнулся.
Разомкнуть его можно только коллективным действием. Публичным обсуждением, отказами от продления с объяснением причин, требованиями совместимости как обязательного условия закупки.
Архитектура продуктов устарела. Требования исключений в модели безопасности клиента не нормальная практика а системная проблема. Чем дольше все делают вид что её нет тем дороже обойдётся исправление когда станет невозможно игнорировать.
Инструменты защиты не должны быть самыми опасными точками в инфраструктуре. Именно это происходит сейчас и именно это нужно менять.
#кибербезопасность #инфобез #нулевоедоверие #zerotrust #информационнаябезопасность #киберугрозы #защитаданных #кибераудит #безопасностьIT #кибертренды