Утечка маршрутов Google в 2018 году показала разрыв между контрактами на маршрутизацию и реальным контролем

Кратко

• 12 ноября 2018 года маршруты, связанные с сервисами Google, были ошибочно переданы нигерийским провайдером MainOne в China Telecom, а затем распространены другими операторами. Часть трафика, направлявшегося к Google, пошла по неожиданным путям, и для некоторых пользователей сервисы стали недоступны.
• Инцидент отличается от перехвата YouTube компанией Pakistan Telecom в 2008 году. Здесь ключевая проблема подотчётности заключалась не в национальной блокировке, экспортированной как более специфичный маршрут с чужим происхождением, а в несоответствии контракта и контроля: маршруты, полученные в рамках одного отношения, вышли за его пределы в другие.
• Публичные данные говорят скорее о случайной ошибке конфигурации, чем о доказанном успешном перехвате содержимого. По сообщениям, Google заявил, что затронутый трафик был зашифрован и у компании не было оснований считать сервисы скомпрометированными; независимые наблюдатели при этом расценивали путь маршрутизации как серьёзный риск для доступности и слежки.
• Валидация происхождения RPKI не является полным ответом для этого класса сбоев, поскольку затронутые маршруты могли по-прежнему выглядеть исходящими из легитимной AS Google. Утечки маршрутов требуют фильтрации клиентских и пиринговых маршрутов, средств контроля с учётом отношений, лимитов префиксов, мониторинга, координации и более поздних механизмов, таких как BGP Roles.
• Урок подотчётности в том, что коммерческие соглашения о пиринге и транзите не обеспечивают себя сами. Операторы должны превращать деловые отношения в политики маршрутизаторов и внешне проверяемые средства контроля до того, как утёкший маршрут станет глобальным сбоем.

Доказательная база и как она используется

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

Инцидент был о границах, которые маршрутизаторы не могут определить сами

Утечку маршрутов Google 2018 года легко свести к привычной фразе: BGP хрупок. Эта фраза верна, но недостаточно точна. Более точный урок в том, что в интернете существует множество деловых отношений, которые программное обеспечение маршрутизации не может определить само, если операторы не закодируют их. Пир может передавать маршруты, которые должны оставаться локальными. Транзитный провайдер может получать маршруты, которые не должен принимать от этого соседа. Маршрут может сохранять корректный AS происхождения и при этом идти по пути, нарушающему коммерческие и операционные ожидания.

Отчёты Cloudflare, ThousandEyes и Internet Society сходятся в главном. MainOne имел связь с Google через пиринговое отношение в Лагосе. Маршруты, связанные с Google, вышли из этого отношения в сторону China Telecom. China Telecom распространил их дальше, и появились пути через TransTelecom, NTT и другие сети. Пользователи, пытавшиеся достичь сервисов Google, попадали на пути, у которых не было достаточной ёмкости, политики или ожидаемой фильтрации для этого трафика. Часть трафика отбрасывалась, и для некоторых пользователей сервисы стали недоступны.

Это не тот же механизм, что перехват YouTube компанией Pakistan Telecom. В 2008 году Pakistan Telecom объявил более специфичный маршрут для адресного пространства YouTube из чужого AS происхождения, а PCCW распространил его. В 2018 году, согласно важным публичным анализам, произошла утечка маршрутов: маршруты с происхождением от Google распространялись за пределы предусмотренного отношения. Происхождение могло выглядеть легитимным, но путь всё равно был ошибочным. Это различие важно, потому что оно меняет средства контроля, которые помогли бы. Валидация происхождения может отклонить ложное происхождение.

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

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

Именно поэтому это событие относится к области управления. Сбой был не загадочным стихийным бедствием. Это было несоответствие между технической конфигурацией, деловыми отношениями, полномочиями на маршруты, мониторингом и эскалацией. У каждой организации на пути был более узкий операционный обзор, чем глобальный эффект. MainOne мог ошибиться при экспорте. China Telecom мог принять и распространить маршруты. Другие провайдеры могли предпочесть или передать эти пути. Google мог обнаружить проблему, информировать о ней и защищать конфиденциальность на прикладном уровне, но не мог напрямую переписать политику импорта каждого внешнего оператора.

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

Многие обсуждения безопасности маршрутизации начинаются с угонов, потому что объявления с ложным происхождением объяснять проще. Тот, кто не владеет префиксом, по сути говорит: направляйте этот трафик мне. Валидация происхождения маршрутов RPKI создана именно для этого класса: владелец ресурса публикует авторизацию происхождения маршрута (ROA), и валидирующие сети могут отклонять маршруты, чьё происхождение AS или длина префикса не совпадают. Это важное средство контроля. Событие с Google в 2018 году показывает его границы.

Internet Society ясно сформулировала это в своём публичном анализе: в этом сценарии префиксы по-прежнему легитимно исходили из корректной AS, поэтому промежуточным сетям трудно заблокировать утечку, используя только валидацию происхождения. Маршрут мог иметь валидное происхождение и при этом быть недопустимым экспортным отношением. Поэтому утечка маршрута — это не просто угон с более мягкой формулировкой. Это сбой отношений: маршруты распространяются за пределы своей предусмотренной области.

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

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

Более поздние технические разработки, такие как BGP Roles и атрибут Only-to-Customer, пытаются сделать деловые отношения видимыми для протокола маршрутизации. В 2018 году эти механизмы не были завершённым универсальным средством контроля, и статья не применяет их задним числом как обязательный стандарт. Их значимость объяснительная: они появились потому, что операторы осознали: многие разрушительные утечки — это сбои политики пути, а не авторизации происхождения. Отрасли были нужны способы сделать утверждение «этот маршрут не должен идти туда» проверяемым машиной.

China Telecom стал усилителем распространения маршрутов

В публичных источниках MainOne фигурирует как источник утечки, но глобально значимым событие стало потому, что другие провайдеры приняли и распространили маршруты. China Telecom занимает центральное место в публичных описаниях, потому что получил утёкшие маршруты Google и передал их дальше. Эту роль нужно описывать аккуратно. Публичные источники поддерживают версию случайной или ошибочной обработки маршрутов; они не доказывают успешную операцию по перехвату трафика. Но для подотчётности намерение не требуется. Транзитный провайдер может нанести серьёзный вред, поверив клиентскому или пиринговому маршруту, который должен был отфильтровать.

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

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

Публичная видимость пути маршрутизации сделала роль распространения трудно игнорируемой. ThousandEyes описал пути через China Telecom и TransTelecom. Cloudflare зафиксировал необычную маршрутизацию и влияние на сервисы. Новостные сообщения обращали внимание на прохождение трафика через Китай и Россию, поскольку этот путь вызывал очевидные политические опасения и вопросы о слежке. Даже если трафик был зашифрован и не было показано его компрометации, сам маршрут подрывал ожидания клиентов о том, где будет идти трафик и останется ли он доступным.

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

У Google были обязанности по устойчивости, но не было одностороннего контроля

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

Обязанности Google в таком событии включают мониторинг маршрутов, публикацию ROA, корректные объекты IRR, эскалацию к провайдерам, информирование клиентов, экстренную инженерию трафика и послемероприятийную фиксацию доказательств. Платформа масштаба Google не может остановить каждую внешнюю утечку, но может сократить время до обнаружения и восстановления. Она также может проектировать сервисы так, чтобы обходной путь не раскрывал пользовательский контент молча. Шифрование, гигиена сертификатов, резервирование сервисов и сетевая телеметрия — часть этого пакета устойчивости.

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

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

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

Контрактам нужны исполнимые средства контроля

Фраза «несоответствие контракта и контроля» описывает модель сбоя, встречающуюся во всей интернет-инфраструктуре. Стороны могут иметь контракты, определяющие, кто является пиром, клиентом или провайдером. Но маршрутизаторы применяют маршрутную политику, а не юридические намерения. Если маршрутная политика не воплощает отношения, контракт становится аргументом после факта, а не превентивным контролем. Утечка Google в 2018 году сделала этот разрыв видимым для обычных пользователей, потому что изменение пути сломало высокозаметные сервисы.

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

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

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

Главный вывод в том, что утечка маршрутов Google в 2018 году была событием подотчётности об управляемости отношений. Ошибка MainOne имела значение. Распространение China Telecom имело значение. Принятие маршрутов другими сетями имело значение. Устойчивость и коммуникация Google имели значение. Публике пришлось пережить сбой маршрутной политики как отключение сервиса. Урок устранения не только в абстрактно «лучшей гигиене BGP»; это превращение контрактов и ожиданий в маршрутные средства контроля, которые заметно отказывают и быстро восстанавливаются.

Путь выглядел политическим, потому что был операционно ошибочным

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

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

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

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

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

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

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

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

Пиринг и транзит — это деловые отношения с техническими рычагами

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

Это отображение должно быть реализовано в конфигурации маршрутизаторов и системах валидации. Оно включает явную политику импорта того, что сосед может передавать, явную политику экспорта того, куда эти маршруты могут идти, фильтры префиксов и AS-PATH, лимиты маршрутов, валидацию происхождения RPKI там, где она применима, теги отношений, мониторинг внезапного расширения маршрутных наборов и полномочия на аварийное отключение. Ключевое слово — явная. Умолчания, допущения и устные знания недостаточны, когда ошибка конфигурации может сделать Google недоступным.

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

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

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

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

Почему валидация происхождения всё равно была уместна

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

Ограничение точное. Если маршрут по-прежнему исходит из авторизованной AS Google, компонент происхождения может быть валидным, при этом путь остаётся неприемлемым. В этом случае RPKI говорит, что происхождение разрешено, но не то, что MainOne, China Telecom, TransTelecom, NTT или любой другой сегмент пути должен нести этот маршрут в рамках такого отношения. Валидация пути и предотвращение утечек требуют дополнительных средств контроля. Поэтому важны RFC 9234 и механизмы с учётом отношений. Они решают другую часть проблемы доверия.

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

RPKI также меняет стимулы вокруг документации. Платформа вроде Google должна поддерживать корректные ROA, но также маршрутные объекты, пиринговые политики, контакты провайдеров и внешний мониторинг. Провайдер вроде China Telecom должен валидировать происхождение, но также фильтровать в соответствии с отношениями. Пир вроде MainOne должен не допускать утечки маршрутов, полученных от пиров, в транзит. Эти средства контроля дополняют, а не заменяют друг друга.

Поэтому читатель должен вынести многослойную модель. RPKI отвечает за авторитет происхождения. Фильтры префиксов и AS-PATH отвечают за ожидаемые полномочия клиентов и пиров. BGP Roles и OTC могут кодировать направление отношений. Мониторинг обнаруживает отклонения. Людская координация исправляет то, что автоматизация не может безопасно решить. Контрактный язык и управленческие метрики поддерживают слои в рабочем состоянии. Событие с Google вскрыло пробел в этой многослойной модели, а не бесполезность её построения.

Лучший публичный отчёт об устранении разделил бы каждую точку контроля

Полезный послемероприятийный отчёт по утечке 2018 года идентифицировал бы каждую точку контроля на пути. По MainOne — какой маршрутный набор был получен от Google, какая политика должна была предотвратить экспорт, что изменилось, когда началась утечка, когда она была обнаружена и как исправлена. По China Telecom — почему утёкший маршрут был принят, существовали ли клиентские или пиринговые фильтры, сработали ли лимиты маршрутов и когда экспорт остановился. По нижестоящим провайдерам — какие пути были выбраны и почему.

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

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

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

Утечка Google 2018 года остаётся полезной, потому что делает несоответствие контракта и контроля видимым. Было недостаточно, что деловые отношения подразумевали: маршрут не должен идти этим путём. Маршрутизаторам нужна была исполнимая политика. Мониторингу нужно было увидеть отклонение. Людям нужны были доступные контакты. Публике нужны были доказательства, что утечка локализована и что шифрование ограничивает риск для конфиденциальности. Это и есть стек управления, который вскрыл инцидент.

Что читателю решить по поводу контрактов на маршрутизацию

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

Для платформ решение состоит в том, чтобы считать внешнюю маршрутизацию частью устойчивости сервиса. Провайдер может владеть отличными дата-центрами, сильным TLS и укреплёнными приложениями и при этом стать недоступным, если удалённые сети предпочтут утёкший путь. Это значит, что глобальный мониторинг маршрутов, учения по эскалации к провайдерам, гигиена ROA, гигиена маршрутных объектов и коммуникация с клиентами должны находиться рядом с обычной инженерией доступности. «Интернет сломался за пределами нашей границы» может быть описательно верно, но клиентам всё равно нужны доказательства обнаружения, диагностики и восстановления.

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

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

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

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

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

Инцидент Google/MainOne — напоминание, что владельцы приложений наследуют часть маршрутной зависимости, независимо от того, трогают ли их команды политику маршрутизаторов.

Подотчётность начинается, когда эта унаследованная зависимость названа, измерена и закреплена за владельцем контроля, а не рассматривается как непознаваемая погода интернета.

Этот владелец должен также контролировать язык, используемый во время сбоя. Утечки маршрутов могут звучать как отдалённые мелочи операторов связи, но вопрос клиента непосредственный: могут ли пользователи достичь сервиса, заслуживает ли путь доверия, что изменилось и когда всё вернётся в норму? Сильный отчёт об инциденте различает потерю доступности, неожиданный транзитный путь, статус шифрования, подозрение на компрометацию и устранение. Запись Google показывает, почему эти различия важны. Заверение, что трафик был зашифрован, важно, но не отвечает на вопрос о доступности.

Отзыв маршрута может восстановить сервис, но не объясняет, какое отношение отказало.

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

Главный вывод

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