security - CouchDB 中的基本 HTTP 身份验证对于跨 EC2 区域的复制是否足够安全？

Question

我能理解在同一句话中看到“基本身份验证”和“足够安全”很像阅读“没有降落伞的跳伞仍然安全吗？”，所以我会尽力澄清我得到的是什么在.

据我在网上看到的情况，人们通常将基本 HTTP 身份验证描述为不安全，因为凭据以纯文本形式从客户端传递到服务器；这会让您的凭据很容易被网络配置中的恶意人员或中间人嗅探，您的流量可能会通过不受信任的访问点(例如咖啡店的开放式接入点)。

为了确保您与服务器之间的对话安全，解决方案通常是使用基于 SSL 的连接，您的凭据可能以纯文本形式发送，但您与服务器之间的通信 channel 本身是安全的。

那么，关于我的问题......

在将一个 CouchDB 实例从一个区域(例如美国西部)的 EC2 实例复制到另一个区域(例如新加坡)的另一个 CouchDB 实例的情况下，网络流量将通过我认为的路径“可信” Backbone 服务器。

鉴于(假设我没有复制高度敏感的数据)任何人/每个人都会认为 CouchDB 复制的基本 HTTP 身份验证足够安全吗？

如果不是，请说明我在这里遗漏了哪些场景会使此设置无法接受。我确实理解这对于敏感数据是不合适的，我只是想更好地了解通过相对受信任的网络复制的非敏感数据的来龙去脉。

Answer 1

Bob 是对的，最好是谨慎行事，但我不同意。在这种情况下，Bob 可能是对的(请参阅下面的详细信息)，但他的一般方法的问题在于它忽略了偏执狂的代价。它留下了“和平红利”的钱。我更喜欢 Bruce Schneier 的评估，即这是一种权衡。

简答

现在开始复制!不用担心 HTTPS。

最大的风险不是线路嗅探，而是您自己的人为错误，其次是软件错误，这可能会破坏或破坏您的数据。 复制一个!。如果您要定期复制，请计划迁移到 HTTPS 或类似的东西(SSH 隧道、stunnel、VPN)。

理由

对于 CouchDB 1.1，HTTPS 是否简单？它与 HTTPS 一样简单，或者换句话说，不，它并不容易。

您必须制作一个 SSL key 对、购买一个证书或运行您自己的证书颁发机构——当然，您不会愚蠢到自行签名!从您的远程沙发上可以清楚地看到用户的散列密码!为了防止破解，你会实现双向 SSL 身份验证吗？ CouchDB 支持吗？也许您需要一个 VPN？您的 key 文件的安全性如何？不要将它们 checkin Subversion!并且不要将它们捆绑到您的 EC2 AMI 中!这违背了目的。您必须将它们分开并保持安全。当您部署或从备份恢复时，请手动复制它们。此外，用密码保护它们，这样如果有人得到文件，他们就无法窃取(或更糟，修改!)您的数据。启动 CouchDB 或复制时，必须手动输入密码才能进行复制。

简而言之，每个安全决策都有成本。

一个类似的问题是，“我应该在晚上锁上我的房子吗？这要看情况。您的个人资料显示您在图斯康，所以您知道有些社区是安全的，而其他社区则不是。是的, 始终锁好所有门总是更安全。但是你的时间和心理健康成本是多少？这个类比有点不成立，因为投入在最坏情况安全准备上的时间比扭曲 bolt 锁。

Amazon EC2 是一个中等安全的社区。 主要风险是针对常见错误的机会主义广谱扫描。基本上，有组织犯罪正在扫描常见的 SSH 帐户和 Wordpress 等 Web 应用程序，因此他们可以扫描信用卡或其他数据库。

您是大海中的一条小鱼。没有人特别关心你。 除非你是政府或有组织的犯罪团伙的特别目标，或者是有资源和动机的人(嘿，这是 CouchDB - 这种情况发生了!)，否则担心恶魔是没有效率的。您的对手正在广撒网以获取最大的收获。没有人试图用矛钓鱼你。

我将其视为高中积分:测量曲线下的面积。时间向右(x 轴)。危险行为上升(y 轴)。当您做一些有风险的事情时，您可以节省时间和精力，但图表会向上攀升。当你以安全的方式做某事时，它会花费时间和精力，但图表会向下移动。您的目标是最小化曲线下的长期区域，但每个决定都是根据具体情况而定。每天，大多数美国人都乘坐汽车:这是美国人生活中最危险的行为。我们直观地理解风险 yield 权衡。互联网上的事件也是如此。