94 Part II: Oracle Database Vault racle has always endeavored to increase the capabilities of the Oracle Database. Over the years, staggering innovations have been realized in performance, reliability, extensibility, and sheer capability. Oracle Database is the number one database in the world because of these unmatched capabilities. But as robust as Oracle Database is in the database security arena, a few things about the implementation needed to be improved. It may be startling to discover that, until recently, a security gap in Oracle Database desperately needed to be filled. This gap has become wider and more relevant because of the critical security challenges we face with compliance and cyber security today. Oracle Database Vault fills that gap elegantly and innovatively with additional layers of security. And unlike many features of the database, Oracle Database Vault radically changes what you do as a DBA and how you do it. Therefore, you will most certainly want to review this part carefully In Chapters 4–7, you’ll learn about Oracle Database Vault in detail. This chapter discusses the security gap, including the reasons why Database Vault was created. Understanding the design intent can help you understand why you should use it, when you should use it, and how you should use it. That is the goal of this chapter: To understand why Oracle Database Vault is needed and how its core components work the way they work. Chapter 5 is perhaps the literary equivalent of the military’s basic training. This chapter leads you through the basic workings of the product, including the core capabilities and principles that Oracle Database Vault brings to the database. Chapter 6 puts Oracle Database Vault to work in the context of application building. To appreciate the power of Oracle Database Vault and what it makes possible, the applications used in the examples are somewhat unconstrained—that is, you have the flexibility to modify the application configuration and potentially the code to take advantage of all that the Oracle Database Vault has to offer. Chapter 7 examines Oracle Database Vault in the context of applications, but this time, for existing applications. We debated how to title Chapter 7 because of what the word “existing” can mean. In this context, existing applications are applications that offer you limited modification options. In fact, modifications are largely configurations. Our approach is that you don’t have the luxury of modifying your application’s source code, its accounts, or its structure. Anything you do occurs around the application and in a transparent manner. The Security Gap Chapter 1 covered important concepts about data categorization, identity management, and database account management. Many of those concepts are important to the information covered in this chapter. Specifically, security issues center on object owner accounts or schemas versus user accounts—that is, the accounts we want users to log in to. To understand why you need to use Database Vault, look closely at your core database accounts, including default privileges and their default intent. You may recognize security gaps or suboptimal conditions that can be directly addressed by Oracle Database Vault (DBV). History of Privileged Accounts Recall from Chapter 1 the discussion about two of the primary accounts/schemas for Oracle: SYS, the object owner of the database engine, and SYSTEM, which acts as a DBA user account. Oracle uses metadata tables (aka the data dictionary) to manage many database functions, and the fact that SYS owns these tables accounts for some of Oracle Database’s most serious security O Chapter 4: Database Vault Introduction 95 implications. SYSTEM is the standard account to which DBAs connect to create users, create tablespaces, and perform basic DBA tasks and is covered a bit later in the chapter. Object owners have all rights on all objects they own. For SYS, this translates to full rights on many of the core database objects, including objects owned by accounts supporting any given application. As you will see, the security discussion goes beyond this simple principle. The angst around SYS has recently climaxed in part due to the sensitivity of data and data types such as financial records and personally identifiable information (PII). Governance and compliance issues and concepts such as segregation of duty have also focused attention on SYS. The concern is that SYS has the complete and unregulated ability to do absolutely anything and everything in the database. And unlike SYSTEM, SYS doesn’t need to be granted privileges to do these things. The privileges are automatic because of the object owner principle and because SYS has to work that way for the database to work at all. SYS can not only disable security policies (such as Virtual Private Database, or VPD, policies), but can do even more, such as delete data from the audit trail. This means a user logged into the SYS account has the ability to do bad things, and to do them without any record or trace that they were done. In fact, the issue of deleting from the audit tables drove the requirement for operating system auditing for SYS. Although we cannot stop SYS from performing these actions, we must have a way to audit SYS without the risk of SYS deleting or changing the audit logs. Superuser 0 The all-powerful SYS is not actually intended to be a user. This can be confusing, because you can log into the SYS account with a password, and this process is really no different from the way you would log into any generic database user account. Therefore, it’s difficult to discuss the concept of SYS not being a database user with someone unfamiliar with Oracle but very familiar with compliance initiatives. It turns out that in addition to SYS owning many of the objects that run the database, much of the database code checks to see if the user is specifically SYS. If you query SYS.USER$, you will see a column titled USER#, and for the user SYS, this column has a value of 0 (zero), because SYS is established as the primary owner of the core database objects. What makes SYS a superuser with unyielding rights has a lot to do with the fact that SYS owns many of the objects that run the database. There are two important points to be made here. First, we know that we must have SYS for the database to function. We need to have a container for core database objects. And we need to be able to log on as SYS to install patches, perform upgrades, conduct backup/recovery operations, and perform other important tasks. Removal of the SYS account is simply not an option. The second point to be made is that there is a huge security risk in having a super-user account. Security is essentially and intentionally bypassed with SYS, and this is not optimal for many security architects. It is also undesirable if you are trying to conform to compliance guidelines around segregation of duties. The SYS account’s major risks are not necessarily most severe when an actual person has connected to the database as SYSDBA, but rather when the code underneath the user’s session is operating in the context of SYS. This can occur through techniques such as privilege escalation and SQL injection code that exploit security vulnerabilities. These techniques, if successful, can allow someone to tamper with the database security controls and/or gain access to very sensitive data. Poorly secured databases are certainly targets, but even well-designed and secured systems can be attacked. But these risks can be significantly reduced by upgrading to DBV and adding a few new DBV concepts to your system. One of the fundamental objectives of DBV is to ensure that the SYS account can be controlled and will not inherently bypass the new security layers it introduces. 96 Part II: Oracle Database Vault Other Privileged Accounts It wasn’t too many versions or years ago that all the core database objects were stored in the SYS account. The first departure occurred with SYSTEM, which was created specifically to address the object owner principle and to separate a user from the database objects. At first, many objects were shared with SYS and SYSTEM, but over time, SYS retained sole ownership and SYSTEM became the intended DBA user account. This allowed us to start controlling who has access to what, because SYSTEM required privileges to perform actions (although giving SYSTEM every possible privilege tends to defeat the intended goal). As Oracle introduced more options and capabilities, with the release of Oracle 7.3 there came a need and an obvious desire to create separate schemas in which to install these options. Schemas such as MDSYS, which supports spatial data objects, and CTXSYS, which supports Oracle text objects, came to be. These schemas were meant to serve as containers for the objects that made up the options. (In this chapter, we’ll refer to them as an “option’s schemas” to differentiate them and note their intended role.) In a similar manner to SYS, administrators—and anyone with the correct password—could log onto the option’s schemas. In addition, in combining the object owner principle of SYS and the need to grant many privileges such as SYSTEM, the option’s schemas were sometimes considered to be superusers in their own right. Other accounts of note quickly sprang up as well. Large enterprise applications followed similar models of creating object container schemas with extreme privileges. But this was not isolated to enterprise applications. Many small- to medium-size applications also adopted this architecture. There were good reasons for the apparent excessive privileges, which you will learn more about. Today’s Accounts Today, lots of accounts can do lots of things: SYS and SYSTEM; every Oracle database option schema; enterprise resource planning (ERP) application schemas and user accounts; customer relationship management (CRM) application schemas and accounts; other back office enterprise application suites; and custom and other third-party software schemas and accounts. There are a lot of schemas, and the implementations are fairly consistent, as described earlier. It’s worth repeating that the security ramifications are enormous. All these accounts have login potential. The object owner principle exists, but, more important, vast privileges—often system *ANY privileges—are in place. This allows the schema or a user logged into that schema to do not only what is required for the application or option, but to do quite a bit more than what was originally intended. The Security Remedy Security specialists and best practice recommendations from folks such as the SANS Institute offer a consistent approach to dealing with these security problems: lock and expire the accounts. Other suggestions, such as some made by the authors, have included varying technical Band-Aids such as setting impossible passwords, auditing logons, and sending alerts if someone accesses one of the special schemas. The thinking is that you don’t want people logging into these schemas because they are object owner–intended schemas and not user accounts. In many cases, new requests come in from the security or governance committee, asking if the schemas can be removed altogether. In other cases, such as with the Java Virtual Machine (JVM), removal of the schema can occur, but this is often not a supportable configuration. While the suggestions mentioned here are good security practices, they are still suboptimal. Chapter 4: Database Vault Introduction 97 To resolve the security issues, think about what you need to do to architect this properly. You need to be able to partition schemas to avoid the object owner principle from cross-infecting your applications and data. You also need a way to limit the privileges on those schemas to restrict them to their particular area of responsibility—that is, users should have all privileges only within their application domain. One More Clarifying Challenge One final wrinkle that you may recall from Chapter 1 will help you put this discussion in perspective. Recall that many applications span several schemas, often for good design reasons, even outside the security realm. As it turns out, the system privileges—in particular, the system *ANY privileges (such as SELECT ANY TABLE, DELETE ANY TABLE)—are granted to schemas so that users can access all the tables used by an application regardless of which schema contains the tables. Many applications include thousands or tens of thousands of objects. Direct object grants are not practical. Logging in to each schema to perform an operation is impractical if not undesirable. The only practical choice is to create new object owner accounts and grant the system *ANY privileges, thereby leaving us with a potpourri of user accounts, schemas, and vast privileges. It is a perplexing dilemma. The Gap Identified This last reflection puts a light on the security gap that exists. Before we declare it directly, let’s follow the logic of how we identified this the security gap. To illustrate this point, suppose you are building a sales reporting application in which all the historical sales data is stored in a schema called the SH schema. This application requires some helper objects—materialized views, PL/SQL procedures, and other objects—that you naturally create in a different schema called the SHELPER schema. The administrator for the sales reporting application requires full access to the SH and SHELPER schemas. Logging into one schema does not necessarily do her much good, because object owner rights are limited to the schema in which the admin logs in. (We noted that there are often more than two schemas in most applications.) Logging into every schema is not a practical solution, so the administrator will do one of two things: She will log into one of the schemas directly, such as the SH schema, after having granted system privileges to SH, and she will then use those system privileges to access the SHELPER schema. True user identity is lost in this scenario, however, because it leaves no attribution to the real user who performed the operation. Option two is to create a new user account that can be associated with a real person (let’s call it SR_ADMIN) and grant that user all the system privileges. The good news is that the administrator’s identity is preserved because she has a private schema. The bad news with this option is that it creates another user who can do much more than is desirable for security. You may suggest, as have many, that a new privilege grant or grants are needed to grant all privileges on all objects within a schema to another user. The grant syntax might look something like the following: /* Wouldn't it be nice if we could give all privileges to everything in the SH schema to SR_ADMIN with the following */ GRANT ALL ON SH TO SR_ADMIN; 98 Part II: Oracle Database Vault /* Wouldn't it be nice if we could give select every table in the SH schema to SR_ADMIN with the following */ GRANT SELECT ON SHELPER.% TO SR_ADMIN; Now you see the gap. In Oracle, direct object privileges occur at an object by object level—for example, GRANT SELECT ON SH.SALES TO SR_ADMIN. System privileges exist for all objects everywhere (barring the data dictionary)—for example, GRANT SELECT ANY TABLE TO SR_ADMIN. You can see the need for a middle ground—a privilege set that allows everything within a certain schema or set of schemas. This last notion of a set of schemas is called a realm, and it is one of the new security layers provided by DBV. Before we consider that, and since we are in the mood for improving things in the database, let’s look at a few more security should-haves. Security Should-haves Over the years, as you’ve built security into your databases, you have probably come across a few techniques and methods that were extremely useful and effective. As avid security engineers, we, too, have discovered patterns of success not only within the database but also outside of the database. In this section, we’ll review a few of these methods or requirements that have found their way into DBV. Multifactored Authentication The notion of multifactor authentication is probably a familiar concept. Multifactor authentication involves using more than one item to authenticate a user (or entity) and is usually considered as an alternative to using passwords. Multifactor authentication is considered more secure than single-factor authentication because several authentication mechanisms are far more difficult to compromise, obtain, or spoof than a single form of authentication. Multifactor authentication is required to perform many real-world transactions, such as setting up a new financial account or obtaining a passport. Our objective is to take the notion of multifactor authentication and bring it to privilege enablement within the database. This is the basis for one of the most loved privilege enablement techniques in the database: Secure Application Roles (SARs). SARs are enabled from within defined procedural code. The notion is that simply enabling roles either by default or explicitly (via the SET ROLE command) was generally not good enough. With SARs, the database validates that the SET ROLE call is being made from within the defined procedure code. This complies with multifactor authentication because the code can perform various checks prior to enabling the role. If the checks fail, the role is not enabled. SARs thus gives you a multifactored approach to privilege enablement from within the database. Conditional Security While implementing the logic within the SARs procedures, many popular methods and checks would and could be performed to allow us to form some abstractions and classifications: Context-based security Recognizes that the privilege should be allowed only as part of a specific configuration, fact, function, business flow, or other specific situation. If the situation does not exist, an incongruity exists in the context of what is allowable and supposed to happen, and therefore the privilege should not be enabled. For example, the privilege could be enabled only at a certain time of day or on a certain day of the week. ■ Chapter 4: Database Vault Introduction 99 Alternatively, the privilege can check how the user authenticated, where the user are coming from, and which application the user is using. Adaptive security The overall security is changing in near real time. The procedural code can detect the current state and loosen or constrain privileges accordingly. For example, an intrusion detection system detects an attack and raises a signal that the procedure reads and then denies a privilege request. The core concept is that the security is not rigid, nor does it rely on human intervention; it is designed to adapt itself to the situation. Separation of duty An often dreaded phrase, separation of duty prevents (or attempts to prevent) any single person from performing nefarious actions or duties. The separation forces a co-conspirator to play along. Just as a single factor is less secure than multiple factors, a single user is less secure than multiple users. Within the database, many accounts offer privileges that may conflict with a desired regulation. To resolve this, privileges would be enabled sequentially or would be able to validate that a multiple- person action is taking place. Conditional auditing Auditing is part of the security life cycle, but it suffers many problems similar to those of privilege enablement requirements. Auditing is generally turned on or off. Fine-grained auditing was a major step forward in achieving the desired objective of auditing only when we want to audit. The “when” is based on the contextual basis and adaptive security objectives. Some of the requirements you derive will probably land in multiple categories. This discussion is meant to serve as a new way of thinking about security—that security can be conditional. It is not rigid like a role with its static set of privileges. It should not be turned either on or off. In deciding whether a user may perform an action can be “it depends.” In many ways, conditional security separates the decision-making part of security from the enforcement part. Practical Implementation Lessons Many lessons have been learned in the implementation of security and security policies. One that always comes up is transparency, mentioned in Chapter 1 but worth a replay here because it is an essential element of success for many security implementations. Transparency is important for security because it acknowledges that user or application interference for pure security reasons is always undesirable. If you can secure something without causing extra work for the user or code modifications, then that is the way to proceed. The next lesson learned in effective security implementations is the judicious use of a declarative environment. VPD security is great, but Oracle Label Security (OLS) is better, because OLS is declarative. Having a declarative framework saves coding time, reduces risk, and increases success (assuming that the framework is sound). A declarative framework also facilitates security verification and auditing tasks, as validating settings in the framework is almost always exponentially easier than validating code. TIP Move as much of your code as possible into a declarative framework. This saves time, reduces risk, and allows others to validate the implementation more easily. ■ ■ ■ 100 Part II: Oracle Database Vault Securing by Command A final nice-to-have capability concerns security by command. A command in this context is any Data Manipulation Language (DML) or Data Definition Language (DDL) SQL statement. SARs help to motivate this discussion, because they suggest that a user must have privileges to execute a command, but the command can be controlled conditionally through another layer of security. With security by command, the focus shifts from the role to the ability to execute a command. Assigning privileges directly to a user or grouping them in a role and then granting them to the user should not be the only methods that grant users the ability to execute commands. Instead, we can treat the ability to execute a command in a manner analogous to the conditional security mentioned earlier. Consider, for example, a user’s direct privileges that are required to perform some action (such as using a SELECT on a table), and add another layer that can reject the action if a certain condition is not met. Recall that the conditional security philosophy says that the answer to deciding whether a user should be able to do something is “it depends.” This is not role-dependent. Ultimately, it would be nice for the database to evaluate all commands in a conditional, extensible manner. Database Vault Components Now that we have identified a few areas to improve, let’s look at how DBV addresses these requirements and security should-haves. The objective is here is simply to impart the natural and intuitive architecture for DBV. Having a fundamental understanding of the DBV components— why they are what they are—will help you to employ DBV in an effective manner. DBV is built largely around a declarative framework that consists of tables that store information that drives the desired security policy and security enforcement. The framework is manipulated by a set of web-based user interfaces and a set of application programming interface (API) calls to the PL/SQL code. One of the principles that drove the design of DBV was to provide higher assurance through additional security mechanisms that were separate and distinct from the existing database mechanisms. Risks are not always associated with an actual user’s session privileges; they do occur when the code underneath a user’s session is operating in the context of a powerful privilege that could be exploited for malicious use. The High Assurance Principle (HAP) defines a basic security axiom: the use of multiple security mechanisms from different sources provides a higher level of assurance than using multiple security mechanisms from a single source. NOTE HAP for database security = 1 DB mechanism + 1 DBV mechanism. HAP for database security separates the security mechanisms into two sources: core database security (accounts, privileges, roles, VPD and views, PL/SQL, and triggers) and Database Vault security (factors, rules, realms, and command rules). In addition to making a robust security implementation possible, DBV’s declarative nature helps others—auditors, in particular—verify and validate your security policies. We cannot over- emphasize the criticality of this point. When security is buried inside code, it is more difficult to understand, modify, and reuse. To this end, you will see that DBV has built itself around an easily verifiable, yet robust and resilient, security model. Chapter 4: Database Vault Introduction 101 Factors We’ll start at the most elementary place, which for DBV is factors. Think back to the discussion about multifactored and conditional security. With conditional security, we are not making security decisions based on whether or not a person has the “privilege” to do something. Security is more dynamic and can involve many factors that are checked at runtime and can be very extensible. Multiple factors can be considered when you’re deciding whether or not to enable a privilege or perform an action—time of day, day of the week, how the user authenticated, whether the request was part of a specific transaction, and so forth. Each, if not all, of those elements can be a factor in the overall security decision—that is, the decision on whether or not to allow an action to take place, and the individual elements can be thought of as security factors. NOTE For DBV, a factor is simply an item that you decide to use to make security decisions. Factors are discrete security-related attributes that resolve to a specific value. As you might guess, these factors are generally resolved using PL/SQL expressions. Factors are like application context variables, but you don’t have to develop any code to set, audit, and provide event handlers. Protecting the Security Mechanisms If you have ever employed SARs or written VPD policies with application context variables, you are quite familiar with the use of factors. Everything from the user’s identity, to a client identifier, to an IP address are factors that are commonly used to ensure that the security policies are being upheld. With DBV, factors are declared, named, and stored in tables. This allows factors to be reused, validated, and security enhanced. Factor security is possible because the entire DBV infrastructure is secured. One of the biggest risks to any security implementation is an attack on the logical implementation itself. If you are using PL/SQL to protect your data, either as part of a SAR, a VPD, or even an API to prevent direct data access, what protects the PL/SQL? Without DBV, nothing protects the security infrastructure other than standard security rights, which, as you have seen, are frequently overridden by system privileges. DBV ensures that the things that are used to secure the database are also protected. This is an important point: DBV significantly strengthens any security implementation. It cannot be replicated using any other database mechanism. NOTE DBV protects the things that protect the things. Rules If you’ve written security code, you know that within your security policy or implementation, you construct a set of logical statements. These statements are used to determine whether an action can or should take place. Many statements take the form of Boolean logic that uses logical ANDs and ORs nested inside IF-THEN-ELSE statements. You usually write code that says something analogous to “if this and that, or the user is an administrator, then do choice one, else do choice two.” You could say that the security rule determines which choice will occur. 102 Part II: Oracle Database Vault For a simple database example, consider the following logic checks to decide whether a user can SELECT from a table: The user authenticated using Secure Sockets Layer (SSL). The user’s request comes from the application server’s known IP address. It is currently Monday through Friday. The time is not between the hours of midnight and 6:00 A.M. The user is a member of the SALES_DEPARTMENT user group. What you know about these checks is that each is a security factor. In DBV, each will be represented as a factor that, when called, will return the value in a secure way. We are taking the security factors and putting them together in a logical series of ANDs and ORs, which you could call your security rules. DBV rules are the sequence of factors that you use to determine your security rules. Our five security checks or the factors stated previously could be combined into a rule that is used to determine appropriate access privileges. If all five factors are met, the rule may say, the action can be performed. DBV Rule Sets As with factors, rules are stored in the DBV declarative framework. Depending on your experience, you may quickly identify with this best practice. Quite a few implementations use declarative constructs. The security code reads data from the tables and enforces what the data tells it to do. This makes it easy for you to add or modify the security factors or rules. To modify your security, you add or delete a new record in the table. This is also the basis for DBV rules and factors. It is simple, secure, and intuitive. As DBV was being designed, it became clear that rules were a key component that offered high reusability. Therefore, DBV supports the notion of a library of rule groupings known as rule sets, which allow for a large amount of logic reuse that typically governs access for different controls within an application. By aggregating the rules into a rule set, you gain a much simpler and more maintainable security model. Realms At the heart of our security gap discussion is an architectural quandary. We have been looking at object owners and user accounts and observing default behaviors, possibilities, and limitations. The quandary concerns the use of implicit and granted privileges on objects based on the schemas in which the objects exist and the schema the user is logged into when attempting to access these objects. The ideal schema/user design solution is none of the above. In analyzing the basic security requirements, what you are really trying to do is to apply security to a certain set of users on a certain set of objects. It’s not a certain set of users for all the objects in the database. The system privileges apply to all objects in the system—that is, the database. Unfortunately, system privileges (especially the ANY privileges) are essential, because our applications access many objects across many schemas. We need to alter our thinking, then, about how security is supposed to work. Think about the security requirements for only a single application as opposed to security for the entire database. Application security means that you want to ensure that everything that happens to the data for ■ ■ ■ ■ ■ Chapter 4: Database Vault Introduction 103 the application is secured. You are not concerned about the other data or applications in the database so long as they don’t interfere with your application. Likewise, you want to ensure that any application user or administrator is also prevented from tampering with things outside the application. This is a subtle but important change in thinking for many database experts. Let’s now focus on the simple notion of object grouping, with an emphasis on security. You want to define what your application is with respect to the database. You want to list the objects and schemas and declare those objects to be part of the application. Your ideal security model would then allow you to define the security behavior relevant only to those particular objects without regard to all the other database objects. This all drives the requirement for DBV realms, a new security layer that provides containment and eliminates inadvertent accesses based on system privileges. NOTE Realms are the collection of (application) relevant objects that are grouped together for security reasons. You can think of realms as marking a set of objects—tables, views, roles, PL/SQL, and so forth— that you want to protect, regardless of which account owns the object. The objects are identified across the various schemas and placed in a realm. Once the objects are placed in a DBV realm, they are instantly protected from users with system ANY privileges. The sandbox metaphor used to describe how Java applets are secure within a web browser is also relevant here. Each application, when in a realm, can be considered as being in its own security sandbox within the database. System ANY privileges no longer give you access to items protected within a realm. Therefore, putting your application objects in the same protected sandbox or realm allows you to limit very specifically who gets access to what. Our definition of realms, which used the natural grouping of objects generally associated with applications, helped us explain why you would group objects. However, there is no restriction in DBV for objects to be bound to any application or anything in particular. Realms are purely logical groupings; you define the reason for the grouping. Realm-isms Realms can consist of any objects from any schemas. They are not simply subsets of a single schema. This allows you to maintain a database design based on factors other than security while still being able to support security. Once the objects are in a realm, they are protected from users that have system ANY privileges. Realms can also contain users. The ability to map users to realms works well to support most security policies that define specific application administrators and separation of duty requirements. You can think of users as realm administrators and realm participants. An administrator can execute privilege management commands (GRANT, REVOKE) on objects and roles that are protected by the realm, while a participant cannot. The process of setting up a realm is as simple as defining the objects of interest and then adding users to the realm as either administrators or participants. This allows you to keep other users—even SYSTEM and other privileged accounts— from tampering with objects and data in your realm. Realms generally consist of objects from multiple schemas and are especially important to security relevant information (metadata) such as a table that lists group memberships. Database roles can also be defined as part of a protected realm object in addition to the typical database object types you may identify at first. You can include roles in the realm protections to protect . capabilities and principles that Oracle Database Vault brings to the database. Chapter 6 puts Oracle Database Vault to work in the context of application building. To appreciate the power of Oracle Database. extensibility, and sheer capability. Oracle Database is the number one database in the world because of these unmatched capabilities. But as robust as Oracle Database is in the database security. cyber security today. Oracle Database Vault fills that gap elegantly and innovatively with additional layers of security. And unlike many features of the database, Oracle Database Vault radically