Code Orange: Как мы устраняем уязвимости после глобальных сбоев

18 ноября 2025 года в сети Cloudflare произошли серьезные сбои в обработке сетевого трафика примерно на два часа и десять минут. Почти через три недели, 5 декабря 2025 года, наша сеть снова не смогла обслуживать трафик для 28% приложений, использующих нашу сеть, в течение примерно 25 минут.

После обоих инцидентов мы опубликовали подробные отчеты (post-mortem), но мы понимаем, что должны сделать больше, чтобы вернуть ваше доверие. Сегодня мы рассказываем о работе, которая ведется в Cloudflare, чтобы предотвратить повторение подобных сбоев.

Мы называем этот план «Код «Оранжевый»: Отказ в малом масштабе» («Code Orange: Fail Small»), что отражает нашу цель сделать нашу сеть более устойчивой к ошибкам или сбоям, которые могут привести к крупному отказу. «Код «Оранжевый»» означает, что работа над этим проектом имеет наивысший приоритет над всеми остальными задачами. Для справки: мы объявляли «Код «Оранжевый»» в Cloudflare лишь однажды ранее, после другого крупного инцидента, который потребовал максимального внимания от всех сотрудников компании. Мы считаем, что последние события требуют такой же концентрации. Код «Оранжевый» — это наш способ обеспечить это, позволяя командам при необходимости работать на межфункциональной основе для выполнения задачи, приостанавливая любую другую работу.

Работа по Коду «Оранжевый» организована по трем основным направлениям:

• Ввести обязательные контролируемые развертывания для любых изменений конфигурации, распространяемых в сети, подобно тому, как мы это делаем сегодня для выпусков программных бинарных файлов.

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

• Изменить наши внутренние процедуры «разбития стекла»* и устранить любые циклические зависимости, чтобы мы и наши клиенты могли действовать быстро и без проблем получать доступ ко всем системам во время инцидента.

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

Мы понимаем, что эти инциденты болезненны для наших клиентов и для Интернета в целом. Нам глубоко стыдно за них, и именно поэтому эта работа является первоочередной задачей для каждого сотрудника Cloudflare.

^{* Процедуры «разбития стекла» в Cloudflare позволяют определенным лицам в определенных обстоятельствах повысить свои привилегии для выполнения неотложных действий по устранению сценариев высокой степени серьезности.}

При первом инциденте пользователи, посещавшие сайт клиента на Cloudflare, видели страницы с ошибками, указывающими, что Cloudflare не может доставить ответ на их запрос. Во втором случае они видели пустые страницы.

Оба сбоя развивались по схожей схеме. В моменты, предшествовавшие каждому инциденту, мы мгновенно развернули изменение конфигурации в наших центрах обработки данных в сотнях городов по всему миру.

Изменение в ноябре было автоматическим обновлением классификатора нашей системы Bot Management. Мы запускаем различные модели искусственного интеллекта, которые обучаются на трафике, проходящем через нашу сеть, чтобы создавать методы обнаружения ботов. Мы постоянно обновляем эти системы, чтобы опережать злоумышленников, пытающихся обойти нашу защиту и получить доступ к сайтам клиентов.

Во время инцидента в декабре, пытаясь защитить наших клиентов от уязвимости в популярном фреймворке с открытым исходным кодом React, мы развернули изменение в инструменте безопасности, используемом нашими аналитиками для улучшения сигнатур. Подобно срочности обновлений Bot Management, нам нужно было опередить злоумышленников, которые хотели эксплуатировать уязвимость. Это изменение спровоцировало начало инцидента.

Эта модель выявила серьезный пробел в том, как мы развертываем изменения конфигурации в Cloudflare, по сравнению с тем, как мы выпускаем обновления программного обеспечения. Когда мы выпускаем обновления версий ПО, мы делаем это контролируемым и отслеживаемым образом. Для каждого нового выпуска бинарного файла развертывание должно успешно пройти несколько этапов, прежде чем оно сможет обслуживать трафик по всему миру. Сначала мы развертываем обновление на трафике сотрудников, а затем осторожно распространяем изменение на возрастающий процент клиентов по всему миру, начиная с бесплатных пользователей. Если мы обнаруживаем аномалию на любом этапе, мы можем откатить выпуск без какого-либо вмешательства человека.

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

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

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

Внедрение контролируемых развертываний нашей конфигурации, как мы уже делаем для выпусков ПО, является самым важным направлением работы нашего плана «Код «Оранжевый»».

Изменения конфигурации в Cloudflare очень быстро распространяются по сети. Когда пользователь создает новую DNS-запись или правило безопасности, она достигает 90% серверов в сети за секунды. Это обеспечивается программным компонентом, который мы внутри называем Quicksilver.

Quicksilver также используется для любых изменений конфигурации, требуемых нашими собственными командами. Скорость — это особенность: мы можем реагировать и глобально обновлять поведение нашей сети очень быстро. Однако в обоих инцидентах это привело к тому, что критическое изменение распространилось на всю сеть за секунды, минуя этапы проверки.

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

Мы выпускаем обновления программного обеспечения для нашей сети несколько раз в день через то, что мы называем системой Health Mediated Deployment (HMD). В этой системе каждая команда Cloudflare, отвечающая за сервис (часть ПО, развернутого в нашей сети), должна определить метрики, указывающие на успешность или неудачу развертывания, план поэтапного внедрения и шаги, которые нужно предпринять в случае неудачи.

У разных сервисов могут быть немного разные переменные. Некоторым могут потребоваться более длительные периоды ожидания перед переходом к большему количеству ЦОД, в то время как другие могут иметь более низкий допустимый порог частоты ошибок, даже если это вызывает ложные срабатывания.

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

К завершению работы по Коду «Оранжевый» обновления конфигурации будут следовать этому же процессу. Мы ожидаем, что это позволит нам быстро обнаруживать проблемы, подобные тем, что произошли в последних двух инцидентах, задолго до того, как они станут широкомасштабными.

Хотя мы оптимистично настроены, что лучший контроль над изменениями конфигурации позволит выявлять больше проблем до того, как они станут инцидентами, мы понимаем, что ошибки могут и будут происходить. Во время обоих инцидентов ошибки в одной части нашей сети стали проблемами для большей части нашего технологического стека, включая плоскость управления (control plane), которую клиенты используют для настройки работы с Cloudflare.

Нам необходимо думать об осторожных, постепенных развертываниях не только с точки географического прогресса (распространение на большее количество наших ЦОД) или прогресса по пользователям (распространение на сотрудников и типы клиентов). Нам также необходимо планировать более безопасные развертывания, которые ограничивают распространение отказов между сервисами (распространение от одного продукта, например, нашего сервиса Bot Management, к несвязанному, например, нашей панели управления).

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

Возвращаясь к сбою в сервисе Управления ботами, было как минимум два ключевых интерфейса, где, если бы мы предположили, что отказ произойдет, мы могли бы обработать его изящно, так что клиенты, скорее всего, не пострадали бы. Первый — это интерфейс, который читал поврежденный конфигурационный файл. Вместо паники должна была существовать разумная проверенная конфигурация по умолчанию, которая позволила бы трафику проходить через нашу сеть, в то время как мы, в худшем случае, потеряли бы тонкую реальную настройку, которая питает наши модели машинного обучения для обнаружения ботов. Второй интерфейс — между основным программным обеспечением, работающим в нашей сети, и самим модулем Управления ботами. В случае сбоя нашего модуля управления ботами (как и произошло), мы не должны были по умолчанию блокировать трафик. Вместо этого мы могли бы, опять же, предусмотреть более разумную настройку по умолчанию, позволяющую трафику проходить с приемлемой классификацией.

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

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

Циклические зависимости также повлияли на качество обслуживания клиентов. Например, во время инцидента 18 ноября Turnstile, наше решение для защиты от ботов без CAPTCHA, стало недоступным. Поскольку мы используем Turnstile в процессе входа в панель управления Cloudflare, клиенты, у которых не было активных сеансов или токенов API-сервиса, не могли войти в Cloudflare в момент острой необходимости для внесения критических изменений.

Наша команда рассмотрит и улучшит все аварийные процедуры и технологии, чтобы обеспечить возможность при необходимости как можно быстрее получать доступ к нужным инструментам, сохраняя при этом наши требования безопасности. Это включает в себя анализ и устранение циклических зависимостей или возможность их быстрого «обхода» в случае инцидента. Мы также увеличим частоту наших учебных тренировок, чтобы все команды хорошо понимали процессы до любого потенциального кризисного сценария в будущем.

Хотя мы не описали в этом посте всю внутреннюю работу, которая ведется, указанные выше направления детально описывают ключевые приоритеты, на которых командам предложено сосредоточиться. Каждое из этих направлений связано с детальным планом, затрагивающим почти каждую продуктовую и инженерную команду в Cloudflare. Нам предстоит много работы.

К концу первого квартала, и в значительной степени раньше, мы:

• Обеспечим, чтобы все производственные системы были охвачены развертываниями с контролем работоспособности (Health Mediated Deployments, HMD) для управления конфигурацией.

• Обновим наши системы для соблюдения надлежащих режимов обработки отказов в соответствии с каждой продуктовой линейкой.

• Обеспечим наличие процессов, чтобы нужные люди имели соответствующий доступ для оказания надлежащей помощи во время чрезвычайной ситуации.

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