Oracle Database -- In-Depth Security (Preventive, Detective and Administrative)

Just a little joke before we start -> Database Vault - Don't worry, it is not your vault. :)

While thinking about database security, we need consider all the aspects.  Preventing access to data is the key, but detecting unexpected accesses and managing our secure environment should also be in our focus.

Today's post will be about Oracle Database Security.. We'll look at the Oracle products that we use in order to prevent the unauthorized access, monitor and report the access, realize our vulnerabilities (and fix them) and secure the database both in place -physically (at the backend directly on the disk + before queries ever reaching the database) and on-the-fly when queried -- logically. 

Of course, we'll shed a light on the administrative part as well, on the tools let us manage the secure environment.

Actually following picture just by itself sums up the subject quite well:), but  I will still try to explain it all. (of course briefly, but without omitting the important points..)

Let's check what we have..

Well...In the preventive side; we have Advanced Security Option, Data Masking & Subsetting and Label Security.

Audit Vault, Database Firewall, Oracle Database Vault and Oracle Database Auditing.. These are on the detective side.

And, we have Oracle Database Lifecycle Management, Oracle Key Vault and Oracle Database Vault(again) for the administrative side of things..

Okay. Let's take a closer look at each of these products to understand what we mean by Database Security, the purposes that make us place these products in customer environments, and the value we provide by implementing database security projects using these products.

Preventive

Advanced Security Option: First things first; all the functionalities we will about the visit; are engineered to work seamlessly with Oracle Exadata, Oracle Real Application Clusters, Oracle Data Guard, Oracle Golden Gate, and more.

Using advanced security option, we can encrypt data in place, in the database layer. This provides a physical security mechanism that prevents attackers from getting information even if they can bypass the database security layer and reach the bits.. Even in these cases, even if attackers get the data, they will not get any information out of it, because we encrypt it physically, and we have the ability to encrypt the data in columns, in tables or in entire tablespaces. We even have the ability to encrypt things in database exports and database backups. This is called Transparent Data Encryption(TDE) bytheway.

In addition to TDE, we have the ability to redact the data before it reaches the users. It is like blacken the sensitive data on documents. Being able to scribble the data while displaying it, is very important in terms of privacy and security. That is; we can change the data before it arrives to the clients; we change it according to the policies we define, I mean we can do it according to the things like “username”, “IP” and other session information.. 2 more things for this one -> This will be transparent to the application & this brings just a minimal negative impact on workload.

We also have the ability to encrypt all the data transit.. From and to the Oracle Database. For instance; we can encrypt the Data Guard traffic using this option. ( In those old days; I was doing it with SSL tunnels , but now no need for that.. Advanced Security brings us the opportunity to encrypt data guard traffic (redo transport traffic) in a managed way, stable and transparent to the applications.

We have a few more things under this Advanced Security Option. But the things above are the main ones, and we better get going.. We have a long way to go :) 

Data Masking and Subsetting: Using Oracle Data Masking and Subsetting, we basically discover and protect the data by masking it and subsetting it :) 

We mostly use these functionalities in the Test, Development environments. We integrate to the Development and Test environment creation processes and remove sensitive data from those instances. We have a powerful library to change the data in the  Test, Dev environments and we do it without breaking the application integrity there. We mask all the data or part of it.. All can be done according to the data security policies of the environment. There are also ready to use templates for data masking for Oracle Products such as EBS. In the data subsetting side of the things; we can create smaller data sets to save time and storage costs. We have the ability to implement a goal based subsetting.. Such as ; a goal like having a smaller table size in TEST environment. Also we have the condition based subsetting option.. A condition can be for instance; having only Europe based data in the new TEST environment.

Note that, these are in database operations; so they permanently change the data in the database. 

Label Security:

This one is based on Virtual Private Database (VPD) technology. But it requires less effort . 

Label security is easy to enable, and it work on row level. We basically display the data according to the policies. A user (or app) with rights to access sensitive data, sees sensitive data stored in a table, another user who doesn't have that; doesn't see that data, but he/or she may still see the unsensitive part of the data if we like.

Oracle Database Vault:

Oracle Database Vault provides access control even  for the privileged users, even for the administrators of the database. It can block and report those failed attempts (queries from users trying to break security) for reaching the sensitive data. It has a alert mechanism as well.. 

We have lots of solutions for the unauthorized users but what about the authorized users, right? Here, Database Vault comes into play.

Your DBA credentials is stolen? You re still safe (not that safe actually:) if Database Vault is in place. We have a very fine grained access control here.. That is; we can control the access for every single SQL.

We can also prevent unauthorized and unplanned production changes.. (for instance, a developer accidentally making changes to production).. In this context, we can also prevent the execution of DDL commands like (ALTER SYSTEM, ALTER SESSION, ALTER TABLE and so on) outside maintenance windows.

We also implement a true separation of duties in the database. Security administrators manage the security, DBAs manage backup, tuning and etc..

Detective: --> Trust but verify!

Audit Vault & Database Firewall: 

These two are generally deployed together, and that's why I've put them under the same title. But, there is one thing mention, and that is; Audit Vault & Database Firewall can be considered as detective tools, but Database Firewall can also be considered as a preventive tool.

Let's start with Audit Vault;

We may trust ourselves about our database access.. Our database may be secure enough to make us think our data is only accessed by authorized ones, however; we still need to verify this.

So, we capture all the events happened in the database and save them in a secure and centralized repository (a best practice) and we do it almost a fully managed manner.. We then get our reports about these events along with the access information if we like and take our corrective actions.

This is also a quite handy tool for collecting and analyzing of audit data.. Besides we have our audit data in a secure center. This is also a one-stop reporting approach of audit data collected from different sources. We have the opportunity to use ready-made reports populated with our audit records, and these can be created according to our wishes and we may use them for analytic purposes.

Using Audit vault, we can get audit data from non-Oracle sources as well.. (such as MS SQL, SAP Sybase, IBM DB2 for LUW and MYSQL) We can get audit data from these different sources and consolidate them all in our centralized audit repository.

Using Database Firewall, we can block, permit or substitute a SQL before it reaches the database server. It is the first line of defense and that's why we call it a Database Firewall :)

Database Firewall parses the SQL before it reaches the database, and according to the policies, it decides whether it should log, substitute or block the request. We have black lists and white lists as you may guess. There are different deployment options/modes for this one. In-line, Out-of-band, Proxy Mode & Host Monitor.. The behavior and capabilities of the firewall changes according to the deployment mode. I will not get into the details of these modes, if you are curious; just check the Oracle documentation. But I must say, Database Firewall really listens and gets the database network traffic, that's for sure :)

Administrative:

Oracle Database Lifecycle Management: In addition to the convenience it provides in things like patching and provisioning; Oracle Database Lifecycle Management evaluates the alignment of our database environments with the security standards, and checks our systems to see how close they are to the best practices. ( configuration, security, and storage best practices)

Using the functionalities delivered with Oracle Database Lifecyle Management; we can also identify, secure, manage, and track sensitive data in our data centers. Databases can be scanned periodically inspecting either object metadata or the data itself for items matching Oracle or user provided criteria and patterns. An example usage maybe: Use Database Lifecycle Management to identify sensitive data, flag them and then mask them in Test, Dev etc.. environments.. Note that; what we mean by sensitive data is; standard things like credit card numbers, social security numbers, phone number, etc. . But we can also create custom–sensitive column types using regular expressions.

Oracle Database Vault (Again!:)

Oracle Database Vault is back again, in the administrative part also :) In this category, it provides Authorization monitoring feature. It also enables us determine the privileges and roles that are actually used in the database. It also lets us easily identify unnecessary privileges (privilege analysis) (and thus we can revoke them) 

It basically enables us to implement the minimum privilege principle and minimize the security risks based on having unnecessary privileges all over the place. At the end of the day, we have secure applications and database schemas freed from unnecessary access privileges.

Oracle Key Vault (OKV):

It is our Key management solution, closely related with TDE ( Transparent Data Encryption). It provides a centralized key management mechanism which is compatible with the Industry standard. It is for us to use with Oracle Products (such as Oracle Database, Oracle RAC, GoldenGate, RMAN Backups and so on.) Key Vault stores and delivers passwords, tokens, SSH keys, certificates, wallets, and other secrets to authorized users and servers. It can be deployed as a cluster and provide high availability that way.

Set a strong password , don't remember it, just upload it to OKV. So, when you want to connect to the database using that password, get it from OKV programmatically. Don't remember those passwords, don't write them to anywhere.. You see the value of it, right?

Finally, the big picture, Oracle's Maximum Security Architecture.. We see all these instruments in orchestration in harmony ->

Okay, here is where I will stop:) Of course this is a big topic, but I tried to give you the general information that can be used in day 1 of your database In-depth security projects. It is important to mention that, there are also things that can be done in the database without using any of these.. But! these are the best practices and we need implement both in-database security hardening plus these ones.

If you are wondering about what I meant by in-database securing actions, please see the following blog post.. It is for EBS , but you will get idea. ->

 

https://ermanarslan.blogspot.com/2014/07/ebs-122-securing-ebs.html --Securing EBS