如何在Node.js中使用Azure Key Vault安全地管理密钥
内容提要
本文介绍如何用Azure Key Vault替代.env文件管理Node.js应用密钥。通过DefaultAzureCredential实现本地与生产环境统一认证，应用启动时从Key Vault加载并缓存数据库密码、JWT密钥等敏感信息，避免凭据泄露。文中详细演示了创建密钥库、配置托管身份、部署到Azure App Service及轮换密钥的完整流程，强调最小权限原则和审计日志的重要性。
延伸解读
为什么选择Key Vault而不是.env
文章指出，.env文件容易因意外提交而泄露，且难以追踪访问记录。相比之下，Azure Key Vault提供集中管理、细粒度访问控制和审计日志，满足SOC 2、HIPAA等合规要求。对于需要向审计方证明安全控制的团队，Key Vault提供了可验证的解决方案。
统一认证：DefaultAzureCredential的便利与局限
DefaultAzureCredential让本地开发（使用az login）和生产环境（使用托管身份）无需修改代码即可切换认证方式。但需注意，它按顺序尝试多种认证方法，若环境变量中存在无效凭据，可能导致认证失败。因此，确保本地环境干净，避免残留的Azure环境变量。
缓存与启动检查：提升可靠性的关键设计
文章强调在启动时加载所有密钥并缓存，避免每次请求都访问Key Vault，降低延迟和成本。同时，若密钥加载失败则立即退出进程，防止应用带病运行。这种设计让问题在启动阶段暴露，而非在用户请求时才出现，提高了系统的可诊断性。
密钥轮换与最小权限实践
通过Key Vault，密钥轮换只需更新密钥库中的值并重启应用，无需重新部署。文章还强调最小权限原则：应用仅被授予读取所需密钥的权限（Key Vault Secrets User角色），防止横向移动。此外，所有访问均有日志记录，便于安全审计。
Q&A
为什么不应该在Node.js应用中使用.env文件存储密钥？
因为.env文件容易被意外提交到Git仓库，导致数据库密码、API密钥等敏感信息泄露。GitHub在2023年就发现超过一百万个公钥仓库泄露了密钥，且平均数据泄露成本高达488万美元。
Azure Key Vault相比.env文件有哪些优势？
Azure Key Vault提供集中式加密存储，支持密钥轮换、细粒度访问控制和审计日志。应用运行时从Key Vault获取凭据，避免凭据出现在代码或仓库中。
DefaultAzureCredential在本地和生产环境分别如何使用？
DefaultAzureCredential会自动尝试多种认证方式：本地开发时使用Azure CLI登录会话（az login），生产环境（如Azure App Service）使用托管身份（Managed Identity）。这样同一套代码无需修改即可在两种环境运行。
如何在Node.js应用中从Azure Key Vault加载并缓存密钥？
使用@azure/keyvault-secrets和@azure/identity包，创建SecretClient，在应用启动时调用loadAllSecrets()函数，将所需密钥（如DB-HOST、DB-PASSWORD、JWT-SECRET）加载到内存缓存中，后续通过getFromCache()获取，避免每次请求都访问Key Vault。
部署到Azure App Service时，如何授予应用访问Key Vault的权限？
首先为App Service启用系统分配的托管身份，然后获取其principalId，再通过az role assignment create命令为托管身份分配“Key Vault Secrets User”角色，这样应用只能读取密钥，不能修改或删除，遵循最小权限原则。
如何在不重新部署的情况下轮换Azure Key Vault中的密钥？
只需在Key Vault中更新密钥值，然后重启应用（如az webapp restart），应用启动时会重新从Key Vault加载最新密钥。无需修改代码或重新部署。
如果应用启动时无法从Key Vault加载密钥，会发生什么？
应用会立即退出（process.exit(1)），并输出错误信息。这是故意设计的，避免应用在缺少凭据的情况下带病运行，导致后续请求失败。
在本地测试时，如何验证Key Vault集成是否成功？
运行npm start，看到“All secrets loaded successfully.”后，使用JWT_SECRET生成一个测试令牌，然后调用/api/status端点，如果返回包含“All secrets loaded from Azure Key Vault”的JSON，说明集成成功。
