Постмортем CrowdStrike: как мы пересмотрели порядок обновления агентов безопасности

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

CrowdStrike в своих первых публичных заявлениях признал, что механизм staged rollout для content-обновлений агента работал не так, как должен. Content-обновление (не полноценный апгрейд агента, а обновление конфигурационного файла channel) прилетело во все сенсоры сразу, без фазового раскатывания. Canary-тестирование на этом уровне фактически отсутствовало. Именно поэтому событие оказалось таким масштабным - не было ни одного барьера между ошибкой в файле и миллионами BSOD.

Что именно мы пересмотрели

До сбоя у нас существовало правило «смотреть на крупные версионные апгрейды агента через неделю после релиза». Это разумно, но это только про major-обновления. Content-обновления, которые CrowdStrike (и не только он) рассылает автоматически и непрерывно, были вне этого правила - их никто не рассматривал как потенциально опасные. Теперь рассматривают.

Новый регламент закрывает три дыры.

Первая - отсутствие staging-сегмента для агентов безопасности. EDR, антивирус, агенты мониторинга конечных точек - всё это раньше обновлялось централизованно и синхронно. Теперь в каждой инфраструктуре выделяется отдельная группа хостов под ранние обновления. Это не обязательно физически изолированный сегмент - достаточно группы политик в консоли управления, которая получает обновления раньше основного флота.

Вторая - отсутствие окна наблюдения. Даже если staging-группа и существовала, никто не ждал формально. Теперь между обновлением staging-группы и выкаткой в прод - минимум 48 часов. В этот промежуток смотрим на метрики: нагрузка CPU, количество падений процессов агента, алерты в SIEM. Если за 48 часов ничего не сломалось - идём дальше.

Третья - нет чеклиста перед выкаткой. Обновление агента в прод раньше было «нажать кнопку». Теперь это пункт в чеклисте, который нельзя пройти без явного подтверждения.

Контрольный список перед выкаткой в прод

Вот что проверяем перед тем, как пускать обновление агента на основной флот.

• Срок выдержки в staging. Прошло не менее 48 часов с момента применения в staging-группе.
• Метрики staging-хостов. Нет аномального роста CPU/памяти, нет рестартов процессов агента, нет новых алертов в SIEM, связанных с агентом.
• Changelog вендора. Прочитан. Если есть изменения в поведении ядерного драйвера или kernel-модуля - срок выдержки удваивается.
• Окно выкатки. Запланировано в рабочее время, не в пятницу вечером. Инженер на связи в течение двух часов после начала.
• Rollback-план. Определена конкретная версия, к которой откатываемся, проверена её доступность в репозитории вендора.
• Покрытие хостов. Обновление идёт волнами: сначала не более 20% флота, потом через час - остальное, если всё чисто.

Список звучит как капитанщина. Но именно его отсутствие привело к тому, что 19 июля кто-то нажал кнопку «раскатить» без каких-либо барьеров.

Что сложно

Есть одна честная проблема с этим подходом: content-обновления у большинства EDR-вендоров нельзя отложить так же просто, как версионный апгрейд агента. CrowdStrike, например, исторически не давал возможности откладывать channel-файлы - это была особенность архитектуры, которая и стала уязвимостью. После сбоя они анонсировали изменения в этой части, но пока это анонс, а не работающая функциональность.

Поэтому на практике для content-обновлений staging-группа помогает только зафиксировать факт проблемы раньше, чем она разойдётся по всему флоту. Остановить раскатку автоматически она не позволяет - только дать команде время среагировать и отозвать обновление вручную.

Это не идеально. Но это лучше, чем «узнать о проблеме, когда упало всё».

Что с этим дальше

Регламент внедрён, staging-группы размечены у клиентов. Теперь нужно убедиться, что он реально работает, а не просто лежит в Confluence. Первый тест будет при следующем мажорном обновлении агента - посмотрим, насколько процедура выдерживает реальное давление, когда вендор присылает уведомление «обновите как можно скорее по соображениям безопасности».

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