面向 Java 开发人员的 db4o 指南: 事务、分布和安全性

核心提示： 要在 db4o 中定义访问控制，只需使用 grantAccess() 方法，面向 Java 开发人员的 db4o 指南: 事务、分布和安全性(4)，它授权对整个数据库实例的访问，这种方法简化了安全设置场景，您可以 考虑使用它，毕竟，但是这样一来就无法使用最小特权原则了，因此该方法既有优点也有缺点

要在 db4o 中定义访问控制，只需使用 grantAccess() 方法，它授权对整个数据库实例的访问。这种方法简化了安全设置场景，但是这样一来就无法使用最小特权原则了，因此该方法既有优点也有缺点。

最小特权原则

和许多安全思想一样，最小特权原则 的原理很简单，但是有时难于在实践中实现。该原则规定给定用户或代码体应该被授予能完成所分配任务的最少权限，不能拥有多余的特权（显然也不能缺少必要的特权）。例如，在一个 RDBMS 场景中，访问 RDBMS 的代码应该只对它访问的表拥有基本的 SELECT/INSERT/UPDATE/DELETE 权限，而不能超出这些权限。这样，即使代码中包含 SQL 注入攻击程序，它也不能执行注入攻击，因为它没有足够的数据库访问权限。

目前 db4o 还不支持更加粒度化级别的解决方式，其他 OODBMS 系统可能更加灵活。您应该确保只使用了最小数量的安全性凭证。如果不能限制登录需要使用的资源，那么至少可以限制系统访问原则的数量。

加密格式

分布式系统的安全性问题 — 尤其是 Fourth Fallacy of Enterprise Computing— 说明，不能认为只有监听网络通信量的人或代码才是可信的。这意味着您必须确保在网络中传输的数据不是明文和二进制形式（如果使用的二进制形式的格式众所周知，那么它和明文形式是相同的）。

关心安全性的开发人员也会关心存储在 db4o 文件中的数据，因为文件 “仅仅是文件”，因此打开文件和阅读其中的内容会将文件暴露给攻击者（关系数据库也存在着这类问题）。

解决方案是对文件进行加密，这在 db4o 中比较简单。对于大多数场景，db4o 的默认加密模式 eXtended Tiny Encryption Algorithm (XTEA) 对暴露给攻击者的数据进行模糊化。对于其他实例，db4o 提供了一个定制加密 “技巧”，支持使用第三方加密提供程序（不要定义自己的加密格式，除非您可以编写出论文挑战既有标准，并受到全世界密码学家和数学家的关注，而且可以在主流安全会议上进行辩护。如果达到了这些要求，您可以 考虑使用它，毕竟，没有被发现并不意味着不存在）。