CouchDB中的基本HTTP认证是否足够安全,可以跨EC2区域进行复制?



我能理解在同一个句子中看到"basic auth"one_answers"safe enough"就像阅读"不带降落伞跳伞还安全吗?"一样,所以我会尽力澄清我的意思。

从我在网上看到的情况来看,人们通常将基本的HTTP认证描述为不安全的,因为凭据以明文形式从客户端传递到服务器;这将使您的凭证在网络配置中被恶意人员或中间人嗅探,您的流量可能通过不受信任的访问点(例如咖啡店的开放AP)。

为了保证您和服务器之间的对话安全,解决方案通常是使用基于ssl的连接,您的凭据可能以明文形式发送,但您和服务器之间的通信通道本身是安全的。

那么,回到我的问题…

在将一个CouchDB实例从一个地区(例如us-west)的EC2实例复制到另一个地区(例如新加坡)的另一个CouchDB实例的情况下,网络流量将通过我认为是"可信的"骨干服务器的路径传输。

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

如果没有,请澄清我在这里错过了什么场景,这将使这个设置不可接受。我知道这对于敏感数据是不合适的,我只是想更好地理解在相对可信的网络上复制的非敏感数据的来龙来脉。

Bob是对的,宁可谨慎行事,但我不同意。在这种情况下,Bob可能是对的(详见下文),但他的一般方法的问题在于,它忽略了偏执的代价。它留下了"和平红利"的钱。我更喜欢Bruce Schneier的评价,认为这是一种权衡。

简短回答

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

最大的风险不是监听,而是您自己的人为错误,然后是软件错误,这可能会破坏或损坏您的数据。创建副本!。如果您要定期复制,请计划迁移到HTTPS或类似的东西(SSH隧道,隧道,VPN)。

的基本原理

是HTTPS是容易与CouchDB 1.1?它和HTTPS一样简单,或者换句话说,不,它并不容易。

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

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

一个类似的问题是,"晚上我应该锁门吗?"看情况。你的资料上说你在托斯卡纳,所以你知道有些社区是安全的,有些则不安全。是的,总是锁上所有的门总是更安全的。但这对你的时间和精神健康有什么代价呢?这个类比有点不成立,因为花在最坏情况下的安全准备上的时间要比扭一个螺栓锁多得多。

Amazon EC2是一个中等安全的邻域。主要的风险是机会主义的,对常见错误的广谱扫描。基本上,有组织犯罪正在扫描常见的SSH帐户和Wordpress等网络应用程序,这样他们就可以进入信用卡或其他数据库。

你是浩瀚海洋中的一条小鱼。没有人特别关心你。除非你是政府或有组织犯罪的特别目标,或者是有资源和动机的人(嘿,这是CouchDB—发生了!),否则担心妖怪是没有效率的。你的对手正撒开大网,伺机大捞一笔。没有人想用鱼叉钓你。

我把它看作是高中积分学:测量曲线下的面积。时间向右(x轴)。风险行为上升(y轴)。当你做一些有风险的事情时,你节省了时间和精力,但图表会上升。当你以安全的方式做事时,它会花费时间和精力,但图表会向下移动。您的目标是最小化曲线下的长期区域,但每个决定都是具体情况具体分析的。每天,大多数美国人都乘坐汽车:这是美国人生活中最危险的行为。我们本能地理解风险与收益的权衡。互联网上的活动也是如此。

正如您所暗示的,没有传输层安全的基本身份验证是100%不安全的。EC2上任何可以嗅探您的数据包的人都可以看到您的密码。假设没有人可以是错误的。

在CouchDB 1.1中,您可以启用本机SSL。在早期版本中,使用stunnel。添加SSL/TLS保护非常简单,没有理由不这样做。

我刚刚从Amazon找到了这个声明,它可以帮助任何人了解EC2上数据包嗅探的风险。

由其他租户嗅探数据包:以混杂模式运行的虚拟实例不可能接收或"嗅探"用于另一个虚拟实例的流量。虽然客户可以将其接口设置为混杂模式,但虚拟机监控程序将不会向他们传递任何未寻址的流量。这包括由同一客户拥有的两个虚拟实例,即使它们位于同一物理主机上。像ARP缓存中毒这样的攻击在EC2中不起作用。虽然Amazon EC2确实提供了足够的保护,防止一个客户无意或恶意地试图查看另一个客户的数据,但作为标准做法,客户应该加密敏感的流量。

http://aws.amazon.com/articles/1697

相关内容

  • 没有找到相关文章

最新更新