← Cloudflare Workers / workers / reference

Модель безопасности

В этой статье приводится обзор архитектуры безопасности Cloudflare, а затем рассматриваются два часто задаваемых вопроса: ошибки V8 и Spectre.

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

Именно поэтому Workers спроектирован так, чтобы код не мог локально измерить собственное время выполнения. Например, значение, возвращаемое Date.now() фиксируется на время выполнения кода. Других таймеров не предоставляется. Более того, Cloudflare не дает доступа к параллелизму (например, к многопоточности), поскольку это позволило бы злоумышленникам создавать произвольные таймеры. Такие архитектурные решения нельзя задним числом внедрить в другие платформы, например в веб-браузеры, поскольку это удалило бы API, от которых зависят существующие приложения. В Workers это оказалось возможным только благодаря архитектурным решениям, заложенным с самого начала.

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

Подход Workers существенно отличается от подхода, принятого в большей части индустрии. Он устойчив ко всему спектру Атаки в стиле Spectre ↗, без необходимости уделять особое внимание каждому из них и без необходимости в целом блокировать спекулятивное выполнение. Однако, поскольку подход Workers отличается, он требует тщательного изучения. Cloudflare в настоящее время сотрудничает с исследователями из Грацского технического университета (TU Graz), изучая проделанную работу. Среди этих исследователей есть те, кто изначально обнаружил Spectre. Cloudflare опубликует результаты этого исследования по мере их появления.

Подробнее см. в это выступление ↗ от Kenton Varda, архитектора Cloudflare Workers. Об уязвимости Spectre рассказывается ближе к концу.

Начнём с краткого обзора архитектуры среды выполнения Workers:

При проектировании песочницы для кода есть две ключевые составляющие: безопасная изоляция и проектирование API.

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

Для этого Cloudflare в первую очередь использует V8, движок JavaScript, разработанный Google для Chrome. V8 выполняет код внутри изолятов, которые не позволяют этому коду обращаться к памяти за пределами изолята, даже в рамках одного процесса. Это важно, поскольку означает, что Cloudflare может запускать множество изолятов в одном процессе. Это необходимо для edge-платформы вроде Workers, где Cloudflare приходится размещать на каждой машине тысячи гостевых приложений и тысячи раз в секунду быстро переключаться между ними с минимальными накладными расходами. Если бы Cloudflare пришлось запускать отдельный процесс для каждого гостя, число клиентов, которых Cloudflare могла бы обслуживать, резко сократилось бы, и Cloudflare пришлось бы ограничить edge-вычисления небольшим числом крупных клиентов Enterprise. Благодаря технологии изолятов Cloudflare может сделать edge-вычисления доступными для всех.

Иногда, впрочем, Cloudflare всё же решает запустить Worker в отдельном приватном процессе. Это происходит, если Worker использует определённые функции, которым нужен дополнительный уровень изоляции. Например, когда разработчик использует отладчик devtools для проверки своего Worker, Cloudflare выполняет этот Worker в отдельном процессе. Дело в том, что исторически в браузере протокол инспектора был доступен только доверенному оператору браузера и поэтому не проверялся на безопасность так же тщательно, как остальной код V8. Чтобы снизить риск возможных уязвимостей в протоколе инспектора, Cloudflare переносит проверяемые Workers в отдельный процесс с песочницей на уровне процесса. Cloudflare также использует изоляцию процессов как дополнительную защиту от Spectre.

Кроме того, даже для изолятов, работающих в общем процессе с другими изолятами, Cloudflare запускает на каждой машине несколько экземпляров всей среды выполнения; это называется cordons. Workers распределяются между cordons по уровню доверия: менее доверенные Workers отделяются от более доверенных. Например, клиент на плане Free никогда не окажется в одном процессе с клиентом на плане Enterprise. Это дает дополнительный уровень защиты на случай, если в V8 обнаружится уязвимость нулевого дня.

На уровне всего процесса Cloudflare применяет ещё один слой изоляции для многоуровневой защиты. Песочница второго уровня использует пространства имён Linux и seccomp чтобы запретить любой доступ к файловой системе и сети. Пространства имен и seccomp обычно используются для реализации контейнеров. Однако Cloudflare применяет эти технологии гораздо строже, чем это обычно возможно в движках контейнеров, потому что Cloudflare настраивает namespaces и seccomp после запуска процесса, но до загрузки изолятов. Это, например, означает, что Cloudflare может использовать (и использует) полностью пустую файловую систему (mount namespace) и использует seccomp чтобы полностью блокировать все системные вызовы, связанные с файловой системой. Обычно движки контейнеров не могут запретить весь доступ к файловой системе, поскольку это сделало бы невозможным использование exec() чтобы запустить гостевую программу с диска. В случае Workers гостевые программы Cloudflare не являются нативными бинарными файлами, а сама среда выполнения Workers уже завершает загрузку до того, как Cloudflare блокирует доступ к файловой системе.

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

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

Например, когда процесс песочницы получает запрос к Worker, с которым он ранее не сталкивался, этот запрос включает ключ шифрования кода этого Worker, включая прикреплённые секреты. Песочница может передать этот ключ супервизору, чтобы запросить код. Она не может запросить ни один Worker, для которого не получила соответствующий ключ, и не может перечислить известные Workers. Она также не может запросить конфигурацию, которая ей не нужна: например, не может запросить ключ TLS, используемый для HTTPS трафика к Worker.

Помимо чтения конфигурации, есть ещё одна причина, по которой песочница обменивается данными с другими процессами системы: это реализация API, доступных Workers.

Есть поговорка: если дерево падает в лесу и никто этого не слышит, издаёт ли оно звук? А в Cloudflare говорят так: если Worker выполняется в полностью изолированной среде, из которой ему запрещено любое взаимодействие с внешним миром, работает ли он вообще?

Полная изоляция кода, по сути, бесполезна. Чтобы Workers могли делать что-то полезное, они должны иметь возможность взаимодействовать с пользователями. Как минимум, Worker должен уметь принимать запросы и отвечать на них. А чтобы Workers могли безопасно отправлять запросы во внешний мир, нужны API.

В контексте песочницы проектирование API приобретает новый уровень ответственности. API Cloudflare точно определяют, что Worker может и не может делать. Cloudflare должна крайне внимательно проектировать каждый API так, чтобы он допускал только разрешённые операции и не более того. Например, Cloudflare хочет разрешить Workers отправлять и получать HTTP-запросы, но не давать им доступ к локальной файловой системе или внутренним сетевым службам.

В настоящее время Workers не предоставляют доступа к локальной файловой системе. Поэтому Cloudflare вообще не предоставляет API файловой системы. Нет API, значит нет и доступа.

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

Для этого Workers будет использовать архитектуру, основанную на безопасность на основе прав доступа ↗. Тема capabilities сама по себе обширна, но в данном случае имеется в виду, что Cloudflare передаёт Worker объект типа Directory, представляющий каталог в файловой системе. Этот объект имел бы API, позволяющий создавать и открывать файлы и подкаталоги, но не позволяющий переходить в родительский каталог. По сути, каждый Worker видел бы свой собственный Directory как будто это корень их собственной файловой системы.

Как бы реализовать такой API? Как было описано выше, процесс песочницы не имеет доступа к реальной файловой системе. Вместо этого доступ к файлам обеспечивается через процесс супервизора. Песочница взаимодействует с супервизором с помощью Cap’n Proto RPC ↗, протокол RPC на основе возможностей (capability-based). (Cap’n Proto, проект с открытым исходным кодом, который сейчас поддерживает команда Cloudflare Workers.) Этот протокол значительно упрощает реализацию API на основе возможностей, благодаря чему Cloudflare может строго ограничить песочницу доступом только к тем файлам, которые принадлежат запускаемым в ней Workers.

А как насчет доступа к сети? Сегодня Workers могут обмениваться данными с внешним миром только по HTTP, как входящему, так и исходящему. API для других видов сетевого доступа не существует, поэтому такой доступ запрещен, хотя Cloudflare планирует поддержать другие протоколы в будущем.

Как уже упоминалось, процесс песочницы не может подключаться к сети напрямую. Вместо этого все исходящие HTTP-запросы отправляются через UNIX domain socket в локальный прокси-сервис. Этот сервис применяет к запросу ограничения: например, проверяет, что запрос адресован либо публичному интернет-сервису, либо собственному исходному серверу зоны Worker, а не внутренним службам, которые могут быть видны в локальной сети или на локальной машине. Кроме того, он добавляет к каждому запросу заголовок с указанием Worker, от которого запрос исходит, чтобы можно было отследить и заблокировать вредоносные запросы. После того как всё проверено, запрос отправляется на уровень HTTP-кеширования сети Cloudflare, а затем выходит в интернет.

Аналогично, входящие HTTP-запросы не поступают напрямую в среду выполнения Workers. Сначала их принимает входящий прокси-сервис. Этот сервис отвечает за терминацию TLS (среда выполнения Workers никогда не видит ключи TLS), а также определяет нужный скрипт Worker для конкретного URL запроса. После того как всё проверено, запрос передаётся в процесс песочницы через UNIX domain socket.

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

Workers во многом полагаются на изоляцию, которую обеспечивает V8, JavaScript-движок Google, используемый в Chrome. У этого подхода есть свои плюсы и минусы. С одной стороны, V8 представляет собой чрезвычайно сложную технологию, что создаёт более широкую поверхность атаки, чем у виртуальных машин. Чем выше сложность, тем больше возможностей для сбоев. С другой стороны, в поиск и исправление ошибок V8 вкладываются огромные усилия, ведь это, пожалуй, самая популярная в мире технология песочницы. Google регулярно выплачивает вознаграждения в пять цифр за обнаружение выхода за пределы песочницы V8. Кроме того, Google использует инфраструктуру фаззинга, которая находит ошибки автоматически и быстрее, чем это способно сделать большинство людей. Благодаря этим вложениям Google риск появления уязвимостей нулевого дня в V8, то есть ошибок, обнаруженных злоумышленниками и неизвестных Google, значительно снижается.

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

Промежуток времени между публикацией исправления и его развёртыванием называется patch gap. Ранее Google объявила о сокращении разрыва между выходом патчей и их применением в Chrome с 33 до 15 дней ↗.

К счастью, Cloudflare напрямую управляет машинами, на которых работает среда выполнения Workers. Процесс сборки и выпуска почти полностью автоматизирован: как только выходит патч V8, системы Cloudflare автоматически собирают новый релиз среды выполнения Workers и после утверждения в один клик от необходимых (живых) рецензентов автоматически выкатывают этот релиз в продакшен.

В результате разрыв в применении патчей для Workers теперь составляет менее 24 часов. Патч, опубликованный командой V8 в Мюнхене в течение их рабочего дня, обычно попадает в продакшен ещё до конца рабочего дня в США.

Команда V8 в Google заявила, что Сам V8 не может защититься от Spectre ↗. Для этого Workers не обязательно зависит от V8. Среда Workers предлагает множество альтернативных подходов к защите от Spectre.

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

Подробнее о Spectre см. в страница Learning Center, посвящённая этой теме ↗.

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

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

В Cloudflare Workers арендаторы изолируются друг от друга с помощью V8 isolates, а не процессов или виртуальных машин. Это значит, что Workers не всегда может полагаться на патчи ОС или гипервизора для защиты от Spectre: платформе нужна собственная стратегия.

Cloudflare Workers спроектирован так, чтобы выполнять ваш код в каждой точке присутствия Cloudflare.

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

Совместите эти два момента, и планирование сразу усложняется.

Типичный serverless-провайдер без edge-инфраструктуры может обслуживать арендатора с низким трафиком, направляя весь его трафик на одну машину, так что нужно загрузить только одну копию приложения. Если машина способна обслужить, скажем, десяток арендаторов, этого более чем достаточно. Такую машину можно разместить в огромном дата-центре с миллионами машин, за счёт чего достигается экономия на масштабе. Однако такая централизация приводит к задержкам и глобальным расходам на трафик, когда пользователи находятся далеко.

В случае Workers, напротив, каждый тенант, независимо от уровня трафика, в настоящее время выполняется в каждой локации Cloudflare. А стремясь оказаться как можно ближе к конечному пользователю, Cloudflare иногда выбирает локации, где хватает места лишь для ограниченного числа машин. В итоге Cloudflare должна уметь размещать на одной машине тысячи активных тенантов и быстро поднимать неактивные по требованию. Это означает, что каждый guest не может занимать больше пары мегабайт памяти: этого едва хватает на call stack, не говоря уже обо всем остальном, что нужно процессу.

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

Чтобы Workers оставались недорогими, быстрыми и доступными для всех, Cloudflare нужно было найти способ размещать несколько арендаторов в одном процессе.

У Spectre нет официального решения. Даже использование тяжеловесных виртуальных машин не спасает. Уязвимы все.

Индустрия продолжает сталкиваться с новыми атаками Spectre. Каждые несколько месяцев исследователи обнаруживают новую уязвимость Spectre, производители CPU выпускают новый микрокод, а производители ОС выпускают патчи для ядра. Всем приходится постоянно обновляться.

Но достаточно ли просто устанавливать последние патчи?

Существуют и другие уязвимости, которые пока не были обнародованы. Чтобы защититься от Spectre, Cloudflare потребовался другой подход. Недостаточно блокировать отдельные известные уязвимости, нужно устранять целые классы уязвимостей сразу.

Маловероятно, что когда-либо будет найдено универсальное решение проблемы Spectre. Тем не менее следующий мысленный эксперимент поднимает вопросы, которые стоит рассмотреть:

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

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

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

Многие исследователи безопасности считают, что на этом история заканчивается. Какой смысл замедлять атаку, если она всё равно возможна?

Однако меры, замедляющие атаку, могут быть весьма эффективными.

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

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

Что можно сделать, чтобы замедлить атаки Spectre настолько, что они станут бессмысленными?

Workers не позволяет клиентам загружать нативные бинарные файлы для выполнения в сети Cloudflare: разрешены только JavaScript и WebAssembly. Многие другие языки, например Python, Rust или даже Cobol, можно скомпилировать или транспилировать в один из этих двух форматов. Оба формата проходят через V8, который преобразует их в настоящий машинный код.

Само по себе это не обязательно усложняет атаки Spectre. Однако этот шаг обозначен как шаг 0, поскольку он необходим для выполнения следующих шагов.

Поддержка программ на нативном коде означает привязку к определённой архитектуре процессора (как правило, x86). Чтобы выполнять код с приемлемой производительностью, его обычно приходится запускать напрямую на реальном оборудовании, что существенно ограничивает контроль хоста над ходом выполнения. Например, ядро или гипервизор не может запретить приложениям вызывать CLFLUSH инструкция, инструкция что полезно при атаках по сторонним каналам ↗ и почти ничего больше.

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

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

В Workers текущее время можно получить с помощью JavaScript Date API, вызвав Date.now(). Однако возвращаемое значение времени не является текущим временем. Date.now() возвращает время последней операции ввода-вывода. Оно не увеличивается во время выполнения кода. Например, если злоумышленник напишет:

let start = Date.now();
for (let i = 0; i < 1e6; i++) {
  doSpectreAttack();
}
let end = Date.now();

Значения start и end всегда будет точно таким же. Злоумышленник не может использовать Date чтобы измерить время выполнения своего кода, что необходимо для проведения атаки.

Аналогично, в Workers не допускаются многопоточность и общая память. Всё, что связано с обработкой одного события, происходит в одном потоке. Иначе можно было бы устраивать гонки потоков, чтобы угадывать и проверять базовый таймер. Нескольким Workers запрещено одновременно обрабатывать один и тот же запрос. Например, если в вашей зоне установлено приложение Cloudflare, реализованное на Workers, а сама зона тоже использует Workers, запрос к зоне может обрабатываться двумя Workers последовательно. Они выполняются в одном потоке.

На этом этапе локальное измерение времени выполнения кода уже невозможно. Однако его всё ещё можно измерить удалённо. Например, HTTP-клиент, отправляющий запрос для запуска Worker, может измерить, сколько времени требуется на ответ. Такое измерение, скорее всего, будет очень зашумлённым, поскольку запросу приходится проходить через весь интернет и нести общие сетевые издержки. Теоретически этот шум можно устранить, повторив атаку много раз и усреднив результаты.

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

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

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

Теперь об обычной проблеме использования метрик производительности для обнаружения атак Spectre: иногда случаются ложные срабатывания. Иногда легитимная программа работает нестабильно. Среда выполнения не может останавливать любое приложение с низкой производительностью.

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

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

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

Cloudflare разрабатывает этот подход совместно с экспертами Грацского технического университета. Команда TU Graz сама участвовала в открытии уязвимости Spectre и с тех пор стояла за множеством последующих открытий в этой области. Cloudflare реализовала возможность динамической изоляции Workers и определила метрики, надёжно выявляющие подобные атаки.

Как уже упоминалось, изоляция процессов не является исчерпывающей защитой. Со временем атаки Spectre становится всё сложнее и дольше проводить, а значит у Cloudflare появляется возможность с достаточной уверенностью выявлять злоумышленников. Изоляция процесса дополнительно замедляет потенциальную атаку.

На этом этапе все известные атаки уже предотвращены. Это оставляет Workers уязвимыми перед будущими неизвестными атаками, как и любую другую систему на базе CPU. Однако новые атаки обычно требуют очень много времени, дни и более, что даёт Cloudflare время подготовить защиту.

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

В целом, поскольку Workers по своей природе вытесняемы (в отличие от контейнеров или виртуальных машин), у Cloudflare есть широкие возможности противодействовать атакам.

Cloudflare рассматривает это как непрерывную работу, а не задачу, которую можно когда-либо считать завершённой.