【问题标题】:best practice for sensitive configuration data in source control?源代码控制中敏感配置数据的最佳实践?
【发布时间】:2011-07-13 17:34:05
【问题描述】:

我已经看到了一些解决这个问题的方法,所以我很好奇 SO 社区对此有什么看法。

如果我有用于访问生产数据库的配置数据(特别是连接字符串):

  • 将这些信息保存在源代码控制中是不是一个坏主意(例如黑客的另一种攻击途径)?
  • 如果您不将其保存在源代码管理中,那么您会将其保存在哪里?
  • 这是一个“如果他们已经进入你的源代码控制服务器,那么你就完蛋了”的例子吗?

【问题讨论】:

    标签: version-control deployment production-environment


    【解决方案1】:

    如果您担心这个问题(坦率地说,我不担心这个问题),您可以将连接字符串编码保存,并将密钥存储在其他地方(= 不同的服务器)。

    【讨论】:

    • 我也不相信我应该担心它。你不担心的理由是什么?
    • 首先-希望,如果您在一家公司工作,您的源代码控制不在公共服务器上。所以这更安全一些。其次-您的生产数据库可能没有很大的价值-如果您开发银行/电子商务应用程序或包含其他敏感数据的应用程序,那么可以,但否则-谁会打扰?第三,也是最重要的——破解你的应用程序可能比破解你的源代码控制更容易(我知道这对我的应用程序来说是正确的:))
    • “谁来打扰”从来都不是合法的风险缓解措施,随着时间的推移,这一点变得非常明显。人们到处重复使用密码。对一个站点的破坏可能会产生严重的级联后果。
    • 也就是说,如果您的 VCS 托管在受到良好保护的服务器上,并且在此之外实施了自己的访问控制,并且您不允许签出/克隆到非公司系统,那么您可能没问题。
    • @Novelocrat:我半同意你的第一点。 “谁来打扰”本身并不是一个争论,也不应该被视为让自己不受保护的许可。这只是一个考虑到你会保护自己的长度。在这个问题的背景下:您没有持有任何有价值的东西可能的事实是考虑到非平凡的安全级别(例如在源代码控制中保护数据库密码)您想拥有
    猜你喜欢
    • 2013-03-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-05-17
    • 1970-01-01
    • 2020-05-13
    • 1970-01-01
    相关资源
    最近更新 更多