步骤 1

npx dotenv-vault push

您运行 npx dotenv-vault push。您的请求已启动。

步骤 2

加密连接

您的 .env 文件已加密并通过 SSL 安全地发送到 Dotenv 的内存服务器。

步骤 3

Dotenv 服务器

此加密有效负载将被解密并短暂地保存在内存中以完成后续步骤。 之后，内存将被刷新。 请放心，解密版本永远不会持久保存到 Dotenv 系统。

步骤 4

解析

您的 .env 文件将在内存中逐行解析。

注意： 不同语言和框架的 dotenv 解析器之间存在细微差异。 到目前为止，Dotenv Vault 能够处理 100% 的这些差异，我们还将继续添加测试用例以涵盖所有边缘情况。

步骤 5

密钥提取

每个键值对（以及任何注释）都在内存中提取。

步骤 6

密钥划分

密钥被划分为单独的密钥和值。 这是有意为之的。 它们将被存储在独立的数据库中以增强安全性。 这样，如果攻击者以某种方式获得了对一个数据库的访问权限，他们将无法理解数据 - 因为他们只掌握了拼图的一半。

步骤 7

AES-GCM 加密

KEY 被加密。 VALUE 被加密。 它们使用不同的主加密密钥加密。 这样，如果攻击者以某种方式获得了 VALUE 解密密钥的访问权限，他们会发现数据毫无用处。 他们将无法知道密钥属于 Twilio 还是 AWS。

加密使用 AES-GCM 算法。 它

• 经过充分研究
• NIST 推荐
• IETF 标准
• 由于专用的指令集而速度快

此外，所有主加密密钥都按照未公开的时间表轮换，进一步提高了安全性。

步骤 8

令牌化

加密的 VALUE 被发送到 Dotenv 保管库以安全存储。 一个令牌将作为标识符返回。 令牌在下一步中用于将 KEY 映射到 VALUE 以便稍后进行安全读取操作。

保管库采用了多项安全措施。 这些措施包括但不限于

• 与应用程序数据库分开的存储库
• 无法通过互联网访问，并阻止所有外部连接
• 要求使用加密客户端，这些客户端必须经过应用程序 - 应用程序本身具有额外的加密层
• 连接到保管库时有更严格的 TLS 要求。 无法使用 TLS 1.0 进行连接。
• 存储在保管库中的密钥不仅在存储库级别加密。 就像您在之前的步骤中看到的那样，它们还在每个存储库条目中加密。

步骤 9

使用令牌存储密钥部分

最后，加密的 KEY 和令牌（代表加密的 VALUE）被放在一个信封中并一起存储在应用程序数据库中。