[论文解读] Sieve: A Middleware Approach to Scalable Access Control for Database Management Systems

Primal Pappachan, Roberto Yus+2 more|arXiv (Cornell University)|Apr 16, 2020

Access Control and Trust参考文献 33被引用 5

一句话总结

SIEVE 是一种中间件架构，通过查询上下文感知的策略过滤和索引优化的受保护表达式，减少策略评估开销，实现数据库管理系统中可扩展的细粒度访问控制（FGAC）。在强制执行数千条策略时，其性能相比基线查询重写策略最高可提升 5.6 倍，且在大规模场景下仍能保持低延迟。

ABSTRACT

Current approaches for enforcing Fine Grained Access Control (FGAC) in DBMS do not scale to scenarios when the number of access control policies are in the order of thousands. This paper identifies such a use case in the context of emerging smart spaces wherein systems may be required by legislation, such as Europe's GDPR and California's CCPA, to empower users to specify who may have access to their data and for what purposes. We present Sieve, a layered approach of implementing FGAC in existing DBMSs, that exploits a variety of their features (e.g., UDFs, index usage hints, query explain) to scale to a large number of policies. Given a query, Sieve exploits its context to filter the policies that need to be checked. It also generates guarded expressions that save on evaluation cost by grouping policies and exploit database indices to cut on read cost. Our experimental results demonstrate that existing DBMSs can utilize Sieve to significantly reduce query-time policy evaluation cost. Using Sieve DBMSs can support real-time access control in applications such as emerging smart environments.

研究动机与目标

• 解决在数据库系统中强制执行大量细粒度访问控制策略时的可扩展性瓶颈。
• 在智能校园和物联网系统等隐私敏感环境中支持实时访问控制强制执行。
• 使现有数据库管理系统在无需底层系统修改的情况下高效处理数千条策略。
• 通过最小化策略检查和元组评估，减少策略重写带来的查询执行开销。
• 设计一种通用的中间件解决方案，适用于 MySQL 和 PostgreSQL 等多种数据库管理系统平台。

提出的方法

• SIEVE 使用分层中间件架构部署在现有数据库管理系统之上，以避免厂商特定约束。
• 它利用数据库管理系统特性，如用户定义函数（UDFs）、索引使用提示和查询解释计划，优化策略评估。
• SIEVE 在查询时使用上下文信息过滤相关策略，减少每条元组需评估的策略数量。
• 它生成‘受保护表达式’，将策略分组并利用数据库索引，以最小化磁盘 I/O 和谓词评估。
• 该系统动态创建保护索引，以支持高效的索引扫描，减少处理的元组数量。
• SIEVE 在 PostgreSQL 中使用位图扫描，高效合并多个保护器的结果，进一步降低 I/O 和评估成本。

实验结果

研究问题

• RQ1 如何在不修改底层系统的情况下，使现有数据库管理系统实现对数千条策略的细粒度访问控制可扩展性？
• RQ2 中间件级别的哪些优化可以降低查询执行期间策略强制执行的性能开销？
• RQ3 是否可以有效协调数据库管理系统特性（如 UDF、提示和索引扫描）以加速策略评估？
• RQ4 在策略负载不断增加的情况下，SIEVE 的性能与基于传统查询重写的策略强制执行相比如何？
• RQ5 SIEVE 在不同数据库管理系统平台和数据集上，能在多大程度上保持低延迟查询处理？

主要发现

• 在 PostgreSQL 上强制执行每条查询 1,200 条策略时，SIEVE 相比基线查询重写策略最高可实现 5.6 倍的性能提升。
• 随着策略数量的增加，性能提升更加显著，表明在策略集不断增长时具有强大的可扩展性。
• 即使在 PostgreSQL 中未使用索引使用提示，SIEVE 仍优于基线，这得益于其原生支持使用内存位图合并多个索引结果。
• PostgreSQL 利用内存位图对多个保护器结果进行 OR 操作，显著减少了磁盘 I/O 和评估成本。
• SIEVE 在处理数千条策略时仍能保持低查询处理时间，使隐私敏感应用中的实时访问控制成为可能。
• 中间件方法实现了在 MySQL 和 PostgreSQL 等数据库管理系统之间的可移植性，展现出良好的通用性和实际可部署性。