Как Cloudflare защищает свои сети от самых современных кибератак: архитектура безопасности из первых рук

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

В разговорах с ИБ-директорами и командами безопасности, которые состоялись после этого, вопросы были одинаковыми: как на самом деле выглядит наша архитектура, за чем нам следует следить, с чего начать и как Cloudflare может помочь?

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

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

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

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

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

• Первое — это скорость обнаружения. Модели фронтира облегчают поиск в больших массивах публичного кода, включая библиотеки с открытым исходным кодом, от которых зависят многие компании. Это не значит, что каждый баг в библиотеке эксплуатируем, или что баги в библиотеках являются источником большинства уязвимостей. Эксплуатируемость по-прежнему зависит от того, как используется код, может ли управляемый атакующим ввод достичь уязвимого пути, и от защит, которые его окружают. Но широко используемые библиотеки и фреймворки с открытым исходным кодом дают атакующим общую поверхность для изучения в масштабе. Когда там существует реальная, достижимая уязвимость, модель может помочь найти её, проанализировать возможные пути эксплуатации и сгенерировать варианты доказательства концепции быстрее, чем мейнтейнеры и защитники могут проверить каждое последующее использование. Разрыв между моментом, когда атакующий обнаруживает уязвимость, и моментом, когда защитники узнают о её существовании, беспокоит нас больше всего. Если вы не запускаете эти модели против своего собственного кода, можете быть уверены, что кто-то другой это делает.

• Второе — это объем и адаптация эксплойтов. Модель может создать тысячи вариаций одного эксплойта и проводить разведку в том же масштабе. Весь этот объем дает атакующему преимущество, но не обязательно позволит обойти сигнатурные детекты. Многие из этих итераций будут иметь одну и ту же базовую сигнатуру, поэтому правило, которое ловит первую, поймает и остальные. Адаптация — это то, как они обойдут сигнатурные детекты. Попросите модель показать вам SQL-инъекцию, и она вернет учебный пример. Скажите ей, что на пути стоит WAF, и она начнет зондирование, изучая, что блокируется, и переписывая полезную нагрузку, пока не сможет проскользнуть мимо блокирующего правила.

• Третье — это воздействие, когда уязвимость неизбежно эксплуатируется. Никакая архитектура не ловит всё. После эксплуатации уязвимости вопрос, который мы себе задаем: куда может попасть атакующий, имея одну учетную запись, один путь или один credential, прежде чем что-то ещё его остановит? Если ответ — "куда угодно", то проблема никогда не была в уязвимости. Проблемой была архитектура вокруг уязвимости.

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

Первая — это Cloudforce One, наша команда по анализу угроз, исследованиям и операциям, которая находится в составе организации безопасности Cloudflare. Они превращают то, что мы видим в сети, в инсайты, на которые может реагировать остальная часть стека: отслеживаемые противники, новые кампании и индикаторы компрометации (IOC). Сложность этой работы никогда не заключалась в знании того, что является вредоносным, — проблема была в задержке при реагировании. Информация о новой угрозе обычно должна пройти путь от отчета об угрозе через фид до защиты компании, прежде чем её можно будет использовать для блокировки. Атакующие научились двигаться быстрее. Наша сеть устраняет этот разрыв: клиенты Cloudflare теперь могут использовать аналитику угроз Cloudforce One непосредственно в WAF для блокировки высокорискованного трафика.

Вторая — это команда, которая владеет движком WAF, выполняющим фактическое обнаружение: управляемые наборы правил, которые работают перед нашими собственными ресурсами и доступны каждому клиенту Cloudflare, машинное обучение, стоящее за WAF Attack Score, и взаимосвязи, которые иногда позволяют нам выпустить правило до того, как CVE будет публично раскрыт. Команда распределена по всему миру и действует быстро, выпуская правила в течение нескольких часов после того, как становится известно о доказательстве концепции атаки. После развертывания обнаружение достигает всей нашей сети, а вместе с ней и каждого клиента Cloudflare, менее чем за 30 секунд. React2Shell — недавний пример: управляемое правило WAF защищало наши собственные ресурсы и ресурсы всех остальных на Cloudflare за несколько часов до публикации официального уведомления.

Уровень скоринга, защиты, которые мы размещаем перед приложением, и изоляция вокруг уязвимости — все это строится на том, что видят эти две команды.

Сигнатурные защиты были созданы для мира, где новые эксплойты были редкостью, а вариации занимали недели. Традиционный SLA Cloudflare от свежего доказательства концепции до живого развернутого правила составлял 12 часов. С появлением моделей фронтира этого больше недостаточно. Обнаружения должны быть установлены до того, как CVE будет обнаружен. Именно поэтому мы размещаем ML-обнаружение перед традиционным сигнатурным WAF.

Модель обучается на большом массиве прошлого атакующего трафика и ловит новые варианты уязвимостей до того, как они станут публично известны. Новая SQL-инъекция или цепочка удаленного выполнения кода почти всегда являются перегруппировкой форм атаки, которые модель уже видела, даже если конкретный эксплойт является совершенно новым. Мы запускаем модель на каждом запросе и присваиваем WAF Attack Score от 1 до 99, основываясь на том, насколько запрос похож на эти базовые формы, а не на основе списка известных плохих сигнатур. Чем ниже оценка, тем более агрессивно мы обрабатываем запрос. Эта оценка определяет, пропускаем ли мы запрос. Мы применяем аналогичную методологию скоринга к AI-промптам с помощью AI Security for Apps: вместо проверки каждого промпта по списку известных вредоносных промптов, мы оцениваем, насколько промпт похож на реальную атаку.

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

На поверхности API мы используем позитивную модель безопасности через API Shield. Вместо того чтобы пытаться предугадать каждый плохой запрос, мы описываем, как выглядит допустимый запрос к каждому API — либо из собственного определения API, либо на основе реального трафика — и всё, что не соответствует, не проходит. Это нейтрализует преимущество передовых ИИ-моделей: поскольку мы разрешаем только проверенный трафик, генерация тысяч новых вариаций атак не позволяет обойти систему.

^{Многоуровневая архитектура Cloudflare}

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

Zero Trust Network Access используется для каждого внутреннего приложения. Неявное доверие к нахождению внутри сети заменяется явной идентификацией и политикой для каждого запроса каждого сотрудника, получающего доступ к каждому инструменту. Ценность этого стала очевидной, когда один из наших инженеров развернул неправильно настроенный инструмент. В плоской сети всё в том же сегменте было бы открыто, но в нашем развертывании воздействие ограничилось самим инструментом. После этого мы создали Require Access Protection, чтобы вновь развернутые или неправильно настроенные приложения не были доступны до применения политики доступа.

IdP Federation упрощает поддержание безопасной конфигурации по умолчанию во всех аккаунтах Cloudflare — что становится ещё более необходимым, когда больше людей быстро развертывают внутренние инструменты. Вместо того чтобы просить каждую команду настраивать SSO отдельно, мы настраиваем нашего провайдера идентификации (IdP) один раз и используем его во всей организации. Новые аккаунты получают SSO автоматически, соединения IdP на стороне получателя доступны только для чтения, а политики доступа в каждом аккаунте по-прежнему оценивают полученную идентификацию в рамках обычного потока запросов.

MCP Server Portal предоставляет командам контролируемый способ подключения ИИ-агентов к корпоративным системам. Агенты получают доступ к MCP-серверам, которые централизованно управляются через единый портал, при этом каждое действие регистрируется. Таким образом, когда агент действует от чьего-либо имени, мы знаем, что он сделал, к чему прикоснулся и должно ли это было быть разрешено. Полная картина того, как мы это построили, описана в нашей статье о корпоративном MCP.

AI Gateway работает перед нашими внутренними ИИ-инструментами так же, как AI Security for Apps работает перед ориентированными на клиентов ИИ-функциями, с теми же оценками и той же видимостью. Внутри компании компонент видимости более полезен, чем блокировка, потому что нам нужно было видеть, что на самом деле строят инженеры, прежде чем мы сможем написать осмысленную политику для этого.

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

• Разместите проверку перед публичными приложениями.

• Определите, как выглядит допустимый API-трафик.

• Используйте обнаружение ботов для ограничения автоматического зондирования.

• Требуйте политику идентификации и доступа до того, как станет доступен любой внутренний инструмент.

Для ИИ и агентных систем:

• Направляйте трафик моделей через шлюз.

• Поддерживайте подключение агентов через одобренные MCP-серверы.

• Регистрируйте их действия.

Цель — гарантировать, что когда один уровень пропускает угрозу, следующий уровень ограничивает то, что злоумышленник может увидеть, достичь или изменить.

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

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

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

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

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