Резюме

  • PREMI3NS больше не является лишь анонсированным будущим сервисом. S3NS вывела его в общий доступ 16 октября 2025 года, а ANSSI квалифицировала сервис IaaS, PaaS и CaaS по стандарту SecNumCloud 3.2 17 декабря 2025 года; согласно решению, квалификация действует до 17 декабря 2028 года.
  • Его физическая география сконцентрирована, но сознательно разделена: автономный регионu-france-east1имеет три зоны, каждая из которых связана с одним из трёх независимых дата-центров во Франции. В публичной продуктовой документации указано, что функции, требующие нескольких регионов, недоступны.
  • Thales Cloud Sécurisé является квалифицированным поставщиком, а S3NS — коммерческим обозначением. Компания действует по французскому праву и контролируется Thales; её отчётность за 2024 год зафиксировала долю Thales в 95% и Google в 5%, а действующий устав отводит пять голосующих мест в совете директоров представителям Thales и одну позицию наблюдателя без права голоса другому акционеру.
  • Публичные данные убедительно подтверждают французский контроль, действующий сервис, обширный каталог управляемых услуг и проектирование на уровне зон. Они не раскрывают трёх операторов объектов, точные площадки, коммунальные подключения, контракты с операторами связи, топологию магистральной сети, запасы запчастей или обязательства по времени реакции службы поддержки.
  • Итоговая оценка доказательств — средняя. У S3NS необычайно сильные регуляторные и эксплуатационные свидетельства для молодого облака, но покупатель не может сделать вывод о восстановлении всего региона, пригодной резервной мощности или быстром физическом ремонте только на основании квалификации SecNumCloud или карты трёх зон.

Облачное обещание стало действующим сервисом

S3NS теперь следует оценивать как действующего поставщика инфраструктуры, а не как проект, который Франция впервые обсуждала в 2022 году. Последовательность имеет значение. В январе 2025 года компания открыла программу раннего доступа, заявила, что к её завершению в ней участвовали более 50 клиентов и партнёров, вывела PREMI3NS вобщий доступ 16 октября 2025 года, а двумя месяцами позже получилавизу безопасности SecNumCloud 3.2. К апрелю 2026 года всовместном заявлении S3NS, SAP и Thalesговорилось, что компания обслуживает более 60 клиентов и предлагает 30 управляемых сервисов, ещё 30 планируется запустить в течение следующего года.

Эти вехи решают один вопрос, который ранее требовал осторожности: PREMI3NS — это не просто проектная мощность и не будущая цель сертификации. Существует производственный сервис, квалифицированный объём и база организаций, использующих предложения S3NS. Различие между предложениями остаётся важным. CRYPT3NS, более ранний продукт с локальными средствами контроля, построенный на базе стандартного Google Cloud, был явно представлен без цели получения квалификации SecNumCloud. PREMI3NS — это отдельная выделенная среда, которую квалифицировала ANSSI.

Клиент не может переносить гарантии с одного названия продукта на другое только потому, что оба продаёт S3NS.

Квалификационное решение ANSSIточнее пресс-релиза. В нём поставщик назван THALES CLOUD SÉCURISÉ, а сервис — CLOUD DE CONFIANCE S3NS. Его объём охватывает инфраструктурные, платформенные и контейнерные сервисы, но не программное обеспечение как услугу. Втекущем каталоге агентствауказаны даты квалификации: с 17 декабря 2025 года по 17 декабря 2028 года. Это создаёт чёткую границу гарантий: используйте квалифицированный сервис на квалифицированных условиях и проверяйте, что каждый зависимый продукт действительно попадает в эту границу.

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

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

Поставщик — Thales Cloud Sécurisé, а не абстрактный альянс

Название S3NS описывает партнёрство и бренд, но юридический поставщик вполне конкретен. Торговый реестр Франции идентифицирует THALES CLOUD SECURISE, SIREN 908 211 980, как французское упрощённое акционерное общество, созданное в 2021 году. Его нынешний зарегистрированный офис находится по адресу: 26 rue de Montholon, Париж.Обновлённый устав компаниипоказывает капитал в размере 3,3 миллиона евро по состоянию на апрель 2026 года.

Контроль информативнее расплывчатого описания «Thales и облако Google». Вфинансовой отчётности за 2024 годуказано, что на конец года Thales владела 95% акций, а Google — 5%. Устав 2026 года предусматривает пять голосующих директоров, предложенных Thales, и одного наблюдателя без права голоса, назначенного другим акционером. Он также исключает этого наблюдателя из доступа к данным клиентов и чувствительной информации о физической и логической безопасности. В показаниях перед французской парламентской комиссией в 2026 году директор по связям с общественностью Google охарактеризовал роль Google как место наблюдателя без права голоса или вето в совете директоров. Устав — более полезное доказательство, поскольку он детализирует структуру, а не сжимает её до лозунга.

Это не означает, что Google не важен. В отчётности за 2024 год указано, что S3NS и Google подписали соглашение, регулирующее технические и коммерческие отношения в сфере доверенного облака, в декабре 2024 года. Google поставляет базовую облачную технологию и её развитие. Ценностное предложение S3NS состоит в том, что Thales Cloud Sécurisé контролирует выделенную среду, персонал, ключи, операции и развёртывание обновлений, одновременно получая выгоду от программной инженерии Google.

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

Корпоративные документы также свидетельствуют о наращивании инфраструктуры. На конец 2024 года S3NS отчиталась о 126 сотрудниках, добавив за год 51 человека, включая 40 новых членов технических команд. В балансе компании отражено 14,2 миллиона евро материальных активов в стадии строительства против 3,7 миллиона годом ранее. Выручка выросла до 4,94 миллиона евро, при этом компания зафиксировала годовой убыток в размере 942 293 евро. Эти цифры описывают оператора на инвестиционной стадии до выхода в общий доступ и получения квалификации.

Сами по себе они не доказывают ни клиентскую ёмкость, ни финансовую слабость, но показывают, что сервис зависел от существенного строительства и найма персонала до запуска.

Один французский регион содержит три физических домена отказа

Физически PREMI3NS уже, чем предполагает слово «облако». В текущемобзоре Cloud de Confianceсказано, что это автономная облачная вселенная с одним регионом,u-france-east1. В этом регионе три зоны:u-france-east1-a,u-france-east1-bиu-france-east1-c. В коммерческих материалах S3NS говорится, что регион состоит изтрёх независимых дата-центров во Франции. Более ранние материалы S3NS размещали их в парижском регионе и описывали выделенные залы рядом с тремя французскими дата-центрами Google, с физически и логически изолированными стойками, серверами и сетями.

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

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

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

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

Три зоны не создают второй регион

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

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

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

Клиент, которому необходимо пережить потерюu-france-east1, нуждается во второй среде за пределами PREMI3NS. Это может быть собственный парк оборудования, другой квалифицированный французский или европейский провайдер, отдельно контролируемая холодная среда восстановления или менее чувствительный уровень обслуживания с тщательно определённой границей данных. Каждый вариант порождает свои проблемы: репликация данных, хранение ключей, совместимость программного обеспечения, пропускная способность сети, доступ оператора и правовой статус резервной копии.

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

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

Физическая изоляция меняет круг лиц, имеющих доступ к машинам

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

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

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

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

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

Программный суверенитет имеет часы обслуживания

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

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

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

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

Документация S3NS уже предупреждает, что Cloud de Confiance — это отдельный продукт с подмножеством продуктов Google Cloud и другими конечными точками, включаяs3nsapis.frвместоgoogleapis.com. Это свидетельство реального разделения. Это также свидетельство того, что миграция — не простое переключение региона. Владельцам приложений нужно тестировать код, библиотеки, допущения об идентификации, доступность сервисов и операционные процедуры в самой вселенной S3NS.

Связь начинается там, где клиент входит в облако

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

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

Документация S3NS по Partner Interconnectиллюстрирует этот момент. В ней сказано, что для проекта с доступностью 99,9% нужны два резервных подключения в разных доменах доступности на границе, а типовая схема 99,99% требует четырёх подключений, распределённых между двумя мегаполисами и двумя регионами. Поскольку у PREMI3NS сейчас только один регион, эту двухрегионную схему нельзя полностью реализовать внутри нынешней вселенной S3NS. Клиентам не следует полагать, что покупка четырёх каналов внутри Парижа создаёт такую же изоляцию отказов.

У HA VPN другая топология. S3NS документирует конфигурацию 99,99%, когда оба интерфейса управляемого шлюза соединяются соответствующими туннелями со стороной пира. Но доступность сквозного соединения по-прежнему зависит от физических шлюзов клиента, интернет-провайдеров или межсоединений, политики маршрутизации и размещённой нагрузки. Показатель уровня обслуживания на стороне облака не покрывает один маршрутизатор в офисе клиента.

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

Уровень операторов и магистральной сети остаётся непрозрачным

Документация PREMI3NS сообщает, что её премиальная сеть передаёт трафик по сети Cloud de Confiance и выбирает пути BGP к пиринговым или транзитным сетям. Она также позволяет клиентам приносить допустимые диапазоны IPv4 и IPv6 при условии проверки владения и авторизации источника маршрута. Это зрелые облачные сетевые возможности. Они не раскрывают реальных поставщиков или физических маршрутов за границей S3NS.

В публичных материалах, на которые ссылается эта статья, не названы транзитные операторы, здания межсоединений, точки обмена интернет-трафиком, поставщики магистрального оптоволокна или отношения с серверами маршрутов, используемые PREMI3NS. Не публикуется платформенный ASN, полный список префиксов провайдера или карта, по которой клиент мог бы установить разнообразие путей. Адреса, которые видит нагрузка клиента, также могут зависеть от того, использует ли клиент адресное пространство, назначенное S3NS, приносит собственные адреса, входит через партнёра или держит сервис частным.

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

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

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

Установленная ёмкость не равна ёмкости аварийного переключения

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

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

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

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

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

Труд поддержки — часть инфраструктуры

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

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

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

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

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

Соглашение об уровне обслуживания не делает приложение устойчивым

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

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

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

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

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

SecNumCloud — сильная гарантия, но не универсальная страховка

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

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

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

Виза также не покрывает каждый продукт, продаваемый под именем S3NS. Она покрывает названный сервис Cloud de Confiance как IaaS, PaaS и CaaS. CRYPT3NS был явно представлен как промежуточный шаг, не преследующий квалификацию SecNumCloud. Партнёрские SaaS-приложения, работающие на PREMI3NS, требуют собственного анализа объёма. Квалифицированная основа не делает автоматически квалифицированным программное обеспечение и операционные практики над ней.

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

Объявления клиентов показывают спрос, а не проверенное восстановление

S3NS назвала клиентов в сферах страхования, здравоохранения, финансов, промышленности и услуг. В объявлении о квалификации упомянуты MGEN, Matmut, AGPM, Thales, Birdz, Qonto, BConnect и Club Med.Кейс MGENособенно показателен, поскольку страховщик описал платформу, рассчитанную на размещение до шести миллионов человек. В объявлении от апреля 2026 года сказано, что SAP RISE Private Cloud Edition будет развёрнута на PREMI3NS для Thales во втором полугодии 2026 года и охватит ключевые бизнес-области, включая финансы, цепочку поставок, производство и закупки.

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

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

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

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

Локализация данных требует карты каждой копии

PREMI3NS предлагает ясное предложение по основной локации: данные и нагрузки остаются во Франции в выделенной среде S3NS. Это сильнее, чем предполагать расположение по платёжному адресу или результату геолокации IP. Архитектура также удерживает производственную идентификацию, контроль ключей, администрирование и поддержку под властью французского оператора.

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

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

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

Локализация также меняет задержку и зону обслуживания. Три дата-центра находятся во Франции, в более ранних описаниях S3NS — в парижском регионе. Европейские пользователи могут получать хорошую задержку, но французский регион не всегда близок к каждому филиалу, заводу или заморской территории. Сеть доступа и конструкция приложения определяют воспринимаемую производительность. Многонациональная организация также должна решить, принадлежат ли все пользователи и данные французской юрисдикции или PREMI3NS должна хранить только чувствительное подмножество.

Миграция — последний механизм восстановления

S3NS продвигает преемственность с технологией Google Cloud, и это может снизить усилия по миграции для клиентов, уже использующих знакомые API и управляемые сервисы. Это не делает платформы идентичными. У выделенной вселенной другие конечные точки, более узкий набор сервисов, один регион и операционные меры, обусловленные квалификацией. Миграция в PREMI3NS — это плановая инженерная программа; миграция из неё будет такой же.

Руководство по миграции S3NS отмечает, что время переноса зависит от объёма данных и пропускной способности сети. Это простое утверждение становится суровым во время сбоя. Перенос 500 терабайт по пути с устойчивой скоростью 5 гигабит в секунду занимает более девяти дней без учёта накладных расходов протокола, повторов, проверки и переключения приложения. Если исходный сервис деградировал, фактическая пропускная способность может быть значительно ниже. Если назначение использует другую управляемую базу данных, преобразование может доминировать над копированием.

Французские и европейские правила укрепляют позицию клиента. Статья 28французского закона SRENтребует, чтобы облачные сервисы поддерживали безопасную совместимость, переносимость экспортируемых данных и цифровых активов, а также интерфейсы и информацию, необходимые для этого.Рекомендация Arcep 2025 годасосредоточена на прозрачности переключения и стабильных интерфейсах. Закон ЕС о данных вводит обязательства по переключению и постепенно отменяет плату за него.

Юридическая переносимость не гарантирует операционной эквивалентности. Экспортируемые данные могут исключать интеллектуальную собственность провайдера. Приложение Kubernetes может переноситься легче, чем нагрузка, построенная вокруг BigQuery, поведения Cloud SQL, идентификации провайдера и проприетарного мониторинга. Даже если записи экспортируются чисто, политики, очереди, история событий, криптографическое состояние и операционные панели могут не перенестись.

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

Правдоподобные пути отказа — обыденные

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

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

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

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

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

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

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

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

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

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

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

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

Оценка доказательств — средняя

S3NS перешла порог от правдоподобного проекта к подтверждённому оператору. PREMI3NS общедоступна, имеет названного юридического поставщика, нанимает значительную французскую команду, эксплуатирует задокументированный автономный регион, предлагает широкий каталог управляемых услуг, имеет публичные клиентские программы и действующую квалификацию SecNumCloud 3.2 для IaaS, PaaS и CaaS. Это более сильные сигналы, чем маркетинговая карта, спящая запись о компании или непроверенная облачная метка.

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

Поэтому справедливый вывод — ни «французский контроль решает всё», ни «технология Google делает суверенитет бессмысленным». ANSSI установила, что Thales Cloud Sécurisé контролирует квалифицированную среду и защищает её от правового доступа из стран, не входящих в Европу, на заявленных условиях. Платформа по-прежнему зависит от технологии Google, французской инфраструктуры дата-центров, электроэнергии, оптоволокна, поставок оборудования и персонала S3NS. Этими зависимостями можно управлять, потому что они идентифицируемы; ими нельзя управлять, делая вид, что они исчезли.

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