我们正在计划一个安全的Node.JS服务器,它使用多个第三方Web服务。每个都需要操作团队需要配置的凭据。管理Node.JS的Web服务凭据的最佳实践?
很明显,他们可以简单地将它们以明文形式放在配置文件中。
Microsoft .NET似乎提供了更好的DPAPI选项 - 请参阅Credential storage best practices。有没有办法通过IISNode使其可用?或者是否有任何其他选项可以在Node-JS配置中保护这些凭据?
- 查尔斯
我们正在计划一个安全的Node.JS服务器,它使用多个第三方Web服务。每个都需要操作团队需要配置的凭据。管理Node.JS的Web服务凭据的最佳实践?
很明显,他们可以简单地将它们以明文形式放在配置文件中。
Microsoft .NET似乎提供了更好的DPAPI选项 - 请参阅Credential storage best practices。有没有办法通过IISNode使其可用?或者是否有任何其他选项可以在Node-JS配置中保护这些凭据?
有2种方式来做到这一点安全:
第一个是当您启动您的应用程序使用命令行参数。
这些参数然后process.argv
于是发现,node myapp.js username password
会给你:
process.argv[0]=node
process.argv[1]=/.../myapp.js (absolute path)
process.argv[2]=username
process.argv[3]=password
二是设置凭据作为ENV变量。通常认为这是最好的做法,因为只有您有权访问这些变量。
你将不得不使用export命令设置变量,比你访问它在process.env
有几个选项进行了广泛讨论,这里包括由xShirase建议二:
http://pmuellr.blogspot.co.uk/2014/09/keeping-secrets-secret.html
用户定义的服务解决了这个问题,但仅限于Cloud Foundry。
这个博客http://encosia.com/using-nconf-and-azure-to-avoid-leaking-secrets-on-github/指出你通常可以在服务器上单独设置环境变量,并建议使用nconf分别读取它们和配置文件。
我还在想,IIS是否有特色?
我现在必须做同样的事情对我的外部API凭据。这是我做过什么
希望这有助于。
所以你的配置可以和节点代码一样位于同一个容器中。
感谢您的响应。但也许我没有说清楚。这将是一个Web服务器 - 我没有启动“应用程序”。所以ENV变量和命令行参数最终都必须位于脚本的某个位置;使用它们不会提供额外的安全性。或者我错过了什么? – CharlesW 2014-10-09 16:56:39
您的节点服务器仍然必须从某处启动,因此您可以在运行服务器的计算机上设置env变量,不是吗? – xShirase 2014-10-09 16:58:35