Due to increasing threats and cyber-attacks, new privacy regulations are being implemented such as the European Union (EU) General Data Protection Regulation (GDPR), are also being enforced and the increasing adoption of Public Cloud also legitimate these new Cyber Security requirements.
Data Lake/Hub environments can be a treasure trove of sensitive data, so data protection must be considered in almost all Big Data SQL implementations. Fortunately, Big Data SQL is able to propagate several of the data protection capabilities of the Oracle Multi-Model Database such as Virtual Private Database (aka Row Level Security) or Data Redaction described in a previous post (see Big Data SQL Quick Start. Security - Part4.).
But now is the time to speak about one of the most powerful ones: Database Vault.
Clearly, databases are a common target and 81% of 2017 hacking-related breaches leveraged either stolen and/or weak passwords. So, once legitimate internal credentials are acquired (and preferably those for system accounts), then accessing interesting data is just a matter of time. Hence, while Alexey described all the security capabilities you could put in place to Secure your Hadoop Cluster:
...once hackers get legitimate database credentials, it's done... unless you add another Cyber Security layer to manage fine grained accesses.
And here comes Database Vault1. This Introductory post is the first of a series where we'll illustrate the security capabilities that can be combined with Big Data SQL in order to propagate these protections to Oracle and non-Oracle data stores: NoSQL clusters (Oracle NoSQL DB, HBase, Apache Cassandra, MongoDB...), Hadoop (Hortonworks and Cloudera), Kafka (Confluent and Apache, with the 3.2 release of Big Data SQL).
In essence, Database Vault allows to separation of duties between the operators (DBA) and application users. As a result, data are protected from users with system privileges (SYSTEM (which should never be used and locked), DBA named accounts...) - but they can still continue to do their job:
Moreover Database Vault has the ability to add fine grained security layers to control precisely who accesses which objects (tables, view, PL/SQL code...), from where (e.g. edges nodes only), and when (e.g. application maintenance window solely):
As explained in the previous figure, Database Vault introduces the concepts of Realms and Command Rules.
A realm is a grouping of database schemas, database objects, and/or database roles that must be secured for a given application.
Think of a realm as a zone of protection for your database objects. A schema is a logical collection of database objects such as tables (including external tables, hence allowing to work with Big Data SQL), views, and packages, and a role is a collection of privileges. By arranging schemas and roles into functional groups, you can control the ability of users to use system privileges against these groups and prevent unauthorized data access by the database administrator or other powerful users with system privileges. Oracle Database Vault does not replace the discretionary access control model in the existing Oracle database. It functions as a layer on top of this model for both realms and command rules.
Oracle Database Vault provides two types of realms: regular and mandatory. A regular realm protects an entire database object (such as a schema). This type of realm restricts all users except users who have direct object privilege grants. With regular realms, users with direct object grants can perform DML operations but not DDL operations. A mandatory realm restricts user access to objects within a realm. Mandatory realms block both object privilege-based and system privilege-based access. In other words, even an object owner cannot access his or her own objects without proper realm authorization if the objects are protected by mandatory realms.
After you create a realm, you can register a set of schema objects or roles (secured objects) for realm protection and authorize a set of users or roles to access the secured objects.
For example, you can create a realm to protect all existing database schemas that are used in an accounting department. The realm prohibits any user who is not authorized to the realm to use system privileges to access the secured accounting data.
A command rule protects Oracle Database SQL statements (SELECT, ALTER SYSTEM), database definition language (DDL), and data manipulation language (DML) statements.
To customize and enforce the command rule, you associate it with a rule set, which is a collection of one or more rules. The command rule is enforced at run time. Command rules affect anyone who tries to use the SQL statements it protects, regardless of the realm in which the object exists.
One important point to emphasize is that Database Vault will audit any access violation to protected objects ensuring governance and compliance over time.
In the next parts of this series, I'll present 3 use cases as following in order to demonstrate some of Database Vault capabilities in a context of Big Data SQL:
And in the meantime, you shall discover practical information by reading one of our partner white-papers.
1: Database Vault is a database option and has to be licensed accordingly on the Oracle Database Enterprise Edition only. Notice that Database Cloud Service High Performance and Extreme Performance as well as Exadata Cloud Service and Exadata Cloud at Customer have this capability included into the cloud subscription.
Thanks to Alan, Alexey and Martin for their helpful reviews!