场景与目标
在 Linux 环境下使用 Postman 进行接口测试时，保护请求体中的敏感数据和凭证成为重要需求。本文聚焦于在 Linux 上实现数据加密的两条实操路径，并结合 Postman 的脚本能力与常见的 Linux 工具链，帮助你在实际工作中落地。
通过将加密逻辑分散到客户端（Postman 脚本）与服务器端解密、以及利用操作系统层的加密存储，可以实现更高的安全性。重要点是确保密钥管理、密钥轮换以及加密格式的一致性。
本文的核心是给出可执行的步骤，覆盖：1) Postman 内置 CryptoJS 的客户端加密；2) Linux 命令行的 OpenSSL/GPG 加密与测试；3) 如何在 Postman 流程中与这些加密方式结合。本主题的核心表达为 Postman在Linux环境下如何加密数据：实操指南，帮助你快速落地实现。
使用 Postman 内置 CryptoJS 实现数据加密
在 Pre-request Script 中进行对称加密
Postman 的脚本环境内置了 CryptoJS 库，因此可以在发送请求前对请求体进行对称加密，避免明文直接暴露在网络日志中。要点在于将明文 payload 转换为密文并把密文作为环境变量供请求体引用使用。
// Pre-request Script
const secret = "mysecretkey"; // 应使用更安全的密钥管理方式
const payload = { user: "alice", action: "login" };
const ciphertext = CryptoJS.AES.encrypt(JSON.stringify(payload), secret).toString();
pm.environment.set("encrypted_payload", ciphertext);
上述代码会在当前环境变量中生成一个加密后的 payload。注意：生产环境应通过安全的密钥轮换和密钥管理机制来替代硬编码密钥。
在请求体中引用密文时，可以将请求体设为原始 JSON，并使用变量占位符来插入密文。确保请求头 Content-Type 设置为 application/json，且服务器能够正确处理解密后的数据。
{"payload": "{{encrypted_payload}}"
}将密文放入请求体的最佳实践
除了直接在 Pre-request Script 里生成密文，还可以将密文存放在环境变量或全局变量中，以便在不同的请求中重复使用。避免将密钥或明文直接写入脚本，并在测试阶段开启详细日志时避免输出密文。
// 将明文 payload 直接加密并写入全局变量的示例
const payload = { account: "bob", secret: "s3cr3t" };
const encryptedPayload = CryptoJS.AES.encrypt(JSON.stringify(payload), secret).toString();
pm.globals.set("encrypted_body", JSON.stringify({ data: encryptedPayload }));
在请求的 Body 中直接引用全局变量即可实现多请求复用。这一点对日常自动化测试尤为重要，能显著简化对敏感数据的处理流程。
Linux 命令行加密：OpenSSL 与 GPG 的组合
使用 OpenSSL 进行对称加密并导出可传输的密文
在 Linux 环境下，使用 OpenSSL 的对称加密能力，可以把敏感数据离线加密后再通过 Postman 发送。典型做法是将明文文件加密为密文，并以 Base64 形式在网络中传输，接收端再进行解密。这是端到端加密的一种常见实现方式，尤其在没有直接接入密钥托管的场景中。
# 使用 OpenSSL 进行对称加密，输出 Base64 文本
openssl enc -aes-256-cbc -a -salt -in plaintext.json -out ciphertext.b64 -pass pass:MyP@ssw0rd
将密文文本通过 Postman 发送时，Body 可以使用该 Base64 字符串，服务器端接收到后再进行解密。务必在传输层使用 HTTPS，以额外保护传输过程。
如果你愿意在命令行直接查看明文与密文之间的对比，可以先解密出原文进行验证。下面是解密的演示片段（仅供测试环境使用）：
# 解密示例
openssl enc -aes-256-cbc -d -a -in ciphertext.b64 -out plaintext_decrypted.json -pass pass:MyP@ssw0rd
使用 GPG 实现对称/非对称加密的工作流
GPG 提供了对称和公钥加密模式，适用于需要更强密钥管理的场景。对称加密适用于快速保护临时数据，而非对称加密常用于需要安全地分发密钥的场景。以下示例展示了对称加密的基本做法，便于在 Linux 下与 Postman 搭配使用。
# 使用 GPG 进行对称加密（AES256）
gpg --symmetric --cipher-algo AES256 secret.json
生成的 secret.json.gpg 即可在 Postman 端作为密文上传，服务器端再使用相同的密钥进行解密。请确保密钥管理遵循组织的安全策略，避免通过明文传输密钥。
如果要在协作环境中实现密钥分发与轮换，可以将公钥部署在服务器端，使用公钥加密对数据进行保护，再由接收端用私钥解密。您也可以将对称密钥托管在受保护的密钥仓库中，结合自动化流水线实现轮换与访问控制。
环境变量与密钥管理在 Postman 的实践
环境变量安全存储与解密加载
Postman 环境变量在本地磁盘中以文本形式存储，存在被他人读到的风险。因此，在 Linux 环境中可将环境文件进行系统级加密（如 GPG）后再在 CI/CD 或本地工作流中解密加载。这样可以在不直接暴露密钥的前提下，继续使用 Postman 的变量机制进行测试。
# 使用 GPG 对环境变量文件进行对称加密
gpg --symmetric --cipher-algo AES256 postman_env.json
在需要使用时，通过解密步骤将环境变量文件还原为可读 JSON，然后用于 Newman 或 Postman Runner。下述示例展示了在 CI/CD 中的基本流程：解密、运行 Newman、再清理密文。
# CI/CD 流程示意（简化）
gpg --decrypt --output=postman_env.json postman_env.json.gpg
newman run collection.json -e postman_env.json
rm -f postman_env.json
使用 Newman 与加密环境文件的工作流
Newman 是 Postman 的命令行工具，适合在持续集成中使用。将环境文件进行加密后，在执行测试前进行解密加载，测试完成后立即清理密文，能有效降低测试数据泄露风险。这是一种在 Linux 环境中实现端到端加密的常见工作流。
# 通过 Newman 使用解密后的环境文件
gpg --decrypt --output=env.json env.json.gpg
newman run collection.json -e env.json
rm -f env.json
综合要点与实操要点回顾
在本文的实操路径中，读者可以看到两条核心路线：一是依赖 Postman 内置的 CryptoJS，在 Pre-request Script 中直接对请求数据进行加密；二是结合 Linux 环境的 OpenSSL / GPG 等工具，对敏感数据进行外部加密后再通过 Postman 发送。通过这两种方法的结合，可以为数据在传输与存储过程中的隐私保护提供多层防护，并且能够灵活地嵌入到现有的测试或持续集成流程中。
本文覆盖的操作步骤包括：在 Postman 中使用 CryptoJS 进行对称加密、在 Linux 上使用 OpenSSL 进行对称加密并导出 Base64、以及通过 GPG 实现更强的密钥管理和数据保护。这些内容共同构成了一个完整的、可落地的加密实操指南，帮助你在 Linux 环境下实现数据加密需求。你可以结合具体的 API 要求和合规要求，选取合适的路径来落地实施。
