Introduction To MCollective Security

2013-01-16

MCollective 27

由于mcollective采用广播范式分发请求，安全是一个复杂的主题。

这些讨论主要集中在加强基于SSL和基于AES+RSA的安全插件,这些虽然不是默认做法或者说仅仅是个选项，但却是目前最安全的做法。SSL安全插件和AES安全插件提供强有力的主叫(caller)识别，这被SimpleRPC框架用于授权和审计。

正如每个组织都会有它们自己的需求，因此几乎安全系统所有的部分都是插件化的。下面是对目前使用的基于SSL的验证、授权和审计情况的介绍。

上面图显示了一个MColletive系统的建立和可能涉及的其他讨论领域。这里主要集中讨论ACtiveMQ中间件，一些细节可能会随着中间件的选择不同而有不同。

这部分的内容只是概述这个过程及可能涉及到的安全问题，对于每一部分将会可能涉及的详细讨论都将穿插在具体小结里。

客户端连接和凭证

每一个STOMP连接都有一个用户名和密码用来获取ACtiveMQ系统的访问权限。

关于ACtiveMQ安全的讨论请参见专门部分。ACtiveMQ能够使用LDAP和其他安全提供者。细节可以参考ACtiveMQ文档。

MCollective协议安全

MCollective使用的主要协议用来记录消息创建时间和每个消息的TTL。超过TTL的消息不会被接受，今后也会考虑对回复消息做全面保护。

AES+RSA和SSL插件都会保护这两个属性加密以确保不会被篡改。

AES+RSA安全插件

当使用AES安全插件时，每个用户会需要公共钥和私密密钥，就像SSH一样需要确保私钥保持私密不被用户间共享。

这个插件可以通过配置文件类分发公钥，但是这是以安全为代价。为了更安全可以通过手动分发公钥。

首先使用AES公钥/私钥对用来加密,然后使用RSA对AES阶段加密的密钥进行加密。这为回复结构提供有效加密负载保护。

客户端在每个请求中内置主叫(caller)结构，如果RSA解密通过，其他MCollective代理、审计等可以很安全地知道是谁发起这个请求。

这个主叫(caller)在之后的授权和审计被使用。

插件保护消息的TTL和消息时间属性可以确保别人不会拦截、篡改和回复这些消息。

这个插件会带来安装、维护和性能开销，如果它保证安全地识别用户使用SSL安全插件。

SSL安全插件

当使用SSL安全插件时，每个用户会需要公共和私密证书，就像SSH一样需要确保私钥保持私密而不被用户间共享。公共部分需要分发给所有节点。

客户端使用私钥对每个请求加密签名，之后公钥会被用来验证这些签名。

客户端在每个请求中内置主叫(caller)结构，如果SSL签名验证通过，其他的MCollective代理，审计等都能安全地知道是谁发送这个请求。

这个主叫(caller)在之后的授权和审计被使用。

插件保护消息的TTL和消息时间属性可以确保别人不会拦截、篡改和回复这些消息。

连接中间件

默认情况下，中间件和节点之间未被加密，只使用SSL密钥进行签名。ACtiveMQ支持TLS, stomp connector支持包括全部基于CA证书认证验证也同时也支持TLS,配置MCollective与节点之间使用TLS过程在ACtiveMQ SSL 部分。

全面启用TLS会保护连接远离任何形式的嗅探和中间人攻击。

中间件授权和认证

ACtiveMQ有自己的用户名，每个节点和客户端段验证都使用这些。除了这些你可以在中间件层对某些主题（topics）限制访问权限。比如你可以在相同的ACtiveMQ基础设施上分别运行development collective和production collective,然后通过使用这些限制只允许的developers访问development collective。在ACtiveMQ安全部分中有这种控制的示例安装文档。

通过结合主题（topic）级别的限制和Subcollectives,可以创建虚拟隔离节点组合并且授予特定用户仅仅访问某些subcollectives。有效地划分出机器的子集并给与它们仅对这些分区的安全访问权限。

节点连接和凭证

同客户端连接一样，节点同中间件连接同样需要用户名和密码，当然也可以使用TLS。

因为一般情况下节点并不会发送新的请求，所以所有节点使用相同的用户名和密码没有任何问题。可以启用注册功能这样就能看到节点建立连接，应该限制前面提到的。

当使用SSL安全插件时，所有节点共享同相同SSL私钥和公钥，所有的回复使用这个密钥进行签名。每个节点安装节点证书不是不可能但这并没有给现有的安全级别增加安全级别。

当使用AES安全插件时，所有的节点拥有自己的密钥对而且注册数据会很安全。回复使用客户端密钥进行加密，因此仅仅客户端发送请求的人才能阅读该回复。

SimpleRPC授权

RPC框架有一个插件化的授权系统，可以对请求进行非常精细粒度的控制，比如使用Action Policy安装能创建如下策略：

应用在service代理上会对不同用户在不同动作（actions）上应用不同的权限控制。这个主叫(caller)识别是基于直接使用SSL私钥然后在每个节点上验证。

正如mcollective其他部分，授权与facts和classes这样的目标数据（metadata）紧密相连，可以使用这些来结构化授权系统，就像之前例子使用用户名一样。

可以根据自己的需求来提供适合需求的授权层，它既可以是某个代理或者是应用整个collective的。

SimpleRPC审计

RPC层能够为每个接收到的请求记录详细的审计信息，审计日志显示：SSL签名或者RSA验证，主叫（caller）、什么代理、动作和请求发送的所有参数。

审计层是一个基于系统的插件，默认提供的是每个节点会有一个日志文件，但也可以根据插件保留一个中心化的日志文件或者存入MongDB NoSQL数据库。

怎样使用需要根据自己的情况，但是很显然对于成千上万的节点中心化审计系统将会很复杂需要开发特殊插件，社区中心化审计日志能允许100多节点左右。