3 ms·

How exactly is this different from what Oracle has offered as part of Database Vault since the mid 2000s? [1] https://www.oracle.com/database/technologies/secu

by viksit 7y ago

How exactly is this different from what Oracle has offered as part of Database Vault since the mid 2000s? [1] https://www.oracle.com/database/technologies/security/db-vault.html https://www.oracle.com/database/technologies/security/db-vau...

jerf 7y ago
Footnote 5 references "Kristy Browder and Mary Ann Davidson.The virtualprivate database in Oracle9iR2. Oracle Technical WhitePaper, Oracle Corporation. 2002." and in the paper can be found under section 2, "Existing Approaches" with the text "Transparent query rewriting approaches, by contrast, avoid predefined views. Instead, they dynamically insert restrictions congruent with access policies into queries on execution [5, 8, 17]. Both view-based and query rewriting approaches increase the final query’s complexity, slowing it down (e.g., by 3–10×in Qapla [17])." Does that provide any clues? I honestly don't know since I don't know what that Oracle feature is under the hood. Also, I'd point out that my initial reaction to your post was a bit hostile, but I noticed this is a paper so "how does it differ from this $PREVIOUS_WORK" is a fair question. I thought at first it was a project someone did, where that question is perhaps still fair, but a bit, ah, strong to lead with, shall we say.
ms705 7y ago
I'm one of the authors of the paper. Thanks for pointing this out -- while I knew about various advanced Oracle features, I'd missed the Database Vault feature. The multiverse database idea and Oracle's Database Vault are different, but somewhat complementary: 1) Database Vault is designed to protect sensitive application data against privileged users (DBAs, highly privileged role accounts). This is an important problem: administrator accounts are juicy targets, and restricting their access while still allowing maintenance activities is hard. Multiverse databases, as described in the paper, do not solve this problem, as the administrator still has access to the base universe. But ideas from Database Vault and its "realms" concept could be combined with the multiverse DB concept to achieve this! 2) Unlike multiverse databases, Database Vault does not protect the data against a buggy application, nor does it isolate different end-users within a single application from each other. In practice, this is where a lot of leaks do damage: a bug in the frontend either exposes information or can be exploited to expose it. Database Vault won't help here, as the leak does not even require a privileged user to be involved, and since the application runs inside a single realm. You can see multiverse databases as the DB vault idea with application-level end-users each having their own realm. Making realms/universes work efficiently at scale, though, poses some serious systems research challenges. It also raises questions about how to write the policies defining what's visible to each end-user -- something that Database Vault doesn't have to deal with, because it merely requires an application-specific policy that indicates what information is sensitive and needs protecting.

by viksit 7y ago

jerf 7y ago

Footnote 5 references "Kristy Browder and Mary Ann Davidson.The virtualprivate database in Oracle9iR2. Oracle Technical WhitePaper, Oracle Corporation. 2002." and in the paper can be found under section 2, "Existing Approaches" with the text "Transparent query rewriting approaches, by contrast, avoid predefined views. Instead, they dynamically insert restrictions congruent with access policies into queries on execution [5, 8, 17]. Both view-based and query rewriting approaches increase the final query’s complexity, slowing it down (e.g., by 3–10×in Qapla [17])." Does that provide any clues? I honestly don't know since I don't know what that Oracle feature is under the hood. Also, I'd point out that my initial reaction to your post was a bit hostile, but I noticed this is a paper so "how does it differ from this $PREVIOUS_WORK" is a fair question. I thought at first it was a project someone did, where that question is perhaps still fair, but a bit, ah, strong to lead with, shall we say.

ms705 7y ago

I'm one of the authors of the paper. Thanks for pointing this out -- while I knew about various advanced Oracle features, I'd missed the Database Vault feature. The multiverse database idea and Oracle's Database Vault are different, but somewhat complementary: 1) Database Vault is designed to protect sensitive application data against privileged users (DBAs, highly privileged role accounts). This is an important problem: administrator accounts are juicy targets, and restricting their access while still allowing maintenance activities is hard. Multiverse databases, as described in the paper, do not solve this problem, as the administrator still has access to the base universe. But ideas from Database Vault and its "realms" concept could be combined with the multiverse DB concept to achieve this! 2) Unlike multiverse databases, Database Vault does not protect the data against a buggy application, nor does it isolate different end-users within a single application from each other. In practice, this is where a lot of leaks do damage: a bug in the frontend either exposes information or can be exploited to expose it. Database Vault won't help here, as the leak does not even require a privileged user to be involved, and since the application runs inside a single realm. You can see multiverse databases as the DB vault idea with application-level end-users each having their own realm. Making realms/universes work efficiently at scale, though, poses some serious systems research challenges. It also raises questions about how to write the policies defining what's visible to each end-user -- something that Database Vault doesn't have to deal with, because it merely requires an application-specific policy that indicates what information is sensitive and needs protecting.