Резюме

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

Сбой, который видели клиенты

Первое полезное описание инцидента — это не схема протокола. Это опыт людей, пытавшихся пользоваться сервисами. TechCrunch сообщил, что проблемы появились примерно в 14:30 по тихоокеанскому времени 9 июня 2020 года и переросли в масштабный сетевой сбой. Пострадали размещённые сервисы. Главная страница статуса IBM во время события возвращала ошибку внутреннего сервера, а отдельно размещённая страница статуса другого сервиса IBM показывала масштабное влияние на сеть. В прямом репортаже причина ещё не была известна. Эта неопределённость важна: наблюдение масштабного отказа устанавливает влияние, а не причину.

Запись об инциденте Zello даёт более конкретное представление с точки зрения зависимого клиента. Компания открыла инцидент в 18:03 по центральному летнему времени. Zello сообщила, что большинство пользователей не могли войти или переподключиться, уже подключённые пользователи теряли связь, административные консоли были недоступны, и пострадали четыре названных сервиса Zello. Zello отметила свой инцидент как устранённый в 20:22 в том же часовом поясе. Эти факты описывают сервис Zello и его пользователей. Они не являются полным подсчётом клиентов IBM Cloud и не задают единое время для каждого региона и продукта IBM.

CRN, издание о технологиях, сообщило о похожих проблемах с управлением и видимостью у партнёров и клиентов IBM. Люди не могли получить доступ к средам, консолям или экранам статуса. Издание отнесло первый публичный твит IBM Cloud к 20:26 восточного времени, а более поздний твит о восстановлении всех сервисов — к 21:54. Эти метки времени помогают реконструировать публичные коммуникации, но не превращают сложное восстановление в единый мировой старт и финиш. Облачная сеть может возвращаться поэтапно по мере изменения политик маршрутизации, снижения перегрузки и повторного установления соединений разными сервисами.

Более позднее уведомление IBM сообщило причину, на которую ссылается компания. Как сохранили The Register и CRN, IBM заявила, что внешний сетевой провайдер направил в IBM Cloud поток некорректных маршрутов. IBM сообщила, что возникшая перегрузка затронула облачные сервисы и дата-центры. Компания также сообщила, что сетевые специалисты скорректировали политики маршрутизации, все сервисы были восстановлены, приняты меры по снижению последствий, а работа по выяснению первопричины не выявила потери данных или проблем кибербезопасности.

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

Позже Zello описала механизм с точки зрения пострадавшего клиента. В её отчёте говорится, что внешний провайдер ввёл большое количество маршрутов. Серверы в IBM Cloud затем отправляли исходящий IPv4-трафик на некорректные адреса назначения, что способствовало сильной перегрузке и потере сервиса. Internet Protocol version 4 (IPv4) — широко используемая система адресации, при которой каждое доступное устройство или сервис использует числовой адрес.

Описание Zello полезно, потому что связывает состояние маршрутизации — набор путей, которые сеть в данный момент считает действующими и использует, — с последствием для приложения. Это по-прежнему опубликованный отчёт Zello, а не замена закрытым записям IBM и провайдера.

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

Как маршрутное сообщение может привести к отказу облака

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

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

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

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

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

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

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

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

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

Событие также не следует называть распределённой атакой типа «отказ в обслуживании» (DDoS) — преднамеренной попыткой перегрузить сервис трафиком из многих источников. Перегрузка имела место, но сама по себе перегрузка не доказывает враждебных намерений. IBM сообщила, что её работа не выявила проблем кибербезопасности. Это отрицательное заключение, сделанное самой компанией, а не доказательство отсутствия любых возможных последствий для безопасности, однако его достаточно, чтобы отвергнуть неподтверждённое объяснение атакой.

Граница провайдера — это место применения средств контроля

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

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

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

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

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

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

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

Что могут и чего не могут установить стандарты и рекомендации

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

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

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

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

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

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

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

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

Доступность, администрирование и статус отказали одновременно

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

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

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

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

Могут ли редакторы статуса публиковать сообщения через путь, который остаётся доступным за пределами пострадавшего облачного региона или сети?

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

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

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

Хронология, сохраняющая атрибуцию

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

Zello открыла свой клиентский инцидент в 18:03 по центральному летнему времени. Она задокументировала массовую невозможность войти или переподключиться, потерю связи у уже подключённых пользователей, недоступные административные консоли и четыре пострадавших сервиса. Это даёт окно с точки зрения пострадавшего клиента, а не полный знаменатель инцидента IBM.

CRN сообщило о публичном обновлении IBM в 20:26 восточного времени и обновлении о восстановлении в 21:54. Zello отметила свой инцидент как устранённый в 20:22 по центральному летнему времени. С учётом часовых поясов эти записи показывают пересекающиеся, но не идентичные наблюдения. Их не следует насильно сводить к единой поминутной универсальной последовательности, потому что каждый источник измерял разные сервисы или коммуникационные поверхности.

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

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

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

Какие доказательства должна сохранять проверка границы провайдера

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

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

Запись о маршрутах должна сохранять достаточно контекста, чтобы различать несколько возможностей. Добавил ли провайдер много новых законных префиксов? Объявил ли он пути за пределами коммерческих отношений? Привело ли обновление политики к тому, что ранее отклонённые маршруты стали допустимыми? Оставалось ли содержимое стабильным, пока темп обновлений резко вырос? Изменил ли ответ IBM предпочтение, отклонил ли набор, закрыл ли сессию или перенаправил ли трафик другому провайдеру? Это вопросы, а не утверждения о том, что произошло.

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

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

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

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

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

Что доказывают публичные данные

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

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

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

Прямая запись справочника BTW Media — индекса организационных идентификаторов — подтверждает связь с International Business Machines Corporation. Сообщения о событии называют IBM Cloud пострадавшим оператором. Справочник не устанавливает, какое юридическое лицо IBM подписало соответствующий договор с провайдером, и ничего не говорит о неназванном провайдере. Записи об идентичности помогают читателям связать организацию; они не реконструируют работающую сеть.

Что остаётся неизвестным

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

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

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

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

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

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

Превращение неизвестного в вопросы для подтверждения надёжности

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

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

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

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

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

Подотчётность без выдуманных обвинений

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

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

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

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

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

Источники

  1. https://www.theregister.com/2020/06/11/ibm_blames_external_network_provider/
  2. https://techcrunch.com/2020/06/09/ibm-cloud-suffers-prolonged-outage/
  3. https://www.crn.com/news/cloud/ibm-blames-massive-cloud-outage-on-third-party-network-provider
  4. https://status.zellowork.com/issues/5ef227ab4a0ebd6da0cb113e
  5. https://www.rfc-editor.org/rfc/rfc7454.html
  6. https://btw.media/en/directory/international-business-machines-corporation-united-states-of-america-the