asten-cloud-bretagne ASTEN CLOUD SAS のホスティング容量はラック、トランジット、修理時間に依存

概要

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

企業は可視であるが、資産は依然としてローカル

asten-cloud-bretagne ASTEN CLOUD SAS を読み解く有用な方法は、抽象的なリージョンを持つハイパースケールプラットフォームとしてではなく、地域密着型のフランスのホスティング事業者として見ることです。その公開バリュープロポジションは、まさに顧客システムがブルターニュ、フランス法、Asten のサポートデスクに近いままであることです。フランス企業検索サービスは、ASTEN CLOUD を SIREN 323789990で特定し、Gouesnou に本社があり、コンピュータ設備管理の活動コードを持つアクティブな企業としてリストしています。登録シグナルが重要なのは、法的なアンカーなしのクラウドサービスページは、単なる販売フロントに過ぎない可能性があるからです。ここでは、同社はブルターニュのクラウドストーリーに合致する登録済みの事業所を持っています。

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

同社の沿革ページは、そのフットプリントがどのように発展したかを説明するのに役立ちます。Asten によると、グループは1995年に設立され、2008年に STTG を買収し、最初のデータセンターの所有者となり、2013年に WhiteBox シェルターデータセンターを創設し、2018年にコロケーション用の新しいブレストデータセンターを購入し、2019年に ISO 27001認証を取得し、2020年に HDS 認証を取得し、同年に通信事業者になりました。また、規模の指標も示しています。ブルターニュに2つのデータセンター、約140人の専門家、350の顧客、1,650万ユーロの収益です。これらの数字はファーストパーティの主張であるため、監査済みの容量使用率として扱うべきではありませんが、それによって同社はシェル上場企業よりもはるかに透明性が高くなります。

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

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

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

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

また、設置容量と利用可能容量が異なる理由も示しています。48ラックは床面積の尺度です。175kVA は電気容量の尺度です。300平方メートルは部屋の尺度です。1,000を超えるホスト型サーバーは在庫またはサービス規模の主張です。これらの数字のいずれも、今日どれだけの予備容量が残っているか、発電所のうちどれだけがコミットされているか、どれだけの冷却ヘッドルームが確保されているか、または1つのサイトが利用不能になり残存容量が保護されたワークロードを吸収しなければならない場合に何が起こるかを顧客に伝えるものではありません。ラックは存在しても満杯かもしれません。UPS は設置されていてもバッテリーランタイムによって制約されるかもしれません。2つ目のデータセンターは存在しても、すべての顧客ワークロードを一度に引き受けるのに十分なコールドスペアコンピュートがないかもしれません。

ハウジングページは、データセンターが異なる通信事業者に開放されていると述べています。これは顧客選択にとって良い表現です。単一のキャリアエッジは、それ以外は冗長なホスティング設計において隠れた共通点になり得るからです。しかし、「異なる事業者に開放されている」というのは、アクティブなキャリア、多様な入口、分離されたダクト、独立したミートミールーム、テスト済みのフェイルオーバーを明記することとは異なります。このアサインメントの核心的な物理的依存関係はまさにここにあります。顧客はサーバーを 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 の運用を Bretagne ASN から分離する

ネットワーク記録には奇妙だが有用な区別があります。このアサインメントに付けられた ASN、AS206308 は、RIPE にasten-cloud-bretagne ASTEN CLOUD SASとして登録されています。ホルダー情報は、それを ASTEN CLOUD SAS と Gouesnou およびブレスト地域のアドレスに結び付けています。しかし、AS206308 の RIPEstat 概要はアナウンスされていないとマークしており、ルーティングステータスビューには、調査時点で可視の IPv4 または IPv6 プレフィックスはなく、観測されたネイバーもありません。これは Asten Cloud がオフラインであることを意味しません。これは、Bretagne という名前の ASN が利用可能なルーティング証拠においてパブリックルートキャリアではないことを意味します。

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

これらの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つのデータセンターにバックアップを保存し、長期のカスタマイズ可能な保存期間を提供し、1つのデータセンターのロボットによるテープバックアップを追加でき、サイバー攻撃に抵抗するために切断または分離されたバックアップコンセプトを使用しています。また、隔離環境での定期的な復元テスト、復旧計画サービス、事業影響分析、セキュリティ専門知識による文書化された復旧計画が含まれると述べています。

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

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

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

Asten のサービスカタログは、バックアップをマネージドサービスおよび復旧計画と組み合わせることで、この一部を認識しています。買い手の検証タスクは、カタログを証拠に変えることです。最後に成功した復元テストの日付、テスト済みワークロードリスト、測定された復元時間、依存関係マップ、認証リカバリ、ネットワーク切り替え手順、復元後検証、および緊急宣言のための指名された意思決定者。公開ページは、リカバリが Asten の提供の一部であるという主張を支持していますが、部外者が特定の顧客がどれだけ早く戻ってくるかを計算させるものではありません。

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

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

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

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

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

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

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

Asten の最も強力な市場の主張はローカリティです。メインのクラウドページは、データがフランス、ブルターニュの Asten 自身のインフラでホストされ、アメリカのクラウドはなく、そのクラウドの主張においてサブコントラクティングもないと述べています。ホスティングページは、クラウドが主権的であり、フランスおよび欧州法の下にあると述べています。HDS ページは、健康データが欧州経済領域外に転送されないと述べています。公共機関向けページは、ブルターニュの公共団体に対して同じ論理を提示しています。これらの主張は、データ主権とローカリティをこの記事の正しい統制トピックの1つにしています。

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

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

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

したがって、優れた顧客レビューは、主権をスローガンではなく一連の実用的な証明ポイントとして扱うべきです。プロダクションデータはどこに保存されるか？バックアップはどこに保存されるか？監視ログはどこに保存されるか？各レイヤーに誰がアクセスできるか？暗号鍵は顧客管理、プロバイダー管理、または共有か？ハードウェアが返却、修理、廃棄される場合はどうなるか？どのサブコントラクターがデータやメタデータに触れることができるか？公開証拠は Asten を信頼できるローカルプロバイダーにしていますが、契約は依然として顧客の実際のワークロードがローカルパスに従うことを証明しなければなりません。

障害経路は5つの実用的なボトルネックに収束する

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

2番目の障害経路は電力です。ハウジングページは、データセンターが175kVA のセキュアで UPS バックアップ付きの冗長電源供給を備え、その後に発電機があると述べています。この表現は、施設レベルの電力復元力の主張を支持します。しかし、バッテリーランタイム、発電機の燃料自律性、メンテナンススケジュール、負荷テスト結果、電力チェーントポロジー、ラックが装填されたときにどれだけのヘッドルームが残っているかを公開していません。Asten が同じ電力エンベロープ内でプロダクションとリカバリの両方のホスティングを販売している場合、サイト障害後の利用可能なヘッドルームは経済的かつ技術的な問題になります。

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

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

5番目の障害経路は移行と移植性です。Asten のバリュープロポジションは、顧客にデータとシステムをそのデータセンターまたはマネージド環境に移行するよう求めます。後で離れるには、仮想マシン、データベース、バックアップ、ファイアウォールルール、DNS ゾーン、アプリケーションシークレット、監視履歴、アクセス文書のエクスポートが必要になる場合があります。Asten の公開ページは保護、継続性、フランスの場所を強調しています。標準的な出口フォーマット、大量エクスポート料金、移行リードタイム、緊急本国送還のサポートを公開していません。顧客は、プロバイダー契約の失敗時にではなく、その前にこれらの質問を解決すべきです。

このシステムが故障した場合、誰が影響を受けるか

影響を受ける当事者は、「顧客」という言葉が示唆するよりも広範囲です。ハウジング顧客は、プライベートルームを運用することを避けるために自社のサーバーを Asten のラックに設置した地元企業かもしれません。共有ホスティング顧客は、会計、発注、ID、コラボレーションシステムが Asten 管理のサーバーで動作する中小企業かもしれません。ソフトウェア出版社は、自社のクライアントにサービスを提供するために Asten のホスティングを使用し、Asten のインシデントをダウンストリームのアプリケーション停止に変えるかもしれません。CANUT 関連のサービスを使用する公共団体は、市民向けまたは管理サービスを Asten に依存するかもしれません。HDS ホスティングを使用する医療または医療社会関係者は、患者データの可用性と機密性の義務を負う可能性があります。

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

最も強力な顧客の姿勢は、契約前または更新前に依存関係をマッピングすることです。どのサービスがプロダクションクリティカルか？どのサービスが Asten データセンター、顧客構内、またはハイブリッド環境で動作するか？どのサービスが2つ目のデータセンターにバックアップされるか？どのサービスがテスト済みの復元を持つか？どのサービスがリカバリ中に固定 IP アドレス、VPN、ファイアウォールルール、DNS 変更を必要とするか？どのユーザーが Asten に直接電話をかけ、どのユーザーが顧客自身のサービスデスクに電話しなければならないか？これらの質問は手続き的に聞こえますが、リカバリの約束が使用可能な計画になるかどうかを決定します。

Asten の公開証拠は、顧客がこれらの質問を正確に行うのに十分な詳細さです。曖昧なクラウドプロバイダーは抽象論でかわすことができます。Asten は、買い手が主張をテストするために、ラック、データセンター、バックアップ、HDS 範囲、サポート、ルーティングについて十分に公開しています。欠けている部分は、サービスが真剣でない兆候ではなく、真剣な買い手が要求すべきプライベートな運用詳細です。

買い手のテストは依存関係マップである

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

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

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

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

依存関係マップには、通常時の容量だけでなく、障害後の容量を含めるべきです。2サイト設計は、いずれかのサイトが保護されたサービスを実行するのに十分なスペアコンピュート、ストレージ、ライセンス、ネットワーク容量を持っている場合に優れています。セカンドサイトが主にバックアップストレージ、選択されたクリティカルワークロード、または低速リカバリ用に設計されている場合、弱くなる可能性があります。Asten の公開バックアップページは、定期的な復元テストとセカンドデータセンターに言及しています。契約は、顧客の環境がそこで実行されることが期待されているか、移動にどれくらい時間がかかるか、どれだけのパフォーマンスが確保されているか、他のどの顧客が同じ緊急プールを競うかを述べるべきです。

最後に、買い手は出口経路を要求すべきです。これは敵対的な姿勢ではなく、復元力の一部です。商業紛争、戦略変更、または持続的停止中にプロバイダーを離れられない顧客は、依存関係を減らしたのではなく、集中させたことになります。Asten の場合、出口テストは、仮想マシンのエクスポート、バックアップエクスポート、データベースダンプ、暗号鍵、ファイアウォールと VPN 設定、パブリック IP 変更、DNS ゾーン、サポート文書、および離脱後の削除証拠をカバーすべきです。真にうまく運営されているサービスは、顧客がどのように入り、インシデントを生き延び、データの制御を失うことなく去るかを説明できるべきです。

証拠をアップグレードするもの

現在の公開記録は中程度の信頼度の評価を支持しています。Asten が2サイト設計の顧客安全な証拠を公開または共有すれば、より強固になるでしょう。非機密のサイト分離、キャリア多様性、独立した電力パス、テスト済みのフェイルオーバー結果、バックアップ復元メトリクス、RTO/RPO バンド、緊急エスカレーション手順、標準出口サポートなどです。また、AS199727 に対する AS206308 の役割を説明するのにも役立つでしょう。Bretagne という名前の ASN が予約済み、歴史的、またはプライベートな取り決めでのみ使用されている場合、そう述べることで部外者がその非アクティブな公開ステータスを誤解するのを防ぐことができます。

顧客にとって、証拠要求は具体的であるべきです。最新の ISO および HDS 証明書範囲、どのサービスがその範囲内にあるかを示すサービスマトリックス、プロダクションとバックアップのデータロケーションステートメント、サービスに影響を与える可能性のあるサブコントラクターのリスト、リカバリ中の顧客責任を要求します。各サイトに何本のキャリアパスが入っているか、それらが物理的に多様かどうかを尋ねます。バックアップテストがどのようにスケジュールされているか、障害がどのように報告されるか、顧客が結果を目撃または受信できるかを尋ねます。1時間だけでなく、1週間データセンターが失われた場合に何が起こるかを尋ねます。

コストについても同様です。Asten のホスティング経済は共有インフラに依存しており、それが自社のセキュアルームを構築したくない顧客にとって魅力的である理由です。しかし、復元力は予約容量を消費します。予約されたリカバリヘッドルームのない安価なサービスは、テスト済みフェイルオーバーとスペアコンピュートを備えたより高価なサービスと同等ではありません。買い手は、ベースホスティング、バックアップ、PRA、マネージド運用、サポートポイント、移行支援をバンドルされていると想定するのではなく、分離すべきです。

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