操作系统 、 虚拟机管理程序
我们在操作系统和虚拟机管理程序级别遇到的问题在其他系统领域重新出现，解决方案有时是相似的。在本节中，我们将简要讨论数据库，作为操作系统安全原则，问题和解决方案如何应用于其他领域的一个例子[77]。数据库系统的安全性遵循与操作系统中类似的原则，主要关注的是身份验证、特权、访问控制等。访问控制也是如此，其中许多数据库默认提供自由访问控制，以及基于角色的强制访问控制，以便对更敏感的数据进行更严格的控制。
将每个用户表示为一个安全域，我们需要 回答的问题涉及，例如，用户的权限、应记录以进行审核的操作以及磁盘配额、CPU 等资源限制处理时间等用户的权限包括连接到数据库、创建表、在表中插入行或从其他用户的表中检索信息的权限，等等。请注意，有时，除非通过特定的SQL查询，否则无法访问数据库的用户可能会在所谓的SQL注入攻击中制作恶意输入以提升其权限。
虽然数据库级 访问控制限制谁可以访问数据库的哪些元素，但它不会阻止在操作系统级别访问磁盘上的数据。因此，许多数据库支持对磁盘上的敏感表列进行透明数据加密，通常将加密密钥存储在数据库外部的模块中。在极端情况下，数据库中的数据可能会被加密，而只有客户端持有密钥。
查询此类加密数据并非易事。虽然存在复杂的加密解决方案（例如同态加密），但它们非常昂贵且通常使用更简单的解决方案。例如，有时存储信用卡号 的哈希值而不是实际号码就足够了，然后在数据库中查询哈希值。当然， 在这种情况下，只能进行完全匹配 — 因为我们无法查询数据库中的值是否大于、小于或类似于其他值（平均值或总和等聚合值也是如此）。可能）。查询加密数据库 的问题是一个活跃的研究领域，超出了本知识领域的范围。
虽然 常规数据库中的安全性和访问控制已经不平凡，但在外包数据库（ODB）的情况下，事情变得更加复杂，组织将其数据外包对外部服务提供商的管理。具体而言，数据 所有者在外部数据库提供程序创建和更新数据，然后处理客户端的查询。除了我们之前对机密性和加密的担忧之外，出现的问题还涉及对提供商的信任程度。数据所有者或查询客户端是否可以信任提供程序向查询提供由原始数据所有者创建的数据（真实性）、未修改（完整性）和新结果？
从概念上讲，可以通过签名来保证完整性和真实性。例如，数据所有者可以对整个表、表中的行/记录甚至行中的单个属性进行签名，具体取决于 所需的粒度和开销。通常还提倡基于经过身份验证的数据结构的更高级解决方案，例如Merkle哈希树。在最初用于分发经过身份验证的公钥的 Merkle 哈希树中，树中的叶节点包含其数据值的哈希（数据库记录），每个非叶节点包含 其子节点的哈希，以及根节点的哈希已签名并发布。验证叶节点 中的值是否确实是原始签名哈希树的一部分所需要的只是中间哈希节点， 客户端可以使用 与树大小的对数成比例的哈希数快速验证。当然，范围查询和聚合涉及更多，研究人员提出了比默克尔哈希树更复杂的方案，但这些都超出了此知识领域的范围。要传达的信息是，通过一些努力，我们可以保证真实性、完整性和新鲜度，即使在 ODB 中也是如此。
