因为很懒好久没写文章，正在考虑应该写点什么的时候，有人撞枪口上来了，看到一篇MongoDB数据库又被勒索攻击了，借此机会聊聊MongoDB的各种安全机制。再说，怼人的事情我最乐此不疲了。
1 怼人篇
其实这种炒冷饭的文章近几年来反反复复好多次了，本来没有什么怼的热情，但是这位仁兄另辟蹊径，自创了一个“未授权访问漏洞”。那我们就来聊聊这个“未授权访问漏洞”到底是怎么回事。
在原文“02 漏洞成因”中描述了他所认为的“漏洞”所在。其实这个行为有一个更专业的名字叫做“localhost exception”（https://docs.mongodb.com/manual/core/security-users/#localhost-exception）。与他的理解不同的是，localhost exception成立的必要条件有三：
已经启用了认证授权。
数据库中没有任何用户，这点他说对了。
必须从localhost访问（不然为什么叫localhost exception？）
也就是说如果这个“漏洞”要生效，黑客必须先ssh到你的主机上，到你的主机上，主机上……你管这叫漏洞？我觉得ssh到你主机上才叫漏洞。这么决定性的条件你只字不提，作为一个安全类的公众号，再严谨点如何？
别的不多说了，总结一下，目前所有勒索事件的发生都是因为没有通过security.authrization启用认证授权，没有其他原因。
2 干货篇
既然聊到了安全问题，下面就来看看MongoDB都有哪些安全机制，按需取用。
认证与授权
不用我多说大家都知道MongoDB的角色权限管理了。还有少数不知道这是什么的，黑客盯上的就是你们。不过似乎很多人不知道每个数据库用户都是可以约束可访问地址的，这是3.6新加入的一个特性。包括：
限制访问来源地址：使用这个用户访问系统时必须来自这个地址；
限制访问目标地址：使用这个用户访问系统时只能访问这个地址；
举个例子可能更好理解：
场景一：假设A是数据库管理员，B是服务器管理员。A手上有所有数据库的账户，怎样防止A或者B删库跑路呢？可以在创建账户时限制访问来源地址，只能从某一台服务器才能登录数据库，而服务器登录权限掌握在B手上，所以A有数据库账号，B有机器权限，谁也别想单独干坏事，除非两人都想删库跑路……
场景二：A通过B的授权登录上了数据库，A想要偷偷拿到用户数据出去卖，可以防止这样的情况吗？方案之一可以是启用审计日志，把A做过的事情都记录下来，将来有迹可查。但是我只希望审计A的行为，不希望审计应用程序的行为，所以就可以限制访问目标地址，让A只能访问启用了审计的那个节点，应用程序则访问没有审计的节点。
通讯加密
MongoDB的节点之间的通讯是可以加密的，应用与数据库之间的通讯也是可以加密的。如果你的应用跟数据库经过了公网，或者数据库节点之间经过了公网，就可以通过启用TLS来确保通讯安全。启用加密本身不难，难倒大部分人的可能是签证书的问题，为了节省篇幅我把签证书的脚本放到了Github上：https://github.com/zhangyaoxing/mongodb-scripts/blob/master/create-certificate/create-certificates.md
即便如此，作为从业人员，还是强烈建议大家应该先了解TLS是如何工作的。
客户端字段级加密
完整的字段级加密功能是企业版功能，但是社区版也可以使用大部分功能，不影响正常使用。具体使用的问题限于篇幅不可能在这里讲清楚，大致说说它是用来干什么的。字面意思上大家都能理解它到底是怎么回事。但是为什么需要字段级加密呢？很大的原因还在于隐私保护。比如DBA是有数据库权限的，但是DBA并不应该看到用户隐私信息，传统的加密方案无法解决这个问题，客户端字段级加密则可以解决。在此方案下，DBA能够查询数据，但看到的是加密的字段，没有密钥的DBA是无法解读加密信息的。另外如果大家对GDPR还有印象的话，GDPR明确要求了“被遗忘权”(right to be forgotten)。在字段级加密的前提下，如果所有隐私信息都使用一个密钥加密，那么销毁了密钥就等于“遗忘”了所有的隐私信息，这也是字段级加密的目的之一。
日志编校
企业版功能。在日志输出到文件之前对所有字段做脱敏处理，在避免日志中出现用户信息等关键数据。这在很多合规场景中是强制性规定。
落盘加密
企业版功能。对使用者透明的加密，也是很多合规场景的强制性要求。
审计
企业版功能。跟踪用户的可疑行为以便在发生问题后有迹可查。其他数据库中也有相同的概念，不多做解释。同样是很多合规场景的强制性要求。
LDAP/Kerberos集成
企业版功能。由LDAP/Kerberos管理认证授权相关功能。
3 总结
另外今天是愚人节，但是我说的都是认真的。
