Пятница, которая началась в 04:09 UTC
19 июля 2024 года CrowdStrike отправила на Windows-машины конфигурационное обновление Falcon. В одном из наборов данных оказался некорректный параметр. Валидатор пропустил его, сенсор попытался прочитать данные и уронил систему. Через 78 минут обновление отозвали, но к этому моменту часть компьютеров уже не могла нормально загрузиться.
Microsoft оценила масштаб в 8,5 млн устройств. Это меньше одного процента всех Windows-машин, но среди них были рабочие станции и серверы авиакомпаний, больниц, банков и государственных служб. Процент маленький, радиус поражения огромный.
Самая опасная фраза — «это всего лишь контент»
Обновление не было новой версией приложения в привычном смысле. Оно меняло данные, по которым защитный агент распознаёт угрозы. Именно такие изменения команды часто выпускают по упрощённой схеме: без полноценного тестового контура, долгой выдержки и ручного подтверждения.
Практическое правило простое: если файл меняет поведение программы, относитесь к нему как к коду. У него должны быть схема, тесты на граничные значения, версия, журнал изменений и безопасная процедура отката.
Canary — не модное слово, а ограничитель ущерба
После инцидента CrowdStrike пообещала начинать подобные выкладки с canary-группы и только затем расширять охват. Такая схема полезна не только корпорациям. Даже у небольшого сервиса можно выделить внутренний контур, один процент трафика, один регион или несколько некритичных клиентов.
Важна не сама ступень, а пауза между ступенями. За это время система должна проверить ошибки, перезапуски, задержки и бизнес-метрики. Если наблюдаемость молчит, поэтапный релиз превращается в обычную массовую выкладку, только чуть медленнее.
Почему восстановление оказалось ручным
Проблемный агент загружался очень рано и мог отправить Windows в цикл синих экранов. На многих машинах требовалось загрузиться в безопасном режиме и удалить файл. Для удалённых офисов и зашифрованных дисков это означало физический доступ, ключи восстановления и часы работы по каждой машине.
Отсюда неприятный вопрос для любого бизнеса: можно ли починить критичный сервер, если не работает корпоративная сеть, SSO и ноутбук администратора? Нужны out-of-band доступ, автономный список контактов, сохранённые ключи и runbook вне той системы, которую предстоит спасать.
Чек-лист без бюджета уровня авиакомпании
- Разделите системы по критичности и запишите допустимое время простоя.
- Включите кольца выкладки: команда, canary, часть пользователей, все пользователи.
- Автоматически останавливайте релиз при росте ошибок и перезапусков.
- Храните аварийные инструкции и контакты независимо от основной инфраструктуры.
- Проверяйте восстановление из бэкапа, а не только факт создания копии.
- Для ключевых поставщиков опишите сценарий «сервис недоступен сутки».
- После сбоя разбирайте систему и процесс, а не ищите одного виноватого.
Главный вывод
CrowdStrike подвёл не один неудачный байт. Сошлись слишком доверенный валидатор, мгновенная массовая доставка и сложное ручное восстановление. Надёжность появляется, когда одна ошибка остаётся маленькой. Всё остальное — надежда на аккуратность людей и поставщиков.