安全的 CouchDB 架构
我想创建一个使用 CouchDB 作为分布式数据库的应用程序。每个用户都将使用本地 CouchDB 副本，这样就可以离线工作。 每个本地副本将与中央副本同步，这不是主副本，只是现在更容易使用中央副本。
鉴于这种设计，我如何才能保护本地和中央数据库的安全？
我所说的安全是指用户必须使用用户名和密码进行身份验证，然后才能读取或写入数据库。
当然，更重要的方面是保护中央数据库，因为任何本地数据最终都可能并且将会被黑客攻击，但中央（或远程）数据库应该更安全。 我读到人们建议将 CouchDB 放在代理后面，但是复制过程如何代表用户进行身份验证？
谢谢你， 我愿意。
I would like to create an application that use CouchDB as distributed database. Each user will work with the local CouchDB replica, and that way will be able to work offline.
Each local replica will sync with a central replica, this is not a master replica it just easier for now to use central replica.
Given this design how can I secure both local and central databases?
By secure I mean that a user will have to authenticate with username and password before allow to either read or write to the database.
Off course the more important aspect is securing the central database because anything local can and will be hacked eventually but the central (or remote) database should be more secure.
I've read that people suggest putting the CouchDB behind a proxy but how can the replication process authenticate on behalf of the user?
Thank you,
Ido.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为我无法给出一些针对智能 Couch 的建议，因为所有要点都属于一般安全问题，但以下是它们：
对于初学者，请确保节点之间的通信是加密的。 CouchDB 从 1.1 开始就原生支持 SSL，因此对于早期版本，您必须将其置于某个能够处理 SSL 的代理（nginx、apache 的 mod_proxy、varnish）后面，或者使用 VPN 限制访问。
检查角色和用户权限。禁止一切不需要蜜蜂允许的事情。需要有效的用户等...
确保如果某人经过身份验证，并不意味着您可以信任他。确保严格验证所有数据 - 自由使用
validate_doc_update函数。检查每个人是否都在访问他们真正有权访问的数据。再次强调，身份验证并不意味着授权。I don't think I can give some smart Couch-specific advice, as all the points fall in general security concerns, but here are them:
For starters, make sure that communication between nodes is encrypted. CouchDB supports SSL natively since 1.1, so for earlyer versions you will have to put it behind some proxy that will handle SSL (nginx, apache's mod_proxy, varnish), or limit access with VPN.
Check roles and user permissions. Disallow everything that need not to bee allowed. Require valid users, etc...
Make sure that if someone is authenticated it doesn't mean you can trust him. Make sure that you tightly validate all the data - use
validate_doc_updatefunctions liberally. Check that everyone is accessing data they really have access to. Again authentication does not mean authorization.