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