asten-cloud-bretagne ASTEN CLOUD SAS は、依然としてラック、トランジット、修理窓口に依存するホスティング容量を販売

概要

• Asten Cloud は公開記録上で事業を行っているフランスのクラウドおよびホスティング企業である。フランスの企業検索サービスは、ASTEN CLOUD をグエノウに所在するコンピュータ設備管理の活動中の企業として登録している。Asten 自身のサイトにはブレスト地域の2つのデータセンターが記載されており、RIPE の記録では ASTEN CLOUD SAS が自律システムリソースを保有していることが示されている。
• 最も強力な物理的証拠は一次情報だが具体的である。Asten は、自社のプライベートクラウドがフランス国内の2つのデータセンター、300平方メートルのクリーンルームのホスティングスペース、1,000台以上の物理および仮想サーバーをホストしており、48ラック、冗長電源と冷却、通信事業者の選択肢、アクセス制御、24時間365日のサイトアクセスを備えたハウジングオファーを提供していると述べている。
• ルーティングの状況は弱いというよりは混在している。ASTEN CLOUD SAS として保持されている AS199727 は現在、RIPEstat を通じて7つの IPv4 /24 アナウンスメントと1つの IPv6 /31 で可視化されている。一方、「asten-cloud-bretagne」という名前の ASN である AS206308 は登録されているがアナウンスされていない。したがって、公開ネットワークシグナルは Asten の現在の運用を裏付けているが、ブルターニュという名前の ASN 自体が顧客トラフィックを運んでいるという単純な主張を支持するものではない。
• ここでのバックアップとリカバリは単なるマーケティングの脚注ではない。Asten は、Commvault ベースのバックアップを2つのフランスのデータセンターにわたって提供し、長期保存、片方のデータセンターのロボットを介したオプションのテープバックアップ、定期的なリストアテスト、ビジネス影響分析、正式なリカバリ計画サービスを説明している。これらの主張は顧客のリスクをある程度低減するが、ワークロードレベルの RTO、RPO、フェイルオーバーテストの結果、またはデータセンター喪失後の残存容量は公開されていない。
• エビデンスグレードは中程度である。法的登録、認証ページ、稼働中のルーティング、詳細なサービスページにより、同社は実質的に検証可能であるが、正確な施設住所、実際のラック占有率、キャリアパスの分離、発電機の稼働時間、顧客分布、サポートスタッフの深度、測定されたリカバリ結果は依然として公開記録で公開されていない。

会社は視認できるが、資産は依然としてローカルである

asten-cloud-bretagne ASTEN CLOUD SAS を読み解く上で有用なのは、抽象的なリージョンを持つハイパースケールプラットフォームとしてではなく、地域密着型のフランスのホスティング事業者として捉えることだ。同社の公的な価値提案は、まさに顧客のシステムがブルターニュ、フランス法、Asten のサポートデスクの近くに留まることにある。フランスの企業検索サービスは、SIREN 323789990 で ASTEN CLOUD を特定し、グエノウにアクティブな本社を置き、活動コードがコンピュータ設備管理であることを示している。この登録情報が重要であるのは、法的な裏付けのないクラウドサービスのページは単なる販売の看板に過ぎない可能性があるからだ。ここでは、同社はブルターニュのクラウドストーリーと一致する登録された事業拠点を持っている。

Asten 自身のクラウドページは、クラウドサービスの提案にしては異例なほど物理的である。そこでは、Asten Cloud がフランス国内、具体的にはブルターニュに自社のインフラストラクチャでデータをホストし、ブレスト地域に2つの主権的データセンター、300平方メートルのクリーンルームホスティングスペース、1,000台以上の物理および仮想サーバーをホストしていると説明している。また、このサービスを、外国のパブリッククラウドを再販するラッパーではなく、プライベート認証クラウドとして提示している。これらはすべての顧客ワークロードの証明ではないが、具体的な資産の主張である。部屋、ラック、サーバー、運用スタッフがサービスカタログの背後に存在していなければならない。

同社の沿革ページは、そのフットプリントがどのように発展したかを説明するのに役立つ。Asten は、グループが1995年に設立され、2008年に STTG を買収し、最初のデータセンターの所有者となり、2013年に WhiteBox シェルターデータセンターを創設し、2018年にコロケーション用の新たなブレストデータセンターを購入し、2019年に ISO 27001 認証を取得し、2020年に HDS 認証を取得し、同年に通信事業者になったと述べている。また、スケール指標として、ブルターニュに2つのデータセンター、約140名の専門家、350の顧客、1650万ユーロの売上高を挙げている。これらの数値は一次情報による主張であるため、監査済みの稼働率として扱うべきではないが、同社を、単なる名前だけの存在よりはるかに透明性のあるものにしている。

営業エリアは販売文言では全国、インフラストラクチャの論理では地域的である。Asten は、その専門知識がフランス全土およびそれ以外にも展開されていると述べているが、ホスティングの主張はフィニステールのフランスのデータセンターに固定されている。ホスティングページでは、フィニステールに拠点を置く2つのフランスのデータセンターについて説明し、そのオファーを、フランスおよび欧州の管轄下に留めるべきデータのための主権的ホスティングとして位置付けている。ブルターニュの顧客にとっては、近くの事業者であればエスカレーションパスが短くなり、サイト訪問がより現実的になる。地域外の顧客にとっては、ローカリティは依然として重要だが、依存関係は広域リンク、リモートサポート、Asten のトランジットおよび顧客アクセスパスの回復力へと移行する。

この地理的条件が最初の運用制約である。Asten はクラウド容量をサービスとして販売できるが、その供給は有限な地域資産ベースに結びついている。2つのデータセンターは、物理的、電気的、運用的に十分に独立していれば、意味のある回復力設計になり得る。両サイトが同じキャリアコリドー、保守チーム、燃料供給、変更スケジュール、ベンダー在庫に依存している場合、共通運命クラスタにもなり得る。公開ページは、Asten が2つのサイトをマーケティングしていることを証明しているが、サイト間のフォールトツリーは公開していない。

ラックがクラウドの主張を容量テストに変える

最も具体的な公開容量ページは、Asten のハウジングオファーである。そこでは、顧客は物理サーバーを安全なデータセンターに設置でき、ラックの3分の1からフルラックまで選択でき、ラックサイズは800×1200ミリメートルで各48U、オプションに応じて1 kVA または3 kVA の電力が含まれるとしている。また、データセンターには48ラック、175 kVA の保護された冗長電源供給、冗長冷却、生体認証、デジコード、ロック、火災検知・消火設備、24時間365日の監視、顧客の常時アクセスがあると述べている。これらの詳細は、「ホストされた容量」をテスト可能なものに変えるまさにその種類の事実である。

それらはまた、設置済み容量と使用可能容量が異なる理由を示している。48ラックは床面積の指標である。175 kVA は電気容量の指標である。300平方メートルは部屋の指標である。1,000台以上のホストサーバーは、在庫またはサービス規模の主張である。これらの数値だけでは、現在の空き容量がどれだけ残っているか、電源プラントのどれだけがコミットされているか、冷却のヘッドルームがどれだけ確保されているか、または、一方のサイトが利用できなくなり、残存容量が保護対象のワークロードを吸収しなければならない場合に何が起こるかは、顧客にはわからない。ラックは存在しても満杯かもしれない。UPS は設置されていてもバッテリー駆動時間によって制約されるかもしれない。第2のデータセンターは存在しても、すべての顧客ワークロードを一度に受け入れるのに十分なコールドスペアの計算能力を欠いているかもしれない。

ハウジングページには、データセンターがさまざまな通信事業者に開かれていると記載されている。これは顧客の選択にとって良い文言である。なぜなら、単一のキャリアエッジが、それ以外は冗長なホスティング設計の中で隠れた共通点になり得るからだ。しかし、「さまざまな事業者に開かれている」ことは、アクティブなキャリアの名前、多様な入口、分離されたダクト、独立した meet-me ルーム、またはテスト済みのフェイルオーバーを示すことと同じではない。この課題の中核となる物理的依存関係はまさにここにある。顧客はサーバーを Asten にアウトソースしても、ラックの可用性、クロスコネクトのリードタイム、事業者のメンテナンス、ルーターの障害、故障したポートの実際の修理ウィンドウに依然としてさらされる可能性がある。

Asten のホスティングポートフォリオは、ハウジング、共有ホスティング、HDS ホスティング、アプリケーションホスティング、コンテナホスティングに及ぶ。この幅広さは、複数の運用パターンがあることを示唆している。ハウジングの顧客はサーバーを所有し、Asten にスペース、電源、冷却、セキュリティ、ネットワークアクセスを提供するよう依頼するかもしれない。共有ホスティングの顧客は、Asten 所有のインフラストラクチャ上の仮想サーバーを利用するかもしれない。ソフトウェアパブリッシャーは、ホスティングとマネージドオペレーションの両方を Asten に依存するかもしれない。コンテナの顧客は、物理ラックのレイアウトよりも、プラットフォームのオーケストレーションとレジストリの可用性に関心があるかもしれない。同じデータセンターの停止やキャリア障害でも、各層で責任分担が異なるため、各顧客への影響は異なる。

中心的な経済的緊張は、Asten がプライベートなコンピュータルームの構築からの解放を販売している一方で、多くの顧客の部屋を置き換える共有ルームの資金を調達しなければならないことだ。これは古典的なホスティング経済学のトレードオフである。顧客は設備投資、コンプライアンス作業、ローカルの電源/冷却の心配を回避し、プロバイダーは安全な部屋、有人運用、冗長システムを運営するのに十分な需要を集中させる。プロバイダーは次に、希少なリソースを売りすぎることを避けなければならない。公開証拠は、購入者が鋭い質問をすることを可能にするが、それらに完全には答えていない。現在のラック充填率、コミット済み電力とバースト電力、ピーク外気条件下での冷却冗長性、スペアサーバーの在庫、交換用ハードウェアのリードタイム、空のリカバリ容量を維持するコストは、公開されていない。

認証は約束を絞り込むが、機構を取り除かない

Asten は認証に大きく依存しており、公開ページはバッジだけよりも範囲を明確にしている。認証ページは、Asten Cloud がホスティング、マネージドサービス、ユーザーサポートについて ISO 27001 認証を取得していると述べている。また、物理インフラホスティングとマネージドホスティング活動の両方について HDS 認証を取得しており、物理サイト、ハードウェアインフラ、仮想インフラ、アプリケーションプラットフォーム、管理/運用、外部化バックアップをカバーする6つの HDS 活動領域を含むと説明している。HDS ホスティングページは、6ドメインの枠組みを繰り返し、このサービスが医療およびメディコソーシャルの顧客やソフトウェアパブリッシャーを対象としていると述べている。

これは重要である。なぜなら、HDS は単にセキュリティに関するスローガンではないからだ。それは、場所、アクセス制御、トレーサビリティ、管理、バックアップが重要なセンシティブなワークロードにホスティングの主張を結びつける。Asten の HDS ページは、その医療データホスティングが欧州経済領域外への個人健康データの移転を回避すると述べている。顧客にとって、これは施設運用の上に重ねられたローカリティの約束である。データはフランスのデータセンターに保管され、欧州の法的保護の下、認証されたプロセスによって管理され、制御されたサービスを通じてバックアップされるべきである。これらの層のいずれかがずれれば、サービス価値は変わる。

しかし、認証は容量を無限にするわけでも、停止を不可能にするわけでもない。ISO 27001 は情報セキュリティ管理システムを示す。HDS は医療データホスティング活動の適合性を示す。どちらのページも、顧客ごとのリカバリ時間、待機中のエンジニア数、故障したストレージシェルフの交換平均時間、共有スイッチのメンテナンスカレンダー、2つのデータセンター間の実際の地理的距離とキャリアパスの分離を公開していない。認証は場当たり的な対応のリスクを低減するが、電源、冷却、ハードウェア、人、リンクへの物理的依存を消し去るわけではない。

公共部門向けのオファーは、さらなる需要シグナルを追加する。Asten のコミュニティおよび公共施設向けページは、グループがクラウドおよびホスティングフレームワークである CANUT のブルターニュ地域ロットに選定されたと述べている。公共機関向けに、コロケーション、共有ホスティング、マネージドホスティング、バックアップ、接続性、電話を提示している。これは、公共部門の顧客がしばしば正式な調達、継続性要件、データ主権の選好をもたらすため重要である。また、弱いリカバリ設計のコストを引き上げる。停止は、単なるプライベートテスト環境だけでなく、自治体、学校、公共機関、地域サービスプロバイダーに影響を与える可能性がある。

したがって、正しい結論は冷笑でも盲信でもない。Asten の認証と公共部門へのポジショニングは、真剣な運用態勢を示す意味のある、情報源に裏打ちされたシグナルである。それらは、1ページの再販業者にふさわしいよりも高い信頼レベルを正当化する。しかし、それらは顧客のデューデリジェンスの代替にはならない。購入者は依然として、範囲説明書、証明書の有効期限、除外されたサービス、下請け業者リスト、バックアップ場所、インシデント通知プロセス、契約したワークロードが認証境界内にある証拠を必要とする。

ルーティング証拠が Asten の運用をブルターニュ ASN から分離する

ネットワーク記録には、奇妙だが有用な区別がある。この課題に名前が付けられた ASN、AS206308 は、RIPE でasten-cloud-bretagne ASTEN CLOUD SASとして登録されている。ホルダー情報は、これを ASTEN CLOUD SAS およびグエノウとブレスト地域の住所に結びつけている。しかし、AS206308 の RIPEstat 概要は、アナウンスされていないとマークしており、ルーティングステータスビューは、調査カットオフ時点で可視の IPv4 または IPv6 プレフィックスや観測された隣接ノードを示していない。これは、Asten Cloud がオフラインであることを意味しない。ブルターニュという名前の ASN が、利用可能なルーティング証拠において公的な経路キャリアではないことを意味する。

稼働中のルーティング証拠は代わりに AS199727 を指している。RIPE RDAP は、AS199727を ASTEN CLOUD SAS の下での「asten-cloud-idf」としてリストし、RIPEstat AS 概要は、アナウンスされているとマークしている。そのルーティングステータス結果は、RIPE RIS ピア全体での完全な IPv4 可視性とかなりの IPv6 可視性を示している。アナウンスプレフィックス結果は、現在の観測ウィンドウで7つの IPv4 /24 と1つの IPv6 /31 が可視であることを示し、ASN 隣接データは、AS174 と AS12645 の2つの観測された隣接ノードを示している。

これらの2つの事実は、一緒に保持されなければならない。一方で、Asten は稼働中のルーティングされたインフラストラクチャを持っている。他方で、名前に「bretagne」を含む ASN は静かである。単純な記事は、その区別を崩して「Asten Cloud は ASN を持っている」と言うかもしれない。より良いインフラストラクチャの読み方は、なぜ名前付きの地域 ASN が登録されているが可視でないのか、現在使用されていない設計のために予約されているのか、顧客トラフィックが AS199727 の背後にあるのか、2つの ASN 構成がサイト、レガシー、製品、またはトラフィックエンジニアリングの選択を反映しているのかを問う。公開ルートコレクターはその質問に答えない。

プレフィックス名も、顧客の配置を証明せずにサービス機能を示唆している。RIPE RDAP は、185.189.172.0/24を「HEBERGEMENT」、185.189.173.0/24を「HEBERGEMENT_SEC2」、185.189.174.0/24を「HEBERGEMENT_SEC」、185.37.43.0/24を「HEBEGEMENT-SEC」、185.37.41.0/24を「K8S」、185.37.42.0/24を「HORS-VDOM-INTERNET」と識別している。これらのラベルは有用な公開の手がかりである。ホスティング、セキュアホスティング、Kubernetes のような命名が Asten 管理のアドレス空間に現れている。それらは、特定の IP の背後にあるデータホール、顧客テナント、VLAN、ファイアウォールゾーン、または回復力レベルを明らかにしない。

したがって、経路依存のリスクは、Asten がインターネット上で見えるかどうかではない。見える。リスクは、顧客が自分のワークロードで使用される実際の上流、パス、フェイルオーバー構成を知っているかどうかである。観測された2つのルーティング隣接は1つよりは良いが、BGP 隣接の多様性はファイバーパスの多様性と同じではない。2つのセッションが依然としてダクト、建物の入り口、ルーター、メンテナンスウィンドウ、または商業的依存を共有する可能性がある。高可用性の顧客は、キャリア名、ハンドオフ場所、経路多様性、フェイルオーバーポリシー、メンテナンス通知期間、DDoS 処理、RPKI/IRR 態勢、および最近のフェイルオーバー演習からの証拠を尋ねるべきである。

バックアップはデータ損失リスクを減らすが、リカバリには依然として時間制限がある

Asten のバックアップとリカバリページは、メカニズムと障害思考の両方を挙げているため、証拠セットの中でより強力なページの1つである。それによると、Asten Backup は Commvault を使用し、バックアップを2つのフランスのデータセンターに保存し、長期のカスタマイズ可能な保持期間を提供し、一方のデータセンターのロボットを介してテープバックアップを追加でき、サイバー攻撃に耐えるために切断または分離されたバックアップ概念を使用する。また、このオファーには、隔離環境での定期的なリストアテスト、リカバリ計画サービス、ビジネス影響分析、セキュリティ専門知識に基づく文書化されたリカバリ計画が含まれるとしている。

これは冗長性タスクの良い出発点である。バックアップは単に本番環境の隣にある別のストレージボリュームではない。Asten は複数のメディア、オフサイトロジック、リストアテスト、リカバリ計画について説明している。オプションのテープ層は、オンラインレプリカが破損、暗号化、または削除を忠実に再現できるため、ランサムウェアに対して特に関連性が高い。長期間の保持は、侵害が最初の侵入から数週間または数ヶ月後に発見された場合に役立つ。リストアテストは、復元できないバックアップはリカバリ能力ではないため、重要である。

残るギャップはサービスクロックである。このページは、各ワークロードクラスのデフォルトの RPO または RTO 目標を公開していない。地域的なインシデント中に同時に実行できる顧客リストア数、バックアップトラフィックがどのようにレート制限されるか、バックアップリポジトリが本番環境と同じストレージベンダーを共有するかどうか、テープロボットがすべての顧客を保護するのか、オプションを購入した顧客だけなのかを述べていない。また、同じ停止中に多くの顧客が電話をかけてきた場合に、リストアがどのように優先順位付けされるかも説明していない。顧客は「2つのデータセンターのバックアップ」が迅速な継続性を意味すると信じるかもしれないが、実際の結果は、契約範囲、自動化、ネットワークスループット、クリーンルームの容量、スタッフの可用性、アプリケーションの依存関係に依存する。

データ保護とサービス継続性の違いは見落とされがちである。物理サーバーが故障した場合、バックアップはデータを復元するかもしれないが、正確なコンピュート環境、ライセンス状態、ファイアウォールルール、DNS 設定、アプリケーションの依存関係は復元しないかもしれない。1つのデータセンターが利用できなくなった場合、第2サイトのバックアップはデータを保存できるが、ユーザーが戻る前にコンピュート、ストレージ、IP 到達可能性、アプリケーションのシーケンスが必要になる。サイバー攻撃がアイデンティティシステムを侵害した場合、バックアップデータは存在しても、特権アクセスと信頼決定がボトルネックになる。回復力のあるリカバリ計画は、単にブロックをコピーするのではなく、人と依存関係を振り付けなければならない。

Asten のサービスカタログは、バックアップとマネージドサービスおよびリカバリ計画を組み合わせることで、この点をある程度認識している。購入者の検証タスクは、カタログを証拠に変えることである。最新の成功したリストアテストの日付、テストされたワークロードリスト、測定されたリストア期間、依存関係マップ、認証リカバリ、ネットワーク切り替えステップ、リストア後の検証、緊急宣言の指名された意思決定者。公開ページは、リカバリが Asten のオファーの一部であるという主張を裏付けている。外部の者が特定の顧客がどれだけ早く戻るかを計算することはできない。

サポート要員も容量リソースである

クラウド障害はしばしば技術的なイベントとして説明されるが、修理は人によって行われる。Asten のマネージドサービスページは、そのオファーがオンプレミス、Asten のデータセンター、または共有プラットフォーム上の顧客インフラストラクチャをカバーできると述べている。監視システム、継続的モニタリング、リアルタイムアラート、アラートの修正、セキュリティアップデート、重大な脆弱性に対する緊急パッチについて説明している。また、このサービスは、Asten のサーバーでホストされた外部リソースとオンデマンドサポートを組み合わせることができると述べている。これが、サーバールームをマネージドサービスに変える運用層である。

サポート契約ページは、より平凡だが重要な詳細を追加している。マネージドサービスの範囲外のリクエストは、ポイントベースのサポート契約を通じて処理でき、レベル1の技術者がレベル2および3のエンジニアや専門家にエスカレーションする。これは障害パスにおいて重要である。なぜなら、すべての停止が Asten のコア内部で始まるわけではないからだ。顧客のアプリケーション変更、証明書の有効期限切れ、ファイアウォールリクエスト、軽微な構成タスク、またはハードウェア介入は、含まれる運用と有料サポートの境界に位置する可能性がある。停止中にその境界が不明確な場合、修理は遅くなる。

サポート要員はラックと同じ利用率の問題を抱えている。Asten の沿革ページは、グループに約140人の専門家がいると述べているが、公開記録では、クラウド運用、セキュリティ、フィールドワーク、ヘルプデスク、アプリケーションスペシャリスト、マネージャー、管理機能に分類していない。通常の日には、アラート、計画変更、顧客チケットに十分なスタッフがいるかもしれない。ホスティング、バックアップ、ネットワーク、顧客システムにわたる同時インシデントは、データセンターが電力を消費するよりも早く専門家を消費する可能性がある。

したがって、顧客はサポートを契約リソースとして扱うべきである。問題は「サポートは利用可能か？」だけではない。契約が応答時間、エスカレーショントリガー、重大度レベル、オンコールカバレッジ、変更フリーズ、緊急メンテナンスウィンドウ、顧客責任、インシデント後の証拠を要求する権利を定義しているかどうかである。Asten の公開ページは、マネージド運用とマルチレベルサポートの期待を裏付けている。その期待の背後にある正確なキュー深度や人員計画は公開していない。

これは、公共機関や医療関連のワークロードにとって特に重要である。Asten の HDS ページは、医療データ環境向けの24時間365日の監視と迅速な介入について説明している。自治体や医療ソフトウェアパブリッシャーは、単なるチケット応答以上のものを必要とするかもしれない。文書化されたインシデントブリッジ、優先リストア順序、プライバシー通知サポート、緊急作業中にデータが承認されたホスティング境界内に留まる証拠が必要である。公開マーケティング文言はその方向を指しているが、それが運用上強制可能かどうかを示すのは契約とランブックだけである。

主権は運用境界であり、装飾的なラベルではない

Asten の最も強力な市場主張はローカリティである。メインのクラウドページは、データがフランス国内、ブルターニュの自社インフラストラクチャにホストされており、アメリカのクラウドはなく、そのクラウド主張において下請けもないと述べている。ホスティングページは、クラウドが主権的であり、フランスおよび欧州法の下にあると述べている。HDS ページは、医療データが欧州経済領域外に移転されないと述べている。公共部門ページは、ブルターニュの公共施設に対して同じ論理を売り込んでいる。これらの主張は、データ主権とローカリティを、この記事の正しい制御されたトピックの1つにしている。

しかし、主権は単純さと同じではない。ローカルクラウドにも、ハードウェアサプライヤー、ソフトウェアベンダー、通信事業者、バックアップテクノロジー、セキュリティ製品、顧客アクセスネットワークがある。Asten のマネージドサービスページは、SecNumCloud 要件については、ハイブリッド主権アプローチで Dassault Systemes ブランドである OUTSCALE に依存していると述べている。これは、認定された主権クラウドオプションを必要とする顧客にとって賢明な設計かもしれない。また、購入者は、どのワークロードが Asten 自身のブルターニュデータセンターで動き、どのワークロードが OUTSCALE 環境で動き、どのデータがそれらの間を移動し、各ポイントでどの契約制御が適用されるかを尋ねなければならないことを意味する。

この区別は批判ではなく、ローカリティの実用的な定義である。顧客が通常のホスティングを購入する場合、期待される資産は Asten のブレスト地域のインフラストラクチャかもしれない。顧客がハイブリッド主権サービスを購入する場合、資産境界には、Asten 管理の顧客構内、Asten データセンター、OUTSCALE リソースが含まれるかもしれない。顧客が Microsoft 365 データのバックアップを購入する場合、本番サービスは Microsoft の環境に留まり、バックアップが Asten のフランスのデータセンターに置かれるかもしれない。「souverain（主権的）」という言葉は、実際のサービスパスが描かれるまで評価できない。

法的管轄についても同様である。フランスおよび欧州のルールの下でフランスに保存されたデータは意味のある保護であるが、運用アクセスは依然として管理者、サポートベンダー、監視システム、暗号鍵管理、緊急手順に依存する。Asten の HDS および ISO ページは、これらのプロセスが正式なセキュリティフレームワークの下で管理されているという見方を裏付けている。それらは、どのログが保持され、鍵がどこに保持され、顧客管理者がどのように認証され、国境を越えたベンダーサポートがどのように制限されるかを示していない。

したがって、良い顧客レビューは、主権をスローガンではなく一連の実用的な証明点として扱うべきである。本番データはどこに保存されるか？バックアップはどこに保存されるか？監視ログはどこに保存されるか？誰が各層にアクセスできるか？暗号鍵は顧客制御か、プロバイダー制御か、共有か？ハードウェアが返却、修理、または破壊される場合に何が起こるか？どの下請け業者がデータやメタデータに触れることができるか？公開証拠は、Asten を信頼できるローカルプロバイダーにしているが、顧客の実際のワークロードがローカルパスに従うことを契約が証明しなければならない。

障害パスは5つの実際的なボトルネックに収束する

最初の障害パスは、ラックまたはハードウェア在庫の問題である。ハウジングの顧客は機器を所有するかもしれないが、Asten は依然として部屋、ラック、電源、冷却、アクセス、そしておそらくハンズオン介入を提供する。共有ホスティングの顧客は、Asten のサーバー在庫と交換在庫により直接依存する。ハウジングページの48ラックという数字は、可視の容量境界を与える。1台の顧客サーバーのハードウェア障害は狭いが、冷却、配電、ストレージアレイ、共有スイッチの障害はすぐに広がる可能性がある。リカバリは、スペアパーツ、ベンダーサポート、リモートハンドの可用性、および顧客の変更承認能力に依存する。

2番目の障害パスは電源である。ハウジングページは、データセンターに保護された、UPS バックアップ付きの175 kVA の冗長電力供給があり、移行の背後に発電機があると述べている。この文言は、施設レベルでの電力回復力の主張を裏付けている。バッテリー駆動時間、発電機の燃料自律性、メンテナンススケジュール、負荷テスト結果、電源チェーントポロジー、またはラックがロードされたときにどれだけのヘッドルームが残っているかは公開されていない。Asten が同じ電力エンベロープ内で本番ホスティングとリカバリホスティングの両方を販売する場合、サイト障害後の利用可能ヘッドルームは経済的および技術的な問題になる。

3番目の障害パスは、上流または経路障害である。RIPEstat は AS199727 をアクティブ、AS206308 を非アクティブと見ている。顧客トラフィックが AS199727 に依存している場合、その上流の多様性と物理パスが重要である。一部の製品が公開 BGP で可視でないキャリアハンドオフを使用している場合、顧客のデューデリジェンスは ASN ページを超えなければならない。可視プレフィックスは、ルーター障害、ルートポリシーエラー、メンテナンス、DDoS 緩和問題、キャリア停止、商業的紛争のために消える可能性がある。クラウド顧客は、すべてのサーバーが健全なままでも、これらすべてをアプリケーションのダウンタイムとして感じる。

4番目の障害パスはサポートエスカレーションである。Asten は、監視、アラート修正、セキュリティパッチ、サポートレベルについて説明している。大規模なイベント中、ボトルネックは、ファイアウォール、ハイパーバイザー、ストレージ、バックアップ、DNS、アイデンティティ、顧客アプリケーションを安全に触れることができる専門家の数かもしれない。公共部門や医療の顧客が優先される場合、優先順位は明示的でなければならない。ポイントベースのサポート契約が範囲外作業をカバーする場合、緊急ポリシーは、インシデント中にポイント計算が一時停止するのか、通常通り継続するのかを述べるべきである。

5番目の障害パスは、移行と移植性である。Asten の価値提案は、顧客にデータとシステムをそのデータセンターまたはマネージド環境に移動するよう求める。後で離脱するには、仮想マシン、データベース、バックアップ、ファイアウォールルール、DNS ゾーン、アプリケーションシークレット、監視履歴、アクセスドキュメントをエクスポートする必要があるかもしれない。Asten の公開ページは、保護、継続性、フランスの場所を強調している。標準的な退出形式、一括エクスポート料金、移行リードタイム、または緊急帰還のためのサポートは公開されていない。顧客は、プロバイダー契約の障害の際ではなく、その前にこれらの質問を解決すべきである。

このシステムが障害を起こしたときに影響を受けるのは誰か

影響を受ける当事者は、「顧客」という言葉が示すよりも広い。ハウジングの顧客は、プライベートルームの運用を避けるために自社サーバーを Asten ラックに設置した地元企業かもしれない。共有ホスティングの顧客は、会計、発注、アイデンティティ、コラボレーションシステムが Asten 管理のサーバーで動いている中小企業かもしれない。ソフトウェアパブリッシャーは、Asten のホスティングを使って自身のクライアントにサービスを提供しているかもしれず、Asten のインシデントが下流のアプリケーション停止に変わる。CANUT 連携オファーを利用する公共機関は、市民向けまたは行政サービスを Asten に依存しているかもしれない。HDS ホスティングを使用する医療またはメディコソーシャルのアクターは、患者データの可用性と機密性の義務を負うかもしれない。

影響は障害の種類によっても異なる。短いキャリアのフラップは、データを損傷せずに Web アクセスを壊すかもしれない。ストレージ障害は、アプリケーションをオンラインのままにするが不整合にするかもしれない。バックアップ障害は、リストアが必要になるまで見えないかもしれない。サポートのバックログは、管理可能なインシデントを長期停止に変えるかもしれない。施設のメンテナンスウィンドウは、バッチシステムには許容できるが、公共サービスポータル、クリニックスケジューリングシステム、またはピーク時の小売業者には許容できないかもしれない。

最強の顧客態勢は、署名または更新の前に依存関係をマップすることである。どのサービスが本番クリティカルか？どれが Asten データセンター、顧客構内、またはハイブリッド環境で動くか？どれが第2データセンターにバックアップされているか？どれがテスト済みのリストアを持っているか？リカバリ中に固定 IP アドレス、VPN、ファイアウォールルール、DNS の変更が必要なのはどれか？どのユーザーが Asten に直接電話し、どのユーザーが顧客の自社サービスデスクに電話しなければならないか？これらの質問は手続き的に聞こえるが、リカバリの約束が使える計画になるかどうかを決める。

Asten の公開証拠は、顧客がこれらの質問を精度を持って行えるだけの詳細がある。漠然としたクラウドプロバイダーは抽象化でかわすことができる。Asten は、ラック、データセンター、バックアップ、HDS 範囲、サポート、ルーティングについて十分に公開しており、購入者が主張をテストできる。欠けている部分は、サービスが真剣でない兆候ではなく、真剣な購入者が要求すべき私的な運用詳細である。

購入者のテストは依存関係マップである

最も有用な顧客演習は、移動または保護される特定のシステムについて、Asten の公開主張を依存関係マップに変えることである。仮想マシンからではなく、ビジネスサービスから始める。自治体ポータルは、Web フロントエンド、コンテンツストア、アイデンティティ、DNS、メール、支払いコネクタ、ヘルプデスク連絡先に依存するかもしれない。ヘルスケアアプリケーションは、HDS ホスティング、暗号化バックアップ、アイデンティティフェデレーション、監査ログ、VPN アクセス、Asten がベースプラットフォームを復元した後にアプリケーションをサポートできるベンダーに依存するかもしれない。小売業者は、POS データベース、在庫システム、決済端末、店舗からのインターネットアクセス、夜間の統合に依存するかもしれない。各サービスは異なる破壊点を持っている。

各依存関係について、購入者は、Asten がその層を所有しているのか、管理しているのか、単に収容しているだけか、まったく制御していないのかを尋ねるべきである。この区別は、この記事のタイトルにとって中心的なものだ。ホストされた容量は、Asten 自身のインフラストラクチャが故障したために失敗する可能性がある。また、顧客のサーバーが保証切れである、サードパーティアプリケーションが再構築できない、ファイバープロバイダーが修理目標を逃す、ドメインレジストラが DNS 変更をブロックする、セキュリティインシデントが手動の信頼決定を強いるなどの理由で失敗する可能性もある。Asten が各ケースで適切なパートナーであるかもしれないが、契約はインシデントの前に境界を可視化すべきである。

このマップは、通常サポートと緊急権限も分離すべきである。通常運用中、顧客はチケットパスを通じてファイアウォール変更、ストレージ拡張、またはリストアを要求するかもしれない。大規模なインシデント中、同じ顧客は、リカバリ宣言を承認し、DNS 切り替えを許可し、劣化したパフォーマンスを受け入れ、非必須サービスを一時停止し、ユーザーとコミュニケーションできる指名された人物を必要とするかもしれない。Asten のサポートページは構造化されたサポート体制を示しているが、購入者は依然として名前、役割、エスカレーション時間、重大度の定義を必要とする。決定権限のないリカバリ計画は単なる在庫である。

データの所在地も同じマップに表示されるべきである。本番が Asten のブルターニュデータセンターで動き、バックアップが2つのフランスのデータセンターにまたがり、SecNumCloud 関連サービスが Asten 管理の下で OUTSCALE を使用している場合、それらは3つの異なるローカリティ主張である。各々に別々のラインが必要である。本番がどこに住んでいるか、バックアップがどこに住んでいるか、ログがどこに住んでいるか、管理者がどこから接続するか、暗号鍵がどこに保持されているか、緊急コピーがどこに作成されるかもしれないか。Asten の主権ストーリーが強力であればあるほど、実際のサービスのすべてのコンポーネントが同じポリシーに従うことを証明することがより重要になる。

依存関係マップには、通常時の容量だけでなく、障害後の容量も含めるべきである。2サイト設計は、どちらかのサイトに保護対象サービスを運ぶのに十分なスペアの計算、ストレージ、ライセンス、ネットワーク容量があれば優れたものになり得る。第2サイトが主にバックアップストレージ、選択されたクリティカルワークロード、またはより遅いリカバリのために設計されている場合、より弱くなる可能性がある。Asten の公開バックアップページは、定期的なリストアテストと第2データセンターに言及している。契約は、顧客の環境がそこで稼働することが期待されているかどうか、移動にどれくらいかかるか、どれだけのパフォーマンスが予約されているか、同じ緊急プールを競合する他の顧客は誰かを述べるべきである。

最後に、購入者は退出パスを要求すべきである。これは敵対的な態度ではなく、回復力の一部である。商業紛争、戦略的変更、または持続的な停止の間にプロバイダーから離脱できない顧客は、依存関係を減らしたのではなく、集中させている。Asten にとって、退出テストは、仮想マシンのエクスポート、バックアップのエクスポート、データベースダンプ、暗号鍵、ファイアウォールと VPN 構成、パブリック IP の変更、DNS ゾーン、サポートドキュメント、離脱後の削除証拠をカバーすべきである。真にうまく運営されているサービスは、顧客がどのように入り、インシデントを生き延び、データの制御を失うことなく離脱できるかを説明できるべきである。

証拠を強化するもの

公開記録は現在、中程度の信頼度評価を裏付けている。Asten が、サイト分離、キャリア多様性、独立した電源パス、テスト済みのフェイルオーバー結果、バックアップリストアメトリクス、RTO/RPO 帯域、緊急エスカレーション手順、標準的な退出サポートなど、非機密の2サイト設計の証拠を公開または共有すれば、さらに強力になるだろう。AS206308 の AS199727 に対する役割を説明することも役立つだろう。ブルターニュという名前の ASN が予約済み、歴史的、または私的な取り決めでのみ使用されている場合、そう述べることで、部外者がその非アクティブな公開ステータスを誤読するのを防げるだろう。

顧客にとって、証拠要求は具体的であるべきだ。最新の ISO および HDS 証明書の範囲、その中に含まれるオファーを示すサービスマトリックス、本番とバックアップのデータ所在地声明、サービスに影響を与える可能性のある下請け業者のリスト、リカバリ中の顧客責任を尋ねること。各サイトに入るキャリアパスの数と、それらが物理的に多様かどうかを尋ねること。バックアップテストがどのようにスケジュールされ、失敗がどのように報告され、顧客が結果を目撃または受け取ることができるかどうかを尋ねること。1つのデータセンターが1時間だけでなく1週間失われた場合に何が起こるかを尋ねること。

コストについても同様である。Asten のホスティング経済学は共有インフラストラクチャに依存しているため、独自の安全な部屋を建設したくない顧客にとって魅力的であり得る。しかし、回復力は予約された容量を消費する。予約されたリカバリヘッドルームのない安価なサービスは、テスト済みのフェイルオーバーとスペアの計算能力を持つより高価なサービスと同等ではない。購入者は、基本ホスティング、バックアップ、PRA、マネージドオペレーション、サポートポイント、移行支援を、バンドルされていると仮定するのではなく、区別すべきである。

最終的な判断は、Asten Cloud の容量は精査するのに十分現実的であるということだ。その公開資料は、消えたプロバイダーや純粋な仲介業者のようには読めない。それらは、合法的なフランス企業、ブルターニュのデータセンターの主張、認証範囲、稼働中のルーティングされたアドレス空間、ホスティング製品、バックアップツール、公共部門ターゲティングを示している。この記事の注意点はより狭い。顧客の運用依存関係は「クラウド」という言葉で解決されない。それは Asten のラック、電源プラント、経路選択、バックアップリポジトリ、サポートキュー、リカバリ契約に移動する。それは、それらの物理的および契約上の依存関係が、修理ウィンドウ中に発見されるのではなく、障害の前に測定される場合にのみ、立派なインフラストラクチャ提案である。