Cloud Temple: 产品责任证明

摘要

ANSSI 的决定将IAAS - SECURE TEMPLE认定为由 CLOUD TEMPLE 提供的合格 IaaS 服务，而 Cloud Temple 的合规页面描述了额外的范围和确认。这些记录为指定服务提供了重要证据，但并不能证明每个产品、区域、供应商、客户配置或工作负载都受到相同的控制。
Cloud Temple 的产品页面描述的责任限制存在显著差异。VMware IaaS、OpenSource IaaS、Object Storage、Private Backbone 和 Housing 在复制、备份、网络、客户控制、物理空间和可移植性方面的假设各不相同。特别是 Housing 页面明确指出其专属空间位于非 SecNumCloud 区域。
AS33930、RIPEstat 和 PeeringDB 提供了部分可验证的网络表面积。它们将 CLOUD TEMPLE 与公共数字资源、观察到的公告、交换容量和设备清单联系起来，但无法确定流量量、备用容量、路径多样性、客户路径选择、供应商角色或所列设备的所有权。
实际的尽职调查工作需要为每个购买的架构收集四项内容：确切的合格或认证服务、提供的架构、操作责任的划分，以及供应商、事件、恢复和退出的合同证据。组合标志无法代替客户完成这项工作。

最有用的披露是例外

Cloud Temple Housing 页面上的一句话比一整页一般性保证做了更多的分析工作。该公司描述了共享或专属机架、双电源链路、Meet-Me-Room 连接和现场支持，但也明确指出 Dedicated Space 产品托管在非 SecNumCloud 区域。这并非披露的弱点。这是解读产品组合最清晰的指南。

这一区分很重要，因为采购方通常首先通过其最强认证来发现云提供商。在这种情况下，公开证据包括 ANSSI 的资格决定、讨论 SecNumCloud 3.2 的合规页面，以及使用认证服务语言的产品资料。很容易将这些证据转移到所有相邻产品上。Housing 页面阻止了这种捷径。客户可以从同一供应商处采购，与同一商业伙伴谈判，但如果所选服务发生变化，最终可能会处于不同的控制环境中。

这一限制是操作性的，而非语义性的。Housing 为客户提供物理空间和相关的现场服务。IaaS 提供抽象计算平台。对象存储有其自身的复制、接口和保留行为。私有骨干引入电路、地址、VLAN、安全控制和拓扑选择。这些产品可以组合，但组合并不能消除它们各自的边界，而是创造了它们之间的过渡。

因此，正确的问题不是 Cloud Temple 是不是一个广义上的“SecNumCloud 供应商”，而是在所提议的架构中，确切的服务、区域、选项和支持组件是否属于所依赖的证据范围。Housing 的披露使答案可见，且随着部署位置的不同而变化。任何严肃的评估都应该在从采购到运营再到退出的整个过程中保持这种产品级别的粒度。

资格适用于指定服务

公共记录中最强的独立证据是具体的。ANSSI 的公开决定命名了IAAS - SECURE TEMPLE，将其描述为由 CLOUD TEMPLE 提供的 IaaS，并规定在有效期内持续合规才能保持资格。名称很重要。条件性同样重要。资格决定并非对供应商所有活动的抽象认可；它标识了一项服务和有限保证状态。

Cloud Temple 的合规材料扩展了公开画面，但并未使其普遍适用。它展示了 IaaS Secure Temple 和 PaaS OpenShift 的 SecNumCloud 3.2 范围，并讨论了 HDS、ISO 27001、C5 和其他保证材料。这些标签是有用的起点，但不可互换。每一项都有其自己的主体、范围、有效期和证明目的。即使多项出现在同一合规页面上，也不应浓缩为一个声明，即 Cloud Temple 销售的一切都受到相同覆盖。

对于采购方来说，确切名称必须在合同和设计文件中保持一致。IAAS - SECURE TEMPLE出现在 ANSSI 决定中，Secure Temple 出现在商业讨论中，特定的 IaaS 配置出现在采购订单上，而实际提供的资源必须引用相同的预期服务边界。如果项目还使用 OpenShift、对象存储、私有骨干、Housing 或外部电路，每个新增部分都需要自己的答案。它是否包含在相关范围内？仅仅是相邻？还是完全在外？

时间维度也很重要。公开材料中描述的决定有一项定义的有效期，且取决于持续合规。这支持一个严谨的证据时间表：记录所依赖的是哪项决定或证书、何时有效、它命名的确切服务是什么，以及如果状态或范围发生变化会发生什么。这并不能证明可以预测未来的资格，也不能证明客户的配置保持合规仅仅因为供应商级别的决定保持最新。

法律身份比目录标签更清晰

法国企业公共研究 API 将 CLOUD TEMPLE 识别为活跃法律实体，SIREN 825400336，成立于 2017 年 1 月 17 日，归类为数据处理、托管及相关活动。其总部位于 1-7 Le Belvedere, 1 Cours Valmy, Puteaux。Cloud Temple 网站的使用条款将编辑方识别为一家法国简化股份公司，并在同一地址有股东。这些记录共同为本文讨论的服务和公共网络身份提供了稳定的合同锚点。

命名规则在这里也很重要。BTW 目录使用 TEMPLE Cloud Temple SAS 作为现有企业名称，因此该字符串出现在概览中。公开证据支持 CLOUD TEMPLE 作为法律和面向读者的身份。它们并未将 TEMPLE Cloud Temple SAS 确立为当前官方法律名称，本文也不将其视为如此。

合同方身份对于服务责任是必要但不充分的。一致的法律名称、注册号和地址告诉采购方哪个组织发布了条款并出现在资格决定中。但它们并未显示哪个第三方运营特定设施、提供电路、交付组件或传输流量。它们也未回答某一特定义务是归于 Cloud Temple、客户还是其他供应商。这些答案属于与已识别法律方相关的服务计划、架构记录和支持保证证据。

产品组合需要责任地图

Cloud Temple 的公共目录最好被理解为一组控制面，而不是单一堆栈。在一端，合格的 IaaS 服务可能将广泛平台责任置于供应商处。在另一端，Housing 将客户自有设备和许多操作决策置于明确位于 SecNumCloud 区域之外的物理服务中。在这两端之间是混合产品，它们将供应商运营的基础设施与客户选择的拓扑、保留或工作负载配置相结合。

至少需要绘制四个层。第一是服务本身：订购了哪个确切产品和选项？第二是部署：实际选择了哪些区域、主机、存储类、备份设置、地址和电路？第三是运营：谁在监控、打补丁、配置、测试、批准变更以及响应组件故障？第四是证据：哪项资格、证书、报告、供应商文件或合同时间表支持每项控制声明？

这些层不能被总结为一个标志或产品家族名称。合格的服务仍可能要求客户正确配置网络和访问。复制的存储产品仍可能要求做出保留决策和经过测试的提取程序。多区域选项可能存在但未被选择。声明的恢复目标可能取决于购买的架构和双方的行为。设施清单可能标识一个地点，但未说明位于该地点的设备或服务。

因此，责任地图必须足够具体以揭示差距。如果应用程序依赖于 IaaS、对象存储和私有电路，证据应显示三个产品边界及它们之间的转换。如果添加 Housing 用于遗留设备或系统，其非 SecNumCloud 状态必须保持可见，而不应被吸收进关于周围平台的笼统声明中。Cloud Temple 披露的价值在于它为采购方提供了构建这张地图所需的原始区分。剩下的工作是将它们与购买的架构联系起来。

VMware IaaS 发布的是目标，而非结果

VMware IaaS 页面描述了相对丰富的服务设计。Cloud Temple 声明提供专用的计算、网络、存储和备份基础设施，提供多区域部署，并使用异步存储复制。它提到了 15 分钟的恢复点目标（RPO）、少于 4 小时的恢复时间目标（RTO）以及 99.99% 的可用性。这些是供应商发布的规格。它们使预期服务可测量，但并非对特定客户环境运行情况的观察。

这一区分对于韧性分析至关重要。声明的 RPO 描述了相关条件下可容忍的数据丢失目标。它不能证明每个工作负载都在范围内、复制在故障发生时是健康的，或实现了应用一致性恢复。RTO 描述了恢复目标，不能证明依赖关系、凭证、网络规则和应用团队在规定时间内完成了实际恢复。可用性语言也需要定义合同条款、排除项、测量点和补救措施，然后才能应用于客户结果。

“专用”一词也需要针对具体服务进行解释。页面将其与计算、网络、存储和备份基础设施联系起来，这是一个实质性的描述。但采购方仍需了解在所订购的设计中哪些元素是专用的，哪些管理或安装依赖关系仍然共享，以及界限是如何证明的。多区域能力也需要同样的处理：选择了哪些区域？哪些组件跨区域分布？还有哪些依赖关系可能是共同的？

这些问题均不与产品页面矛盾。它们是将产品页面的主张转化为可操作性用途的方式。该页面提供了设计功能和数字目标，可被整合到测试计划和合同矩阵中。独立证据将来自购买的架构、监控记录、演练结果以及适用的服务条款。没有这种联系，已发布的数字必须归因于 Cloud Temple，并与关于实际 SLA 表现或恢复成功的声明分开。

OpenSource IaaS 划定了另一条界限

Cloud Temple 的 OpenSource IaaS 页面描述了 Xen 虚拟化、两个主机上的高可用性、实时迁移、备份到对象存储以及自动将备份分发到三个可用区。所用词汇与 VMware 产品重叠，但控制模型并不相同。不同的虚拟化、主机和备份描述意味着保证不能简单地从一种 IaaS 产品转移到另一种。

两个主机上的高可用性是一项平台设计声明。其对客户的意义取决于工作负载放置、宿主机独立性、共享存储或网络依赖关系以及该机制旨在应对的故障模式。实时迁移可以支持维护和工作负载移动，但其本身并不是灾难恢复结果。放置在对象存储中并分布在三个可用区的备份增加了另一层韧性，但备份副本的存在和分布并不能证明可用的恢复已经发生。

操作交接也因层次而异。Cloud Temple 可以提供宿主机级别机制、迁移能力和备份分发，而根据合同，客户可能仍负责客户操作系统配置、应用一致性、凭证、保留决策或恢复验收。公共页面并未为每位客户固定确切划分。但它说明了为什么这种划分必须为这个产品记录，而不是从 VMware 描述或产品组合级别的合规声明中推断出来。

一项有用的评估会将每个已发布的机制与故障场景联系起来。两个主机的高可用性应对某些主机事件。实时迁移应对某些计划内或突发情况。分布式备份应对副本保留。这些都不能必然解决应用错误、凭证泄露、错误保留策略保护的删除或平台之外的依赖关系。目的不是贬低架构。而是识别每个控制设计用于什么，谁需要激活或验证它，以及哪些证据可以表明客户的实施能够使用它。

对象存储使可移植性变得具体且有条件

对象存储页面对于韧性和退出都异常重要。Cloud Temple 将该服务宣传为 SecNumCloud 认证、兼容 S3、复制到三个可用区且无出口费用。它还标识了与 Object Lock 相关的限制。这些声明揭示了一个有用的组合：一侧是保证和可移植性功能，另一侧是可能限制修改的保留行为。

S3 兼容性可以减少应用摩擦，因为熟悉的接口可以支持常见工具和工作流。但兼容性并不能保证每个 API 行为、策略模型、元数据字段、生命周期规则或操作工具都能无缝迁移。真正的退出计划需要了解应用程序使用了什么，而不仅仅是协议标签。它还需要目的地、凭证、传输方法、完整性检查以及足够的时间来移动数据。

供应商提出的无出口费用消除了一个潜在成本要素。但这并不证明退出是免费的。技术工作、目的地费用、临时双重存储、电路容量、查询成本、验证和应用修改仍然可能影响经济性。它也不能证明传输将在目标日期前完成。吞吐量和时间取决于一个已配置的情况，而公共页面并未记录这一点。

Object Lock 强化了责任界限。防止修改或删除的保留可能很有价值，但同样的限制可能影响迁移和关闭。采购方应该知道谁选择模式和期限，法律或政策义务如何体现，在锁定情况下可以复制什么，以及删除何时变为可能。公共材料支持限制的存在，但并非普遍的退出结果。因此，最强烈的解读是有条件的：Cloud Temple 发布了可能支持可移植和弹性存储的功能，但客户的配置和经过测试的提取过程决定了这些功能是否提供了所需结果。

私有骨干将拓扑决策留给客户

Private Backbone 页面描述了区域 VPLS 网络、公共 IPv4 和 IPv6 分配、反 DDoS 功能、VLAN 控制以及 1 或 10 Gbit/s 的外部或专用电路。它还指出客户可以保留对拓扑和安全设备的完全手动控制。这一点不是脚注。它将操作模型的关键部分放在了客户一方的服务边界内。

供应商运营的骨干可以提供传输、地址和保护功能，而无需确定最终应用路径。VLAN 设计、路由选择、安全设备策略以及云区域、Housing 区域和外部站点之间的连接可能反映客户的决策。手动控制提供了灵活性，但也意味着供应商的平台控制不能保证防止客户创建的任何单点故障或策略错误。

公布的电路速率是产品选项，并非购买能力或观察到的备用容量的证据。10 Gbit/s 选项不能证明客户订购了它，端到端路径以该速率运行，或者在事件发生时有足够的备用容量。同样，公共 IPv4 和 IPv6 可用性并不能说明特定服务的地址分配。反 DDoS 语言标识了一类控制，但评估仍需要激活条件、受保护流量、卸载点和客户义务。

这种混合控制模型正是架构证据比一般供应商证据更有价值的地方。图表应识别 Cloud Temple 运营的网段、客户控制的设备或策略，以及第三方电路进入的位置。变更和事件流程应确定谁可以修改每一层以及各方如何协调。公共页面支持可配置网络服务的存在。但它没有揭示客户的拓扑、路径选择或安全态势，这些私人细节不应从产品目录推断。

AS33930 锚定身份，而非性能

公共网络记录为 Cloud Temple 提供了可验证的基础设施身份。RIPE RDAP 将 AS33930 识别为 CLOUD-TEMPLE 名下的。在公开验证时，RIPEstat 观察到 8 个 IPv4 和 IPv6 前缀被公告。这些记录有助于区分一个运营网络和一个不留下公共数字资源痕迹的云品牌。

证据仍然狭窄。RDAP 是一个行政注册系统，因此它支持自治系统资源的归属；它不能描述背后运行的完整服务。RIPEstat 观察显示在某一时刻前缀在路由数据中可见。它们不测量流量、客户可用容量、应用可达性或合同服务。前缀可以被公告而不证明客户工作负载如何使用它，而私有服务可能在没有单独公开公告的情况下很重要。

自治系统号特别诱人，容易将其转化为架构图。研究人员可能假设它标识了每个上游、所有路由和完整的冗余设计。但该记录不支持这些结论。AS33930 建立了一个公共路由身份。它不能证明路径多样性、备用连接、地理独立性、故障转移行为或客户数据包经过的路径。

对于尽职调查，ASN 最好用作核对键。它可以与 PeeringDB 条目、观察到的前缀以及客户设计中写入的网络标识符进行比较。差异可能引发问题：哪些地址属于购买的服务？哪些路径是私有的？哪一方宣告了一个前缀？答案必须来自最新的技术和合同证据。公共注册表为调查提供了一个稳定的起点，而不是性能判断。

PeeringDB 增加了已披露的地点，而非拥有的设施

PeeringDB 增加了另一种可追溯性。其 Cloud Temple 条目列出了 30 个 IPv4 和 10 个 IPv6 前缀、开放对等策略、巴黎的两个 10G 交换点，以及包括 DATA4、Digital Realty、Equinix 和 Telehouse 在内的设施。这是一项有用的披露，说明了网络声明可能连接的地方以及向目录声明的资源范围。

这些数字与 RIPEstat 观察到的 8 个 IPv4 和 IPv6 前缀并不矛盾，因为它们描述了不同的事物。PeeringDB 前缀限制或数量是目录字段；RIPEstat 报告其系统在验证时观察到被公告的内容。两者都不应被默认替换为对方。更重要的是，两者都不是流量测量。这些记录不显示负载、峰值使用、客户分布或备用容量。

设施名称同样需要谨慎。PeeringDB 条目可以将网络放置在一个站点以进行连接。它不能证明 Cloud Temple 拥有该建筑、控制整个设施、占用特定数量空间，或在每个列出的站点提供相同的产品。因此，DATA4、Digital Realty、Equinix 和 Telehouse 应被理解为公共网络目录中命名的基础设施或设施运营商，而非 Cloud Temple 的资产。

巴黎的两个 10G 交换点使公共连接面更具体，但仍不能证明多样化的路径或强韧的客户部署。两个列出的交换点可能共享清单中不可见的依赖关系，而客户流量可能遵循此处未捕获的协议。开放对等描述了一项声明的政策，并非接受所有请求的承诺，也不是对等替代传输。PeeringDB 当被用于其本意时是精确宝贵的：作为一层披露，可以与详细设计进行验证，而不是替代该设计。

Housing 是一项独立运营产品

Housing 将物理层置于前台。Cloud Temple 描述了共享或专属机架、双电源链路、Meet-Me-Room 连接和现场支持。每一项对于将设备放置在设施中的客户都可能很重要。然而，同一页面上的非 SecNumCloud 区域警告确定了该产品不能仅仅因为它出现在同一组合中就继承另一项服务的资格。

物理责任划分也与 IaaS 不同。在 Housing 中，客户可能拥有或控制设备，并负责硬件生命周期、系统配置以及在其上运行的应用程序，而 Cloud Temple 提供指定空间和现场服务。确切划分是合同性的；公共页面并未固定每项义务。现场支持可能涵盖许多可能的任务，营销术语本身不能确定响应时间、授权、备件可用性或成功修复。

双电源链路是一项设计特征，而非端到端电气独立性的证据。它们的效用取决于客户设备如何连接以及简短描述之外的共享依赖关系。Meet-Me-Room 连接创造了连接选项，但不能证明客户订购了多样化的运营商或物理分离的路径。共享或专属机架标识说明了空间，而非更广泛设施的所有权。

因此，该产品需要自己的一套证据：命名站点及其运营商、空间分配、电气设计、访问流程、支持范围、互连、客户设备清单以及事件责任。这些细节均不能从网页或 PeeringDB 中发明。公共材料确立了一项产品和明确的资格限制。采购方的私人文件必须确立所购买的实施方案。

合规标签需要工作负载级别链接

合规页面呈现了相当大的保证表面。SecNumCloud 3.2 范围与 HDS、ISO 27001、C5 及相关材料并存，而 ANSSI 决定独立命名了IAAS - SECURE TEMPLE。对于采购团队来说，这一集合很有价值，因为它提供了多条尽职调查路径。但这也是最容易出现范围错误的地方。

一个标签只能回答它被设计和限定的问题。一个管理系统证书不会自动认证每个技术结果。健康数据托管状态不会在缺少适当服务和客户配置的情况下使每个工作负载合规。绑定到命名 IaaS 的云保证资格不会扩展到 Housing，供应商自己也将 Housing 标识为在 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 的义务、客户的义务、保证证据、通知协议以及依赖关系变化时的后备方案。这在认证平台遇到非认证 Housing 或客户选择的连接时尤其重要。过渡完全可以是功能性的，但它必须被设计和证明，而不是被供应商名称的便利所掩盖。

经济性不能从价格特征中读出

公共材料包含了具有直接经济影响的特点。对象存储被宣传为无出口费用。私有骨干提供 1 或 10 Gbit/s 的外部或专用电路作为产品选项。Housing 引入了机架空间、电力、连接和现场支持。IaaS 产品以不同方式组合计算、网络、存储和备份。这些决策在捆绑服务、客户工作和第三方依赖关系之间转移成本。

无出口定价是为什么一个有吸引力的术语不应代表总成本的最清晰例子。取消一项传输费用可以使例行移动或最终迁移成本降低。实际退出预算可能仍然包括工程、目的地服务、临时复制、完整性检查、应用修改以及足够的连接。Object Lock 可能增加时间约束。公开证据支持声明的无出口费用，但不支持免费或即时退出的保证。

专用基础设施创造了另一种权衡。它可以为采购方提供更清晰的资源限制或性能规划，但经济性取决于订购的能力、期限、使用情况以及所包含的操作服务。99.99% 可用性或恢复目标的公开声明并未揭示财务补救措施、排除项或停机的商业价值。这些属于合同以及客户自身的影响模型。

Housing 可以将硬件选择和生命周期责任转移给客户，而托管云可能将更多平台工作放在供应商处。两者并非在所有情况下都固有地便宜。有意义的比较包括人员时间、备件、迁移努力、保证工作、互连、备份测试以及达到所需控制范围的成本。Cloud Temple 的产品组合为客户提供了多种组装基础设施的方式。其公共页面不能证明哪种组合对于特定工作负载在经济上最优。

可移植性必须被验证，而非假定

对象存储通过 S3 兼容性和无出口费用提供了产品组合中最明确的可移植性词汇。VMware 和 Xen 环境、备份、网络分配以及 Housing 设备创造了其他移动性问题，即使页面没有做出广泛的退出承诺。它们共同表明退出不是单一行动。数据、机器、配置、地址、安全策略、物理资产和合同各自可能遵循不同路径。

一个可靠的计划从需要移动的内容和可以重建的内容开始。存储的对象可以通过兼容接口复制，受保留和 Object Lock 约束。虚拟工作负载可能需要镜像、应用数据、密钥、网络规则以及在目标环境中的验证。Housing 中的客户设备可能需要授权的物理访问、物流和替代连接。公共地址和路由需要一个与实际分配和合同控制一致的计划；AS33930 不告诉外部读者客户可以带走什么。

计划还需要一个时钟。恢复目标不是退出目标。异步复制不是迁移计划。1 或 10 Gbit/s 电路选项不是可用传输吞吐量的证据。持续时间必须根据实际数据量、所选路径、目的地准备情况、保留限制和操作窗口来估算。测试代表性提取可以将这些假设转化为证据。

最后，责任必须超越终止期。谁提供对源的访问？谁创建导出？谁回答完整性问题？谁在允许时删除保留的副本？谁支持失败的传输？如果范围资格、供应商协议或产品选项在迁移前发生变化怎么办？公共来源不回答这些针对客户的问题，因此不能声称普遍的退出结果。但它们提供了足够的产品细节，使退出时间表在依赖关系变得紧迫之前就能具体化。

合同证据应反映架构

Cloud Temple 页面上描述的架构是模块化的。合同证据也应同样模块化。框架协议可能将 CLOUD TEMPLE 识别为合同方，但服务计划应保留认证 IaaS、OpenShift、对象存储、骨干连接和 Housing 之间的区分。否则，一项精确的公开资格可能在客户需要执行时变得模糊。

对于每项服务，合同卷宗应捕获订购的选项、适用的站点或区域、指定的服务级别、测量点、排除项、支持范围以及变更通知义务。数字声明需要精确处理。VMware 页面上的 15 分钟 RPO、少于 4 小时的 RTO 以及 99.99% 可用性应针对所购买配置的约束性条款进行验证。单独公共页面不显示补救措施也不证明性能。

供应商证据应伴随这些计划。如果设施或电路是关键，卷宗应标识对客户负责的方以及底层层级的可用证据。如果 Cloud Temple 在 Housing 中提供现场支持，授权任务和响应义务应明确。如果客户控制私有骨干上的拓扑或安全设备，变更和事件义务不应默认归因于供应商。

这种镜像使变更可管理。如果服务、区域、供应商或保证状态发生变化，客户可以标识受影响的工作负载和控制，而不是重新进行无差异的供应商评估。它也使 Housing 的非 SecNumCloud 界限与认证服务并列可见。目的不是为自身而签署更长合同，而是遵循与运营系统相同边界的证据结构。

采购方的实用证据矩阵

Cloud Temple 的披露支持一组紧凑的结论，每个都有明确的限制。以下矩阵并非对客户私人设计的判断。它展示了公开证据如何转化为问题，而不会超越来源界限。

公开可见声明	支持的内容	仍需客户特定证据的内容
ANSSI 将`IAAS - SECURE TEMPLE`认定为由 CLOUD TEMPLE 提供的合格 IaaS 服务	一项定义的认证服务和保证期限	购买的服务、区域、当前适用性、配置和工作负载分配
Cloud Temple 展示 SecNumCloud 范围及 HDS、ISO 27001、C5 及相关材料	通向多个保证工件的路径	每个工件对部署组件的范围、期限、例外和相关性
VMware IaaS 规定多区域复制、15 分钟 RPO、小于 4 小时 RTO 和 99.99% 可用性	供应商发布的设计和服务目标	约束性条款、选择的架构、测试结果、实际 SLA 和恢复结果
OpenSource IaaS 描述了两节点高可用性、实时迁移和三区域备份	发布的平台机制	工作负载放置、应用一致性、恢复测试和客户义务
对象存储被宣传为认证、S3 兼容、三区域复制且无出口费用	发布的存储、接口、复制和定价功能	使用的 API 表面、保留设置、传输时间、目的地成本和测试的退出
私有骨干提供 VPLS、地址、反 DDoS、VLAN 和 1/10 Gbit/s 电路	供应商的可配置网络服务	已订购容量、完整路径、客户拓扑、安全策略和备用
RDAP、RIPEstat 和 PeeringDB 披露 AS33930、公告和连接列表	公共网络身份和披露	流量、路径多样性、客户范围、容量、供应商角色和故障转移
Housing 描述机架、电源链路、连接和现场支持，且位于非 SecNumCloud 区域	一项独立的物理托管产品和明确的资格界限	站点、运营商、设备、支持范围、电源路径、互连和合同

原则是耦合。左侧防止不必要的轻视：这里有实质性和可验证的信息。右侧防止夸大：没有任何记录揭示完整的客户架构或其观察到的结果。采购方可以要求 Cloud Temple 提供有针对性的证据，因为公开材料已经标识了产品和控制词汇。

同一矩阵可以成为操作记录。添加服务负责人、证据日期、测试结果和下次复审日期。将每一行链接到依赖它的工作负载。在证据保密时，记录验证而非披露文件。在客户控制机制时，分配内部负责人。以这种形式，认证成为持续保证的组成部分，而非签约后褪色的采购徽章。

最终结论审慎设限

Cloud Temple 的公开表面比许多基础设施供应商更可验证。法律身份可追溯到 CLOUD TEMPLE，SIREN 825400336 和 Puteaux 地址。ANSSI 命名了特定的认证 IaaS。产品页面描述了虚拟化、存储、备份、复制、网络和托管机制。AS33930、RIPEstat 和 PeeringDB 披露了部分公共网络足迹。合规页面将客户导向保密条件下更深入的证据。

来源在保持区分时最强。资格决定证明了与产品规格不同的东西。路由观察证明了与设施目录条目不同的东西。声明的恢复目标证明了与完成恢复不同的东西。非 SecNumCloud Housing 的披露并不否定认证 IaaS 的价值；它标识了该价值停止自动适用的地方。

这就是为什么逐产品责任证据是核心要求。客户必须知道使用了哪个 Cloud Temple 服务、哪个保证范围适用、它是如何配置的、哪些依赖关系在外部、谁操作每个控制以及合同在发生变更或故障时说什么。答案可能很稳固。但它不能仅从单个组合标志推断出来。

对公共记录最可信的解读既非全面认可也非全面怀疑。Cloud Temple 披露了认证服务、详细的产品功能和可见的网络身份，同时发布了关于 Housing 的明确例外。采购方应利用这种开放性来要求具有匹配精度的架构、证据和合同。结果将是从命名服务到部署工作负载的可辩护链条，并在每个过渡点记录不确定性，而非将其隐藏在组合最强的徽章下。