什么是受信任硬件标识管理 (THIM)，它在 Enclave 证明中起到哪种作用？
受信任的硬件标识管理 (THIM) 为 Intel 中的 Azure 机密计算 (ACC) 节点提取 Azure 安全基线，并缓存数据。 Azure 证明还使用缓存的信息来验证受信任执行环境 (TEE)。
建议使用 THIM 的原因如下：
- 提供高可用性
- 减少对外部托管服务和 Internet 连接的依赖。
- 定期提取 Intel 中 ACC 节点的较新版本的 Intel 证书、CRL、受信任计算基础 (TCB) 信息和引文 Enclave 标识。 该服务在验证 TEE 的同时确认 Azure 证明所引用的 Azure 安全基线，大大减少了因 Intel 证书失效或吊销而导致的证明失败。
非 Azure 环境中的 Azure 证明是否支持 Software Guard Extensions (SGX) 证明？
否。 Azure 证明依赖于受信任的硬件身份管理 (THIM) 中声明的安全基线来验证 TEE。 根据设计，THIM 目前只支持 Azure 机密计算节点。
Azure 证明执行哪些验证来证明 SGX enclave？
在 SGX 证明过程中，Azure 证明执行以下验证：
- 验证已签名 enclave 引用的受信任的根是否属于 Intel
- 验证 TEE 引用是否符合受信任的硬件标识管理 (THIM) 定义的 Azure 安全基线
- 如果客户创建了证明提供程序并配置了自定义策略，除了上述验证之外，Azure 证明根据证明策略评估 TEE 引用。 客户可以使用证明策略来定义 TEE 的授权规则，同时指定有关生成证明令牌的颁发规则。
验证程序如何获取 Azure 证明支持的 SGX 证明的附件？
通常，对于以 Intel 作为信任根的证明模型，证明客户端与 enclave API 通信来提取 enclave 证据。 enclave API 在内部调用 Intel PCK 缓存服务，以提取要证明的节点的 Intel 证书。 这些证书用于对 enclave 证据进行签名，从而生成远程可证明的附件。
同样的过程也可以在 Azure 证明中实现。 但是，为了利用受信任硬件标识管理 (THIM) 的优势，建议在安装 ACC 虚拟机后安装 Azure DCAP 库。 根据与 Intel 的协议，如果安装了 Azure DCAP 库，则生成 Enclave 证据的请求会从 Intel PCK 缓存服务重定向到 THIM。 基于 Windows 和 Linux 的环境中支持 Azure DCAP 库。
如何从其他 SGX 证明模型迁移到 Azure 证明？
- 在安装 Azure 机密计算虚拟机后，请安装 Azure DCAP 库 (Windows/Linux)，以便利用受信任硬件标识管理 (THIM) 带来的优势。
- 需要创作远程证明客户端，它可以检索 enclave 证据，并向 Azure 证明发送请求。 有关参考信息，请参阅代码示例。
- 证明请求可以发送到默认提供程序或自定义证明提供程序的 REST API 终结点。
- 在 2018-09-01-preview API 版本中，客户端需要将 Microsoft Entra 访问令牌以及证据发送到 SGX 证明 API 终结点。 在 2020-10-01 API 版本中，Microsoft Entra 访问令牌不是执行 SGX 证明所必需的参数。
信赖方如何验证证明令牌的完整性并确认 Azure 证明在 enclave 中运行？
由 Azure 证明生成的证明令牌使用自签名证书进行签名。 签名证书通过 OpenID 元数据终结点公开。 依赖方可以从此终结点检索签名证书，并执行对证明令牌的签名验证。 签名证书还包括在其中运行 Azure 证明的 TEE 的 SGX 引用。 如果信赖方还希望检查 Azure 证明是否在有效的 SGX enclave 内运行，则可以从签名证书中检索 SGX 引用并在本地进行验证。 有关详细信息，请参阅代码示例。
证明令牌的有效期为多长？
证明令牌的有效期为 8 小时。 目前没有用于自定义该值的预配。
如何从 OpenID 元数据终结点识别用于签名验证的证书
OpenID 元数据终结点中公开的多个证书对应于 Azure 证明支持的不同用例（例如，SGX 证明）。 根据 RFC 7515 指定的标准，使用密钥 ID (kid) 与证明令牌头中的 kid 参数匹配的证书进行签名验证。 如果找不到匹配的 kid，则应尝试使用 OpenID 元数据终结点公开的所有证书。
信赖方能否与验证的受信任执行环境 (TEE) 共享机密？
在创建 TEE 证据时，TEE 内部运行的代码可以在证据中包含任意信息。 例如 TEE 可以创建一个或多个非对称密钥对，将这些密钥对的公钥组件序列化为 JWKS JSON 字符串，并将 JWKS JSON 字符串作为 RunTimeData { quote, JWKS JSON string } 包含在 TEE 证据中。 Azure 证明检查 RuntimeData 的 SHA256 哈希是否与引用的“报表数据”属性的低 32 字节匹配。 在评估 TEE 证据后，Azure 证明生成 JWT，JWKS 可用作“x-ms-runtime”声明下名为“keys”的声明。 信赖方可进一步使用 RunTimeData 建立安全通道，并安全地将数据传输到 TEE。
Azure 证明将客户数据存储在何处？
Azure 证明在客户部署服务实例的地理区域内出于 BCDR 目的在处理和复制期间存储客户的静态数据。