在现代应用开发中，保护敏感配置数据（如API密钥、数据库密码等）变得越来越重要。典型的配置会包含两个部分：

• Settings: 普通配置项，非敏感数据，如监听打开，日志level等
• Secrets: 敏感配置项，如数据库密码，API Key等

典型的配置系统通常会同时包含这两部分配置项，Settings通常以明文形式存储，而Secrets则需要加密保护。

接下来是几种常见的配置文件加密方案的对比分析：

普通的.env文件​

这个是最常见的方案，简单易用，你只需要在项目根目录创建一个.env文件， 并将其添加到.gitignore中，确保它不会被提交到版本控制系统中。然后使用类似dotenv的库在应用启动时加载这些环境变量。

.env文件的优点是简单直接，各种语言和框架都有对应的库支持，使用方便，适合小型项目和个人开发者。 在Node.js和Python生态中，.env非常流行，看一下这两个语言的dotenv库就知道啦。

• dotenv npm: 一周接近7000万次下载量
• python-dotenv: 一周接近5500万次下载量

当然.env文件也有一些缺点，就是没有加密特性，敏感信息以明文形式存储在文件中，比如如果不小心提交到了版本控制系统中，可能会导致敏感信息泄露， 这也是GitHub上泄露API Key的主要原因之一，另外如果多人协作开发，协作也非常麻烦。在新的AI Code场景下，明文存储的.env文件，可能会被AI Agent读取到，导致敏感信息泄露。

JWT在Web应用中应用非常广泛，对Spring Boot应用也不例外，不少同学都会使用Nimbus JOSE + JWT生成并验证JWT， 当然Nimbus JOSE + JWT也是Spring Boot推荐的JWT开发包。

Nimbus JOSE + JWT覆盖多种算法支持，典型的如HS256，RS256等，当然也包括secp256k1的支持，其算法名称为ES256K， 详细请参考JSON Web Token (JWT) with ES256K (secp256k1) signature。

不少开发工具和框架，都或多或少地依赖环境变量来进行配置，下面介绍几款比较流行的工具和框架。

GoFr​

GoFr是一个用Go语言编写的微服务框架，专注于简化微服务的开发和部署。它提供了一套完整的工具和库，帮助开发者快速构建高性能、可扩展的微服务应用。 其配置项，GoFr Config，几乎完全是基于环境变量的。 在开发阶段，你只需要configs/.env文件来保存配置项，而在生产环境中，你可以通过环境变量来覆盖这些配置项。

Deno​

Deno是一个基于V8引擎的JavaScript和TypeScript运行时，旨在提供一个安全、现代化的开发环境。Deno内置了对TypeScript的支持，并且默认启用了许多安全特性，如权限控制和模块化。 Deno默认支持.env文件，如deno run --env-file main.ts，可以轻松为Deno应用加载环境变量配置项。

此外Deno自身的配置，也是基于环境变量的，可以通过Special environment variables进行查看。

dotenvx-spring-boot为Spring Boot应用提供了完美的配置项加密和解密支持， 保护你的配置项不被泄露，而且Dotenvx JetBrains Plugin也提供了非常好的IDE使用体验， 既保证了你的配置项安全，又保证了你的使用体验，不会降低你的工作效率。

使用Spring Boot开发REST API时，有时会涉及到一些安全级别比较高的场景，如提供用户敏感信息的REST API，会包括手机号码、身份证号码、银行卡号等， 当然这些REST API只会开放给特定的应用，而且也有注入JWT Token验证、IP来源限制等安全措施，但是安全同学还是会要求你对这些敏感信息进行字段级加密， 这样只有掌握密钥的应用，才能解密这些敏感信息，这样即便是REST API被攻击，攻击者也无法获取到敏感信息。

那么如何才能做到字段级加密呢？让我们看一下典型的做法，这里我们以抖音平台应用对接为例，进行一个说明。

Apache Maven是Java生态系统中最流行的构建工具之一，广泛应用于Java项目的构建、依赖管理和项目生命周期管理。 但是在某些场景下，我们可能需要在Maven构建过程中使用一些敏感信息，比如API密钥、数据库密码等， 典型的做法就是pom.xml文件中使用${env.VAR_NAME}来引用环境变量，然后在构建环境中设置这些环境变量即可。

典型的做法就是编写一个.env文件，然后填写相关的环境变量，然后使用一些.env支持的工具，如direnv， just - task runner等工具，都比较简单的。

如果不想使用普通明文的.env文件，而想使用Dotenvx加密版本的.env文件，那么应该如何做呢？

目前Dotenvx主要支持.env和.properties文件格式的加解密，但是在实际的开发中，我们可能还会使用到其他格式的配置文件， 如xml,toml,json等格式的文件，那么Dotenvx能否支持这些格式的文件的加解密呢？

为何这些格式的文件也会包含加密信息呢？ 主要是因为很多框架和工具，都是约定了某种格式的配置文件，包括Nginx的配置文件，Apache的配置文件等， 这些配置文件中，可能也会包含一些敏感信息，当然还有一些工具，也需要这些配置文件的。 如果你使用过consule-template，那么就会知道，在一些场景中，我们确实需要结合配置来调整一些配置文件的内容。

在我们日常开发中，不可缺少地设计到配置和私密信息的管理，主要区别如下：

• Settings: 配置信息，以明文方式存在，如应用名称，映射路径，维护人员信息等
• Secrets: 私密信息，如数据库密码，API Key等，这些信息需要加密存储

目前来说，主要有以下几种文件格式来保存这两者信息：

• .env文件： 这是最常见的配置文件格式，也是Twelve-factor App - Config推荐的做法
• application.properties文件：Java程序员在熟悉不过啦，应用的基本信息，数据库、Redis、API Key等，这些都可以放在这个文件中
• YAML文件：很多云原生应用都会采用YAML文件格式来保存配置和私密信息，在Kubernetes中，ConfigMap和Secret都是YAML格式
• JSON文件：很多前端应用和Node.js应用，都会采用JSON格式保存相关的配置
• TOML文件：Rust语言的配置文件格式，很多Rust应用都会采用TOML格式保存配置，如mise的mise.toml文件
• INI文件：很多传统的应用，尤其是C/C++应用，都会采用INI格式保存配置

对于Dotenvx采用非对称加密的方案来说，一个典型的配置文件主要包括以下信息：

• Front Matter: 保存元信息，如UUID，group，name，profile等，还包括签名信息
• Public Key: 用于加密配置项的公钥
• Variables: 配置项，key-value格式，value可以是明文，也可以是加密的，也就是同时包括Settings和Secrets

DuckDB 1.4版本增加了数据库加密功能， 截止目前为止，DuckDB涉及到Secrets的主要包括如下：

• 原生Secret：如S3和兼容存储服务的的AK/SK，http资源访问的token，huggingface和数据库访问的账号密码等
• DuckLake：主要是MySQL/PostgreSQL元信息数据库的账号密码，S3服务的AK/SK等，这个是DuckLake的核心配置
• 加密数据库：是对整个数据库的加密，使用AES 256进行加密，加密密码由用户提供

DuckDB虽然提供了Secret的管理能力，但是并没有达到安全的需求，而且用户使用体验也有一些问题，如：

• Temporary Secrets：临时Secret，保存在内存中，进程退出后就会丢失，所以要每次都要创建，如S3的AK/SK，我都是每次创建，反复copy创建Secret的SQL。
• Persistent Secrets: 持久化Secret，默认以未加密的方式保存在$HOME/.duckdb/stored_secrets目录下

鉴于DuckDB的Secret管理的加密特性缺失，所以也有不少人建议使用KMS来进行加密，而且好像也没有第三方的扩展来支持这一点。

此外如果你稍不留意的话，你创建的Secret的SQL语句就会被记录到$HOME/.duckdb_history文件中，这个文件也是明文保存的。

Dotenvx采用非对称方式对配置项进行加密，默认的私钥都保存在$HOME/.dotenvx/.env.keys.json文件中，这个做法和其他工具也没有什么不同， 如大家都知道的$HOME/.ssh/id_rsa文件，也是保存SSH私钥的地方，你的GitHub也是使用这个私钥进行SSH认证的。

但是还是有些同学会担心这个私钥文件的安全性，毕竟这个文件是保存在本地磁盘上的，如果被其他人获取到，那么就可以解密你的配置项了。 这个不是杞人忧天，而且确实有这种风险，不少同学的私密信息，就是这样被恶意软件或者代码窃取的。

此外保存电脑上，还有一个丢失的风险，如你的笔记本电脑丢失了，或者被盗了，虽然笔记本有登录密码，但是这个开机密码很容易被跳过， 那么这个秘钥文件就会泄露，你还需要准备应急预案。大公司、金融组织和其他相关部门，员工的笔记本电脑丢失和被盗后，第一时间就是要上报给公司， 不是没有道理的。

安全编辑器是一种专门设计用于处理敏感信息的文本或代码编辑器。其核心目标是防止数据在编辑过程中被无意或恶意地泄露，确保信息的机密性和完整性。 它不仅仅是“一个带加密功能的编辑器”，而是将安全理念深度融入其整个生命周期——从启动、编辑、保存到退出的每一个环节。 普通编辑器或者IDE（如文本编辑器、VIM、VS Code、Sublime Text，IntelliJ IDEA）关注的是功能和用户体验，而安全编辑器将安全性视为与功能性同等甚至更高优先级的核心要求。