Компания 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 для предотвращения случайного отключения сервисов.
Cloudflare опубликовала полный postmortem инцидента. По данным компании, отключение затронуло сервисы глобально, показывая, что даже при правильно выстроенной защите от внешних атак, операционные ошибки внутренних команд при реагировании на угрозы остаются значимым вектором риска.
