Cloud Temple: 製品別の責任証明が必要

まとめ

ANSSI の決定は、CLOUD TEMPLE が提供する認定 IaaS サービスとしてIAAS - SECURE TEMPLEを特定しています。Cloud Temple のコンプライアンスページでは追加の範囲と確認事項が説明されています。これらの記録は、指定されたサービスにとって意味のある証拠ですが、すべての製品、ゾーン、サプライヤー、顧客設定、ワークロードが同じ管理を受けていることを証明するものではありません。
Cloud Temple の製品ページは、実質的に異なる責任範囲を示しています。VMware IaaS、OpenSource IaaS、Object Storage、Private Backbone、Housing は、それぞれレプリケーション、バックアップ、ネットワーキング、顧客管理、物理スペース、可搬性に関する前提が異なります。特に Housing ページは、専有スペース製品が非 SecNumCloud ゾーンにあることを明確にしています。
AS33930、RIPEstat、PeeringDB は、ネットワーク表面の一部を検証可能にします。これらは CLOUD TEMPLE を公的な番号リソース、観測されたアナウンス、交換容量、施設リストに結び付けますが、トラフィック量、予備容量、経路多様性、顧客パス選択、サプライヤーの役割、リストされた施設の所有権を確定するものではありません。
実務上のデューデリジェンスは、購入する設計ごとに4つの要素を統合することです。それは、正確な認定または保証されたサービス、提供されるアーキテクチャ、運用責任の分担、およびサプライヤー、インシデント、復旧、退出に関する契約上の証拠です。ポートフォリオレベルのバッジでは、顧客に代わってこの統合を実行することはできません。

最も有用な開示は例外である

Cloud Temple のハウジングページにある小さな一文は、一般的な保証が並ぶページよりも分析的な価値があります。同社は共有または専有ラック、二重電源系統、ミートミールーム接続、オンサイトサポートを説明していますが、専有スペース製品が非 SecNumCloud ゾーンでホストされていることも明記しています。これは開示の欠陥ではありません。ポートフォリオの読み方を示す最も明確なガイドです。

この区別が重要なのは、購入者がクラウドプロバイダーを最初に最も強力な保証を通じて知ることが多いからです。この場合、公的な証拠には ANSSI の認定決定、SecNumCloud 3.2について議論するコンプライアンスページ、認定サービスの言葉を使用する製品資料が含まれます。これらの証拠を隣接するすべてのオファリングに拡大解釈するのは簡単です。ハウジングページはその近道を防ぎます。顧客は同じプロバイダーから購入し、同じ契約相手と交渉しても、選択したサービスが変われば異なる管理環境に入る可能性があります。

この境界は運用上のものであり、意味上のものではありません。ハウジングは顧客に物理スペースと関連するサイトサービスを提供します。IaaS は抽象化されたコンピューティングプラットフォームを提供します。オブジェクトストレージには独自のレプリケーション、インターフェース、保持動作があります。プライベートバックボーンは回線、アドレス、VLAN、セキュリティ管理、トポロジ選択を導入します。これらの製品は組み合わせることができますが、組み合わせによって個別の範囲が消えるわけではありません。それらの間の遷移が生まれます。

したがって、正しい質問は、Cloud Temple が広い意味で「SecNumCloud プロバイダー」であるかどうかではありません。提案されたアーキテクチャにおいて、正確なサービス、ゾーン、オプション、サポートコンポーネントが依拠する証拠の範囲内にあるかどうかです。ハウジングの開示は、その答えがポジションごとに変わることを可視化します。真剣な評価は、調達から運用、退出に至るまでこの製品レベルを維持すべきです。

認定は指定されたサービスに適用される

公的記録の中で最も強力な独立した証拠は具体的です。ANSSI の公開決定はIAAS - SECURE TEMPLEを挙げ、IaaS として説明し、CLOUD TEMPLE が提供し、認定の継続的な準拠を条件としています。名前が重要です。条件性も重要です。認定決定はプロバイダーのすべての活動に対する抽象的な承認ではありません。サービスと限定された保証状態を特定します。

Cloud Temple のコンプライアンス資料は、公的なイメージを拡張しますが、普遍的なものにはしません。IaaS Secure Temple と PaaS OpenShift の SecNumCloud 3.2範囲を提示し、HDS、ISO 27001、C5、その他の保証資料について議論します。これらの指定は有用な出発点ですが、互換性はありません。それぞれが独自の主題、範囲、期間、証拠目的を持っています。複数がコンプライアンスページに表示されても、Cloud Temple が販売するすべてのものが同じようにカバーされているという単一の主張に凝縮すべきではありません。

購入者にとって、正確な命名は契約書と設計文書に残る必要があります。ANSSI 決定のIAAS - SECURE TEMPLE、商談での Secure Temple、注文書上の特定の IaaS 構成、実際にプロビジョニングされたリソースは、同じ意図されたサービス境界を参照しなければなりません。プロジェクトが OpenShift、オブジェクトストレージ、プライベートバックボーン、ハウジング、外部回線も使用する場合、追加ごとに独自の回答が必要です。それは関連範囲に含まれているのか、単に隣接しているのか、範囲外なのか？

時間的側面も重要です。公的資料で説明されている決定は定義された有効期間を持ち、継続的な準拠に依存します。これは規律ある証拠カレンダーをサポートします。どの決定または証明書に依拠したか、それがいつ有効だったか、どの正確なサービスを指定したか、ステータスや範囲が変わった場合にどうなるかを文書化します。将来の認定を予測したり、プロバイダーレベルの決定が最新であるからといって顧客の設定が準拠し続けていることを証明したりするものではありません。

法的な身元はディレクトリラベルよりも明確である

フランスの公開企業検索 API は、CLOUD TEMPLE を SIREN 825400336、2017年1月17日設立、データ処理、ホスティングおよび関連活動に分類される活動中の法人として特定しています。本社は Puteaux の1-7 Le Belvedere, 1 Cours Valmy に所在します。Cloud Temple ウェブサイトの利用条件は、発行者を同じ住所の株主1名を持つフランスの簡易株式会社として特定しています。これらの記録は、ここで議論されているサービスと公開ネットワーク ID の安定した契約相手アンカーを提供します。

ここでも命名の規律が重要です。BTW ディレクトリは TEMPLE Cloud Temple SAS を既存の企業呼称として使用しているため、この文字列が概要に表示されます。公的証拠は CLOUD TEMPLE を法的かつ読者向けの ID としてサポートしています。TEMPLE Cloud Temple SAS を公式の現在の法的名称として確立するものではなく、この記事はそれをそのように扱いません。

契約相手の身元は必要ですが、サービス責任には十分ではありません。一致する法的名称、登録番号、住所は、購入者にどの組織が条件を公開し、認定決定に登場するかを示します。特定の施設を運営する第三者、回線を提供する者、コンポーネントを供給する者、トラフィックを輸送する者は示しません。また、特定の義務が Cloud Temple、顧客、または他のサプライヤーにあるかどうかも回答しません。これらの回答は、特定された法的契約相手にリンクされたサービス計画、アーキテクチャ記録、およびサポート保証証拠に属します。

ポートフォリオには責任マップが必要

Cloud Temple の公開カタログは、単一のスタックではなく、一連の管理面として理解するのが最善です。一方の端では、認定 IaaS サービスが広範なプラットフォーム責任をプロバイダーに置くことができます。もう一方の端では、ハウジングは顧客自身の機器と多くの運用上の決定を、明示的に SecNumCloud ゾーン外にある物理サービス内に残します。これらの端の間には、プロバイダーが運用するインフラストラクチャと顧客が選択したトポロジ、保持、またはワークロード構成を混合する製品があります。

少なくとも4つの層をマッピングする必要があります。第1はサービス自体：正確な製品とオプションは何か？第2はプロビジョニング：実際に選択されたゾーン、ホスト、ストレージクラス、バックアップ設定、アドレス、回線は何か？第3は運用：誰が監視、パッチ適用、設定、テスト、変更承認、コンポーネント障害対応を行うか？第4は証拠：各管理主張をサポートする認定、証明書、レポート、サプライヤー文書、または契約スケジュールは何か？

これらの層は、ロゴや製品ファミリー名に凝縮することはできません。認定サービスでも、顧客がネットワークとアクセスを正しく設定する必要がある場合があります。レプリケーションされたストレージ製品でも、保持決定とテストされた抽出手順が必要な場合があります。マルチゾーンオプションは存在しても選択されていない可能性があります。指定された復旧目標は、購入された設計と両当事者の措置に依存する場合があります。施設リストは、どの機器やサービスがそこにあるかを示さずに場所を特定する場合があります。

したがって、責任マップはギャップを明らかにするのに十分具体的でなければなりません。アプリケーションが IaaS、オブジェクトストレージ、プライベート回線に依存する場合、証拠は3つの製品境界とそれらの間の遷移を示す必要があります。ハウジングが機器やレガシーシステムのために追加される場合、その非 SecNumCloud ステータスは可視のままであり、周囲のプラットフォームに関する一般的な声明に吸収されないようにする必要があります。Cloud Temple の開示の価値は、購入者にこのマップを構築するために必要な生の区別を提供することです。残りの作業は、それらを購入されたアーキテクチャに結び付けることです。

VMware IaaS は目標を公開し、結果は公開しない

VMware IaaS ページは、比較的豊富なサービス設計を説明しています。Cloud Temple は、専用コンピュート、ネットワーク、ストレージ、バックアップインフラを提供し、マルチゾーン展開を提供し、非同期ストレージレプリケーションを使用すると述べています。復旧ポイント目標15分、復旧時間目標4時間未満、可用性99.99%を挙げています。これらはプロバイダーが公開した仕様です。意図されたサービスを測定可能にしますが、特定の顧客環境がどのように機能したかの観測ではありません。

この区別は回復力分析にとって不可欠です。指定された復旧ポイント目標は、該当条件下での許容データ損失の目標を説明します。すべてのワークロードが範囲内であったこと、障害時にレプリケーションが健全であったこと、またはアプリケーション整合性のある復旧が達成されたことを証明するものではありません。復旧時間目標は復旧の目標を説明しますが、依存関係、資格情報、ネットワークルール、アプリケーションチームが実際にそのウィンドウ内で復旧を完了した証拠ではありません。可用性の文言も、顧客の結果に適用する前に、契約上の定義、除外事項、測定ポイント、救済措置が必要です。

「専用」という言葉もサービス固有の解釈が必要です。ページはそれをコンピュート、ネットワーク、ストレージ、バックアップインフラに結び付けており、これは実質的な説明です。購入者は、発注された設計のどの要素が専用であるか、共通の管理または施設依存関係がどこに残っているか、境界がどのように証明されるかを知る必要があります。マルチゾーン機能も同様の扱いが必要です。どのゾーンが選択されたか、どのコンポーネントがゾーン間で拡張されるか、どの依存関係が依然として共有される可能性があるか？

これらの質問はいずれも製品ページと矛盾しません。これらは、その主張が運用上有用になる方法です。ページは、テスト計画と契約マトリックスに組み込むことができる設計機能と数値目標を提供します。独立した証拠は、購入されたアーキテクチャ、監視記録、演習結果、該当するサービス条件から得られます。この接続なしでは、公開された数値は Cloud Temple に帰属し、実際の SLA パフォーマンスや復旧成功の主張から分離されるべきです。

OpenSource IaaS は別の境界線を引く

Cloud Temple の OpenSource IaaS ページは、Xen 仮想化、2ホスト高可用性、ライブマイグレーション、オブジェクトストレージバックアップ、3つのアベイラビリティゾーンへの自動バックアップ分散を説明しています。語彙は VMware オファリングと重複しますが、管理パターンは同一ではありません。仮想化、ホスト、バックアップの説明が異なるため、保証をある IaaS 製品から別の IaaS 製品に単純に移行することはできません。

2ホスト高可用性はプラットフォーム設計の声明です。顧客にとってのその意味は、ワークロード配置、ホスト独立性、共有ストレージまたはネットワーク依存関係、メカニズムが対処する障害モードに依存します。ライブマイグレーションはメンテナンスとワークロード移動をサポートできますが、それ自体で災害復旧結果を提供するわけではありません。オブジェクトストレージに配置され3つのアベイラビリティゾーンに分散されたバックアップは、別の回復力層を追加しますが、バックアップコピーの存在と分散は、使用可能な復旧が行われたことを証明しません。

運用の引き継ぎも層ごとに異なります。Cloud Temple はホストレベルのメカニズム、移行機能、バックアップ分散を提供できますが、顧客は契約に応じて、ゲスト設定、アプリケーション整合性、資格情報、保持決定、復旧受入れに対して責任を負い続けます。公開ページは顧客ごとの正確な割り当てを定めていません。しかし、この製品について、VMware の説明やポートフォリオレベルのコンプライアンス主張から推測するのではなく、この割り当てを書面で記録する必要がある理由を示しています。

有用な評価は、公開された各メカニズムを障害シナリオに結び付けます。2ホスト可用性は一部のホストイベントに対処します。ライブマイグレーションは一部の計画または発生条件に対処します。分散バックアップはコピーの保持に対処します。これらのいずれも、アプリケーション障害、資格情報の侵害、誤った保持ポリシーによる削除、プラットフォーム外の依存関係を必ずしも解決しません。ポイントはアーキテクチャを軽視することではありません。各管理が何のために設計されたか、誰がそれを有効化または検証する必要があるか、顧客の実装がそれを活用できることを示す証拠は何かを特定することです。

オブジェクトストレージは可搬性を具体的かつ条件的にする

オブジェクトストレージページは、回復力と退出の両方に異常に関連します。Cloud Temple はこのサービスを SecNumCloud 認定、S3 互換、3つのアベイラビリティゾーンにレプリケーション、出力料金なしと販売しています。また、Object Lock に関連する制限も指摘しています。これらの声明は有用な組み合わせを明らかにします。一方で保証と可搬性機能、他方で変更を制限する可能性のある保持動作です。

S3 互換性は、使い慣れたインターフェースが一般的なツールとワークフローをサポートできるため、アプリケーションの摩擦を減らすことができます。ただし、互換性は、すべての API 動作、ポリシーモデル、メタデータフィールド、ライフサイクルルール、運用ツールが変更なく移行することを保証するものではありません。真の退出計画には、プロトコルラベルだけでなく、アプリケーションが使用するもののインベントリが必要です。また、ターゲット、資格情報、転送方法、整合性チェック、データ移動に十分な時間も必要です。

プロバイダーが提示する出力料金なしは、潜在的な価格構成要素を除去します。しかし、退出が無料であることを確定するものではありません。技術作業、ターゲット料金、一時的な二重保存、回線容量、リクエストコスト、検証、アプリケーション変更が依然として経済性に影響を与える可能性があります。また、希望する日付までに転送が完了することを証明するものでもありません。スループットとタイミングは、公開ページが文書化していないプロビジョニングされた状況に依存します。

Object Lock は責任の境界を明確にします。変更や削除を防ぐ保持は貴重ですが、同じ制約が移行と閉鎖に影響を与える可能性があります。購入者は、誰がモードと期間を選択するか、法的またはポリシー上の義務がどのように表現されるか、ロックされたものをコピーできるか、そしていつ削除が可能になるかを知るべきです。公開資料は制限の存在をサポートしますが、普遍的な退出結果をサポートするものではありません。したがって、最も強い解釈は条件的です。Cloud Temple は可搬性と回復力のあるストレージをサポートできる機能を公開していますが、顧客の設定とテストされた抽出プロセスが、これらの機能が必要な結果を提供するかどうかを決定します。

プライベートバックボーンはトポロジ決定を顧客に委ねる

プライベートバックボーンページは、リージョナル VPLS ネットワーク、パブリック IPv4 および IPv6 割り当て、Anti-DDoS 機能、VLAN 制御、1または10 Gbps の外部または専用回線を説明しています。また、顧客がトポロジとセキュリティ機器の手動制御を保持できるとも述べています。この最後の点は脚注ではありません。運用モデルの重要な部分をサービス境界の顧客側に置きます。

プロバイダーが運用するバックボーンは、最終的なアプリケーションパスを決定せずに、トランスポート、アドレッシング、保護機能を提供できます。VLAN 設計、経路選択、セキュリティ機器ポリシー、クラウドゾーン、ハウジングエリア、外部サイト間の接続は、顧客の決定を反映する可能性があります。手動制御は柔軟性を提供しますが、プロバイダーのプラットフォーム管理が、顧客が作成したすべての単一障害点やポリシーエラーを防止できると見なせないことも意味します。

宣伝されている回線レートは製品オプションであり、購入された容量または観測された予備力の証拠ではありません。10 Gbps オプションは、顧客がそれを注文したこと、エンドツーエンドパスがそのレートで動作すること、またはインシデント時に十分な予備容量があることを証明しません。同様に、パブリック IPv4 および IPv6 の可用性は、特定のサービスのアドレス割り当てについて何も語りません。Anti-DDoS の文言は管理カテゴリを特定しますが、評価は依然として有効化条件、保護対象トラフィック、ハンドオフポイント、顧客義務を必要とします。

この混合管理モデルは、アーキテクチャ証拠が一般的なプロバイダー証拠よりも価値を持つポイントです。図は、Cloud Temple がどのセグメントを運用するか、顧客がどの機器またはポリシーを管理するか、サードパーティの回線がどこで入るかを特定する必要があります。変更およびインシデント手順は、各層を誰が変更できるか、両当事者がどのように調整するかを定める必要があります。公開ページは設定可能なネットワークサービスの存在をサポートします。顧客のトポロジ、経路選択、セキュリティ体制を明らかにするものではなく、これらのプライベートな詳細は製品カタログから推測されるべきではありません。

AS33930 は身元を固定し、性能は固定しない

公開ネットワーク記録は、Cloud Temple に検証可能なインフラ ID を提供します。RIPE RDAP は AS33930 を CLOUD-TEMPLE の下で特定します。公開検証時点で、RIPEstat は8つの IPv4 および IPv6 プレフィックスのアナウンスを観測しました。これらの記録は、運用中のネットワークを、公開番号リソースの痕跡を残さないクラウドブランドから区別するのに役立ちます。

証拠は限定的です。RDAP は管理登録システムであるため、自律システムリソースの帰属をサポートします。その背後で実行されている完全なサービスを説明するものではありません。RIPEstat の観測は、特定の検証時点でプレフィックスがルーティングデータに可視であったことを示します。トラフィック、使用可能な顧客容量、アプリケーション到達可能性、契約サービスを測定するものではありません。プレフィックスは、顧客ワークロードがそれをどのように使用するかを証明せずにアナウンスされる可能性があり、プライベートサービスは独立した公開アナウンスとして表示されなくても重要であり得ます。

自律システム番号は、アーキテクチャ図に変換するのが特に誘惑的です。研究者は、それがすべてのアップストリーム、すべての経路、完全な冗長設計を特定すると想定するかもしれません。この記録はそれらの結論をサポートしません。AS33930 は公開ルーティング ID を確立します。経路多様性、予備接続、地理的独立性、フェイルオーバー動作、顧客パケットがたどった経路を証明するものではありません。

デューデリジェンスのために、ASN は調整キーとして最もよく使用されます。PeeringDB エントリ、観測されたプレフィックス、顧客設計に書き込まれたネットワーク識別子と比較できます。差異は疑問を提起する可能性があります。購入されたサービスに属するアドレスはどれか、どのパスがプライベートか、どの当事者がプレフィックスをアナウンスするか？回答は、最新の技術的および契約上の証拠から得る必要があります。公開レジストリは調査に安定した出発点を提供しますが、性能評価は提供しません。

PeeringDB は開示された場所を追加し、施設所有権は追加しない

PeeringDB は別の種類の可視性を追加します。その Cloud Temple エントリは、30の IPv4 および10の IPv6 プレフィックス、オープンピアリングポリシー、パリの2つの報告された10G 交換プレゼンス、DATA4、Digital Realty、Equinix、Telehouse を含む施設をリストしています。これは、ネットワークが接続できると主張する場所と、ディレクトリに報告されたリソースの範囲に関する有用な開示です。

数字は、異なるものを説明しているため、RIPEstat の8つの IPv4 および IPv6 プレフィックスの観測と矛盾しません。PeeringDB のプレフィックス制限または数はディレクトリフィールドです。RIPEstat は、そのシステムが検証時にアナウンスされたと観測したものを報告します。いずれも暗黙的に他方で置き換えるべきではありません。さらに重要なことに、いずれもトラフィック測定ではありません。記録は負荷、ピーク使用率、顧客分布、予備容量を示しません。

施設名も同様の注意が必要です。PeeringDB エントリは、接続目的でネットワークを場所に配置できます。Cloud Temple が建物を所有していること、施設全体を管理していること、特定の量のスペースを占有していること、リストされた各場所で同じ製品を提供していることを証明するものではありません。したがって、DATA4、Digital Realty、Equinix、Telehouse は、公開ネットワークディレクトリ内の指定された施設または施設運営者として理解されるべきであり、Cloud Temple に帰属する資産としてではありません。

パリの2つの報告された10G 交換プレゼンスは、公開接続インターフェースをより具体的にしますが、それでも多様な経路や回復力のある顧客プロビジョニングを証明するものではありません。2つの報告されたプレゼンスは、リストに表示されない依存関係を共有する可能性があり、顧客トラフィックはそこにキャプチャされていない取り決めに従う可能性があります。オープンピアリングは宣言されたポリシーを説明しますが、すべての要求が受け入れられることやピアリングがトランジットを置き換えることを約束するものではありません。PeeringDB は、それが何であるか、つまり詳細な設計に対してチェックできる開示層として使用され、その設計の代わりとしてではない場合に正確に価値があります。

ハウジングは別の運用オファリングである

ハウジングは物理層を前面に押し出します。Cloud Temple は共有または専有ラック、二重電源系統、ミートミールーム接続、オンサイトサポートを説明しています。各機能は、施設に機器を設置する顧客にとって重要であり得ます。しかし、同じページの非 SecNumCloud ゾーン警告は、同じポートフォリオに表示されるという理由だけで、オファリングが別のサービスの認定を継承してはならないと述べています。

物理的な責任分担も IaaS とは異なります。ハウジングでは、顧客が機器を所有または管理し、ハードウェアライフサイクル、システム設定、その上で実行されるアプリケーションに対して責任を負い続けます。一方、Cloud Temple はスペースと指定されたサイトサービスを提供します。正確な分担は契約によります。公開ページはすべての義務を定めているわけではありません。オンサイトサポートは多くの可能なタスクを含む可能性があり、マーケティング用語だけでは応答時間、承認、スペアパーツの可用性、修理の成功を確立しません。

二重電源系統は設計上の特徴ですが、エンドツーエンドの電源独立性の証拠ではありません。有用性は顧客の機器の接続方法と、簡単な説明を超えた共通の依存関係に依存します。ミートミールーム接続は接続のオプションを生み出しますが、顧客が多様なキャリアや物理的に分離されたパスを注文したことを証明するものではありません。共有または専有ラックの指定はスペースについて何かを語りますが、より広い施設の所有権については語りません。

したがって、この製品は独自の証拠パッケージに値します。指定された場所と運営者、スペース割り当て、電源設計、アクセス手順、サポート範囲、クロスコネクト、顧客機器インベントリ、インシデント責任。これらの詳細はいずれもウェブページや PeeringDB から推定されるべきではありません。公開資料はオファリングと明確な認定境界を確立します。購入者のプライベート文書は、購入された実装を確立する必要があります。

コンプライアンスラベルはワークロードレベルの接続を必要とする

コンプライアンスページは、実質的な保証面を提示します。SecNumCloud 3.2範囲は HDS、ISO 27001、C5、関連資料と並んでおり、ANSSI の決定は独立してIAAS - SECURE TEMPLEを挙げています。調達チームにとって、このコレクションはデューデリジェンスへの複数の経路を提供するため価値があります。また、範囲エラーが最も発生しやすいポイントでもあります。

ラベルは、それが設計されスコープされた質問にのみ答えることができます。管理システム証明書は、すべての技術的結果を自動的に認証するわけではありません。健康データホスティングステータスは、該当するサービスと顧客設定なしではすべてのワークロードを準拠させるわけではありません。名前付き IaaS に結び付けられたクラウド保証認定は、プロバイダー自身が SecNumCloud ゾーン外と特定するハウジングには流れ込みません。密接に関連するプラットフォームサービスでも、正確な範囲の確認が必要です。

欠けている接続は、保証アーティファクトとプロビジョニングされたワークロードの間にあります。有用な証拠は、サービス名、バージョンまたはオプション、該当するゾーン、顧客アーキテクチャ、共有責任管理、証拠期間、除外されたコンポーネントを特定します。その後、各要件をプロバイダー、顧客、第三者に割り当てます。これは証明書の収集よりも要求が厳しいですが、よくあるエラーを防ぎます。それは、真正で最新であるが、評価対象のコンポーネントには無関係な証拠です。

Cloud Temple の公開特異性は、このマッピングを原則として可能にします。同社は資料内で IaaS Secure Temple、PaaS OpenShift、Object Storage、Private Backbone、Housing を区別しています。購入者はこれらの区別を保持し、単一の「認定」行で置き換えるべきではありません。結果は懐疑主義そのものではありません。保証が存在する場所と追加の証拠が必要な場所のより正確な表現です。

機密証拠は証拠連鎖の一部である

Cloud Temple は、詳細な管理、サプライヤー証明書、ISAE 3402資料が機密保持の下で顧客に利用可能になり得ると述べています。これは公開証拠と顧客デューデリジェンスの間に合理的な分離を生み出します。公開ページは特定のサービス、管理、保証アーティファクトが存在することを述べることができます。機密レポートとサプライヤー文書は、範囲、例外、依存関係をテストするために必要な詳細を、運用情報を公開ウェブにさらさずに提供できます。

機密性は、外部の読者がそれらを閲覧できないという理由だけで証拠を弱めるわけではありません。誰が主張を検証できるか、どのような条件で行うかを変更します。非公開資料に依拠する顧客は、文書タイトル、発行者、対象期間、範囲、例外、監査日、監査人を記録する必要があります。結論は証拠よりも広くすべきではありません。「機密保持の下で監査済み」は、監査が繰り返され異議を唱えられるのに十分具体的である場合にのみ有用です。

サプライヤー証明書は、Cloud Temple サービスがサードパーティの施設やコンポーネントに依存する場合に特に重要です。プロバイダーは契約上の契約相手であり続けることができますが、ある層の保証は別の組織から来ます。証明書は役立つ可能性がありますが、実際のサプライヤー、場所、サービス、期間にリンクされる必要があります。無関係または期限切れのアーティファクトは連鎖を閉じません。

したがって、公開記録には意図されたエッジがあります。研究者に、より強力な文書がどこに存在すべきかを特定するのに十分な情報を提供しますが、その内容を証明することはできません。この記事は、資料が利用可能であるという声明から、サプライヤー性能、監査結果、隠された管理を推定しません。機密性の下での可用性を、資格のある顧客が追求できるデューデリジェンス経路として扱います。

サードパーティ依存関係は可視のままでなければならない

クラウドポートフォリオは、複数の運用層にわたる商用インターフェースを提示することがよくあります。顧客は Cloud Temple と契約できますが、施設運営者が建物環境を提供し、交換が接続をサポートし、キャリアが回線を提供し、顧客自身がセキュリティ機器やトポロジを管理します。公開ソースは可能な場所とサービス特徴を特定しますが、すべての依存関係を完全にリストまたはマッピングするわけではありません。

このギャップは、責任と管理が同じではないため重要です。Cloud Temple はサービス結果に対する契約上の責任を負うことができますが、提供の一部をサプライヤーに依存します。あるいは、回線や顧客主導の機器がプロバイダーの義務の範囲外にある場合があります。これを認識する唯一の信頼できる方法は、サービス計画、サプライヤー証拠、アーキテクチャハンドオフに従うことです。PeeringDB の施設エントリや製品ページの参照だけで責任を割り当てることはできません。

施設所有権は明確な例です。ディレクトリは DATA4、Digital Realty、Equinix、Telehouse をリストしますが、Cloud Temple がこれらの施設のいずれかを所有していることは示しません。また、各場所でどの製品が利用可能かも特定しません。リストされたすべての場所を統合された Cloud Temple 資産として扱うことは、不動産管理とサービスカバレッジの両方を過大評価することになります。

運用上の対応は、製品レベルの依存関係レジスタを維持することです。重要なコンポーネントごとに、提供当事者、Cloud Temple の義務、顧客の義務、保証証拠、通知契約、依存関係が変更された場合のフォールバックを特定する必要があります。これは、認定プラットフォームが非認定ハウジングや顧客選択の接続性と出会う場合に特に重要です。移行は完全に機能するかもしれませんが、プロバイダー名の便宜によって隠されるのではなく、設計され証明される必要があります。

ホスティング経済性は価格機能から読み取れない

公開資料には、直接的な経済的影響を持つ機能が含まれています。Object Storage は出力料金なしで提示されます。Private Backbone は指定されたレート1または10 Gbps の外部または専用回線を製品オプションとして提供します。Housing はラックスペース、電力、接続、オンサイトサポートを導入します。IaaS 製品は、コンピュート、ネットワーク、ストレージ、バックアップをさまざまな方法で組み合わせます。これらの決定は、バンドルされたサービス、顧客作業、サードパーティ依存関係の間でコストをシフトします。

出力料金なしは、魅力的な用語が総コストを代表すべきではない理由の最も明確な例です。転送料金の除去は、ルーチン移動や最終的な移行を安くする可能性があります。実際の退出予算には、エンジニアリング、ターゲットサービス、一時的な重複、整合性チェック、アプリケーション変更、十分な接続性が依然として含まれる場合があります。Object Lock は時間的制約を追加する可能性があります。公開証拠は宣伝された出力料金の不在をサポートしますが、無料または即時の退出の保証はサポートしません。

専用インフラは別のトレードオフを生み出します。購入者により明確なリソース境界や性能計画を与えることができますが、経済性は注文容量、期間、使用率、含まれる運用サービスに依存します。公的な99.99%可用性声明や復旧目標は、金銭的救済、除外事項、ダウンタイムのビジネス価値を明らかにしません。これらは契約と顧客自身の影響モデルに属します。

ハウジングはハードウェア選択とライフサイクル責任を顧客に移すことができ、マネージドクラウドはより多くのプラットフォーム作業をプロバイダーに置くことができます。どちらも本質的に常に安いわけではありません。意味のある比較には、人員時間、スペアパーツ、移行作業、保証作業、クロスコネクト、バックアップテスト、必要な管理範囲を満たすコストが含まれます。Cloud Temple のポートフォリオは、顧客にインフラを構成する複数の方法を提供します。公開ページは、特定のワークロードにとってどの組み合わせが経済的に最適かを証明しません。

可搬性は想定ではなくリハーサルされなければならない

Object Storage は、S3 互換性と出力料金なしを通じてポートフォリオの最も明示的な可搬性語彙を提供します。VMware および Xen 環境、バックアップ、ネットワーク割り当て、ハウジング機器は、ページが広範な退出約束を行わなくても、他の移動問題を生み出します。これらは一緒になって、退出が単一のアクションではないことを示します。データ、マシン、設定、アドレス、セキュリティポリシー、物理資産、契約はそれぞれ異なる経路をたどる可能性があります。

信頼できる計画は、何を移動する必要があり、何を再構築できるかから始まります。保存されたオブジェクトは、保持と Object Lock の制限に従って、互換性のあるインターフェースを介してコピーできます。仮想ワークロードは、ターゲット環境でイメージ、アプリケーションデータ、キー、ネットワークルール、検証を必要とする場合があります。ハウジング内の顧客機器は、承認された物理アクセス、ロジスティクス、代替接続を必要とする場合があります。公開アドレスと経路は、実際の割り当てと契約上の管理と一致する計画を必要とします。AS33930 は、外部の読者に顧客が何を持ち出せるかを教えません。

計画には時計も必要です。復旧目標は退出目標ではありません。非同期レプリケーションは移行計画ではありません。1または10 Gbps の回線オプションは、利用可能な転送スループットの証拠ではありません。期間は、実際のデータ量、選択された経路、ターゲットの準備状況、保持制限、運用ウィンドウから推定される必要があります。代表的な抽出をテストすることで、これらの仮定を証拠に変換できます。

最後に、責任は解約後も持続する必要があります。誰がソースアクセスを提供し、エクスポートを作成し、整合性質問に回答し、許可された場合に保持コピーを削除し、失敗した転送をサポートするのか？認定範囲、サプライヤー契約、製品オプションが移行前に変更された場合はどうなるのか？公開ソースはこれらの顧客固有の質問に回答しないため、普遍的な退出結果を主張することはできません。しかし、依存関係が緊急になる前に退出スケジュールを具体的にするのに十分な製品詳細を提供します。

契約証拠はアーキテクチャを反映すべきである

Cloud Temple のページで説明されているアーキテクチャはモジュール式です。契約証拠も同様にモジュール式であるべきです。フレームワーク契約は CLOUD TEMPLE を契約相手として特定できますが、サービス計画は認定 IaaS、OpenShift、オブジェクトストレージ、バックボーン接続、ハウジングの区別を保持する必要があります。そうしなければ、正確な公開認定は、顧客がそれを執行しなければならない瞬間に曖昧になる可能性があります。

サービスごとに、契約記録は注文されたオプション、該当する場合は場所またはゾーン、指定されたサービスレベル、測定ポイント、除外事項、サポート境界、変更通知義務をキャプチャする必要があります。数値的主張は正確な扱いに値します。VMware ページの15分 RPO、4時間未満 RTO、99.99%可用性は、購入された設定の拘束力のある条件に対してチェックされるべきです。公開ページだけでは救済措置を示さず、性能を証明しません。

サプライヤー証拠はこれらの計画に隣接する必要があります。施設や回線が重要な場合、記録は顧客に対して責任を負う当事者と、基礎となる層に利用可能な証拠を特定する必要があります。Cloud Temple がハウジングでオンサイトサポートを提供する場合、許可されたタスクと応答義務は明示的であるべきです。顧客がプライベートバックボーンでトポロジやセキュリティ機器を管理する場合、変更およびインシデント義務は想定によってプロバイダーに割り当てられるべきではありません。

このミラーリングは変更を管理可能にします。サービス、ゾーン、サプライヤー、保証ステータスが変更された場合、顧客は影響を受けるワークロードと管理を特定でき、未分化のプロバイダー評価を再ロールする必要はありません。また、非 SecNumCloud ハウジング境界を認定サービスと並べて可視に保ちます。目標はより大きな契約それ自体ではなく、運用システムと同じ境界に従う証拠構造です。

購入者のための実用的証拠マトリックス

Cloud Temple の開示は、それぞれが明示的な境界と対になったコンパクトな一連の結論をサポートします。以下のマトリックスはプライベート顧客設計の判断ではありません。公開証拠を、ソース境界を超えずに質問に変換する方法を示しています。

公開されている主張	サポートするもの	顧客固有の証拠が必要なもの
ANSSI が CLOUD TEMPLE 提供の認定 IaaS サービスとして`IAAS - SECURE TEMPLE`を挙げている	定義された認定サービスと保証期間	購入されたサービス、ゾーン、現在の適用可能性、設定、ワークロードマッピング
Cloud Temple が SecNumCloud 範囲、HDS、ISO 27001、C5、関連資料を提示している	複数の保証アーティファクトへの経路	各アーティファクトの範囲、期間、除外事項、プロビジョニングされたコンポーネントとの関連性
VMware IaaS がマルチゾーンレプリケーション、15分 RPO、4時間未満 RTO、99.99%可用性を記載している	プロバイダー公開の設計およびサービス目標	拘束力のある条件、選択されたアーキテクチャ、テスト結果、実際の SLA、復旧結果
OpenSource IaaS が2ホスト可用性、ライブマイグレーション、3ゾーンへのバックアップを説明している	公開されたプラットフォームメカニズム	ワークロード配置、アプリケーション整合性、復旧テスト、顧客義務
Object Storage が認定、S3 互換、3ゾーンレプリケーション、出力料金なしで提示されている	公開されたストレージ、インターフェース、レプリケーション、価格機能	使用される API 表面、保持設定、転送時間、ターゲットコスト、テストされた退出
Private Backbone が VPLS、アドレス、Anti-DDoS、VLAN、1/10 Gbps 回線を提供している	設定可能なプロバイダーネットワークサービス	注文された容量、完全なパス、顧客トポロジ、セキュリティポリシー、予備力
RDAP、RIPEstat、PeeringDB が AS33930、アナウンス、接続リストを明らかにしている	公開ネットワーク ID と開示	トラフィック、経路多様性、顧客到達性、容量、サプライヤー役割、フェイルオーバー
ハウジングが非 SecNumCloud ゾーンでのラック、電源系統、接続性、サポートを説明している	明確な物理ホスティングオファリングと明示的な認定境界	場所、運営者、機器、サポート範囲、電気経路、クロスコネクト、契約

規律はペアリングです。左側は不要に否定的な評価を防ぎます。実質的で検証可能な情報がここにあります。右側は誇張を防ぎます。記録のいずれも完全な顧客アーキテクチャやその観測された結果を明らかにしません。購入者は、公開資料がすでに製品と管理語彙を特定しているため、Cloud Temple に的を絞った証拠を要求できます。

同じマトリックスは運用記録になる可能性があります。サービス責任者、証拠日付、テスト結果、次のレビュー日付を追加します。各行をそれに依存するワークロードにリンクします。証拠が機密の場合は、文書を公開せずにレビューをキャプチャします。顧客がメカニズムを管理する場合は、内部の責任者を割り当てます。この形式では、認定は調達バッジではなく、継続的な保証のコンポーネントになります。

最も強い結論は意識的に限定されている

Cloud Temple は、多くのインフラプロバイダーよりも検証可能な公開面を持っています。法的身元は CLOUD TEMPLE、SIREN 825400336、Puteaux の住所に結び付けられます。ANSSI は特定の認定 IaaS を挙げています。製品ページは仮想化、ストレージ、バックアップ、レプリケーション、ネットワーキング、ハウジングメカニズムを説明しています。AS33930、RIPEstat、PeeringDB は公開ネットワークフットプリントの一部を明らかにします。コンプライアンスページは顧客を機密性の下でのより深い証拠に導きます。

ソースは、区別されたままである場合に最も強力です。認定決定は製品仕様とは異なることを証明します。ルーティング観測は施設ディレクトリエントリとは異なることを証明します。指定された復旧目標は完了した復旧とは異なることを証明します。非 SecNumCloud ハウジングの開示は、認定 IaaS の価値を無効にするのではなく、その価値が自動的に適用されなくなる場所を特定します。

だからこそ、製品別の責任証明が中心的な要件です。顧客は、どの Cloud Temple サービスが使用されているか、どの保証範囲が適用されるか、どのように設定されたか、どの依存関係が外部にあるか、誰が各管理を運用するか、何かが変更または失敗した場合に契約が何を言っているかを知る必要があります。答えは堅牢かもしれません。ポートフォリオラベルだけから推測することはできません。

公開記録の最も信頼できる読み方は、包括的な承認でも包括的な疑念でもありません。Cloud Temple は認定サービス、詳細な製品機能、可視のネットワーク ID を開示する一方で、ハウジングの明確な例外も公開しています。購入者はこの開放性を活用して、同様に正確なアーキテクチャ、証拠、契約を要求する必要があります。その結果、名前付きサービスからプロビジョニングされたワークロードまでの防御可能な連鎖が生まれ、各移行で不確実性が記録され、ポートフォリオで最も強いバッジの下に隠されることはありません。

Cloud Temple の認定サービスには依然として製品別の責任証明が必要

まとめ