保护测试中需要使用的凭证

本文目的

本文主要讨论了测试凭证的重要性，与其相关的风险，以及 Testany 采取的保护措施。

理解风险数据：测试凭证

测试凭证是什么

定义： 测试凭证是测试用例在 Testany 平台上进行执行并按照被测试软件服务要求提供的证明调用者身份和权限的凭证。获取测试用例和执行测试流水线的凭证同样是测试凭证但其保护措施不在本文讨论之列。

测试凭证的类型：

可能包括 API 密钥，测试账户，令牌以及在测试阶段使用的其他类型的凭证。

保护测试凭证的重要性

测试凭证在软件测试中的作用

测试凭证在软件测试过程中发挥着至关重要的作用。在模拟环境中，它们有助于复制真实世界的场景，而不影响实际的生产数据或泄露真实用户信息。

这些凭证使测试人员能够验证和核实应用程序的各种特性，如其处理身份验证、用户角色和权限级别的能力。此外，它们帮助测试人员识别身份验证系统内可能存在的漏洞和脆弱点，这些漏洞和脆弱点在现实世界中可能被利用。这种级别的测试对于维持软件的健壮性、安全性和可靠性至关重要。

此外，测试凭证被用于访问不同的测试环境。例如，这些可以用于访问与生产环境非常相似但用于测试和开发目的的 QA（质量保证）、UAT（用户接受测试）和暂存环境。这种方式，测试凭证有助于促进有效的测试，同时最大程度地降低在实际环境中意外变更或侵入的风险。

测试凭证泄露的可能后果

测试凭证的泄露可能导致一系列破坏性的后果，包括：

1. 未授权访问测试环境： 如果测试凭证被泄露，未经授权的用户可能会访问到测试环境。他们可以篡改测试结果，引入漏洞，甚至中断测试过程。
2. 开发数据的敏感性暴露： 测试环境通常包含与正在开发的软件相关的敏感数据，包括新的功能、专有算法或未修复的漏洞。一次侵入可能导致这些敏感信息的泄露。
3. 安全漏洞： 一个被泄露的测试环境可以为攻击者提供进入其他相互连接的系统的跳板。通过获取访问权限，他们可能尝试提升权限或利用任何发现的漏洞，导致更大的安全漏洞。
4. 信誉损害： 如果安全漏洞公之于众，可能导致信誉损害。客户和合作伙伴可能会对公司保护其生产环境和测试环境能力的信任度产生怀疑。
5. 法律和合规问题： 可能会出现法律和合规性问题，特别是如果侵入导致敏感或个人身份信息（PII）的暴露。公司可能会因为未能充分保护其系统而面临罚款或诉讼。

保护测试凭证以防止这些可能的后果至关重要。这意味着需要采取强大的安全措施，包括安全的凭证存储，基于角色的访问控制，以及定期的审计和监控。

保护测试中使用的凭证的解决方案

为了提供对在测试中所需的凭证的全面保护，Testany 引入了"受信任的凭证保险箱"解决方案。

这个"受信任的凭证保险箱"解决方案有两个关键组成部分：

a) IaaS供应商提供的安全凭证 CRUD 产品（例如 AWS Secrets Manager，Azure Key Vault）

b) Testany 平台和 IaaS 供应商提供的凭证保险箱之间交换凭证和引用的安全方法。

目前，Testany 平台支持以两种不同的方式部署"受信任的凭证保险箱"解决方案：

a) 由 Testany 托管，或者

b) 使用用户自己的 IaaS 账户下的凭证保险箱服务。

如果您是管理员，需要设置凭证保险箱和管理凭证，请参阅《管理测试凭证》。

在测试代码中使用凭证

当前推荐的使用方式是：先在测试用例的 Environment variables 中新增 Secret 类型条目；执行开始前，平台会自动把它解析成真实值，并注入到测试代码可读取的普通环境变量中。

步骤 1：在 Environment variables 中配置 Secret

进入测试用例详情页，点击 Edit，找到 Environment variables。

新增一条环境变量后，将 Type 设为 Secret，然后依次选择：

• Workspace
• Credential Safe
• Credential

同时填写该行的 Key。这个 Key 用于在测试用例配置中标识该 Secret 引用，便于后续审查和批量操作。

保存后，平台只会保存结构化引用，不会在测试用例中存储或展示明文 secret。

运行时会如何提供这个 Secret

在真正开始执行测试前，trusted runtime 会自动解析您配置的 Secret 引用，并把凭证真值写入执行环境。

对测试代码来说，最终效果就是：

• Secret 行里的 Key，就是执行时可以读取到的环境变量名。
• 您像读取普通环境变量一样读取它即可。
• 您不需要在脚本里自己拼 safe_key / credential_key。
• 您不需要手动调用 TESTANY_SECRETS_SERVICE。

例如，如果您把这条 Secret 的 Key 设为 CLIENT_SECRET，那么执行时测试代码里读取的就是 CLIENT_SECRET。

Secret 状态说明

保存后，平台会为每条 Secret 返回可用性状态，常见状态包括：

• valid：引用存在，且当前测试用例具备使用该凭证的资格。
• blocked：引用存在，但当前测试用例的 owner 或 visibility 已不满足使用条件。
• invalid：引用无法解析，通常表示工作区、凭证库或凭证本身已不存在，或者引用填写不完整。

步骤 2：像普通环境变量一样读取它

一旦执行开始，这个 Secret 就会以普通环境变量的形式出现在测试运行环境里。

也就是说，您应当使用各测试框架读取普通环境变量的标准方式来读取它。

示例代码

Postman

JavaScriptCopy
const clientSecret = pm.environment.get("CLIENT_SECRET");

if (!clientSecret) {
  throw new Error("CLIENT_SECRET is missing");
}

Python

PythonCopy
import os

client_secret = os.getenv("CLIENT_SECRET")
if not client_secret:
    raise RuntimeError("CLIENT_SECRET is missing")

Java

JavaCopy
String clientSecret = System.getenv("CLIENT_SECRET");
if (clientSecret == null || clientSecret.isBlank()) {
    throw new IllegalStateException("CLIENT_SECRET is missing");
}

Playwright (TypeScript)

TypeScriptCopy
const clientSecret = process.env.CLIENT_SECRET;

if (!clientSecret) {
  throw new Error('CLIENT_SECRET is missing');
}

JMeter

在 JMeter 中，可以在 JSR223 Sampler 的 Groovy 脚本里像读取普通环境变量一样读取它：

GroovyCopy
def clientSecret = System.getenv("CLIENT_SECRET")
if (!clientSecret) {
    throw new IllegalStateException("CLIENT_SECRET is missing")
}

保护凭证的最佳实践与建议

在软件测试过程中保护凭证，是维护被测软件完整性与安全性的关键环节。这不仅依赖 Testany 平台提供的保护能力，也依赖用户遵循规范的操作方式和完整的安全流程。以下是我们强烈建议您遵循的实践。

管理员

1. 遵循最小权限原则（PoLP）

• 访问控制： 确保用于测试的凭证只具备完成测试所需的最小权限。这样即使凭证泄露，也能将影响范围降到最低。
• 定期审计： 定期检查每条凭证关联的权限，确保它们始终符合最小权限原则。

2. 定期轮换凭证

• 自动轮换： 使用自动化工具或云服务能力定期轮换凭证，以缩短攻击者利用过期或长期有效凭证的窗口期。

3. 监控并审计访问

• 访问日志： 为凭证保险箱启用访问日志，记录对敏感信息和凭证的访问行为，并定期审查是否存在未授权访问或异常模式。
• 告警： 针对异常访问模式或与凭证使用相关的安全事件配置告警机制。

4. 将云 IAM 与受信任凭证保险箱配合使用

• 访问控制： 使用云厂商提供的 IAM 方案与受信任凭证保险箱联动，实现更稳健的权限治理。

用户

1. 不要在测试脚本或测试元数据中硬编码任何敏感信息。 请始终将敏感数据（例如 credential、PII）存放在您组织提供的凭证保险箱中，并在测试用例里通过 Secret 引用它们。执行时由运行时自动把这些值注入到环境变量里，这样可以把敏感信息与代码库隔离，降低意外暴露风险。

2. 定期轮换凭证

• 自动轮换： 使用自动化工具或云服务能力定期轮换凭证，以降低长期暴露的风险。

3. 使用专门的测试账户

• 与生产隔离： 为测试创建独立于生产环境的专用账户，确保即使测试凭证发生问题，也不会直接影响生产数据或生产服务。