5个MongoDB安全提示，帮助您远离困境

The recent Meow attacks on unsecured MongoDB and Elasticsearch instances are yet another reminder that we need to properly secure our databases.

最近对不安全的MongoDB和Elasticsearch实例进行的Meow攻击再次提醒我们，我们需要适当地保护数据库。

Unlike those in previous MongoDB attacks, the Meow hackers don’t leave any ransom requests or notes. Their script simply deletes all data, first by dropping all collections, then creating new ones with the telltale meow string.

与以前的MongoDB攻击不同 ，Meow黑客不会留下任何赎金要求或票据。 他们的脚本只删除所有数据，首先删除所有集合，然后使用Telltale meow字符串创建新数据。

@MayhemDayOne @MayhemDayOne

1,779 Elasticsearch and 701 MongoDB instances had been already meowed by July 24, according to Bob Diachenko.

鲍勃·迪亚琴科 ( Bob Diachenko)称 ，到7月24日，已经拥有1,779个Elasticsearch和701个MongoDB实例。

By July 25, the number had risen to almost 4,000 databases, which by then also included Redis, Cassandra, CouchDB, Redis, Hadoop, Jenkins, and open-file system instances.

到7月25日，该数据库的数量已增加到近4,000个 ，其中还包括Redis，Cassandra，CouchDB，Redis，Hadoop，Jenkins和开放文件系统实例。

The hacking attacks have claimed Zimbabwe’s leading online payments platform and a prominent open-source VPN as victims and appear likely to continue.

黑客攻击已使津巴布韦领先的在线支付平台和著名的开源VPN成为受害者，而且似乎很可能会持续下去 。

MongoDB安全性必须是主动的，而不是被动的 (MongoDB Security Must Be Proactive, Not Reactive)

At Studio 3T, we’ve received the occasional support ticket from customers whose databases had been hacked, asking if we’ve maybe stored a backup of their data (we never do — we’re a MongoDB GUI).

在Studio 3T中，我们偶尔会收到数据库遭到黑客入侵的客户的支持票，询问我们是否可能存储了他们数据的备份(我们从未这样做过- 我们是MongoDB GUI )。

There are two levels of MongoDB security:

MongoDB安全性有两个级别：

1. There’s the database, which you can secure by enforcing user and role access control, using the right authentication, limiting network exposure — the usual suspects.
   有一个数据库，您可以通过使用正确的身份验证，限制网络暴露(通常是可疑的)来实施用户和角色访问控制，来保护这​​些数据库。
2. There’s also the client side, the handling of actual data that you could secure by enabling read-only mode on a connection or collection level, using your own cryptographic key store to encrypt passwords, among other things.
   还有客户端，可以处理实际数据，这些数据可以通过在连接或收集级别启用只读模式，使用您自己的加密密钥存储区来加密密码来保护。

No one wants to be hacked, but prevention requires action. Meow-proof your MongoDB (or MongoDB Atlas) instance today by taking these five easy steps on both the database and client side.

没有人想要被黑客入侵，但是预防需要采取行动。 现在，通过在数据库和客户端上执行这五个简单的步骤，就可以使您的MongoDB(或MongoDB Atlas)实例实现低噪音。

1.停止将0.0.0.0列入白名单并将网络公开限制为受信任的IP地址 (1. Stop Whitelisting 0.0.0.0 and Limit Network Exposure to Trusted IP Addresses)

This is particularly relevant for MongoDB Atlas clusters, which require you to whitelist your IP address during setup.

这对于MongoDB Atlas集群尤其重要，该集群要求您在设置过程中将IP地址列入白名单 。

Most users likely whitelist their current IP address at first, but IP addresses usually change over time. At some point, you’ll likely come across this error:

大多数用户一开始可能会将其当前IP地址列入白名单，但IP地址通常会随着时间而变化。 在某个时候，您可能会遇到此错误：

Could not connect to any servers in your MongoDB Atlas cluster. Make sure your current IP address is on your Atlas cluster's IP whitelist.

MongoDB Atlas has a default “Allow access from anywhere” option that whitelists all IP addresses (0.0.0.0). This is an insecure option that grants access to everyone on the web. Do not use this.

MongoDB Atlas具有默认的“允许从任何地方访问”选项，该选项将所有IP地址(0.0.0.0)列入白名单。 这是一个不安全的选项，授予网络上的所有人访问权限。 不要使用这个。

Screenshot of MongoDB Atlas

MongoDB Atlas屏幕截图

A more secure alternative would be to whitelist a range of IP addresses, whitelist multiple IP addresses (like your work and home IPs), or whitelist your current IP address regularly.

一种更安全的选择是将一系列IP地址 列入白名单，将多个IP地址 (例如您的工作和家庭IP) 列入白名单 ，或将您当前的IP地址定期列入白名单 。

2.启用访问控制并仅授予用户所需的角色 (2. Enable Access Control and Grant Users Only the Roles They Need)

If you aren’t self-hosting your MongoDB server, then your MongoDB instance is already using SCRAM as a default authentication mechanism.

如果您不是自托管MongoDB服务器，那么您的MongoDB实例已经在使用SCRAM作为默认身份验证机制。

With it in place, users are required to provide a login and password first to read or modify data. But what good is a mechanism with no one to authenticate it?

放置好后，要求用户首先提供登录名和密码才能读取或修改数据。 但是，没有人对其进行身份验证的机制有什么好处呢？

If you’re the user administrator, put this preemptive security measure to use by creating additional users in your database and only granting the roles they need. This is a more secure alternative to passing connection strings around.

如果您是用户管理员，请通过在数据库中创建其他用户并仅授予他们所需的角色来使用这种先占式安全措施。 这是传递连接字符串的更安全的选择。

3.强制执行身份验证-记住您有选择 (3. Enforce Authentication — and Remember You Have Options)

If you are self-hosting your MongoDB server, then you must enable authentication first.

如果要自托管MongoDB服务器，则必须首先启用身份验证 。

Otherwise, MongoDB will set bindIp to localhost by default — a feature introduced in MongoDB 3.6 to enforce security — which means only you will have access to your data.

否则，MongoDB将默认将bindIp设置为localhost(MongoDB 3.6中引入的用于bindIp安全性的功能)，这意味着只有您才能访问您的数据。

As we learned in the first tip, don't fall for the easy workaround of setting bindIp to 0.0.0.0.

正如我们在第一篇技巧中了解到的，不要因为将bindIp设置为0.0.0.0的简单变通办法而bindIp 。

For users who need a more robust authentication mechanism than SCRAM, MongoDB also supports x.509, LDAP, and Kerberos.

对于需要比SCRAM更可靠的身份验证机制的用户，MongoDB还支持x.509，LDAP和Kerberos 。

The first three points should already be sufficient Meow-proofing, but here are two additional security measures you can also take on the client side.

前三点应该已经足够满足喵喵的要求，但是您可以在客户端上采取另外两项安全措施。

4.在连接或收集级别启用只读模式 (4. Enable Read-Only Mode on Either a Connection or Collection Level)

Read-only mode within a GUI or client does not replace properly implemented access control.

GUI或客户端中的只读模式不能替代正确实现的访问控制。

However, it’s still a handy option to enable if you don’t want to mess anything up (e.g. production data you’ve rightfully been granted access to).

但是，如果您不想弄乱任何内容(例如，您理所当然地被授予访问权限的生产数据)，启用它仍然是一个方便的选择。

Studio 3T lets you enable read-only mode on MongoDB collections and connections, so you can query collections and explore results with the peace of mind that nothing could be mistakenly edited.

Studio 3T允许您在MongoDB集合和连接上启用只读模式 ，因此您可以放心地查询集合并浏览结果，以免被错误编辑。

5.使用您自己的加密密钥存储区加密MongoDB密码 (5. Encrypt MongoDB Passwords Using Your Own Cryptographic Key Store)

MongoDB offers encryption at rest, which allows the database to encrypt data files that can only be decoded and accessed by users with the right decryption key. But it’s only available in MongoDB Enterprise.

MongoDB提供静态加密 ，该加密使数据库能够加密仅由具有正确解密密钥的用户才能解码和访问的数据文件。 但仅在MongoDB Enterprise中可用。

An alternative would be to use a third-party GUI that supports password encryption using your own cryptographic key store. This is a more secure way of handling passwords than the default mechanisms in place.

一种替代方法是使用第三方GUI，该GUI支持使用您自己的加密密钥存储区进行密码加密。 与现有的默认机制相比，这是一种更安全的密码处理方式。

翻译自: https://medium.com/better-programming/5-mongodb-security-tips-364a44f32977