S3NS Thales Cloud Securise SAS、ラック、トランジット、修理窓口に依存したホスト容量を販売

サマリー

PREMI3NS はもはや単なる将来予告サービスではありません。S3NS は2025年10月16日に一般提供を開始し、ANSSI は2025年12月17日に SecNumCloud 3.2に基づき IaaS、PaaS、CaaS サービスを認定しました。この認定は2028年12月17日まで有効とされています。
物理的な地理構成は集約されていますが、意図的に区画化されています。スタンドアロンのu-france-east1リージョンには3つのゾーンがあり、それぞれがフランス国内の3つの独立したデータセンターに関連付けられています。公開製品ドキュメントには、複数のリージョンを必要とする機能は利用できないと記載されています。
認定サプライヤーは Thales Cloud Sécuriséであり、商業的には S3NS という名称が使用されています。この企業はフランス法に準拠し、Thales の支配下にあります。2024年の会計報告では Thales が95%、Google が5%の株式を保有しており、現在の定款では Thales の指名による5名の議決権付き取締役と、他の株主による1名の議決権のない監査役が置かれています。
公開記録はフランスの支配、稼働中のサービス、実質的なマネージドサービスカタログ、ゾーンレベルの設計を強く支持しています。ただし、3つの施設運営者、正確なサイト、ユーティリティ供給、キャリア契約、バックボーントポロジー、スペア在庫、カスタマーサポートの応答義務などは開示していません。
結果としての証拠グレードは「中」です。S3NS は若いクラウドとしては異例なほど強力な規制およびオペレーション上の証拠を持っていますが、購入者が SecNumCloud 認定や3ゾーンマップだけからリージョン全体の復旧や使用可能なフェイルオーバーキャパシティ、迅速な物理修復を推測することはできません。

クラウドの約束が稼働中のサービスになった

S3NS は、フランスが2022年に初めて議論した提案としてではなく、稼働中のインフラプロバイダーとして評価されるべきです。その順序が重要です。同社は2025年1月に早期アクセスプログラムを開始し、50以上の顧客とパートナーが参加したと述べてプログラムを終了した後、2025年10月16日に PREMI3NS を一般提供に移行し、その2か月後にSecNumCloud 3.2セキュリティビザを取得しました。2026年4月までに、S3NS、SAP、Thales の発表では、同社が60を超える顧客にサービスを提供し、30のマネージドサービスを提供しており、さらに30のサービスを翌年に計画しているとされています。

これらのマイルストーンにより、以前は注意が必要だった一つの疑問が解消されます。PREMI3NS は単なる設計上のキャパシティや将来の認証目標ではありません。本番サービス、認定範囲、S3NS の提供物を利用する組織基盤が存在します。提供物の区別は依然として重要です。CRYPT3NS は、標準的な Google Cloud 上に構築された初期のローカルコントロール製品であり、SecNumCloud 認証を目指さないと明示されていました。PREMI3NS は ANSSI によって認定された別個の専用環境です。顧客は、両方が S3NS によって販売されているという理由だけで、ある製品名の保証を別の製品名に持ち越すことはできません。

ANSSI の認定決定はプレスリリースよりも正確です。プロバイダーを THALES CLOUD SÉCURISÉ、サービスを CLOUD DE CONFIANCE S3NS と指定しています。その範囲はサービスとしてのソフトウェア（SaaS）ではなく、インフラ、プラットフォーム、コンテナサービスを対象としています。当局の最新のカタログでは、認定期間は2025年12月17日から2028年12月17日までとされています。これにより明確な保証境界が設定されます。認定サービスを認定条件下で使用し、依存するすべての製品がその境界内に実際に収まっていることを確認してください。

サービスカタログは十分な広さがあり、実質的な依存を生み出します。PREMI3NS 製品ページには、仮想マシン、Kubernetes、オブジェクトストレージとブロックストレージ、マネージドリレーショナルデータベース、BigQuery、VPN、相互接続、DNS、セキュリティサービスがリストされています。これらは周辺ツールではありません。ID、トランザクション、分析、アプリケーション、バックアップ機能を保持することができ、組織が運用モデルをそれらを中心に標準化した後では、切り離しが難しくなります。

だからこそ、物理層が今重要です。ロードマップはもっともらしさで判断できます。本番クラウドは、ラックの電源が切れたり、ゾーンが隔離されたり、キャリアが故障したり、アップデートが保留になったり、サポートキューが溢れたり、顧客が離脱を必要とした場合に、何が引き続き使用可能かによって判断されなければなりません。

サプライヤーは Thales Cloud Sécuriséであり、抽象的な提携ではない

S3NS という名称はパートナーシップとブランドを表しますが、法的なサプライヤーは明確です。フランスの商業登記簿では、THALES CLOUD SECURISE（SIREN 908 211 980）は2021年に設立されたフランスの簡易株式会社として登録されています。現在の登記上の本社所在地はパリの26 rue de Montholon です。同社の更新された定款では、2026年4月時点の資本金は330万ユーロとされています。

「Thales と Google のクラウド」というざっくりとした説明よりも、支配の実態の方がより多くの情報を提供します。同社の2024年財務諸表によれば、年末時点で Thales が株式の95%、Google が5%を保有していました。2026年定款では、Thales が指名する5名の議決権付き取締役と、他の株主が任命する1名の議決権のない監査役の設置が定められています。また、その監査役は顧客データや機密性の高い物理的および論理的セキュリティ情報から除外されています。2026年のフランス議会公聴会での証言では、Google の広報担当ディレクターが、Google は取締役会に監査役として参加しているが、議決権も拒否権も持たないと説明しました。定款は、構造を明確に示しているため、より有用な証拠です。

これが Google を重要でないとするものではありません。2024年の会計報告では、S3NS と Google が2024年12月にトラステッドクラウドに関する技術的および商業的関係を規定する契約を締結したとされています。Google は基盤となるクラウド技術とその進化を提供しています。S3NS の価値提案は、Thales Cloud Sécuriséが専用環境、人員、鍵、運用、アップデートの展開を管理しながら、Google のソフトウェアエンジニアリングの恩恵を受けるという点にあります。

その境界は厳格なフランスの認定を通過しています。それは依然としてサプライヤー境界です。もしソフトウェアアップデートが停止したり、ライセンス条件が変更されたり、ドキュメントアクセスが狭められたり、ハードウェア世代が利用不能になったりした場合、稼働環境の法的管理は代替の技術スタックを作り出しません。逆に、技術依存は Google が顧客データを読み取ったり PREMI3NS を管理したりできることを意味するものではありません。有意義な評価は、両方の事実を同時に保持します。すなわち、S3NS は認定サービスを管理し、Google は戦略的な技術サプライヤーであり続けるということです。

企業記録はまた、構築の証拠も提供しています。S3NS は2024年末時点で126人の従業員を報告し、年間で51人を追加しました。そのうち40人は技術チームへの配属です。貸借対照表には建設中の有形固定資産が1420万ユーロと記録されており、前年の370万ユーロから増加しています。売上高は494万ユーロに上昇し、同社は94万2293ユーロの年間損失を報告しました。これらの数値は、一般提供開始と認定前の投資段階にある事業者を示しています。それ自体で顧客容量や財務上の脆弱性を証明するものではありませんが、このサービスが立ち上げ前に相当な構築と人員配置に依存していたことを示しています。

1つのフランスリージョンが3つの物理的な障害ドメインを含んでいる

PREMI3NS は、クラウドという言葉が示唆するよりも物理的には狭いものです。現在のCloud de Confiance 概要では、1つのリージョンu-france-east1を持つ自己完結型のクラウドユニバースであるとされています。このリージョンには、u-france-east1-a、u-france-east1-b、u-france-east1-cの3つのゾーンがあります。S3NS のセールス資料では、このリージョンはフランス国内の3つの独立したデータセンターで構成されるとしています。以前の S3NS 資料ではこれらをパリ地域に位置し、3つの Google フランスデータセンターに近接した専用ルームとして、物理的および論理的に隔離されたラック、サーバー、ネットワークを備えていると説明していました。

これは有意義な物理的証拠です。1つのサーバールームに付けられた3つのラベル以上のものを示しています。ベンダーはゾーンが独立したデータセンターにマッピングされており、各ゾーンを別個の障害ドメインとして扱うよう顧客に指示しています。したがって、ゾーンに分散されたアプリケーションは、あるゾーンのハードウェア、電源、冷却、ネットワーク障害を乗り切れるように設計できます。

しかし、ゾーンは自動的にすべてのサービスの完全な複製ではありません。コンピューティングインスタンスとゾーンディスクはゾーンに紐付いたままです。一部のリージョンサービスはゾーン間でレプリケートされますが、他のマネージド製品には独自の耐久性と可用性のセマンティクスがあります。仮想マシンを起動してゾーンディスクをアタッチした顧客は、単に3ゾーンリージョンを選択しただけでは3サイトの継続性を得たわけではありません。それは2つのゾーナルリソースを1つの障害ドメインに配置したことになります。

アーキテクチャの責任は顧客にあります。コンピューティングには少なくとも別のゾーンの別のインスタンス、ヘルスチェック、トラフィックシフトメカニズムが必要です。ステートフルなシステムには、アプリケーションに一致する一貫性と復旧動作を持つレプリケーションモデルが必要です。アイデンティティ、シークレット、ログ、デプロイメントコントロールも同じゾーン障害に耐える必要があります。バックアップは、単に障害が発生した運用境界内の別のオブジェクトとして存在するのではなく、一次サービスが損なわれたときに復元可能でなければなりません。

S3NS は、ここにリンクされている資料では、3つの施設の所在地や運営者を公開していません。機密性の高いワークロード向けに構築されたプラットフォームとしては理解できる制約です。しかし購入者は、ゾーン名だけから、それらのサイトが同じ氾濫原、変電所、光ファイバー回廊、家主、保守業者、リモートハンドサプライヤーを共有しているかどうかを独自に判断することはできません。「独立したデータセンター」は有用な主張ですが、相関リスクは秘密保持契約の下で回答されるべきデューデリジェンスの質問として残ります。

3つのゾーンは第2のリージョンを作り出さない

アーキテクチャ上の最大の制約は、S3NS ドキュメントに明確に述べられています。Cloud de Confiance には現在1つのリージョンしかなく、複数のリージョンを必要とする機能は利用できません。これにより、高可用性と災害復旧の違いが特に重要になります。

3つのゾーンは、アプリケーションがそれらを正しく使用している場合、サーバー、ラック、サイトレベルのイベントから保護できます。しかし、リージョンをユニットとして影響を与えるあらゆるイベントから保護できるわけではありません。リージョナルなアイデンティティ、コントロールプレーン、ソフトウェア、ルーティング、オペレーションの障害はゾーン境界を越える可能性があります。深刻な都市の電力や光ファイバーイベントも、建物が物理的に離れていても相関的な圧力を生み出すことができます。共有サービスを環境全体で意図的に無効にするセキュリティ対応も同様です。

Google のパブリッククラウドでは通常、顧客はリージョンをペアリングできます。PREMI3NS は現在、認定されたユニバース内でそのパターンを提供していません。その「グローバル」リソースは、自己完結型の S3NS 環境内でのみグローバルであり、単一のフランスリージョンに解決されます。Google の世界的なクラウド全体に分散されたレプリカではありません。これは厳格な管轄権と運用の分離の必然的な結果ですが、復旧計算を変えます。

u-france-east1の喪失を乗り切る要件がある顧客は、PREMI3NS の外部に第2の環境を必要とします。それはオンプレミス資産、別の認定フランスまたは欧州プロバイダー、個別に管理されたコールドリカバリー環境、あるいは慎重に定義されたデータ境界を持つ低センシティビティのサービス層かもしれません。それぞれの選択は独自の問題を引き起こします。データレプリケーション、キー保管、ソフトウェア互換性、ネットワーク容量、オペレーターアクセス、復旧コピーの法的地位です。

これは PREMI3NS に対する反対意見ではありません。特に外国のサプライヤーが直接的な運用管理権を持つ代案と比較した場合、機密データにとって単一リージョンは適切な境界となり得ます。3つのゾーンを地理的災害復旧と誤解することに対する異議です。この判断はビジネス影響分析に属します。どのワークロードがリージョン停止を受け入れられるか、どれが別の場所で復旧する必要があるか、その移動中にどれだけのデータまたは機能が失われ得るか、ということです。

プロバイダー自身のドキュメントは、アプリケーションをゾーンに分散するよう顧客に指示することで正しい方向を示しています。成熟した契約はその考えを継続すべきです。S3NS がリージョン復旧計画を持っているかどうか、壊滅的な損失後に構成と顧客メタデータがどのように復旧されるか、顧客の期限内にリージョンが復旧できない場合にプラットフォーム外で再構築するための支援が利用可能かどうかを定義すべきです。

物理的隔離は、誰がマシンに触れられるかを変える

S3NS の中核的なエンジニアリング主張は、単にデータがフランスに保存されているということではありません。機器が隔離され、それを操作できる人物が S3NS の管理下にあるということです。同社は専用のラック、サーバー、ネットワーク機器、物理アクセス制御、監視、侵入検知に加えて、分離されたアイデンティティ、信頼ルート、暗号化、ネットワーク境界について説明しています。認定発表では、サービスを管理するのは S3NS の従業員のみであり、Google の技術とアップデートは本番展開前に検疫エリアに入り、分析と検証を受けるとされています。

これらの管理策はいくつかの実際のリスクに対処しています。Google が雇用するリモート管理者が環境に入ることはできないはずです。ソフトウェアアップデートは技術サプライヤーから直接本番環境に流れ込むべきではありません。暗号管理と本番アイデンティティはフランスの運営者にあります。認定サービスは、物理的セキュリティ、隔離された管理、インシデント処理、継続性、下請け管理、非欧州法からの保護に関する SecNumCloud 要件も満たさなければなりません。

しかし、物理的な分離は、S3NS が自ら維持しなければならない運用資産を生み出します。誰かがサーバーを受け取り、ファームウェアを検証し、ラックをケーブル接続し、故障したドライブを交換し、ハードウェアセキュリティモジュールをローテーションし、データホール内での作業を調整しなければなりません。ハイパースケーラーのグローバルなフリートが行う修理は、S3NS の責任または厳格に管理された下請け活動になります。運営者は全3サイトで十分な人員、アクセス権、スペアパーツ、サプライヤー契約を必要とします。

公開文書は、ラック数、サーバー世代、総電力割り当て量、冷却余裕、スペアパーツの保有量、各ゾーンのローカル技術者カバレッジを明示していません。どの施設作業が S3NS 従業員によって行われ、どれがランドロードや専門業者に委ねられるかも特定していません。SecNumCloud は、評価対象範囲内でこれらの管理策が評価されたことを立証していますが、すべてのコンポーネントの容量計画や修理時間保証を顧客に提供するものではありません。

この隠れた運用資産こそが、サービスの経済的実体です。顧客は、S3NS が機器、リース、電力、トランジット、ライセンス、セキュリティ管理策、専門労働力を、メータリングされたクラウドサービスに変換するために対価を支払います。設置された基盤と顧客需要の間のマージンが、故障したラックが日常的な退避を引き起こすか、容量不足を生み出すかを決定します。部品契約が、故障したネットワークシャーシが数時間で戻るか、国際物流待ちになるかを決定します。どちらの結果も製品カタログには見えません。

ソフトウェア主権には保守時計がある

PREMI3NS は、Google が顧客環境を管理したり遠隔から停止したりするのを防ぐように設計されています。これは Google エンジニアリングへの依存を排除することとは異なります。マネージドデータベース、オーケストレーション、ストレージ、分析サービスは、依然としてセキュリティ修正、互換性作業、ハードウェア有効化を必要とする複雑なソフトウェアシステムです。したがって、問うべきことは、サプライヤーとの断絶後に S3NS が今日のコードを稼働させ続けられるかどうかだけではありません。脆弱性、証明書、依存関係、顧客要件が変化し続ける中で、どれだけの期間安全に稼働させられるかということです。

SecNumCloud 3.2要件は、プロバイダーが第三者に依存する場合の運用自律性について明示的に言及しています。ANSSI 長官はその後、認定は直接的な非欧州からのアクセスと顧客固有のシャットダウンから保護するものであるが、技術依存がないことを意味するものではないと公に強調しました。これは正しい区別です。運用に対する主権は、すべてのサプライヤーからの無期限の独立と同じではありません。

Google は、その Dedicated Cloud の設計により、ローカルパートナーがアップデートを監視、ブロック、ロールバックし、Google への接続が切断された後、最大12か月間運用を継続できると述べています。同じ Google の出版物では、PREMI3NS をフランスの実装であると特定しています。これは重要な継続性の主張ですが、公開された文言は顧客固有の復旧保証ではなく、設計能力を説明しています。購入者は、どの PREMI3NS サービスが対象か、その期間中「運用」とは何を意味するか、どのセキュリティアップデートが引き続き利用可能か、その期間の終わりに何が起こるかを確認すべきです。

検疫メカニズムは独自のトレードオフをもたらします。アップデートをスクリーニングすることで、侵害されたり不適切なリリースが信頼できる環境に入るリスクを減らします。しかし、それは機能の遅れや、多くの上流変更が一度に到着したときのキューを生み出す可能性もあります。S3NS は、重要な脆弱性を未解決のまま放置することなく、アップデートを評価、テスト、承認、拒否するのに十分なエンジニアリングの深さを必要とします。顧客は、デプロイスクリプトやマネージドサービスの前提が黙ってずれないように、標準の Google Cloud との違いの通知を必要とします。

S3NS のドキュメントはすでに、Cloud de Confiance がサブセットの Google Cloud 製品と、googleapis.comではなくs3nsapis.frの異なるエンドポイントを持つ別個の製品であると警告しています。これは真の分離の証拠です。また、移行が単純なリージョン切り替えではないことの証拠でもあります。アプリケーション所有者は、S3NS ユニバース自体に対して、コード、ライブラリ、アイデンティティの前提、サービスの可用性、運用手順をテストしなければなりません。

接続性は顧客がクラウドに入る場所から始まる

到達できない主権サーバーはサービスではありません。PREMI3NS はパブリックインターネットアクセス、Cloud VPN、Cloud Interconnect をサポートしており、それらの経路には異なる障害と信頼の境界があります。ネットワーク接続ドキュメントでは、VPN をパブリックインターネット上の暗号化トラフィック、Interconnect を顧客ネットワークとクラウド間の専用またはパートナー接続として説明しています。

本番資産の場合、アクセス設計はゾーン設計と一致させるべきです。別々のゾーンにある2つの仮想マシンでも、両方が1つのトンネルを介して到達される場合、依然として1つの顧客ルーターに依存します。2つの相互接続回線でも、建物入り口、キャリア、光システム、メトロダクトを共有する可能性があります。回復力のある図は、すべてのハンドオフポイントで多様性を必要とします。顧客ルーター、キャリアプロバイダー、クロスコネクト、S3NS エッジドメイン、BGP セッション、およびクリティカルな負荷を運ぶのに十分なフェイルオーバー帯域幅です。

S3NS のPartner Interconnect ドキュメントはこの点を例示しています。99.9%の設計には異なるエッジ可用性ドメインに2つの冗長アタッチメントが必要であり、一般的な99.99%パターンには2つのメトロエリアと2つのリージョンに分割された4つのアタッチメントが必要であるとされています。PREMI3NS には現在1つのリージョンしかないため、その2リージョンパターンは現在の S3NS ユニバース内では完全に実装できません。顧客は、パリ内で4つの回線を購入すれば同じ障害隔離が得られると想定するべきではありません。

HA VPN は異なるトポロジを持っています。S3NS は、マネージドゲートウェイの両方のインターフェースが一致するトンネルを通じてピア側に接続する場合の99.99%の構成を説明しています。しかし、エンドツーエンド接続の可用性は依然として顧客の物理ゲートウェイ、インターネットプロバイダーまたは相互接続、ルーティングポリシー、ホストされるワークロードに依存します。クラウド側のサービスレベル数値は、顧客のオフィスにある単一のルーターをカバーしません。

スループットも復旧の一部です。通常のデータベースレプリケーション用にサイジングされた相互接続は、障害後にストレージを再シードするには小さすぎる可能性があります。管理トラフィックを快適に運ぶ VPN は、顧客トランザクションの唯一の経路になったときに崩壊する可能性があります。復旧演習では、ポート速度を代理とせずに、劣化したトポロジ下での転送速度を測定すべきです。

キャリアとバックボーンレイヤーは不透明なまま

PREMI3NS のドキュメントでは、プレミアムネットワークが Cloud de Confiance ネットワーク上でトラフィックを運び、ピアリングまたはトランジットネットワークへの BGP 経路を選択すると述べています。また、所有権検証と経路起点認可を条件に、顧客が適格な IPv4 および IPv6 範囲を持ち込むことも許可しています。これらは成熟したクラウドネットワーキング機能です。これらは S3NS エッジの背後にある実際のサプライヤーや物理的な経路を明らかにするものではありません。

この記事にリンクされている公開資料では、PREMI3NS が使用するトランジットキャリア、相互接続ビル、インターネットエクスチェンジ、バックボーン光ファイバープロバイダー、ルートサーバー関係を明示していません。プラットフォーム ASN、完全なプロバイダープレフィックスリスト、顧客が経路多様性を確立するために使用できる地図も公開していません。顧客のワークロードによって公開されるアドレスも、顧客が S3NS 割り当てスペースを使用するか、自身のアドレスを持ち出すか、パートナーを通じて入るか、サービスをプライベートに保つかによって異なります。

不透明性は脆弱性の証明ではありません。機密性の高いプロバイダーはトポロジの開示を制限することが多く、分散仮想ネットワークを1つのルーターアイコンに還元することはできません。これは、「複数の経路」という表現が機密保持契約の下での証拠を必要とすることを意味します。購入者は、3つのゾーンが物理的に別々の光ファイバー入り口を持っているか、ゾーン間リンクがダクトを共有しているか、専用相互接続がどこで終端するか、2つの指名されたキャリア製品が最終的に同じホールセールネットワークに乗っているかどうかを尋ねるべきです。

また、S3NS がルーティングセキュリティをどのように検証するかも尋ねるべきです。顧客提供のプレフィックスには、正しい経路起点認可、正確なルーティングオブジェクト、管理された切り替えが必要です。プロバイダー空間には独自の起点セキュリティとフィルタリングが必要です。誤ったルートポリシーは、すべてのラックが電源投入されたままでも、健全なサービスをインターネットから引き離す可能性があります。

境界は S3NS を超えて広がります。パブリックアプリケーションは DNS、証明書発行、ドメイン登録、コンテンツ配信、ID、アップストリームユーザーネットワークに依存します。それらのサービスの一部は PREMI3NS の外側やフランスの外側に位置する可能性があります。コアワークロードを認定リージョンでホストしても、サービスの全体が自動的に同じ管轄権や障害ドメインに入るわけではありません。

設置されたキャパシティはフェイルオーバーキャパシティではない

S3NS は2026年2月に30のマネージドサービスを宣伝し、コンピューティングオプションとして H100 GPU 仮想マシンを挙げています。これは広がりを示していますが、量ではありません。公開文書は、各ゾーンに設置されたプロセッサ、GPU、ストレージデバイス、ネットワークポートの数、どれだけが予約されているか、ゾーン喪失後にどれだけの余裕が残っているかを示していません。

これは重要なことです。なぜなら、クラウドキャパシティは顧客の想像の中で二重に販売されているからです。第一の販売はエラスティシティです。リソースは要求に応じて現れます。第二は冗長性です。第一のゾーンが故障したときに別のゾーンが準備できているように見えます。どちらの約束も同じ物理的在庫に依存しています。ゾーンイベント中に多くの顧客が代替インスタンスを要求すると、スペアキャパシティは急速に消失します。通常の状態でリソースを許可するクオータは、リージョン全体のストレス時にも同等のハードウェアが利用可能であることを保証しません。

特殊な機器は制約を厳しくします。GPU ワークロードは、すべてのゾーンに均等に在庫されていない特定のアクセラレータ、ドライバ、マシンファミリーに依存する可能性があります。大容量メモリデータベースや高スループットストレージにも同様の配置制限があります。顧客は名目的なマルチゾーン設計を構築しても、実際には同じシェイプで別の場所で再起動できない可能性があります。

正しい尺度は、選択した障害後の使用可能なキャパシティであり、その前の設置キャパシティではありません。クリティカルなサービスについては、顧客は予約済みまたは契約上優先されたキャパシティ、配置確認、スタンバイゾーンがワークロードを受け入れられるという定期的な証拠を必要とします。また、合意されたデグラデーション戦略も必要です。完全なキャパシティが復旧できない場合のより小さなインスタンス、縮小された分析、中断されたバッチ作業、最小限のトランザクションサービスです。

S3NS にはフリート数を公開しない十分な理由があります。競合他社や攻撃者にとってその情報は価値があり、数は急速に変化します。秘密保持に基づく保証は、購入者が必要とするものを提供できます。キャパシティクラス、テストされた退避限界、希少なハードウェアのリードタイム、競合時に使用される優先ルールです。その証拠がなければ、「3つのゾーン」は場所を記述するに過ぎず、1つが失われた後に利用可能なサービス量を記述しません。

サポート労働はインフラの一部である

早期アクセスプログラムは、S3NS の運用モデルに関する有用な詳細を明らかにしました。同社は、サイト信頼性エンジニア、サイバーセキュリティチーム、データセンタースタッフ、サポート、テクニカルアカウントマネージャー、カスタマーエンジニアがすべて参加したと述べました。これは、セルフサービスポータル以上のものを運営するために構築された組織としての信頼できる証拠です。現在のプラットフォーム概要でも、インフラ管理とサポートの責任は Google Cloud ではなく S3NS にあると述べられています。

このローカルな責任は主権主張の中核です。顧客インシデントは Google の管理者が環境に入ることを必要とすべきではありません。また、エスカレーションを S3NS に集中させます。マネージドデータベースの欠陥がアップストリームの専門知識を必要とする場合、S3NS は問題を再現し、どの情報が環境を離れるかを管理し、Google と調整し、安全な修正を返さなければなりません。顧客はこの翻訳レイヤーの品質に依存します。

公開資料は、深刻度定義、初回応答時間、復旧目標、電話エスカレーション条件、サービスティア別の補償を含む完全なサポートマトリックスを提供していません。一般提供の発表では、契約上のサービスレベル合意がローンチに伴って提供されたと述べていますが、それを再現してはいません。したがって、購入者はローンチ文言ではなく、契約を必要とします。

修理の時計は分解されるべきです。検知は S3NS または顧客が障害に気付くまでの時間です。所有権は権限のある誰かがそれを受け入れるまでの時間です。診断は、その問題が顧客の構成、マネージドサービス、S3NS ネットワーク、施設、技術アップデートのいずれに属するかを特定します。アクセスはエンジニアが該当サイトに立ち入ることができるまでの遅延です。修理には部品、変更承認、検証が含まれます。復旧は、アプリケーション、データ、キューイングされた作業が再び使用可能になるまで完了しません。

一つの総合的な復旧目標はこれらの遷移を隠します。また、第三者も隠します。施設のリモートハンド、光ファイバー技術者、ハードウェアベンダー、Google スペシャリストはすべて、顧客環境を直接操作することなく関与する可能性があります。顧客は、どの当事者が時計を止めることができるか、大規模インシデント中に誰が顧客に話しかけるか、アイデンティティや S3NS コンソールが損なわれた場合にステータスチャネルが到達可能かどうかを知るべきです。

サービスレベル合意は回復力のあるアプリケーションを構築しない

S3NS は一般提供が正式なサービスレベル合意と本番準備をもたらすと説明しました。これは必要な商業的証拠です。SLA は依然として、定義されたサービスメトリックに囲まれた境界のある約束です。ゾーナル仮想マシンをリージョナルにしたり、第二の PREMI3NS リージョンを追加したり、すべての経路を1つのゲートウェイに送る顧客アーキテクチャを修復したりすることはできません。

複合インシデントの間、その違いは明確になります。ゾーンが電力を失い、アプリケーションがフェイルオーバーし、生き残ったデータベースが顧客課す接続制限に達したとします。インフラサービスはその可用性尺度を満たしながら、アプリケーションは利用不能になる可能性があります。顧客がアイデンティティ、シークレット、監視を分散していなければ、プロバイダーは事業者がサービスを復旧する前にインフラを復旧させるかもしれません。

サービス利用料のクレジットも同様に限定的です。適格障害後の請求書を調整します。失われた公共サービス、遅延した医療作業、逃した金融取引、緊急の移行労働を払い戻すことはありません。機密性の高いシステムにとって、有用な契約文言は、月間稼動時間率だけでなく、インシデントコミュニケーション、データ整合性、支援、証拠保全、復旧優先順位、解約支援をカバーします。

メンテナンス除外も同様の注意が必要です。隔離されたソフトウェア供給を運営するプロバイダーは、パッチ適用とアップグレードを行わなければなりません。顧客は、どれだけの通知が適用されるか、ゾーンが順次メンテナンスされるか、緊急変更が待てない場合に何が起こるか、ロールバックが技術的に可能かどうかを知る必要があります。契約が許可するメンテナンス動作に耐えられるようにアプリケーションを設計すべきです。

ステータスチャネルも別の依存関係です。S3NS のドキュメントは顧客に Cloud de Confiance のサービスヘルスダッシュボードを参照させますが、有用な大規模インシデントチャネルは障害のあるコンソールやアイデンティティプレーンの外側で機能しなければなりません。指名された連絡先、独立した通知経路、更新のリズムは運用能力です。それは顧客が待機、フェイルオーバー、リージョン復旧計画の呼び出しの間でいかに迅速に選択できるかを決定します。

SecNumCloud は強い保証であり、万能の保険ではない

SecNumCloud 認定は PREMI3NS を支持する最も強力な公的証拠です。ANSSI の枠組みはデータの場所をはるかに超えています。その要件には、物理的セキュリティ、アクセス制御、隔離された管理、ログ、脆弱性管理、暗号化、継続性、サプライヤー管理、可逆性、非欧州法からの保護が含まれます。当局の認定 FAQは、顧客データ、管理ディレクトリ、ユーザーディレクトリ、ログ、ルート認証局、バックアップが領域的管理策を満たさなければならず、継続的な運用自律性が評価されることを説明しています。

また、この決定は S3NS がフランスの国家クラウドドクトリンの勧告 R9 を満たし、域外法に対する保護を提供することを明示しています。これは公的機関や規制対象組織にとって重要な結果です。フランスのCloud at the Centre ドクトリンは、特に機密性の高い国家ワークロードを、第三国当局による不正アクセスから保護された認定商用クラウドに向けます。

認定は、S3NS のすべての利用が自動的に準拠または回復力を持つことを意味するものではありません。ANSSI の決定は、枠組みの勧告に準拠することを利用条件としています。顧客は依然としてアイデンティティ、ネットワーク、ストレージ、暗号化、ログ、アプリケーションを構成します。シングルゾーンデータベースを作成したり、安全でないサービスを公開したり、データを非認定の外部システムにコピーしたりする可能性があります。

また、ビザは S3NS ブランドで販売される全製品をカバーするものではありません。IaaS、PaaS、CaaS としての Cloud de Confiance サービスを対象としています。CRYPT3NS は、SecNumCloud 認定を目指さない足がかりとして明示的に販売されました。PREMI3NS 上で動作するパートナーSaaS アプリケーションは、独自の範囲分析を必要とします。認定された基盤は、その上のソフトウェアや運用慣行を自動的に認定するものではありません。

最後に、ビザには日付があります。3年間有効であり、継続的なコンプライアンスに依存します。重要な法的、組織的、技術的な変更は、認定義務の範囲内で管理されなければなりません。調達にあたっては、決定番号、範囲、有効期限、その後の条件を記録し、「SecNumCloud」を恒久的なバッジとして使うべきではありません。

顧客発表は需要を示すが、テストされた復旧を示さない

S3NS は、保険、医療、金融、産業、サービスの分野で顧客名を挙げています。認定発表では、MGEN、Matmut、AGPM、Thales、Birdz、Qonto、BConnect、Club Med が引用されました。MGEN の事例は、保険会社が最大600万人を収容できるプラットフォームを構想していると説明したため、特に重要です。2026年4月の発表では、SAP RISE Private Cloud Edition が2026年後半に Thales 向けに PREMI3NS 上に展開され、財務、サプライチェーン、製造、調達を含むコア事業領域をカバーするとされました。

これらの名前は、S3NS が実際のワークロードにサービスを提供しているか準備中であるという結論を裏付けます。また、障害の結果を誰が負うかも示しています。保険契約者、医療サービス利用者、従業員、サプライヤー、財務チーム、産業運用です。その結果は、実用的な復旧の必要性を高めつつ、強力なフランスの管理の価値を高めます。

顧客発表はインシデント履歴ではありません。どのワークロードがすでに本番環境にあるか、どれだけのデータを保持しているか、3つのゾーンすべてにまたがっているか、どの復旧時間が実証されたか、リージョン退出が行使されたかを述べることはほとんどありません。「選ばれた」という表現は、契約、移行プログラム、アーリーアダプターテスト、本番環境のいずれかを意味する可能性があります。それぞれ異なる証拠的価値を持ちます。

したがって、そのような発表の適切な使い方は控えめです。それらは市場の牽引力を検証し、要求の厳しい組織が独自の評価を実施したことを示します。それらは、他の購入者にそれらの組織の未開示の保証を転送するものではありません。新規顧客は、独自のアプリケーション、ネットワーク、データ、サポートチェーンをテストしなければなりません。

S3NS 自体もサプライヤーの顧客です。データセンターのランドロード、ユーティリティ、キャリア、サーバーメーカー、部品販売業者、Google は、それらがサービスを管理できなくても、その背後に存在します。信頼モデルは、各依存関係が制約され、交換可能で、テストされている場合により強固です。顧客が S3NS 契約をチェーンの最終ノードとして扱う場合、それは弱くなります。

データの地域性にはすべてのコピーの地図が必要

PREMI3NS は明確なプライマリロケーションの提案を提供します。データとワークロードは専用の S3NS 環境下でフランスに留まります。これは請求先住所や IP ジオロケーションの結果から場所を仮定するよりも強力です。アーキテクチャはまた、本番アイデンティティ、鍵管理、管理、サポートをフランスの運営者の権限下に保ちます。

それでも顧客は情報の各カテゴリをマッピングする必要があります。一次データ、レプリカ、バックアップ、スナップショット、ログ、サポート添付ファイル、請求記録、テレメトリ、鍵、アイデンティティメタデータは必ずしも同じライフサイクルを共有しません。SecNumCloud は認定サービス内での領域的要件を課しますが、顧客はログを外部プラットフォームに送信したり、機密データを含むサポートケースを開いたり、データベースを別の管轄区域にレプリケートしたりすることができます。

シングルリージョン設計はバックアップの配置を特に重要にします。3つのゾーンにコピーされたバックアップはデバイスやサイトの障害を乗り切ることができますが、u-france-east1内に留まります。リージョン外のコピーは災害復旧を改善しますが、組織が選択した正確な認定境界を離れる可能性があります。一部のワークロードは、別の認定プロバイダーでの暗号化されたコールドストレージを正当化するかもしれません。他のワークロードは、法的または運用上、S3NS 環境内に留まることが要求されるかもしれません。答えはデータと復旧目標に依存します。

鍵管理も同じ地図に従わなければなりません。復旧コピーは、その鍵が故障したリージョンに閉じ込められている場合には役に立ちません。別の場所にコピーされた鍵は、元の管理を損なう新たなアクセス経路を作り出す可能性があります。したがって、復旧設計には、鍵、アイデンティティ、構成、それらを使用する権限を与えられた人々のための独立した可用性が必要であり、少なくともデータの周りの管理策と同じくらい意図的な管理策が求められます。

地域性はレイテンシとサービスエリアも変えます。3つのデータセンターはフランスにあり、以前の S3NS の説明ではパリ地域に配置されていました。欧州のユーザーは良好なレイテンシを受け取る可能性がありますが、フランスのリージョンがすべての支店、工場、海外領土に自動的に近いわけではありません。アクセスネットワークとアプリケーション設計が体験されるパフォーマンスを決定します。多国籍組織はまた、すべてのユーザーとデータをフランスの管轄権に属させるか、PREMI3NS が機密性の高いサブセットのみを保持するかを決定しなければなりません。

移行は最終的な復旧メカニズムである

S3NS は Google Cloud 技術との継続性を促進しており、既存の使い慣れた API とマネージドサービスを利用している顧客にとって移行の労力を減らすことができます。それはプラットフォームを同一にするわけではありません。専用のユニバースは異なるエンドポイント、より狭いサービスセット、1つのリージョン、認定駆動の運用管理策を持っています。PREMI3NS への移行は計画されたエンジニアリングプログラムであり、移行はそれもまたそうなるでしょう。

S3NS の移行ガイドは、転送時間はデータ量とネットワーク帯域幅に依存することを指摘しています。この単純な表現は、障害時には深刻になります。500テラバイトを、持続的な5ギガビット/秒の経路で移動するには、プロトコルオーバーヘッド、再試行、検証、アプリケーションのカットオーバーの前に9日以上かかります。ソースサービスが劣化している場合は、実際のスループットはさらに低くなる可能性があります。宛先が異なるマネージドデータベースを使用する場合、変換がコピーを支配する可能性があります。

フランスと欧州のルールは顧客の立場を強化しています。フランス SREN 法第28条は、クラウドサービスに対して、安全な相互運用性、エクスポート可能なデータとデジタル資産のポータビリティ、それらを実行するために必要なインターフェースと情報をサポートすることを義務付けています。Arcep の2025年勧告は、切り替えの透明性と安定したインターフェースに焦点を当てています。EU データ法は切り替え義務を適用し、切り替え料金を段階的に廃止します。

法的なポータビリティは運用上の同等性を保証しません。エクスポート可能なデータはプロバイダーの知的財産を除外する可能性があります。Kubernetes アプリケーションは、BigQuery、Cloud SQL の振る舞い、プロバイダーアイデンティティ、独自の監視を中心に構築されたワークロードよりも容易に移動できるかもしれません。レコードがクリーンにエクスポートされても、ポリシー、キュー、イベント履歴、暗号化状態、運用ダッシュボードはエクスポートされないかもしれません。

したがって、顧客は別の場所に小規模だが完全な復旧展開を維持すべきです。実際のデータを復元し、アイデンティティとネットワーキングを再作成し、事業が定義された最小限のレベルで運用できることを実証する必要があります。演習では、転送速度、変換失敗、不足しているメタデータ、必要な人員を記録すべきです。契約文言としてのみ存在する退出計画はスペアキャパシティではありません。

現実的な障害経路はありふれたものである

S3NS は地政学的および法的な質問のために注目を集めていますが、最も起こりうる障害はよく知られたインフライベントです。電源コンポーネントが故障する。ストレージデバイスがエラーを生む。光ファイバーが切断される。BGP 経路が引き込まれる。証明書が期限切れになる。マネージドサービスアップデートが動作を変える。サポートチケットが誤分類される。顧客の支払いやアカウント状態がアクセスを妨げる。移行が承認されたウィンドウよりも長くかかる。

ラックやサーバーの障害はローカル冗長性によって封じ込められるべきですが、それはサービスと顧客の配置がそれをサポートする場合のみです。ゾーン障害はマルチゾーンアーキテクチャと十分な残存キャパシティによって封じ込められるべきです。リージョン障害には第二の PREMI3NS リージョンがないため、顧客の外部復旧設計を呼び出します。アップストリームや相互接続の障害は多様なネットワーク経路を呼び出します。ソフトウェア供給の中断は S3NS の自律性とアップデート戦略を呼び出します。契約や請求の紛争は管理上の継続性と輸出権を呼び出します。

各経路は異なる利用者層に影響を与えます。隔離された分析サービスは内部報告を遅らせる可能性があります。アイデンティティ障害は、コンピューティングが健全なままでも、すべてのアプリケーションの起動を妨げる可能性があります。医療プラットフォームの喪失はケア管理と患者アクセスに影響を与える可能性があります。産業用 ERP の喪失は購買、製造、出荷をブロックする可能性があります。依存性は、クラウドリソース名の見かけの重要さではなく、ビジネス機能によってランク付けされるべきです。

複合障害には特に注意が必要です。メンテナンス中のゾーン障害はスペアキャパシティを少なくします。サイバーインシデントは自動化を無効にしながら、手動サポートの需要を高める可能性があります。リージョンのネットワーク問題は、復旧を意図したバックアップ転送自体を遅くする可能性があります。サプライヤー紛争は緊急のセキュリティ脆弱性と同時に起こる可能性があります。回復力とは、アーキテクチャ図上の3つのボックスの存在ではなく、これらの組み合わせを通じて運用する能力です。

S3NS は、非フランス技術に基づくフレンチクラウドの周りに異常に強力な管理策を構築しました。その成果は、いくつかの障害経路、特に直接的な外部管理や技術サプライヤーによる顧客固有の遠隔シャットダウンを取り除きます。物理学、ソフトウェアの老朽化、ヒューマンエラー、顧客の集中を取り除くものではありません。

重要なワークロードを委託する前に購入者が入手すべき証拠

最初の証拠は配置を説明すべきです。S3NS は適切な機密保持契約の下で、選択されたサービスが3つのデータセンターすべてを使用すること、どのコンポーネントがゾーナルのままか、どれがリージョナルか、どのコントロールプレーン依存関係がゾーンを横断するかを確認できます。顧客はその後、すべてのコンピューティング、ストレージ、アイデンティティ、鍵、ログ、デプロイメントコンポーネントを障害ドメインにマッピングできます。

第二の証拠は残存キャパシティを説明すべきです。各クリティカルマシンとマネージドサービスについて、顧客は同等のキャパシティが予約されているか、または1つのゾーン喪失後に利用可能となる可能性が高いかを知る必要があります。特殊なプロセッサ、大容量メモリ形状、ストレージパフォーマンス、パブリックアドレスが含まれるべきです。別のゾーンでワークロードが再起動する成功した演習は、可用性の形容詞よりも価値があります。

第三の証拠は、機密詳細を公に公開せずに物理的およびネットワークの多様性を説明すべきです。独立した施設およびユーティリティリスク、別々の入り口、ゾーン間経路、キャリア所有権、相互接続終端、フェイルオーバー帯域幅は、管理された保証設定で検証することができます。回答は、単に契約を数えるのではなく、共有依存関係を特定すべきです。

第四の証拠は、修理とエスカレーションを説明すべきです。顧客は、昼夜を問わず誰が応答するか、S3NS のサイトスタッフがいつ関与するか、どの修理が施設またはハードウェアサプライヤーに依存するか、どの部品が現地に保持されているか、顧客データを公開せずに問題がどのように Google に到達するかを知るべきです。大規模インシデントコミュニケーションには帯域外経路が必要です。

第五の証拠はリージョン復旧演習であるべきです。PREMI3NS リージョンは1つしかないため、顧客はデータ、鍵、アイデンティティ、構成、ネットワークエントリを含む代表的なサービスをその外部で復元すべきです。測定された結果はビジネス復旧目標と比較されるべきです。ソースコンソールが利用可能であることを前提とするステップは、その前提なしでもう一度テストされるべきです。

最後に、契約は技術的結果と整合すべきです。認定範囲、サービスレベル、メンテナンス、インシデント支援、データ所在地、下請業者、ソフトウェア供給の継続性、ポータビリティ、削除、解約サポートはすべて、エンジニアがテストしたものと同じサービスを記述すべきです。契約はキャパシティを作り出すことはできませんが、障害前に責任と証拠を利用可能にすることができます。

証拠グレードは「中」である

S3NS はもっともらしいプロジェクトから証拠のある事業者への敷居を越えました。PREMI3NS は一般提供されており、指名された法的主体を持ち、実質的なフレンチチームを雇用し、文書化されたスタンドアロンリージョンを運営し、広範なマネージドサービスカタログを公開し、公的な顧客プログラムを持ち、IaaS、PaaS、CaaS 向けの現行の SecNumCloud 3.2認定を保持しています。これらはマーケティングマップ、休眠会社記録、未検証のクラウドラベルよりも強力なシグナルです。

「強」からの格下げは、公開されていないままのものを反映しています。3つのデータセンター運営者と正確なサイトは指名されていません。ユーティリティ、キャリア、バックボーン、クロスコネクトの多様性は説明されていません。公開されたフリート数、ゾーン退避限界、スペアパーツスケジュール、完全な顧客サポート応答条件はありません。最も重要なのは、PREMI3NS には1つのリージョンしかないことです。その3つのゾーンは可用性を向上させますが、リージョン喪失からのプラットフォーム内復旧を提供しません。

したがって、公平な結論は「フランスの管理がすべてを解決する」でも「Google 技術が主権を無意味にする」でもありません。ANSSI は、Thales Cloud Sécuriséが認定環境を管理し、明示された条件下で非欧州法のアクセスから保護することを立証しました。プラットフォームは依然として Google 技術、フランスのデータセンターインフラ、電力、光ファイバー、ハードウェア供給、S3NS の人員に依存しています。これらの依存関係は特定可能であるため管理できます。それらが消えたふりをして管理することはできません。

購入者にとって、S3NS の最も価値のある特徴は、その境界の明確さかもしれません。このサービスは、認定された管理モデルの下で Google クラウド技術を用いて、Thales 支配下のフランス企業によって運営される、3つの物理的ゾーンを持つ1つのフレンチ自律型クラウドリージョンです。ゾーンを越えて構築してください。残存サイトでのキャパシティを実証してください。物理的および経路の多様性に関する秘密保持証拠を入手してください。リージョンの外にテスト済みの復旧環境を維持してください。そうすれば、主権の約束は、他人のラックに付けられたバッジではなく、運用能力になります。