Akamai Prolexic превратил маршрутизируемую DDoS-защиту в проверку ответственности за обходные маршруты

Резюме

• Обновление Akamai от 17 июня 2021 года сообщило, что инцидент в сервисе Prolexic Routed 3.0 затронул часть клиентов, использующих маршрутизируемую защиту от DDoS: оповещения начались в 8:47 по восточному времени, а трафик клиентов автоматически или вручную перенаправлялся до восстановления сервиса.
• Ответственный вопрос — делегированная защита. Клиент направляет трафик через сервис фильтрации, чтобы пережить DDoS-атаки, но этот маршрут становится зависимостью для непрерывности бизнеса, когда внутри провайдера защиты происходит сбой проверки или состояния маршрутизации.
• Akamai заявила, что инцидент не был вызван обновлением системы или кибератакой, и указала на непреднамеренное превышение значения в таблице маршрутизации. Это сужает анализ до операционной проверки маршрутов, контроля ёмкости и состояния, перенаправления трафика и восстановления клиентов.
• Внешние измерения ThousandEyes важны, потому что показали различное влияние на клиентов и ценность резервных планов. Инцидент с маршрутизируемой защитой следует оценивать по тому, могут ли клиенты безопасно обойти или вернуть трафик, когда защитный путь нарушен.
• Надёжное подтверждение исправлений должно охватывать ограничители таблиц маршрутизации, заранее проверенный обходной маршрут, уведомление клиентов, масштаб автоматического перенаправления, ресурсы ручной поддержки, безопасность возврата трафика и доказательство того, что путь защиты не может стать более крупным сбоем, чем атака, которую он должен поглотить.

Делегированная защита меняет того, кто управляет непрерывностью

Публичное обновление Akamai,Akamai предоставляет обновление о влиянии на сервис Prolexic DDoS, является основным источником информации об инциденте. Компания сообщила, что в Prolexic Routed 3.0 произошёл сбой сервиса, затронувший часть клиентов. Было сказано, что оповещения начались в 8:47 по восточному времени, трафик пострадавших клиентов автоматически или вручную перенаправлялся командами Akamai, а сервисы были восстановлены в 12:47 по восточному времени. Также было отмечено, что инцидент не был вызван обновлением системы или кибератакой, а причиной стало непреднамеренное превышение значения в таблице маршрутизации.

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

Материалы Akamai о Prolexic описывают сервис как защиту инфраструктуры от DDoS.Страница продукта Prolexic,страница описания продукта ProlexicиPDF-описание продукта Prolexicобъясняют защитную задачу: поглощать, проверять и фильтровать вредоносный трафик до того, как он достигнет источников клиента. Более поздние или актуальные формулировки продукта не следует считать выводом об инциденте 2021 года, но они проясняют модель сервиса, создающую зависимость.

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

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

Маршрутизируемая защита превращает проверку маршрутов в заботу о клиентах

Материалы с описанием сервиса Akamai важны, потому что показывают, как маршрутизируемая защита зависит от механизмов сетевого управления.PDF с описанием услуг Akamaiописывает Prolexic Routed через направление трафика в центры фильтрации Akamai с помощью BGP. Блог Akamai оProlexic и Equinix Cloud Exchangeобсуждает приближение защиты от DDoS к источнику клиента через точки обмена трафиком. Эти материалы не являются отчётами о сбое, но они объясняют, почему управление маршрутизацией и есть сервис.

Сам BGP определён вRFC 4271. GRE, часто используемый в схемах возврата трафика или туннелирования в архитектурах защиты, определён вRFC 2784. Эти стандарты не говорят, что Akamai сделала верно или неверно в 2021 году. Они уточняют техническую лексику: объявления маршрутов, пути трафика, туннели и механизмы возврата — это не фоновые детали. Это поверхность продукта.

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

Проверка маршрутов в этом контексте — это забота о клиенте. Это не просто внутренняя сетевая инженерная проверка. Проверка провайдера защищает выручку клиента, публичные порталы, API, доступ к банковским сервисам, SaaS-приложения и сервисы, важные для экстренных ситуаций. Сбой проверки переносит работу на операционные команды клиента, которые должны решить, ждать, перенаправлять трафик, использовать обход, сообщать пользователям или эскалировать через поддержку.

RFC 7454,Эксплуатация и безопасность BGP, предлагает общие операционные требования к маршрутной политике, фильтрации и операционной гигиене.Действия сетевых операторовMANRS иЗащита интернет-маршрутизацииCISA дают публичное и отраслевое понимание маршрутной дисциплины. Это общие ориентиры, а не выводы об инциденте. Они важны, потому что маршрутизируемые сервисы защиты непосредственно встраивают маршрутную дисциплину оператора в непрерывность бизнеса клиента.

Примечание о типографике

Внешние измерения показывают разный масштаб влияния

Анализ сбоя Akamai Prolexic Routedот ThousandEyes ценен тем, что смотрит снаружи провайдера. Он зафиксировал различия в достижимости, поведение, связанное с пирингом, и неоднородность влияния на клиентов. ThousandEyes позже включила это событие вСемь сбоев, потрясших 2021 год, подчеркнув, что некоторые организации с заранее подготовленными резервными планами смогли уменьшить влияние. Это и есть главный урок ответственности: сбои маршрутизируемой защиты — это не только сбои провайдера; это проверка готовности клиентов к обходу и поддерживаемого провайдером перенаправления.

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

Вторичные публикации, включаяAkamai объясняет сбой сервисом защиты от DDoSот SecurityWeek иОшибка маршрутизации Akamai вызвала массовые сбоиот iTnews, описывали заметные нарушения в публичных сервисах. Такие сообщения могут иллюстрировать масштаб, но их не следует использовать для утверждений об одинаковой длительности или одинаковом восстановлении у всех организаций. Маршрутизируемая защита влияет на клиентов по-разному в зависимости от префиксов, партнёров по маршрутизации, обходных планов, архитектуры приложений и скорости коммуникации.

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

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

Обходной маршрут — совместно спроектированное решение, а не экстренная импровизация

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

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

NIST SP 800-61 Revision 2,Руководство по обработке инцидентов компьютерной безопасности, — это общее руководство, но его жизненный цикл инцидента уместен: подготовка, обнаружение, сдерживание, устранение, восстановление и извлечённые уроки. В маршрутизируемой защите подготовка включает знание того, как безопасно перемещать трафик. Восстановление включает возврат к нормальной защищённой маршрутизации без всплеска, утечки маршрутов или бреши в безопасности.

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

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

Автоматическое перенаправление требует доказанного охвата

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

Автоматическое перенаправление должно проверяться в условиях реалистичного сбоя на стороне провайдера. Недостаточно доказать, что перенаправление работает во время планового упражнения или перехода по запросу клиента. Оно должно работать, когда нарушено собственное состояние маршрутизации провайдера, когда объём оповещений высок, когда многим клиентам нужна помощь одновременно и когда коммуникация о статусе находится под давлением. Система восстановления провайдера DDoS-защиты должна быть рассчитана на одновременное влияние на многих клиентов, потому что сам сервис — это общая инфраструктура.

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

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

Годовой отчёт Akamai по форме 10-K за 2021 год,отчёт в SEC, даёт более широкий контекст бизнес-рисков: Akamai продаёт услуги, которые клиенты используют для производительности, безопасности и доступности. Отчёт не решает вопрос об инциденте Prolexic. Он показывает, почему сбои провайдера в инфраструктуре безопасности и доставки могут становиться вопросами управления для клиентов. Когда роль поставщика — непрерывность, собственные средства непрерывности поставщика являются частью продукта.

Уведомление о статусе должно указывать зависимость и точки принятия решений

Во время инцидента с маршрутизируемой защитой клиентам нужно больше, чем общее уведомление о доступности. Им нужно знать, затронут ли сервис Prolexic Routed или другая функция Akamai, касается ли проблема всех клиентов или части, остаётся ли активной защита от атак, рекомендуется ли обход или он рискован, происходит ли автоматическое перенаправление и что делать клиенту, если его приложение недоступно.

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

Инцидент Prolexic — это случай, где пересекаются статус провайдера и сценарии действий клиента. Если защищённый сервис клиента не работает, клиент должен решить, ждать перенаправления провайдером или активировать собственный резервный путь. Провайдер лучше всего видит неисправность на стороне сервиса. Клиент лучше всего видит бизнес-приоритеты и локальное влияние на приложения. Хорошее уведомление о статусе позволяет этим взглядам быстро встретиться.

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

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

Сервисы фильтрации нуждаются в прозрачности областей отказа

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

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

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

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

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

Оставшиеся неизвестные и вопрос ответственности

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

Того, что известно, достаточно для определения ответственности. Akamai эксплуатировала сервис Prolexic Routed 3.0. Сервис использовал маршрутизируемые пути трафика для защиты клиентов от DDoS-атак. Akamai сообщила, что значение таблицы маршрутизации было непреднамеренно превышено, а пострадавшие клиенты перенаправлялись автоматически или вручную. Внешние измерения показали, что влияние на клиентов различалось и резервные планы имели значение. Клиенты и пользователи понесли последствия того, что зависимость от защиты стала недоступной.

Ответственный вопрос — стала ли маршрутизируемая защита безопаснее после инцидента. Добавила ли Akamai проверки, чтобы пределы состояния маршрутов не превращались в сбои клиентов? Покрыло ли автоматическое перенаправление всех клиентов, как было обещано? Стала ли документация по обходу понятнее? Начали ли уведомления о статусе быстрее указывать точки принятия решений? Улучшились ли процедуры возврата трафика? Получили ли клиенты результаты тестов или руководство по архитектуре? Сократил ли сервис ручное вмешательство при неисправности на стороне провайдера?

Ответ следует оценивать по доказательствам. Заявление провайдера о восстановлении сервисов — это начало. Запись об исправлениях после инцидента, клиентские сценарии, проверенные обходные пути и последующее поведение сервиса — это доказательства. Поскольку защита от DDoS продаётся как непрерывность под враждебным давлением, собственная непрерывность маршрутов провайдера должна соответствовать высокому стандарту.

Итоговый урок не в том, что маршрутизируемая защита от DDoS плоха. Он в том, что делегированная защита создаёт делегированную зависимость. Клиентам нужен защитный путь, но им также нужен безопасный маршрут в обход защитного пути, когда система защиты нарушена. Инцидент Akamai с Prolexic сделал это требование к проектированию видимым. Стандарт ответственности — стало ли это видимое требование долгосрочным контролем клиента, а не однодневным воспоминанием о сбое.

Контроль ёмкости на стороне провайдера должен иметь значение для клиентов

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

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

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

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

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

Клиентам следует классифицировать защищаемые сервисы по риску при обходе

Не каждый защищённый сервис следует обходить одинаково. Публичный маркетинговый сайт, платёжный API, вход в онлайн-банк, медицинский портал, управляющая плоскость SaaS и государственный сервис имеют разное раскрытие при снятии защиты от DDoS. Сценарий обхода, который считает все защищённые префиксы равными, слишком груб. Клиентам следует классифицировать защищённые сервисы по риску остаться на отказавшем пути защиты и по риску ухода с защиты.

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

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

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

Поэтому запись о Prolexic полезна даже для клиентов, которые не пострадали. Любая организация, использующая маршрутизируемую защиту от DDoS, может спросить, актуальна ли её классификация обходов. Можно провести настольное упражнение: Akamai или другой провайдер сообщает о неисправности маршрутизируемой защиты; автоматическое перенаправление работает для одних префиксов, но не для всех; публичные пользователи терпят сбои; атака не видна; что мы делаем в первые пятнадцать минут? Ответ покажет, управляется ли зависимость от защиты.

Защита с несколькими провайдерами может снизить риск и добавить сложности

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

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

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

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

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

Договор о защите должен включать взаимодействие при сбоях

Договоры о защите от DDoS часто сосредоточены на ёмкости защиты, времени реакции, доступности сервиса, поддержке и ценах. Инцидент Prolexic подсказывает дополнительные вопросы. Определяет ли договор ответственность провайдера при нарушении маршрута защиты? Требует ли он автоматического перенаправления там, где оно доступно? Указывает ли, как приоритизируется ручное перенаправление? Определяет ли обязательства клиента по данным о префиксах, конфигурации туннелей, экстренным контактам и одобрению обхода? Включает ли доказательства после инцидента?

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

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

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

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

Подтверждение обратного маршрута должно быть частью гарантий защиты

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

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

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

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

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

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

Коммуникация с клиентами должна отличать сбой от атаки

Клиент защиты от DDoS может обоснованно предположить, что любая проблема доступности рядом с сервисом защиты — это атака. Обновление Akamai сообщило, что инцидент Prolexic Routed не был вызван кибератакой. Это различие ценно операционно. Если клиент считает, что сбой вызван атакой, он может избегать обхода, ужесточать контроль, активировать кризисные коммуникации или эскалировать к руководству по безопасности. Если провайдер может подтвердить внутреннюю проблему маршрутизации, путь решений клиента меняется.

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

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

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