Пожар в OVHcloud показал: локализация данных — не разделение при катастрофах

Краткое содержание

• Пожарная сигнализация на площадке OVHcloud в Страсбурге сработала в 00:35 10 марта 2021 года. Пожар начался в энергетических помещениях на первом этаже SBG2, уничтожил это здание, повредил четыре из двенадцати залов SBG1 и привёл к отключению электроэнергии на всём кампусе. SBG3 и SBG4 не были охвачены первоначальным огнём, однако их сервисы оставались недоступными: потребовались обесточивание, проверка безопасности, очистка и поэтапный перезапуск. Никто не погиб и не пострадал.
• Французское расследование по промышленной безопасности не установило точную причину почти одновременных электрических отказов, зафиксированных у ИБП и связанных с ним свинцовых аккумуляторов. Оно выявило факторы распространения и реагирования: отсутствие автоматической системы пожаротушения во всех пяти зданиях в Страсбурге, быстрое распространение дыма из-за открытой конструкции SBG2, рассчитанной на охлаждение, ограниченный запас воды для пожаротушения и сложное обесточивание всей площадки. Работающее обнаружение, ночной персонал, противопожарные преграды, защитившие SBG3, и прибытие мощного франко-германского пожарного судна ограничили более тяжёлые последствия.
• Потеря доступности и безвозвратная потеря данных — разные исходы. OVHcloud сообщила о нарушении работы примерно 65 000 клиентов и 120 000 сервисов, а Netcraft зафиксировала отключение примерно 3,6 млн сайтов на 464 000 доменах. OVHcloud заявила, что многие клиенты, потерявшие данные, не выбрали дополнительное резервное копирование. Это не снимает вопрос об ответственности: в собственном регистрационном документе OVHcloud говорилось, что предлагаемые резервные копии могут храниться в том же или другом дата-центре, а более позднее апелляционное решение касалось клиента, чья платная автоматическая резервная копия была уничтожена в том же здании, что и производственные данные.
• Инцидент вскрыл категориальную ошибку при закупке облачных услуг. Суверенитет данных, юридическая юрисдикция, задержка, доступность, резервное копирование и аварийное восстановление связаны между собой, но не взаимозаменяемы. Хранение данных во Франции или в Европейском союзе может удовлетворять политике локализации и при этом допускать, чтобы производственные и резервные копии находились в одной физической зоне риска. И наоборот: географически удалённая копия может оставаться в том же правовом пространстве и под тем же европейским контролем.
• OVHcloud сообщила о масштабных изменениях после пожара: более широкое применение автоматического пожаротушения, усиление противопожарных отсеков, отдельные энергетические помещения, дистанционное отключение электричества, аудит площадок, совместная работа с пожарными службами и новые варианты мультизонального и удалённого резервного копирования. Ответственное закрытие вопроса, однако, требует доказательств по каждому сервису и каждой площадке: полнота внедрённых мер, независимая проверка, реалистичные учения по пожару и обесточиванию, заявленные места хранения резервных копий, успешные тесты восстановления и подтверждение того, что восстановление клиента не зависит от пострадавшего региона или той же плоскости управления.

Физический пожар стал событием об ответственности в облаке

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

Страсбург сделал эту физическую цепочку видимой. Ранним утром 10 марта 2021 года огонь уничтожил SBG2 — одно из зданий кампуса OVHcloud в Порт-дю-Рен. SBG1 была разрушена частично. Два других дата-центра на площадке были остановлены, хотя первоначальное сообщение компании описывало их как неповреждённые. Ущерб распространился как минимум по трём различным механизмам: оборудование было физически уничтожено; оборудование в соседних зданиях подверглось воздействию тепла, дыма, воды или неопределённости; а исправное оборудование стало недоступным, когда площадку пришлось обесточить и привести в безопасное состояние.

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

Наиболее авторитетная публичная реконструкция —отчёт о расследованиифранцузского Бюро расследований и анализа промышленных рисков (Bureau d'enquêtes et d'analyses sur les risques industriels, BEA-RI) от мая 2022 года. Его мандат — профилактика, а не распределение гражданской или уголовной ответственности. Эта граница важна. Отчёт может зафиксировать наблюдения, возможные причины, способствующие факторы и рекомендации по безопасности. Его нельзя превратить в судебный вывод о том, что каждый выявленный недостаток был проявлением халатности или что один недостаток юридически стал причиной ущерба конкретного клиента.

Анализ ответственности ставит смежный, но более широкий вопрос: какие субъекты обладали полномочиями над условиями, в которых один ночной сбой оборудования превратился в отключение нескольких зданий, длительное восстановление и необратимые потери клиентов? OVH контролировала проектирование и эксплуатацию площадки, предлагаемые продукты, точность их описаний и реагирование. Клиенты контролировали классификацию рабочих нагрузок, архитектуру, многие параметры сервисов и независимые копии. Регуляторы и профессиональные организации контролировали часть минимальных требований. Ни одна из этих ролей не отменяет другие.

Что устанавливают доказательства, а что нет

В отчёте BEA-RI первый сигнал тревоги датирован 00:35. Охранник добрался до энергетического помещения SBG2 в 00:37 и обнаружил густой чёрный дым. Здание было эвакуировано в 00:39, пожарно-спасательная служба Нижнего Рейна вызвана в 00:42, первые расчёты прибыли в 00:59. На публичной странице инцидента OVH время начала пожара указано как 00:47. Это различие стоит сохранить, а не сводить к одной метке времени: расследование по безопасности имело доступ к сигналам и эксплуатационным записям, тогда как страница компании была публичным маркером инцидента.

Аварийное электропитание SBG2 было отключено в 01:13, а SBG1, SBG3 и SBG4 — в 01:28. Пожарные наблюдали электрическое дуговое замыкание и сдерживали масштабную подачу воды, пока риск не удалось взять под контроль. К 01:42 огонь распространился по всему первому этажу. Около 02:00 пожарные сообщили о повсеместном охвате SBG2 огнём. Мощное пожарное судно EUROPA прибыло около 03:00, используя прилегающий водный путь. Пожар был потушен в 10:02, вмешательство считалось завершённым в 18:13.

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

Эта сдержанность часто теряется в пересказах, утверждающих, что пожар «вызвали» протекающая система охлаждения или недавно обслуживавшийся ИБП.Официальная запись об инциденте во французской базе ARIA— полезное подтверждение обстановки в техническом помещении и хода реагирования, но она не превращает правдоподобный механизм в доказанную первопричину. Достоверный рассказ должен констатировать: ранние электрические события и зона очага известны, а причина этих событий в опубликованном отчёте BEA-RI осталась невыясненной.

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

Здание обнаружило опасность, но не смогло её сдержать

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

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

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

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

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

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

Вофициальном ответе на рекомендации BEA-RIOVH утверждала, что отсутствие автоматического пожаротушения не нарушало нормативных требований, а отраслевые руководства, на которые ссылалось расследование, появились уже после проектирования SBG2. Это значимо для правового и комплаенс-анализа. Но на этом операционная ответственность не заканчивается. Минимальное соответствие требованиям спрашивает, обязывало ли правило внедрить меру. Устойчивость спрашивает, была ли мера необходима для реалистичного сценария с тяжёлыми последствиями. Само решение OVH после пожара распространить автоматическое пожаротушение на площадки, где его не было, — свидетельство того, что подход к риску изменился.

Четыре здания не означали четыре независимых исхода

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

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

Первое восстановление не было линейным. SBG3 заработала 18 марта. Вечером 19 марта дым был обнаружен в обесточенном аккумуляторном помещении SBG1. OVH в порядке предосторожности снова остановила SBG1 и SBG4 и пересмотрела график перезапуска. Восстановление сервисов возобновилось 22 марта. К концу марта bare-metal серверы SBG4 стали доступны, сервисы SBG3 возвращались постепенно, в процентном выражении, а оборудование из SBG1 всё ещё очищали, ремонтировали и перевозили.

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

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

Чтобы оценить последствия, нужен не один показатель

Внешние измерения Netcraftпоказали: в период измерений офлайн находились около 3,6 млн сайтов на 464 000 отдельных доменах, а более 18 % IP-адресов, отнесённых в последнем обзоре к OVH, не отвечали. Это взгляд на потерю доступности в масштабе всего интернета. Он учитывает размещённые поддомены и нижестоящие хостинговые схемы, поэтому сильно превышает число клиентов OVH.

65 000 пострадавших клиентов и 120 000 сервисов OVH описывают коммерческие и продуктовые отношения. Ни одна из этих цифр не говорит, сколько конечных пользователей не могли получить доступ к сервису, сколько компаний потеряли канал выручки и сколько наборов данных оказались невосстановимыми. Всообщениях Reutersтого времени среди нарушений упоминались правительственные порталы, банки, магазины, новостные сайты и другие онлайн-сервисы. Эти примеры показывают разнообразие последствий, а не полную картину.

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

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

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

Сведение всех этих случаев к фразе «у некоторых клиентов не было резервной копии» мешает точной оценке ответственности.

Резервная копия — это обещание о будущем восстановлении

Врегистрационном документе OVHcloud за 2021 годговорилось, что услуги резервного копирования для большинства клиентов были опциональными платными, а часть клиентов столкнулась с безвозвратной потерей данных. Там также сообщалось, что клиенты могли выбирать из предложенных вариантов, в которых резервные данные хранились либо в том же дата-центре, либо в другом. Некоторые управляемые провайдером сервисы, включая почту, были нарушены лишь незначительно и данных не потеряли, потому что OVH создавала для них резервные копии.

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

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

1. Охват:данные, состояние системы, конфигурации, хранилища учётных данных, ключи, программное обеспечение и внешние зависимости, включённые или сознательно исключённые.
2. Точка:максимально допустимый возраст восстановленных данных, обычно выражаемый как целевая точка восстановления, и глубина хранения, необходимая для случаев повреждения или позднего обнаружения проблемы.
3. Изоляция:физические, логические, административные сбои и сбои провайдера, которые не могут уничтожить или изменить все копии одновременно.
4. Доступ:учётные данные, ключи шифрования, каталоги, инструменты, сетевые пути и уполномоченные люди, необходимые для получения копии во время кризиса.
5. Время:проверенная продолжительность получения мощностей, передачи данных, пересборки зависимостей, сверки транзакций и возврата бизнес-функции в приемлемое состояние.
6. Доказательства:мониторинг завершения резервного копирования, проверки целостности, выборочные восстановления, полные учения сервисов и сохранённые записи о результатах.

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

Французский регулятор защиты данных CNIL теперь прямо формулирует этот физический урок вруководстве по безопасности резервного копирования: храните хотя бы одну копию на географически отдельной площадке, изолируйте хотя бы одну копию офлайн, защищайте резервные копии на том же уровне безопасности, что и производственные данные, и тестируйте целостность и восстановление.Руководство CNIL по облачной безопасностирекомендует клиентам проверять, что места хранения резервных копий облачного провайдера географически удалены от его дата-центров. Эти материалы 2024 года — более поздние рекомендации, а не доказательство точной договорной обязанности по каждому сервису OVH в 2021 году. Зато они — чёткий ориентир для сегодняшней практики.

Дело Bati Courtage придало формулировкам продукта юридическое значение

Спор одного клиента придал границе резервного копирования юридическую конкретность. Компания France Bati Courtage использовала виртуальный частный сервер OVH и платную опцию автоматического резервного копирования. Согласно материалам дела, в апреле 2021 года OVH сообщила ей, что резервная копия также полностью и безвозвратно уничтожена, поскольку копии хранились в том же здании, что и основной сервер. Клиент требовал миллионы евро за потерю данных и заявленный сопутствующий ущерб бизнесу.

Исход изменился при апелляции. Врешении от 24 апреля 2025 годаАпелляционный суд Дуэ подтвердил наличие договорного нарушения: OVH не смогла обеспечить клиенту доступ к созданной резервной копии и сохранить её для получения. Суд не поддержал отдельное требование клиента о вине OVH в том, что сервисы не были размещены в географически изолированных местах. Он также оставил в силе прежний вывод о том, что в этом споре OVH не совершила грубого проступка и не допустила серьёзных нарушений пожарной безопасности, отклонил ссылку OVH на форс-мажор, применил соответствующие ограничения ответственности и снизил присуждённую сумму до 1 800,48 евро.

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

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

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

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

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

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

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

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

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

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

Конечным клиентам нужно знать эту цепочку.

Действующее руководство ANSSI по основам резервного копированияпревращает эти обязанности в практические меры. Оно требует целевых точек и сроков восстановления, правила 3-2-1, как минимум одной офлайн-копии или надлежащим образом защищённой внешней копии, регулярных тестов восстановления, порядка восстановления и защиты установочных носителей и конфигураций приложений. Для внешнего резервного копирования ANSSI обращает внимание на размещение в ЕС, поведение провайдера при репликации, шифрование под контролем клиента и срок получения данных. Это полезное напоминание: физическую устойчивость, киберизоляцию, суверенитет и восстанавливаемость нужно проектировать вместе.

Локализация отвечает на несколько разных вопросов

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

«Где находятся данные?» может означать как минимум пять вещей:

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

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

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

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

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

Концентрация — свойство приложения, а не только рынка

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

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

Другая может остаться у одного провайдера, но использовать действительно отдельные регионы, выгружаемые резервные копии, независимый DNS и офлайн-материалы для восстановления.

Финансовое регулирование всё яснее формулирует эту сохраняющуюся ответственность клиента.Руководящие принципы Европейского банковского управления (EBA) 2019 года по аутсорсингутребуют, чтобы подпадающие под них учреждения управляли рисками аутсорсинга и сохраняли способность к надзору, а не превращались в пустые оболочки. Принятый позже Регламент ЕС об операционной устойчивости цифрового сектора (Digital Operational Resilience Act, DORA) требует, чтобы финансовые организации поддерживали и периодически тестировали механизмы резервного копирования, восстановления и аварийного воспроизведения.Требования его статьи 12включают физическую и логическую сегрегацию, когда организации восстанавливают резервные данные с использованием собственных систем.

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

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

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

Восстановление должно быть доказано со стороны клиента

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

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

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

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

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

Меры OVHcloud после пожара затронули физическую цепочку

В ответе OVH на рекомендации BEA-RI описана масштабная программа «Hyper Resilience». Компания сообщила, что усилит обнаружение, распространит автоматическое пожаротушение на объекты, где его не было, перепроектирует зоны и противопожарные отсеки, повысит базовый предел огнестойкости с 60 до 120 минут, а на новых площадках разместит энергетические и аккумуляторные помещения вне зданий дата-центров, там, где это возможно, — и на существующих. Планировалось дистанционное отключение электричества по зонам, чтобы реагирующие подразделения могли изолировать опасность, не отключая без необходимости незатронутые участки.

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

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

Универсальный регистрационный документ OVHcloud за 2025 годсообщает, что группа продолжила картирование рисков площадок в 2025 году, и описывает Hyper Resilience как повышение безопасности дата-центров сверх рекомендаций регуляторов и страховщиков. В нём также зафиксирован действующий резерв на последствия страсбургского пожара, включая иски об ответственности. Это свидетельство долгосрочной программы и её финансового отражения, а не независимый сертификат о завершении работ по каждой площадке.

Ответственное закрытие вопроса потребовало бы публикации или предоставления квалифицированным клиентам и аудиторам матрицы мер защиты: на каких площадках автоматическое пожаротушение есть во всех профильных энергетических и ИТ-помещениях; где установлены отсеки с пределом огнестойкости 120 минут; где аккумуляторные вынесены наружу; в каких зонах действует дистанционно управляемое обесточивание; какие требования к расходу воды проверены; какие учения с пожарными проводились; какие замечания остаются открытыми; и какая независимая сторона подтвердила работу. Заявление о политике — начало устранения недостатков.

Полнота охвата и проверка в условиях противодействия показывают, работает ли оно.

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

Дизайн продуктов изменился, но устойчивость по-прежнему решает конфигурация

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

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

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

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

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

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

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

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

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

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

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

Чего требовать от сервиса, прежде чем назвать его устойчивым

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

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

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

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

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

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

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

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

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