我正在设置一个NodeJS后端，该后端需要持有一些API密钥，以便与Firebase联系以验证用户。
我已经能够发布后台，并成功地从其上的API端点获得HTTP回复。我使用Express运行NodeJS API。
现在我希望NodeJS API作为我的用户和数据库联系人。但是我不确定将API密钥安全地存储在什么地方。因为我对这种类型的安全性比较陌生。
所以，我在谷歌上搜索了一下，发现人们说.env文件不是存储API密钥的安全地方。然而，在DigitalOcean的文档中，它写道：
环境变量是存储敏感信息(如API密钥)或需要从应用程序中的任何位置全局访问的信息(如版本号或硬编码路径)的好地方。
所以我的问题是，当许多其他来源说在环境变量中存储API密钥是安全的时，DigitalOcean说这是安全的原因是什么。这是因为危险在于文件的可访问性，而DigitalOcean则以某种方式保护了文件吗？我注意到他们有一个"；秘密"；您可以勾选布尔框，表示它不会出现在控制台中。但是，对于一般人来说，它也会完全无法访问吗
我主要关心的是防止黑客或恶意人员访问API密钥。我不担心有合法访问权限的人会滥用它，只担心没有合法访问权限。
期待您的真知灼见。
我将按照以下顺序(从不太安全到最安全)对存储机密的安全性进行排序：
- 将它们直接存储在代码中(非常非常糟糕)
- 将它们存储在环境变量中
- 将它们存储在磁盘上的文件中
- 可以设置访问权限，例如谁可以读取
- 如果将内容加载到env-vars中，它将与
Point 2没有什么不同
- 将它们存储在对象存储中(AWS S3、谷歌云存储)
- 使用机密管理器(AWS、GCP机密管理器)存储它们
- 使用IAM(不是一个真正存储机密的地方，而是一种控制谁可以使用上述方法访问机密的方式)
硼化：
点2&3：
如果您的系统受到损害，points 2 and 3之间的区别将变得模糊。在这种情况下，如果攻击者拥有root访问权限，他/她可以读取/写入/删除/更改所有内容，因此point 3将失败。对于point 2，攻击者可以通过3种方法访问环境变量：
根据@phmmmer在这篇文章
进程的运行环境当进程正在运行时，该进程的环境变量可以是>gt；通过CCD_ 5访问。但是，只有拥有进程或root可以访问该文件。
环境变量的源如果您使用的是init脚本，并且变量存储在该init脚本中当然，变量可以通过阅读该脚本来获得。
或者，如果环境变量来自其他地方，那么无论在哪里。
- 'ps的输出是的，我知道我说的是2，在任何一个像样的系统中，它都是2。然而，如果管理员不知道自己在做什么可以开辟第三大道
如果进程是通过类似
sh -c 'cd /foo/bar; POP=tart /my/executable'的东西启动的，那么该sh进程将在ps:中可见$ ps ax | grep POP phemmer 3085 14 5 0.0 0.0 SN 00:00 sh -c cd /; POP=tart sleep 10```
第4点：
您可以将机密作为对象存储在对象存储中，并在部署或启动时下载它们。大多数对象存储都提供日志记录功能，因此您还可以监控您的秘密是如何被使用的以及谁在使用它们。注意：Point 4是好的，如果且仅当您正确配置IAM权限。否则，它将与Point 2没有什么不同，尽管现在您正在从远程位置获取文件。
第5点：
您的应用程序可以调用机密管理器的API来使用机密。你的秘密不会存储在本地的任何地方，除非存储在内存中。而且，是的。你也可以加密你的内存，你可以在这个后中阅读更多
第6点：
IAM或身份和访问管理用于在适当的时间将对适当资源的访问权限授予适当的人员/用户/应用程序。它不是秘密存储器，但可以用于管理对秘密存储器的访问。
因此，要回答您的问题：
"Environment variables are excellent places to store sensitive information"可能是DO的夸大其词。但它们提供的不仅仅是将敏感信息存储在环境变量中并将其留在那里。
在你在问题中提到的下一篇"How to Use Environment Variables in App Platform"文档中，DO确实提供了一些关于环境变量的访问控制和加密级别：
- 运行时变量
- 在创建应用程序期间
- 创建应用程序后
- 生成时间变量
- 环境变量中的可绑定变量
- 应用程序范围的变量
- 组件特定变量
因此，当人们说使用环境变量存储敏感信息不安全时，他们中的大多数人都在谈论没有访问控制和加密的普通env-var。在这种情况下，将API密钥存储在那里肯定是不安全的。应该使用普通的环境变量来存储端口号、生产环境或其他非敏感信息等信息。
以下是我用来作为这个答案参考的一些帖子：
- 管理无服务器机密的5种方法，从最佳到最差
- 管理Terraform代码中的秘密的全面指南
- DigitalOcean：如何在应用平台中使用环境变量
同意上一篇文章。一个好的做法是思考"；如果您的系统受到损害，则它们在您的系统上作为ROOT运行"；。如果有什么你可以做的，假设他们也可以。
我想补充的一项是养成为dev/test/prod/和每个本地开发人员使用唯一API密钥的习惯。我知道这似乎很明显，但我看到过很多情况，人们在prod中做得很好，但在dev中重复使用相同的API密钥，甚至允许开发人员在他们的本地机器上使用相同的prod API密钥，因为它没有受到同样严格的保护。
此外，如上所述使用IAM可以确保限制访问，但如果你走这条路，请确保你愿意让自己更难在Azure、AWS和GCP环境之间移动。