Компания Cloudflare столкнулась с серьезным инцидентом, когда рутинная операция по блокировке фишингового URL-адреса привела к масштабному сбою в работе критической инфраструктуры. Инцидент, продлившийся 59 минут, затронул множество ключевых сервисов компании и наглядно продемонстрировал важность наличия надежных протоколов безопасности даже при выполнении стандартных операций.

Анатомия инцидента: от фишинга к системному сбою

Проблема возникла при реагировании на обнаруженную фишинговую угрозу в системе Cloudflare R2 — современном объектном хранилище, аналогичном Amazon S3. Вместо точечной блокировки вредоносного эндпоинта сотрудник по ошибке деактивировал всю службу R2 Gateway, что спровоцировало каскадный эффект нарушений в работе связанных сервисов.

Масштаб воздействия на инфраструктуру

Инцидент существенно повлиял на работоспособность ключевых сервисов Cloudflare. В частности, наблюдались сбои в функционировании системы Durable Objects (рост ошибок на 0,09%), Cache Purge (увеличение количества ошибок HTTP 5xx на 1,8% и десятикратный рост задержки), а также Workers & Pages (проблемы с развертыванием у 0,002% проектов, связанных с R2).

Технические причины и принятые меры

Анализ инцидента выявил две основные проблемы: человеческий фактор и отсутствие достаточных механизмов защиты от потенциально опасных действий. В ответ на это Cloudflare реализовала ряд превентивных мер: удалила возможность отключения систем из интерфейса специалистов по борьбе со злоупотреблениями и внедрила дополнительные ограничения в Admin API для предотвращения случайного отключения сервисов.

Этот инцидент подчеркивает критическую важность внедрения многоуровневых систем защиты и тщательной валидации действий даже для привилегированных пользователей. Компаниям рекомендуется регулярно пересматривать свои протоколы безопасности и внедрять механизмы предотвращения случайных системных сбоев, особенно в критически важной инфраструктуре.